Thank You PASS DBA Virtual Chapter

Yesterday I was able to do my first webcast, a presentation for the PASS DBA Virtual Chapter.   A Big Thank You to Idera for being the Webcast Sponsor!  Go check them out they are a great SQL Community Member, and a Sponsor of user groups and SQL Saturday Events.  I want to Thank everyone who was able to take time away from work, or during, to attend.  I would also like to thank Sharon & PASS for having me present.  Last but not least I would like to say a big Thank You to Mike Clark for being my Presenter, he made the experience super easy, and was a pleasure to work with!  Mike You rock!

So Dear Reader, the topic at hand was Compression.  I did my presentation that will be part of the up-coming SQL Rally, May 11th - May 13th, in Beautiful Orlando FL.  We have an amazing line-up of SQL Proffesionals throughout the industry that will be on hand.   And for the cost of less than $500 (if you sign up now and that is INCLUDING the Pre-Con)!

DECK & SCRIPTS

My Deck & Scripts were the same that I've used before but I wanted to post them for download, in case anyone would like to use compression.  I want them to have all the tools they need to get started.

Get my Slide Deck Here.

And all the Demo's Here.

QUESTIONS
A Question was asked after the presentation, forgive me if I butcher it, But the main idea was as follows.

 "I've compressed all of the tables in my database, my CPU is below 40%, are there any KNOWN issues with this?  And what do you recommend?"

There is always a case that will be the exception of the rule.  I would not recommend compression your entire database, just like I would not recommend compressing the entire contents of your C Drive.  Sure you'll save some space, but your performance will go down hill because of the overhead.

When you look through the Demo's there is an order that I like to suggest people go through.

1. Look at the Size of your Tables.
2. Look at the Makup of your Tables Allocation Unit's (Only IN_ROW_DATA Compresses)
3. Look at your Scan & Update pattern usage, this will help determine the type of Compression you should use.
4. GET A BASELINE!!! Look at your Table and/or Indexes Size, I/O's, CPU, and Runtime Before.  Then Look at them After.  Do a comparison.   If anything has changed for the negative, then perhaps you shouldn't be using Compression on that Table and/or Index.

It is possible that someone out there has a system that could benefit from every table being compressed, It's not outside of the realm of possibilities.  However, I would wager that would be a very Rare Scenario.

Compression is like Indexes, used properly it is a beautiful thing, but too much can tank your performance.

Thank's Again to everyone who could make the Presentation, I hope you are motivated to go to SQL RALLY!

Thanks,

Brad