אפשרויות להתאוששות מאסון (DR) לעומסי עבודה של מסדי נתונים של אורקל

במדריך הזה מתוארות האפשרויות לשחזור מאסון שזמינות למשתמשים שמריצים עומסי עבודה של מסדי נתונים קריטיים של אורקל בסביבת Bare Metal Solution.

במדריך הזה אנחנו יוצאים מנקודת הנחה שאתם מפעילים את Oracle Enterprise Edition. חלק מהתכונות שמתוארות במדריך הזה מורשות בנפרד מרישיון מהדורת Enterprise. דוגמאות לתכונות כאלה:

• Oracle Real Application Clusters
• Oracle Active Data Guard
• Oracle Advanced Compression
• Oracle GoldenGate

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

RTO ו-RPO של אפליקציות

התאוששות מאסון (DR) לטכנולוגיות של מסד נתונים של Oracle צריכה להיקבע על סמך יעד משך ההתאוששות (RTO) ויעד נקודת ההתאוששות (RPO) של האפליקציה. באופן כללי, RTO מתאר את משך ההשבתה המקובל של מערכת, ו-RPO מתאר את כמות אובדן הנתונים שמקובלת. ככל שכל אחד מהערכים האלה קטן יותר, העלות והמורכבות של המערכת גדלות. למידע נוסף על RTO ו-RPO, ראו מושגי יסוד בתכנון התאוששות מאסון.

בארכיטקטורות שמסומנות בתווית RPO = 0 או בתווית 'אפס אובדן נתונים', הנתונים צריכים להיכתב בכמה מיקומים לפני שהם נחשבים כ'מחויבים' למסד הנתונים. זמן האחזור הופך לבעיה ככל ש-RPO מתקרב לאפס.

אם לא לוקחים את זה בחשבון בשלב התכנון, הטמעה של ארכיטקטורה שמונעת אובדן נתונים עלולה להשפיע לרעה על הביצועים הכוללים של האפליקציה.

זמינות גבוהה לעומת תוכנית התאוששות מאסון (DR)

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

כשמתכננים מערכת אמינה, זמינות גבוהה צריכה להיות 'קו ההגנה הראשון'. ארכיטקטורה של מסד נתונים עם זמינות גבוהה צריכה להיות מסוגלת לעמוד בכשלים ספציפיים ולהמשיך לפעול בלי לגרום להשבתה של האפליקציה. רכיבי הזמינות הגבוהה של מערכת חייבים לכלול, בין היתר:

• אספקת חשמל עודפת לשרת, לרשת או לחומרת אחסון
• ממשקי רשת, מתגים וכבלים מרובים
• מערכות אחסון, בקרי אחסון ומכשירי דיסק מיותרים
• חיבורי Partner Interconnect עמידים בכשלים בין Google Cloud לבין אזור ההרחבה של Bare Metal Solution
• ‫Oracle RAC כדי למנוע מכשלי שרת להשבית מסד נתונים

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

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

כלים של Oracle להתאוששות מאסון ולזמינות גבוהה

אלה כמה כלים של Oracle לזמינות גבוהה ולתוכנית התאוששות מאסון:

• Oracle Real Application Clusters
• ‫Oracle Recovery Manager
• Oracle Data Guard
• מסד נתונים של פלאשבק
• ‫Oracle GoldenGate

Oracle Real Application Clusters

‫Oracle Real Application Clusters ‏ (RAC) משמש להרחבת עומסי עבודה של מסדי נתונים באופן אופקי, כדי שיוכלו לקבל שירות ממספר שרתים של מסדי נתונים. במסדי נתונים שמשתמשים ב-RAC, אפשר להגדיר מצב פעיל/פעיל בין שרתים בתוך אזור הרחבה.

בדרך כלל משתמשים ב-RAC כדי לספק זמינות גבוהה למערכות שצריך להגן עליהן מפני כשל בשרת יחיד. בגלל הגישה של 'הכול משותף' (אחסון משותף ורשתות משותפות) לאשכולות, צריך שאשכול RAC שפועל בסביבת Bare Metal Solution יהיה בתוך תא Bare Metal Solution יחיד. לכן, RAC הוא פתרון לבעיות שקשורות לזמינות גבוהה, אבל הוא לא עונה על הדרישה של תוכנית התאוששות מאסון (DR).

