Controlli di integrità proattivi di SQL Server, parte 4:ERRORLOG

C'è così tanto da dire sulla storia e l'importanza. Storia di un Paese, di civiltà, di ognuno di noi. Adoro le citazioni e mi piace questa di Teddy Roosevelt (cool guy):

Perché sto diventando poetico (o sto provando a farlo) sulla storia in un blog su SQL Server? Perché anche la cronologia in SQL Server è importante. Quando si verifica un problema di prestazioni in SQL Server, è l'ideale per risolvere il problema in tempo reale, ma in alcuni casi le informazioni storiche possono fornire una pistola fumante o almeno un punto di partenza. Un'ottima fonte di informazioni storiche in SQL Server è ERRORLOG. Ho menzionato nel mio post originale, Performance Issues:The First Encounter, che l'ERRORLOG era un ripensamento per me. Non piu. Durante gli audit dei client acquisiamo sempre gli ERRORLOG e, sebbene veniamo informati di eventuali avvisi di gravità elevata (che vengono scritti nel registro), non è raro trovare altre informazioni interessanti nel registro. Ci prepariamo per il futuro utilizzando le informazioni storiche nei log; le informazioni possono aiutarci a risolvere un problema, o potenziale problema, prima che diventi catastrofico.

Visualizzazione dell'ERRORLOG

Prima di tutto, esamineremo alcune opzioni per visualizzare l'ERROLOG. Se sono connesso a un'istanza, di solito vi accedo tramite SSMS (Gestione | Registri di SQL Server, fare clic con il pulsante destro del mouse su un registro e selezionare Visualizza registro di SQL Server). Da questa finestra posso semplicemente scorrere il registro o utilizzare le opzioni Filtro o Cerca per restringere il set di risultati. Posso anche visualizzare più file selezionandoli nel riquadro a sinistra.

Se sto guardando i dati acquisiti in uno dei nostri controlli sanitari, apro semplicemente i file di registro in un editor di testo e li rivedo (ho anche la possibilità di entrare nel visualizzatore e caricarli). I file di registro esistono nella cartella di registro (percorso predefinito:C:\Programmi\Microsoft SQL Server\MSSQL12.SQL2014\MSSQL\Log) se mai volessi guardarli sul server. Molti di voi potrebbero preferire visualizzare e/o cercare nel registro utilizzando la procedura non documentata sp_readerrorlog o la stored procedure estesa xp_readerrorlog.

E infine, se ti piace PowerShell, questa è anche un'opzione per leggere il registro in questo modo (vedi questo post:Usa PowerShell per analizzare i log degli errori di SQL Server 2012). Il metodo dipende da te:usa ciò che sai e ciò che funziona per te:è il contenuto che conta davvero. E ricorda che ci sono momenti in cui dovrai semplicemente leggere il registro per comprendere l'ordine degli eventi, e ci sono altre volte in cui potresti cercare un errore o un'informazione specifici.

Cosa c'è nell'ERRORLOG?

Quindi quali informazioni possiamo trovare nell'ERRORLOG, oltre agli errori? Di seguito ho elencato molti degli elementi che ho trovato più utili. Nota che questo non è un elenco esaustivo (e sono sicuro che molti di voi avranno suggerimenti su cosa potrebbe essere aggiunto – sentitevi liberi di pubblicare un commento e posso aggiornarlo!), ma ancora una volta, questo è quello che sono cercando prima quando sto esaminando un'istanza in modo proattivo.

• Se il server è fisico o virtuale (cerca la voce Produttore del sistema)
• Flag di traccia abilitati all'avvio
  • All'interno della voce relativa ai parametri di avvio del Registro di sistema, se scorri fino in fondo a destra, vedrai se sono abilitati flag di traccia:
    
    Traccia flag abilitati all'avvio
