Sqlserver
 sql >> Database >  >> RDS >> Sqlserver

Inconvenienti comuni di SQL Server

Insegno e scrivo da molti anni sugli errori comuni di SQL Server. Ne ho scritto un blog anche anni fa, tuttavia, con il passare del tempo, la guida è cambiata un po'. Questo articolo espanderà il mio articolo precedente e indicherà come si applicano a SQL Server, database SQL di Azure e Istanza gestita SQL di Azure.

Per molti anni ho trovato utenti che commettevano gli stessi errori. Li chiamo errori, tuttavia, nella maggior parte dei casi, sono più solo cose che non vengono fatte correttamente perché le persone che gestiscono l'ambiente non ne sanno niente di meglio. Ecco alcuni degli elementi più critici che chiunque installi e supporti SQL Server dovrebbe conoscere:

  • Backup
  • DBCC CHECKDB
  • Impostazioni memoria
  • Statistiche
  • Manutenzione dell'indice
  • MAXDOP e soglia di costo per il parallelismo
  • Avvisi di SQL Server Agent

Backup

Controllo sempre prima i backup quando guardo un nuovo sistema. È fondamentale disporre di backup adeguati per soddisfare gli obiettivi di ripristino. La perdita di dati può essere dannosa per un'organizzazione. Quando esamino i backup, controllo il modello di ripristino e la cronologia corrente dei backup per ciascun database. Di solito trovo una combinazione di quanto segue:

  • Nessun backup:nessun record di alcun backup per il database
  • Backup mancanti:nessun backup del registro per un database che utilizza il modello di ripristino completo
  • Nessun backup recente:l'ultimo backup risale a settimane/mesi/anni

I backup non configurati correttamente sono dannosi per un'organizzazione quando si verifica una situazione di ripristino. Lavorare con i clienti e doverli dire che hanno perso dei dati non è mai né divertente né facile. Avere backup adeguati per soddisfare gli SLA dovrebbe essere la massima priorità di qualsiasi organizzazione oltre ad assicurarsi che ci siano copie di questi backup archiviate in una posizione secondaria fuori sede.

Questa situazione si applica a SQL Server e IaaS locali. Il database SQL di Azure e Istanza gestita di Azure dispongono di backup gestiti.

DBCC CHECKDB

Il danneggiamento del database si verifica purtroppo. Senza controllare regolarmente la corruzione, i clienti possono trovarsi in una brutta situazione non disponendo di backup per eseguire il ripristino quando tale corruzione colpisce i dati fisici. Per verificare la presenza di danneggiamenti, DBCC CHECKDB deve essere eseguito regolarmente su ogni database. Quello che trovo è molto simile ai backup:

  • Nessun DBCC CHECKDB eseguito
  • DBCC CHECKDB viene eseguito solo su database selezionati
  • Gli ultimi DBCC CHECKDB sono stati eseguiti mesi o anni fa

Il caso peggiore è un processo pianificato che segnala DBCC CHECKDB non riusciti

Non è mai piacevole trovare un danneggiamento o chiedere a un cliente di contattare un problema di danneggiamento quando il danneggiamento è un heap o un indice cluster e non sono presenti backup prima che si verifichi il danneggiamento. In questi casi, il danneggiamento è rappresentato dai dati effettivi e l'avvio del ripristino da prima del danneggiamento è nella maggior parte dei casi l'unica opzione. Nei casi in cui il danneggiamento è un indice non in cluster, la ricostruzione dell'indice è la soluzione.

In alcune situazioni, ho dovuto lavorare con clienti che hanno una brutta corruzione senza backup adeguati in cui sono stato in grado di eseguire lo script del database e copiare manualmente tutti i dati utilizzabili in un database appena creato. Queste situazioni costose possono essere facilmente evitate eseguendo DBCC CHECKDB e mantenendo un'adeguata conservazione del backup.

Consiglio ai clienti di eseguire DBCC CHECKDB in locale, IaaS, database SQL di Azure e Istanza gestita SQL di Azure. Azure fa un ottimo lavoro controllando la corruzione fisica; tuttavia, ritengo che i consumatori debbano controllare la corruzione logica.

Impostazioni memoria

Un'installazione predefinita di Microsoft SQL Server ha il valore minimo della memoria impostato su 0 e il valore massimo della memoria del server impostato su 2147483647 MB, ovvero 2 petabyte. Prima di SQL Server 2012, il valore massimo della memoria del server si applicava solo al bufferpool, quindi i clienti dovevano limitare la quantità di memoria che il bufferpool poteva usare per risparmiare memoria per il sistema operativo e altri processi. SQL Server 2012 ha introdotto una riscrittura del gestore della memoria in modo che il valore massimo della memoria del server si applichi a tutte le allocazioni di memoria di SQL Server.

È altamente consigliabile impostare un valore massimo per l'istanza di SQL Server. Jonathan Kehayias ha scritto un post sul blog Di quanta memoria ha effettivamente bisogno il mio SQL Server, con una formula che aiuta a stabilire la linea di base per il valore massimo di memoria. In caso di SQL Server condiviso, consiglio ai miei clienti di impostare il valore minimo sul 30% della memoria sul server.

