I'm really excited to be selected as a speaker for SQL Saturday 62 in Tampa on January 15th 2011, register today at http://www.sqlsaturday.com/62/register.aspx !
Just a quick blog this evening, the whole family, myself included, have been under the weather. I wanted to get something out on this, and I’ll put more out in the coming days.
The topic I will be presenting on is Compression. My session is titled Page and Row Compression How, When, and Why, and I’m very excited to be presenting on this topic. There are also a lot of really great sessions but other speakers, to check out the full line up click here.
I'm going to break up the subject and talk about it in parts, we will start with a very brief introduction to the concepts in Row Compression..
Row Compression was introduced to us in SQL 2008, it’s predecessor was vardecimal compression introduced in SQL 2005, and subsequently deprecated in SQL 2008. It is still available in 2008, but vardecimal compression does almost the exact same thing as Row Compression, but on variable length numeric fields.
The premises is that you take the variable length columns from a record and you make them a fixed length field, you take the variable length array and covert it from a 4 byte field to a 4 bit field, and there is also special handling for nulls and zero values.
In SQL 2008 R2 Row Compression was extended even further to include Unicode support.Okay, it sounds smart but what does it mean?
We are extracting every bit of extra space down to trim the size of the data stored in a record on a page. Row compression should be synonymous to you as saving space!
If you move from a bigger house to a smaller house then you toss some things out, re-organize, possible consolidate a little. This is what is going on. Now keep in mind that not all data-types are covered and this is for In Row Data, LOB and Row Overflow data will not be compressed.
We’ll save more for later, but needless to say we next need to talk about Page Compression, what makes it up, how to tell if your tables are candidates for compression based on your record types. Also your tables activity level, and type, can help you estimate what kind of overhead to expect from compression.