VPN düştükten sonra SQL Server'dan Oracle'a yüklemeyi kurtarma

VPN düştüğünde veritabanları arası transfer ölür ve «yeniden çalıştır» bir kurtarma planı değildir. Kaynaktan çıkarma tamamlanmış olabilir, hedef zaten commit yapmış olabilir veya yanıt dönüş yolunda basitçe kaybolmuş olabilir. Bu üç durum farklı eylemler gerektirir ve yalnızca «hata» bilen bir istemci bunları ayırt edemez.

Çözüm mimaridir: her çalıştırmaya dayanıklı bir toplu iş kimliği verin ve istemcinin tahmin etmesine izin vermek yerine veritabanlarının soruları yanıtlamasına izin verin.

Veritabanı gerçekte neyi garanti eder

SQL Server ve Oracle, bir işlem içinde atomiklik sağlar. Hiçbiri ikisi arasında atomiklik sağlamaz. Kaybolan bağlantı veritabanına zarar vermez ve elle geri alma zorlamaz, çünkü sunucu kendi işlemini siz olmadan çözer. Kırılan şey, çağıranın sonuç hakkındaki bilgisidir.

Ayrı commit, ayrı commit demektir. İki bağlantıyı taşıyan bir VPN, iki commit'i tek bir iş biriminde birleştirmez.

Hiç duymadığınız commit

Bir arıza modu saf yeniden deneme mantığını cezalandırır: sunucu commit yapar ve onay çağırana asla ulaşmaz. Oracle bunu bilinmeyen sonuç sorunu olarak belgeler ve bunun için işlem belgelerinde Transaction Guard sunar. Bir iletişim hatası, gönderilen bir commit'in başarısız olduğunun kanıtı değildir ve onu kanıt olarak ele almak, bir toplu işin iki kez gönderilmesinin yoludur. Bu ayrım en çok yeniden deneme yolunda önemlidir; burada operatörün elinde bir hata mesajı vardır ve harekete geçmek için başka bir sinyal yoktur.

Bu nedenle kurtarma adımı sonucu hata metninden çıkarmak yerine hedeften okumalıdır.

Transferi bir toplu iş kimliğine kavuşturun

Her çalıştırma değişmez bir toplu iş ID'si alır ve hedef o ID ile ne yaptığını kaydeder. Yaşam döngüsü dört adımdır ve satıcıdan bağımsız olarak aynı görünür:

1. Çıkar kaydedilmiş şema ve sınırla tanımlanmış, değişmez kaynak toplu işini.
2. Aktar onu hedefin hazırlık alanına ve hazır ilan etmeden önce eksik veya çelişkili içeriği tespit et.
3. Uygula onu hedefin kendi benzersizlik veya kilitleme kuralları altında ve tamamlanmayı aynı yerel işlemde kaydet.
4. Mutabakat et dayanıklı sonucu desteklenen protokol aracılığıyla, onaylamadan veya yeniden denemeden önce.

Yeniden denemeler aynı ID'yi kullanır. Her deneme için yeni bir ID, yeni kurduğunuz yinelenen engellemeyi boşa çıkarır; bu, bir yeniden deneme sarmalayıcısı otomatik olarak bir tane üretene kadar açık görünür.

ID ayrıca size daha sonra mutabakat yapacağınız bir şey verir; istemci süreci çoktan kaybolduktan çok sonra bile.

Toplu işi talep edin, sonra uygulayın

Uygulama adımı toplu iş ID'sini talep etmeli, iş değişikliklerini yapmalı ve tamamlanmayı tek bir yerel işlemde kaydetmelidir. Kontrolü ve eklemeyi ayrı ifadeler olarak yapmak, kaldırmaya çalıştığınız yarışı geri getirir. İki çalışan yarışırsa tam olarak bir talep kazanır ve diğerine bu bildirilir.

Tamamlama kaydının olmaması, devam eden bir işlemin asla commit yapmayacağının kanıtı değildir. Talep, rekabet eden denemeleri sıralamalı veya protokol herhangi bir karardan önce dayanıklı sonucu okumalıdır.

Bu sıralama için uygulama kodunda bir denetle-ve-yinele döngüsü yerine veritabanının desteklenen mekanizmasını kullanın.

Tasarımın hâlâ vaat edemeyeceği şey

Hazırlık, işi yeniden başlatılabilir kılar ve tek bir uzun ömürlü oturuma bağımlılığı azaltır. SQL Server, Oracle ve işin gerçekleştirdiği herhangi bir dış yan etki genelinde tek bir atomik commit yaratmaz. İş gerçekten buna ihtiyaç duyuyorsa, desteklenen bir dağıtılmış işlem veya mutabakat süreci tasarlayın ve nitelendirin; sonucu belirsiz işin kime ait olduğu da dahil. Bundan daha zayıf olan her şey transfer koduna değil, mutabakat el kitabına aittir.

Kesintiyi üç yerde kabul edin: transfer sırasında, uygulama sırasında ve commit'ten sonra ama onaydan önce. Ardından istemcinin mesajı yerine iş sonucunu kontrol edin ve toplu iş defterinin işin tamamlanmadığını, commit edildiğini veya hâlâ çözülmediğini söylemesine izin verin.