Narcis Miclaus

5 min di lettura

SQL Server, dalle fondamenta Lezione 37 / 40

Il First Responder Kit: il regalo di Brent Ozar all'umanità

Cos'è il kit, perché è MIT-licensed e gratuito per sempre, come installarlo su ogni SQL Server che possiedi e la forma degli strumenti al suo interno.

Diciotto anni fa, un consulente di nome Brent Ozar ha cominciato a scrivere stored procedure che riassumevano tutto ciò che non andava in un SQL Server in un unico result set. sp_Blitz è stata la prima. Controlla backup, sicurezza, configurazione, design degli indici, layout del disco e centinaia di altre cose, e stampa una lista prioritizzata di findings con link a post di blog che spiegano ognuno.

Poi ha scritto sp_BlitzIndex, che fa l’audit degli indici. Poi sp_BlitzCache per la performance delle query. Poi sp_BlitzFirst per “cosa sta succedendo proprio adesso.” Negli anni la collezione è cresciuta. L’azienda di Brent ha rilasciato tutto in open source come First Responder Kit (FRK), con licenza MIT.

È il singolo set di script più utile che puoi installare su un SQL Server. Ogni DBA competente ce li ha deployati su ogni istanza di produzione che tocca. La lezione di oggi è l’introduzione; le lezioni 38-40 vanno a fondo su strumenti specifici.

Cosa c’è nel kit

Le stored procedure principali:

  • sp_Blitz — scansione completa del server. Configurazione, backup, sicurezza, problemi maggiori.
  • sp_BlitzFirst — “cosa sta succedendo proprio adesso?” Wait stat in tempo reale, top query, sessioni attive.
  • sp_BlitzIndex — audit degli indici. Indici inutilizzati, indici mancanti, tabelle heap, frammentazione.
  • sp_BlitzCache — analizza la plan cache. Query cattive, indici mancanti, conversioni implicite.
  • sp_BlitzLock — legge gli Extended Events di default per riassumere i deadlock.
  • sp_BlitzBackups — storico dei backup e stime di RPO/RTO.
  • sp_BlitzWho — sessioni live, più pulito della query DMV della lezione 36.
  • sp_BlitzQueryStore — diagnostica basata su Query Store.

Più alcune procedure di supporto. Tutto vive in un unico database (spesso master, a volte DBA o un nome custom).

Installazione

Dalla repo GitHub — github.com/BrentOzarULTD/SQL-Server-First-Responder-Kit — scarica o clona. Esegui Install-All-Scripts.sql contro il database in cui vuoi installarli.

-- Crea un database DBA per ospitare gli strumenti
CREATE DATABASE DBA;
USE DBA;
GO

-- Esegui Install-All-Scripts.sql dal kit

Ordine di installazione: una view di supporto chiamata FirstResponderKitVersion, poi tutte le stored procedure, poi alcune tabelle per il logging.

Ogni procedura è autonoma — puoi eseguire sp_Blitz senza sp_BlitzIndex. Installarle tutte non costa nulla e ti tiene a prova di futuro.

Aggiorna trimestralmente. Il team di Brent aggiorna il kit ogni mese o giù di lì con nuovi controlli e bugfix. Install-All-Scripts.sql gestisce gli aggiornamenti puliti — ti basta rieseguirlo.

Licenza e uso

Licenza MIT. Puoi usarlo su server commerciali, modificarlo, distribuirlo embedded nei tuoi tool, eseguirlo su 10.000 server. È gratis. Nessuno ti chiede di pagare. L’azienda di Brent fa soldi tramite consulenza e formazione; gli script sono un investimento di buona volontà.

Se trai beneficio dal kit (lo trarrai), considera una donazione alla Vintage Computing Federation, che la fondazione della moglie di Brent supporta. È una piccola richiesta per strumenti che mi hanno fatto risparmiare centinaia di ore.

Eseguire sp_Blitz: la scansione completa

EXEC sp_Blitz;

Tutto qua. Il result set ha le colonne:

  • Priority — 1 è “l’edificio sta bruciando”, 200 è “minor warning”. Ordina ascendente.
  • FindingsGroup — categoria (Backup, Performance, Security, Reliability, eccetera).
  • Finding — il problema specifico.
  • DatabaseName — se applicabile.
  • Details — i dettagli.
  • URL — link al blog di Brent che spiega il finding, perché conta e come risolverlo.

