April 5, 2010 at 4:54 pm
If you can, it would be great for you to capture a workload and then some CPU/mem/disk stats before and after compression. That would make a great article on a real world experience.
April 5, 2010 at 4:57 pm
Steve Jones - Editor (4/5/2010)
If you can, it would be great for you to capture a workload and then some CPU/mem/disk stats before and after compression. That would make a great article on a real world experience.
Great idea, I'll see what I can do for this. I think figuring out the right stats to pull is a big part of it. Any tips anyone has to this regard are welcome. I'll probably do some reading on how to measure I/O and then track those stats.
April 5, 2010 at 4:59 pm
Steve Jones - Editor (4/5/2010)
If that's the case, you might be surprised what compression does for you.
I know I like what it does to my DB size. From ~75gb down to ~20.
April 5, 2010 at 5:06 pm
Steve Jones - Editor (4/5/2010)
If that's the case, you might be surprised what compression does for you.
I think I might be considerably surprised as well.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
April 6, 2010 at 1:20 am
Garadin (4/5/2010)
I think figuring out the right stats to pull is a big part of it. Any tips anyone has to this regard are welcome. I'll probably do some reading on how to measure I/O and then track those stats.
My favourite approach to performance trouble shooting is as described by Sunil Agarwal in Chapter 1 of Inside Microsoft SQL Server 2005 Query Tuning and Optimization, combined with the techniques outlined in:
The SQL Server 2005 Waits and Queues Best Practices Article.
and
Troubleshooting Performance Problems in SQL Server 2008
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
Viewing 5 posts - 31 through 34 (of 34 total)
You must be logged in to reply to this topic. Login to reply