Oracle Recovery Manager

‫Oracle Recovery Manager‏ (RMAN) הוא הכלי העיקרי לגיבוי ושחזור של מסדי נתונים של Oracle, כי הוא יכול לקרוא את פורמט קובץ הנתונים הקנייני של Oracle. אפשר להשתמש בה כדי לבצע שיבוטים של מסדי נתונים, שחזור לנקודת זמן מסוימת או אפילו שחזור של טבלה יחידה במסד נתונים של Oracle.

‫RMAN הוא הכלי היחיד שאפשר להשתמש בו כדי ליצור גיבויים בזמן שמסד הנתונים פתוח. הוא משמש גם לשמירה על קטלוג של קובצי גיבוי שזמינים לשימוש לצורך שחזור.

Oracle Data Guard

‫Oracle Data Guard מבצע שכפול של מסד נתונים לאשכולות RAC מרוחקים או להתקנות אחרות של מסד נתונים. ‫Data Guard תומך במסדי נתונים במצב המתנה בתצורה פיזית או לוגית.

מסדי נתונים פיזיים במצב המתנה הם עותקים של בלוקים שמאפשרים לפתוח עותק אחד של מסד הנתונים לכתיבה. כל העותקים האחרים מותקנים (אבל לא פתוחים) כדי להחיל שינויים או פתוחים לקריאה בלבד כדי לתמוך באפליקציות דיווח.

מידע נוסף על הגדרת Data Guard ב-Bare Metal Solution זמין במאמר בנושא פריסת Oracle Data Guard ב-Bare Metal Solution.

FLASHBACK DATABASE

התכונה FLASHBACK DATABASE של Oracle Enterprise Edition מאפשרת לאדמינים להחזיר במהירות מסד נתונים לנקודה ספציפית בזמן, בלי לבצע שחזור ארוך של מסד הנתונים.

בהקשר של התאוששות מאסון, בדרך כלל משתמשים ב-FLASHBACK DATABASE בשילוב עם Data Guard במהלך פעולות מעבר לגיבוי (failover) כדי להחזיר את מסד הנתונים לפעולה מהר יותר. מסד הנתונים שנכשל מוחזר לנקודה ספציפית בזמן שתואמת ליומנים בשרת הראשי החדש, והפעולה חוזרת על עצמה כדי שניתן יהיה לסנכרן מחדש באופן מלא.

Oracle GoldenGate

‫Oracle GoldenGate הוא כלי לשכפול לוגי שמשמש בדרך כלל להפעלת פריסות פעילות/פעילות באתרים מרובים או להעברת נתונים בין פלטפורמות חומרה. כשמשתמשים ב-GoldenGate, תהליך extract במסד הנתונים של המקור מתעד שינויים ביומני התיקון אונליין וכותב אותם לשינויים בקובצי trail, שמועברים למסד הנתונים של היעד. תהליך replicat במסד נתונים היעד ממיר את העסקאות מקבצי הזנב ל-SQL, ומריץ את ה-SQL במסד נתונים היעד.

הארכיטקטורה הזו הופכת את GoldenGate לכלי רב עוצמה להעברת נתונים בין פלטפורמות של מסדי נתונים או לשינוי נתונים בזמן השכפול. בניגוד ל-Data Guard,‏ GoldenGate מחייב התקנה ותחזוקה של תוכנה נפרדת במערכות המקור והיעד. אי אפשר להשתמש ב-GoldenGate לשכפול סינכרוני, כי העסקאות מתורגמות ומוחלות כ-SQL במסד הנתונים של היעד. ‫GoldenGate יכול לספק השהיה מינימלית לשכפול, אבל הוא לא יכול להבטיח RPO של אפס.

מודלים של פריסת תוכנית התאוששות מאסון (DR) (מסד נתונים בלבד)

חברת אורקל יצרה את מסגרת Maximum Availability Architecture (MAA) כדי לספק לכם מודלים מומלצים להתאוששות מאסון (DR) לפריסת האפליקציות ומסדי הנתונים שלכם.

