Oracle AI Database 23.26.2 ช่วยให้คุณสามารถสร้าง standby pluggable database (PDB) และ redo logs ได้ด้วยคำสั่ง Data Guard Broker เพียงคำสั่งเดียว ซึ่งช่วยขจัดขั้นตอนการคัดลอกไฟล์ด้วยตนเองที่เคยทำให้การตั้งค่าการกู้คืนระบบจากภัยพิบัติ (disaster-recovery) ล่าช้ามาอย่างยาวนาน

ทำไมเรื่องนี้ถึงสำคัญ

การสร้าง physical standby PDB จำเป็นต้องมีขั้นตอนการทำงานด้วยตนเองหลายขั้นตอน ได้แก่ การคัดลอกทุก datafile ไปยัง standby container, การสร้าง standby redo logs (SRLs) ด้วยคำสั่ง ALTER ที่ระบุเจาะจง และการตรวจสอบการตั้งค่าทั้งหมดซ้ำอีกครั้ง แต่ละขั้นตอนมีความเสี่ยงที่จะเกิดการพิมพ์ผิด, การลืมไฟล์บางไฟล์ หรือกลุ่ม log ที่ไม่ตรงกัน ซึ่งอาจทำให้การทดสอบการกู้คืนล่าช้า หรือในกรณีที่แย่ที่สุดคือทำให้การทำ failover ล้มเหลว การทำให้กระบวนการนี้เป็นอัตโนมัติจะช่วยลดความเสี่ยงเหล่านั้น และช่วยให้ DBA สามารถไปโฟกัสกับงานในระดับที่สูงขึ้นได้

วิธีการสร้าง standby PDB ในอดีต

ในสถาปัตยกรรมแบบ multitenant, primary CDB (container database) จะเป็นโฮสต์สำหรับ PDB หนึ่งตัวหรือมากกว่า เพื่อปกป้อง PDB ผู้ดูแลระบบจะต้อง:

  • ระบุและคัดลอกแต่ละ datafile จาก primary ไปยัง standby host
  • สร้าง SRLs ด้วยตนเองเพื่อให้มีโครงสร้าง redo-log เหมือนกับ primary
  • รันคำสั่ง RMAN restore หรือ duplicate เพื่อทำให้ standby ทำงานสอดคล้องกัน (in sync)
  • รันขั้นตอนการตรวจสอบหลายขั้นตอนเพื่อให้แน่ใจว่า standby สามารถรองรับการทำ switchover ได้

ขั้นตอนการทำงานนี้อาจใช้เวลาหลายชั่วโมง โดยเฉพาะสำหรับ PDB ขนาดใหญ่ และความผิดพลาดเพียงเล็กน้อยอาจทำให้ standby ไม่สามารถใช้งานได้

สิ่งที่อัปเดต 23.26.2 ทำได้

Oracle AI Database เวอร์ชันล่าสุดได้รวมขั้นตอนที่จำเป็นไว้ใน Data Guard Broker โดยการใช้คำสั่ง ADD PLUGGABLE DATABASE เพียงคำสั่งเดียว broker จะดำเนินการดังนี้:

  1. ลงทะเบียน standby PDB ใหม่กับ primary
  2. คัดลอก datafiles ที่จำเป็นอยู่เบื้องหลัง โดยไม่จำเป็นต้องใช้ RMAN restore หรือการคัดลอกไฟล์ด้วยตนเอง
  3. สร้าง standby redo logs ที่เหมาะสม และเพิ่มเข้าไปใน standby CDB โดยอัตโนมัติ
  4. ปล่อยให้ PDB อยู่ในโหมด READ ONLY พร้อมสำหรับการทำ physical standby switchover

คำสั่งที่ใช้ในการทดสอบคือ:

DGMGRL> ADD PLUGGABLE DATABASE 'amol' AT cdb2
       SOURCE IS 'amol' AT cdb1
       PDBFILENAMECONVERT IS "'/CDB1/','/CDB2/'";

การทดสอบในโลกจริง

