Аднаўленне загрузкі з SQL Server у Oracle пасля разрыву VPN

Міжбазавы перанос памірае, калі VPN разрываецца, а «запусціць яшчэ раз» — не план аднаўлення. Выманне з крыніцы можа быць завершана, мэта можа ўжо зафіксаваць змены, а адказ можа проста згубіцца на зваротным шляху. Гэтыя тры станы патрабуюць розных дзеянняў, і кліент, які ведае толькі «памылка», не можа іх адрозніць.

Рашэнне архітэктурнае: дайце кожнаму запуску ўстойлівую ідэнтычнасць пакета і дазвольце базам даных адказваць на пытанні замест таго, каб кліент здагадваўся.

Што база даных насамрэч гарантуе

SQL Server і Oracle абодва забяспечваюць атамарнасць унутры транзакцыі. Ні адзін не дае атамарнасці паміж імі двума. Страчанае злучэнне не псуе базу даных і не прымушае да ручнога адкату, бо сервер вырашае сваю транзакцыю без вас. Ламаецца тое, што выклікальнік ведае пра вынік.

Зафіксавана асобна — значыць зафіксавана асобна. VPN, які нясе абодва злучэнні, не злівае дзве фіксацыі ў адну адзінку працы.

Фіксацыя, пра якую вы ніколі не чулі

Адзін рэжым збою карае наіўную логіку паўтору: сервер фіксуе змены, а пацвярджэнне ніколі не даходзіць да выклікальніка. Oracle дакументуе гэта як праблему невядомага выніку і прапануе для яе Transaction Guard у дакументацыі па транзакцыях. Памылка сувязі не з’яўляецца доказам таго, што адпраўленая фіксацыя не ўдалася, і стаўленне да яе як да доказу — гэта шлях да двойчы адпраўленага пакета. Розніца найбольш важная на шляху паўтору, дзе ў аператара ёсць паведамленне пра памылку і больш ніякага сігналу для дзеянняў.

Такім чынам, крок аднаўлення павінен чытаць вынік з мэты, а не выводзіць яго з тэксту памылкі.

Дайце пераносу ідэнтычнасць пакета

Кожны запуск атрымлівае незмяняльны ідэнтыфікатар пакета, і мэта запісвае, што яна зрабіла з гэтым ідэнтыфікатарам. Жыццёвы цыкл складаецца з чатырох крокаў і выглядае аднолькава незалежна ад пастаўшчыка:

1. Выманне вызначанага, незмяняльнага пакета крыніцы з запісанай схемай і межамі.
2. Перанос яго ў падрыхтоўчую вобласць мэты і выяўленне няпоўнага або супярэчлівага змесціва перад абвяшчэннем гатоўнасці.
3. Прымяненне пад уласнымі правіламі ўнікальнасці або блакіроўкі мэты і запіс завяршэння ў той жа лакальнай транзакцыі.
4. Зверка ўстойлівага выніку праз падтрымоўваны пратакол перад пацвярджэннем або паўторам.

Паўторы выкарыстоўваюць той жа ідэнтыфікатар. Новы ідэнтыфікатар на кожную спробу знішчае прадухіленне дублікатаў, якое вы толькі што пабудавалі; гэта гучыць відавочна, пакуль абгортка паўтору не згенеруе яго аўтаматычна.

Ідэнтыфікатар таксама дае вам з чым зверыць пазней, праз доўгі час пасля знікнення працэсу кліента.

Займіце пакет, затым прымяніце

Крок прымянення павінен заняць ідэнтыфікатар пакета, зрабіць бізнес-змены і запісаць завяршэнне ў адной лакальнай транзакцыі. Выкананне праверкі і ўстаўкі асобнымі аператарамі вяртае гонку, якую вы спрабавалі прыбраць. Калі два працоўнікі спаборнічаюць, роўна адно займанне перамагае, а другому паведамляюць пра гэта.

Адсутнасць запісу завяршэння не з’яўляецца доказам таго, што транзакцыя ў працэсе ніколі не зафіксуецца. Займанне павінна серыялізаваць канкуруючыя спробы, або пратакол павінен прачытаць устойлівы вынік перад любым рашэннем.

Выкарыстоўвайце падтрымоўваны механізм базы даных для гэтай серыялізацыі, а не цыкл «правер і паўтары» ў кодзе праграмы.

Што дызайн усё яшчэ не можа абяцаць

Падрыхтоўка робіць працу перазапускальнай і змяншае залежнасць ад адной доўгай сесіі. Яна не стварае адзіную атамарную фіксацыю праз SQL Server, Oracle і любы знешні пабочны эфект, які выконвае праца. Калі бізнесу гэта сапраўды патрэбна, спраектуйце і пракваліфікуйце падтрымоўваную размеркаваную транзакцыю або працэс зверкі, уключаючы, хто валодае працай з няпэўным вынікам. Усё, што слабейшае за гэта, належыць у інструкцыю па зверцы, а не ў код пераносу.

Прыміце перапынак у трох месцах: падчас пераносу, падчас прымянення і пасля фіксацыі, але да пацвярджэння. Затым праверце бізнес-вынік, а не паведамленне кліента, і дайце рэестру пакетаў сказаць, ці праца няпоўная, зафіксаваная або ўсё яшчэ нявырашаная.