Statische Listener-Registrierung

Um einen Switchover durchführen zu können, ist es (neben den ASM-Aliases für Redo-Logs) notwendig, die beteiligten Datenbanken statisch am Listener zu registrieren.

Bei der normalerweise üblichen dynamischen Listener-Registrierung meldet sich die Datenbank am Listener an, sobald sie gestartet worden ist; erst dann weiss der Listener über die Datenbank Bescheid und kann Remote-Zugriffe weiter reichen.

Damit ein Remote-Zugriff auch dann funktioniert, wenn die Datenbank nicht läuft (z.B. um die Datenbank aus der Ferne zu starten – was beim Switchover passiert), muss sie explizit dem Listener bekannt gemacht werden.

Eine dynamisch registrierte Datenbank mit dem Namen SENTEST sieht im Output von “lsnrctl status” folgendermassen aus:

[...]
Service "SENTEST" has 1 instance(s).
  Instance "SENTEST", status READY, has 1 handler(s) for this service...
[...]

Um diese Datenbank statisch am Listener zu registrieren, ist ein Eintrag im File $ORACLE_HOME/network/admin/listener.ora nötig:

SID_LIST_LISTENER=
  (SID_LIST=
    (SID_DESC=
      (ORACLE_HOME=/opt/oracle/app/product/11.2.0/db_1)
      (SID_NAME=SENTEST))
  )

Passen Sie dabei den Pfad für das ORACLE_HOME Ihrem Setup entsprechend an.

Falls Sie mehr als eine Datenbank statisch registrieren möchten, erweitern Sie die Liste einfach:

SID_LIST_LISTENER=
  (SID_LIST=
    (SID_DESC=
      (ORACLE_HOME=/opt/oracle/app/product/11.2.0/db_1)
      (SID_NAME=SENTEST))
    (SID_DESC=
      (ORACLE_HOME=/opt/oracle/app/product/11.2.0/db_1)
      (SID_NAME=SENPROD))
  )

Nach einem Neu-Einlesen des Config-Files mittels “lsnrctl reload” zeigt “lsnrctl status” nun die statisch registrierte Datenbank (zusätzlich) an:

Service "SENTEST" has 2 instance(s).
  Instance "SENTEST", status UNKNOWN, has 1 handler(s) for this service...
  Instance "SENTEST", status READY, has 1 handler(s) for this service...

Die Instanz mit Status “READY” ist die aktuell laufende, die sich dynamisch am Listener registriert hat; die statisch registrierte wird immer als “UNKNOWN” angeführt.

Falls Sie einen RAC einsetzen, müssen Sie beachten, dass der Listener hier üblicherweise im Grid Environment läuft; das zu bearbeitende Config-File liegt also in $GRID_HOME/network/admin, und auch lsnrctl muss aus dem Grid Environment gestartet werden.

ASM-Aliases für Redo-Logs

Falls Sie ein DBSentinel-Setup mit zwei Oracle-Datenbanken auf ASM betreiben und vorhaben, einen Switchover zwischen Primary- und Standby-Datenbank durchzuführen (“Rollentausch”), ist es zwingend erforderlich, dass die Redo-Logs der Primary-Datenbank mit ASM-Alias-Dateinamen angesprochen werden.

Da üblicherweise bei einer Standard-Datenbankinstallation für die Redo-Logs “system generated filenames” vergeben werden, müssen Sie Ihre Redo-Logs umbenennen und dabei explizit ASM-Alias-Dateinamen verwenden. Am einfachsten geht das, indem Sie neue Redo-Logs bzw. Redo-Log-Gruppen anlegen und die alten Redo-Logs droppen.

Finden Sie zunächst heraus, wieviele Redo-Log-Gruppen in Ihrer Datenbank vorhanden sind, wieviele Logfiles es pro Gruppe gibt und wie groß diese sind:

SQL> select group#, thread#, members, bytes from v$log;

    GROUP#    THREAD#    MEMBERS      BYTES
---------- ---------- ---------- ----------
         1          1          2   52428800
         2          1          2   52428800
         3          2          2   52428800
         4          2          2   52428800

Legen Sie nun für jede vorhandene Gruppe eine neue Gruppe an – passen Sie dabei die ASM-Alias-Namen an Ihre Diskgroups an (inkl. Verteilung der Logs einer Gruppe auf mehrere Diskgroups), verwenden Sie freie Gruppennummern und achten Sie auf die Thread-Zuweisung und die Größe:

SQL> alter database add logfile thread 1 group 5 ('+DG_REDO1/redo1_1_1.log', '+DG_REDO2/redo1_1_2.log') size 52428800;

SQL> alter database add logfile thread 1 group 6 ('+DG_REDO1/redo1_2_1.log', '+DG_REDO2/redo1_2_2.log') size 52428800;

SQL> alter database add logfile thread 2 group 7 ('+DG_REDO1/redo2_1_1.log', '+DG_REDO2/redo2_1_2.log') size 52428800;

SQL> alter database add logfile thread 2 group 8 ('+DG_REDO1/redo2_2_1.log', '+DG_REDO2/redo2_2_2.log') size 52428800;

Erzwingen Sie einige Logswitches, indem Sie die folgende Anweisung mehrere Male durchführen, um die neuen Redo-Logs in Verwendung zu nehmen:

SQL> alter system archive log current;

Überprüfen Sie den Status der Redo-Log-Gruppen:

SQL> select group#, thread#, archived, status from v$log;

    GROUP#    THREAD# ARC STATUS
---------- ---------- --- ----------------
         1          1 YES ACTIVE
         2          1 YES ACTIVE
         3          2 YES ACTIVE
         4          2 YES ACTIVE
         5          1 NO  CURRENT
         6          1 YES INACTIVE
         7          2 YES INACTIVE
         8          2 NO  CURRENT

Erzwingen Sie weitere Logswitches bzw. warten Sie, bis die alten Log-Gruppen als “INACTIVE” angezeigt werden, und droppen Sie diese dann:

SQL> alter database drop logfile group 1;
SQL> alter database drop logfile group 2;
SQL> alter database drop logfile group 3;
SQL> alter database drop logfile group 4;

Falls die Datenbank die Logfiles noch nicht droppen kann (weil sie noch in Verwendung sind), liefert sie einen ORA-01623 bzw. ORA-01624 Fehler, und Sie müssen noch warten oder weitere Logswitches durchführen, bis die Datenbank die Logfiles freigibt.

Am Ende sollten Sie wieder die gleiche Anzahl an Redo-Log-Gruppen haben wie am Beginn des Umbaus.

Mit folgender Abfrage können Sie noch prüfen, ob die neuen Logfiles tatsächlich die richtigen Alias-Namen haben:

SQL> select member from v$logfile;

MEMBER
--------------------------------
+DG_REDO1/redo1_1_1.log
+DG_REDO2/redo1_1_2.log
+DG_REDO1/redo1_2_1.log
+DG_REDO2/redo1_2_2.log
+DG_REDO1/redo2_1_1.log
+DG_REDO2/redo2_1_2.log
+DG_REDO1/redo2_2_1.log
+DG_REDO2/redo2_2_2.log