Verfahren zum Auflösen von Problemen bei der Datenbankreplikation oder Synchronisierung in Prime Network

Einführung

In diesem Dokument wird ein schrittweises Verfahren zur Lösung von Problemen mit der Datenbankreplikation oder Synchronisierung im Prime Network beschrieben, wenn die Standby-Datenbank der primären Datenbank neu erstellt wird.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• Verwenden Sie dieses Verfahren, um eine sekundäre Datenbank nur dann neu zu erstellen, wenn SWITCHOVER_STATUS der primären Datenbank UNRESOLVABLE GAP lautet.
• Stellen Sie sicher, dass sich die primäre Datenbank in READ-SCHREIBUNG befindet und die sekundäre Datenbank NUR LESEN oder NUR MIT ANWENDBAREM Modus LESEN.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

• Prime Network Version 3.9 und höher
• Oracle Database 11G-Version

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrundinformationen

1. Verwenden Sie diesen Befehl, um den switchover_status der primären Datenbank zu ermitteln:

SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
UNRESOLVABLE GAP 

Hinweis: Der Prime Central Geo HA-Switchover schlägt abrupt fehl, sodass das HA-System für Prime Central und/oder der Status der Datenbank-Rolle beschädigt sind (sowohl primär als auch im Standby-Modus). Anschließend müssen Sie je nach letztem Aktiv/Standby-Status eine primäre oder sekundäre Wiederherstellung vornehmen.

Hinweis: In allen anderen Fällen können Sie SR mit dem Cisco TAC öffnen, um Probleme mit der Datenbankreplikation zu beheben.

2. Mit diesem Befehl können Sie den aktuellen Modus der primären und sekundären Datenbank ermitteln:

 SQL> select open_mode from v$database;  

Problem

Prime Network Database Replication Failure.

Prime Network-Anwendung erstellt Systemereignisse, die derartige Fehler melden, die im GUI-Client von Event Vision verfügbar sind.

Fehlerbehebung

Führen Sie vor der Projektmappe grundlegende Schritte zur Fehlerbehebung durch, z. B.:

1. Prüfen Sie die Netzwerkverbindungen und/oder latenzbedingte Probleme zwischen dem primären und sekundären Prime Network Gateway.

2. Überprüfen Sie diese Datenbankprotokolle bei Primary, um Datenbankfehler zu finden:

<database_home_directory>/diag/rdbms/anadb/anadb/trace/alert_anadb.log

3. Überprüfen Sie den Status open_mode, current_scn und switchover in Primary (Primäre und sekundäre Datenbank).

SQL> select open_mode from v$database;
SQL> select current_scn from v$database;
SQL> select switchover_status from v$database;

4. Die Ursache für die Datenbankreplikation kann durch Probleme bei der Netzwerkkommunikation zwischen dem primären und sekundären Prime Network Gateway, beschädigte Datenbanken oder ähnliche datenbankbezogene Fehler verursacht werden.

Lösung

Führen Sie das Verfahren zur Wiederherstellung der Datenbank auf dem primären und sekundären Prime Network Gateway aus:

Schritt 1: Die aktuellen geplanten Sicherungsaufträge enthalten mehrere Tage Archiv-Protokolldateien im Dateisystem. Um zu verhindern, dass aus den Archiv-Protokolldateien entfernt werden, wird diese Zeile in backup_daily.sh, backup_high_daily.sh, backup_week.sh und backup_high_week.sh wie folgt kommentiert:

Ändern Sie das Löschen noprompt Archivelog bis zum ... um #delete noprompt archivelog bis zum ...

Hinweis: Diese '.sh'-Skripte sind Eigentum von Oracle-Benutzern und können im Verzeichnis $ORACLE_HOME/ana_scripts gefunden werden.

Schritt 2: Melden Sie sich in der primären Datenbank als sysdba an, suchen Sie die Anzahl der Wiederholungsdateien im System, indem Sie diesen Befehl ausführen:

SQL> select member from v$logfile;

Führen Sie für jedes Protokoll diesen Befehl korrekt aus. Wenn der vorherige Befehl also 6 Zeilen zurückgegeben hat, führen Sie den nächsten Befehl 6 Mal aus.

SQL>alter system switch logfile;

