SQL Server 2008

Verifica le revisioni del database dell'organizzazione

Paul S. Randal

 

In un riepilogo delle:

  • La necessità di rilevamento delle modifiche
  • Rilevamento modifiche in SQL Server 2005
  • Modificare la tracciabilità in SQL Server 2008
  • Modificare l'acquisizione di dati in SQL Server 2008

Contenuto

Si traccia cambia in SQL Server 2005
Come semplice rilevamento delle modifiche in SQL Server 2008
Modalità Modifica data acquisizione Works
Come modificare la gestione di Works
Disposizione dei

Per gli sviluppatori, un problema difficile in SQL Server tiene traccia che è stato modificato un database.Tema dell'architettura di una richiesta maggiore è scritti una soluzione semplice che molto doesn’t impatto sulle prestazioni del carico di lavoro e non è difficile creare, implementare e gestire.Pertanto, perché passare tutti i problemi di tenere traccia delle modifiche apportate?È rilevamento delle modifiche veramente utile tutti questo impegno?Due esempi le citazioni sono comunemente sono per supportare gli aggiornamenti un data warehouse e per supportare la sincronizzazione di eterogenei, talvolta connessi sistemi.

Un data warehouse ha in genere alcuni rappresentazione in forma delle tabelle nel database di elaborazione di transazioni in linea (OLTP), ma gli schemi di tabella possono effettivamente essere piuttosto diversi.Ciò significa che esiste deve essere un processo ETL (estrazione, trasformazione, carico) che sposta i dati dal database OLTP in data warehouse.

È possibile considerare tre possibilità per questa operazione.Il primo è per aggiornare periodicamente intero data warehouse.Si tratta poco chiara per volumi di dati di grandi dimensioni e significa che Aggiorna data warehouse non è inoltre continua.Il secondo metodo è utilizzare uno schema di partizionamento del database OLTP per consentire il processo ETL di utilizzare solo i dati di nuovi dopo il precedente processo ETL.Questo metodo funziona solo per consente di inserire dei dati, non aggiorna o elimina e richiede un meccanismo complesso per gestire definizione di limiti di partizione e passare le partizioni.Il terzo metodo consiste nel tenere traccia delle modifiche ai dati OLTP e solo eseguire il processo ETL utilizzando i dati modificati.Questo è il metodo più efficiente in termini di volume di dati.

Dispositivi mobili sono connettività in ambiente aziendale di oggi, indica che la gestione di sistemi connessi in alcuni casi è un requisito.In termini di sistemi di database, il problema è come aggiornare in modo efficiente un archivio dati su un dispositivo che non si connette spesso, soprattutto quando archiviare i dati stesso può essere piccolo e radicalmente diverso nello schema del database principale di.

Si consiglia un portatile rappres responsabile di una parte di un catalogo prodotti molto grande.Si ogni notte connette il dispositivo palmare a del database principale per scaricare i dati più recenti, tutte le modifiche a tale parte del catalogo prodotti semplificato per l'archiviazione in un computer palmare.Il trasferimento di dati deve essere efficiente possibile.

A questo punto, è possibile che il sistema database preparare la parte rilevante intera del catalogo prodotti per il download nel dispositivo e dispone del dispositivo scaricarlo.In altre parole, tutti i dati viene scaricato ogni volta che si connette il dispositivo, in anche se i dati non sono stato modificato.Questo è ovviamente di un approccio piuttosto inefficiente.

Un altro metodo consiste nel richiedere il sistema di database tenere traccia delle modifiche apportate la parte rilevante per il catalogo prodotti.Quindi, quando si connette il dispositivo portatile, richiesto per i dati che sono stato modificato dopo l'ultima volta che connesso.In questa soluzione nel sistema di database sono disponibili solo preparare un sottoinsieme di dati e il download è efficiente possibile.

Un altro motivo per il rilevamento delle modifiche apportate è per il supporto di controllo, essenziale i giorni selezionati.Controllo rileva le modifiche da apportate nonché quando si è verificata la modifica e che ha apportato la modifica.Verrà effettivamente visualizzata operazioni a un altro livello con vincoli rigide intorno a durata, protezione e la correttezza di un itinerario di controllo completo.