Un’installazione fresca di SQL Server potrebbe produrre 20 finding. Un’istanza di produzione di 10 anni trascurata potrebbe produrne 200. Il punto è sapere quali.

Tipici finding di “priority 1”:

  • Nessun backup recente.
  • Corruption rilevata.
  • Database in stato suspect.

Tipici finding di “priority 10”:

  • Account SA abilitato con password facile da indovinare.
  • Nessun DBCC CHECKDB negli ultimi 30 giorni.
  • Istanza che gira con la sola default trace, niente Extended Events.

Tipici finding di “priority 50”:

  • Auto-close abilitato su un database (rallenta gli accessi).
  • Tante opzioni di configurazione non standard.
  • Le statistiche non sono state aggiornate da un mese.

Esamina i finding uno per uno. Non tutti vanno risolti subito — alcuni sono scelte di design intenzionali — ma dovresti sapere cosa c’è.

La colonna URL è la magia

Ogni finding ha un link a un post del blog di Brent Ozar che spiega:

  • Cosa significa il finding.
  • Perché è un problema (con esempi reali).
  • Come risolverlo.
  • Quando va bene ignorarlo.

Non hai bisogno di memorizzare ogni anti-pattern di SQL Server. Hai bisogno di riconoscere il finding nell’output di sp_Blitz e cliccare l’URL.

Col tempo sviluppi memoria muscolare: “L’ho già visto una decina di volte, so cosa fare.” Fino ad allora: leggi l’URL, sistema o documenta, prossimo.

Personalizzare i controlli

Alcuni finding li vuoi sopprimere perché sono intenzionali nel tuo ambiente. sp_Blitz ha una tabella di skip:

-- Crea la tabella di skip (la prima volta)
EXEC sp_Blitz @CheckServerInfo = 1, @OutputType = 'NONE';

-- Salta un controllo specifico tramite il suo CheckID
INSERT INTO dbo.BlitzChecksToSkip (CheckID, ServerName, DatabaseName, Comment)
VALUES (24, @@SERVERNAME, 'ReportingDB', 'Intenzionale; parte del design del DW.');

-- Adesso sp_Blitz non segnalerà CheckID 24 su quel server + database
EXEC sp_Blitz;

I CheckID sono documentati nei sorgenti. Costruisci una skip list nel tempo che corrisponda alle convenzioni della tua azienda.

Loggare i risultati per i trend

-- Manda l'output a una tabella di log
EXEC sp_Blitz @OutputDatabaseName = 'DBA', @OutputSchemaName = 'dbo', @OutputTableName = 'BlitzResults';

Schedalo nell’Agent, settimanalmente. Poi hai uno storico di ogni finding. Nuovi finding compaiono; quelli vecchi sperabilmente spariscono. Grafica il count nel tempo; trend di igiene di produzione in un grafico.

Cosa succede su Azure SQL DB

Azure SQL Database ha alcune restrizioni. Alcuni controlli non si applicano (configurazione di tempdb, job dell’Agent), alcuni sono sostituiti da equivalenti specifici di Azure. Il kit autorileva ed esegue ciò che ha senso. Ottieni comunque un report utile, solo più corto.

Prova questo sulla tua macchina

-- 1. Crea un database DBA se non ne hai uno
CREATE DATABASE DBA;
USE DBA;

-- 2. Vai su github.com/BrentOzarULTD/SQL-Server-First-Responder-Kit
--    Scarica Install-All-Scripts.sql
--    Aprilo in SSMS, assicurati di essere nel database DBA
--    Eseguilo.

-- 3. Scansione completa
EXEC sp_Blitz;

-- 4. Vedi il summary
EXEC sp_Blitz @CheckServerInfo = 1;

-- 5. Guarda nel dettaglio uno specifico finding tramite CheckID
SELECT * FROM dbo.BlitzResults   -- se hai loggato l'output
WHERE CheckID = 68               -- "Security - SA account name"
ORDER BY CheckDate DESC;

Leggi ogni URL per i finding sul tuo server almeno una volta. Chiedi a Claude qualsiasi cosa non capisci. L’obiettivo è “ho visto questo finding, so cosa significa, so se sistemarlo o no.”

Prossima lezione: sp_BlitzIndex e sp_BlitzCache — la scansione completa per i tuoi indici e per i tuoi piani di query, in quest’ordine.

Cerca