Domande e risposte su SQL: Dati dinamici e ripristino di emergenza
Soluzioni di questo mese per il successo SQL eseguite nella gamma dall'espansione di un database tempdb e clustering di un problema per i piani di ripristino di emergenza half-baked.
Paul S. Randal
Riempire lo spazio
D. Uno dei server di produzione per il quale mi assumo la responsabilità di presenta un problema. Tempdb Aumenta molto grande di tanto in tanto. Si tratta di un problema relativamente nuovo. Non vedo alcuna differenza nel numero di connessioni al server o l'utilizzo della memoria. Come è possibile monitorare la situazione per determinare cosa utilizza tutto lo spazio di tempdb?
R. Esistono numerose ragioni potrebbe aumentare dell'utilizzo di tempdb:
- Utilizzo del sistema di controllo delle versioni (per l'isolamento dello snapshot o operazioni di indice in linea, ad esempio) potrebbe causare l'archivio versione nel database tempdb a crescere.
- Impossibile modificare un piano di query a causa delle statistiche non aggiornate, che a sua volta può provocare un operatore del piano di query che generano in una fuoriuscita di grandi dimensioni di memoria in tempdb.
- Qualcuno ha distribuito nuovo codice dell'applicazione che utilizza le tabelle temporanee per i dati dell'archivio parzialmente elaborato.
Tutto ciò è, esistono alcuni semplici metodi per tenere traccia cosa sta succedendo. La prima cosa, si è esaminare l'utilizzo di spazio di tempdb globale con sys.dm_db_file_space_usage la vista a gestione dinamica (DMV). Se si acquisiscono i risultati di questa DMV ogni 30 secondi, ad esempio, sarà in grado di verificare se l'utilizzo di uno spazio aggiuntivo proviene dall'archivio versione, gli oggetti utente o gli oggetti creati per facilitare l'elaborazione delle query.
In questo caso l'archivio versione occupa tutto lo spazio, consentono di approfondire ulteriormente utilizzando il sys.dm_tran_top_version_generators DMV. È necessario metterla in join con sys.partitions e sys. Indexes per ottenere informazioni realmente utili fuori di esso, ma che consentirà di stabilire le tabelle che la maggior parte delle versioni da generare.
Se si tratta di qualsiasi altro occupare spazio, consentono di approfondire mediante l'acquisizione di risultati da sys.dm_db_task_space_usage a una frequenza simile. Quindi unire le DMV con sys.dm_exec_requests per scoprire quali le connessioni e le query occupano spazio.
Se si scopre essere una lunga stored procedure, è necessario instrumentare la procedura per l'output periodicamente la quantità di spazio di tempdb che viene utilizzato in modo che è possibile lavorare sui quali istruzioni all'interno della routine che sono le dovute. Sono stato costretto a scopo di questo più volte sui sistemi client.
È possibile trovare molte più informazioni sull'utilizzo di queste DMV nel white paper, "utilizzo di tempdb in SQL Server 2005." (Questo documento si applica anche alle versioni più recenti di SQL Server).
Cluster valido
D. Mi hanno posto per progettare lo schema per un database in cui verrà archiviati i dati per una nuova applicazione. Ho letto tutti i tipi di suggerimenti relativi alla scelta di chiavi di indice cluster "buono" per le tabelle. Spiegare che cosa è una chiave di indice cluster "buono" e perché è tanto importante?
R. Si tratta di una domanda complessa e quasi impossibile rispondere globalmente qui. In poche parole, una chiave di indice cluster "buono" è quello che è stato scelto con attenzione per ridurre a icona una riduzione delle prestazioni e lo spazio inutilizzato. Sono le quattro qualità di una chiave di indice cluster buona: stretto, statico, univoco e una crescente:
- Restringere (occupare byte con il minor numero possibile): tutti i record di indice non cluster includono la chiave di indice cluster. Più grande è, occupano più informazioni duplicate di spazio in indici non cluster.
- Statico (non modificabili): le modifiche ai valori di chiave sono costose. SQL Server è un aggiornamento della chiave come un'eliminazione + operazione di inserimento (vedere il mio blog post qui), e ogni volta che viene aggiornata una chiave di indice cluster, tutte le righe corrispondenti in indici non cluster inoltre devono essere aggiornati. Modifiche principali possono causare lo spazio vuoto nelle pagine del file di dati se tale posizione della chiave dell'indice non viene utilizzato nuovamente.
- Unique: questo modo si evita che SQL Server di aggiungere una colonna nascosta di quattro byte per valori di chiave duplicati "uniquify", rendendo quindi la chiave più ampia.
- Sempre: il modello di inserimento di nuovi record comporta la creazione di inserimenti casuali nell'indice cluster che può causare costose operazioni di divisione di pagina. Di conseguenza una frammentazione logica e lo spazio inutilizzato nelle pagine del file di dati.
Date queste qualità per una chiave di indice cluster valida, non vi è una chiave naturale che si adatta (ad esempio, una derivata dai dati di tabella), pertanto è necessario utilizzare una chiave surrogata (ad esempio, una colonna della tabella artificiale). Una colonna BIGINT IDENTITY è un esempio di una chiave surrogata buona. Leggere ulteriori spiegazioni dettagliate e una giustificazione della categoria di blog di Kimberly Tripp Chiave di Clustering.
Preparare il peggiore
D. Nel quadro dei terremoti recenti in Nuova Zelanda e Giappone, ho esaminato il piano di ripristino di emergenza e trovare che realmente è obsoleto. Ho state cercando con esito negativo ottenere la nostra società per ristrutturare e test del piano. Semplicemente non pensano che avremo sempre una situazione di emergenza. Posso avere alcuni suggerimenti su come effettuare tale gestione?
R. Sono contento ascoltare in modo proattivo è l'analisi della strategia di ripristino di emergenza nel quadro di tali catastrofi di recente. Molte aziende sono sottovalutare e hanno spesso la convinzione che descrivono la domanda. Sebbene su larga scala calamità naturali sono relativamente rari, più localizzati problemi quali la creazione di incendi o interruzioni dell'alimentazione sono relativamente comuni e una società non deve presupporre che è immune per guasti casuali.
Anche se non è possibile ottenere gestione sulla parte degli utenti, è una grande quantità di test è possibile effettuare personalmente, come ripristino di copie dei database dai backup. Si verifica l'integrità dei backup e la strategia di backup e può garantire che i tempi di ripristino soddisfino i requisiti di tempo massimo di inattività consentito per un determinato database. Molto spesso, questo è il primo problema riscontrato durante i test strategia di ripristino di emergenza. Volumi di dati con il tempo e il ripristino commensurately ora aumenta.
Altre parti della strategia di ripristino di emergenza sono molto più difficili da verificare personalmente, ad esempio il failover con una relazione o in un cluster di failover di mirroring del database. Entrambi questi richiedono un tempo di inattività, sia per eseguire il failover e failback.
Per quanto convincente management è interessato, chiedere loro se essi sarebbe piuttosto individuare la strategia di ripristino di emergenza non funziona durante un test pianificato con tutti i personale disponibili per semplificare il ripristino o situazioni di reale emergenza alle 02. in un giorno festivo quando è solo uno staff minimo-hand.
Ci sono moltissime altamente pubblicizzati incidenti delle società subire interruzioni perché una strategia di ripristino di emergenza era insufficiente. Gestione desidera di loro azienda di quella successiva, le notizie? Che può sembrare melodramatic, ma è un punto giusto.
Ripristino di emergenza è ridurre al minimo il costo per la società e i suoi clienti. Se i client può essere causa di un'interruzione o si perdono fede nella capacità della società per recuperare rapidamente, possono prendere in un'altra azienda. Ciò ovviamente ha un impatto negativo la linea inferiore.
Come tecnici, è necessario chiedere gestione pensare di catastrofi IT per quanto concerne l'impatto finanziario sull'azienda. Ho trovato questo è una tattica efficacia in inducendo management di investire tempo e denaro di rinnovo e verifica della strategia di ripristino di emergenza. Ulteriori informazioni su questo nel mio post di blog recenti qui.
Riduzione dei costi
D. Vorrei veramente utilizzare la funzionalità di compressione dei dati in SQL Server 2008 per ridurre i costi di archiviazione, ma ho letto è solo per i data warehouse e se si tenta di utilizzarlo in una transazione in linea (OLTP) sistema di elaborazione, saranno comportano problemi di prestazioni. Questa condizione è vera?
R. Risposta corretta che la funzionalità di compressione dei dati è stato inizialmente previsto per l'utilizzo di data warehouse. Compressione dei dati riduce le dimensioni dei record di tabelle e indici. Ciò significa che i record più adattano in una pagina di file dati di 8 KB e pagine a file in modo meno i dati necessari per memorizzare i dati sul disco. Questo si traduce in dimensioni minori requisiti di spazio su disco per il database contenente i dati compressi, che a sua volta possono portare a significativi risparmi sui costi è richiesto meno spazio di memoria di livello aziendale.
Il compromesso, naturalmente, è che i dati devono essere decompresso prima dell'uso. I dati non viene decompresso quando viene letto nel pool di buffer di SQL Server (in memoria cache delle pagine del file di dati). Esso viene decompresso solo quando è effettivamente necessario per soddisfare una query. Decompressione utilizza le risorse della CPU, in modo che un compromesso è l'utilizzo dello spazio nei confronti delle risorse della CPU.
Un tipico del data warehouse ha una grande quantità di dati (pensare centinaia di gigabyte a più terabyte). Il modello di accesso per tali dati è in genere una grande quantità di dati letti nel pool di buffer, elaborata una sola volta e quindi non utilizzato nuovamente per molto tempo sufficiente rimosso dalla memoria.
Con questo criterio di accesso, è opportuno ridurre al minimo il numero di operazioni dei / O lettura comprimendo i dati di dimensioni inferiori. Ciò richiederebbe meno pagine di file di dati di SQL Server per memorizzare e meno operazioni dei / O leggere queste pagine. Ciò comporta in genere più rapida realizzazione di questi tipi di query. Pertanto, un altro svantaggio è velocità delle query nei confronti delle risorse della CPU (per la decompressione dei dati).
Se si considera un carico di lavoro OLTP, è in genere molto più elevata volatilità dei dati rispetto a un data warehouse. Ciò significa che se si utilizza la compressione dei dati, si sarà comportano un elevato utilizzo della CPU a causa di compressione dei dati inseriti o aggiornati e la decompressione costante di dati da leggere. È possibile esaminare più attentamente i compromessi quando si considera la compressione dei dati per un database OLTP.
Tornando alla domanda, anche se la compressione dei dati originariamente era mirata di data warehouse, molti clienti di SQL Server hanno trovato che hanno una grande quantità di CPU "head room" sui propri server. Può permettersi l'ulteriore utilizzo della CPU e potenzialmente più lunghi tempi di esecuzione di query per ottenere il risparmio di spazio di grandi dimensioni e risparmio sui costi di archiviazione associati all'utilizzo di compressione dei dati. Compressione dei dati possibile essere utile per gli ambienti OLTP. È sufficiente accertarsi di che valutare i costi di prestazioni e risparmio di spazio per il carico di lavoro prima di avviare la produzione.
Per il risparmio di spazio, è possibile utilizzare la procedura sp_estimate_data_compression_savings per avere un'idea dei risparmi percentuale che è possibile prevedere. È importante effettuare questa operazione perché attivare (o disattivare) la compressione dei dati avviene mediante un'operazione di ricostruzione. Ciò può essere costoso in sé. Per ulteriori informazioni, vedere il white paper, "la compressione dei dati: Strategia, pianificazione della capacità e le procedure consigliate. "
.jpg)
**S. Paul Randal**è managing director di SQLskills.com, un Microsoft regional director e un Server SQL MVP. Ha lavorato nel team SQL Server Storage Engine in Microsoft dal 1999 al 2007. Egli ha scritto l'istruzione 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, alta disponibilità e la manutenzione di database ed è un normale relatore a conferenze in tutto il mondo. Un blog he al /blogs/paul, e che è possibile trovarlo nei movimenti in twitter.com/PaulRandal.