Hey, thanks for stopping by

This is my blog where I used to write about SQL Server and PowerShell. I now mainly blog about SQL Server on the SQLWATCH (The free and open source SQL Server Monitoring framework) blog. If you previously subscribed for the SQL Server content, you may want to re-subscribe to the SQLWATCH blog. If you like however to read random things, check the posts below. Thanks!

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

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.