אימות הפריסה של Data Guard

אחרי ההגדרה של Data Guard broker, צריך לוודא שפעולות ה-redo הועתקו ממסד הנתונים הראשי והוחלו על מסד הנתונים המשני. אפשר להשתמש בהליך הבא כדי לבדוק את הסטטוס של Data Guard מתוך מסדי הנתונים הראשיים ומסדי הנתונים במצב המתנה.

בדוגמאות הבאות נעשה שימוש לאורך המדריך הזה:

שם ייחודי של מסד הנתונים שמות מארחים של שרתים שמות של מכונות RAC תפקיד
DBDG_SITE1 site1db1, site1db2 DBDG_SITE11, DBDG_SITE12 ראשי
DBDG_SITE2 site2db1, site2db2 DBDG_SITE21, DBDG_SITE22 מצב המתנה

אימות הפריסה של Data Guard

  1. מתחברים לשרת הראשון של Bare Metal Solution שמארח את מסד הנתונים הראשי, ואז מגדירים את משתנה הסביבה ORACLE_SID כדי להתחבר למסד הנתונים הראשי:

    source oraenv <<< "DBDG_SITE11"

  2. מפעילים את SQL*Plus, ואז קובעים את המספר הסידורי האחרון של יומני הרישום של פעולות חוזרות בארכיון:

    sqlplus / as sysdba

    SELECT THREAD#, max(SEQUENCE#) "Last Primary Seq Archived"
FROM V$ARCHIVED_LOG VAL, V$DATABASE VDB WHERE VAL.RESETLOGS_CHANGE# =
VDB.RESETLOGS_CHANGE# GROUP BY THREAD# ORDER BY 1;

    בפלט הבא, המספר המקסימלי של הרצף הוא 40 עבור thread 1, ו-33 עבור thread 2:

       THREAD# Last Primary Seq Archived
---------- -------------------------
         1                        40
         2                        33

    רושמים את התוצאות כדי להשוות אותן למסד הנתונים במצב המתנה. מספרי הרצף במסד הנתונים במצב המתנה צריכים להיות זהים למספרי הרצף במסד הנתונים הראשי.

  3. מתחברים לשרת הראשון של Bare Metal Solution שמארח את מסד הנתונים במצב המתנה, ואז מגדירים את משתנה הסביבה ORACLE_SID כדי להתחבר למסד הנתונים במצב המתנה:

    source oraenv <<< "DBDG_SITE21"

  4. מפעילים את SQL*Plus, ואז מוודאים שמספר הרצף האחרון שהתקבל והוחל על יומני ה-redo שנארכו תואם למספר הרצף האחרון במסד הנתונים הראשי:

    sqlplus / as sysdba

    SELECT THREAD#, max(SEQUENCE#) "Last Standby Seq Received"
FROM V$ARCHIVED_LOG VAL, V$DATABASE VDB WHERE VAL.RESETLOGS_CHANGE# =
VDB.RESETLOGS_CHANGE# GROUP BY THREAD# ORDER BY 1;

    SELECT THREAD#, max(SEQUENCE#) "Last Standby Seq Applied"
FROM V$ARCHIVED_LOG VAL, V$DATABASE VDB WHERE VAL.RESETLOGS_CHANGE# =
VDB.RESETLOGS_CHANGE# AND VAL.APPLIED IN ('YES','IN-MEMORY') GROUP BY
THREAD# ORDER BY 1;

    בפלט הבא יש מספרים סידוריים שתואמים להרצת השאילתה הקודמת מול מסד הנתונים במצב המתנה:

       THREAD# Last Standby Seq Received
---------- -------------------------
         1                        40
         2                        33

       THREAD# Last Standby Seq Applied
---------- ------------------------
         1                       40
         2                       33

  5. בודקים שהסטטוס של תהליך השחזור המנוהל הוא APPLYING_LOG:

    SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE '%MRP%';

    בדוגמה הבאה מוצג תהליך יחיד של שחזור מנוהל בשם MRP0 עם הסטטוס APPLYING_LOG:

    PROCESS   STATUS
--------- ------------
MRP0      APPLYING_LOG

  6. בודקים אם יש השהיה בהעברה או בהחלה של מסד הנתונים במצב המתנה:

    COLUMN NAME FORMAT a20
COLUMN VALUE FORMAT a30
SELECT NAME, VALUE FROM V$DATAGUARD_STATS WHERE NAME LIKE '%lag%';

    בפלט הבא לא מוצג פיגור במסד הנתונים במצב המתנה:

    NAME                 VALUE
