DOMANDE E RISPOSTE SU SQLBackup compressione, il reindirizzamento del client con mirroring e altro ancora

Paul S. Randal

D si prevede di eseguire l'aggiornamento la maggior parte dei nostri server a SQL Server 2008 e una delle caratteristiche di desiderato Avanti per inserire in produzione è compressione backup.So che È possibile attivarla per impostazione predefinita per tutti i database su ciascun server, ma anche HO sentito che è possibile non si desidera questo scopo.Non sono che perché non desidera la funzionalità attivata per impostazione predefinita, mentre sembra che È stato ottenuto niente da perdere.Possibile è spiegare soluzione dietro ciò che HO sentito?

la risposta è il preferito perennial : dipende.Consente di assegnare concetti per illustrare.

Il punto chiave da considerare è il rapporto di compressione che ciascun backup di database avrà quando è attivata la compressione backup.Il rapporto di compressione tra nulla da compressi mediante qualsiasi algoritmo è determinato dai dati effettivi da compressi.

Stai cercando suggerimenti per SQL Server?

Per suggerimenti su SQL Server, visitare ilSuggerimenti di TechNet Magazine SQL Serverpagina.

Per ulteriori suggerimenti su altri prodotti, visitare ilIndice TechNet Magazine suggerimenti.

Dati casuali (integer piccoli valori, ad esempio) verrà non comprimere molto bene, in modo che il contenuto delle tabelle e gli indici nel database determinerà, nella maggior parte dei casi, il rapporto di compressione che può essere raggiunta.

Ecco alcuni esempi di quando compressione backup non può produrre un rapporto di compressione elevato:

• Se il database contiene dati trasparente crittografia abilitata, il rapporto di compressione saranno molto basso poiché i dati da compressi sono valori di piccole dimensioni casuali.
• Se la maggior parte dei dati nel database è crittografato a livello di colonna, quindi il rapporto di compressione sarà basso, nuovamente poiché la crittografia di colonna randomizes essenzialmente i dati.
• In caso di compressione dei dati abilitata la maggior parte delle tabelle del database, quindi il rapporto di compressione sarà basso, la compressione dei dati già principalmente sono compresso in genere effetto minimo.

Nel caso quando il rapporto di compressione è basso, il problema non è il rapporto basso ma il fatto che risorse della CPU sono utilizzate per eseguire l'algoritmo di compressione per nessun profitti.Indipendentemente da come un blocco di dati può essere compressi, risorse della CPU vengono sempre utilizzate per eseguire gli algoritmi di compressione e decompressione.

In tal caso è necessario controllare come ogni database Comprime di un backup prima di decidere di utilizzare compressione backup per il database in qualsiasi momento.In caso contrario si possono eventualmente essere sprecare risorse della CPU.Questa è la base per che cosa è sentito.

Per riassumere, se la maggior parte dei database verrà beneficiano di compressione di backup, è opportuno attivare la compressione backup a livello del server e alcuni processi di backup specificatamente utilizzare l'opzione WITH NO_COMPRESSION vengono modificati manualmente.In alternativa, se la maggior parte dei database non verrà beneficiare di compressione di backup, opportuno lasciare compressione backup disattivato a livello del server e alcuni processi di backup specificatamente utilizzare l'opzione WITH COMPRESSION vengono modificati manualmente.

Anno ultimo D viene aggiornato i database per avere il mirroring del database in modo che se si verifica un errore, è possibile failover al mirror e continua l'applicazione.Mentre si sono stati progettando il sistema, abbiamo practiced eseguire il failover del database e tutti gli elementi utilizzati correttamente.Ultima settimana avevamo un errore reale e si è verificato il failover del database, ma tutte le transazioni di applicazione interrotta e l'applicazione non connettersi al server di failover.In futuro, come È possibile impostare SQL Server in modo che non elimina le connessioni dell'applicazione durante il failover in modo che le transazioni possono continuare?

AConsenti a questa suddivisione in due parti, come le applicazioni possono gestire failover e come gestire il reindirizzamento del client con il mirroring del database.

Quando un failover si verifica utilizzando uno delle tecnologie di alta disponibilità disponibili con SQL Server, la connessione di client al server viene interrotta e le transazioni in corso vengono perse.Non è possibile eseguire la migrazione una transazione in corso tra i server (in una situazione di failover o).In base sulla tecnologia di elevata disponibilità, la transazione in corso oppure verrà non esistere affatto sul server failover o saranno disponibili come una transazione corso ma verrà eseguito il rollback come parte del processo per portare in linea il database sul server di failover.

Con riferimento al database mirroring, fornito continuamente i record del log delle transazioni dal server principale al server mirror è in genere quest'ultimo caso, le transazioni in corso vengono sottoposte a rollback come parte di portare il database mirror in linea del nuovo principale.

