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