[callout]In a previous blog post, I discussed how you can use database backups to forecast disk capacity if you don’t have a monitoring tool in place. And, because it’s common for existing environments to NOT have any monitoring tools implemented, you need to be very creative and work with what you have to accomplish your tasks. In this series of blog posts, we’ll look at how to analyze database activity if you don’t have a monitoring tool.[/callout]
In part 1 of this series of blog posts, we started looking at how you can analyze database activity by looking at the contents of the transaction log backups. If you’ve followed the steps provided in the previous blog post, you should be able to create a worktable that contains the aggregated values of INSERTS, UPDATES and DELETES per transaction log backup. A sample output from the worktable may look something like this.
|SampleDB||INSERT||4581||May 25 2011 5:40PM|
|SampleDB||UPDATE||1097||May 25 2011 5:40PM|
|SampleDB||INSERT||758||May 25 2011 5:40PM|
Continue processing all of the transaction log backups that you’ve collected based on the dynamic SQL generated from the production database. Once you’re done with the processing, you can then import the data in Excel to create graphs and charts of the transactions within the specified period. Here’s an example chart displaying the volume of INSERT transactions on a sample database. This data is from a former customer from way back 2011. Note the trend in the amount of INSERT transactions early on in the analysis.
You can start creating the charts for the UPDATE and DELETE transactions to complete your analysis.
While this is a great way to analyze database transactions without having monitoring tools, it’s not without flaws. First, the INSERT/UPDATE/DELETE transactions recorded in the transaction log contain more than the information you need. The data you got from the queries that process the transaction log records are a bit skewed. Second, you really need to have an understanding of what your database does and the overall schema. Some of the questions that you may ask your database developers (or vendors if it’s a third-party custom application) are the following:
- How sure are you that the INSERT transactions on your database only pertain to new sales generated?
- Does the database include logging and audit functionality that also inserts records on an audit table within itself?
- How do new sales transactions get added to the database?
These are some of the things that you need to understand in order to quantify the results of your analysis. Your responses to these questions will determine whether or not the data you got from the analysis are inaccurate and skewed. They’re good enough to give you a sense of the database activity but still inaccurate, nonetheless. Fortunately, the transaction log (including the transaction log backups) contains the information you need. If you have the name of the table that is used to track sales information, you can start digging deeper into the transaction log records to be more specific. For now, let’s work on what we have to at least get a report of the analysis of database activities. Give the report to your boss and see how he responds.
In a future blog post, we will look at digging deeper to find out the amount of INSERT, UPDATE and DELETE transactions for a specific table. Stay tuned.
[callout]NOTE: These tricks are not intended for you to just ditch having a monitoring tool. It is highly recommended to install and configure a monitoring tool for your databases so that you can be proactive about managing your databases instead of being reactive. Have a look at SQLSentry’s Performance Advisor to start getting a glimpse of what’s happening in your SQL Server databases.[/callout]