כל אחד מהמודלים הבאים מספק יעדי RTO ו-RPO ספציפיים:

• מודל Copper
• מודל ארד
• מודל Silver
• מודל Gold
• מודל פלטינה

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

מודל ברונזה מיועד למסדי נתונים שלא צריך למדוד את ה-RTO שלהם בדקות. המודלים ברמת Silver ומעלה כוללים מסדי נתונים במצב המתנה שפועלים באתר מרוחק. כל מודל משלב את הפונקציונליות של המודלים ברמה הנמוכה יותר. לדוגמה, במודל Bronze נעשה שימוש במושגים של גיבוי ושחזור, שעדיין צריך לפעול גם אם מסד נתונים במצב המתנה נפרס.

מודל נחושת

מודל Copper מספק פריסה מינימלית לגיבוי מסדי נתונים למדיה של אחסון מקומי ולהעתקה לאחסון שנמצא מחוץ להרחבת האזור. הפריסה הזו דורשת גישה דו-שלבית, אבל אפשר להשתמש ב-Google Cloud SDK כדי ליצור סקריפט לאוטומציה של העברת הגיבויים.

בנוסף, השימוש בפריסה הזו מגדיל את זמן ההתאוששות (RTO) בגלל השחזור הדו-שלבי שנדרש. ל-RMAN אין גישה ישירה לגיבויים, ולכן צריך להעביר אותם למיקום שזמין ל-RMAN לפני שמתחילים בשחזור.

הפסקה זמנית בשירות	סוג ההפסקה הזמנית בשירות	RPO	RTO
לא מתוכנן	כשל שניתן לשחזור בצומת או במכונה	0	הזמן שנדרש להפעלה מחדש של המופע
	אסונות: השחתות	הגיבוי האחרון של יומן הארכיון, הגיבוי המצטבר או הגיבוי המלא שהועבר מחוץ ל-RE	שעות, בהתאם לגודל מסד הנתונים ולרוחב הפס שהוקצה ל-Partner Interconnect
	אסונות: כשלים בהרחבת אזורים	הגיבוי האחרון של יומן הארכיון, הגיבוי המצטבר או הגיבוי המלא שהועבר מחוץ ל-RE	ימים או שבועות, בהתאם לזמן שנדרש כדי להחזיר את הרחבת האזור למצב אונליין
לפי התכנון	תיקוני מסד נתונים, עדכוני מערכת הפעלה או קושחה	0	הזמן שנדרש לעדכון ולהפעלה מחדש של המופע
	שדרוג חשוב של מסד נתונים	0	שעה עד שעתיים

מודל ארד

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

פריסת Bronze 1: גיבוי באחסון אזורי

בפריסה הזו, הגיבויים נכתבים ישירות למדיה מחוץ לאתר. ברוב המקרים, יעד הגיבוי המומלץ הוא Cloud Storage עם Cloud Storage FUSE, שמציג קטגוריה של Cloud Storage כמערכת קבצים.

ההמלצות לשימוש ב-Cloud Storage FUSE מפורטות במאמר בנושא גיבויים של Oracle באמצעות NFS ו-Cloud Storage. Google Cloud אפשר גם להשתמש ב-Filestore, שמציג שיתופי NFS למופעים של Bare Metal Solution.

בתרשים הבא מוצגת פריסה לדוגמה.

הפסקה זמנית בשירות	סוג ההפסקה הזמנית בשירות	RPO	RTO
לא מתוכנן	כשל שניתן לשחזור בצומת או במכונה	0	הזמן שנדרש להפעלה מחדש של המופע
	אסונות: השחתות	הגיבוי האחרון של יומן הארכיון, הגיבוי המצטבר או הגיבוי המלא	שעות, בהתאם לגודל מסד הנתונים ולרוחב הפס שהוקצה ל-Partner Interconnect
	אסונות: כשלים בהרחבת אזורים	הגיבוי האחרון של יומן הארכיון, הגיבוי המצטבר או הגיבוי המלא	ימים או שבועות, בהתאם לזמן שנדרש כדי להחזיר את הרחבת האזור למצב אונליין
