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.  Read more...

SQL Monitor’s dev team has made huge improvements to the product over the last year. In the first half of 2017 alone, they released reporting capabilities, support for collecting metrics from VMWare hosts, significant improvements to performance and scalability, improved configurability of alerts, as well as dozens of smaller enhancements. Since we’re about half way through 2017, it’s time to talk about the plans for the rest of the year.  Read more...

The Redgate SQL Monitor team has been looking into how you can more effectively monitor SQL Server running on a virtual machine, and are pleased to announce that they've begun this by introducing support for VMware in SQL Monitor version 7.0.11. Find out more about the beta feature in this blog post.  Read more...

When something's wrong with your database you need to be able to identify the primary pain points within SQL Server and get to the root cause of the problem fast. Grant Fritchey explains how you can use execution plans inside SQL Monitor to help quickly and simply identify the problem.  Read more...

Learn about deadlocks and how you might better troubleshoot the issues involved.  Read more...

Any SQL Server monitoring tool must gather the metrics that will allow a DBA to diagnose CPU, memory or I/O issues on their SQL Servers. It should also provide a set of accurate, reliable, configurable alerts that will inform the DBA of any abnormal or undesirable conditions and properties, as well as specific errors, on any of the monitored servers. This article provides an in-depth guide to the monitoring and alerting functionality available in one such tool, Redgate SQL Monitor. It focuses on the latest edition (5.0), which includes several key new features, such as performance diagnosis using wait statistics, the ability to compare to baselines, and more.  Read more...

This metric is useful if you want to know exactly how much physical space a particular table is taking up, including the size of its indexes.  Read more...

Anthony Nocentino, experienced Enterprise Architect and Friend of Redgate, explains the challenges presented by monitoring Availability Groups and shows you a technique for monitoring AG replication latency with Redgate SQL Monitor and its Custom Metric functionality.  Read more...

This metric measures the amount of memory used by the total number of ad-hoc queries that are currently in the plan cache. If the value is high, it indicates memory is being wasted by storing the execution plans of queries that will never be run more than one time.  Read more...

This metric shows Writelog wait time in ms, per elapsed second. Writelog wait types occur when the log cache is being flushed to disk. If this happens all the time, it may suggest disk bottlenecks where the transaction log is stored.  Read more...

This is a good general indicator of performance problems. High stall times indicate I/O problems, which can be attributed to busy physical disks or queries that return large data sets to the client.  Read more...

This metric collects the number of 8-kilobyte pages that make up the plan cache to help identify memory pressure or plan cache pollution. A sudden drop in values for this metric may indicate that the instance is under memory pressure and SQL Server had to reclaim part of the plan cache for other use.  Read more...

After examining the SQLServerCentral servers using the sp_Blitz™ script, Steve Jones now looks at how we will use the script moving forward.  Read more...

This alert is raised when the number of hash warnings events in the last hour goes above a specified threshold. A hash warning event means that part of the data processed for a hash operation was written to tempdb during query execution, which can degrade SQL Server Performance.  Read more...

If your code uses temporary tables, variable tables or dynamic cursors, this metric can help identify whether you have contention on tempdb allocation. Tempdb is shared by all databases and is used for many operations in a SQL Server instance, so it is common for tempdb to cause performance problems.  Read more...

This metric can help if you want to monitor the number of indexes per database that haven't been used for the last month. Indexes that aren't in use should be removed because they can degrade INSERT, UPDATE and DELETE performance, and they use storage space.  Read more...

This is a general indicator of performance problems. Index fragmentation can affect the rate of return for moderate to large tables. If this value indicates an increased amount of index fragmentation throughout your database, you may need to fine-tune your indexes by redesigning, or rebuilding more frequently.  Read more...

If your application relies on identity columns, this metric is a useful measure of the number of identity columns that are near to the limit per database. You can then avoid logical problems in your application and SQL Server errors.  Read more...

This metric picks up excessive counts of Virtual Log Files (VLF) in a transaction log that can lead to performance problems, including write performance, restore and recovery times. The ideal value for this metric should be less than 25; excessively high values (greater than 50) can cause high write times when writing to the transaction log.  Read more...

When a table has multiple indexes defined on the same columns, it produces duplicate indexes that waste space and have a negative impact on performance. This metric measures the number of possible duplicate indexes per database above a set threshold. You can then consider dropping the indexes and reverse the change.  Read more...