SQL Server: Primi 10 segreti di un esperto SQL Server

La manutenzione di un ambiente SQL Server è un compito potenzialmente complesso. Ecco dieci modi è possibile ridurre la complessità e ridurre il carico superiore.

Paul s. Randal

Molte aziende hanno downsized i reparti IT nel corso degli ultimi anni. Molti amministratori di database (DBA) hanno terminato con responsabilità di un numero elevato di database di SQL Server. Peggio ancora, spesso non è nessun amministratore di database effettivo. Un utente contrassegnato come gli amministratori di database involontari o de facto. In alcuni casi, l'amministratore di database finisce in modalità pure combattere incendi, passare da una crisi al successivo. Questo tipo di ambiente è difficile e toxic unsustainable. Nessuno piace essere sotto stress costante e interruzioni.

Uno dei metodi di questo tipo di situazione è di investire un po' di tempo semplificazione dell'ambiente di SQL Server per rendere più facili da comprendere e gestire. Basato sulla mia consulenza di SQL Server, ecco i primi 10 modi un amministratore di database di SQL Server possono assumere il controllo del suo ambiente e ridurre il potenziale complessivo per crises verificarsi. Questo elenco viene visualizzato in ordine di priorità crescente circa.

10. Eseguire l'inventario

Quante volte è stato richiesto ai dati danneggiato di ripristino su un database che è stato che non esisteva ancora? È facile per i database di SQL Server per sprawl all'interno di un'azienda. Il team DBA può perdere traccia di ciò che è già disponibile, causando non gestite istanze di SQL Server. In questo modo i database sottoposti a backup, non sono corretti, correttamente non sono protetti e mancante out via un host di altre attività di gestione necessari.

È essenziale disporre di un inventario aggiornato dei database è necessario nell'organizzazione e sotto il controllo e istanze. Questo è l'unico modo è possibile gestire correttamente, consolidare laddove necessario, correttamente l'ambito e pianificare gli aggiornamenti e i progetti. Consente inoltre di stabilire limiti per le responsabilità pubblicando un elenco di istanze noti accettare responsabilità con contratto da diversi team all'interno dell'organizzazione. È possibile definire criteri di supporto per istanze noti e insistere che nuove istanze siano conformi alle linee guida della configurazione prima che li supportano.

Esistono numerosi strumenti per la creazione di un inventario di SQL Server, da semplici strumenti quali SQLPing3 e SQLRecon Microsoft Assessment e Planning Toolkit e la procedura guidata Discovery Quest.

9. Standardizzare configurazioni

Se il numero di database e istanze di SQL per cui si è responsabili sta aumentando il tempo, si saprà che il numero di configurazioni aumenta in modo simile. È estremamente difficile lavorare in modo efficiente durante lo spostamento di istanza istanza sono costantemente ricordare i dettagli di configurazione per istanze diverse.

La soluzione è di standardizzare la configurazione nella misura massima possibile di lettere di unità, opzioni di configurazione, le impostazioni del database, la manutenzione del database, le impostazioni di protezione e così via. SQL Server 2008 è stata introdotta la funzionalità di gestione basata su criteri consente di definire e applicare criteri. Lara Rubbelke, un esperto di tecnologia SQL Server presso Microsoft, ha prodotto anche il framework di criteri Enterprise Management (EPM), facilmente estende le funzionalità per le istanze di SQL Server 2005 e SQL Server 2000. È possibile trovare il Framework EPM su CodePlex. Figura 1 Visualizza un report di esempio EPM Framework.

The Enterprise Policy Management Framework report

Figura 1 report The Enterprise Policy Management Framework

8. Comprendere il sottosistema di I/O

Esistono vari fattori correlati al sottosistema di I/O che può influenzare le istanze di SQL Server. È necessario essere a conoscenza di questi e il loro impatto potenziale:

  • La capacità del sottosistema di I/O in termini di spazio del disco e velocità effettiva di lettura/scrittura. Deve essere in grado di far fronte a richieste di picco del carico di lavoro e fornire comunque spazio sul volume di dati a crescere prima è necessario acquistare ulteriori capacità. Identificazione dei colli di bottiglia I/O e lo spostamento di dati e/o altre parti del sottosistema di I/O dei file di log è più uniforme possibile bilanciare il carico.
  • Le funzionalità di ridondanza del sottosistema di I/O del livello RAID e se è possibile eseguire operazioni quali backup con mirror suddiviso e qualsiasi forma di mirroring/replica (livello di I/O sottosistema, il livello di SQL Server). È importante proteggere i dati e i file di registro da errori del disco e altri potenziali problemi. Ciò è spesso un commercio disattivata, RAID 10 offre una maggiore ridondanza rispetto a RAID-5, ma è più costoso. Leggere il white paper “ Physical Database archivi Design ” per ulteriori indicazioni.
  • Il sottosistema di I/O è configurato correttamente in termini di dimensione di striping RAID NTFS allocazione o unità cluster dimensioni e partizioni allineamento. Estrarre questo post di blog “ are compensa la partizione del disco, RAID stripe dimensioni e unità di allocazione NTFS impostate correttamente? ” per ulteriori dettagli.

