Uzyskiwanie zmiany przy użyciu funkcji śledzenia zmian
W tym temacie opisano w funkcji śledzenia zmian SQL Server 2008 oraz używania ich uzyskania zmiany, które są dokonywane w bazie danych i informacji na temat zmiany.
Informacje o funkcji śledzenia zmian
Aplikacje można używać następujących funkcji uzyskania zmiany dokonane w bazie danych i informacji dotyczących zmian:
Funkcja CHANGETABLE zmian (…)
Ta funkcja zestaw wierszy jest używana do kwerendy, zmienianie informacji.Funkcja kwerendy danych przechowywanych w wewnętrznych zmian tabel.Funkcja zwraca zestaw wyniki zawierający klucze podstawowe wiersze, które zmieniły się razem z innymi informacjami zmiany, takie jak działania, zaktualizowane kolumn i wersja wiersza.CHANGETABLE(CHANGES …) trwa ostatniej wersja synchronizacji jako argumentu.Ostatnia wersja synchronizacji jest otrzymywana z zastosowaniem @last_synchronization_version zmiennych, jak przedstawiono w przykładach w tym temacie.Semantyka ostatniej wersja synchronizacji są następujące:
Klient wywołujący uzyskał zmian i wie o wszystkich zmianach, w tym ostatniej wersja synchronizacji.
CHANGETABLE(CHANGES …) dlatego zwróci wszystkie zmiany, które nastąpiły po ostatniej wersja synchronizacji.
Na następującej ilustracji pokazano, jak CHANGETABLE(CHANGES …) jest używana do uzyskiwania zmiany.
.gif "Przykład danych wyjściowych zapytania śledzenia zmian")
Funkcja CHANGE_TRACKING_CURRENT_VERSION()
Jest używany do uzyskiwania bieżącej wersja, która będzie używana następna czas podczas badania zmiany.Ta wersja reprezentuje wersja ostatnia transakcja przekazana.Funkcja () CHANGE_TRACKING_MIN_VALID_VERSION
Jest używany do uzyskiwania minimalna wersja ważne, że klient ma i nadal uzyskać prawidłowe wyniki z CHANGETABLE().klient należy sprawdzić ostatniej wersja synchronizacji przeciwko thatis wartość zwracana przez tę funkcja.Jeśli ostatnia wersja synchronizacji jest mniejsza niż wersja zwracana przez tę funkcja, klient będzie mógł uzyskać prawidłowe wyniki z CHANGETABLE() i będzie musiał ponownie zainicjować.
Uzyskiwanie danych początkowy
Zanim aplikacja może uzyskać zmiany w pierwszym czas, aplikacja musi wysłać kwerendę do uzyskania początkowych danych i synchronizacja wersja.Aplikacja musi uzyskać odpowiednie dane bezpośrednio z tabela, a następnie użyj CHANGE_TRACKING_CURRENT_VERSION() uzyskać wersja początkowej.Ta wersja zostanie przekazany do CHANGETABLE zmian (…) pierwszy czas uzyskuje się zmiany.
Poniższy przykład pokazuje sposób uzyskiwania wersja synchronizacja początkowa i początkowego zestaw danych.
-- Obtain the current synchronization version. This will be used next time that changes are obtained.
SET @synchronization_version = CHANGE_TRACKING_CURRENT_VERSION();
-- Obtain initial data set.
SELECT
P.ProductID, P.Name, P.ListPrice
FROM
SalesLT.Product AS P
Do uzyskania zmiany przy użyciu funkcji śledzenia zmian
Aby uzyskać zmienionych wierszy tabela oraz informacje dotyczące zmian, należy użyć CHANGETABLE(CHANGES…).Na przykład, poniższa kwerenda uzyskuje zmian dla SalesLT.Product tabela.
SELECT
CT.ProductID, CT.SYS_CHANGE_OPERATION,
CT.SYS_CHANGE_COLUMNS, CT.SYS_CHANGE_CONTEXT
FROM
CHANGETABLE(CHANGES SalesLT.Product, @last_synchronization_version) AS CT
Zazwyczaj klient będzie chcesz uzyskać najnowsze dane dla wiersza zamiast klucze podstawowe dla wiersza.W związku z tym, czy aplikacja łączyć CHANGETABLE zmian (…) wyniki z danymi w tabela użytkownika.Na przykład poniższa kwerenda łączy się z SalesLT.Product tabela, aby uzyskać wartości dla Name i ListPrice kolumny.Uwaga Użycie OUTER JOIN.Jest to wymagane, aby upewnić się, że informacje Zmień zwracane dla tych wierszy, które zostały usunięte z tabela użytkownika.
SELECT
CT.ProductID, P.Name, P.ListPrice,
CT.SYS_CHANGE_OPERATION, CT.SYS_CHANGE_COLUMNS,
CT.SYS_CHANGE_CONTEXT
FROM
SalesLT.Product AS P
RIGHT OUTER JOIN
CHANGETABLE(CHANGES SalesLT.Product, @last_synchronization_version) AS CT
ON
P.ProductID = CT.ProductID
Aby uzyskać wersja do użytku w wyliczeniu następnej zmiany, należy użyć CHANGE_TRACKING_CURRENT_VERSION(), jak pokazano w następującym przykładzie.
SET @synchronization_version = CHANGE_TRACKING_CURRENT_VERSION()
Gdy aplikacja uzyskuje zmiany, go należy użyć CHANGETABLE(CHANGES…) i CHANGE_TRACKING_CURRENT_VERSION(), jak pokazano w następującym przykładzie.
-- Obtain the current synchronization version. This will be used the next time CHANGETABLE(CHANGES...) is called.
SET @synchronization_version = CHANGE_TRACKING_CURRENT_VERSION();
-- Obtain incremental changes by using the synchronization version obtained the last time the data was synchronized.
SELECT
CT.ProductID, P.Name, P.ListPrice,
CT.SYS_CHANGE_OPERATION, CT.SYS_CHANGE_COLUMNS,
CT.SYS_CHANGE_CONTEXT
FROM
SalesLT.Product AS P
RIGHT OUTER JOIN
CHANGETABLE(CHANGES SalesLT.Product, @last_synchronization_version) AS CT
ON
P.ProductID = CT.ProductID
Numery wersji
Bazy danych, który ma włączone jest śledzenie zmian ma licznika wersja, który zwiększa zmiany tabel prześledzone zmiany.Każdy wiersz zmienionych ma numer wersja skojarzony z nim.Podczas wysyłania żądania do aplikacji kwerendy w celu zmiany, funkcja jest nazywana dostarczający numer wersja.Funkcja zwraca informacje o wszystkich zmianach wprowadzonych od tej wersja.Pod pewnymi względami zmian wersja jest podobne do rowversion typu danych.
Sprawdzanie poprawności ostatniej synchronizacji wersji
Informacje o zmianach jest utrzymywane przez ograniczony czas.Czas jest kontrolowana przez parametr CHANGE_RETENTION, który może być określony jako część ALTER DATABASE.
Należy pamiętać, że czas określony dla CHANGE_RETENTION Określa, jak często wszystkie aplikacje muszą zażądać zmian w bazie danych.Jeśli aplikacja ma wartość dla last_synchronization_version jest starsza niż wersja minimalna Ważne Synchronizacja tabela, że aplikacja nie może wykonać Zmień prawidłowego wyliczenia.Jest tak, ponieważ niektóre zmiany informacji może mieć został oczyszczony.Zanim aplikacja uzyskuje zmiany przy użyciu CHANGETABLE zmian (…), aplikacja musi sprawdzać wartość dla last_synchronization_version , który zamierza przekazać do CHANGETABLE(CHANGES …).Jeśli wartość last_synchronization_version jest nieprawidłowy, że aplikacja musi ponownie zainicjować wszystkich danych.
Poniższy przykład ilustruje sposób poprawność wartości last_synchronization_version dla każdej tabela.
-- Check individual table.
IF (@last_synchronization_version < CHANGE_TRACKING_MIN_VALID_VERSION(
OBJECT_ID('SalesLT.Product')))
BEGIN
-- Handle invalid version and do not enumerate changes.
-- Client must be reinitialized.
END
Jak pokazano na przykładzie, ważność wartość last_synchronization_version mogą być sprawdzane wszystkie tabele w bazie danych.
-- Check all tables with change tracking enabled
IF EXISTS (
SELECT COUNT(*) FROM sys.change_tracking_tables
WHERE min_valid_version > @last_synchronization_version )
BEGIN
-- Handle invalid version & do not enumerate changes
-- Client must be reinitialized
END
Za pomocą kolumny śledzenia
Kolumny śledzenia aplikacjom uzyskać dane dla kolumn, które zmieniły się zamiast całego wiersza.Na przykład Rozważmy scenariusz, w którym tabela ma jedną lub więcej kolumn, które są duże, ale rzadko zmian; i ma również innych kolumn, które często zmieniane.Bez kolumna śledzenia aplikacji tylko można określić, że wiersz został zmieniony i musiałaby synchronizowanie danych, które zawiera dane kolumna dużych.Jednak za pomocą kolumna śledzenia, aplikacja może ustalić, czy danych kolumna duże zmiany i tylko synchronizację danych uległa zmianie.
Śledzenie informacji o kolumnie pojawia się w SYS_CHANGE_COLUMNS kolumna, która jest zwracana przez funkcja CHANGETABLE(CHANGES …).
kolumna śledzenia można tak, zostanie zwrócona wartość NULL kolumna, która nie uległa zmianie.Kolumny można zmienić wartość null, osobnej kolumnie musi zwracane do wskazania, czy kolumna zmieniony.
W poniższym przykładzie CT_ThumbnailPhoto kolumny zostanie NULL , jeśli kolumna została Zmień.Ta kolumna może być również NULL , ponieważ została zmieniona na NULL -aplikacji można używać CT_ThumbNailPhoto_Changed kolumnę, aby określić, czy kolumna jest zmieniany.
DECLARE @PhotoColumnId int = COLUMNPROPERTY(
OBJECT_ID('SalesLT.Product'),'ThumbNailPhoto', 'ColumnId')
SELECT
CT.ProductID, P.Name, P.ListPrice, -- Always obtain values.
CASE
WHEN CHANGE_TRACKING_IS_COLUMN_IN_MASK(
@PhotoColumnId, CT.SYS_CHANGE_COLUMNS) = 1
THEN ThumbNailPhoto
ELSE NULL
END AS CT_ThumbNailPhoto,
CHANGE_TRACKING_IS_COLUMN_IN_MASK(
@PhotoColumnId, CT.SYS_CHANGE_COLUMNS) AS
CT_ThumbNailPhoto_Changed
CT.SYS_CHANGE_OPERATION, CT.SYS_CHANGE_COLUMNS,
CT.SYS_CHANGE_CONTEXT
FROM
SalesLT.Product AS P
INNER JOIN
CHANGETABLE(CHANGES SalesLT.Product, @last_synchronization_version) AS CT
ON
P.ProductID = CT.ProductID AND
CT.SYS_CHANGE_OPERATION = 'U'
Uzyskiwanie wyników konsekwentne i prawidłowe
Uzyskiwanie zmienionych danych dla tabela wymaga wielu kroków.Należy pamiętać, że może zwracane wyniki niespójne lub nieprawidłowe, jeśli pewne problemy nie są traktowane i obsługiwana.
Na przykład, aby uzyskać informacje o zmianach wprowadzonych do Sales tabela i SalesOrders tabela, aplikacja może wykonać następujące czynności:
Sprawdzanie poprawności ostatniej wersja zsynchronizowane za pomocą CHANGE_TRACKING_MIN_VALID_VERSION().
Uzyskania wersja, używany do uzyskania zmienić następną czas za pomocą CHANGE_TRACKING_CURRENT_VERSION().
Zmiany dotyczące uzyskania Sales tabela za pomocą CHANGETABLE(CHANGES …).
Zmiany dotyczące uzyskania SalesOrders tabela za pomocą CHANGETABLE(CHANGES …).
Dwa procesy występujących w bazie danych, które mogą wpłynąć na wyniki, które są zwracane przez poprzednie kroki:
Proces oczyszczania działa w tle i usuwa zmienić informacje o śledzeniu, która jest starsza niż okres zachowywania określonych.
Proces oczyszczania jest proces osobne tło stosowany okres zachowywania określonej podczas konfigurowania zmian bazy danych.Problem jest, że proces oczyszczania mogą występować w czas między podczas ostatniej wersja synchronizacji został sprawdzony i gdy wykonane wywołanie CHANGETABLE(CHANGES…).Ostatnia wersja synchronizacji, który został właśnie prawidłowe przestaną być ważne przez czas zmiany są uzyskiwane.Może być zwracane niepoprawne wyniki.
Kolejne operacje DML występujących w Sales i SalesOrders tabele, takich jak następujące operacje:
Wprowadzone zmiany do tabel po wersja następny czas zostało uzyskane za pomocą CHANGE_TRACKING_CURRENT_VERSION().Dlatego zmiany mogą być zwrócone, niż oczekiwano.
Transakcja może zatwierdzić w czas między wywołaniu w celu uzyskania zmiany z Sales tabela i wywołaniu w celu uzyskania zmiany z SalesOrders tabela.Dlatego wyniki dla SalesOrder tabela może mieć wartość klucz obcy, który nie istnieje w Sales tabela.
Aby stawiać czoła wyzwaniom wymienione wcześniej, zaleca się używać izolacji migawka.Pomoże to zapewnić spójność Zmień informacje i uniknąć wyścigu powiązanych zadań oczyszczania tła.Jeśli nie używasz transakcji migawka, opracowywanie aplikacji korzystającej z śledzenia zmian może wymagać znacznie więcej wysiłku.
Przy użyciu migawki izolacji
Śledzenie zmian został zaprojektowany do pracy ze izolacji migawka.Migawki izolacji musi być włączone dla bazy danych.Kroki, które są wymagane do uzyskania zmiany musi znajdować się wewnątrz transakcji migawka.Zapewni to wszystkie zmiany wprowadzone do danych podczas uzyskiwania zmiany nie będą widoczne dla kwerend wewnątrz transakcji migawka.
Uzyskanie danych wewnątrz transakcji migawka, wykonaj następujące czynności:
Ustawić poziom izolacji transakcji migawka i uruchomić transakcję.
Sprawdzanie poprawności ostatniej wersja synchronizacji za pomocą CHANGE_TRACKING_MIN_VALID_VERSION().
Uzyskaj wersja być używana następnym czas za pomocą CHANGE_TRACKING_CURRENT_VERSION().
Zmiany dotyczące uzyskania Sales tabela przy użyciu CHANGETABLE(CHANGES …)
Zmiany dotyczące uzyskania Salesorders tabela przy użyciu CHANGETABLE(CHANGES …)
Zatwierdzenia transakcji.
Niektóre punkty do zapamiętania jako wszystkie kroki w celu zmiany są wewnątrz transakcji migawka:
Jeśli oczyszczanie nastąpi po uwierzytelnieniu wersja ostatniej synchronizacji, wyniki z CHANGETABLE(CHANGES …) nadal będzie obowiązywać jak operacje usunięcia wykonywane przez oczyszczanie nie będzie widoczny wewnątrz transakcji.
Wszelkie zmiany wprowadzone do Sales tabela lub SalesOrders tabela po następnej synchronizacji wersja, nie będzie widoczny, i wywołania CHANGETABLE(CHANGES …) nigdy nie będzie zwracać zmian w wersja nowszej niż zwrócony przez CHANGE_TRACKING_CURRENT_VERSION().Spójność między Sales tabela i SalesOrders tabela będzie również obsługiwany, ponieważ transakcje, które zostały zatwierdzone w czas między wywołaniami do CHANGETABLE zmian (…) nie będzie widoczny.
Poniższy przykład pokazuje, jak migawka izolacji jest włączone dla bazy danych.
-- The database must be configured to enable snapshot isolation.
ALTER DATABASE AdventureWorksLT2008
SET ALLOW_SNAPSHOT_ISOLATION ON;
Transakcja migawka jest używany w następujący sposób:
SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
BEGIN TRAN
-- Verify that version of the previous synchronization is valid.
-- Obtain the version to use next time.
-- Obtain changes.
COMMIT TRAN
Aby uzyskać więcej informacji o transakcjach migawka, zobacz Wiersz wersji na podstawie poziomów izolacji.
Sygnalizowanie przy użyciu migawki izolacji
Istnieją alternatyw przy użyciu migawka izolacji, ale wymagają więcej pracy, aby upewnić się, że spełnione są wszystkie wymagania aplikacji.Aby upewnić się, last_synchronization_version jest prawidłowa i danych nie jest usuwany w procesie oczyszczania, zanim zmiany są uzyskiwane, wykonaj następujące czynności:
Sprawdź, czy last_synchronization_version po wywołania CHANGETABLE().
Sprawdź, czy last_synchronization_version jako część każdej kwerendy do uzyskania zmiany za pomocą CHANGETABLE().
Zmiany może wystąpić po pobraniu wersja synchronizacji dalej wyliczania.Istnieją dwa sposoby obsługi tej sytuacji.Opcja, która jest używana, zależy od aplikacji i jak może obsłużyć efekty uboczne każde podejście:
Ignoruj zmiany, które mają większy niż nowa wersja synchronizację wersji.
Takie podejście ma efekt uboczny, która byłaby nowych lub zaktualizowanych wierszy pomijane on został utworzony lub zaktualizowany zanim nowa wersja synchronizacji, ale później zaktualizować.W przypadku nowego wiersza, jeśli wystąpił wiersza w innej tabela, który został utworzony, odwołanie do wiersza pominięto może wystąpić problem więzów integralność.W przypadku zaktualizowanego istniejącego wiersza zostaną pominięte i niezsynchronizowany aż do następnego wiersza czas.
Obejmują wszystkie zmiany, nawet te, które mają większy niż nowa wersja synchronizacja wersji.
Wiersze, które mają większy niż nowa wersja synchronizacja wersji uzyska się ponownie podczas następnej synchronizacji.Musi to oczekiwana i obsługiwane przez aplikację.
Oprócz poprzedni dwie opcje można opracować podejścia, łączącego obie opcje, w zależności od operacji.Na przykład może być aplikację, dla której najlepiej zignorować zmiany nowsze niż następnej wersja synchronizacji, w której wiersz został utworzony lub usunięty, ale aktualizacje nie są ignorowane.
Ostrzeżenie
Wybranie podejścia, który będzie działać dla aplikacji podczas korzystania z śledzenia zmian (lub dowolny mechanizm śledzenia niestandardowych) wymaga znaczących analiz.Dlatego jest znacznie prostsze używać izolacji migawka.
Zobacz także