SQL Q & A: Backup e configurazione
SQL Server è una piattaforma potente, ma richiede eleganza per quanto concerne le impostazioni del log delle transazioni e altre problemi di configurazione.
Paul s. Randal
Registri transazioni XXXL
D: Nostro prodotto utilizza SQL Server per memorizzare i dati. Tanto spesso, si rilascia una nuova versione del nostro prodotto include uno script di aggiornamento per eseguire sul database. Come abbiamo avremmo test script di aggiornamento più recente su un database di test significativi, il file di registro delle transazioni è più di 40 GB. Si desidera impedire la crescita così elevato di file di registro. Quali sono le opzioni? È necessario utilizzare il modello di recupero completo per ragioni di ripristino di emergenza.
R: Per iniziare con è grande che si sta test rispetto ai dati rappresentativi del cliente. Molte volte, vedo fornitori di applicazioni a più livelli, questi tipi di script su piccoli insiemi di dati di test e rilascio ai clienti, che viene quindi eseguito in tutti i tipi di problemi di produzione. Potrà rispondere alla domanda come se l'utente. È quindi possibile tradurre nel contesto dei propri clienti.
Ad esempio che necessario mantenere con il modello di recupero completo. Ciò implica già sta prendendo transazione i backup del log e non hai problemi generali di log delle transazioni aumenta all'esterno del controllo. Questa è una buona, accettando i backup del log delle transazioni è l'unica operazione che consente di cancellare dopo avere eseguito il commit transazioni del log delle transazioni. (Per informazioni in merito, vedere technet.microsoft.com/magazine/2009.02.logging , che spiega come funziona il log delle transazioni e dei vari modelli di recupero influenzano il comportamento.)
La frequenza con cui si esegue il backup del log delle transazioni che detto, è una cosa che indicherà rapidità può deselezionare e non aumentare le dimensioni del log delle transazioni. Ad esempio, se il processo di backup regolare esegue un backup del log delle transazioni ogni 30 minuti, il file di registro delle transazioni deve essere sufficiente per contenere la maggior parte dei dati del log delle transazioni che possono essere generate in un periodo di 30 minuti. In caso contrario, verrà incrementato.
Se lo script di aggiornamento viene eseguito in 60 minuti, che potrebbe scoprire a 20 GB di log delle transazioni generati ogni 30 minuti, in modo che il file di registro delle transazioni dovranno essere 20 GB. Che è probabilmente comunque troppo grande, pertanto sarà necessario eseguire il backup del log delle transazioni più frequentemente durante l'esecuzione dello script di aggiornamento. Deselezionare più frequentemente e impedire la crescita così grande consentirà il log delle transazioni. Ci aveva una situazione simile a una posizione del client e terminato di eseguire un backup del log delle transazioni una volta al minuto per diverse ore durante l'esecuzione di uno script simile in un database di grandi dimensioni.
Una cosa da ricordare è che queste transazioni “ extra ” log backup fanno parte della catena di backup del registro e sono necessari per il ripristino di emergenza. Assicurarsi che tutti abbiano nomi significativi e non vengono eliminati.
C'è un altro fattore da considerare: Che cos'è la più grande singola transazione si verifica come parte del processo di aggiornamento che è stato progettato Il log delle transazioni può cancellare solo se i record del log da tutte le transazioni completate (che potrebbe essere oversimplifying un po', vedere l'articolo citato in precedenza per ulteriori dettagli). Ciò significa che una transazione a esecuzione prolungata non consentono il registro deselezionare, anche se il log delle transazioni viene backup eseguire il backup del log delle transazioni generati.
Se lo script di aggiornamento contiene una transazione che richiede 15 GB di spazio di log, il file di registro delle transazioni dovranno essere almeno 15 GB per contenere l'intera transazione finché non esegue il commit. Se questo è il caso, indipendentemente dalla frequenza con cui è possibile eseguire un backup del log delle transazioni non cancellare il log delle transazioni. È in questo caso l'unico modo per suddividere la transazione di grandi dimensioni piccole, se possibile.
Tenere presente questo: le dimensioni del log delle transazioni necessaria per l'esecuzione dello script di aggiornamento verranno determinata la frequenza dei backup del log delle transazioni e le dimensioni della singola transazione più grande che si crea.
Configurazione Conundrum
D: Ci stiamo provisioning alcuni nuovi direct attached storage per uno dei nostri server di database e si desidera assicurarsi che abbiamo attentamente tutte le opzioni e ottenere la configurazione corretta. È possibile spiegare le varie impostazioni di configurazione che è opportuno essere a conoscenza di come dal punto di Vista riguarda SQL Server?
R: Esistono innumerevoli impostazioni e opzioni di configurazione quando il provisioning di archiviazione, pertanto è preferibile implicano un amministratore archiviazione dedicato. Esistono certamente alcune opzioni con cui un amministratore di SQL Server dovrebbe preoccuparsi e assicurarsi di impostare in modo appropriato.
Il primo è il livello RAID sottostante. I diversi livelli RAID hanno diversi compromessi dal punto di vista sono riguardano le prestazioni e la ridondanza. Ad esempio, la configurazione RAID più economico che offre comunque alcuni ridondanza è RAID-5, ma questa configurazione può gestire solo un errore dell'unità singola (a meno che l'utilizzo di RAID-6, o configurare le unità di riserva a caldo) e talvolta può ridurre le prestazioni dei carichi di lavoro pesante di scrittura, a seconda di quante unità sono nella matrice.
RAID 10 fornisce ridondanza ottimale, ma è più costosa. La capacità complessiva di matrice è più della metà della capacità totale delle unità costitutive. Una trattazione esauriente dei vari livelli RAID viene presentata nell'Appendice A del white paper TechNet “ di Progettazione dell'archiviazione database fisico. ”
Altri fattori principali da considerare sono la dimensione di striping RAID, la dimensione dell'unità di allocazione NTFS (la dimensione del cluster) e l'allineamento di partizione del disco. Tutti questi fattori possono ridurre drasticamente le prestazioni se non impostato correttamente. Il più importante è l'allineamento di partizione disco per i volumi del disco creato utilizzando Windows Server 2003. Per impostazione predefinita, che non corrisponde alle dimensioni di stripe RAID comuni di 64 KB (o sue multiplo) utilizza un allineamento 31,5 KB. Pertanto, ogni I/O presenta essenzialmente leggere o scrivere due stripe RAID per soddisfare l'i/O. Ovviamente causando una riduzione notevole delle prestazioni.
Per impostazione predefinita, Windows Server 2008 utilizza un allineamento di 1 MB. I volumi creati in Windows Server 2003 e aggiornato per l'hosting di Windows Server 2008 non sono loro allineamento cambiato, in modo che potrebbe ancora essere interessati. Risoluzione di questo problema indica che la formattazione di volumi, ma l'incremento delle prestazioni spesso renderla un passaggio utile.
Una descrizione dettagliata di questi è realmente esulano dall'ambito di questo articolo, ma sono disponibili ulteriori dettagli (e collegamenti per ulteriori informazioni) nel post del blog “ are compensa la partizione del disco, RAID stripe dimensioni e unità di allocazione NTFS corrette? ”
Quando il provisioning di un nuovo archivio, è consigliabile per test di stress e test di prestazioni prima di avviare un carico di lavoro di produzione. Test di stress consente di svuotare i problemi di configurazione che potrebbero causare la perdita di dati o i tempi di inattività. Consente di verificare che il nuovo archivio offre la capacità di I/O del carico di lavoro di test delle prestazioni è necessario. Microsoft dispone di strumenti gratuiti per queste informazioni, che è possibile ottenere ulteriori informazioni nel white paper “ di I/O Pre-Deployment consigliate. ”
Mirroring, il mirror
D: È poco chiaro la natura del server di controllo del mirroring durante la configurazione di mirroring del database. Come potente server di controllo del mirroring è necessario che sia? Esso dipende il numero di database per il quale non failover? È importante in cui datacenter si posiziona il server di controllo del mirroring? Si desidera assicurarsi di ottenere la massima disponibilità per i database con mirroring.
R: Il ruolo del server di controllo del mirroring è uno degli aspetti più confusione di qualsiasi sistema di mirroring del database. Il server di controllo del mirroring in una configurazione di mirroring del database sincrono esiste unicamente per facilitare un failover automatico nel caso in cui il server principale non è più disponibile.
Il server principale invia continuamente i record del log delle transazioni al server mirror, mai il server di controllo del mirroring. Il server principale, mirror e server di controllo loro ping ogni secondo come parte del meccanismo di rilevamento degli errori automatico. Se il server mirror determina che non è possibile comunicare con il server principale per un motivo qualsiasi, non può avviare un failover automatico solo se autorizzato dal server di controllo del mirroring che inoltre Impossibile comunicare con il server principale. Se accetti i due server, che costituisce un quorum e del server mirror avvia un failover automatico. Se un server di controllo del mirroring non è presente, non può essere presente un quorum e un failover automatico non è possibile.
Pertanto, il server di controllo del mirroring esiste unicamente per formare un quorum. Non avviare failover o riprodurre qualsiasi parte che ospita il database con mirroring. In genere il quorum esistente tra il server principale e mirror.
Come ad alcuna elaborazione sul server di controllo del mirroring, non è necessario essere un potente server. Grado di ospitare qualsiasi edizione di SQL Server, incluso gratuitamente SQL Server Express Edition. Non è previsto alcun limite al numero di sessioni per cui una determinata istanza di SQL Server può fungere da server di controllo di mirroring del database.
Il server di controllo del mirroring meglio viene inserito in un datacenter separato dal server principale o mirror. Tuttavia, molte aziende non dispongono di tre centri dati, in modo che la domanda è se il server di controllo del mirroring deve essere inserito con il server mirror o con il server principale.
Quando sono disponibili solo due centri dati, il server di controllo del mirroring deve essere inserito sempre con il server principale. Il motivo è con formando un quorum. Se il server mirror e server di controllo sono co-located e interrompe il collegamento di rete al server principale, un quorum formerà tra il testimone e mirror e del server mirror avvierà un failover.
Il server principale, che potrebbe non avere alcun problema affatto, avranno il database principale non in linea quando perde il quorum. Si presuppone che il mirror eseguirà un failover in questo caso. Per evitare questo problema, riducono i server principale e testimone consente l'identità di mantenere il quorum con testimone nel caso di un errore di rete. Il database principale rimane disponibile.
Il server di controllo del mirroring è completamente facoltativo, ma non vi è alcuna possibilità di un failover automatico, e pertanto la massima disponibilità del database in mirroring, ovvero senza uno. Il mirroring del database funziona allo stesso modo in ogni altro modo. Se un server di controllo del mirroring è configurato ma non è disponibile per qualche motivo, non è perdita di funzionalità, tranne la possibilità di eseguire un failover automatico di mirroring.
È inoltre possibile avere due mirroring per una sessione di mirroring del database. L'unico modo per aggiungere ulteriore ridondanza al ruolo del server di controllo del mirroring è che l'istanza SQL Server di controllo del mirroring ospitato in un cluster di failover. È possibile ottenere ulteriori informazioni sulle configurazioni nel TechNet white paper “ mirroring del database in SQL Server 2005 . ” di mirroring del database
.jpg)
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.