In situazioni con più istanze o in cui il server viene utilizzato per SQL Server, SSIS, SSAS o SSRS, è necessario valutare la quantità di memoria necessaria agli altri sistemi e ridurre il valore massimo della memoria del server per consentire memoria adeguata per il sistema operativo e l'altro servizi.

Questo problema è valido per locale, IaaS e parzialmente per Istanza gestita SQL di Azure. Istanza gestita imposta un valore massimo di memoria del server in base al livello distribuito, tuttavia quando ho testato il ridimensionamento dell'ambiente, il valore massimo di memoria non è stato modificato dinamicamente. In quella situazione, dovresti aggiornare manualmente il valore. Questo problema non si applica al database SQL di Azure.

Statistiche

Query Optimizer utilizza le statistiche per creare piani di esecuzione. Ciò significa che SQL Server ha bisogno che le statistiche siano aggiornate in modo che Query Optimizer abbia maggiori possibilità di creare un buon piano di esecuzione. Per impostazione predefinita, le statistiche vengono aggiornate dopo la modifica del 20% +500 righe di dati. Ciò può richiedere molto tempo su tavoli più grandi. A partire dal livello di compatibilità 130, la soglia per gli aggiornamenti delle statistiche per le tabelle di grandi dimensioni è stata abbassata. Per SQL Server 2008R – 2014, puoi abbassare questa soglia usando il flag di traccia 2371.

Mi accorgo regolarmente che i clienti non aggiornano manualmente le statistiche e, anche con la soglia più bassa, ho scoperto che l'aggiornamento manuale rende un ambiente più stabile.

Consiglio ai clienti di utilizzare uno script di terze parti per aggiornare le statistiche. Ola Hallengren ha pubblicato una soluzione di manutenzione ampiamente utilizzata per SQL Server. Parte di questo processo è la sua procedura di ottimizzazione dell'indice, che può richiedere parametri aggiuntivi per aggiornare le statistiche.

@UpdateStatistics 
    ALL     = update index and column statistics
    INDEX   = update index statistics
    COLUMNS = update column statistics
    NULL    = Do not perform statistics maintenance (this is the default)

@OnlyModifiedStatistics
    Y = Update statistics only if rows have been modified since most recent stats update
    N = Update statistics regardless of whether any rows have been modified

Ho scoperto che i clienti che utilizzano prodotti o script di terze parti per eseguire la manutenzione dell'indice in base al livello di frammentazione dell'indice non stanno considerando che le riorganizzazioni non aggiornano le statistiche come fanno le ricostruzioni. Molte di queste applicazioni di terze parti hanno opzioni per aggiornare le statistiche proprio come la procedura di ottimizzazione dell'indice di Ola, devi solo attivarla.

L'aggiornamento delle statistiche si applica a locale, IaaS, database SQL di Azure e Istanza gestita SQL di Azure.

Manutenzione dell'indice

L'esecuzione della manutenzione dell'indice rimuovendo la frammentazione dagli indici è ancora importante. Alcuni documenti ritirati da Microsoft hanno affermato che la frammentazione dell'indice può avere un impatto negativo dal 13 al 460% a seconda delle dimensioni dell'ambiente e del livello di frammentazione. Sebbene hardware come SAN intelligenti, Solid State Disk e altri miglioramenti abbiano contribuito a velocizzare le cose, lo spazio sprecato nell'indice può tradursi in spazio sprecato nel pool di buffer, oltre a sprecare più I/O.

La frammentazione avviene attraverso operazioni regolari come inserimenti, aggiornamenti ed eliminazioni. Per rimediare, è necessaria una corretta manutenzione dell'indice di ricostruzione o riorganizzazione degli indici. Mi rivolgo di nuovo a Ola Hallengren, per il suo script di ottimizzazione dell'indice. Lo script di Ola offre la possibilità di specificare di ricostruire o riorganizzare in base al livello di frammentazione e alle pagine minime. Molti strumenti di terze parti offrono la stessa logica. I piani di manutenzione del database di SQL Server precedenti a SQL Server 2016 consentivano solo la ricostruzione o la riorganizzazione di tutti gli indici. A partire da SQL Server 2016, ora puoi specificare una logica simile in base ai livelli di frammentazione. Non dimenticare queste statistiche se utilizzi una logica intelligente basata sui livelli di frammentazione.

Mi piacciono lo script di Ola e gli strumenti di terze parti che si registrano su una tabella. Posso quindi interrogare la tabella per vedere se sono presenti punti caldi dell'indice in cui la frammentazione si verifica costantemente a livelli elevati e risolvere i problemi relativi al motivo per cui la frammentazione è così diffusa e si può fare qualsiasi cosa.

Ci sono eccezioni a ogni regola o migliore pratica. Alcuni modelli di accesso ai dati portano a una frammentazione costante. Il costo di ricostruire/riorganizzare costantemente quei tavoli potrebbe non valere la pena e può essere escluso dalla manutenzione. Tali situazioni dovrebbero essere valutate caso per caso.

Questo vale per locale, IaaS, database SQL di Azure e Istanza gestita SQL di Azure.

MAXDOP

