Atjaunot ielādi no SQL Server uz Oracle pēc VPN pārrāvuma

Starpdatubāzu pārsūtīšana mirst, kad VPN pārtrūkst, un „palaid to vēlreiz“ nav atjaunošanas plāns. Avota izguve var būt pabeigta, mērķis var būt jau veicis commit, vai arī atbilde vienkārši pazuda atceļā. Šiem trim stāvokļiem vajadzīgas dažādas darbības, un klients, kas zina tikai „kļūda“, tos nevar atšķirt.

Risinājums ir arhitektonisks: piešķiriet katram izpildījumam ilgstošu partijas identitāti un ļaujiet datubāzēm atbildēt uz jautājumiem, nevis ļaut klientam minēt.

Ko datubāze patiešām garantē

SQL Server un Oracle abas nodrošina atomiskumu darījuma ietvaros. Neviena nenodrošina atomiskumu starp abām. Zaudēts savienojums nesabojā datubāzi un neuzspiež arī manuālu atritināšanu, jo serveris pats atrisina savu darījumu bez jums. Tas, kas salūzt, ir izsaucēja zināšanas par rezultātu.

Atsevišķi commitots nozīmē atsevišķi commitots. VPN, kas pārvadā abus savienojumus, nesapludina divus commit vienā darba vienībā.

Commit, par kuru jūs nekad neesat dzirdējuši

Viens kļūmes režīms soda naivu atkārtošanas loģiku: serveris veic commit, un apstiprinājums nekad nesasniedz izsaucēju. Oracle dokumentē to kā nezināma rezultāta problēmu un tam nodrošina Transaction Guard darījumu dokumentācijā. Sakaru kļūda nav pierādījums, ka nosūtītais commit neizdevās, un izturēties pret to kā pret pierādījumu ir veids, kā partija tiek publicēta divreiz. Šī atšķirība ir vissvarīgākā atkārtošanas ceļā, kur operatoram ir kļūdas ziņojums un nekāds cits signāls, pēc kā rīkoties.

Tāpēc atjaunošanas solim ir jālasa rezultāts no mērķa, nevis jāsecina tas no kļūdas teksta.

Piešķiriet pārsūtīšanai partijas identitāti

Katrs izpildījums saņem nemainīgu partijas ID, un mērķis reģistrē, ko tas ar šo ID izdarīja. Dzīves cikls ir četri soļi, un tas izskatās vienādi neatkarīgi no piegādātāja:

1. Izgūstiet identificētu, nemainīgu avota partiju ar reģistrētu shēmu un robežu.
2. Pārsūtiet to uz mērķa sagatavošanas apgabalu un atklājiet nepilnīgu vai pretrunīgu saturu pirms pasludināšanas par gatavu.
3. Piemērojiet to saskaņā ar mērķa paša unikalitātes vai bloķēšanas noteikumiem un reģistrējiet pabeigšanu tajā pašā vietējā darījumā.
4. Saskaņojiet ilgstošo rezultātu ar atbalstīto protokolu pirms apstiprināšanas vai atkārtošanas.

Atkārtojumi izmanto to pašu ID. Jauns ID katram mēģinājumam iznīcina tikko uzbūvēto dublikātu novēršanu, kas šķiet pašsaprotami, līdz atkārtošanas ietvars automātiski ģenerē vienu.

ID arī dod jums kaut ko, ar ko vēlāk saskaņot, ilgi pēc tam, kad klienta process ir pazudis.

Pieprasiet partiju, pēc tam piemērojiet

Piemērošanas solim ir jāpieprasa partijas ID, jāveic biznesa izmaiņas un jāreģistrē pabeigšana vienā vietējā darījumā. Pārbaudes un ievietošanas veikšana kā atsevišķi priekšraksti atgriež sacensību, ko centāties novērst. Ja divi darbinieki sacenšas, uzvar tieši viens pieprasījums, un otram to paziņo.

Trūkstošs pabeigšanas ieraksts nav pierādījums, ka notiekošais darījums nekad neveiks commit. Pieprasījumam ir jāserializē konkurējošie mēģinājumi, vai arī protokolam pirms jebkāda lēmuma ir jāizlasa ilgstošais rezultāts.

Šai serializācijai izmantojiet atbalstīto datubāzes mehānismu, nevis pārbaudi-un-atkārto cilpu lietojumprogrammas kodā.

Ko dizains joprojām nevar apsolīt

Sagatavošana padara darbu atsākamu un samazina atkarību no vienas ilglaicīgas sesijas. Tā neveido vienu atomisku commit pāri SQL Server, Oracle un jebkurai ārējai blakusiedarbībai, ko darbs veic. Ja biznesam tas patiešām ir vajadzīgs, projektējiet un kvalificējiet atbalstītu sadalītu darījumu vai saskaņošanas procesu, tostarp to, kam pieder darbs ar neskaidru rezultātu. Viss vājākais par to pieder saskaņošanas rokasgrāmatai, nevis pārsūtīšanas kodam.

Pieņemiet pārtraukumu trijās vietās: pārsūtīšanas laikā, piemērošanas laikā un pēc commit, bet pirms apstiprināšanas. Pēc tam pārbaudiet biznesa rezultātu, nevis klienta ziņojumu, un ļaujiet partiju grāmatai pateikt, vai darbs ir nepilnīgs, commitots vai vēl neatrisināts.