Le tecnologie che sono stata progettate per il rilevamento delle modifiche dei dati in SQL Server 2008 non sono state destinate per supportare il controllo; tuttavia, SQL Server 2008 è disponibile una nuova caratteristica, che viene chiamata controllo SQL Server, progettato appositamente per il controllo.Feed Byham illustrate la funzionalità di controllo di SQL Server in suo articolo "protezione di SQL Server 2008:" di aprile 2008 di TechNet Magazine (disponibile neltechnet.microsoft.com/Magazine/cc434691).

Come si può vedere, vi sono una serie di motivi interessante per tenere traccia delle modifiche apportate ai dati.In modo che la domanda importante modo migliore è, può essere eseguita verifica?

Si traccia cambia in SQL Server 2005

Con SQL Server 2005 e versioni precedenti di SQL Server non è una soluzione semplice, canned.Pertanto per queste piattaforme, gli sviluppatori sono stata creare soluzioni personalizzate per le applicazioni in genere riguardanti colonne timestamp, i trigger DML (Data Manipulation Language) e le tabelle aggiuntive.Queste soluzioni presentano tuttavia un'ampia gamma di potenziali problemi.Ad esempio:

  • L'aggiunta di colonne timestamp determina lo schema della tabella modificare (con effetti possibili knock-on nelle stored procedure e altro codice).
  • Un trigger DML in modo implicito è parte della transazione contenente DML con cui viene attivato, in modo che il tempo di esecuzione verrà aumentare la lunghezza della transazione.Il più complesso un trigger, il più necessario per l'esecuzione e pertanto maggiore effetto dannosa sulle prestazioni del carico di lavoro.I trigger DML utilizzati per il rilevamento delle modifiche necessario elaborare le tabelle inserite ed eliminate da raccogliere tutte le modifiche e quindi inserirli un'altra tabella Verifica.
  • La tabella di rilevamento è necessario che sia gestito in un modo per evitare la crescita all'esterno del controllo, potrebbe richiedere la creazione simile a un processo dell'agente per periodicamente troncare dati precedenti.

Come semplice rilevamento delle modifiche in SQL Server 2008

SQL Server 2008 introduce due nuove tecnologie che rendono molto più semplice tenere traccia delle modifiche apportate ai dati: modificare tracciabilità e modificare dati acquisizione.Entrambe le funzionalità tenere traccia dei dati che sono stata modificata (come utilizzare gli inserimento, aggiornamento o le operazioni di eliminazione per verificare esattamente come i dati modificati), e si elimina la necessità per soluzioni personalizzate.Isolare le analogie, i meccanismi ed esattamente di cui tenere traccia sono effettivamente molto diversi.

Modifica dati acquisizione utilizza un meccanismo asincrono che tiene traccia di tutte le modifiche che si verificano a una tabella o un insieme di colonne della tabella e inclusi nella colonna i valori stessi.Questo è progettato per scenari come descritto in precedenza il processo ETL warehouse di dati.

Nella figura 1 è illustrata modifica dati utilizzati in temporali.Il meccanismo di acquisizione dei dati modifica estrae i dati modificati in un insieme di tabelle, con le modifiche più recenti nella parte superiore della tabella.Il processo ETL quindi è possibile eseguire query tabelle contenente i dati di modifica per tutte le modifiche che si è verificato in un periodo di tempo impostato.Questo meccanismo consente il processo ETL per limitare la quantità di dati che devono essere utilizzati in ogni blocco.

fig01.gif

Nella figura 1 Storico modificare dati utilizzati in temporali fare clic su Immagine per una visualizzazione ingrandita

