Възстановяване на зареждане от SQL Server към Oracle след прекъсване на VPN

Междубазов трансфер умира, когато VPN прекъсне, а „пусни го отново“ не е план за възстановяване. Извличането от източника може да е завършено, целта може вече да е направила commit или отговорът просто да се е загубил по пътя обратно. Тези три състояния изискват различни действия и клиент, който познава само „грешка“, не може да ги различи.

Решението е архитектурно: дайте на всяко изпълнение устойчива идентичност на партида и оставете базите данни да отговарят на въпроси, вместо клиентът да гадае.

Какво всъщност гарантира базата данни

SQL Server и Oracle дават атомарност в рамките на транзакция. Нито една не дава атомарност между двете. Загубената връзка не поврежда базата данни и не налага ръчно връщане назад, защото сървърът решава собствената си транзакция без вас. Счупено е знанието на извикващия за резултата.

Отделно комитнато означава отделно комитнато. VPN, който носи двете връзки, не слива два commit-а в една единица работа.

Commit-ът, за който никога не сте чували

Един режим на отказ наказва наивната логика за повторение: сървърът прави commit и потвърждението никога не стига до извикващия. Oracle документира това като проблема с неизвестния резултат и предоставя Transaction Guard за него в документацията за транзакции. Комуникационната грешка не е доказателство, че подаден commit се е провалил, и третирането ѝ като доказателство е начинът партида да бъде публикувана два пъти. Разликата е най-важна по пътя на повторението, където операторът има съобщение за грешка и никакъв друг сигнал, на който да действа.

Затова стъпката за възстановяване трябва да прочете резултата от целта, вместо да го изведе от текста на грешката.

Дайте на трансфера идентичност на партида

Всяко изпълнение получава неизменяем идентификатор на партида и целта записва какво е направила с този идентификатор. Жизненият цикъл е четири стъпки и изглежда еднакво независимо от доставчика:

1. Извличане на идентифицирана, неизменяема партида източник със записана схема и граници.
2. Трансфер в подготвителната област на целта и откриване на непълно или противоречиво съдържание преди обявяване за готово.
3. Прилагане под собствените правила за уникалност или заключване на целта и записване на завършването в същата локална транзакция.
4. Сверка на устойчивия резултат чрез поддържания протокол преди потвърждение или повторение.

Повторенията използват същия идентификатор. Нов идентификатор за всяко опита проваля предотвратяването на дубликати, което току-що изградихте; това звучи очевидно, докато обвивка за повторение не генерира такъв автоматично.

Идентификаторът ви дава и срещу какво да правите сверка по-късно, дълго след като процесът на клиента е изчезнал.

Займете партидата, след което приложете

Стъпката на прилагане трябва да заеме идентификатора на партидата, да направи бизнес промените и да запише завършването в една локална транзакция. Ако проверката и вмъкването са отделни оператори, състезанието, което се опитвахте да премахнете, се връща. Ако двама работници се състезават, точно едно заемане печели, а другият получава съобщение за това.

Липсващият запис за завършване не е доказателство, че текуща транзакция никога няма да направи commit. Заемането трябва да сериализира конкуриращите опити или протоколът трябва да прочете устойчивия резултат, преди да реши каквото и да е.

Използвайте поддържания механизъм на базата данни за тази сериализация, вместо цикъл „провери и повтори“ в приложния код.

Какво дизайнът все още не може да обещае

Подготвителната област прави работата рестартируема и намалява зависимостта от една дълготрайна сесия. Тя не създава единен атомарен commit през SQL Server, Oracle и какъвто и да е външен страничен ефект, който работата извършва. Ако бизнесът наистина се нуждае от това, проектирайте и квалифицирайте поддържана разпределена транзакция или процес на сверка, включително кой притежава работата с несигурен изход. Всичко по-слабо от това принадлежи в процедура за сверка, а не в кода за трансфер.

Приемете прекъсване на три места: по време на трансфера, по време на прилагането и след commit, но преди потвърждението. След това проверете бизнес резултата, а не съобщението на клиента, и оставете регистъра на партидите да каже дали работата е непълна, комитната или все още нерешена.