SQL Server, de la zero Lecția 37 / 40

First Responder Kit: cadoul lui Brent Ozar pentru omenire

Ce este kit-ul, de ce e licențiat MIT și gratuit pentru totdeauna, cum se instalează pe fiecare SQL Server pe care îl ai și cum arată uneltele dinăuntru.

Acum optsprezece ani, un consultant pe nume Brent Ozar a început să scrie proceduri stocate care rezumau tot ce nu e în regulă cu un SQL Server într-un singur set de rezultate. sp_Blitz a fost prima. Verifică backup-urile, securitatea, configurația, designul indecșilor, dispunerea pe disc și o sută de alte lucruri și afișează o listă prioritizată de constatări cu linkuri către articole care le explică pe fiecare.

Apoi a scris sp_BlitzIndex, care îți auditează indecșii. Apoi sp_BlitzCache pentru performanța interogărilor. Apoi sp_BlitzFirst pentru „ce se întâmplă chiar acum”. De-a lungul anilor, colecția a crescut. Compania lui Brent a făcut totul open source ca First Responder Kit (FRK), sub licență MIT.

E cel mai util set de scripturi pe care îl poți instala pe un SQL Server. Fiecare DBA competent îl are deployat pe fiecare instanță de producție pe care o atinge. Lecția de azi e introducerea; lecțiile 38–40 intră adânc în unelte specifice.

Ce e în kit

Procedurile stocate principale:

  • sp_Blitz — scanare full-body a serverului. Configurație, backup-uri, securitate, probleme majore.
  • sp_BlitzFirst — „ce se întâmplă chiar acum?” Wait stats live, top interogări, sesiuni active.
  • sp_BlitzIndex — audit de indecși. Indecși nefolosiți, indecși lipsă, tabele heap, fragmentare.
  • sp_BlitzCache — analizează plan cache-ul. Interogări proaste, indecși lipsă, conversii implicite.
  • sp_BlitzLock — citește Extended Events implicite ca să rezume deadlock-uri.
  • sp_BlitzBackups — istoricul backup-urilor și estimări RPO/RTO.
  • sp_BlitzWho — sesiuni live, mai curate decât interogarea DMV din lecția 36.
  • sp_BlitzQueryStore — diagnostice bazate pe Query Store.

Plus câteva proceduri ajutătoare. Toate stau într-o singură bază de date (adesea master, uneori DBA sau un nume personalizat).

Instalare

Din repo-ul GitHub — github.com/BrentOzarULTD/SQL-Server-First-Responder-Kit — descarcă sau clonează. Rulează Install-All-Scripts.sql pe baza în care vrei să-l instalezi.

-- Creează o bază DBA în care să țină uneltele
CREATE DATABASE DBA;
USE DBA;
GO

-- Rulează Install-All-Scripts.sql din kit

Ordinea instalării: o vizualizare ajutătoare numită FirstResponderKitVersion, apoi toate procedurile stocate, apoi câteva tabele pentru logare.

Fiecare procedură e autonomă — poți rula sp_Blitz fără sp_BlitzIndex. Instalarea tuturor nu costă nimic și te ține pregătit pentru viitor.

Actualizează trimestrial. Echipa lui Brent actualizează kit-ul lunar cam, cu verificări noi și fix-uri. Install-All-Scripts.sql gestionează update-urile curat — doar îl rulezi din nou.

Licență și utilizare

Licență MIT. Îl poți folosi pe servere comerciale, modifica, livra încorporat în propriile unelte, rula pe 10.000 de servere. E gratuit. Nimeni nu-ți cere să plătești. Compania lui Brent face bani din consultanță și training; scripturile sunt o investiție de bunăvoință.

Dacă beneficiezi de pe urma kit-ului (vei beneficia), ia în considerare să donezi la Vintage Computing Federation, pe care o sprijină fundația soției lui Brent. E o cerere mică pentru unelte care mi-au salvat sute de ore.

Rularea sp_Blitz: scanarea full-body

EXEC sp_Blitz;

Atât. Setul de rezultate are coloanele:

  • Priority — 1 e „clădirea arde”, 200 e „avertisment minor”. Sortează crescător.
  • FindingsGroup — categorie (Backup, Performance, Security, Reliability etc.).
  • Finding — problema specifică.
  • DatabaseName — dacă se aplică.
  • Details — specificul.
  • URL — link la blogul lui Brent care explică constatarea, de ce contează și cum să o rezolvi.

