• Articolo

A & D SQL Coerenza del database, tabelle temporanei e altro ancora

Paul S. Randal

QHO notato un comportamento molto strano su uno dei nostri database di SQL Server 2005. È eseguire un DBCC CHECKDB sul database come parte del nostro manutenzione notturna del database e alcuni notti il DBCC restituisce errori di danneggiamento. La cosa strana è che è non visualizzare gli errori di checksum di pagina durante il giorno precedente e se manualmente esegue DBCC CHECKDB mattina dopo l'errore del processo di manutenzione, la danneggiati sono state rimosse. È possibile spiegare la cosa sta succedendo? Questo è stato avvenga per un mese e sto ritiene che non attendibile DBCC CHECKDB.

AÈ buona verificare di disporre di DBCC CHECKDB come parte della manutenzione regolare e che siano attivati i checksum della pagina. Il comportamento è descrivere può essere molto disconcerting quando si verifica, quasi sembra DBCC CHECKDB è fornendo risultati non corretti. Ma questo scenario si verifica periodicamente in modo spesso, non sono indicazioni di run-time di danneggiamento, DBCC CHECKDB trova danneggiamento e quindi numero di ore in seguito i danneggiati sono andati quando DBCC CHECKDB viene eseguito nuovamente. Diamo questo passaggio per passaggio.

In primo luogo, è molto comune per danneggiati da dichiarare per DBCC CHECKDB non dichiarata durante le operazioni di database regolare. Anche se i checksum della pagina sono un ottimo metodo di rilevamento danneggiati dovuti il sottosistema di I/O, sono efficaci solo quando le pagine di dati vengono letti da SQL Server dopo un danneggiamento.

Si supponga che una pagina di dati contiene un checksum di pagina applicato e quindi danneggiato a un certo punto successiva dal sottosistema di I/O. Anche se il checksum di pagina verrà rilevato il danneggiamento, è solo quando la pagina viene letto in memoria da SQL Server che viene convalidato il checksum di pagina e viene rilevato il danneggiamento. Se tale pagina non è mai leggere da SQL Server, il danneggiamento non verrà individuato. Questo è il motivo per cui è essenziale per attivare i checksum della pagina ed eseguire regolarmente verifiche della coerenza, verifiche della coerenza leggerà il database, convalida i checksum della pagina e l'individuazione il prima possibile danneggiamento tutte le pagine.

Nel caso sembra come se si sono verificati i danneggiati nelle pagine di dati che non sono stati letti come parte di operazioni di database regolare e quindi i danneggiati non sono stati rilevati fino a quando non DBCC CHECKDB leggere le pagine danneggiate. Anche se sembra come se i checksum della pagina non rilevano il danneggiamento dovrebbe, non è la distinzione tra maiuscole e minuscole.

In secondo luogo, "scompare danneggiati possono verificarsi piuttosto semplice tra successive esecuzioni di DBCC CHECKDB, ma solo sui database in cui le modifiche si verificano tra l'esecuzione DBCC due. Si supponga una pagina è effettivamente danneggiata e DBCC CHECKDB segnala come danneggiato. Ora ad esempio la pagina viene quindi deallocata da una tabella (ad esempio perché diventi vuoto). Un DBCC CHECKDB successivi verrà non leggerlo questo momento e pertanto verrà non segnalare come danneggiato. Letture di DBCC CHECKDB allocata solo pagine (significato pagine che sono attualmente in uso). Nel caso, Attiva individuazione che il resto del processo di manutenzione notturna include Ricrea indice o la riorganizzazione, drasticamente che può modificare l'insieme di pagine allocate a un determinato oggetto o un indice di. Questo sarebbe conto per il comportamento in visualizzazione. Ricostruzione di un indice Dealloca pagine danneggiate un effetto secondario e quindi proviene nuovamente normale successivo DBCC CHECKDB.

Per rilevare le pagine danneggiate, modificare il processo di manutenzione in modo che si interrompe se non riesce il passaggio DBCC CHECKDB. In questo modo, sarà in grado di verificare i danneggiati e richiedere un'ulteriore azione manualmente.

QSi prevede l'aggiornamento da SQL Server 2000 direttamente a SQL Server 2008, ignorando SQL server 2005. Ma sono worried su tempdb. Questo problema già causato problemi per noi in SQL Server 2000 quanto si dispone di numerose tabelle temporanee breve durate. Da ciò che è possibile comprendere, tempdb viene utilizzato molto più frequente ora (in SQL Server 2005 e SQL Server 2008) e provisioning così speciale deve essere eseguita per impedire che le prestazioni rilascio dopo un aggiornamento. Spiegare perché si tratta la distinzione tra maiuscole e minuscole e cosa è necessario fare?

