Manutenzione programmata del database IS 24 ore su 24, 7 giorni su 7 in MS SQL Server

Introduzione

Questo articolo è una breve rassegna delle principali manutenzioni programmate con un database del sistema informativo 24 ore su 24, 7 giorni su 7 che non ha tempi di inattività, nonché degli approcci alla loro esecuzione in MS SQL Server.

Eventuali commenti e aggiornamenti all'articolo sono molto apprezzati.

Manutenzione programmata

Vi è la seguente manutenzione programmata che vorrei segnalare:

Backup programmati con ulteriore verifica senza ripristino
Ripristino pianificato dei backup per verificarne le prestazioni
Analisi del dispositivo di archiviazione dati che contiene il sistema e tutti i database necessari
Test programmato dei servizi richiesti
Ottimizzazione programmata delle prestazioni di un sistema
Manutenzione programmata dell'integrità dei dati
Manutenzione programmata della convalida dei dati

I primi tre punti sono i più importanti, in quanto forniscono un ripristino del sistema dopo vari guasti. Tuttavia, consiglierei di eseguire anche i tre punti minimi, in modo che gli utenti possano lavorare a proprio agio (quindi, tutte le query dovrebbero essere eseguite velocemente) e in modo che i dati debbano essere convalidati in tutti i sistemi di reporting.

Per automatizzare la manutenzione programmata, è possibile organizzare le sue parti nell'Agente o nell'Utilità di pianificazione di Windows.

Il sesto punto si basa sul comando CHECKDB.

Il settimo punto è implementato nei confronti dell'area di dominio utilizzata nel sistema informativo.

Parlerò in dettaglio dei primi cinque punti.

Backup programmati con ulteriore verifica senza ripristino

Poiché ci sono molti articoli su questo argomento, va notato che è necessario eseguire regolarmente questa manutenzione programmata su un server di backup, piuttosto che sul server principale. Questo server di backup dovrebbe contenere dati aggiornati (ad esempio, quello ottenuto con la replica). Inoltre, è necessario eseguire il backup di tutti i database di sistema (tranne tempdb) su ogni istanza di MS SQL Server.

Quando il backup non riesce o una scansione del backup identifica un problema, è necessario segnalare queste informazioni agli amministratori. Ad esempio, puoi inviargli un'e-mail.

È importante determinare una strategia per il backup, che risponderà alle seguenti domande:

Quanto spesso e quando dobbiamo eseguire il backup dei dati (registro completo, differenziale e delle transazioni)?
Per quanto tempo e quando dovremmo eliminare i backup?

Ripristino pianificato dei backup per verificarne le prestazioni

Consiglio di eseguire questa procedura su un server di backup con utilità di terze parti o il RIPRISTINO comando.

Quando il ripristino del backup non riesce, è necessario segnalare queste informazioni agli amministratori. Ad esempio, puoi inviargli un'e-mail.

Inoltre, è necessario ripristinare i backup dei database di sistema. Per fare ciò, è necessario ripristinarli come un normale database utente con un nome diverso dai nomi dei database di sistema.

Analisi dei dispositivi di archiviazione dati che contengono il sistema e tutti i database necessari

È necessario analizzare quanto spazio occupa ogni database, come cambiano le dimensioni dei file e come cambiano le dimensioni dello spazio libero nell'intero dispositivo di archiviazione. Ad esempio, puoi eseguire questa attività in parte con la raccolta automatica dei dati sui file di database e sulle unità logiche del sistema operativo in MS SQL Server.

Puoi fare questo controllo ogni giorno e poi inviare i risultati. Come al solito, puoi inviarli a un'e-mail.

È inoltre necessario monitorare i database di sistema in modo da assicurarsi che tutto funzioni correttamente.

Inoltre, è importante testare i dispositivi di archiviazione per verificare se sono presenti deprezzamenti o settori danneggiati.

Tieni presente che durante il test un dispositivo dovrebbe essere fuori servizio e tutti i dati dovrebbero essere copiati su un altro dispositivo poiché il test carica il dispositivo in modo drastico.

Questo compito è strettamente correlato ai compiti dell'amministratore di sistema, quindi lo terremo da parte. Per assumere il pieno controllo del caso, devi automatizzare la consegna dei rapporti via email.

Consiglierei di eseguire questo test due volte l'anno.

Test programmato dei servizi richiesti

I tempi di inattività del servizio sono una cattiva pratica. Pertanto, un server di backup entrerà in azione in caso di guasti. Tuttavia, è necessario controllare i registri di tanto in tanto. Inoltre, puoi anche pensare a una raccolta dati automatica con ulteriore notifica a un amministratore tramite l'invio di un'e-mail.

È necessario controllare le attività dell'agente SQL Server o dell'Utilità di pianificazione di Windows con una raccolta automatica dei dati sulle attività completate in MS SQL Server.

Ottimizzazione programmata delle prestazioni di un sistema

Comprende i seguenti aspetti:

Automazione della deframmentazione degli indici nei database di MS SQL Server
Automatizzazione della raccolta dei dati sulle modifiche degli schemi di database in MS SQL Server. Puoi ripristinare un backup e confrontare le modifiche, ad esempio, utilizzando dbForge
Automatizzazione della pulizia dei processi bloccati in MS SQL Server
Pulizia della cache delle procedure. Qui è necessario determinare quando e cosa deve essere ripulito
Implementazione di un indicatore di performance
Sviluppo e modifica di indici cluster

