sp_blitzFirst

-

I figured I’d write some notes after watching Brent’s How I Use the First Responder Kit: sp BlitzFirst

This query from Brent’s SQL-Server-First-Responder-Kit essentially gives you a view of what is happening on the database over a 5 second period.

EXEC sp_blitzFirst @ExpertModel = 1

There are several sets of data returned. The first set shows which queries are running right now, at the start of the 5 second snapshot, and also includes their execution plans! You can open these just by clicking the plan link, and if you have the free SentryOne Plan Explorer installed, you can open the plan straight from SSMS.

The second set of data shows a prioritised list of potential issues with your database, for mine it showed pretty high CPU usage. For Brent’s, it showed a database backup was in progress.

The third shows WAIT STATS; like how long SQL Server had to wait for any given reason. My top entry was SOS_SCHEDULER_YIELD, which is in the CPU category and it waited for 70 seconds. We should probably look into this!

The fifth set shows which files were interacted with during the snapshot, and how much data was written or read. I’m starting to wonder how I’ve gone so long without having used these sprocs!

The sixth set is a dump of the available perf-mon counters. For example, our SQL Compilations/sec counter was showing around 20 recompilations per second. That doesn’t sound great.

The last set is a re-run of the first, and again shows us what is running at the end of the 5 second snapshot. This allows us to review which queries were running across the full duration of the sp_blitzFirst snapshots.

Brent also recommends trying out the SinceStartup parameter:

EXEC sp_blitzFirst @SinceStartup = 1

This gives a view of what SQL Server has been up to since it first started up, rather than just over 5 seconds.

This script seems fairly powerful at giving an overview of the health of your database server, and helps you see why it might be running slowly. For us it most certainly is CPU constrained.

Popular posts from this blog

Taking a memory dump of a w3wp process

-
Taking a memory dump of a w3wp process Taking a memory dump of an IIS worker process in a live system can be problematic, as IIS will kill the process if it has been suspended for more than 60 seconds. Only use these steps if your application is on a high availability cluster, else you’ll take your app down! copy sysinternals procdump.exe and pssuspend.exe to target machine create powershell file with: $iispid = Get-Process svchost | ? { $_ . modules . ModuleName -eq "iisw3adm.dll" } | Select - First 1 - ExpandProperty Id $workerpid = Get-Process w3wp | Sort ws - Descending | Select - First 1 - ExpandProperty Id & ".\pssuspend.exe" $iispid Write-Output "Creating memory dump for w3wp PID $workerpid " & ".\procdump.exe" - ma $workerpid & ".\pssuspend.exe" $iispid - r (taken from stackoverflow ) 3) check the w3wp process has reached the high level of RAM usage that you’re intending to
Read more

GitLab Badges

-
Image
GitLab has built in functionality to allow you to add badges, to provide an at-a-glance status of your app's quality.  In order to set project badges up, you need to be a maintainer of the project so that you can access the settings. Pipeline Status This shows whether your master branch pipeline has passed or failed.  The badge is super easy to set up.  In GitLab go to Settings > General > Badges > Add Badge, and enter this: Name:  Pipeline Link:  https://gitlab.com/%{project_path}/commits/%{default_branch} Badge: https://gitlab.com/%{project_path}/badges/%{default_branch}/pipeline.svg These links should be right for any project, as they're using variables. Coverage % Code coverage is a little more involved, as it relies on you having already configured code coverage in your app.  For the app I've been working on, which is a dotnet application, I opted to use the opensource MiniCover .  This is configured to writes a code coverage report to the
Read more

sp_blitzIndex

-
Some more notes after watching Brent’s How I Use the First Responder Kit: sp BlitzIndex . This sproc will analyse every index across all databases in your sql server and return a prioritised list of potential issues. EXEC sp_blitzIndex @GetAllDatabases = 1 The MoreInfo column is interesting. If you copy the SQL out and run it, it will give you more information on the indexing issue in question. E.g: EXEC dbo . sp_BlitzIndex @DatabaseName = 'YourDatabase' , @SchemaName = 'dbo' , @TableName = 'tFoo' ; If you run this, the top result set it a list of indexes that are on the target table. It shows how many seeks and scans each index has had, the size of the index, etc. Note the URL column for more information on each issue category. Missing indexes are shown in the 2nd result set. The 3rd result set shows the table definition, which is nice to have without having to mess with the SSMS UI.
Read more