Everytime a good product comes out, people seem to contrive bad ideas for what can be replaced, usually brains, or people with brains, or that people lacking brains can accomplish something on their own. Let me put it simply. Suppose one had a query that uses a nonclustered index, and required a key lookup, and the key lookup required a disk ...

An observant person has probably noticed that SQL queries requiring disk reads not only have longer duration but also higher CPU times. It is not hard then to deduce that disk access (for both HDD and SSD), which involves the OS performing an IO call, the SQL Server process finding a place in the buffer cache for the data pages, and possibly ...

I recently received a question about the storage of nonclustered index keys. I am assuming you are aware of the fact that if your table has a clustered index, SQL Server uses the clustered index key (all of its columns, if it is a composite index) as a 'bookmark' in your nonclustered indexes,  to allow your nonclustered indexes to uniquely ...

SQL Server 2005 allows rows to include variable length columns which do not actually fit in the maximum row size of 8060 bytes. I previously posted about row-overflow columns, and discussed the maximum number of such columns that you could have in a single table. You can read that post here. Just recently I received another question that ...

At least, I think it might become my new favorite tool.  J One of my readers created a tool to graphically display database storage internals, like allocation information, actual page contents, etc. This is just the tool I would have wanted to write if I ever got back to doing any programming. Here's what the author, Danny ...