Planuri de mentenanță vs Ola Hallengren

SQL Server vine cu un Maintenance Plan Wizard. E o interfață grafică, e încorporat, e tentant. E și considerat în mod larg dăunător.

Lecția asta e despre de ce comunitatea recomandă universal scripturile de mentenanță ale lui Ola Hallengren în schimb, ce fac scripturile, cum se instalează și programul implicit sensibil pe care îl poți copia-lipi.

Ola și-a oferit munca gratuit timp de 17 ani și aproape fiecare SQL Server de producție pe care am lucrat vreodată a ajuns să ruleze scripturile lui. Asta e singura lecție în care îți spun să mergi la un site terț și să ai mai multă încredere în el decât în unealta încorporată de la Microsoft.

De ce planul încorporat e prost

Setările implicite ale wizard-ului de plan de mentenanță:

• Reconstruiește fiecare index, indiferent de fragmentare.
• Actualizează statisticile pe fiecare tabel, indiferent de rata de schimbare.
• Folosește setări implicite de eșantionare care sunt în regulă pentru tabele mici, greșite pentru cele mari.
• Sarcina Shrink Database (activată implicit în versiunile mai vechi) re-fragmentează totul.
• Fără logică selectivă; face fiecare sarcină pe fiecare bază de date la fel.

Rezultat net: un job lung, intensiv pe CPU, care face mult lucru inutil și ocazional face lucru dăunător. Pe un server de producție mediu, planul de mentenanță nocturn poate rula patru ore făcând lucruri care iau zece minute de efort țintit.

Poți tuna wizard-ul de mentenanță, dar butoanele de tunare sunt limitate, iar planul rezultat tot rămâne un blob XML greoi, greu de citit și de versionat.

Ce fac scripturile lui Ola

Trei scripturi principale:

1. DatabaseBackup — backup-uri inteligente. Se ocupă de FULL, DIFF, LOG. Suportă backup pe disc, share de rețea, Azure Blob, S3. Comprimat, cu checksum, verificat.
2. IndexOptimize — mentenanță inteligentă pentru indecși și statistici. Reconstruiește doar indecșii fragmentați, actualizează doar statisticile care au nevoie, cu praguri implicite sensibile.
3. DatabaseIntegrityCheck — rulează DBCC CHECKDB pe toate bazele de date.

Plus câteva proceduri suport (CommandExecute, CommandLog).

Toate trei sunt proceduri stocate. Le programezi prin Agent. Iau parametri, își loghează propriul istoric și se înțeleg bine cu orice îi arunci.

Instalare

# Descarcă MaintenanceSolution.sql de pe ola.hallengren.com
# Rulează-l pe master în SSMS

Rularea MaintenanceSolution.sql creează:

• Un tabel dbo.CommandLog pentru logare.
• Procedurile stocate dbo.CommandExecute, dbo.DatabaseBackup, dbo.IndexOptimize, dbo.DatabaseIntegrityCheck.
• Opțional (configurabil), joburi SQL Agent pentru fiecare.

Setează flag-ul @CreateJobs = 'Y' înainte de rulare și primești joburile direct. Reglează programele mai târziu.

Programul canonic

Iată ce rulează Runehold:

Zilnic

00:00  Backup full pe master
00:05  Backup full pe msdb
00:10  Backup full pe model
00:30  Backup full pe Runehold
02:00  IndexOptimize (doar Runehold, cu @UpdateStatistics = 'ALL')

La fiecare 30 de minute, 06:00–22:00

Backup de log de tranzacții pe Runehold

Săptămânal (duminica)

01:00  DatabaseIntegrityCheck pe toate bazele de date

Lunar

03:00 prima duminică: CHECKDB complet cu EXTENDED_LOGICAL_CHECKS (data purity).

Atât. Șase joburi Agent acoperă întreaga poveste de mentenanță.

Parametrii IndexOptimize, cei importanți

EXEC master.dbo.IndexOptimize
    @Databases         = 'USER_DATABASES',
    @FragmentationLow  = NULL,          -- sare peste fragmentarea joasă
    @FragmentationMedium = 'INDEX_REORGANIZE',
    @FragmentationHigh   = 'INDEX_REBUILD_ONLINE',
    @FragmentationLevel1 = 5,
    @FragmentationLevel2 = 30,
    @UpdateStatistics    = 'ALL',
    @OnlyModifiedStatistics = 'Y',
    @LogToTable          = 'Y';

• @FragmentationLow = NULL — sare peste orice sub 5%. Economisește o tonă de muncă.
• @FragmentationMedium = 'INDEX_REORGANIZE' — reorganizează între 5–30%.
• @FragmentationHigh = 'INDEX_REBUILD_ONLINE' — reconstruiește peste 30%, online (Enterprise) sau offline (Standard).
• @UpdateStatistics = 'ALL' — actualizează statistici pe indecși și coloane.
• @OnlyModifiedStatistics = 'Y' — sare peste statisticile unde nu s-au schimbat rânduri.
• @LogToTable = 'Y' — loghează rezultatele în dbo.CommandLog ca să poți interoga ce s-a întâmplat.

