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.
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!