Oracle AI Database 23.26.2 מאפשרת להקים (spin up) בסיס נתונים פלאגבילי (PDB) במצב standby ולו את ה-redo logs שלו באמצעות פקודה אחת של Data Guard Broker, ובכך מבטלת את שגרת העתקת הקבצים הידנית שעיכבה זמן רב תהליכי התאוששות מאסון (disaster-recovery).

למה זה חשוב

יצירת PDB במצב physical standby דרשה שרשרת של פעולות ידניות: העתקת כל datafile למכולה (container) ה-standby, בניית standby redo logs (SRLs) באמצעות פקודות ALTER מפורשות, ובדיקה כפולה של כל התצורה. כל שלב טומן בחובו סיכון לטעויות הקלדה, קבצים שהוחמצו או קבוצות לוגים (log groups) לא תואמות, מה שעלול לעכב בדיקות התאוששות או, במקרה הגרוע ביותר, לשבש את ה-failover. אוטומציה של התהליך מצמצמת את הסיכונים הללו ומפנה את ה-DBAs להתמקד במשימות ברמה גבוהה יותר.

איך בנו standby PDBs בעבר

בארכיטקטורת multitenant, CDB (container database) ראשי מארח PDB אחד או יותר. כדי להגן על PDB, מנהלי מערכת היו צריכים:

  • לזהות ולהעתיק כל datafile מהמארח הראשי למארח ה-standby.
  • ליצור ידנית SRLs המשקפים את מבנה ה-redo-log של הראשי.
  • להריץ פקודות RMAN restore או duplicate כדי לסנכרן את ה-standby.
  • להריץ סדרה של שלבי אימות כדי לוודא שה-standby יכול לקבל switchover.

תהליך העבודה יכול היה להימשך מספר שעות, במיוחד עבור PDBs גדולים, וכל טעות עלולה להשאיר את ה-standby לא שמיש.

מה עדכון 23.26.2 עושה

גרסת ה-Oracle AI Database האחרונה מטמיעה את השלבים הנדרשים בתוך ה-Data Guard Broker. באמצעות פקודת ADD PLUGGABLE DATABASE אחת, ה-broker:

  1. רושם את ה-standby PDB החדש בראשי.
  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 על CDB משני (cdb2) ששיקף PDB ראשי ב-cdb1. ה-broker השלים את הפעולה באופן מיידי. לא הופעלה פקודת RMAN restore, לא הופיעו העתקות קבצים ידניות בלוגים של מערכת ההפעלה, וקבוצות ה-standby redo log הופיעו בקטלוג ללא צורך בפקודות ALTER DATABASE כלשהן.

פתיחת ה-PDB העבירה אותו למצב READ ONLY, מה שאישר את סטטוס ה-physical-standby שלו. בדיקה מהירה של ה-datafiles הוכיחה שהם הוקצו (provisioned) בצד ה-standby. תהליך ה-redo apply כבר היה פועל, וה-broker דיווח שהתצורה מוכנה ל-switchover.

השלכות על DBAs

האוטומציה מפחיתה את הסיכוי לטעויות אנוש וקיצרה משמעותית את הזמן שבין התכנון לבין ה-production standby. צוותים יכולים כעת להקצות (provision) standby PDBs בדקות במקום בשעות, דבר בעל ערך רב במיוחד עבור סביבות שמקימות שירותים חדשים בתדירות גבוהה.

המחיר הוא תלות גדולה יותר בלוגיקה הפנימית של ה-Data Guard Broker. חלק מה-DBAs מעדיפים לכתוב סקריפטים לכל שלב בעצמם כדי לשמור על שליטה מפורטת (granular control) או כדי לשלב אותם עם כלי ניטור מותאמים אישית. בהגדרות מורכבות — רשתות מרובות, אחסון הטרוגני או מבני redo לא סטנדרטיים — מנהלי מערכת עשויים עדיין להזדקק לוודא שהברירות המחדל של ה-broker תואמות למדיניות שלהם.

מה לצפות בהמשך

Oracle לא הכריזה על הרחבות נוספות לאוטומציה זו, אך המהלך מרמז שגרסאות עתידיות עשויות להעביר חלק גדול יותר מתהליך ה-DR של ה-multitenant אל ה-broker. עקבו אחר:

  • תמיכה בסוגי standby נוספים (למשל, logical standby PDBs).
  • לוגים מורחבים המציגים את החלטות ה-broker לצורכי ביקורת (audit).
  • בדיקות תאימות עם כלי גיבוי של צד שלישי שהסתמכו בעבר על שלבי RMAN ידניים.

אם הארגון שלכם מריץ Oracle AI Database בתצורת high-availability, בדיקת הפקודה החדשה על CDB שאינו בסביבת ייצור (non-production) היא הדרך המהירה ביותר להעריך את ההשפעה.

שורה תחתונה: Oracle AI Database 23.26.2 הופכת הגדרה של standby PDB רב-שלבית וחשופה לטעויות לפעולה של שורה אחת