In lading fan SQL Server nei Oracle weromhelje neidat de VPN falt
In fallen VPN lit de oanropper ûnwis oft de Oracle-commit trochgien is. In duorsume batch-ID lit útlûke, tapasse en ôfstimming ien foar ien beäntwurdzje.
In transfer tusken databanken stjert as de VPN falt, en „doch it nochris“ is gjin herstelplan. De útname út 'e boarne kin klear wêze, it doel kin al commit dien hawwe, of it antwurd kin gewoan ûnderweis werom ferlern gien wêze. Dy trije steaten freegje om ferskillende aksjes, en in klant dy't allinnich „flater“ ken, kin se net útinoar hâlde.
De oplossing is arsjitektoanysk: jou elke run in duorsume batch-identiteit, en lit de databanken freegjen beäntwurdzje ynstee fan de klant te litten rieden.
Wat de databank eins garandearret
SQL Server en Oracle jouwe beide atomisiteit binnen in transaksje. Gjinien jout dy atomisiteit oer beide hinne. In ferlern ferbining beskeadiget de databank net en twingt ek gjin hânmjittige rollback ôf, om't de tsjinner syn eigen transaksje sûnder dy oplost. Wat brekt, is de kennis fan 'e oanropper oer de útkomst.
Apart commit betsjut apart commit. In VPN dy't beide ferbiningen draacht, smeltet twa commits net ta ien wurkeenheid.
De commit dêr'tsto noait fan heard hast
Ien flatermodus straft naïve weromprobeare-logika: de tsjinner commit, en de befêstiging berikt de oanropper nea. Oracle dokumintearret dit as it probleem fan 'e ûnbekende útkomst en biedt dêrfoar Transaction Guard yn 'e transaksjedokumintaasje. In kommunikaasjeflater is gjin bewiis dat in ferstjoerde commit mislearre is, en it as bewiis behannelje is hoe't in batch twa kear pleatst wurdt. It ferskil jildt it meast op it weromprobearepaad, dêr't de operator in flaterberjocht hat en gjin oar sinjaal om op te hanneljen.
Dat moat de herstelstap de útkomst by it doel lêze ynstee fan dy út 'e flatertekst ôf te lieden.
Jou de transfer in batch-identiteit
Elke run krijget in ûnferoarlike batch-ID, en it doel registrearret wat it mei dy ID dien hat. De libbenssyklus hat fjouwer stappen, en hy sjocht der itselde út los fan 'e leveransier:
- Útlûk in identifisearre, ûnferoarlike boarnebatch mei in registrearre skema en grins.
- Oerbring it nei it tariedingsgebiet fan it doel en ûntdek ûnfolsleine of tsjinstridige ynhâld foardat it klear ferklearre wurdt.
- Tapas it ûnder de eigen unisiteit- of beskoattelingsregels fan it doel en registrearje de foltôging yn deselde lokale transaksje.
- Ôfstim de duorsume útkomst fia it stipe protokol foardat der befêstige of opnij besocht wurdt.
Weromprobaaren brûke deselde ID. In nije ID per besykjen ûndergraaft de duplikaatprevinsje dy'tsto krekt boud hast, wat fanselssprekkend klinkt oant in weromprobeare-wrapper automatysk ien generearret.
De ID jout dy ek eat om letter tsjin ôf te stimmen, lang neidat it klantproses fuort is.
Fertel it batch op, tapas it dan
De tapassingsstap moat de batch-ID opeaskje, de saaklike feroarings dwaan en de foltôging yn ien lokale transaksje registrearje. De kontrôle en de ynfoeging as aparte útspraken dwaan, bringt de race werom dy'tsto besochtst fuort te heljen. As twa wurkers om 'e foaroprin stride, wint krekt ien opeask en wurdt de oare dat sein.
In ûntbrekkend foltôgingsrecord is gjin bewiis dat in transaksje dy't oan 'e gong is nea commit sil. De opeask moat konkurrearjende besykjen serialisearje, of it protokol moat de duorsume útkomst lêze foardat der eat besletten wurdt.
Brûk it stipe meganisme fan 'e databank foar dy serialisaasje ynstee fan in kontrolearje-en-werhelje-lus yn 'e applikaasjekoada.
Wat it ûntwerp noch altyd net belove kin
Tarieding makket it wurk werstartber en ferminderet de ôfhinklikens fan ien langduorjende sesje. It makket gjin ien atoombinding oer SQL Server, Oracle en hokker eksterne byeffekt it wurk dan ek útfierd. As it bedriuw dat echt nedich hat, ûntwerp en kwalifisearje dan in stipe ferspraat transaksje of in ôfstimmingsproses, ynklusyf wa't it wurk mei ûnwisse útkomst besit. Alles swakker as dat heart yn in ôfstimmings-runbook, net yn 'e transferkoade.
Akseptearje ûnderbrekking op trije plakken: by de transfer, by it tapassen, en nei commit mar foar befêstiging. Kontrolearje dan it saaklike resultaat ynstee fan it berjocht fan 'e klant, en lit it batchregister sizze oft it wurk ûnfolslein, commit of noch net oplost is.