Revisioni, è invece, utilizza un meccanismo sincrono che tiene traccia solo che una particolare riga modificato in una tabella (e, facoltativamente, l'elenco delle colonne modificare).Questo consente di risolvere tali problemi come lo scenario di sistema connesso occasionalmente descritto in precedenza.Questo approccio è illustrato nella Figura 2 .

fig02.gif

Nella figura 2 un sistema connesso occasionalmente utilizzando dati di rilevamento delle modifiche fare clic su Immagine per una visualizzazione ingrandita

Entrambe le funzionalità introducono un aumento di I/O e registrazione, ma questo è vero con le soluzioni personalizzate, la modifica dei dati deve essere memorizzata in una.Ciò che rende queste due funzioni potenzialmente diverso da una soluzione personalizzata è di che le tabelle utilizzate per memorizzare i dati di modifica devono essere nello stesso database come le tabelle da rilevati.Ciò significa che verranno incluso nei backup e potenzialmente trasmessi in rete per la distribuzione dei log o il mirroring del database i dati di modifica.

In termini di sviluppo, queste due funzionalità deve rimuovere numerose la complessità tiene traccia delle modifiche apportate.Non esistono trigger necessario per una tecnologia o le modifiche dello schema di tabella.Sia le tecnologie sono processi di pulitura configurabile, automatico, variazione di ordine transazione commit volte e fornire funzioni incorporate per recuperare informazioni di modifica.

La prospettiva di gestione, sono disponibili e svantaggi per ogni approccio.Con qualsiasi tecnologia è una quantità elevata di informazioni è necessario conoscere prima di sviluppare e distribuire soluzioni che utilizzano queste funzionalità.Nel resto in questo articolo verrà fornita una panoramica di ciascuno di queste funzionalità, intervenire su loro funzionamento e i punti pratici da considerare prima di utilizzarli nell'ambiente di produzione.

Modalità Modifica data acquisizione Works

Modifica dati acquisizione non effettuare alcuna operazione come parte le transazioni di modificare la tabella viene tenuta traccia.Al contrario, l'inserimento, aggiornamento ed le operazioni di eliminazione vengono scritti nel log delle transazioni, come normale e periodicamente harvested dal registro.Harvesting viene eseguita da un processo di lettura log SQL Agent e le operazioni harvested vengono memorizzate in una tabella separata denominata tabella di modifica.A un certo punto secondo la tabella di modifica può eseguire una query per ottenere dati modifica utilizzando uno dei due funzioni.La combinazione della tabella di modifica e le due funzioni viene chiamata un'istanza di acquisizione.Nella figura 3 è illustrato il flusso dei dati mediante Modifica acquisizione di dati in unità di un processo ETL di data warehouse.

SQL\layout\FIGURES\fig03.gif \\msdnmagtst\MTPS\TechNet\issues\en\2008\11\Randal

L'attivazione di acquisizione dei dati di modifica è un processo due fase.Un membro del ruolo server fisso sysadmin innanzitutto necessario attivare modifica dati acquisizione per il database utilizzando sys.sp_cdc_enable_db.Un membro del ruolo server fisso db_owner quindi necessario attivare modifica acquisizione di dati in una tabella specifica tramite sys.sp_cdc_enable_table.Questi requisiti di protezione sono dovuti alla possibilità di utilizzo del disco elevata se modifica dati acquisizione è non configurato correttamente.È opportuno perfetto che un proprietario della tabella non possibile abilitare la funzionalità e sorprendere un amministratore di database con utilizzo del disco aggiuntive.

Quando acquisizione dei dati di modifica è attivata per un database, alcuni elementi vengono aggiunti al database, incluso un nuovo schema (denominato cdc), alcune tabelle di metadati e un trigger per acquisire gli eventi DDL (Data Definition Language).(Una funzionalità che ritiene è interessante è che è possibile ottenere un elenco di una tabella le modifiche DDL.)

L'attivazione di acquisizione dei dati modifica crea anche l'istanza di acquisizione per la tabella, la modifica tabella e fino a due funzioni per restituire modificare i dati.Il nome della tabella modifica equivale l'istanza di acquisizione, con _CT aggiunto.La prima funzione viene sempre creata ed è quello utilizzato per restituire modificare i dati della tabella di modifica.La seconda funzione viene creata se è specificata l'opzione per consentire di saldo.Ciò significa che il risultato finale delle modifiche acquisite viene restituito, anziché tutti intermedia modifiche che la prima funzione restituisce.La funzione di due nomi è, rispettivamente, fn_cdc_get_all_changes_ e fn_cdc_get_net_changes_ con il nome di istanza acquisizione aggiunto.Si noti che (come la funzionalità di rilevamento di modifica) questa funzionalità richiede la tabella dispone di una chiave primaria o altro indice univoco.

Quando sta si gestiscono la prima tabella del database per modifica dati acquisizione attivata, è possibile creare due processi di Agente SQL: il processo di acquisizione e il processo di pulitura.Dico "è possibile creare" perché il processo di acquisizione è identico a quello utilizzato per harvesting transazioni in replica transazionale.Se è già configurata la replica transazionale, quindi essere creato solo il processo di pulitura e il processo di Visualizzatore registro esistente verrà inoltre essere utilizzato come il processo di acquisizione.Si tratta valida in quanto con due processi di lettura log rapidamente potrebbe portare a problemi di conflitti con il registro e problemi di prestazioni.In entrambi i casi, Agente SQL deve essere in esecuzione se si desidera utilizzare l'acquisizione di modifica dei dati.

La logica all'interno il visualizzatore registro copes automaticamente con le tabelle da attivato e disattivato per la modifica dei dati acquisire e modifica che cosa è harvested conseguenza dal log delle transazioni.Un punto principale da notare di seguito è che una volta acquisizione di modifica dei dati è attivato, il log delle transazioni comportamento solo come con la replica transazionale, il log non può essere troncato finché non ha elaborato il visualizzatore registro.Ciò significa che un'operazione checkpoint, anche in modalità di recupero con registrazione minima, non troncare il log a meno che non è già stata elaborata dal Visualizzatore registro.

Inoltre, se il modello di recupero BULK_LOGGED viene utilizzato per ridurre la registrazione, modifica dati acquisizione imporrà tutto diventano registrate, fatta eccezione per operazioni di indice creare o rilascio/ricostruzione.Tenere se tale comportamento non abbiano riscontrato lo, presente che ciò potrebbe causare transazione problemi di dimensione registro, soprattutto se le impostazioni predefinite processo di acquisizione vengono modificate in modo che il registro non elaborato come spesso.

Per impostazione predefinita, il processo di acquisizione esegue continuamente, scansione nel registro ogni cinque secondi e l'elaborazione di un massimo di 500 transazioni dal registro.Inoltre per impostazione predefinita, il processo di pulitura esegue ogni giorno alle 2e rimuove tutte le modificare voci dati anteriori a tre giorni delle tabelle di modifica.È possibile modificare queste impostazioni utilizzando la procedura sys.sp_cdc_change_job e quindi le modifiche diverranno effettive dopo il riavvio i processi utilizzando sys.sp_cdc_stop_job e sys.sp_cdc_start_job.

Anche se il processo di lettura log verrà in genere un basso impatto sulle prestazioni del sistema, è possibile su sovraccarico sistemi OLTP con numerose la modifica dei dati che l'aggiunta di un solo processo di Visualizzatore registro può causare conflitti sul log delle transazioni.Conflitto effettivo potrebbe essere causato dalle testine disco necessità di spostarsi tra il punto in cui il registro viene salvato in da transazioni e il punto in cui è la lettura dal processo di lettura log.In questo caso, potrebbe essere necessario modificare la frequenza con cui l'esecuzione del processo di acquisizione per garantire prestazioni OLTP non verranno compromesso.Tuttavia, crea spazio classico e commerciali di prestazioni, disattivare, il registro continuerà a crescere fino a quando il processo di acquisizione elabora.

Il problema stesso si verifica se il pulitura processo frequenza o modificare dati conservazione periodi vengono modificati, le tabelle di modifica continuerà a crescere fino a quando viene eliminati i dati di modifica.Questo comporta un considerazioni di progettazione all'ingrosso di ciò che viene rilevato e la durata viene mantenuto.Sono importanti aspetti da considerare di seguito:

  • Elenco di colonne necessaria per l'istanza di acquisizione.Quando sono presenti più colonne, più dati di modifica viene inseriti tra le tabelle di modifica.
  • La quantità di spazio su disco utilizzata per le tabelle di modifica.
  • La frequenza con cui l'esecuzione del processo che utilizza i dati di modifica.Tenere presente che i dati non possono essere eliminate se non è stato utilizzato ancora.
  • La frequenza con cui il processo di pulitura viene eseguito, è possibile in modo da gran parte la modifica dei dati generati che il processo di pulitura viene eliminata eseguire solo sul fine settimana, ad esempio, perché in caso contrario genera una quantità eccessiva log delle transazioni.

Modifica dati acquisizione possibile impostare per semplicemente tenere traccia delle tutte le modifiche apportate a una tabella o per controllare un sottogruppo di colonne in una tabella.Utilizzare un sottoinsieme può essere utile se alcune delle colonne non importanti sono molto ampia varchar colonne o colonne grandi oggetto Binary Object (BLOB) (ad esempio text, image o XML; in caso contrario, lo spazio utilizzato dalla tabella di modifica potrebbe aumentare difficoltoso molto rapidamente.

Dato il maggiore rischio di utilizzo dello spazio su disco, la posizione di filegroup di nella tabella di modifica può essere impostata quando la modifica dei dati acquisizione è attivata.In questo modo più semplice gestione di spazio su disco sottostante e si indica che tutti i dati modifica potenzialmente possono essere memorizzati in un volume di un livello RAID meno costoso rispetto del database principale.Inoltre, le impostazioni del processo di pulitura applicate a tutte le istanze di acquisizione, un'istanza singola acquisizione può essere separatamente pulita in qualsiasi momento se lo spazio su disco diventa un problema.È possibile controllare facilmente utilizzo dello spazio su disco utilizzando le tabelle di acquisizione sp_spaceused.

La riga effettiva scrittura nella tabella di modifica contiene i metadati relativi alla transazione (il numero di sequenza di registro commit, o il numero LSN), come pure l'ordine all'interno della transazione che la variazione è avvenuta, quali l'operazione è stata, una maschera di bit delle quali colonne sono state modificate, e i valori effettivi colonna.

Modifiche DDL sono senza restrizioni mentre acquisizione dei dati di modifica è attivata.Può, tuttavia, hanno alcune effetto sui dati di modifica raccolti se le colonne vengono aggiunti o eliminate.Se una colonna revisione viene rilasciata, tutte le voci ulteriormente l'istanza di acquisizione avrà NULL per la colonna.Se viene aggiunta una colonna, verrà ignorato dall'istanza di acquisizione.In altre parole, la forma dell'istanza di acquisizione viene impostata quando viene creato.

Se sono necessarie modifiche di colonna, è possibile creare un'altra istanza di acquisizione di una tabella (a un massimo di istanze di due acquisizione per tabella) e consentono agli utenti dei dati di modifica per la migrazione a nuovo schema di tabella.Ma dovrà prestare particolare attenzione quando si esegue questo perché la media di due istanze di acquisizione per una tabella rilevata due volte la quantità di spazio su disco, I/o e registrazione.

Evitando in troppo profondità, le modifiche vengono recuperate dalle tabelle di modifica utilizzando le funzioni che sono descritte.Le funzioni di richiedere un numero LSN di inizio e fine LSN e non esistono altre funzioni forniti che consentono di convertire un tempo ordinario in un numero LSN.Quando si recuperano gli aggiornamenti, è possibile anche specificare se visualizzare la prima e dopo i valori oppure solo la prima.È presente un screencast dell'utente utilizzando l'acquisizione di modifica dei dati disponibili inwww.technetmagazine.com/video.

Come modificare la gestione di Works

Come è detto, rilevamento delle modifiche è un processo sincrono ed è molto meno complesso rispetto a modificare l'acquisizione di dati.Fa parte della transazione che apporta una modifica a una riga di una tabella viene tenuta traccia e il fatto che la riga è stato modificato è registrato in una tabella separata.La tabella è ciò che definito una tabella interna e non non controllare il nome o in cui è memorizzato.Non considerare questo un problema poiché è necessario molto meno dati in questa tabella di in una tabella modifica utilizzata per l'acquisizione di modifica dei dati.Ma può comunque esistere problemi di spazio su disco, come spiegherò in un momento.

Il fatto che il rilevamento delle modifiche avviene in modo sincrono, significa che esiste ulteriore elaborazione eseguita all'interno di ciascuna transazione modifica della tabella viene tenuta traccia.L'effetto sulle prestazioni è simile a quella quando un indice non cluster contenga la tabella e devono essere aggiornato con ogni modifica alla tabella.Transazioni stessi sono inoltre rilevate quando eseguire il commit a una riga nella tabella sys.syscommittab interno.

Rilevamento delle modifiche è attivato e disattivato utilizzando regolare ALTER DATABASE e la sintassi ALTER TABLE e si segue lo stesso modello acquisizione dei dati di modifica, in cui è necessario attivare a livello di database prima di livello di tabella.La sequenza delle operazioni si aspetto illustrato Nell'esempio questo:

ALTER DATABASE AdventureWorks2000 SET CHANGE_TRACKING = ON
  (CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);
GO
USE AdventureWorks2000;
GO
ALTER TABLE Person.Person ENABLE CHANGE_TRACKING
  WITH (TRACK_COLUMNS_UPDATED = ON);
GO

Le autorizzazioni necessari per l'attivazione modificare registrazione nel database e tabella livelli sono diversi da quelle per abilitare la modifica dei dati acquisizione: db_owner e il proprietario della tabella, rispettivamente. Quando il rilevamento delle modifiche è attivata a livello di database, è possibile impostare il periodo di conservazione, nonché se i dati di modifica viene automaticamente puliti. Il periodo di predefinito sarà di 2 giorni, con un massimo di 90 giorni e un minimo di un minuto.

Pulitura automatica è inoltre attivata per impostazione predefinita. Quando si apportato modifiche a queste impostazioni, è necessario valutare lo stessi compromessi come discusso con modifica dati acquisizione, fondamentalmente disco spazio e prestazioni in esigenze dell'applicazione.

Per impostazione predefinita, ciò che viene acquisito per ogni riga è sufficiente che è stato modificato. A tale scopo, effettua nota della chiave primaria della riga che stata modificata (ovvero modifica la verifica in una tabella richiede che questo dispone di una chiave primaria), con un numero di versione (una volta che un database è abilitato per il rilevamento delle modifiche, un numero di versione è instituted, che consente l'ordinamento delle operazioni) e il tipo di operazione che ha effettuato la modifica. Anche se lo si desidera è possibile verificare quali colonne modificati, questo richiede 4 byte per colonna modificata.

Monitoraggio di spazio su disco è leggermente diverso con il rilevamento delle modifiche, poiché i dati di modifica sono memorizzati in tabelle interne. Per individuare i nomi delle tabelle interne utilizzate, è sufficiente utilizzare la vista del catalogo di sistema sys.internal_tables:

SELECT [name] FROM sys.internal_tables
  WHERE [internal_type_desc] = 'CHANGE_TRACKING';
GO

Passare quindi il nome in sp_spaceused visualizzare utilizzato lo spazio su disco.

A differenza con acquisizione dei dati di modifica, quando è attivo il rilevamento delle modifiche, esistono restrizioni nella DDL che possono essere eseguite in una tabella viene tenuta traccia. La restrizione più importante è che è impossibile modificare la chiave primaria in alcun modo. La restrizione opportuno chiamata da è che un'istruzione ALTER TABLE SWITCH non riuscirà se una tabella coinvolto ha attivato il rilevamento modifiche. Questo è probabilmente dovuto al fatto che non ha senso automaticamente avviare o rimuovere rilevamento delle modifiche per una partizione in passato all'esterno di una modifica tiene traccia, tabella partizionata o una tabella rilevata modifica quale si è passati in una tabella partizionata, rispettivamente.

Le modifiche vengono recuperate dalle tabelle modifica interno utilizzando una nuova funzione CHANGE­TABLES (modifiche …). Questo corrisponderà al nome della tabella rilevata modifica e il numero di versione dal tempo precedente è stata utilizzata e restituisce informazioni relative a tutte le righe modificate dall'quel momento precedente. Esistono varie funzioni per trovare la versione valida corrente e meno recente. L'applicazione può quindi utilizzare le informazioni che viene restituite al query la tabella in modifica registrata per ottenere i valori effettivi colonna. Naturalmente, è un processo più passaggi, ottenere la versione corrente, utilizzare tale versione da rilevamento delle modifiche di query e quindi eseguire una query le tabelle effettive per i dati della colonna corrispondente a tale versione.

In un sistema costantemente modificato, è possibile ottenere risultati incoerenti o non corretti a meno che un tipo di visualizzazione immutabile della versione, modificare i dati e i dati della colonna effettivo viene mantenuti. A tale scopo, è possibile utilizzare l'isolamento dello snapshot e racchiudere il processo prevede più passaggi in una transazione esplicita. Questo funziona bene ma presenta svantaggi potenziali. Isolamento dello snapshot può influire sulle prestazioni del carico di lavoro e influisce sull'prestazioni e utilizzo dello spazio di tempdb. È possibile trovare ulteriori informazioni su questo in technet.microsoft.com/library/cc280358.

Disposizione dei

Nella figura 4 fornisce un confronto affiancata, dei dati di verifica e modifica di modifica pertanto è possibile farsi un'idea migliore le principali differenze verrà interessano gli amministratori di database. È possibile visualizzare dalla tabella che modifica dati acquisizione è molto maggiore spessore di rilevamento delle modifiche. Richiede più attenzione quando si decide cosa verificare a causa dei potenziali per la crescita veloce della dimensione della tabella verifica se, ad esempio, nella tabella che tiene traccia è indicato BLOB colonne o righe molto ampia. È inoltre disponibile la possibilità di transazione problemi di gestione del registro, come il log non verrà troncato fino a quando il visualizzatore registro ha harvested i record nel registro.

Nella figura 4 confronto tra modificare tracciabilità e modificare dati acquisizione

Funzionalità Modificare la verifica Modifica data acquisizione
Sincrona No
Richiede di Agente SQL No
Forza completa registrazione di alcune operazioni di massa No
Impedisce di troncamento log No Sì, fino a quando harvested record di log
Richiede l'isolamento dello snapshot Consigliato No
È necessario che separate tabelle per memorizzare dati di rilevamento
È necessaria chiave primaria Non per impostazione predefinita
Consente di selezione host di tabelle di rilevamento No
Possibilità di problemi di consumo di spazio Alcuni I gruppi di transazioni
Processo di pulitura automatica
Restrizioni DDL No
Richiesta per consentire l'autorizzazione Sysadmin Proprietario del database

Rilevamento delle modifiche non è senza i propri requisiti, tuttavia. Ad esempio, è necessaria una chiave primaria e si consiglia di utilizzare isolamento dello snapshot quando viene attivato il rilevamento delle modifiche. Isolamento dello snapshot stesso possibile aggiungere un overhead significativo del carico di lavoro e richiede molto più attenzione gestione del database tempdb.

Un problema di ulteriori gli sviluppatori e agli amministratori di database da gestire: ripristino di emergenza. Sebbene questa discussione di profondità sia descritte in questo articolo, l'argomento del ripristino di emergenza è troppo importante almeno non parlare.

Entrambe le funzionalità riprodurre con BACKUP e ripristino. Il problema risulta quando un database Ottiene ripristinato e viene eseguito essenzialmente nuovamente nel tempo. L'applicazione globale o sistema comportamento? Progettato per il rilevamento delle modifiche di soluzioni personalizzate affrontare anche questo problema e richiede comunque da considerare quando si utilizza SQL Server 2008.

Come sempre, assicurarsi letto tramite tutti (di documentazione disponibile technet.microsoft.com/library/bb418491) e qualsiasi white paper esistente prima di procedere a un progetto progettazione e distribuzione che comprende le nuove funzionalità per tenere traccia delle modifiche apportate. È necessario prima verificare se le potenziali problemi non trattati in questo campo possono essere applicabile all'. È anche necessario ottenere i dettagli su nuovo SPs monitoraggio e viste gestione dinamica (DMV).

Queste nuove funzionalità sono globale un avanzamento grande su precedenti metodi per tenere traccia di modifiche dei dati. Ora che esiste, è possibile che gli sviluppatori verranno desidera utilizzarli nelle soluzioni che è possibile gestire.

Esistono configurazione importanti e problemi di gestione da prendere in considerazione e spero che questo articolo è fornita una panoramica a tinta unita delle tecnologie in modo da prevedere e preparare per alcuni dei problemi che sono descritti. Se si dispone eventuali commenti e suggerimenti per questo articolo o domande, procedere e rilascio di una riga Paul@SQLskills.com.

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 è in un normale relatore a conferenze di tutto il mondo. Blog ha in SQLskills.com/blogs/paul.