SQL Server

Linchi Shea has an update to his T-SQL exercise, to produce the simplest data-loading script to produce worst query performance. “The original intent,” writes Linchi, “was to highlight some pitfalls in data loading that may lead to bad query performance. But then I thought why take all the fun away by having too many constraints, and why not just let it loose and see how bad it can get if one is to do it intentionally.”

Aaron Alton, the HOBT, was likewise thinking on ways the SQL DBA goes awry. His conclusion: easy on the updates there, sparky. “To the unsuspecting database developer, it may seem that some operations in SQL Server are more or less ‘free’. Let’s clear the air on that one – nothing is free, ever. Or if it is, it usually has a 30 day limit. It’s easy to forget this, because when you’re working with something like SQL Server, it’s hard to imagine that a sub-second response time can hide anything of significant concern.”

Sometimes you don’t need to make things bad intentionally. For example, when a decimal isn’t a decimal. Simon Sabin writes, “To say the type system in SQL is lax is an not quite correct, its actually lax, inconsistent and very annoying.”

On the Oracle Scratchpad, Jonathan Lewis describes “CPU used,” which demonstrates how, “‘CPU Time’ in the ‘Top N Timed Events’ . . . [looks] very different from the ‘BUSY_TIME’ that appears in the ‘OS Statistics’ part of the [Statspack] report.”