SQLServer

How to read large SQL Server ERRORLOG (the 5GB test)

Let’s take a look at different ways of reading the SQL Server ERRORLOG….I often come across large ERRORLOGS mainly because they are not being recycled frequent enough, or not at all. Sometimes, despite the frequent recycling, the ERRORLOG can grow to unmanageable size. This has recently happened to me during a large transaction rollback over Synchronous Availability Group. Within a few hours, the ERRORLOG log grew to 5GB in size due to “Sending page request for Undo” messages.

Database Development in Visual Studio

A lot of database administrators and developers like to use the SQL Server Management Studio to make changes to the database schema directly. As a production DBA, I can definitely say that there are situations where this is acceptable and even desired, however, in most cases a Visual Studio Database Project is a much better approach. I have made a switch from developing in SSMS to Visual Studio several years ago and never looked back.

SQL Agent Jobs Timeline with dbatools.io (download)

An important element of performance monitoring is knowing what SQL agent jobs run at what time to understand and avoid potential clashing. Notice the underlined what time – time correlation is very important when it comes to performance but finding it is not always easy. I wrote a simple PowerShell script to help visualise what jobs run and when

How to intelligently auto-cycle ERRORLOG using T-SQL

In my previous post, I described different ways to read very large SQL Server Log (ERRORLOG) – 5GB to be exact. However, this was a reaction to something that has already happened. In this post, I will show you how to prevent this from happening at all.

SQL Server Performance Dashboard using PowerBI (download)

I often help improve the performance of a SQL Server or an application. Performance metrics in SQL Server are exposed via Dynamic Management Views (DMVs). However, DMVs only provide a view of the current state and no history. This is important as it makes it particularly difficult to draw a bigger picture of how the system is behaving over time and what problems are occurring during overnight batch processing or during peak operational times, for example when users log in to the system at 8 am or when they leave for lunch at 1 pm. To address this deficiency I have built a simple yet comprehensive SQL Server Performance Dashboard in PowerBI.