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

כמו שעשיתי מאות פעמים בעבר, הורדתי את בסיס הנתונים בצורה מסודרת באמצעות sqlplus ו-shutdown immediate, העלתי את בסיס הנתונים באמצעות startup mount אבל בסיס הנתונים נפתח למצב Open:

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 778387456 bytes
Fixed Size 1374808 bytes
Variable Size 461374888 bytes
Database Buffers 310378496 bytes
Redo Buffers 5259264 bytes
Database mounted.
SQL>
SQL> select status from v$instance

STATUS
------------
OPEN

מוזר, מה פה קורה פה?

קצת רקע על הסביבה: מדובר בבסיס נתונים בתצורה של Data Guard עם DG Broker בגרסה 10.2.0.5. בסיס הנתונים שרצינו לבצע עליו את הפעילות התחזוקה הוא ה-Primary של ה-DG (או יותר מדוייק, העתק שלו שבוצע לטובת גיבוי)

לאחר בדיקה ב-alert log וניחוש מושכל, התברר שה"אשם" המרכזי בבעיה הוא ה-DG Broker שמחליט, על דעת עצמו, שאין מצב שהתכוונתי להעלות את ה-primary ב-mount (שהרי זה המצב של ה-standby בדרך כלל) והוא פותח בעצמו את בסיס הנתונים למצב open. במקרה הספציפי הזה, הדבר יצר בעיה חמורה מכוון שבסיס הנתונים עלה מעותק (snapshot של storage) ודרס את ההגדרות של ה-scn ב-control files של הסביבה התקינה.

כדי לעקוף את הבעיה ניטרלנו את ה-dg broker לפני שהעלנו את בסיס הנתונים ב-mount (באמצעות שימוש ב-pfile במקום ב-spfile) וזה עקף את הבעיה בצורה סבירה.

SQL> alter system set dg_broker_start= false scope=both;
SQL> shutdown immediate;

בקריאה שפתחנו באורקל התברר כי זה המצב התקין של העניינים בגרסה 10 והסיפור הזה שונה בגרסה 11.2 של הברוקר – "Allow a primary or logical standby database in a Data Guard Broker configuration to be mounted without having to be opened automatically"

כדאי להכיר את העניין הזה – הוא מאוד לא טרוויאלי ואני עדיין ממתין לתשובות מאורקל בנוגע ל-workaround-ים אחרים (אם יש). אני אעדכן אם אקבל מהם תשובות נוספות.

עדכון:
אורקל אומרים: זה מה יש, אין דרך אחרת לעקוף את העניין הזה. שיהיה בהצלחה. 🙂