Schritt 3: Melden Sie sich in der Standby-Datenbank als sysdba an, und erstellen Sie eine Datei aus der Spfile:

SQL>create pfile='$ORACLE_HOME/dbs/ana_sb_init.ora' from spfile;

Schritt 4: Melden Sie sich auf der Standby-Datenbank als sysdba an, und suchen Sie den Verzeichnispfad zur Datendatei, zu Sicherungsstücken, zu Redo-Protokollen und zu Archivierungsprotokolldateien. Dies kann mithilfe der folgenden Befehle erfolgen:

So suchen Sie die Datendateien:

SQL> select name from v$datafile;

So suchen Sie die Sicherungsdateien:

rman target /
RMAN> list backup;

So suchen Sie die REDO-Protokolldateien:

 SQL> select member from v$logfile;

So suchen Sie das archiveLog:

SQL> show parameter log_archive_dest_1;

Datenbank herunterfahren:

sqlplus / as sysdba
SQL> shutdown immediate;

Schritt 5: Löschen Sie alle Datendateien, Sicherungsstücke, REDO-Protokolldateien und Archivierungsdateien aus den entsprechenden Verzeichnissen (Pfad wurde in Schritt 4 gefunden).

Starten Sie anschließend die Nominierung mit der in Schritt 3 erstellten Datei neu:

sqlplus / as sysdba
SQL>startup nomount pfile='$ORACLE_HOME/dbs/ana_sb_init.ora;

Schritt 6: In der primären Datenbank erstellen Sie eine Kopie aller ursprünglichen Sicherungsstücke im Sicherungsordner und speichern sie an einem anderen Speicherort.

Schritt 7: Stellen Sie in der primären Datenbank eine Verbindung mit RMAN her, und verwenden Sie zum Löschen der Sicherung, um alle physischen Sicherungsstücke aus dem Dateisystem zu entfernen.

#rman target /
RMAN>delete backup;

Schritt 8: Auf der primären Datenbank stellen Sie eine Verbindung mit RMAN her und sichern Sie die Datenbank, die Standby-Steuerdatei und die Archivierung in dieser Reihenfolge. Führen Sie folgende Befehle aus:

#rman target /
RMAN>backup database;
RMAN>backup format '$BACKUP_DIR/Control%U' current controlfile for Standby;
RMAN>backup archivelog all;

Hinweis: Der $BACKUP_DIR ist der aktuelle Backup-Ordner, der mit der vorherigen Listensicherung gefunden wurde, und die Datei wird zukünftig als Control%U bezeichnet. Es ist keine Variable.

Schritt 9: Stellen Sie in der primären Datenbank eine Verbindung mit dem RMAN her, und verwenden Sie die Listensicherung, um den ckp-Scan für das in Schritt 8 erstellte Standby-Kontrollfeld zu ermitteln. Suchen Sie nach der Datei mit dem Namen $BACKUP_DIR/Control%U.

BS-Schlüsselletyp LV-Größe Gerätetyp Verstrichene Zeit Fertigstellungszeit

— — — — — — — — —

2358 Full 1,09M DISK 00:00:04 21-JAN-14

BP-Schlüssel: Status 2358: Verfügbar komprimiert: JA-Tag: TAG 20140121T162311

Artikelname: /export/home/oracle/backup/Control9nouks3f_1_1

Standby-Steuerdatei enthalten: CP-SCN: 164541747 CKP-Zeit: 21. Januar 2014

Hinweis: In diesem Beispiel lautet die Standby-Sicherungsdatei "/export/home/oracle/backup/Control9nouks3f_1_1". In der Zeile unter diesem Dateinamen sehen Sie "Ckp SCN: 164541747" In Schritt 13 verwenden wir die Nummer "164541747" im Duplizierungs-Ausführungsblock.

Schritt 10: Bereiten Sie auf der primären Datenbank alle Sicherungsstücke auf, die in Schritt 8 erstellt wurden. Als root-Benutzer-SCP wird die TAR-Datei in den Sicherungsordner in der Standby-Datenbank gespeichert.

Schritt 11: Melden Sie sich bei der Standby-Datenbank als root an, und ändern Sie mithilfe der Option chown das Dateieigentum der TAR-Datei in oracle:dba. Wechseln Sie dann den Benutzer zurück zu oracle(su - oracle) und enttar die tar-Datei.

