Враќање на вчитувањето од SQL Server во Oracle по падот на VPN

Преносот меѓу бази на податоци умира кога VPN-от паѓа, а „пушти го повторно“ не е план за враќање. Извлекувањето од изворот може да е завршено, целта може веќе да има направено commit, или одговорот едноставно се изгубил на патот назад. Овие три состојби бараат различни постапки, а клиент што знае само „грешка“ не може да ги разликува.

Решението е архитектонско: дајте ѝ на секое извршување трајна идентификација на партида и дозволете базите на податоци да одговараат на прашањата наместо клиентот да погодува.

Што всушност гарантира базата на податоци

SQL Server и Oracle и двете даваат атомичност внатре во трансакцијата. Ниту една не ви дава атомичност меѓу двете. Изгубената врска не ја расипува базата на податоци и не наметнува рачно враќање, зашто серверот сам ја решава својата трансакција без вас. Она што се крши е знаењето на повикувачот за исходот.

Одделно commit-ирано значи одделно commit-ирано. VPN што ги носи двете врски не спојува два commit-а во една работна единица.

Commit-от за кој никогаш не сте слушнале

Еден режим на отказ ја казнува наивната логика за повторување: серверот прави commit, а потврдата никогаш не стигнува до повикувачот. Oracle го документира ова како проблем на непознат исход и за него обезбедува Transaction Guard во документацијата за трансакции. Комуникациска грешка не е доказ дека испратениот commit не успеал, а третирањето како доказ е начинот на кој партидата се објавува двапати. Оваа разлика е најважна на патот на повторување, каде операторот има порака за грешка и никаков друг сигнал за дејствување.

Затоа чекорот за враќање мора да го чита исходот од целта, наместо да го изведува од текстот на грешката.

Дајте ѝ идентификација на партида на преносот

Секое извршување добива непроменлива ID на партида, а целта запишува што направила со таа ID. Животниот циклус е четири чекори и изгледа исто без оглед на добавувачот:

1. Извлечете идентификувана, непроменлива изворна партида со запишана шема и граница.
2. Пренесете ја во подготвителната област на целта и откријте нецелосна или противречна содржина пред да ја прогласите за подготвена.
3. Применете ја според сопствените правила за единственост или заклучување на целта и запишете го завршувањето во истата локална трансакција.
4. Усогласете го трајниот исход преку поддржаниот протокол пред потврдување или повторување.

Повторувањата ја користат истата ID. Нова ID за секој обид ја поткопува спречувањето дупликати што штотуку го изградивте, што звучи очигледно додека обвивката за повторување не генерира една автоматски.

ID-то ви дава и нешто против што подоцна да се усогласувате, долго откако процесот на клиентот ќе исчезне.

Заземете ја партидата, потоа применете ја

Чекорот на примена мора да ја заземе ID-то на партидата, да ги направи деловните промени и да го запише завршувањето во една локална трансакција. Правењето на проверката и вметнувањето како одделни наредби ја враќа трката што се обидовте да ја отстраните. Ако двајца работници се натпреваруваат, точно едно заземање победува, а другиот е известен за тоа.

Отсутен запис за завршување не е доказ дека трансакцијата во тек никогаш нема да направи commit. Заземањето мора да ги серијализира конкурентните обиди, или протоколот мора да го прочита трајниот исход пред каква било одлука.

За таа серијализација користете го поддржаниот механизам на базата на податоци, наместо јамка провери-па-повтори во кодот на апликацијата.

Што дизајнот уште не може да вети

Подготовката ја прави работата рестартабилна и ја намалува зависноста од една долготрајна сесија. Таа не создава еден атомски commit низ SQL Server, Oracle и каков било надворешен несакан ефект што работата го извршува. Ако на бизнисот навистина му треба тоа, дизајнирајте и квалификувајте поддржана дистрибуирана трансакција или процес на усогласување, вклучително и кој го поседува работата со неизвесен исход. Сето послабо од тоа припаѓа во прирачникот за усогласување, не во кодот за пренос.

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