לפי התכנון	תיקוני מסד נתונים, עדכוני מערכת הפעלה או קושחה	0	הזמן שנדרש לעדכון ולהפעלה מחדש של המופע
	שדרוג חשוב של מסד נתונים	0	שעה עד שעתיים

פריסת Bronze 2: גיבוי באמצעות Backup and DR

בפריסה הזו, שירות Backup and DR משמש לאחסון גיבויים ב-Google Cloud. הפתרון Backup and DR מציע גישה של גיבוי מצטבר ללא הגבלה, והגיבויים מאוחסנים במדיה עם ביצועים גבוהים שמגובה על ידי Cloud Storage לשמירה לטווח ארוך.

בנוסף, Backup and DR מציע RTO מהיר יותר מאחסון גיבויים ב-Filestore או ב-Cloud Storage, כי הוא יכול להפוך מיד תמונות של קובצי מסד נתונים לזמינות במופע Oracle. התכונה 'העלאה והעברה' מאפשרת להעלות מסד נתונים לאונליין במהירות, תוך כדי העתקה חזרה למדיה לאחסון בייצור, וכך מקצרת באופן משמעותי את זמן ההתאוששות (RTO).

בתרשים הבא מוצגת פריסה לדוגמה.

הפסקה זמנית בשירות	סוג ההפסקה הזמנית בשירות	RPO	RTO
לא מתוכנן	כשל שניתן לשחזור בצומת או במכונה	0	הזמן שנדרש להפעלה מחדש של המופע שניות אם משתמשים ב-RAC
	אסונות: השחתות	הגיבוי האחרון של יומן הארכיון, הגיבוי המצטבר או הגיבוי המלא	דקות עד שעות, בהתאם לדרישות הביצועים, לגודל מסד הנתונים ולרוחב הפס שהוקצה ל-Partner Interconnect
	אסונות: כשלים בהרחבת אזורים	הגיבוי האחרון של יומן הארכיון, הגיבוי המצטבר או הגיבוי המלא	ימים או שבועות, בהתאם לזמן שנדרש כדי להחזיר את ההרחבה האזורית למצב אונליין או ליכולת של הלקוח לעבור להרחבה אזורית אחרת.
לפי התכנון	תיקוני מסד נתונים, עדכוני מערכת הפעלה או קושחה	0	הזמן שנדרש לעדכון ולהפעלה מחדש של המופע
	שדרוג חשוב של מסד נתונים	0	שעה עד שעתיים

Silver

מודל Silver מציג שכפול מסד נתונים באמצעות Oracle Data Guard. ‫Data Guard מספק שכפול של מסד נתונים בזמן אמת עם מסד נתונים אחד או יותר שפועלים כמסד נתונים במצב המתנה. מכיוון ש-Data Guard מסתמך על העברה של שינויים במסד הנתונים והחלתם בזמן שהם מתרחשים, ה-RPO יכול להיות קרוב לאפס. מודל Silver מסתמך על שכפול אסינכרוני. שימוש בשכפול סינכרוני מבטיח אפס אובדן נתונים, אבל הזמן שנדרש לשליחת נתונים בין אזורים בדרך כלל גורם לזמן התגובה של האפליקציה לחרוג מהמגבלות המקובלות.

התכונה 'מעבר מהיר לגיבוי בעת כשל' של Data Guard מאפשרת לבצע פעולות אוטומטיות של מעבר לגיבוי בעת כשל אם מסד נתונים ראשי הופך ללא זמין למשך תקופה שהוגדרה על ידי המשתמש. ההגדרה מנוטרת על ידי תהליך של Data Guard observer, שיכול לפעול.

היתרון של מודל Silver הוא שמסד הנתונים זמין במקרה של כשל אזורי מוחלט, אבל פעולות מעבר לגיבוי (failover) ומעבר חזרה (switchover) עלולות להשפיע על ביצועי האפליקציה, כי זמן האחזור ברשת בין שרתי האפליקציה למסד הנתונים גדל. בדרך כלל לא מומלץ להפעיל אפליקציות ומסדי נתונים תומכים באזורים שונים. זמן ההתאוששות (RTO) של מסד הנתונים עשוי להיות פחות מדקה, אבל במקרים של יתירות כשל של אפליקציה, יכולות לעבור דקות או שעות עד שהשירותים יפעלו באופן מלא. ברוב המקרים, הפעלת תוכניות יתירות כשל להתאוששות מאסון בין אזורים כרוכה בתהליכים ידניים בגלל מספר הרכיבים שמועברים.

