I'm running into an issue while trying to execute the stored procedure **sp_BlitzLock** in SQL Server 2022 Developer Edition. Here's the exact error message I'm getting: Msg 2812, Level 16, State 62, Line 1 Could not find stored procedure 'sp_BlitzLock'. Completion time: 2025-07-21T22:17:36.5575216+02:00 Any help would be greatly appreciated!

I have a SQL Managed Instance in Azure with some blocking/deadlocking going on. This DB was on-premise and had all the scripts installed, so I uninstalled them and then installed the Azure specific scripts (Install-Azure.sql), downloaded fresh from Brent Ozar's website. All the scripts seem to work ok, except sp_blitzlock. SpBlitz indeed confirms "94 average deadlocks per day. To find them, run sp_BlitzLock." I am running it as a system administrator, and both main tables are blank. (when I ran it as my EntraID account, I got a permissions issue: Msg 50000, Level 11, State 1, Procedure sp_blitzlock, Line 335 [Batch Start Line 0] A session with the name system_health does not exist or is not currently active. I do not get any error when running it as an instance sysadmin. The data is just blank. It's possible there's no data, but I doubt it given what we've observed elsewhere and what sp_blitz confirmed. I downloaded the latest First Responder Kit, and am using sp_BlitzLock version 8.21 and sp_Blitz version Jul 1 2024 12:00AM. This is a SQL Managed Instance in Azure, instance version is 12.0.2000.8. I am just executing sp_blitzlock; in SSMS to run it. It may be worth pointing out we recently upgraded the service tier from General Purpose to Business Critical. That overall improved performance and locking, but I'm wondering if it triggered a new instance behind the scene which is why no deadlocking data appears. (Although why would it show up in sp_blitz?) Any thoughts?

