Naprawdę nie masz zbyt wielu sposobów wykrywania zmian w SQL 2005. Większość z nich już wymieniłeś.
Powiadomienia o zapytaniach . Jest to technologia, która napędza SqlDependency i jej pochodne. Więcej szczegółów znajdziesz na Tajemnicze powiadomienie . Ale QN ma na celu unieważnienie wyniki, a nie proaktywnie powiadamiać o zmianach treści. Będziesz wiedział tylko, że stół się zmienił, nie wiedząc, co się zmieniło. W obciążonym systemie to nie zadziała, ponieważ powiadomienia będą pojawiać się w sposób ciągły.
Czytanie dziennika . Właśnie tego używa replikacja transakcyjna i jest to najmniej inwazyjny sposób wykrywania zmian. Niestety jest dostępny tylko dla komponentów wewnętrznych. Nawet jeśli zdołasz zrozumieć format dziennika, problem polega na tym, że potrzebujesz wsparcia ze strony silnika, aby oznaczyć dziennik jako „w użyciu” do czasu jego przeczytania lub może zostać nadpisany. Tylko replikacja transakcyjna może wykonać tego rodzaju specjalne oznaczenie.
Porównanie danych . Polegaj na kolumnach sygnatury czasowej, aby wykrywać zmiany. Jest również oparty na ściąganiu, dość inwazyjny i ma problemy z wykrywaniem usunięcia.
Warstwa aplikacji . Jest to teoretycznie najlepsza opcja, chyba że zachodzą zmiany w danych poza zakresem aplikacji, w którym to przypadku się rozpada. W praktyce są zawsze zmiany zachodzące poza zakresem aplikacji.
Wyzwalacze . Ostatecznie jest to jedyna realna opcja. Wszystkie mechanizmy zmian oparte na wyzwalaczach działają w ten sam sposób, kolejkują powiadomienie o zmianie do komponentu monitorującego kolejkę.
Zawsze są sugestie, aby wykonać ściśle powiązane, synchroniczne powiadomienie (za pośrednictwem xp_cmdshell, xp_olecreate, CLR, powiadomić za pomocą WCF, jak to nazwać), ale wszystkie te schematy zawodzą w praktyce, ponieważ są zasadniczo wadliwe:
- nie uwzględniają spójność transakcji i wycofywania
- wprowadzają zależności dostępności (system OLTP nie może działać, dopóki powiadamiany komponent nie jest online)
- działają fatalnie, ponieważ każda operacja DML musi czekać na wywołanie RPC w jakiejś formie do ukończenia
Jeśli wyzwalacze faktycznie nie powiadamiają aktywnie słuchaczy, a jedynie umieszczają powiadomienia w kolejce, pojawia się problem z monitorowaniem kolejki powiadomień (kiedy mówię „kolejka”, mam na myśli dowolną tabelę, która działa jak kolejka). Monitorowanie polega na wyciąganiu nowych wpisów w kolejce, co oznacza prawidłowe równoważenie częstotliwości sprawdzania z obciążeniem zmianami i reagowanie na skoki obciążenia. To wcale nie jest trywialne, w rzeczywistości jest bardzo trudne. Jednak istnieje jedna instrukcja w serwerze SQL, która ma semantykę do zablokowania, bez ściągania, aż do udostępnienia zmian:CZEKAJ NA (ODBIERZ) . To znaczy Service Broker. Kilka razy wspomniałeś o SSB w swoim poście, ale słusznie boisz się go wdrożyć z powodu wielkiej niewiadomej. Ale rzeczywistość jest taka, że zdecydowanie najlepiej pasuje do opisanego przez Ciebie zadania.
Nie musisz wdrażać pełnej architektury SSB, w której powiadomienie jest dostarczane przez całą drogę do usługi zdalnej (co i tak wymagałoby zdalnej instancji SQL, nawet Express). Wystarczy oddzielić moment wykrycia zmiany (wyzwalacz DML) od momentu dostarczenia powiadomienia (po zatwierdzeniu zmiany). Do tego wystarczy lokalna kolejka SSB i usługa. W wyzwalaczu WYŚLIJ powiadomienie o zmianie do lokalnego serwisu. Po zatwierdzeniu pierwotnej transakcji DML procedura usługi aktywuje się i dostarcza powiadomienie, używając na przykład CLR. Możesz zobaczyć przykład czegoś podobnego na Asynchroniczny T-SQL .
Jeśli pójdziesz tą ścieżką, musisz nauczyć się kilku sztuczek, aby osiągnąć wysoką przepustowość i musisz zrozumieć koncepcję uporządkowanego dostarczania wiadomości w SSB. Polecam zapoznać się z tymi linkami:
O sposobach wykrywania zmian, SQL 2008 najwyraźniej dodaje nowe opcje:Zmień przechwytywanie danych i śledzenie zmian . Podkreślam „najwyraźniej”, bo nie są to tak naprawdę nowe technologie. CDC wykorzystuje czytnik dzienników i opiera się na istniejących mechanizmach replikacji transakcyjnej. CT używa wyzwalaczy i jest bardzo podobny do istniejących mechanizmów replikacji scalania. Oba są przeznaczone do okazjonalnych połączeń systemy, które wymagają synchronizacji, a zatem nie nadają się do powiadamiania o zmianach w czasie rzeczywistym. Mogą zapełniać tabele zmian, ale pozostajesz z zadaniem monitorowania tych tabel pod kątem zmian, czyli dokładnie od miejsca, w którym zacząłeś.
