ทดสอบ Oracle RAC 19c Failover:
FAN vs TAF vs AC บน OCI ARM
รายงานการทดสอบสถาปัตยกรรม High Availability ของ Oracle Database 19c (19.19 RU) บน OCI Ampere A1 Compute (ARM64) จำลองสภาวะ Node Failure เพื่อเปรียบเทียบกลไก FAN, TAF และ Application Continuity (AC)
ทำไมองค์กรต้องสนเทคโนโลยี Oracle RAC High Availability?
ทำความเข้าใจความต่างของทั้ง 3 เทคโนโลยี และประโยชน์ที่องค์กรของคุณจะได้รับใน 1 นาที
Downtime นาน (รอ TCP Timeout)
หากไม่มีระบบสลับสายฉุกเฉิน (FAN) เมื่อเครื่องหลักล่ม แอปพลิเคชันจะต้องคอยรอ TCP Timeout นานถึง 15–30 นาที ส่งผลให้หน้าจอระบบค้างนิ่ง
ธุรกรรมค้างชะงัก (Uncommitted TX Rollback)
คำสั่งซื้อ ชำระเงิน หรือบันทึกข้อมูลสำคัญที่ยังไม่ Commit ขณะเครื่องดับจะถูก Rollback เกิดภาระในการต้องส่งคำสั่งใหม่
ภาระซับซ้อนของ Developer
นักพัฒนาแอปพลิเคชันต้องเสียเวลาเขียนโค้ดจับ Exception (Try-Catch) ซับซ้อน เพื่อสั่งรีไทร์ทำงานใหม่ ซึ่งมักเกิดข้อผิดพลาดพลาดสายตาได้ง่าย
Lab 1: FAN (รู้ตัวไว ตัดสายเร็ว)
เปรียบเสมือน: สัญญาณเตือนภัย
ตัด Connection เสียทิ้งทันทีไม่ต้องรอ 15 นาที เพื่อให้แอปเชื่อมต่อไป Node 2 แต่ ธุรกรรมที่ยังไม่ Commit จะถูก Rollback และเกิด Error
Lab 2: TAF (อ่านข้อมูลต่อเนียนๆ)
เปรียบเสมือน: ย้ายไปอ่านหนังสือต่อจากหน้าเดิม
สลับสายและ Replay คำสั่ง SELECT (อ่านข้อมูล) ให้ต่อได้เนียนๆ แต่ คำสั่งเปลี่ยนข้อมูล (DML) จะถูก Rollback และเกิด Error
Lab 3: AC (ไร้รอยต่อในสภาวะที่กำหนด)
เปรียบเสมือน: มีระบบทำธุรกรรมแทนให้อัตโนมัติ
Replay คำสั่ง (ทั้ง SELECT และ DML ที่เข้าเงื่อนไข) บน Node 2 โดยแอปพลิเคชันไม่พบ Exception Error
ลดความเสี่ยงธุรกรรมค้าง
ช่วยคุ้มครองรายการประมวลผลสำคัญขณะเครื่องหลักเกิดเหตุขัดข้องกะทันหันในสภาพแวดล้อมที่ตั้งค่ารองรับอย่างสมบูรณ์
Planned Maintenance Impact Reduction
ช่วยลดผลกระทบระหว่างทำ OS/Database Patching หรือ Maintenance เมื่อกำหนด Service และ Client Configuration ถูกต้อง
ลดภาระการเขียนโค้ด Business Logic
อาจไม่ต้องปรับแก้ Business Logic ของแอปพลิเคชันเดิม แต่ต้องเลือกใช้ Replay Driver, Connection Pool (เช่น UCP) และ Service Attributes ที่รองรับตามเงื่อนไข Oracle RAC Documentation
สรุปเปรียบเทียบการสลับเครื่อง (Failover) ทั้ง 3 รูปแบบ
เปรียบเทียบคุณสมบัติด้านความเสถียรและผลกระทบต่อผู้ใช้งานของแต่ละเทคโนโลยีบน Oracle RAC
| คุณสมบัติ / การทดสอบ (Feature Test) | 🛑 FAN (Fast App Notification) | 🔄 TAF (Transparent App Failover) | 🏆 AC (Application Continuity) |
|---|---|---|---|
| ระดับความคุ้มครอง (Failover Level) | Connection Level | Statement Level (SELECT) | Transaction Level (DML & SELECT) |
| การสลับสาย Connection เมื่อ Node Down | ✓ สลับทันที (ไม่ต้องรอ Timeout) | ✓ สลับทันที | ✓ สลับทันที |
| การเล่นซ้ำคำสั่ง SELECT (Read Replay) | ✗ ไม่รองรับ (หลุด Error) | ✓ Replay อัตโนมัติ | ✓ Replay อัตโนมัติ |
| การเล่นซ้ำคำสั่ง DML (INSERT/UPDATE) | ✗ Uncommitted TX Rollback (แอปพลิเคชันได้รับ Exception Error) | ✗ Uncommitted DML Rollback (แอปพลิเคชันได้รับ Exception Error) | ✓ Replay Request ที่เข้าเงื่อนไข (ใน Lab นี้บันทึกครบ 30/30 TX) |
| ต้องแก้ไขโค้ดแอปพลิเคชันหรือไม่? | ต้องเขียน Try-Catch ในโค้ด | ต้องเขียน Try-Catch สำหรับ DML | ✓ อาจไม่ต้องแก้ Business Logic (แต่ต้องใช้ Client Configuration ที่รองรับ) |
| ประสบการณ์ผู้ใช้งานหน้าจอ (User Experience) | หลุดจากหน้าจอ / ต้องกดรีเฟรช | หลุดเมื่อกดบันทึกข้อมูล DML | ✓ Demo Application ทำงานต่อเนื่องโดยไม่พบ Error ใน Scenario ที่ทดสอบ |
🛑 Fast Application Notification (FAN) — การตัดการเชื่อมต่อและสลับสายทันทีเมื่อเกิดเหตุขัดข้อง
กลไก Fast Application Notification (FAN) ทำหน้าที่ส่งสัญญาณแจ้งเตือน ONS Event ไปยัง Client Driver ทันทีเมื่อเกิดเหตุการณ์ Node Failure ช่วยให้ Connection Pool ทำการยกเลิก Connection เดิมและสลับไปยัง Node สำรองโดยไม่ต้องรอ TCP Timeout
🔍 คลิกเพื่อขยาย
สถานการณ์ปกติ: การประมวลผลบน Node 1 (orcl1)
ระบบเริ่มต้นทำงานปกติ แอปพลิเคชันเชื่อมต่อไปยัง Node 1 (orcl1) คำสั่ง SQL สามารถประมวลผลได้อย่างรวดเร็วผ่าน Connection Pool
🔄 Transparent Application Failover (TAF) — การประมวลผลคำสั่งอ่านข้อมูลต่อเนื่อง (SELECT Replay)
กลไก TAF ช่วยอำนวยความสะดวกในการสลับ Connection พร้อมความสามารถในการประมวลผลคำสั่ง SELECT ต่อเนื่องจากตำแหน่งเดิม (Statement Replay) ทำให้การเรียกดูข้อมูลหรือรายงานไม่หยุดชะงัก
🔍 คลิกเพื่อขยาย
สถานการณ์ปกติ: การทำงานบน Node 1 (orcl1)
แอปพลิเคชันดึงข้อมูลด้วยคำสั่ง SELECT และทำงานต่อเนื่องบน Node 1 (orcl1)
INSERT, UPDATE, DELETE หรือคำสั่งที่มี Transaction ค้างอยู่ จะเกิด Exception Error ส่งกลับไปยังแอปพลิเคชัน
🏆 Application Continuity (AC) — Transaction Replay ภายใต้เงื่อนไขที่รองรับ (ผลทดสอบ Replay ครบ 30/30 Transactions)
ในสภาพแวดล้อมทดสอบนี้ Application Continuity สามารถ Replay คำสั่ง SELECT และ DML ที่เข้าเงื่อนไขไปยัง Node สำรอง โดย Demo Application ไม่พบ Exception Error ใน Scenario ที่ทดสอบ (หมายเหตุ: การ Replay ในระบบจริงขึ้นอยู่กับ Driver, Session State, Request Boundaries และรูปแบบ Transaction ตามข้อกำหนดของ Oracle 19c RAC Documentation)
🔍 คลิกเพื่อขยาย
แอปพลิเคชันกำลังบันทึกข้อมูลอย่างต่อเนื่องบน orcl1
ระบบรันชุดคำสั่ง DML (INSERT/UPDATE) อย่างต่อเนื่องผ่าน Transaction #01 ถึง #06 บน Node 1 (orcl1)
2-Node Oracle RAC 19.19 ARM64 บน OCI Ampere A1
รวม 4 OCPUs / RAM 24 GB (rac1: 2 OCPUs / 12 GB RAM | rac2: 2 OCPUs / 12 GB RAM)
(Lab นี้จัดทำบนทรัพยากร OCI Ampere A1 ที่ได้รับภายใต้ Free Tier ของบัญชีในช่วงเวลาทดสอบ)
บทสรุปการประเมินประสิทธิภาพสถาปัตยกรรม High Availability
ผลการทดสอบนี้แสดงว่า Oracle RAC 19c ร่วมกับ Application Continuity สามารถรักษาความต่อเนื่องของ Demo Application ภายใต้ Node Failure Scenario ที่กำหนด โดยบันทึกครบ 30/30 Transactions ทั้งนี้ผลลัพธ์ของระบบจริงขึ้นอยู่กับสถาปัตยกรรมและการกำหนดค่าของแต่ละระบบ