Sudden performance issues in SQL Server can have many causes, ranging all the way from malfunctioning hardware, through to simple misconfiguration, or perhaps just end users doing things they shouldn’t. But one particularly common culprit is when deployments go wrong: I don’t know a single DBA who hasn’t been burned by a bad release.
To help, hundreds of thousands of developers and DBAs use Redgate’s Database DevOps solution to automate the build, test and deployment of their database changes. By implementing reliable, scalable and repeatable processes the risk of introducing defects into production is significantly reduced. But what if the change behaves differently to expected in the production environment?
Here’s the top of SQL Monitor’s Server Overview screen – the sort of screen you might be looking at after learning that a server’s running slowly. SQL Monitor raised a High CPU alert at 8:31, and it’s pretty clear that something went dramatically wrong shortly beforehand, but what?
At this point, the challenge is to narrow down the root cause as quickly as possible. As the DBA, this kind of investigation turns you into a detective, where every minute taken to find the problem has a real cost to the organisation’s productivity, as well as to your reputation.
While bad deployments can eventually be tracked down by following other avenues, SQL Monitor now makes the cause of the problem instantly obvious by surfacing deployment information generated by Redgate’s deployment tools (DLM Automation, ReadyRoll, and SQL Compare) in context within SQL Monitor.
You now see the release marked on the timeline immediately below the performance data, and upon hovering, we see which database was deployed to, as well as by what tool. This saves valuable time by instantly revealing the smoking gun, with no further exploration needed.
This capability is part of Redgate’s SQL Toolbelt – it is available today for any changes made by the latest versions of DLM Automation and ReadyRoll, and will ship in SQL Compare within the next couple of weeks. There’s zero setup needed, either in SQL Monitor or in the deployment tools, so changes made by anyone in the organisation using these tools will automatically be shown.
Sometime in the future we hope to advance this even further, with information about the user responsible for making the change, and potentially the build number in the case of automated deployments. But for now, we hope that simply being able to correlate changes in key metrics with releases at a glance will make your life a little easier.
Check out the latest version of SQL Monitor, or read more about Redgate’s Database DevOps solution. As usual, we’d love to hear your feedback. How can we improve this further? Just drop an email to firstname.lastname@example.org.
To take advantage of this capability, you’ll need to be running SQL Monitor 7.1.5+ along with SQL Compare 13.0.3+, DLM Automation 2.0.18+, or ReadyRoll 1.14.13+. Additionally the deployment tool must be licensed as part of the SQL Toolbelt, rather than as a standalone product. The user making deployments will need to have execute permission on xp_logevent (or can alternatively either have the dbowner role on the master database, or be a sysadmin).
Also in DLM Automation
While the practice of Continuous Integration (CI) started with application code, you can apply the same principles to databases. Database CI is the process by which we build, test and deploy the datab...
Also in Hub
Do not use a scalar user-defined function (UDF) in a JOIN condition, WHERE search condition, or in a SELECT list, unless the function is schema-bound. Scalar UDFs are often used without a parameter to...
Also in Product learning
Snippets are a great feature of SQL Prompt. They save coding time, and introduce standards and consistency to the way you build code modules. They have multiple replacement points (placeholders) for p...
Also in ReadyRoll
Deploying schema changes to SQL Server databases can be tricky when you’d like to automate parts of your workflow. For instance, how do you go about version controlling your schema changes? In appli...
Also in SQL Compare
Inherited a database from another team? Changed your team policy on the way that you format SQL? What's to stop you formatting the code of an entire database nicely, when you're developing it? It can ...
Also in SQL Monitor
SQL Prompt's Code Analysis feature helps you discover code issues and hidden pitfalls during code development, as you type. It also provides tips for improving your code, and includes links to documen...
Also in SQL Toolbelt
For many companies, particularly those in the financial sector, a key technology consideration is risk management because if systems go down, it can cost a lot of money very quickly.
Take ABSA Bank, ...