Наистина нямате толкова много начини за откриване на промени в SQL 2005. Вече изброихте повечето от тях.
Известия за заявки . Това е технологията, която захранва SqlDependency и нейните производни, можете да прочетете повече подробности на Мистериозното известие . Но QN е проектиран да невалидира резултати, а не за проактивно уведомяване за промяна на съдържанието. Ще знаете само, че таблицата има промени, без да знаете какво се е променило. При натоварена система това няма да работи, тъй като известията ще идват почти непрекъснато.
Четене на журнал . Това е, което репликацията на транзакции използва и е най-малко натрапчивият начин за откриване на промени. За съжаление е достъпно само за вътрешни компоненти. Дори и да успеете да разберете формата на дневника, проблемът е, че имате нужда от поддръжка от двигателя, за да маркирате дневника като „в употреба“, докато не го прочетете, или той може да бъде презаписан. Само репликацията на транзакции може да направи този вид специално маркиране.
Сравнение на данни . Разчитайте на колони с клеймо за време, за да откриете промени. Също така е базиран на изтегляне, доста натрапчив и има проблеми с откриването на изтривания.
Приложен слой . Това е най-добрият вариант на теория, освен ако не настъпят промени в данните извън обхвата на приложението, в който случай то се разпада. На практика винаги има промени, възникващи извън обхвата на приложението.
Задействания . В крайна сметка това е единственият жизнеспособен вариант. Всички механизми за промяна, базирани на тригери, работят по един и същи начин, те поставят известието за промяна на опашка към компонент, който следи опашката.
Винаги има предложения да се направи тясно свързано, синхронно известяване (чрез xp_cmdshell, xp_olecreate, CLR, известяване с WCF, каквото и да е), но всички тези схеми се провалят на практика, защото са фундаментално погрешни:
- те не го правят отчитат последователността на транзакциите и връщането назад
- те въвеждат зависимости на наличността (OLTP системата не може да продължи, освен ако уведоменият компонент не е онлайн)
- те се представят ужасно, тъй като всяка DML операция трябва да изчака RPC извикване от някаква форма за завършване
Ако тригерите всъщност не уведомяват активно слушателите, а само подреждат известията на опашка, има проблем при наблюдението на опашката за известия (когато казвам „опашка“, имам предвид всяка таблица, която действа като опашка). Мониторингът предполага изтегляне за нови записи в опашката, което означава правилно балансиране на честотата на проверките с натоварването от промени и реагиране на пикове в натоварването. Това изобщо не е тривиално, всъщност е много трудно. Има обаче един израз в SQL сървъра, който има семантиката да блокира, без изтегляне, докато не станат налични промените:ИЗЧАКВАНЕ (ПОЛУЧАВАНЕ) . Това означава Service Broker. Споменахте SSB няколко пъти в публикацията си, но вие с право се страхувате да го разгърнете поради голямата неизвестност. Но реалността е, че той е най-подходящият за задачата, която описахте.
Не е нужно да разгръщате пълна SSB архитектура, където известието се доставя чак до отдалечената услуга (което така или иначе ще изисква отдалечен SQL екземпляр, дори Express). Всичко, което трябва да съучаствате, е да отделите момента, в който промяната е открита (задействането на DML), от момента, в който известието е доставено (след като промяната е ангажирана). За това всичко, от което се нуждаете, е локална SSB опашка и услуга. В тригера ИЗПРАЩАТЕ известие за промяна до местната служба. След като оригиналната DML транзакция се ангажира, сервизната процедура активира и доставя известието, използвайки например CLR. Можете да видите пример за нещо подобно на това в Asynchronous T-SQL .
Ако тръгнете по този път, има някои трикове, които ще трябва да научите, за да постигнете висока пропускателна способност и трябва да разберете концепцията за подредена доставка на съобщения в SSB. Препоръчвам ви да прочетете тези връзки:
- Повторно използване на разговори
- Писене на процедури за брокер на услуги
- Демонстрация на SQL Connections 2007
Относно средствата за откриване на промени, SQL 2008 очевидно добавя нови опции:Change Data Capture and Change Tracking . Подчертавам „очевидно“, тъй като те не са наистина нови технологии. CDC използва четец на журнали и се основава на съществуващите механизми за репликация на транзакции. CT използва тригери и е много подобен на съществуващите механизми за репликация на Merge. И двата са предназначени завременна връзка системи, които трябва да се синхронизират и следователно не са подходящи за известяване за промени в реално време. Те могат да попълват таблиците за промени, но вие оставате със задачата да наблюдавате тези таблици за промени, което е точно откъдето сте започнали.