7. Creare un piano di manutenzione personalizzato

Ogni volta che spiegano le classi di manutenzione del database sempre iniziare pronunciando, “ È impossibile soltanto stoccare un database in produzione e analisi. ” Indici frammentati nel tempo, comporta una riduzione delle prestazioni. Le statistiche diventano obsolete, che conduce a piani di query non valida e una riduzione delle prestazioni. Sottosistemi di I/O possono ottenere danneggiati e vi è la necessità di backup ever-present.

È possibile affrontare questi problemi, specifiche per i database di un piano di manutenzione complete. Un piano personalizzato è molto meglio di un piano generico non risoluzione in modo adeguato alle proprie esigenze. La funzione TechNet Magazine di agosto 2008, “ Top suggerimenti per SQL Server Database Maintenance valide , ” viene illustrato come costruire un buon piano. Il punto di partenza ottimale per la creazione di un piano di manutenzione è lo script completo e gratuito da di Ola Hallengren. Ovvero è consigliabile per i client.

6. Garantire la protezione del sistema

Investire tempo nell'individuazione preventiva dei problemi di protezione è essenziale per impedire incidenti e non è necessario gestirli in un secondo momento. Una mia funzionalità TechNet Magazine , “ comuni problemi di protezione di SQL Server e soluzioni , ” Elenca i 10 problemi più comuni e come evitarli. Inoltre, non dimenticare di rimanere di sopra di patch ai sistemi come scoprire vulnerabilità.

5. Visualizzare le relative condizioni valida per sviluppatori

Uno dei punti principali della tensione in qualsiasi reparto IT è spesso tra il team DBA e il team di sviluppo. I due gruppi non capiscono in genere ’ altre priorità problemi e, da scadenze di sviluppo a SQL Server le decisioni di progettazione. Opinioni differenti sui problemi di funzionamento e sulle prestazioni e le responsabilità, distribuzione e supporto sono abbastanza comune.

È possibile rendere il processo molto più uniformi accattivanti in modo proattivo e produttività con il team di sviluppo. Organizzare le sessioni di formazione reciproca funziona bene, soprattutto se eseguite in modo non accusatory. Condurre revisioni di progettazione con una persona del team di DBA presente e testare il codice corretto prima di essere implementato nell'ambiente di produzione, si spera evitando errori dannosi possono ulteriormente erode inter-team relazioni.

4. Sviluppo di una strategia di ripristino di emergenza completo

Indipendentemente da come prova di punto elenco potrebbe essere l'infrastruttura, è necessario disporre di un piano di emergenza per quando emergenza colpisce. Non è possibile prevedere danneggiamento, interruzioni dell'alimentazione, generato, perdite di dati accidentali o un host di altri potenziali problemi. È necessario un piano per gestire e risolvere questi problemi.

Utilizzare Gestione per definire il tempo di inattività e perdita di dati contratti di licenza software per i database, pianificare come recuperare dati da diversi tipi di perdita di dati, determinare come i database e tutte le istanze SQL figura nel piano di continuità aziendale della società. Scoprire l'importanza relativa di tutti i database e istanze, pertanto è possibile assegnare una priorità di ripristino di emergenza.

Sarà inoltre necessario implementare tecnologie che consentono di sapere quando problemi, ad esempio i checksum di pagina, le verifiche di coerenza, avvisi di Agente SQL e gli avvisi di System Center Operations Manager. Questa infrastruttura di ripristino di emergenza consente di proteggere i dati con backup, distribuzione dei log, replica e il mirroring del database;e potenzialmente di clustering di failover per un sistema ridondante con il mirroring del database o il failover. Esistono due white paper che consentono questo: “Disponibilità elevata con SQL Server 2008” e “ dimostrata architetture SQL Server per la disponibilità elevata e Disaster Recovery . ”

