Showing posts with label SQL Saturday 62. Show all posts
Showing posts with label SQL Saturday 62. Show all posts

Saturday, January 15, 2011

SQL Saturday 62: Slide Deck & Presentation

Hello Dear Reader,
      Since SQL Saturday 62, I've been a little busy with a sick baby girl, and didn't have the time to get my Slide Deck online until now.  Click here to view the slide deck.  I want to thank you for your interest.
      The first presentation went well, I got some really good feedback from the some of the DBA's in the audience I'm looking forward to re-working a couple things.  I wanted to list my thoughts.

Presenting

I was a little nervous leading up to the presentation, as a kid I was always involved in drama, plays, and musicals.  I went to a Magnet High School for the performing arts in Atlanta, GA and my concentration was in Drama.  We moved from Atlanta to Asheville, NC and I continued to concentrate on my acting but I also joined the football team, wrestling team, and played soccer (indoor and out-door) as well.

Needless to say between acting and sports I'm used to being up in front of an audience, and to be honest I kind of like it.  So you would think that all of that would prepare me to go in front of the SQL Community and present. 


(This picture would be more accurate if the Hulk was renamed the Demo)



Demo SMASHED!!!!

I rehearsed my Demo's quite a few times.  The last thing I wanted to do was be caught unprepared, but somehow that is the one thing that happened. 

I tried to do a little too much in my demo's, my subject being compression I wanted to create a set of tables that were sizable, with around 15000 rows, and then apply compression.

Re-creating the tables was taking around 38 seconds when I was testing everything out over the last several days.  On the day of when I went to load up my table I knew there was an issue when I went to run the first insert and after 1 minute and 45 seconds it was still running.

So I did what any actor would do in the case where their props fail them, I improvised.  While I wasn't able to load the tables to the full extent that I wanted I was still able to insert data, and run the compression scripts against them.  What I wanted to convey I was still able to.  All of the info in my Slide Deck was still there, all of the knowledge I have on the subject was still there, I took a deep breath and just kept moving forward.


Always Have a Backup Plan

Since the failure of the Demo's my mind went into troubleshooting mode, you can't really stop your talk to throw up Perfmon or start analyzing your wait stats in the middle of the Presentation.  Well you could, but since the talk was on Compression and not wait stats it didn't seem like the right thing to do.  

But when I got home the first thing I did was reboot my laptop and try again.  This time I could let the demo run, needless to say 38 seconds had turned into 5 minutes and 50 seconds.  YOWZZA, I'm glad I stopped and kept speaking.  Looking at my wait stats I was ready to do some analyzing when by happy accident my battery fell out while the laptop was unplugged, after that reboot everything went back to normal.  But even at normal I don't want to get caught unprepared.

So I started building my backup plan.  There are a bunch of different ways I can present to get my point across, I would like to say I would isolate and fix the issue my laptop was having, but it is working swimmingly right now (YAY and BOOO all at the same time).

I was a Boy Scout at one point in life and I do remember the motto of "always be prepared", and it has not left me.  So I'm looking forward to the next round of presentations, because I will have worked up how I can get my demo's done at least 3 different ways so I don't get blindsided again.

Not sure when the next Page & Row Compression presentation will be but I'm already looking forward to it.

Thanks,

Brad

Tuesday, December 21, 2010

SQL Saturday 62: Row Compression

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

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? 

Think Vacuume Sealed.

And Tastey, Tastey meat.
But mainly Vacuume Sealed.




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.