Comments on: SQL Server Data Compression: It’s a Party!

By: Brent Ozar

Brent Ozar — Wed, 19 May 2010 13:56:04 +0000

Paul – howdy, sir. The cost is usually heavy on highly written tables. If something’s being constantly inserted/updated/deleted, the CPU cost might overcome the IO benefits. The best scenario is large tables that get rarely updated, like data warehouse fact tables.

By: Paul

Paul — Wed, 19 May 2010 13:51:44 +0000

At what cost is compression ?

Being in this field for a number of years, there is one thing I learned “You get nuttin’ for free, there is always a cost”. I am ready to migrate one of our risk systems to 2008 from 2005, and compression looks like gold (gold, Jerry gold – Banya), especially for some of the huge, flattened out fact tables that are in the system, I’m talking a 7K row. I did not realize that you can use BOTH row and page compression on a table.

By: Brent Ozar

Brent Ozar — Mon, 12 Apr 2010 20:36:27 +0000

Hugo – yep, and you also have to make sure you don’t have Standard Edition in your disaster recovery environment. That makes for an ugly surprise when you try to recover from a production outage only to find you don’t have the right edition available, and you can’t restore your databases. Whoops!

By: Hugo Shebbeare, SQL Server MVP

Hugo Shebbeare, SQL Server MVP — Mon, 12 Apr 2010 20:33:28 +0000

Great points! Didn't think about inheritance. I wrote on this subject with several code examples on SSC last year, with even a presentation given in Vermont, last Spring. It was early 2009 I posted, after a great project in previous Spring of 2008 using SQL 2005 Entreprise Ed.'s VarDecimal conversion - highly effective if you are still in SQL 2005 and your databases are heavy financial decimal data type dependant. If you are using 2005/8 Developer Edition, you have all the features of Enterprise, therefore you can compress with ease - u just cannot use Standard Ed. for this function. More code examples for SQL Server 2008.