3. Prendere e verifica backup regolari

Indipendentemente come buona la disponibilità e la pianificazione del ripristino di emergenza è, non è possibile evitare di eseguire backup regolari dei database. Se il database viene eliminato o fatally danneggiato, potrebbe essere l'unico modo per ripristinare dall'ultimo set di backup, in modo che se non si dispone di alcun backup società potrebbe risentirne principali conseguenze. Non solo è necessario eseguire backup, è inoltre necessario eseguire regolarmente ripristino da tali per sapere che verranno utilizzati quando è necessario.

È possibile trovare ulteriori informazioni in due articoli che ho scritto per di TechNet Magazine nel 2009: “Backup di informazioni su SQL Server” e “ SQL server: Recupero da guasti con backup.

2. Monitoraggio e gestione delle prestazioni

Prestazioni ottimizzazione accetta la maggior parte del tempo della DBA, ma esistono molti modi per semplificare il processo:

  • Stabilire una baseline delle prestazioni per verificare se le prestazioni veramente sono stato modificato.
  • Suddividere il sistema in primitive che è possibile misurare in isolamento senza l'incertezza fattori esterni.
  • Utilizzare la metodologia di attese e code per individuare rapidamente i problemi di prestazioni.
  • Monitoraggio delle prestazioni di sistema primitivi, i contatori delle prestazioni e le statistiche di attesa. In questo modo che si saprà quando le prestazioni inizino a risentirne. Utilizzare la funzione di agente di raccolta dati delle prestazioni in SQL Server 2008 e dashboard prestazioni per SQL Server 2005.
  • Stabilire un piano di manutenzione.
  • Attentamente pianificare ed eseguire una strategia di indicizzazione con strumenti quali l'ottimizzazione guidata motore di database o DTA indice viste a gestione dinamica (DMV) e indice utilizzo DMV mancanti.

1. Sapere dove trovare informazioni

Con un elenco di attività i è essenziale conoscere a chiamata che uscire dall'applicazione e cercare informazioni. È necessario conoscere le limitazioni e accettare è impossibile sapere tutto su SQL Server. Non ha senso in nessuno la testina contro un muro e sprecare tempo importanti quando qualcuno circolazione può agevolare l'attività o il problema.

Il Nr. 1 fonte di informazioni su SQL Server è Documentazione in linea , che è possibile scaricare e installare localmente o ricerca in linea in MSDN. Documentazione in linea è ideale per la ricerca di sintassi, ma se si dispone di una domanda sulle procedure più complessa o sta tentando di risolvere un problema, la cosa migliore da fare è registra una domanda in un forum in linea. Esistono molti forum di SQL Server su MSDN e siti di community diffusi come Centrale di SQL Server.

Un altro metodo rapido per trovare informazioni consiste di interagire con la community di SQL Server su Twitter. Inserire la domanda #sqlhelp hash-tag, che controllano molti esperti SQL (incluso me).

Partecipare a una conferenza specifici di SQL Server, ad esempio annuale Summit di community PASS, le connessioni server SQL supporta il testo annuale o sabato più frequenti di SQL. Seguono che alcuni dei blog più eseguite da SQL Server esperti della comunità. È possibile ottenere una buona idea di blog in cui sono attivi e vale la pena di seguito dalle valutazioni del blog gestiti da Thomas LaRock collega-MVP.

Potrebbe essere sovraccarico e l'overload, ma se si può in alcuni sforzo aggiuntivo per seguire i seguenti suggerimenti, trovare che i grandi vantaggi. Il sistema eseguirà più uniforme, potrà essere meglio organizzata, si avrà più pace di ricordare, e sarà più esperto DBA.

Paul Randal

Paul s. Randal è direttore gestione di SQLskills.com, un direttore regionale Microsoft e MVP per SQL Server. Ha lavorato nel team SQL Server Storage Engine in Microsoft dal 1999 al 2007. Ha scritto il comando DBCC CHECKDB/repair per SQL Server 2005 ed era responsabile di Core Storage Engine durante lo sviluppo di SQL Server 2008. Randal è un esperto di ripristino di emergenza, disponibilità elevata e la manutenzione del database ed è un normale relatore a conferenze in tutto il mondo. Il suo blog all'indirizzo SQLskills.com/blogs/paul ed è possibile trovare lui Twitter in Twitter.com/PaulRandal.

Contenuto correlato