SQL Q & A: Spostamento, ottimizzazione delle prestazioni, backup e mirroring dei database

  • Articolo

Paul S. Randal

Nuova matrice mobile Day

**D:**I RAID corrente è riempire rapidamente, in modo da spostare altrove alcuni database di SQL Server 2005. Nella nuova matrice è pronta ed già stato preparazione per spostare i database. Ho appena ho scoperto che uno dei database è una pubblicazione transazionale e so che significa che non è possibile spostare il database. Come fare?

**R:**È buona notizia per l'utente, ovvero solo SQL Server 2000 (e versioni precedenti) era la limitazione limitato lo spostamento di un database di pubblicazione senza reinizializzare la replica transazionale o modificando direttamente le diverse tabelle di sistema.

Con SQL Server 2005 e SQL Server 2008 è un processo documentato che consente di spostare un database senza dover eseguire alcuna operazione con la replica transazionale, purché il database rimane collegato alla stessa istanza di SQL Server. È necessario accettare dei tempi di inattività, come non è possibile spostare un file di database mentre è ancora in linea. La procedura da utilizzare è la seguente:

Eseguire innanzitutto il database non in linea utilizzando il codice riportato di seguito. Se vi sono utenti connessi al database, è necessario eliminare innanzitutto completare questo processo:

ALTER DATABASE MyDatabaseName SET OFFLINE;

Quindi copiare i file di dati nella nuova posizione. Utilizzare copia invece di spostamento per consentire un ripristino rapido in caso di qualsiasi elemento va errato (in caso contrario, sarà necessario eseguire un ripristino). Lasciare quindi SQL Server conosce il nuovo percorso di ogni file con il codice seguente:

ALTER DATABASE MyDatabaseName 
MODIFY FILE
   (NAME = N'LogicalFileName',
   FILENAME = N'pathname\filename');

Dopo aver fisicamente copiati tutti i file e aggiornati nei percorsi in SQL Server, portare in linea il database con il codice:

ALTER DATABASE MyDatabaseName SET ONLINE;

Chiusura di latch delle pagine

**D:**Problemi di comprendere alcuni concetti intorno l'ottimizzazione delle prestazioni Che ho letto più volte necessario evitare problemi di “ latch pagina ”. Non so cosa significhi “ pagina ” o “ latch ” o perché un latch pagina potrebbe anche essere un problema. Possibile informare tutto ciò?

**R:**Tutti i dati in un database di SQL Server è memorizzato nel file di dati. Internamente, questi file sono organizzati in sequenze di blocchi da 8 KB chiamati pagine . Una pagina è l'unità di base della memoria e I/O di SQL Server è in grado di gestire. Le pagine sono in genere nei file di dati su disco ed è necessario SQL Server cache (nota come il pool di buffer ) a leggerle prima dell'elaborazione delle query.

SQL Server utilizza diversi tipi di pagine per memorizzare diversi tipi di dati relazionali (ad esempio le righe da una tabella, righe da un indice non cluster o di dati LOB o testo). Sono inoltre disponibili pagine contenenti parti delle strutture di dati interne necessarie per organizzare e accedere alle pagine di memorizzazione dei dati relazionali in SQL Server.

Un latch è un semplice meccanismo interno che SQL Server viene utilizzato per sincronizzare l'accesso a una pagina all'interno della cache. Esistono due tipi di latch di pagina è necessario guardare, latch regularpage e latch I/O di pagina . Se un thread di SQL Server è in attesa di acquisire uno di questi latch, indica un problema di prestazioni.

Quando SQL Server è in attesa di una parte di un file di dati per la lettura da disco, può causare un'attesa di latch I/O di pagina. Se un latch I/O di pagina richiede una quantità eccessiva di tempo, in genere indica un problema di prestazioni con il sottosistema dei dischi sottostanti (ovvero è in overload).

Quando più thread all'interno di SQL Server sta tentando di accedere alla pagina stessa di 8 KB dati file in memoria e contesa per l'accesso alla pagina, ciò può causare l'attesa latch pagina. L'occorrenza più comune per questo implica un utilizzo intensivo di piccoli oggetti temporanei nel database tempdb.

Una spiegazione più approfondita di come monitorare e limitare attese latch pagina esula dall'ambito di questo articolo, ma è possibile trovare ulteriori informazioni in:

Ricerca tramite gli snapshot di database

**D:**Ho appena ho scoperto gli snapshot di database. Ora sto considerando utilizzarle come alternativa per i backup di registro e il modello di recupero completo. Creerò uno snapshot ogni ora o così e in questo modo se si verificassero problemi, è possibile estrarre nuovamente i dati danneggiati. Sembrare molto meno problemi e di ripristino in modo molto più rapido. È possibile visualizzare i problemi con questa modifica?

**R:**Sì, gli snapshot di database non sono un sostituto pratico o praticabile per una strategia di ripristino di emergenza completo. Una snapshot del database non fornisce le stesse funzionalità come un backup del log delle transazioni in termini di completamente recupero da un'emergenza. Lo snapshot di database non contiene una copia di tutte le pagine del database, solo quelli che sono stati modificati è stato prima creato. Questo significa che se il database è danneggiato in alcun modo, lo snapshot del database è inutile senza il database sottostante. È semplicemente un insieme di pagine diverse dal database e non può essere utilizzato per il ripristino.

