SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 

Monitoring After Deployment

By Steve Jones,

Deployments of database and application changes have tended to be stressful in my career. I've seen the actual deployment of changes fail, installation programs crash, the startup of an application error out, or the famous blue screen of death from a .DLL change. I've been most wary, and worried, when the changes were out of my control, and I had no chance to review things.

For most database upgrades, however, I've been able to examine scripts. Even when an installation program is making changes, I could run a test on a separate instance and use Trace to capture the SQL that would be executed. However even when the actual installation succeeds, what I'm often most worried about is a logic or performance problem that won't reveal itself for hours, often not until the next business day when the system is under full load.

This week I wanted to know what formal (or informal) checks people might have to detect issues. I'd like to know if you are you actually monitoring systems in a scientific way that allows you to determine if some database deployment has gone awry.

What Monitoring process do you use to determine if a deployment is working?

One of the customers for Red Gate software noted recently that they have a series of metrics being captured on their systems with SQL Monitor. They can compare the performance of two time periods, say the 4 hours before a deployment with the 4 hours after (or 4 hours the next day) to determine if any issues have surfaced. That's similar to what I've done in the past for performance using other tools, or my own metrics. I've often kept baselines of common queries run during the day, and I can compare that to post-deployment metrics to uncover potential issues.

Logical errors are more problematic, and I've often wanted to be sure I had a couple of backups stored, and at least one backup on a warm standby in case we find information is being incorrectly changed or calculated. Those are the worst errors, and since they is no way to determine how they might surface, I have usually ensured myself and other DBA staff were on standby to perform some manual ETL to move data around between databases in a hurry.

Monitoring is an important part of being a DBA. It's not as critical as backups or security, but it's not far behind in letting you know when something is not right. Let us know this week what tricks you might have to ease the worries you have after database changes.

 
Total article views: 117 | Views in the last 30 days: 1
 
Related Articles
ARTICLE

SSIS: Case sensitivity may expose issues with change deployment

Because SSIS is case sensitive, random VS_NEEDSNEWMETADATA errors on case-insensitive databases may ...

FORUM

Database objects deployment

Database objects deployment

BLOG

SQL Server monitoring and optimization

To optimize the performance of your database, you need to monitor and tune. You determine the perfor...

FORUM

Monitor SSAS database size

Monitor SSAS database size

FORUM

Monitoring Connections to Databases

Monitoring Connections to Databases

Tags
deployment    
editorial    
friday poll    
monitoring    
 
Contribute