Pe Runehold asta rulează cam 35 de minute săptămânal. Planul de mentenanță încorporat lua patru ore pentru un rezultat mai prost.

Parametrii DatabaseBackup

EXEC master.dbo.DatabaseBackup
    @Databases         = 'USER_DATABASES',
    @Directory         = 'D:\Backups',
    @BackupType        = 'FULL',
    @Verify            = 'Y',
    @Compress          = 'Y',
    @CheckSum          = 'Y',
    @CleanupTime       = 336,             -- păstrează backup-urile 14 zile (14 * 24)
    @LogToTable        = 'Y';

Backup-urile de log apelează aceeași procedură cu @BackupType = 'LOG'. DIFF cu @BackupType = 'DIFF'.

Backup în Azure Blob:

EXEC master.dbo.DatabaseBackup
    @Databases  = 'USER_DATABASES',
    @URL        = 'https://runehold.blob.core.windows.net/backups',
    @Credential = 'AzureStorageCredential',
    @BackupType = 'FULL',
    @Compress   = 'Y',
    @CheckSum   = 'Y';

O linie de schimbat; în rest la fel.

DatabaseIntegrityCheck

EXEC master.dbo.DatabaseIntegrityCheck
    @Databases = 'ALL_DATABASES',
    @CheckCommands = 'CHECKDB',
    @LogToTable = 'Y';

DBCC CHECKDB e lent pe baze mari — pe baze de TB poate lua ore. Rulează-l săptămânal într-o fereastră de mentenanță. Spargerea în verificări la nivel de filegroup sau rularea pe o copie restaurată e o opțiune pentru sisteme foarte mari.

Loghează rezultatele într-un tabel

Pentru că scripturile lui Ola loghează în dbo.CommandLog, ai un audit trail complet:

SELECT TOP (100) *
FROM master.dbo.CommandLog
ORDER BY StartTime DESC;

Fiecare comandă, fiecare bază de date, fiecare durată, fiecare eroare. Perfect pentru post-mortem-uri și conformitate.

Pentru firmele cu cerințe grele de conformitate (și Runehold sub DORA, dacă se aplică): pune o alertă de monitorizare pe CommandLog.ErrorMessage IS NOT NULL ca orice eșec de mentenanță să fie observat imediat.

Alte unelte care merită știute

• First Responder Kit de la Brent Ozar (lecțiile 37–40) — diagnostic, nu mentenanță. Focus diferit.
• dbatools — un modul PowerShell care completează scripturile lui Ola. Util pentru lucruri pe care Ola nu le acoperă (configurare la nivel de instanță, copierea bazelor între servere etc.).
• SQL Server Managed Backup to Azure — automatizează backup-urile către Azure Blob fără scripturile lui Ola. Mai simplu, dar mai puțin flexibil.

Pentru o configurație de producție fără bătaie de cap: scripturile lui Ola + dbatools + interfața SSMS Query Store. Acel trio acoperă 95% din uneltele DBA.

Rulează asta pe propria mașină

-- 1. Descarcă MaintenanceSolution.sql de pe https://ola.hallengren.com
-- 2. Deschide-l în SSMS.
-- 3. Înainte de rulare, setează parametrul @CreateJobs la 'Y'.
-- 4. Execută pe baza master.
-- 5. Verifică dacă joburile au fost create:

SELECT name, enabled FROM msdb.dbo.sysjobs
WHERE name LIKE '%IndexOptimize%'
   OR name LIKE '%DatabaseBackup%'
   OR name LIKE '%DatabaseIntegrityCheck%';

-- 6. Încearcă rularea manuală a IndexOptimize (mai întâi pe o BD mică!)
EXEC master.dbo.IndexOptimize
    @Databases = 'Runehold',
    @FragmentationLow  = NULL,
    @FragmentationMedium = 'INDEX_REORGANIZE',
    @FragmentationHigh = 'INDEX_REBUILD_ONLINE',
    @LogToTable = 'Y';

-- 7. Verifică ce a făcut
SELECT TOP (20) * FROM master.dbo.CommandLog ORDER BY StartTime DESC;

După ce ai rulat-o o dată și ai verificat output-ul CommandLog, configurează joburile Agent să ruleze conform programului și uită în mare măsură de mentenanță. Asta e ținta. Plictisitor înseamnă bine.

Lecția următoare: DMV-uri pe care fiecare DBA ar trebui să le știe pe de rost. Interogările pe care le rulezi pe un server rece atunci când cineva îți dă root și zice „dă-ți seama ce nu merge”.