Opravdu nemáte tolik způsobů, jak zjistit změny v SQL 2005. Většinu z nich jste již uvedli.
Oznámení o dotazech . Toto je technologie, která pohání SqlDependency a její deriváty, více podrobností si můžete přečíst na Tajemné oznámení . Ale QN je navržen tak, aby zneplatnil výsledky, nikoli proaktivně oznamovat změnu obsahu. Budete vědět pouze to, že tabulka má změny, aniž byste věděli, co se změnilo. Na vytíženém systému to nebude fungovat, protože oznámení budou přicházet prakticky nepřetržitě.
Čtení protokolu . To je to, co transakční replikace používá a je to nejméně rušivý způsob zjišťování změn. Bohužel je k dispozici pouze pro vnitřní komponenty. I když se vám podaří porozumět formátu protokolu, problém je v tom, že potřebujete podporu od enginu, aby bylo možné označit protokol jako „použitý“, dokud jej nepřečtete, jinak může být přepsán. Tento druh speciálního značení může provádět pouze transakční replikace.
Porovnání údajů . Při zjišťování změn se spolehněte na sloupce časových razítek. Je také založen na pull-based, docela rušivý a má problémy s detekcí mazání.
Vrstva aplikace . Toto je teoreticky nejlepší možnost, pokud nedojde ke změnám dat mimo rámec aplikace, v takovém případě se drolí. V praxi existují vždy změny, ke kterým dojde mimo rámec aplikace.
Spouštěče . Nakonec je to jediná schůdná možnost. Všechny mechanismy změn založené na triggerech fungují stejným způsobem, zařazují do fronty oznámení o změně komponentě, která frontu monitoruje.
Vždy existují návrhy, jak provést těsně spojené, synchronní oznámení (prostřednictvím xp_cmdshell, xp_olecreate, CLR, upozornit pomocí WCF, co si jen vzpomenete), ale všechna tato schémata v praxi selhávají, protože jsou zásadně chybná:
- nefungují zohledňují konzistenci transakcí a vrácení zpět
- zavádějí závislosti dostupnosti (systém OLTP nemůže pokračovat, pokud není oznámená komponenta online)
- fungují příšerně, protože každá operace DML musí čekat na volání RPC nějaké formy dokončit
Pokud spouštěče ve skutečnosti aktivně neupozorňují posluchače, ale pouze zařazují oznámení do fronty, nastává problém ve sledování fronty oznámení (když říkám „fronta“, mám na mysli jakoukoli tabulku, která funguje jako fronta). Sledování zahrnuje vyhledávání nových záznamů ve frontě, což znamená správně vyvážit frekvenci kontrol se zatížením změn a reagovat na špičky zatížení. To není vůbec triviální, ve skutečnosti je to velmi obtížné. Na serveru SQL však existuje jeden příkaz, který má sémantiku, kterou lze blokovat bez stahování, dokud nebudou dostupné změny:WAITFOR(RECEIVE) . To znamená Service Broker. Ve svém příspěvku jste několikrát zmínil SSB, ale oprávněně se bojíte jeho nasazení kvůli velké neznámé. Skutečnost je však taková, že pro úkol, který jste popsal, je zdaleka nejlepší.
Nemusíte nasazovat plnou architekturu SSB, kde je oznámení doručeno až do vzdálené služby (to by stejně vyžadovalo vzdálenou instanci SQL, dokonce i expresní). Vše, co potřebujete, je oddělit okamžik, kdy je změna detekována (spouštěč DML), od okamžiku doručení oznámení (po provedení změny). K tomu potřebujete pouze místní SSB frontu a službu. Ve spouštěči ODESLAT oznámení o změně místní službě. Po potvrzení původní transakce DML se procedura služby aktivuje a doručí oznámení, například pomocí CLR. Příklad něčeho podobného můžete vidět na Asynchronní T-SQL .
Pokud se vydáte touto cestou, budete se muset naučit několik triků, abyste dosáhli vysoké propustnosti, a musíte pochopit koncept uspořádaného doručování zpráv v SSB. Doporučuji vám přečíst si tyto odkazy:
Pokud jde o prostředky k detekci změn, SQL 2008 zřejmě přidává nové možnosti:Change Data Capture and Change Tracking . Zdůrazňuji „zřejmě“, protože se ve skutečnosti nejedná o nové technologie. CDC používá čtečku protokolů a je založeno na existujících mechanismech transakční replikace. CT používá spouštěče a je velmi podobný existujícím mechanismům replikace Merge. Oba jsou určeny pro občas připojené systémy, které se potřebují synchronizovat, a proto nejsou vhodné pro oznamování změn v reálném čase. Mohou vyplnit tabulky změn, ale vy máte za úkol sledovat změny v těchto tabulkách, což je přesně tam, kde jste začali.