במודל Silver, יכול להיות שעדיין תהיה השבתה או חלונות תחזוקה במהלך פעילויות תיקון רבעוניות. הטמעה של Oracle RAC יכולה לצמצם את זמן ההשבתה לצורך תיקון או כתוצאה מכשלים בשרת.

בתרשים הבא מוצגת הגדרה לדוגמה.

ההגדרה לדוגמה בתרשים מציגה מסדי נתונים של RAC שפועלים באזורים us-west2 ו-us-east4. השכפול מוגדר באמצעות Data Guard אסינכרוני. כל התעבורה בין Bare Metal Solution לבין Google Cloudעוברת דרך Partner Interconnect, ותעבורה בין אזורים עוברת דרך רשת הליבה של Google. שרתי האפליקציות מוגדרים בכל אזור, אבל בדרך כלל הם מושבתים באזור השחזור מאסון עד להכרזה על אירוע מעבר לגיבוי.

הפסקה זמנית בשירות	סוג ההפסקה הזמנית בשירות	RPO	RTO
לא מתוכנן	כשל שניתן לשחזור בצומת או במכונה	0	הזמן שנדרש להפעלה מחדש של המופע שניות אם משתמשים ב-RAC
	אסונות: השחתות	< 60s	כמה דקות עד כמה שעות, בהתאם למעבר לגיבוי במקרה של כשל באפליקציה.
	אסונות: כשלים בהרחבת אזורים	< 60s	כמה דקות עד כמה שעות, בהתאם למעבר לגיבוי במקרה של כשל באפליקציה.
לפי התכנון	תיקוני מסד נתונים, עדכוני מערכת הפעלה או קושחה	0	הזמן שנדרש לעדכון ולהפעלה מחדש של המופע. שניות אם משתמשים ב-RAC
	שדרוג חשוב של מסד נתונים	0	שעה עד שעתיים דקות אם משתמשים ב-DBMS_ROLLING כדי לבצע את השדרוג.

דגם הזהב

אם אתם חוששים מאובדן נתונים במודל Silver, אתם יכולים לבחור במודל Gold שמשתמש במכונת סנכרון רחוקה כדי לספק שכפול סינכרוני למכונה שפועלת ב- Google CloudCompute Engine.

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

מופע של סינכרון רחוק הוא לא עותק מלא של מסד הנתונים, ולכן הוא לא יכול לטפל בתנועת נתונים של אפליקציות. מופע הסנכרון המרוחק משמש כדי לספק מיקום סובלני לתקלות שבו שינויים במסד הנתונים נכתבים באופן סינכרוני, וכך מאפשר פתרון שמונע אובדן נתונים. כשמבצעים שכפול סינכרוני למופע של far sync, הטרנזקציות לא מבוצעות במסד הנתונים הראשי עד שהשינויים מתקבלים ומבוצעים במופע של far sync.

המכונות של Compute Engine נבחרות בדרך כלל כמועמדות לאירוח של מכונת סנכרון רחוק. מיקום של מופע הסנכרון המרוחק בתחום של Compute Engine בסמיכות למסד הנתונים הראשי מוסיף השהיה מינימלית (בדרך כלל פחות מ-1.5 אלפיות השנייה) ומגן מפני כשלים בהרחבת האזור.

בתרשים הבא מוצגת פריסה לדוגמה.

ההגדרה לדוגמה בתרשים מציגה מסד נתונים ראשי של RAC שפועל ב-us-west2 עם אפליקציות שפועלות ב-Compute Engine. מכונה של Compute Engine בתוך us-west2 מריצה מכונה של סנכרון רחוק, שמקבלת פעולות חוזרות סינכרוניות. מופע הסנכרון המרוחק מוגדר לשליחת פעולות חוזרות באופן אסינכרוני למסד נתונים של RAC שפועל באזור us-east4. מוגדרות מכונות של האפליקציה באזור us-east4 ב-Compute Engine כדי לטפל בתעבורת הנתונים של האפליקציה במקרה של אסון.