I have a bunch of SQL Servers registered within my SSMS, lots of different SQL versions, editions and DB compatibilities. I want to check out if **any** of those servers have **any** of the [sp_Blitz](https://github.com/BrentOzarULTD/SQL-Server-First-Responder-Kit) or [sp_WhoIsActive](http://whoisactive.com) stored procedures installed, and which versions they are. I know I can **right-click** on my **Registered Servers group** and open **one** query window that connects to **all** the servers in the group, but is there a reliable way to check which SProcs and versions I have?

When running sp_blitzwho, short of modifying the proc itself, is there a simpler way to filter out system-related queries such as broker, traces, etc? This is on Azure Sql Managed Instance, and we are using SignalR, which seems to be showing up in our blitz output. I know I can create a separate proc to put the output to a new table, then query the table without the WAITFOR statements, but I scoured the parameters and couldn't find anything that would remove it.

You can run sp_blitz (First Responder Kit by Brent Ozar) on a sql server to output to a table. But it will store the output only on that server. I am using Dbatools.io PowerShell commands currently. I can run the sp_Blitz commands agains all SQL servers. But I don’t know how to capture the output on my report server in a single database table centrally. Is there a way to store output of sp_blitz command against a list of all servers so that I can create a report for all critical issues across all my servers? Here is the code I am using. ```# Import the dbatools module if you haven't already Import-Module dbatools # Set your database connection details $database = "" $table = "" $output = "dbo.BlitzResults" $sqlInstance = "" # The instance where the ServerList table is located $servers = Invoke-DbaQuery -SqlInstance $sqlInstance -Database $database -Query "select * from $table;" $servers # Loop through each server and execute sp_Blitz foreach ($server in $servers.ItemArray) { Write-Host "Running sp_Blitz on $($server)" try { $result = Invoke-DbaQuery -SqlInstance $server -Database master -Query "EXEC dbo.sp_Blitz" # Output the results $result | Format-Table -AutoSize #Following two lines are not working as expected #Write-Host $result.ItemArray #Write-DbaDbTableData -SqlInstance $sqlInstance -DestinationDatabase $database -DestinationTable $output -Data $result.ItemArray -CreateTable $true } catch { Write-Host "Failed to run sp_Blitz on $($server.ServerName). Error: $_" } }

I was wondering why sp_blitz is recommending to back up TDE certificates that has not been backed up the last 30 days? If the certificate hasn't been changed, and it has been backed up after creation, is there a need to do more backups? Should I do regular backups of the TDE certificates even if they have not changed since last backup?

Has anyone had an issue with running **sp_blitz** on an instance using the Latin1_BIN collation? I created the stored procedure without error, but when I ran it I got the following error message:

Msg 468, Level 16, State 9, Procedure dbo.sp_Blitz, Line 905 [Batch Start Line 9]
Cannot resolve the collation conflict between "SQL_Latin1_General_CP1_CI_AS" and
   "Latin1_General_BIN" in the equal to operation.

I then created a separate database with the Latin1_General_CPI_CI_AS collation, create the **sp_blitz** procedure, and this threw out more errors when executed. Probably due to the joins to the system object. Is there an easy way to fix this or an updated script, without me having to troubleshoot and rewrite every line of code? **sp_blitz info** @Version = '8.03', @VersionDate = '20210420' **collation query results**

InstanceCollation     SystemDbCollation     TempDbCollation
Latin1_General_BIN    Latin1_General_BIN    SQL_Latin1_General_CP1_CI_AS

I recently updated my Brent Ozar first responder kit and ran sp_Blitz and it returned an alert: > The [SSISDB] database has 107 objects that were created with dangerous > ANSI_NULL or QUOTED_IDENTIFIER options. These objects can break when > using filtered indexes, indexed views and other advanced SQL features. These appear to be objects in the 'catalog' and 'internal' schemas that I believe are built during the install and not something one of our developer have created. Do I need to be concerned and take any action on these?

I am a DBA on many servers running SQL Server and am a big user of sp_Blitz. The issue I have is that I am still to maintain a database that is migrating to a VM on AWS. The issue is that I'm not permitted DBA access. I can only now connect with user credentials. But I still have desire to monitor as much as possible. Even simple stuff like check the backups have been run. So I can now only run minimal queries. Obviously I can't install sp_Blitz as it creates stored procedures. But I do have full DBO to the database before it migrates over. Yes I can install sp_Blitz in that database, as it would be dbo.sp_Blitz. But I won't have the permission to then run it as a user. Any suggestions or pointers on how I can get it (or open to alternatives) into the database in a way that I can execute when I'm just a user?

I've run sp_blitz (version 45) on our test database server. It complains about > Database [MDS] has TORN_PAGE_DETECTION for page verification. SQL Server may have a harder time recognizing and recovering from storage corruption. Consider using CHECKSUM instead. But this is a database from Microsoft.
Is it wise to change the Page Verification to CheckSum? Or should we wait for Microsoft to release a new version of MDS?

I want to run sp_Blitz and other scripts (from first aid) on a busy primary production server. There are 75 databases on the server, of which 40 are in an availability group (synchronous, no read scale). I am reading the readme file which says @BringThePain = 1 - required if you want to run @CheckUserDatabaseObjects = 1 with over 50 databases. It's gonna be slow. The term pain is scary and so I want to ask whether the pain is in terms of the time that I have to wait to get the response from the stored proc or does pain mean that its going to cause blocking/slow production workload on the sql server?

Running sp_blitzwho @GetLiveQueryPlan = 1 on SQL2019 to monitor a big index rebuild operation but running into the following error: > Lock request time out period exceeded. Anything I can do to avoid this error?

We are experiencing intermittent SQL Server issues, where from time to time, it would become unresponsive for a few minutes, causing an outage of a system, driving crazy many users. I started using sp_Blitz and related tools to find hints. But I got the following results, which looked very bad, **"slow data reads"**, and alarming **wait stats** of all sorts (160 seconds waiting ?!?!) * Could it be a hard drive issue ? * Based on the image, what should be my top 3 priorities ? * Could you give me hints that could help relieving the pain while I look into it more ? I've been here which seem related: https://dba.stackexchange.com/questions/175590/sp-blitzfirst-wait-stats-interpretation / https://dba.stackexchange.com/questions/188499/sp-blitzfirst-file-stats-interpretation - Just now I changed MAXDOP from 0 to 8 (we have 20 cores cpus) - Next: Will tap the Cost Thresh for Paralellism *BLITZ version date is 4/8/2022* Thanks so much 🙏

Why Multiple Plans for One Query Are Bad So I was running sp_Blitz to get a handle on some systems. Got some code to get cleaned up as usual. Some heaps that should have been clustered indexes. etc. This particular query was using literals, seemed to be resulting in a lot of plans. Got the indexing and stuff sorted out on the tables in this query, and even got the query parameterized for the latest code/database to go into production. But still the query is showing as a parameterization issue. (DBA helpfully turned the plan cache query into an SSRS report so I can just run through them quickly on the PROD environment from my browser). Where to go from here? Ignore it? (Seems like a lot of plan counts) Use forced parameterization? (But the one that is explicitly parameterized is showing up). Ugh - I see the developer didn't take my advice that the LEFT JOIN was being turned into an INNER JOIN... I'll have to get that fixed... Without forced parameterization, will all these literal-style queries never share the same plan? Is this query too complicated for simple parameterization ?

My team came across a In-Memory OLTP (Hekaton) transaction issue with several of our machines showing that there were a varying number of write conflicts per machine. We do have Memory-Optimized TempDB Metadata turned on. > Since restart: 0 validation failures, 0 dependency failures, 63 write conflicts, 0 unique constraint violations. and also the Performance message > In-Memory OLTP (Hekaton) In Use, 0% of your 2097152.00GB of your max > server memory is being used for in-memory OLTP tables (Hekaton). Should we be worried about those messages? It looks like the errors are being reported by the sys.dm_xtp_transaction_stats view, and the Microsoft definition of the "write_conflicts" is "Internal use only".

I am using Brent Ozar's sp_BlitzCache store procedure and I'm attempting to nail down why it is reporting: > "Something in your plan is forcing a serial query. Further > investigation is needed if this is not by design." Upon investigation I found that the server configuration has set: 'Max Degree of Parallelism = 1' (That is on my laundry list to configure correctly. It is a hold over from days of ignorance.) Is that setting the cause of Brent to report forced serialization?

I was playing around with sp_BlitzWho and got blocked by another session. The session was from the DB were sp_BlitzWho is... I was planning to automate it and save the results to a table, so I could analyze the accumulated wait stats for different sessions (I have heard it does that in contrast to sp_WhoIsActive), but now it seems not to be such a good idea... Maybe it is better to just use sys.dm_exec_session_wait_stats or sp_WhoIsActive...?

I'm trying to learn more about how SQL Server works with NUMA nodes as I noticed something in the output of sp_Blitz that I didn't understand:

Node: 0 State: ONLINE Online schedulers: 8 Offline schedulers: 0 Processor Group: 0 Memory node: 0 Memory VAS Reserved GB: 1343

Node: 1 State: ONLINE Online schedulers: 8 Offline schedulers: 0 Processor Group: 0 Memory node: 0 Memory VAS Reserved GB: 1343

Node: 2 State: ONLINE Online schedulers: 8 Offline schedulers: 0 Processor Group: 0 Memory node: 1 Memory VAS Reserved GB: 0

Node: 3 State: ONLINE Online schedulers: 8 Offline schedulers: 0 Processor Group: 0 Memory node: 1 Memory VAS Reserved GB: 0

The server has 32 logical processors so the numbers above make sense. We're running SQL Server 2016 SP2 Enterprise Edition I have a conceptual understanding of NUMA from online reading and need to do much more research, however in the short term, I'd like to understand the meaning/importance of VAS Reserved, why it differs between the nodes above, and whether the difference is anything to be concerned about. This is the query (taken from sp_Blitz):

SELECT  'Node: ' + CAST(n.node_id AS NVARCHAR(10)) + ' State: ' + node_state_desc
        + ' Online schedulers: ' + CAST(n.online_scheduler_count AS NVARCHAR(10)) + ' Offline schedulers: ' + CAST(oac.offline_schedulers AS VARCHAR(100)) + ' Processor Group: ' + CAST(n.processor_group AS NVARCHAR(10))
        + ' Memory node: ' + CAST(n.memory_node_id AS NVARCHAR(10)) + ' Memory VAS Reserved GB: ' + CAST(CAST((m.virtual_address_space_reserved_kb / 1024.0 / 1024) AS INT) AS NVARCHAR(100))
FROM sys.dm_os_nodes n
INNER JOIN sys.dm_os_memory_nodes m ON n.memory_node_id = m.memory_node_id
OUTER APPLY (SELECT
COUNT(*) AS [offline_schedulers]
FROM sys.dm_os_schedulers dos
WHERE n.node_id = dos.parent_node_id
AND dos.status = 'VISIBLE OFFLINE'
) oac

WHERE n.node_state_desc NOT LIKE '%DAC%'
ORDER BY n.node_id OPTION (RECOMPILE);

Thanks.

sp_blitz script not working on Azure sql database >Msg 40515, Level 15, State 1, Procedure sp_Blitz, Line 16 [Batch Start Line 3] Reference to database and/or server name in 'master.sys.all_objects' is not supported in this version of SQL Server.

Non-uncommon scenario: Something has ran wild and caused the TLog for a patifular Db to fill and everything has stopped. How can sp_blitz show us some info on what led up to this point? What about sp_whoisactive?