Inoltre, ti consiglio di disattivare AUTO_CLOSE caratteristica.

A volte, per diversi motivi, un ottimizzatore parallelizza una query, che non è sempre ottimale.

Pertanto, ci sono alcuni consigli che dovresti tenere a mente:

Se ottieni molti dati, lascia il parallelismo.
Se ottieni alcuni dati, non utilizzare il parallelismo.

Esistono due parametri nelle impostazioni dell'istanza di SQL Server responsabili del parallelismo:

massimo grado di parallelismo. Per disattivare il parallelismo, imposta "1" come valore, il che significa che un solo processore eseguirà un codice.
soglia di costo per il parallelismo. Dovrebbe essere impostato per impostazione predefinita.

Ci sono due code principali:

una coda per il tempo della CPU (coda QCPU). Si verifica quando una query è stata abilitata ed è in attesa che un processore la esegua.
una coda per le risorse (coda QR). Si verifica quando una query è in attesa che le risorse siano svincolate per eseguire il processo.

La seguente formula descrive l'esecuzione della query (T):

T=TP+TQR+TCPU+TQCPU, dove:

TP sta compilando il tempo per un piano
TQR è il tempo di coda per le risorse (coda QR)
TQCPU è il tempo di coda per le risorse da svincolare (coda QCPU)
TCPU è il momento di eseguire una query

Nella vista di sistema sys.dm_exec_query_stats:

tempo_lavoro_totale =TP+TCPU+TQCPU
tempo_trascorso_totale =TQR+TCPU

Gli strumenti integrati non consentono di valutare con precisione il tempo di esecuzione delle query.

Nella maggior parte dei casi, tempo_trascorso_totale fornisce il tempo che è vicino al tempo di esecuzione della query.

È possibile determinare il tempo di esecuzione della query in modo più accurato utilizzando trace. In alternativa, puoi registrare l'ora di inizio e di fine della query. Fai attenzione alle tracce poiché caricano in modo significativo il sistema. Pertanto, è meglio eseguirlo su un server di backup e raccogliere dati dal server principale. In questo caso verrà caricata solo la rete.

Durante la parallelizzazione, SQL Server alloca N processi a una query (nell'edizione Standard n<=4). Ogni processo richiede tempo della CPU per eseguire una query (non sempre un processo deve essere eseguito su ciascun core).

Più processi hai, maggiori sono le possibilità che alcuni vengano sostituiti da altri, il che porta ad un aumento della TQCPU.

Potrebbe essere necessario molto più tempo per eseguire una query durante la parallelizzazione, nei seguenti casi:

Velocità effettiva del sottosistema del disco ridotta. In questo caso, la scomposizione della query richiede molto più tempo.
I dati potrebbero essere bloccati per il processo.
Non esiste un indice per il predicato, che porta a una scansione della tabella.
Osservazioni:
È necessario disabilitare le query parallele sui server in cui non è necessario eseguire una selezione enorme (il tempo_di_lavoro_totale dovrebbe essere ridotto a causa di una possibile diminuzione di TCPU e TQCPU). A tale scopo, è necessario impostare la funzionalità del grado massimo di parallelismo su "1" affinché un solo processore funzioni.
Inoltre, è possibile utilizzare altri framework per creare un sistema che determini le prestazioni ad alta velocità dei database . È importante capire come funzionano questi framework e come interpretare i numeri recuperati.

Per quanto riguarda lo sviluppo e la modifica degli indici, ovvero gli indici cluster, l'importante è capire come è impostata la logica degli indici e come funziona.

Tieni presente che le chiavi primarie e in cluster non hanno lo stesso significato:

Una chiave primaria è una colonna o un insieme di colonne, che rendono un record univoco nella tabella. Per la chiave primaria, puoi creare un indice cluster o non cluster univoco. La chiave primaria viene utilizzata in altre tabelle come chiave esterna per fornire l'integrità dei dati.

Un indice cluster è un B-tree o una sua modifica. Le foglie contengono i dati stessi mentre i nodi contengono informazioni sull'indice. Inoltre, un indice cluster può anche essere non univoco. Tuttavia, lo consiglio per essere unico.

Vorrei ricordare che un B-tree è una struttura che memorizza i dati nell'ordine filtrato da un indice cluster. Pertanto, è importante raggruppare i campi selezionati come indice cluster in ordine decrescente o crescente. Per un indice cluster, puoi utilizzare colonne di numero intero (identità), nonché dati e ora. Tuttavia, colonne come l'identificatore univoco non sono adatte in quanto quest'ultimo porterà a una regolare ristrutturazione di un B-tree, che aumenterà la quantità di letture e record su un dispositivo di archiviazione in cui si trova il database.

Inoltre, devi assicurarti che l'indice venga utilizzato con la vista di sistema sys.dm_db_index_usage_stats.

PS È necessario verificare se i dati sono aggiornati su un server di backup, nonché controllare un sistema che sincronizzi questi dati (ad esempio, le repliche).

Manutenzione programmata del database IS 24 ore su 24, 7 giorni su 7 in MS SQL Server

Introduzione