AAlla tua domanda attiva individuazione che stata era necessario implementare l'architettura di tempdb con una file per processore è generalmente necessario quando molte tabelle temporanee breve durate vengono create più connessioni al database. E si potrebbe disporre anche attivare l'analisi 1118-viene flag (vedere" Miglioramenti di concorrenza per il database tempdb"per ulteriori informazioni su questo).

Anche se vi è la possibilità di ad tempdb utilizzare in SQL Server 2005 poi, è possibile non visualizzare questo solo se si utilizza in particolare funzionalità che si basano su tempdb. Si noti che se non si richiedere una soluzione che ha riscontrato problemi di prestazioni di tempdb con SQL Server 2000 e l'aggiornamento a SQL Server 2008 sullo stesso hardware, è necessario in molti casi vedere i problemi di prestazioni ha risolto causa di alcune modifiche specifici di tempdb al motore di archiviazione del server SQL in SQL Server 2005.

Le funzionalità che rendono un utilizzo di tempdb su SQL Server 2005 e SQL Server 2008 sono:

  • Operazioni di indice in linea
  • I trigger DML
  • Gruppi di risultati a più attivo (MARS)
  • Isolamento dello snapshot (livello di transazione e livello di istruzione)

Tutte e quattro queste funzionalità utilizzano una tecnologia denominata il controllo delle versioni per memorizzare varie versioni di punto nel tempo i record di dati. In poche parole, queste versioni di record vengono archiviate nell'archivio versione nel database tempdb, tutti i database utente condivisione l'archivio versione stesso in tempdb singolo. Il più è utilizzare tali funzionalità, il heavier l'utilizzo dell'archivio versione e pertanto sarà tempdb e lì più potenziali sarà un impatto sulle prestazioni.

La chiave per qualsiasi aggiornamento corretto è per implementare un carico rappresentante produzione su un sistema di test con il nuovo schema e misurare le prestazioni per evitare sorprese che possono verificarsi se fosse necessario passare direttamente alla produzione.

Sfortunatamente, questa discussione consente rientra nell'ambito di questa colonna copertina approfondita, ma esistono alcune risorse eccellente disponibili che È consigliabile estrazione:

QSi sta implementazione un piano di manutenzione notturna del database che include il miglioramento delle prestazioni di indice. HO sentito che impostazione dell'opzione fattore di riempimento per gli indici possono rimuovere completamente la necessità di manutenzione di indici. È vero? Sembra che alcune gli indici nel database soffrono frammentazione e alcune non. Deve viene impostato un fattore di riempimento predefinito per il database da applicata a tutti gli indici e in caso affermativo, il valore deve utilizzo?

AL'impostazione del fattore di riempimento può effettivamente essere consente parzialmente ridurre la necessità di manutenzione degli indici, ma raramente utilizzabile per rimuovere completamente la necessità. L'impostazione del fattore di riempimento in istantaneamente indica il motore di archiviazione per lasciare una determinata percentuale di spazio disponibile nelle pagine di indici cluster e quando vengono creati o ricreati. (Si noti che l'impostazione del fattore di riempimento non viene mantenuta durante le normali operazioni inserimento, aggiornamento o eliminazione). Un fattore di riempimento di 90, ad esempio, lascia spazio libero del 10 %. Fattori di riempimento di 0 o 100 non lasciare spazio (che è stato l'origine di quantità confusione).

L'idea è lo spazio viene lasciato in pagine, che consente di record nella pagina per espandere o nuovi record da inserire nella pagina senza causare un'operazione costosa, causando la frammentazione denominata una divisione di pagina. Specificare una percentuale di spazio, in modo le pagine possono diventare più notevole completa finché non si la successiva operazione di manutenzione indice verifica, che reimposta nuovamente il fattore di riempimento. Il trucco è scegliere una percentuale che riduce al minimo divisioni di pagina tra operazioni di manutenzione indice.