• Flag di traccia abilitati o disabilitati dopo l'avvio dell'istanza
  • Se gli utenti (o un'applicazione) abilitano o disabilitano un flag di traccia utilizzando DBCC TRACEON o DBCC TRACEOFF, viene visualizzata una voce nel registro
• Numero di core e socket rilevati da SQL Server
  • Mi piace sempre verificare che SQL Server veda tutto l'hardware disponibile e, in caso contrario, è una bandiera rossa per indagare ulteriormente. Per un buon esempio, vedere il post di Jonathan, Problemi di prestazioni con SQL Server 0212 Enterprise Edition con licenza CAL e il post di Glenn, Bilanciamento delle licenze di base di SQL Server disponibili in modo uniforme tra i nodi NUMA, che include anche alcuni utili TSQL per interrogare il registro.
  • Nota che il testo di questa voce varia tra le versioni di SQL Server.
• Quantità di memoria rilevata da SQL Server
  • Ancora una volta, voglio verificare che SQL Server veda tutta la memoria a sua disposizione.
• Conferma che le pagine bloccate in memoria (LPIM) sono abilitate
  • Mentre questa opzione è abilitata tramite i criteri di sicurezza di Windows, puoi confermare che è abilitata cercando il messaggio "Utilizzo di pagine bloccate nel gestore della memoria" nel registro.
  • Si noti che se si utilizza Trace Flag 834, il messaggio non indicherà pagine bloccate, ma indicherà che vengono utilizzate pagine di grandi dimensioni per il pool di buffer.
• Versione di CLR in uso
• Riuscita o mancata registrazione del nome dell'entità servizio (SPN)
• Quanto tempo impiega un database per essere online
  • Il registro registra quando il database si avvia e quando è online:controllo per vedere se un database impiega troppo tempo per essere visualizzato.
• Stato degli endpoint di Service Broker e Database Mirroring:importante se stai utilizzando una delle due funzionalità
• Conferma che l'Inizializzazione file istantanea (IFI) è abilitata*
  • Per impostazione predefinita queste informazioni non vengono registrate, ma se abiliti Trace Flag 3004 (e 3605 per forzare l'output nel registro), quando crei o cresci un file di dati, vedrai messaggi nel registro per indicare se IFI è in uso o meno.
• Stato delle tracce SQL
  • Quando avvii o interrompi una traccia SQL, questa viene registrata e cerco di vedere se esistono tracce oltre la traccia predefinita (temporaneamente oa lungo termine). Se stai eseguendo uno strumento di monitoraggio di terze parti, come Performance Advisor di SQL Sentry, potresti vedere una traccia attiva che è sempre in esecuzione, ma che acquisisce solo eventi specifici, oppure potresti vedere una traccia avviata, eseguita per un breve periodo, quindi Stop. Non mi preoccupo per una o due tracce in più, a meno che non acquisiscano molti eventi, ma faccio sicuramente attenzione quando sono in esecuzione più tracce.
• L'ultima volta che CHECKDB è stato completato
  • Questo messaggio è spesso frainteso dalle persone:all'avvio dell'istanza, legge la pagina di avvio di ciascun database e rileva quando CHECKDB è stato eseguito l'ultima volta correttamente. La maggior parte delle persone non legge l'intero messaggio:
    
    Data in cui DBCC CHECKDB è stato completato con successo

    La data per il completamento di CHECKDB è l'11 novembre 2012, ma la data di ERRORLOG è il 7 luglio 2015. È importante comprendere che SQL Server non esegui CHECKDB sui database all'avvio, controlla il valore dbcclastknowngood nella pagina di avvio (per vedere quando viene aggiornato, controlla il mio post, What Checks Update dbcclastknowngood. Inoltre, se DBCC CHECKDB non è mai stato eseguito su un database, nessuna voce verrà visualizzato per il database qui.

• CHECKDB completamento
  • Quando CHECKDB viene eseguito su un database, l'output viene registrato nel registro.
• Modifiche alle impostazioni dell'istanza
  • Se modifichi le impostazioni a livello di istanza (ad es. memoria massima del server, soglia di costo per il parallelismo) utilizzando sp_configure o tramite l'interfaccia utente (tieni presente che non registra chi cambiato).

• Modifiche alle impostazioni del database
  • Qualcuno ha abilitato AUTO_SHRINK? Modificare l'opzione RECUPERO su SEMPLICE e poi di nuovo su COMPLETO? Lo troverai qui.
• Modifiche allo stato del database
  • Se qualcuno porta un database OFFLINE (o lo porta ONLINE), questo viene registrato.
• Informazioni sul deadlock*
  • Se devi acquisire informazioni sul deadlock, non eseguire una traccia, e stai eseguendo SQL Server 2005 tramite 2008R2, usa il flag di traccia 1222 per scrivere le informazioni sul deadlock nel log in formato XML. Per quelli di voi che utilizzano SQL Server 2000 e versioni precedenti, è possibile tracciare il flag 1204 (questo flag di traccia è disponibile anche in SQL Server 2005+, ma genera informazioni minime). Se stai utilizzando SQL Server 2012 o versioni successive, questo non è necessario, poiché la sessione dell'evento system_health acquisisce queste informazioni (ed è presente anche nel 2008 e nel 20082, ma devi estrarle da ring_buffer rispetto alla destinazione event_file).
• Messaggi FlushCache
  • Se la cache viene svuotata da SQL Server perché il processo del checkpoint supera l'intervallo di ripristino per il database, vedrai una serie di messaggi FlushCache nel registro (per ulteriori informazioni, consulta questo post di Bob Dorr). Non confondere questi messaggi con quelli che vengono visualizzati quando esegui DBCC FREEPROCCACHE o DBCC FREESYSTEMCACHE:
    
    Messaggio dopo l'esecuzione di DBCC FREEPROCCACHE o DBCC FREESYSTEMCACHE

• AppDomain scarica i messaggi
  • Il registro rileva anche quando vengono creati gli AppDomain e li vedrai solo se stai utilizzando CLR. Se vedo AppDomain scaricare messaggi a causa della pressione della memoria, è qualcosa su cui indagare ulteriormente.

Ci sono altre informazioni utili nel registro, come la modalità di autenticazione in uso, se la Dedicated Admin Connection (DAC) è abilitata o meno, ecc. ma posso anche ottenerle da sys.configurations e controllo quelle con le linee di base dell'istanza Ho discusso in precedenza (Controlli di integrità proattivi di SQL Server, Parte 3:Impostazioni di istanza e database).

Cosa non c'è nell'ERROLOG, che potresti aspettarti?

Questo è un breve elenco, per ora, poiché suppongo che alcuni di voi potrebbero aver trovato altre cose che pensavate sarebbero state nel registro ma non lo erano...

• Aggiunta o rimozione di file di database o filegroup
• Avvio o arresto di sessioni di eventi estesi
  • Tuttavia, se si distribuisce un trigger DDL o una notifica eventi a livello di server, è possibile registrare queste informazioni. Per maggiori dettagli, consulta il post di Jonathan, La registrazione degli eventi estesi cambia in ERRORLOG.
• L'esecuzione di DBCC DROPCLEANBUFFERS viene visualizzata nell'ERRORLOG

Gestione del registro

Tenere presente che, per impostazione predefinita, SQL Server conserva solo i sei (6) file di registro più recenti (oltre al file corrente) e il file di registro esegue il rollover ogni volta che SQL Server viene riavviato. Di conseguenza, a volte puoi avere file di registro estremamente grandi che richiedono del tempo per essere aperti e sono difficili da scavare. D'altra parte, se ti imbatti in un caso in cui l'istanza viene riavviata un paio di volte, potresti perdere informazioni importanti. Si consiglia di aumentare il numero di file conservati a un valore superiore (ad es. 30) e di creare un processo agente per eseguire il rollover del file una volta alla settimana utilizzando sp_cycle_errorlog.

Oltre a gestire i file, puoi modificare le informazioni scritte nel registro. Una delle voci più comuni che crea confusione in ERRORLOG è la voce di backup riuscita:

Backup completato con successo

Se disponi di un'istanza con numerosi database e i backup del registro delle transazioni vengono eseguiti con qualsiasi regolarità (ad esempio ogni 15 minuti), vedrai il registro riempirsi rapidamente di messaggi, il che rende più difficile trovare un vero problema. Fortunatamente, puoi utilizzare il flag di traccia 3226 per disabilitare i messaggi di backup riusciti (gli errori verranno comunque visualizzati nel registro e tutte le voci esisteranno ancora in msdb).

Un'altra serie di messaggi che ingombrano il registro sono i messaggi di accesso riusciti. Questa è un'opzione che configuri per l'istanza nella scheda Sicurezza:

Opzione di sicurezza per registrare accessi riusciti e/o non riusciti

Se registri accessi riusciti o accessi falliti e riusciti, puoi avere file di registro molto grandi, anche se esegui il rollover dei file ogni giorno (dipenderà da quanti utenti si connettono). Raccomando di acquisire solo gli accessi non riusciti. Per le aziende che hanno l'obbligo di registrare gli accessi riusciti, prendi in considerazione l'utilizzo della funzionalità di controllo, aggiunta in SQL Server 2008. Nota a margine:se modifichi l'impostazione di controllo degli accessi, non avrà effetto fino al riavvio dell'istanza.

Non sottovalutare l'ERRORLOG

Come puoi vedere, ci sono alcune ottime informazioni in ERRORLOG che puoi utilizzare non solo durante la risoluzione dei problemi delle prestazioni o l'analisi degli errori, ma anche durante il monitoraggio proattivo di un'istanza. Puoi trovare informazioni nel registro che non si trovano da nessun'altra parte; assicurati di controllarlo regolarmente e di non lasciarlo come un ripensamento.

Guarda le altre parti di questa serie:

• Parte 1:Spazio su disco
• Parte 2:Manutenzione
• Parte 3:Impostazioni di istanza e database