One big caveat with sparse columns is that they don't work with compression. Frankly, this is a big mistake by Microsoft, and I hope the company does right by its users, pushing this fix into a service pack instead of waiting for the next release. In the meantime, if you have sparse columns defined on a table, don't expect to compress your data on it as well. I honestly don't know what Microsoft was thinking with this one, but this should never have gotten out the door. Sparse columns and compression are a perfect match; this one may deserve a Darwin Award.

Compressed indexes are just what they sound like: another opportunity to save storage space. Filtered indexes allow you to put a where clause (just like a query) on your index so that only a portion of your table is indexed. It may seem counterproductive, but there are several instances where you would want to filter an index. The perfect example is with sparse columns. Instead of keeping an index that contains mostly nulls, you would put an index on the sparse column where the value does not equal null. This way, only the rows with actual values will be indexed and the size of your index decreases significantly.

Good workload, bad workload

The Resource Governor is Microsoft's first real attempt at a resource governor in SQL Server. And honestly, it doesn't hold a candle to Oracle's. SQL Server 2008 allows you to define resource limits on memory and CPU, which is a good start, but as I said in my review of Oracle Database 11g, those metrics quite often aren't adequate to define a rogue workload.

In Microsoft's defense, the aim of Resource Governor isn't to define rogue queries just yet. In this first version, the goal is simply capping those resources for workloads to help keep them from becoming rogue processes. Of course, that still doesn't solve the problem of excessive disk usage or processing time. And there's no way to automatically move a process to a defined Resource Governor if it starts using too many resources. A process either belongs to a Resource Governor and has its resources capped, or it doesn't.

I think the biggest boon for this feature may be on OLTP (online transaction processing) systems where some light reporting may be necessary and you don't want it to take up too much of your server's resources. You can put the query processes into their own Resource Governor to cap their resource usage and keep the bulk of the server's power for the OLTP load that actually makes money.

Change Data Capture (CDC) is a very nice feature that I think will be very popular among DBAs grappling with ETL (Extract, Transformation, and Load) processes. CDC allows SQL Server to capture which rows and columns have changed on the defined columns and put the changes into a separate table that can be queried by ETL. The benefit is knowing -- without having to perform extensive queries -- which rows have been inserted, deleted, or updated. Currently, finding these operations in a table isn't easy, and you quite often have to write code into your process to mark these activities. But with CDC, you can define these audit policies at the database level and not have to make those drastic changes to your application code.

This release also brings Policy-Based Management (PBM), which is a way to define policies for any number of boxes that will be either enforced or alerted on when the server is out of policy. You can define almost anything for your policies, so even something like making sure that no tables begin with the prefix "tbl" would be one policy that you could enforce. You can make another policy that says all databases should be backed up every day, in order to be alerted if one of your servers misses a backup. PBM is going to be a very powerful tool for SQL Server going forward, and so far, I really like what I see.