Per un database OLTP (online transaction processing), risposta non semplice tranne per selezionare un fattore di riempimento per ogni indice basato in trial e un errore. Per data warehouse in cui non modificare gli indici, è necessario che il fattore di riempimento che al 100 % (significato non rimane spazio nelle pagine). È piuttosto insolito che il fattore di riempimento predefinito per un database viene modificato dal valore predefinito di 100 %, che i fattori di riempimento migliori per gli indici diversi sono in genere diversi. L'argomento nella documentazione in linea di SQL Server 2008" Fattore di riempimento"presenta molte più informazioni al riguardo.

Un'altra opzione consiste nel modificare l'indice in modo che non si verificano divisioni di pagina. Ciò potrebbe comportare modificando la chiave di indice in modo che inserisce non sono casuali (ad esempio, tramite non una chiave primaria GUID casuale) o apporto di operazioni che modificare le dimensioni di colonne di lunghezza variabile.

QCi concentreremo da passaggio a SQL Server 2008 appena SP1 proviene da e uno delle funzionalità che si cerchi Avanti all'utilizzo è FILESTREAM, come viene rimosso il limite della dimensione 2 GB per i valori di colonna. Prima si inizia la progettazione la prossima versione di nostro schema da utilizzare il tipo di dati FILESTREAM, sono presenti eventuali inconvenienti o problemi è necessario conoscere che potrebbe causare problemi in produzione?

AConsigliabile sempre smart per determinare tutte le caratteristiche di una nuova caratteristica prima di progettare in un nuovo schema o dell'applicazione, in particolare uno che utilizza tecnologie di fuori di SQL Server, come accade con FILESTREAM. La maggior parte delle informazioni è necessario è contenuto in un white paper HO scritto per il team SQL Server denominato" Archiviazione FILESTREAM in SQL Server 2008." Consigliabile di leggere tale carta per una descrizione completa, ma verrà riepilogare le principali aree di interesse in questo campo.

In primo luogo, i dati FILESTREAM viene memorizzati nel file NTFS, sistema, anziché in file di dati SQL Server. Esistono vari passaggi di configurazione che devono essere eseguite per assicurarsi che NTFS eseguito anche con un numero molto elevato di file in una singola directory, ad esempio la disattivazione di generazione del nome di formato 8.3, impostando il NTFS cluster dimensioni in modo appropriato, e probabilmente separando il FILESTREAM dati su fisici dischi separati da altri dati.

In secondo luogo, si consiglia di verificare saranno le dimensioni medie dei dati archiviati utilizzando FILESTREAM 1 MB o superiore. Ricerca è visualizzata che per dimensioni di dati di minore 256KB e talvolta tra 256 KB e 1 MB, prestazioni migliori possono essere ottenute l'archiviazione dei dati direttamente all'interno di SQL Server, anziché utilizzare un meccanismo, ad esempio FILESTREAM.

In terzo luogo, è necessario considerare le operazioni che verranno essere eseguite sui dati FILESTREAM. Aggiornamenti parziali non sono supportati per i dati FILESTREAM, pertanto, anche l'aggiornamento di un singolo byte di un valore di dati 200 MB verrà risultato di un completamente nuovo 200 MB valore creato. Oltre a essere un'operazione costosa, questo può causare frammentazione del livello di NTFS, ridurre ulteriormente le prestazioni. Se aggiornamenti parziali sono commonplace nell'applicazione, un tipo di batch meccanismo potrebbe essere necessario evitare ripetuti aggiornamenti per un singolo valore FILESTREAM.

Infine, è necessario considerare la compatibilità tra funzionalità di FILESTREAM con tecnologie di alta disponibilità. FILESTREAM completamente supporta operazioni di backup e ripristino (inclusi ripristino punto nel tempo), la distribuzione dei log e replica. Non è, tuttavia, compatibile con il mirroring del database in alcun modo in SQL Server 2008. (È stato detto che questo verrà corretto nella prossima versione di SQL Server.)

Si tratta semplicemente tuoi gusti aspetti da considerare. Per l'immagine completa, è consigliabile leggere il white paper. Come con qualsiasi nuova funzione, tuttavia, prima di progettare un'applicazione intorno a esso, assicurarsi di eseguire alcuni test completo per vedere se relativa funzionalità soddisfano i requisiti. Dato che FILESTREAM comprende anche archivio NTFS, è possibile attenersi alla procedura anche le prestazioni di preproduzione e ripristino di emergenza test per verificare che nothing viaggi è alto quando si passa live.

S Paul Randal è il responsabile gestione SQLskills.come un MVP di SQL Server. Ha lavorato 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 è un normale relatore a conferenze di tutto il mondo. Blog ha in SQLskills.com/blogs/paul.