Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

The Voice of the DBA

Steve Jones is the editor of SQLServerCentral.com and visits a wide variety of data related topics in his daily editorial. Steve has spent years working as a DBA and general purpose Windows administrator, primarily working with SQL Server since it was ported from Sybase in 1990. You can follow Steve on Twitter at twitter.com/way0utwest

How Many Rows Have Changed?

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.

Comments

Posted by Matt Wilhoite on 28 October 2009

Thanks, this is a very interesting article.  I did a little playing around after reading this and Kim's article.  I just wanted to mention a couple of issues I had to maybe help out the next person.

1)  You have to be conneted through the DAC to access the tables.  (At least in 2008)

2)  The table referneced (sysrscols) is in the sys schema

3)  Figuring out how to get readable info out of these tables took a little while also.

Here is what I came up with:

SELECT SO.NAME AS tableName, SC.NAME AS columnName, SSC.*, SSR.* FROM sys.sysrscols SSC

INNER JOIN sys.sysrowsets SSR ON SSC.rsid = SSR.rowsetID

INNER JOIN sys.sysobjects SO ON SSR.idmajor = SO.id

INNER JOIN sys.syscolumns SC on SSR.idmajor = SC.id AND SSC.rscolid = SC.colid

WHERE SO.xtype = 'U'

ORDER BY so.name, sc.colid

Leave a Comment

Please register or log in to leave a comment.