Una snapshot del database consente di estrarre i dati che sono stato accidentalmente eliminati dal database, purché il database è ancora disponibile. Se una tabella eliminata nel database esiste ancora dello snapshot, ad esempio, puoi utilizzarlo per ricreare tale tabella eliminata.

Che viene detto, non è consigliabile creare troppe snapshot di un database (come sostituto di un backup del log delle transazioni una half oraria) a causa di potenziali problemi di prestazioni. Prima di poter scambiare una pagina di database (vedere la spiegazione di risposta in “ chiusura della sezione latch delle pagine ”), in modo sincrono prima occorre copiare la pagina in tutti gli snapshot di database esistente non sono già presente una versione della pagina. Quando si creano più snapshot di database, più copie di pagina è necessario eseguire e le prestazioni peggiorano.

Un altro motivo per non creare troppi gli snapshot di database è che ciascuno conterranno pre-change copie delle pagine del database. Ognuno di essi avrà come ulteriori delle modifiche del database. Questo può causare problemi di spazio su disco, nonché i problemi di prestazioni.

Gli snapshot di database non sono progettati per essere un sostituto per i backup del log frequenti. È possibile leggere uno Studio approfondito le implicazioni sulle prestazioni degli snapshot di database nel white paper “ di Considerazioni sulle prestazioni snapshot di database con il / O intensivo dei carichi di lavoro. ”

Inoltre, se si utilizza backup di log delle transazioni e del modello recupero completo, quindi si desidera ovviamente impedire il ripristino fino al punto di un'emergenza e/o la creazione utilizzare dei ripristini punto nel tempo. (Per una spiegazione vedere miei articoli 2009 luglio e novembre 2009 “ di informazioni su SQL Server backup” e “ SQL Server: Ripristino di emergenze utilizzo dei backup, ” rispettivamente.)

Mirroring, il mirror

**D:**Ho ricevuto l'incarico di impostare un mirroring del database per il database, ma si ritiene che il mirroring del database non è intenzione di risolvere il problema. Alcuni problemi di danneggiamento con nostro SAN, abbiamo era il piano è che il mirroring del database noi contro i danni. Non danneggiato automaticamente verranno inviata tramite il mirroring? Come è database mirroring fornire queste informazioni?

**R:**Si tratta di un problema che causa un notevole confusione. Sembrerebbe una tecnologia che fornisce una copia ridondante dei database sarebbe soggetta a danneggiamenti propagazione dal database principale al database mirror (per utilizzare terminologia di mirroring del database), ma in realtà non viene eseguita.

Il problema della questione si trova a comprendere come viene gestito il database mirror. Danneggiamento certamente verrebbe propagato al mirror sottostante meccanismo di sincronizzazione la copia delle pagine del database completo dal database principale al database mirror. Una pagina danneggiata dal database principale dovrebbe essere inserita nel mirror.

Tuttavia, il mirroring del database specificamente evita questo perché non copia le pagine del database da un database a altro. Il mirroring del database funziona copiando i record del log delle transazioni dal database principale al mirror. I record del log delle transazioni descrivono fisiche le modifiche apportate alle pagine del database e non contengono le effettive pagine stesse. (Per una spiegazione completa dei record del log delle transazioni, la registrazione e il ripristino vedere il mio articolo di febbraio 2009: “Informazioni sulla registrazione e il ripristino in SQL Server.”)

Anche se una pagina di database è danneggiata dal sottosistema di I/O sottostante del database principale, non è possibile per tale danneggiamento di propagare direttamente al database mirror. I peggiori eventualmente possono accadere sono se SQL Server non rileva un danneggiamento di pagina (poiché non sono abilitati i checksum della pagina), e un valore di colonna danneggiato viene utilizzato per calcolare il valore memorizzato nel database. Il risultato errato risultante dovrebbe essere propagato al database mirror, ovvero un danneggiamento di ordine secondo effetto .  Come accennato, se sono attivati i checksum di pagina, quando la pagina viene letta dal disco e il danneggiamento del secondo ordine non si verificherebbe tale danneggiamento rimarrebbe non rilevato.

Questo comportamento viene inoltre spiegato perché esegue una verifica della coerenza sul database principale non producono eventuali informazioni sullo stato della coerenza del database mirror e viceversa. Sono due database distinti mantenuti sincronizzati tramite spedizione descrizioni delle modifiche fisiche al database, le pagine di database effettivo.

Nota del curatore: Thanks to Kimberly L. Tripp of SQLskills.com for providing a technical review of this month’s column.

Paul S. Randal is the managing director of SQLskills.com, a Microsoft regional director and a SQL Server MVP. He worked on the SQL Server Storage Engine team at Microsoft from 1999 to 2007. He wrote DBCC CHECKDB/repair for SQL Server 2005 and was responsible for the Core Storage Engine during SQL Server 2008 development. Randal è un esperto di ripristino di emergenza, disponibilità elevata e la manutenzione del database ed è un normale relatore a conferenze in tutto il mondo. He blogs at SQLskills.com/blogs/paul, and you can find him on Twitter at Twitter.com/PaulRandal.

Contenuto correlato