הפסקה זמנית בשירות	סוג ההפסקה הזמנית בשירות	RPO	RTO
לא מתוכנן	כשל שניתן לשחזור בצומת או במכונה	0	הזמן שנדרש להפעלה מחדש של המופע שניות אם משתמשים ב-RAC
	אסונות: השחתות	0	דקות עד שעות, בהתאם למעבר האזורי לגיבוי של האפליקציה.
	אסונות: כשלים בהרחבת אזורים	0	דקות עד שעות, בהתאם למעבר האזורי לגיבוי של האפליקציה.
לפי התכנון	תיקוני מסד נתונים, עדכוני מערכת הפעלה או קושחה	0	הזמן שנדרש לעדכון ולהפעלה מחדש של המופע. שניות אם משתמשים ב-RAC
	שדרוג חשוב של מסד נתונים	0	שעה עד שעתיים דקות אם משתמשים ב-DBMS_ROLLING כדי לבצע את השדרוג.

דגם פלטינה

מודל Platinum מציע שתי אפשרויות פריסה. כל אפשרות פריסה מספקת הגנה באמצעות טכנולוגיה שונה, וכוללת מאפיינים שונים של RTO ו-RPO.

פריסת Platinum 1: Data Guard עם מעבר לגיבוי בשעת כשל מהיר

פריסת Platinum 1 מבוססת על פריסת מודל Gold, ומוסיפה מסד נתונים נוסף של Data Guard במצב המתנה באזור המקומי, שפועל במכונה וירטואלית של Compute Engine. ההגדרה הזו משתמשת בשכפול סינכרוני בין מסד הנתונים הראשי לבין מסד הנתונים במצב המתנה שפועל ב-Compute Engine, ומספקת הבטחה לאובדן נתונים אפסי באזור הראשי.

יצירת מסד נתונים במצב המתנה באזור מאפשרת לבצע פעולות של יתירות כשל ומעבר חזרה של מסד הנתונים בלי להשפיע על האפליקציות. במהלך שינויים בתפקיד מסד הנתונים, אפליקציות שהוגדרו בהתאם לשיקולים של לקוחות Oracle מתחברות מחדש באופן אוטומטי למסד הנתונים הראשי החדש ללא צורך בהתערבות ידנית. באפליקציות שהוגדרו בצורה נכונה, זמן ההשבתה במהלך אירוע מעבר לגיבוי הוא פחות מ-2 דקות.

מסד הנתונים במצב המתנה ב-Compute Engine לא מריץ RAC, אבל הוא צריך להיות בגודל שיאפשר לו לתמוך בתנועת נתונים רגילה של האפליקציה כשהוא פועל כמסד הנתונים הראשי. המופע הזה יכול לפעול עם צורה קטנה יותר בזמן שהוא במצב המתנה, ולהיות מורחב אנכית במהלך אירועי יתירות כשל, או לפעול בקיבולת מלאה בכל הזמנים. שינוי הגודל של המכונה במהלך אירוע יתירות כשל משפיע לרעה על RTO, כי צריך להפעיל מחדש את המכונה במהלך פעולת שינוי הגודל.

המעבר לגיבוי מהיר מוגדר במכונת Compute Engine שמריצה את Data Guard broker עם observer. הכלי observer מריץ לקוח Oracle בסיסי עם חיבורים לכל מסדי הנתונים הראשיים ומסדי הנתונים במצב המתנה. אם הצופה מזהה כשל במסד הנתונים הראשי, הוא מתחיל מעבר לגיבוי חלופי לאחד ממסדי הנתונים במצב המתנה. כשמשתמשים בפריסה ברמת Gold, צריך להגדיר את מסד הנתונים במצב המתנה שפועל ב-Compute Engine כיעד המועדף למעבר לגיבוי בעת כשל.

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

בתרשים הבא מוצגת פריסה לדוגמה.

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