-------------------- ------------------------------
transport lag        +00 00:00:00
apply lag            +00 00:00:00

    אם יש השהיה, אפשר לעיין בתיעוד של Oracle Data Guard לפתרון בעיות.

מעבר בין מסדי נתונים באמצעות Data Guard broker

מעבר בין מצבים הוא היפוך תפקידים שבו מסד הנתונים הראשי הופך למסד נתונים במצב המתנה, ולהפך. במהלך תהליך המעבר, לקוחות מסד הנתונים מתנתקים ממסד הנתונים הראשי. בהתאם לאופן שבו האפליקציה מתחברת למסד הנתונים, מעבר לגיבוי זמין עלול לשבש את התנועה של האפליקציה. ‫Oracle מציעה אפשרויות לשמירה על רציפות האפליקציה במהלך מעברים בין תפקידים. כדי לבדוק את מוכנות המערכת לתוכנית התאוששות מאסון (DR), אפשר לבצע מעבר לגיבוי נתונים של מסד הנתונים לפי ההוראות הבאות:

  1. מתחברים לשרת Bare Metal Solution שמארח את מסד הנתונים הראשי.

  2. מפעילים את ממשק שורת הפקודה של Data Guard ומתחברים למסד הנתונים במצב המתנה:

    dgmgrl

    CONNECT SYS@DBDG_SITE2

  3. כשמוצגת בקשה להזין סיסמה, מזינים את הסיסמה של SYS לכניסה מרחוק למסד הנתונים.

  4. מוודאים שהמסד הנתונים מוכן למעבר לגיבוי.

    VALIDATE DATABASE DBDG_SITE2;

    אם התוצאה תהיה חיובית, יצוין שהמסד מוכן למעבר.

  5. אם הפעולה מסתיימת ללא שגיאות, מריצים את פקודת המעבר:

    SWITCHOVER TO DBDG_SITE2;

    אם הפקודה מצליחה, תקבלו הודעה שבה מצוין ש-DBDG_SITE2 הוא מסד הנתונים הראשי החדש בהגדרה.

  6. מריצים את הפקודה הבאה כדי לוודא שהתפקידים במסד הנתונים הוחלפו:

    SHOW CONFIGURATION;

  7. מריצים את הפקודה הבאה כדי לחזור להגדרה המקורית:

    SWITCHOVER TO DBDG_SITE1;

מעבר לגיבוי (failover) של מסד נתונים באמצעות Data Guard broker

מעבר לגיבוי הוא מעבר תפקידים שבו אחד ממסדי הנתונים במצב המתנה עובר לתפקיד הראשי בגלל הפסקת פעולה מלאה של האתר. הפעולה Redo לא תישלח למסד הנתונים במצב המתנה עד שמסד הנתונים במצב המתנה יוחזר למצב פעיל.

ביצוע מעבר לשירות הגיבוי

  1. מתחברים לשרת הראשון של Bare Metal Solution שמארח את מסד הנתונים במצב המתנה.

  2. מתחברים לממשק שורת הפקודה של Data Guard, ואז מבצעים מעבר לגיבוי כשל של מסד הנתונים הראשי למסד הנתונים במצב המתנה:

    dgmgrl

    CONNECT SYS@DBDG_SITE2

  3. כשמוצגת בקשה להזין סיסמה, מזינים את הסיסמה של SYS לכניסה מרחוק למסד הנתונים.

  4. מפעילים את המעבר לגיבוי:

    FAILOVER TO DBDG_SITE2

    מריצים את הפקודה show configuration; כדי לוודא ש-DBDG_SITE2 הוא עכשיו מסד הנתונים הראשי, וצריך להפעיל מחדש את DBDG_SITE1.

החזרת מסד הנתונים הראשי

אפשר להפעיל מחדש את מסד הנתונים הראשי אחרי מעבר לגיבוי כשל רק אם האפשרות flashback database מופעלת. כדי להחזיר את מסד הנתונים הראשי שנכשל:

  1. מתחברים לשרת הראשון של Bare Metal Solution שמארח את מסד הנתונים הראשי.

  2. מתחברים לממשק שורת הפקודה של Data Guard, מתחברים למסדי הנתונים הראשיים ואז משחזרים את מסד הנתונים שנכשל:

    dgmgrl

    CONNECT SYS@DBDG_SITE2

    כשמוצגת בקשה להזין סיסמה, מזינים את הסיסמה של SYS לכניסה מרחוק למסד הנתונים.

  3. משחזרים את מסד הנתונים:

    REINSTATE DATABASE DBDG_SITE1;
EXIT;

השלבים הבאים

בשלב הבא, מגדירים משקיף של Data Guard ב-Compute Engine.