Search Results

Webinar: 8th Feb 2018

Preventing SQL Server Performance Problems Before They Hit Production Join Mark Allison, Paul Anderton and Kevin Kline at 3pm UTC on 8th Feb 2018 Wouldn’t it be great if performance problems in your SQL estate could be detected BEFORE they reach your production databases? In this demo-centred webinar we will review: How to detect and prevent releases of code that could reduce performance of your SQL Server database Ways to prevent the most common performance problems before they reach production: missing indexes, deadlocks and excessive key lookups How effective SentryOne can be in a DevOps pipeline both on-premise and in

Automating adding servers to Sentry One

Overview Sentry One is a great tool for monitoring many servers. For new installations, it can be a bit of a bind to add your existing servers into the tool to be monitored. I have written a PowerShell module to make this much easier and to validate that servers that you thought were being monitored, are in fact monitored. There is full documentation for the module in the Sentry One user guide which explains how to use the functions within it, but a brief explanation is shown below. it is worth mentioning that all the PowerShell cmdlets are doing is

Running a SQL Server workload using PowerShell

In February 2018, myself and Paul Anderton gave a presentation on how to correlate database deployments with performance issues within the context of a DevOps pipeline. We used Sentry One as our monitoring tool in a Performance Test environment so that we could catch badly performing deployments before they got to production and caused havoc. If you would like to see the recorded video, then you can download it from here: http://info.sentryone.com/partner-webinar-performance-problems As part of this presentation we had a workload running on a workstation, which executed a couple of stored procedures repeatedly, and we’ve had some requests from people

Automating SQL Server Performance Testing

You run performance tests as well as functional tests when deploying new code changes to SQL Server, right? Not many people do, I think you should, and this article will show you how to do it by harnessing an existing performance tool, rather than writing your own monitoring infrastructure from scratch. Any good performance monitoring tool that records information to a database will do fine, and we prefer to use Sentry One . Here are the steps to accomplish this. Create a baseline database When you release your database change, you want to have something to compare against as an