Czy zmieniono wewnętrzne elementy śledzenia zmian z SQL Server 2008 na 2012?

Podczas rozwiązywania problemu z synchronizacją odłączonych urządzeń z centralnym serwerem bazy danych mamy problem po aktualizacji do SQL Server 2012 na serwerze. Wygląda na to, że CHANGE_TRACKING_MIN_VALID_VERSION zwraca wartość o 1 wyższą niż powinna (lub przynajmniej niż przed aktualizacją).

Pracowałem nad wspaniałym spacerem Arshada Ali przez przykład, jak ustawić prosty przykład.

Uruchomiłem skrypty od 1 do 5, aby wstawić, usunąć i zaktualizować wiersz w tabeli Pracowników zarówno w środowisku SQL Server 2008, jak i 2012.

W 2008 roku następująca instrukcja zwraca 0:

SELECT CHANGE_TRACKING_MIN_VALID_VERSION(OBJECT_ID('Employee'))

W 2012 roku zwraca 1.

Pracując przez kilka kolejnych skryptów (6-8) w testach, ustawiłem okres przechowywania na 1 minutę, aby, mam nadzieję, wymusić akcję czyszczenia. Wyszedłem na dzień i najwyraźniej biegł przez noc.

W instancji 2008 CHANGE_TRACKING_CURRENT_VERSION i CHANGE_TRACKING_MIN_VALID_VERSION są równe (11). W instancji z 2012 r. CHANGE_TRACKING_MIN_VALID_VERSION jest o jeden wyższy (12) niż CHANGE_TRACKING_CURRENT_VERSION (11). Może to mieć wpływ na proces synchronizacji, gdy baza danych jest bezczynna przez dłuższy czas. Odkryliśmy, że proces może zostać złapany w pętlę, zwłaszcza gdy wykonywany jest następujący test w celu ustalenia, czy wymagana jest ponowna inicjalizacja, a nie synchronizacja:

IF CHANGE_TRACKING_MIN_VALID_VERSION(object_id(N'dbo.Employee')) > @sync_last_received_anchor 
       RAISERROR (N'SQL Server Change Tracking has cleaned up tracking information for table ''%s''...

Czy ktoś jeszcze doświadczył tej zmiany w zachowaniu? Czy ktoś ma wyjaśnienie?

Nie używa się wersji min_valid_version do śledzenia zmian. Służy to tylko do sprawdzania poprawności, jeśli klient musi zostać ponownie zainicjowany, jeśli metadane zostały wyczyszczone, zanim klient będzie mógł wprowadzić zmiany.

CHANGE_TRACKING_MIN_VALID_VERSION (Transact-SQL)

Uzyskuje minimalną wersję, która jest ważna do użycia podczas uzyskiwania informacji o śledzeniu zmian z określonej tabeli podczas korzystania z tej CHANGETABLEfunkcji.

Min_valid_version zmienia się wraz z wersją czyszczenia i nie zależy od zmian w tabeli użytkowników. Za każdym razem, gdy uruchamia się wątek czyszczenia, aktualizacja min_valid_version może być aktualizowana niezależnie od zmian danych.

Przed 2012 r. Min_valid_version był oznaczony tak samo jak wersja czyszczenia, podczas gdy w rzeczywistości powinien być o jeden więcej niż wersja czyszczenia, ponieważ metadane dla tej wersji zostały już usunięte. W 2012 r. Zmienili to, aby upewnić się, że zaktualizowali właściwą wersję min_valid_version.

Nie należy śledzić zmian za pomocą min_valid_version, zamiast tego należy zapisywać ostatnią synchronizację po każdej synchronizacji i wywoływać, CHANGETABLEaby wyliczyć zmiany po ostatniej wersji synchronizacji.

Zgodnie z projektem - minimalna poprawna wersja zmienia się wraz z wersją czyszczenia i nie zależy od zmian w tabeli użytkowników. Przy każdym uruchomieniu wątku czyszczenia może istnieć aktualizacja minimalnej prawidłowej wersji, niezależnie od zmian danych.

Rozwiązanie - zmień procedurę na „bieżąca_wersja” zamiast „min_valid_version”