O instalare proaspătă de SQL Server poate produce 20 de constatări. O instanță de producție neglijată de 10 ani poate produce 200. Ideea e să știi care.

Constatări tipice de „prioritate 1”:

  • Niciun backup recent.
  • Coruperi detectate.
  • Bază de date în stare suspect.

Constatări tipice de „prioritate 10”:

  • Cont SA activat cu o parolă ușor de ghicit.
  • Niciun DBCC CHECKDB rulat în 30 de zile.
  • Instanța rulează doar cu default trace, fără Extended Events.

Constatări tipice de „prioritate 50”:

  • Auto-close activat pe o bază de date (încetinește accesul).
  • Multe opțiuni de configurare non-standard.
  • Statisticile n-au fost actualizate de o lună.

Treci prin constatări una câte una. Nu toate au nevoie să fie rezolvate imediat — unele sunt alegeri intenționate de design — dar ar trebui să știi ce e acolo.

Coloana URL e magia

Fiecare constatare se leagă de un articol pe blogul lui Brent Ozar care explică:

  • Ce înseamnă constatarea.
  • De ce e o problemă (cu exemple reale).
  • Cum se rezolvă.
  • Când e în regulă să o ignori.

Nu trebuie să memorezi fiecare anti-tipar SQL Server. Trebuie să recunoști constatarea în output-ul lui sp_Blitz și să dai click pe URL.

În timp îți dezvolți memoria musculară: „am mai văzut asta de zeci de ori, știu ce să fac”. Până atunci: citește URL-ul, repară sau documentează, mergi mai departe.

Personalizarea verificărilor

Unele constatări vrei să le suprimi pentru că sunt intenționate în mediul tău. sp_Blitz are un tabel de skip:

-- Creează tabelul de skip (prima dată)
EXEC sp_Blitz @CheckServerInfo = 1, @OutputType = 'NONE';

-- Sare peste o verificare specifică după CheckID
INSERT INTO dbo.BlitzChecksToSkip (CheckID, ServerName, DatabaseName, Comment)
VALUES (24, @@SERVERNAME, 'ReportingDB', 'Intenționat; parte din designul DW.');

-- Acum sp_Blitz nu va mai semnala CheckID 24 pe acel server + bază de date
EXEC sp_Blitz;

CheckID-urile sunt documentate în sursă. Construiește-ți o listă de skip în timp, care să se potrivească cu convențiile firmei tale.

Logarea rezultatelor pentru tendințe

-- Trimite output-ul către un tabel de logare
EXEC sp_Blitz @OutputDatabaseName = 'DBA', @OutputSchemaName = 'dbo', @OutputTableName = 'BlitzResults';

Programează asta în Agent, săptămânal. Atunci ai un istoric al fiecărei constatări. Apar constatări noi; cele vechi, sperăm, dispar. Reprezintă graficul numărului în timp; tendința de igienă a producției într-un singur grafic.

Ce se întâmplă pe Azure SQL DB

Azure SQL Database are niște restricții. Unele verificări nu se aplică (config tempdb, Agent jobs), unele sunt înlocuite cu echivalente specifice Azure. Kit-ul detectează automat și rulează ce are sens. Tot primești un raport util, doar mai scurt.

Rulează asta pe propria mașină

-- 1. Creează o bază DBA dacă n-ai una
CREATE DATABASE DBA;
USE DBA;

-- 2. Mergi la github.com/BrentOzarULTD/SQL-Server-First-Responder-Kit
--    Descarcă Install-All-Scripts.sql
--    Deschide-l în SSMS, asigură-te că ești pe baza DBA
--    Rulează-l.

-- 3. Scanare full-body
EXEC sp_Blitz;

-- 4. Vezi sumarul
EXEC sp_Blitz @CheckServerInfo = 1;

-- 5. Uită-te la o constatare specifică în detaliu, după CheckID
SELECT * FROM dbo.BlitzResults   -- dacă ai logat output-ul
WHERE CheckID = 68               -- „Security - SA account name"
ORDER BY CheckDate DESC;

Citește fiecare URL pentru constatările de pe propriul tău server cel puțin o dată. Întreabă-l pe Claude despre orice nu înțelegi. Țelul e „am mai văzut constatarea asta, știu ce înseamnă, știu dacă să o rezolv”.

Lecția următoare: sp_BlitzIndex și sp_BlitzCache — scanarea full-body pentru indecșii tăi și pentru planurile de query, în acea ordine.

Caută