Konfigurieren und Verwalten von Änderungsnachverfolgung
In diesem Thema wird beschrieben, wie die Änderungsnachverfolgung aktiviert, deaktiviert und verwaltet wird. Außerdem werden die Vorgehensweisen zum Konfigurieren der Sicherheit und zum Ermitteln der Auswirkungen der Änderungsnachverfolgung auf Speicherung und Leistung beschrieben.
Aktivieren der Änderungsnachverfolgung für eine Datenbank
Bevor Sie die Änderungsnachverfolgung verwenden können, müssen Sie die Änderungsnachverfolgung auf Datenbankebene aktivieren. Im folgenden Beispiel wird gezeigt, wie die Änderungsnachverfolgung mit ALTER DATABASE aktiviert werden kann:
ALTER DATABASE AdventureWorks
SET CHANGE_TRACKING = ON
(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON)
Sie können die Änderungsnachverfolgung auch in SQL Server Management Studio aktivieren. Verwenden Sie hierzu das Dialogfeld Datenbankeigenschaften (Seite Änderungsnachverfolgung).
Bei der Aktivierung der Änderungsnachverfolgung können Sie die CHANGE_RETENTION-Option und die AUTO_CLEANUP-Option angeben. Die Werte können Sie nach der Aktivierung der Änderungsnachverfolgung jederzeit ändern.
Der Änderungsbeibehaltungswert gibt den Zeitraum an, für den Änderungsnachverfolgungsinformationen geführt werden. Änderungsnachverfolgungsinformationen, die älter sind als der angegebene Zeitraum, werden in regelmäßigen Abständen entfernt. Bei der Festlegung dieses Werts ist zu berücksichtigen, wie häufig Anwendungen mit den Tabellen in der Datenbank synchronisiert werden. Die angegebene Beibehaltungsdauer muss wenigstens so lange sein wie der maximale Zeitraum zwischen Synchronisierungen. Ruft eine Anwendung Änderungen in längeren Intervallen ab, werden möglicherweise falsche Ergebnisse zurückgegeben, da einige Änderungsinformationen wahrscheinlich entfernt wurden. Zur Vermeidung falscher Ergebnisse kann eine Anwendung die CHANGE_TRACKING_MIN_VALID_VERSION-Systemfunktion verwenden, um zu ermitteln, ob das Intervall zwischen den Synchronisierungen zu lang war.
Mit der AUTO_CLEANUP-Option können Sie den Cleanup-Task aktivieren oder deaktivieren, mit dem alte Nachverfolgungsinformationen entfernt werden. Dies kann hilfreich sein, wenn ein temporäres Problem vorliegt, das eine Synchronisierung von Anwendungen verhindert, und der Prozess zum Entfernen von Änderungsnachverfolgungsinformationen, die älter sind als die Beibehaltungsdauer, angehalten werden muss, bis das Problem behoben wurde.
Beachten Sie generell für Datenbanken, für die die Änderungsnachverfolgung verwendet wird, Folgendes:
Zur Verwendung der Änderungsnachverfolgung muss für den Datenbankkompatibilitätsgrad 90 oder höher festgelegt werden. Wenn eine Datenbank einen Kompatibilitätsgrad von weniger als 90 aufweist, können Sie die Änderungsnachverfolgung konfigurieren. Allerdings gibt dann die CHANGETABLE-Funktion, die verwendet wird, um Änderungsnachverfolgungsinformationen abzurufen, einen Fehler zurück.
Die Snapshotisolation ist die einfachste Möglichkeit, die Konsistenz aller Änderungsnachverfolgungsinformationen sicherzustellen. Aus diesem Grund sollte für die Snapshotisolation für die Datenbank auf jeden Fall ON festgelegt werden. Weitere Informationen finden Sie unter Verwenden der Änderungsnachverfolgung.
Aktivieren der Änderungsnachverfolgung für eine Tabelle
Die Änderungsnachverfolgung muss für jede nachzuverfolgende Tabelle aktiviert werden. Nach der Aktivierung der Änderungsnachverfolgung werden für alle Zeilen in der Tabelle, die von einem DML-Vorgang betroffen sind, Änderungsnachverfolgungsinformationen beibehalten.
Im folgenden Beispiel wird gezeigt, wie die Änderungsnachverfolgung für eine Tabelle mit ALTER TABLE aktiviert werden kann:
ALTER TABLE Person.Contact
ENABLE CHANGE_TRACKING
WITH (TRACK_COLUMNS_UPDATED = ON)
Sie können die Änderungsnachverfolgung für eine Tabelle auch in SQL Server Management Studio aktivieren. Verwenden Sie hierzu das Dialogfeld Tabelleneigenschaften (Seite Änderungsnachverfolgung).
Ist für die TRACK_COLUMNS_UPDATED-Option ON festgelegt, speichert SQL Server Database Engine (Datenbankmodul) in der internen Änderungsnachverfolgungstabelle zusätzliche Informationen dazu, welche Spalten aktualisiert wurden. Mit Spaltennachverfolgung kann eine Anwendung aktiviert werden, um nur die aktualisierten Spalten zu synchronisieren. Hiermit können Effizienz und Leistung gesteigert werden. Da die Verwaltung der Spaltennachverfolgungsinformationen jedoch zusätzlichen Speicherplatz beansprucht, ist diese Option standardmäßig deaktiviert.
Deaktivieren der Änderungsnachverfolgung
Die Änderungsnachverfolgung muss zunächst für alle Tabellen mit Änderungsnachverfolgung deaktiviert werden, bevor die Änderungsnachverfolgung auch für die Datenbank deaktiviert werden kann. Ermitteln Sie für eine Datenbank die Tabellen mit aktivierter Änderungsnachverfolgung mit der sys.change_tracking_tables-Katalogsicht.
Im folgenden Beispiel wird gezeigt, wie die Änderungsnachverfolgung für eine Tabelle mit ALTER TABLE deaktiviert werden kann:
ALTER TABLE Person.Contact
DISABLE CHANGE_TRACKING;
Wenn für keine Tabelle einer Datenbank Änderungen nachverfolgt werden, können Sie die Änderungsnachverfolgung für die Datenbank deaktivieren. Im folgenden Beispiel wird gezeigt, wie die Änderungsnachverfolgung für eine Datenbank mit ALTER DATABASE deaktiviert werden kann:
ALTER DATABASE AdventureWorks
SET CHANGE_TRACKING = OFF
Verwalten der Änderungsnachverfolgung
In den nachfolgenden Abschnitten sind Katalogsichten, Berechtigungen und Einstellungen aufgeführt, die für die Verwaltung der Änderungsnachverfolgung relevant sind.
Katalogsichten
Zur Festlegung, für welche Tabellen und Datenbanken die Änderungsnachverfolgung aktiviert ist, können Sie die folgenden Katalogsichten verwenden:
Zusätzlich werden in der sys.internal_tables-Katalogsicht die internen Tabellen aufgeführt, die bei der Aktivierung der Änderungsnachverfolgung für eine Benutzertabelle erstellt werden.
Sicherheit
Für den Zugriff auf Änderungsnachverfolgungsinformationen mit den Änderungsnachverfolgungsfunktionen muss der Prinzipal über die folgenden Berechtigungen verfügen:
SELECT-Berechtigung mindestens für die wichtigsten Schlüsselspalten der änderungsnachverfolgten Tabelle zur abgefragten Tabelle.
VIEW CHANGE TRACKING-Berechtigung für die Tabelle, für die Änderungen abgerufen werden. Die VIEW CHANGE TRACKING-Berechtigung ist aus folgenden Gründen erforderlich:
Datensätze der Änderungsnachverfolgung beinhalten Informationen zu gelöschten Zeilen, insbesondere zu den Primärschlüsselwerten der gelöschten Zeilen. Einem Prinzipal kann die SELECT-Berechtigung für eine änderungsnachverfolgte Tabelle erteilt worden sein, nachdem einige vertrauliche Daten gelöscht wurden. In diesem Fall sollte der Prinzipal nicht mit der Änderungsnachverfolgung auf die gelöschten Informationen zugreifen können.
Änderungsnachverfolgungsinformationen können Informationen darüber enthalten, welche Spalten mit Aktualisierungsvorgängen geändert wurden. Einem Prinzipal kann die Berechtigung für eine Spalte verweigert werden, die vertrauliche Informationen enthält. Da jedoch Änderungsnachverfolgungsinformationen verfügbar sind, kann der Prinzipal weiterhin feststellen, dass ein Spaltenwert aktualisiert wurde, aber er kann den Wert der Spalte nicht ermitteln.
Grundlegendes zum Aufwand der Änderungsnachverfolgung
Wenn die Änderungsnachverfolgung für eine Tabelle aktiviert ist, wirkt sich dies auf einige Verwaltungsvorgänge aus. In der folgenden Tabelle sind die Vorgänge und Auswirkungen aufgeführt, die Sie berücksichtigen sollten.
Vorgang |
Aktivierte Änderungsnachverfolgung |
|---|---|
DROP TABLE |
Alle Änderungsnachverfolgungsinformationen für die gelöschte Tabelle werden entfernt. |
ALTER TABLE DROP CONSTRAINT |
Ein Versuch, die PRIMARY KEY-Einschränkung zu löschen, schlägt fehl. Die Änderungsnachverfolgung muss deaktiviert werden, damit eine PRIMARY KEY-Einschränkung gelöscht werden kann. |
ALTER TABLE DROP COLUMN |
Ist eine gelöschte Spalte Bestandteil des Primärschlüssels, kann die Spalte nicht gelöscht werden, unabhängig von der Änderungsnachverfolgung. Ist die gelöschte Spalte kein Bestandteil des Primärschlüssels, kann die Spalte gelöscht werden. Es sollte jedoch zuerst die Auswirkung auf eine beliebige Anwendung, die diese Daten synchronisiert, verstanden werden. Ist die Spaltenänderungsnachverfolgung für die Tabelle aktiviert, kann die Spalte trotzdem als Bestandteil der Änderungsnachverfolgungsinformationen zurückgegeben werden. Die Anwendung ist für die Behandlung der gelöschten Spalte zuständig. |
ALTER TABLE ADD COLUMN |
Wird der änderungsnachverfolgten Tabelle eine neue Spalte hinzugefügt, wird das Hinzufügen der Spalte nicht verfolgt. Nur die Updates und Änderungen, die an der neuen Spalte vorgenommen werden, werden nachverfolgt. |
ALTER TABLE ALTER COLUMN |
Datentypänderungen einer Nicht-Primärschlüsselspalte werden nicht nachverfolgt. |
ALTER TABLE SWITCH |
Der Partitionswechsel schlägt fehl, wenn für eine oder beide Tabellen die Änderungsnachverfolgung aktiviert ist. |
DROP INDEX oder ALTER INDEX DISABLE |
Der Index, der den Primärschlüssel erzwingt, kann nicht gelöscht oder deaktiviert werden. |
TRUNCATE TABLE |
Das Abschneiden einer Tabelle kann für eine Tabelle ausgeführt werden, für die die Änderungsnachverfolgung aktiviert ist. Die mit dem Vorgang gelöschten Zeilen werden von dem Vorgang jedoch nicht nachverfolgt, und die minimale gültige Version wird aktualisiert. Führt eine Anwendung eine Versionsprüfung durch, ergibt die Prüfung, dass die Version zu alt ist und dass eine erneute Initialisierung erforderlich ist. Dies ist identisch mit der Deaktivierung der Änderungsnachverfolgung und der anschließenden erneuten Aktivierung für die Tabelle. |
Die Verwendung der Änderungsnachverfolgung führt aufgrund der Änderungsnachverfolgungsinformationen, die im Rahmen des Vorgangs gespeichert werden, zu erhöhtem Aufwand für DML-Vorgänge.
Auswirkungen auf DML
Die Änderungsnachverfolgung wurde optimiert, um den Verwaltungsaufwand für DML-Vorgänge zu minimieren. Der mit der Verwendung der Änderungsnachverfolgung für eine Tabelle verbundene schrittweise Verwaltungsaufwand ist mit dem Aufwand vergleichbar, der entsteht, wenn ein Index für eine Tabelle erstellt wird und beibehalten werden muss.
Für jede mit einem DML-Vorgang geänderte Zeile wird der internen Änderungsnachverfolgungstabelle eine Zeile hinzugefügt. Die Auswirkung dieses Vorgangs hängt von verschiedenen Faktoren ab, wie z. B. Folgendem:
Anzahl der Primärschlüsselspalten
In der Benutzertabellenzeile geänderte Datenmenge
Anzahl der Vorgänge, die in einer Transaktion ausgeführt werden
Die Verwendung der Snapshotisolation wirkt sich auch auf die Leistung für alle DML-Vorgänge aus, unabhängig davon, ob die Änderungsnachverfolgung aktiviert ist oder nicht.
Auswirkungen auf die Speicherung
Änderungsnachverfolgungsdaten werden in den folgenden Typen von internen Tabellen gespeichert:
Interne Änderungstabelle
Es gibt eine interne Änderungstabelle für jede Benutzertabelle, für die die Änderungsnachverfolgung aktiviert ist.
Interne Transaktionstabelle
Es gibt eine interne Transaktionstabelle für die Datenbank.
Diese internen Tabellen beeinflussen die Speicheranforderungen folgendermaßen:
Für jede Änderung einer Zeile in der Benutzertabelle wird der internen Änderungstabelle eine Zeile hinzugefügt. Diese Zeile verfügt über einen geringen festen Aufwand zuzüglich eines variablen Aufwands entsprechend der Größe der Primärschlüsselspalten. Die Zeile kann optionale, von einer Anwendung festgelegte Kontextinformationen enthalten. Wenn Spaltennachverfolgung aktiviert ist, werden für jede geänderte Spalte 4 Byte in der Nachverfolgungstabelle benötigt.
Für jede Transaktion, für die ein Commit ausgeführt wurde, wird einer internen Transaktionstabelle eine Zeile hinzugefügt.
Wie bei anderen internen Tabellen auch können Sie den für die Änderungsnachverfolgungstabelle verwendeten Speicher mit der sp_spaceused-gespeicherten Prozedur festlegen. Die Namen der internen Tabellen können mit der sys.internal_tables-Katalogsicht abgerufen werden, wie im nachfolgenden Beispiel dargestellt:
sp_spaceused 'sys.change_tracking_309576141'
sp_spaceused 'sys.syscommittab'
Siehe auch