กู้คืนการโหลดจาก SQL Server ไปยัง Oracle หลังจาก VPN หลุด
VPN ที่หลุดทำให้ผู้เรียกไม่แน่ใจว่า commit ใน Oracle สำเร็จหรือไม่ ID แบทช์ที่คงทนช่วยให้ตอบคำถามเรื่องการดึงข้อมูล การนำไปใช้ และการกระทบยอดได้ทีละข้อ
การถ่ายโอนระหว่างฐานข้อมูลหยุดชะงักเมื่อ VPN หลุด และ «รันอีกครั้ง» ไม่ใช่แผนกู้คืน การดึงข้อมูลจากต้นทางอาจเสร็จสมบูรณ์แล้ว ปลายทางอาจ commit ไปแล้ว หรือคำตอบอาจสูญหายไประหว่างทางกลับ สามสถานะนี้ต้องดำเนินการต่างกัน และไคลเอนต์ที่รู้จักแค่ «ข้อผิดพลาด» ไม่สามารถแยกแยะได้
วิธีแก้คือเชิงสถาปัตยกรรม: ให้ทุกการรันมีอัตลักษณ์แบทช์ที่คงทน และปล่อยให้ฐานข้อมูลตอบคำถามแทนที่จะให้ไคลเอนต์เดา
ฐานข้อมูลรับประกันอะไรจริง ๆ
SQL Server และ Oracle ต่างให้ความเป็นอะตอมภายในทรานแซกชัน ทั้งคู่ไม่ให้ความเป็นอะตอมข้ามทั้งสอง การเชื่อมต่อที่หลุดไม่ทำให้ฐานข้อมูลเสียหาย และไม่บังคับให้ย้อนกลับด้วยมือ เพราะเซิร์ฟเวอร์แก้ไขทรานแซกชันของตัวเองโดยไม่ต้องพึ่งคุณ สิ่งที่พังคือความรู้ของผู้เรียกเกี่ยวกับผลลัพธ์
commit แยกกันหมายถึง commit แยกกัน VPN ที่พาทั้งสองการเชื่อมต่อไม่ได้หลอมสอง commit เป็นหน่วยงานเดียว
commit ที่คุณไม่เคยได้ยิน
โหมดล้มเหลวหนึ่งลงโทษตรรกะการลองใหม่แบบไร้เดียงสา: เซิร์ฟเวอร์ commit และการตอบรับไม่เคยไปถึงผู้เรียก Oracle บันทึกสิ่งนี้เป็นปัญหาผลลัพธ์ที่ไม่ทราบและมี Transaction Guard สำหรับเรื่องนี้ในเอกสารทรานแซกชัน ข้อผิดพลาดในการสื่อสารไม่ใช่หลักฐานว่า commit ที่ส่งไปล้มเหลว และการปฏิบัติต่อมันเป็นหลักฐานคือวิธีที่แบทช์ถูกโพสต์สองครั้ง ความแตกต่างนี้สำคัญที่สุดในเส้นทางการลองใหม่ ซึ่งผู้ปฏิบัติงานมีเพียงข้อความข้อผิดพลาดและไม่มีสัญญาณอื่นให้ดำเนินการ
ดังนั้นขั้นตอนกู้คืนต้องอ่านผลลัพธ์จากปลายทางแทนที่จะอนุมานจากข้อความข้อผิดพลาด
ให้อัตลักษณ์แบทช์แก่การถ่ายโอน
ทุกการรันได้ ID แบทช์ที่ไม่เปลี่ยนแปลง และปลายทางบันทึกว่าทำอะไรกับ ID นั้น วงจรชีวิตมีสี่ขั้นตอน และดูเหมือนกันไม่ว่าผู้ขายรายใด:
- ดึง แบทช์ต้นทางที่ระบุตัวตนได้และไม่เปลี่ยนแปลงพร้อมสคีมาและขอบเขตที่บันทึกไว้
- ถ่ายโอน ไปยังพื้นที่เตรียมของปลายทาง และตรวจจับเนื้อหาที่ไม่สมบูรณ์หรือขัดแย้งก่อนประกาศว่าพร้อม
- นำไปใช้ ภายใต้กฎเฉพาะหรือการล็อกของปลายทางเอง และบันทึกการเสร็จสิ้นในทรานแซกชันภายในเดียวกัน
- กระทบยอด ผลลัพธ์ที่คงทนผ่านโปรโตคอลที่รองรับก่อนยืนยันหรือลองใหม่
การลองใหม่ใช้ ID เดิม ID ใหม่ต่อการพยายามแต่ละครั้งทำลายการป้องกันข้อมูลซ้ำที่คุณเพิ่งสร้าง ซึ่งดูเหมือนชัดเจนจนกว่าตัวห่อการลองใหม่จะสร้างขึ้นมาอัตโนมัติ
ID ยังให้สิ่งที่คุณจะกระทบยอดในภายหลังได้ นานหลังจากกระบวนการไคลเอนต์หายไป
Claim แบทช์ แล้วจึงนำไปใช้
ขั้นตอนการนำไปใช้ต้อง claim ID แบทช์ ทำการเปลี่ยนแปลงทางธุรกิจ และบันทึกการเสร็จสิ้นในทรานแซกชันภายในเดียว การทำการตรวจสอบและการแทรกเป็นคำสั่งแยกกันจะนำการแข่งขันที่คุณพยายามกำจัดกลับมา หากผู้ทำงานสองคนแข่งขันกัน จะมีเพียงการ claim เดียวที่ชนะและอีกคนได้รับแจ้ง
การไม่มีบันทึกการเสร็จสิ้นไม่ใช่หลักฐานว่าทรานแซกชันที่กำลังดำเนินอยู่จะไม่ commit ตลอดไป การ claim ต้องทำให้ความพยายามที่แข่งขันกันเป็นลำดับ หรือโปรโตคอลต้องอ่านผลลัพธ์ที่คงทนก่อนตัดสินใจใด ๆ
สำหรับการทำให้เป็นลำดับนั้น ให้ใช้กลไกที่ฐานข้อมูลรองรับแทนลูปตรวจสอบแล้วทำซ้ำในโค้ดแอปพลิเคชัน
สิ่งที่การออกแบบยังรับประกันไม่ได้
การเตรียมทำให้งานเริ่มใหม่ได้และลดการพึ่งพาเซสชันยาวหนึ่งเซสชัน แต่ไม่ได้สร้าง commit แบบอะตอมเดียวข้าม SQL Server, Oracle และผลข้างเคียงภายนอกใด ๆ ที่งานทำ หากธุรกิจต้องการสิ่งนั้นจริง ๆ ให้ออกแบบและตรวจสอบคุณสมบัติของทรานแซกชันแบบกระจายที่รองรับหรือกระบวนการกระทบยอด รวมถึงใครเป็นเจ้าของงานที่ผลลัพธ์ไม่แน่นอน สิ่งใดที่อ่อนกว่านั้นอยู่ในรันบุ๊กการกระทบยอด ไม่ใช่ในโค้ดถ่ายโอน
ยอมรับการหยุดชะงักในสามจุด: ระหว่างการถ่ายโอน ระหว่างการนำไปใช้ และหลัง commit แต่ก่อนการยืนยัน จากนั้นตรวจสอบผลลัพธ์ทางธุรกิจแทนข้อความของไคลเอนต์ และให้บัญชีแบทช์บอกว่างานยังไม่สมบูรณ์ commit แล้ว หรือยังแก้ไม่เสร็จ