ผู้เขียนได้สร้าง standby PDB ชื่อ AMOL บน secondary CDB (cdb2) ที่ทำหน้าที่ mirror กับ primary PDB บน cdb1 โดย broker สามารถดำเนินการเสร็จสิ้นได้ทันที ไม่มีการรัน RMAN restore ไม่พบการคัดลอกไฟล์ด้วยตนเองใน OS logs และกลุ่ม standby redo log ก็ปรากฏขึ้นใน catalog โดยไม่ต้องใช้คำสั่ง ALTER DATABASE ใดๆ

เมื่อเปิด PDB ระบบจะเปลี่ยนเป็นโหมด READ ONLY ซึ่งเป็นการยืนยันสถานะ physical-standby การตรวจสอบ datafiles อย่างรวดเร็วพิสูจน์ให้เห็นว่าไฟล์เหล่านั้นได้รับการจัดเตรียม (provisioned) ไว้ที่ฝั่ง standby แล้ว นอกจากนี้ redo apply ก็กำลังทำงานอยู่ และ broker รายงานว่าการตั้งค่าพร้อมสำหรับการทำ switchover แล้ว

ผลกระทบต่อ DBA

ระบบอัตโนมัตินี้ช่วยลดโอกาสที่จะเกิดความผิดพลาดจากมนุษย์ (human error) และลดเวลาตั้งแต่ขั้นตอนการวางแผนไปจนถึงการใช้งาน standby ในระบบ production ทีมงานสามารถจัดเตรียม standby PDB ได้ภายในไม่กี่นาทีแทนที่จะเป็นหลายชั่วโมง ซึ่งมีค่าอย่างยิ่งสำหรับสภาพแวดล้อมที่มีการเปิดใช้งานบริการใหม่ๆ อยู่บ่อยครั้ง

ข้อแลกเปลี่ยนคือการต้องพึ่งพาตรรกะภายในของ Data Guard Broker มากขึ้น DBA บางคนอาจชอบเขียนสคริปต์แต่ละขั้นตอนด้วยตนเองเพื่อรักษาการควบคุมที่ละเอียด (granular control) หรือเพื่อรวมเข้ากับเครื่องมือตรวจสอบ (monitoring tools) ที่ปรับแต่งเอง ในการตั้งค่าที่ซับซ้อน เช่น มีหลายเครือข่าย, มีการจัดเก็บข้อมูลแบบ heterogeneous หรือมีโครงสร้าง redo layout ที่ไม่เป็นมาตรฐาน ผู้ดูแลระบบอาจยังคงต้องตรวจสอบว่าค่าเริ่มต้น (defaults) ของ broker นั้นสอดคล้องกับนโยบายของตนหรือไม่

สิ่งที่ควรจับตามองต่อไป

Oracle ยังไม่ได้ประกาศการขยายขอบเขตของระบบอัตโนมัตินี้เพิ่มเติม แต่การเคลื่อนไหวนี้บ่งชี้ว่าการปล่อยเวอร์ชันในอนาคตอาจผลักดันขั้นตอนการทำงานของ multitenant DR เข้าสู่ broker มากขึ้น สิ่งที่ควรจับตามองคือ:

  • การรองรับประเภท standby เพิ่มเติม (เช่น logical standby PDBs)
  • การขยายการบันทึก log ที่แสดงการตัดสินใจของ broker เพื่อวัตถุประสงค์ในการตรวจสอบ (audit)
  • การตรวจสอบความเข้ากันได้กับเครื่องมือสำรองข้อมูลจากบุคคลที่สาม (third-party) ที่ก่อนหน้านี้ต้องพึ่งพาขั้นตอน RMAN ด้วยตนเอง

หากองค์กรของคุณใช้งาน Oracle AI Database ในการตั้งค่าแบบ high-availability การทดสอบคำสั่งใหม่บน CDB ที่ไม่ใช่ระบบ production คือวิธีที่เร็วที่สุดในการประเมินผลกระทบ

สรุปสาระสำคัญ: Oracle AI Database 23.26.2 เปลี่ยนการตั้งค่า standby PDB ที่มีหลายขั้นตอนและเสี่ยงต่อความผิดพลาด ให้กลายเป็นการทำงานเพียงบรรทัดเดียว ช่วยให้การกู้คืนระบบจากภัยพิบัติในสภาพแวดล้อมแบบ multitenant รวดเร็วและน่าเชื่อถือยิ่งขึ้น