Pertanto, sono due cose che un'applicazione deve essere in grado eseguire correttamente quando in esecuzione in un server con la possibilità di disporre di failover a un altro server:

1. Deve essere in grado di gestire correttamente la connessione al server l'eliminazione e quindi provare a riconnettersi dopo un intervallo di tempo piccole.
2. Deve essere in grado di gestire correttamente una transazione da interrompere e quindi ripetizione la transazione dopo una connessione è stabilita con il server failover (possibilmente mediante un gestore delle transazioni mid-tier).

Il solo alta disponibilità tecnologia qui che non richiede modifiche del client in modo specifico per consentire il reindirizzamento della connessione client dopo un failover è il clustering di failover.I client connettersi a un nome del server virtuale e vengono reindirizzati in modo trasparente a qualsiasi nodo del cluster fisico è attivo.

Con tecnologie di alta disponibilità, ad esempio la distribuzione dei log e di replica, il server di nome del server di failover è diverso, che significa che manuale dopo un failover è necessario il reindirizzamento di connessioni client.Questo reindirizzamento manuale può essere eseguito in diversi modi di seguito:

• È possibile impostare come hardcoded il nome del server failover in client in modo che vengono eseguiti i tentativi di riconnessione al server di failover.
• È possibile utilizzare bilanciamento del carico di rete con un 100/0, 0 e 100 configurazione, che verrà quindi consentire la connessione alla quale passare al server di failover.
• È possibile utilizzare qualcosa come un alias del nome server o passa le voci in una tabella DNS.

Con il mirroring del database, una di queste opzioni funzionerà.Ma anche il mirroring del database dispone di funzionalità direzione client integrato.La stringa di connessione del client è possibile specificare in modo esplicito il nome del server mirror e se non è possibile contattare il server principale, mirror verrà quindi automaticamente ritentato.Questo processo è noto come il reindirizzamento esplicito.

Se la stringa di connessione client non può essere modificata, il reindirizzamento implicito potrebbe essere possibile se il server non riuscito a questo punto viene eseguito come server mirror.Tutte le connessioni a esso verranno reindirizzate automaticamente al nuovo principale, ma questo funziona solo se viene eseguito il server mirror.

SQL Server 2005 white paper"Implementazione dell'applicazione di failover con mirroring del database"vengono illustrate le opzioni in modo più dettagliato.

D quando viene aggiornato a SQL Server 2005, riprogettato è nostro grandi tabelle per essere partizionata in modo che è possibile sfruttare partizionata manutenzione e il meccanismo di finestra scorrevole.Questo descritto nella RATA agosto 2008 "Partizionamento, verifiche della coerenza e altro ancora").Ma è stato verificato un problema.In alcuni casi le query concorrenti applicazione verificano blocco tra l'intera tabella durante le query non anche l'accesso le partizioni stesse.HO sentito che SQL Server 2008 risolvere questo problema, può è necessario spiegare come È possibile evitare questo blocco?

Figura 1 analisi blocchi in una tabella partizionata

A che il problema in visualizzazione è causato da un meccanismo denominato escalation dei blocchi.SQL Server consente di acquisire blocchi in dati per proteggerli mentre una query è la lettura o la scrittura dei dati.È possibile acquisire blocchi su intere tabelle, le pagine del file di dati o singola tabella e indice righe e ogni blocco occupa memoria un po'.

Se una query provoca un numero eccessivo di blocchi essere acquisiti, SQL Server può decidere di sostituire tutti i blocchi sulle righe o le pagine in una tabella con un singolo blocco sull'intera tabella (la soglia, quando questo viene eseguita, è di circa 5.000 blocchi, ma l'algoritmo esatta è complessa e configurabile).Questo processo è chiamato blocco escalation.

In SQL Server 2005, se query A esecuzione su una singola partizione di una tabella e provoca sufficiente blocchi da eseguire per avviare l'escalation dei blocchi, quindi l'intera tabella viene bloccata.Questo può impedire la query B funzionare in una partizione diversa della stessa tabella.Di conseguenza, la query B è bloccata finché non viene completata la query e relativi blocchi verranno ignorati.

In SQL Server 2008, è stato migliorato il meccanismo di escalation dei blocchi per consentire una tabella escalation di blocco a livello di partizione.Utilizzando l'esempio precedente, questo significa che l'escalation di blocco causati da un solo necessario bloccare la query singola partizione A è utilizzando, anziché l'intera tabella query.

Query B sarà in grado di operare in un'altra partizione senza bloccato.La query B può anche attivare blocco escalation, che viene quindi bloccare solo la partizione di query che funziona B, anziché l'intera tabella.

Questo modello di escalation dei blocchi è possibile impostare utilizzando la sintassi seguente:

ALTER TABLE MyTable SET (LOCK_ESCALATION = AUTO);
GO