Schritt 12: Melden Sie sich auf dem primären Gateway als Benutzer des primären Netzwerks an, und führen Sie den Befehl "cd to ~/Main" aus, um das sys-Kennwort abzurufen:

./runRegTool.sh –gs 127.0.0.1 get 127.0.0.1 persistency/general/EmbeddedDBSystemPass

Hinweis: Das zurückgegebene Kennwort sys wird im nächsten Schritt für die Verbindung mit der Standby-Datenbank aus der primären Datenbank verwendet.

Schritt 13: Herstellen einer Verbindung zur Zieldatenbank (primär) und dann zur Zusatzdatenbank (Standby) in der primären Datenbank. Führen Sie dann einen doppelten Ausführungsblock aus, um die Standby-Datenbank zu erstellen:

#rman target /
RMAN>connect auxiliary sys/$sys_pwd@ANADB_SB
RMAN>run {
set until scn $SCN_NUMBER;
duplicate target database
for Standby
dorecover
spfile
set "db_unique_name"="anadb_sb"
set LOG_ARCHIVE_DEST_2="Service=anadb ASYNC LGWR VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
database_unique_name=anadb"
set FAL_CLIENT="anadb_sb"
set FAL_SERVER="anadb"
set log_file_name_convert="$REDO","$REDO"
nofilenamecheck;
}

Hinweis: $sys_pwd ist das sys-Kennwort, das Sie in Schritt 12 erhalten haben. Die $SCN_NUMBER im Testblock wird in Schritt 9 abgerufen. als Beispiel. $REDO ist der Speicherort für das Wiederholungsprotokoll gefolgt von /.

Schritt 14: Nach dem Ausführen des Blocks in Schritt 13. beendet, dann auf der Standby-Datenbank anmelden als sysdba und führen diese Befehle aus, um die Standby-Datenbank im schreibgeschützten Modus aufzurufen, gefolgt von einem schreibgeschützten Modus mit Anwenden:

sqlplus / as sysdba
SQL>shutdown immediate;
SQL>startup nomount;
SQL>alter database mount Standby database;
SQL>recover managed Standby database using current logfile disconnect from session;
SQL>recover managed Standby database cancel;
SQL>alter database open read only;
SQL>recover managed Standby database using current logfile disconnect from session;

Schritt 15: Nach der Überprüfung der primären Datenbank entfernen Sie diese Zeile in backup_daily.sh,backup_high_daily.sh, backup_week.sh und backup_high_week.sh:

Ändern Sie #delete noprompt archivelog bis zum ... um noprompt archivelog zu löschen bis ...

Überprüfen

Datenbanküberprüfung auf primärem und sekundärem Prime-Netzwerk-Gateway:

1. Überprüfen Sie, ob Anzahl und Namen der Redo-Protokolldateien in der primären und Standby-Datenbank identisch sind.

2. Überprüfen Sie, ob Anzahl und Größe der Datendateien in der primären und Standby-Datenbank identisch sind.

3. Verwenden Sie diesen Befehl in der primären und der Standby-Datenbank, um anzuzeigen, dass die aktuelle SCN in der Standby-Datenbank SCN in der primären Datenbank abrufen kann:

sqlplus / as sysdba
SQL>select current_scn from v$database;

4. Stellen Sie sicher, dass der open_mode der primären Datenbank READ WRITE und READ ONLY WITH APPLY auf Standby-Datenbank lautet.

sqlplus / as sysdba
SQL>select open_mode from v$database;

5. Stellen Sie sicher, dass der switchover_status of primary auf STANDBY und NICHT auf Standby-Datenbank ZULÄSSIG ist:

sqlplus / as sysdba 
SQL>select switchover_status from v$database;

6. Überprüfen, ob die Archivprotokolle übertragen werden

Primarydatabase:

SQL> alter system switch logfile;

Sekundäre Datenbank:

Überprüfen Sie, ob eine neue Datei in ~/arch erstellt wird.

7. Vergewissern Sie sich, dass in der Benutzeroberfläche von Event Vision ab jetzt (in den nächsten 20 Minuten) kein Fehler bei der Datenbankreplikation angezeigt wird.