I’ve grown up reading Tom Clancy and probably most of you have at least seen Red October, so this book caught my eye when browsing used books for a recent trip. It’s a fairly human look at what’s involved in sailing on a Trident missile submarine…
One of the things that I’ve asked DBAs, and I see asked often, is how much does your data change? That affects the transaction log sizes (and backups), the load on your server, possibly the tuning and specs you want to implement, etc. But most DBAs don’t have any clue what the change rate on their data is. Most probably can’t even tell you quickly what their data growth rate is.
The good ones can, and many of them either track it, or they do what I used to do: they monitor backup sizes and calculate an acceleration and velocity that assists them in proactively managing servers.
That accounts for growth, but what about changes? Very few DBAs know this, and it seems like it’s an advanced topic. I’ve never had a great, homegrown way to track this, and haven’t worried about it. Most of my systems could have weekly downtime, and I’d rebuild indexes, and statistics, during that time, so it wasn’t an issue.
The other day I was reading Kim Tripp’s blog because, well, it’s a good idea. She doesn’t post a lot, but when she does, it’s good stuff to know. In this post she talked about filtered indexes and statistics going stale quicker than expected. I’ll let you read it if you’re interested (you should be), but the interesting thing to me was her mentioning a way to know how many rows have changed.
In SQL Server 2000, there’s a value in sysindexes.rcmodctr that keeps track of how many rows have changed. This is used to note when to refresh statistics (it’s when 20% of the rows have changed).
In SQL Server 2005 and 2008, this is tracker per column, which may or may not be better. Read Kim’s explanation of that. However the values are in sysrowsetcolumns.rcmodified for SS2K5 and sysrscols.rcmodified for SS2K8.
That’s a handy piece of information for me to know. I can now easily track the number of rows that change daily, and then get some averages that might clue me in to the activity of the database. It’s not that this average means anything by itself, but if I know it, and then compare the last day’s change against the average, I’ll have some idea of the load on my server. Might help me diagnose issues, or let me know if the server if coming under more load.