Questa sintassi indica Gestione SQL server Blocca utilizzare escalation di blocco a livello di partizione se la tabella è partizionata e ampliamento normale blocco a livello di tabella se la tabella non è partizionata. Il comportamento predefinito consiste nell'utilizzare escalation di blocco a livello di tabella. Dovrà prestare particolare attenzione durante l'impostazione di questa opzione, come possono causare deadlock base sul comportamento delle query.

Ad esempio, se perché le query A e B entrambi provocano escalation dei blocchi in diverse partizioni di una tabella e quindi ogni tentano accedere la partizione che ha bloccato l'altre query, una delle query verrà interrotto dal processo di monitoraggio di deadlock.

Nella figura viene illustrato un esempio di eseguire la query alla vista di catalogo di sistema di sys.partitions (il primo set di risultati e sys.dm_os_locks DMV (il secondo set di risultati per esaminare i blocchi gestiti per le query su una tabella partizionata in cui escalation di blocco a livello di partizione sia avvenuta. In questo caso, esistono due blocchi esclusivi di livello di partizione (i blocchi HOBT nell'output, ma i blocchi di tabella (i blocchi OBJECT nell'output non sono esclusivi, pertanto più query può accedere partizioni anche se è stata eseguita escalation dei blocchi. Si noti che l'ID di risorsa per questi blocchi di due partizioni corrispondere la partizione ID per le prime due partizioni della tabella dell'output del sys.partitions.

All'inizio dell'anno È blogged sull'con script di esempio come blocco a livello di partizione escalation funzionae la possibilità di blocchi critici (deadlock). L'argomento nella documentazione in linea di SQL Server 2008 denominata" Blocco nel motore di database"presenta una spiegazione approfondita del tutti gli aspetti di blocco in SQL Server 2008.

D uno dei nostri server era alcuni problemi con il disco contenente il log delle transazioni per un database e il database è diventato sospetto. Ultimo backup completo è di cinque settimane fa e doveva richiedono troppo tempo per ripristinare tutti i backup di log, troppo. Non è compreso ore quando si è verificato il problema, pertanto è ricostruire il log delle transazioni interrotte evitare i tempi di inattività. In alcuni casi, ciò potrebbe causare problemi. Ma se non è stato accede ai dati, quindi RITENGO che siamo sicuri. Si ha fare la cosa destra?

A la risposta semplice è che il tempo solo che necessario considerare la ricostruzione di un registro delle transazioni non risulta è possibile ripristinare dal backup. Sebbene sia di pericoli della ricostruzione di un registro delle transazioni (per i lettori che hanno, non, vedere il blog di registrare " Ultima utilizzate utenti prima tentano in corso..." il fatto che il database ha cessato sospetto significa che non è riuscito durante il recupero, all'esecuzione del ripristino arresto anomalo del sistema o durante il rollback di una transazione. Ciò significa che è la possibilità di reale di danneggiamento dei dati nel database.

Anche se il problema si è verificato durante il periodo di attesa, ha è considerare i processi pianificati e le attività in background? Un processo di manutenzione Impossibile sono stati in esecuzione è stata ricostruzione o riorganizzazione di un indice cluster quando il registro è diventato danneggiato. Un'attività in background potrebbe sono in esecuzione pulitura fantasma in pagine di un heap o indice cluster. Uno di questi valori, ad esempio, Impossibile sono stato apportare modifiche a strutture di indice cluster che, se non correttamente rollback, potrebbero causare un danneggiamento il database e di possibile perdita di dati dei.

La riga inferiore è che la ricostruzione di un registro delle transazioni deve essere sempre l'ultima risorsa assoluto in qualsiasi scenario di ripristino d'emergenza a causa il rischio di enorme di causare ulteriori danni e la perdita dei dati. Almeno, è consigliabile eseguire un DBCC CHECKDB completo di tale database per verificare la presenza di eventuali problemi di danneggiamento.

Passare, è consigliabile modificare la strategia di backup in modo da sono in grado di eseguire ripristini tempi e non è necessario ricorrere alle misure bruschi, ad esempio la ricostruzione del log delle transazioni. I passaggi necessari per progettare una strategia di backup si estendono oltre l'ambito di questa colonna, ma prevede di coprire in questo argomento in un articolo full-length funzionalità a un certo punto dell'anno prossimo. <A pertanto sempre ottimizzata.

S Paul Randal è il responsabile gestione SQLskills.come un MVP di SQL Server. HeHe collaborato nel team motore di archiviazione di SQL Server in Microsoft da 1999 a 2007. Paul scritto DBCC CHECKDB e ripristino per SQL Server 2005 ed era responsabile per il motore di archiviazione principale durante lo sviluppo di SQL Server 2008. Paul è un esperto di ripristino di emergenza, un'elevata disponibilità e manutenzione dei database ed è in un normale relatore a conferenze di tutto il mondo. Blog ha in SQLskills.com/blogs/paul.