Trovo che il grado massimo di parallelismo e la soglia di costo per il parallelismo siano in genere lasciati ai valori predefiniti sui server client. Per MAXDOP il valore predefinito è zero, il che significa che è possibile utilizzare un numero "illimitato" di CPU per eseguire una regione parallela di una query. Tecnicamente fino a 64 processori a meno che non si abiliti un flag di traccia per usarne di più.

Un decennio fa, quando i processori avevano un numero di core inferiore, questo valore era accettabile. Oggi, con un'elevata densità di core e server multi-socket, un numero illimitato di CPU per il parallelismo non è così buono. Microsoft ha fornito indicazioni sui valori da utilizzare per MAXDOP.

Se utilizzi SQL Server 2008 – SQL Server 2014, per un singolo nodo NUMA con meno di 8 processori logici, mantieni MAXDOP pari o inferiore al numero di processori logici. Se hai più di 8 processori logici, mantieni MAXDOP a 8. Se hai più nodi NUMA con meno di 8 processori logici per nodo NUMA, mantieni MAXDOP uguale o inferiore al numero di processori logici per nodo NUMA. Maggiore di 8, mantieni MAXDOP a 8.

SQL Server 2016 ha introdotto i nodi soft-NUMA. Durante l'avvio del servizio, se Motore di database rileva più di 8 core fisici per nodo o socket NUMA, i nodi soft-NUMA vengono creati automaticamente. Il motore si occupa di posizionare i processori logici dallo stesso core fisico in diversi nodi soft-NUMA. Per questo motivo, abbiamo linee guida leggermente diverse per MAXDOP da SQL Server 2016 in poi.

Se utilizzi SQL Server 2016 e versioni successive, per un singolo nodo NUMA con meno di 16 processori logici, mantieni MAXDOP pari o inferiore al numero di processori logici. Se hai più di 16 processori logici, mantieni MAXDOP a 16. Se hai più nodi NUMA con meno di 16 processori logici per nodo NUMA, mantieni MAXDOP uguale o inferiore al numero di processori logici per nodo NUMA. Maggiore di 16, mantieni MAXDOP alla metà del numero di processori logici per nodo NUMA con un valore MAX di 16.

Se sei per lo più virtualizzato su macchine con 8 o meno processori logici con un MAXDOP predefinito, probabilmente sei a posto. Se disponi di hardware fisico di grandi dimensioni con impostazioni predefinite, dovresti cercare di ottimizzare MAXDOP.

Tutte le cifre sopra sono linee guida, non verità dure. I tuoi carichi di lavoro variano e dovresti prendere in considerazione quando determini quale valore è più ottimale per il tuo carico di lavoro.

La configurazione di MAXDOP si applica a Istanza gestita SQL di Azure, IaaS e locale. Tuttavia, esiste una configurazione con ambito database che può essere applicata a ciascun database a partire da SQL Server 2016 e ciò si applica al database SQL di Azure.

Soglia di costo per il parallelismo

La soglia di costo per il parallelismo ha un valore predefinito di 5. La cronologia di questo numero risale ai primi giorni di SQL Server e alla workstation su cui veniva eseguito il test del carico di lavoro. Con l'hardware moderno, la stima dei costi di 5 è obsoleta. I test hanno dimostrato che l'aumento del numero da 5 a un valore più alto impedirà alle query con esecuzione più breve di avere un piano parallelo. Tendo a consigliare di aumentare questo valore a un numero più alto dopo aver esaminato la Plan Cache. In molti casi finisco per iniziare con un valore di 25 e quindi monitorare ulteriormente e regolare da lì, se necessario. Per ulteriori informazioni sull'ottimizzazione della soglia di costo per il parallelismo, Jonathan Kehayias ha scritto:Ottimizzazione della "soglia di costo per il parallelismo" dalla cache del piano.

Ciò si applica a Istanza gestita di SQL di Azure in locale, IaaS e.

Avvisi di SQL Server Agent

Tutti dovrebbero sfruttare gli avvisi di SQL Agent a meno che non dispongano di un'applicazione di terze parti che monitora le stesse condizioni di errore. La configurazione degli avvisi è facile e gratuita e averli configurati ti fornirà informazioni critiche quando i tuoi server hanno problemi.

Ho scritto un articolo intitolato Avvisi di SQL Server Agent, fornendo istruzioni dettagliate su come creare avvisi per errori di gravità 19-25 ed errore 825. Abilitare questi avvisi è semplice:abilitare la posta del database, creare un operatore di posta e quindi creare il avvisi. Questo può essere ottenuto utilizzando la GUI o con T-SQL. Incoraggio tutti a scrivere questo processo usando T-SQL e renderlo parte della build del tuo server standard.

Ciò si applica a Istanza gestita di SQL di Azure in locale, IaaS e.

Riepilogo

Come puoi vedere, ci sono molte impostazioni che dovrebbero essere modificate dalle impostazioni predefinite dopo l'installazione di SQL Server. Questa non è una lista esauriente; tuttavia, copre molti dei problemi più critici e che incidono sulle prestazioni che trovo e che ho raggruppato nella mia categoria "contrattempi di SQL Server".