• מסד נתונים ראשי שמופעל ב-RAC בשרת Bare Metal Solution באזור us-west2 מסוים.
• מסד נתונים במצב המתנה (standby) שפועל במכונה וירטואלית של Compute Engine באזור us-west2.
• מסד נתונים מרוחק במצב המתנה שפועל בשרת Bare Metal Solution באזור us-east4.
• הכלי Data Guard observer פועל במכונת Compute Engine באזור us-central1.

השכפול הסינכרוני מוגדר למסד הנתונים במצב המתנה באזור שפועל במכונה של Compute Engine, והשכפול האסינכרוני מוגדר לאזור המרוחק. בכל מקרה, פעולת ה-redo נשלחת ממסד הנתונים הראשי למסד הנתונים במצב המתנה, ולא מועברת ממסד נתונים אחד במצב המתנה למסד נתונים אחר במצב המתנה. ה-observer מוגדר באזור שלישי ושומר על קישוריות לכל מסדי הנתונים בהגדרה. מופעים של אפליקציות מוגדרים באזור הראשי ומתחברים למסד הנתונים הראשי בשרת Bare Metal Solution (או למסד הנתונים במופע Compute Engine במהלך פעולות של מעבר לגיבוי אוטומטי ומעבר חזרה). מופעים של אפליקציות מוגדרים באזור us-east4 ב-Compute Engine כדי לטפל בתעבורת הנתונים של האפליקציה במקרה של אסון.

הפסקה זמנית בשירות	סוג ההפסקה הזמנית בשירות	RPO	RTO
לא מתוכנן	כשל שניתן לשחזור בצומת או במכונה	0	הזמן שנדרש להפעלה מחדש של המופע שניות אם משתמשים ב-RAC
	אסונות: השחתות	0	< 60s
	אסונות: כשלים בהרחבת אזורים	0	< 60s
לפי התכנון	תיקוני מסד נתונים, עדכוני מערכת הפעלה או קושחה	0	הזמן שנדרש לעדכון ולהפעלה מחדש של המופע. שניות אם משתמשים ב-RAC
	שדרוג חשוב של מסד נתונים	0	שעה עד שעתיים דקות אם משתמשים ב-DBMS_ROLLING כדי לבצע את השדרוג.

פריסת פלטינה 2: GoldenGate לשכפול

פריסת Platinum 2 מסתמכת על שימוש ב-Oracle GoldenGate לשכפול. מכיוון ש-GoldenGate לא משכפל ברמת הבלוק. היא מאפשרת לכל מסד נתונים לשרת סשנים של אפליקציות לקריאה ולכתיבה באופן עצמאי. הוא משכפל את השינויים לשני הכיוונים, וכך מאפשר הגדרת מסד נתונים פעיל/פעיל.

צריך לאמת את האפליקציות באופן יסודי לפני שמתחייבים לפריסה פעילה/פעילה, וצריך להתייחס לזיהוי סתירות ולפתרון שלהן.

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

פריסות שמסתמכות על GoldenGate לכל השכפול לא יכולות לתמוך ב-RPO של אפס אובדן נתונים בגלל האופי האסינכרוני של שכפול לוגי. אפשר לפרוס מסדי נתונים מקומיים במצב המתנה שפועלים ב-Compute Engine באמצעות Data Guard כדי לספק RPO של אפס עם שכפול סינכרוני.

בתרשים הבא מוצגת פריסה לדוגמה.

הפסקה זמנית בשירות	סוג ההפסקה הזמנית בשירות	RPO	RTO
לא מתוכנן	כשל שניתן לשחזור בצומת או במכונה	0	הזמן שנדרש להפעלה מחדש של המופע
	אסונות: שחיתויות	שניות לדקות ‫0 אם משתמשים ב-Data Guard בכל מיקום	0
	אסונות: כשלים בהרחבת אזורים	שניות לדקות ‫0 אם משתמשים ב-Data Guard בכל מיקום	0
לפי התכנון	תיקוני מסד נתונים, עדכוני מערכת הפעלה או קושחה	0	הזמן שנדרש לעדכון ולהפעלה מחדש של המופע. שניות אם משתמשים ב-RAC
	שדרוג חשוב של מסד נתונים	0	0