Einführung
In diesem Dokument wird ein schrittweises Verfahren zur Lösung von Problemen mit der Datenbankreplikation oder Synchronisierung in Prime Network beschrieben, indem die Standby-Datenbank aus 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 APPLY-Modi LESEN.
- Stellen Sie sicher, dass Sie das richtige primäre und sekundäre Prime Central-Gateway/-Datenbank identifizieren.
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:
- Prime Central Version 1.2 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;
3. Verwenden Sie diesen Befehl, um ORACLE_SID der primären und sekundären Datenbank zu kennen:
Auf primärem Gateway vom Oracle-Benutzer:
echo $ORACLE_SID -> output should be “primedb”
Auf sekundärem Gateway vom Oracle-Benutzer:
echo $ORACLE_SID -> output should be “primstdb”
Problem
Prime Central GEO HA-Switch und/oder Failover/Failback-Verfahren schlagen fehl, wenn Active- und Standby-Datenbanken nicht synchronisiert sind. Dies führt dazu, dass sowohl die primäre als auch die Standby-Datenbank gleichzeitig aktiv oder im Standby-Modus arbeiten.
Fehlerbehebung
Bevor Sie der Lösung folgen, können Sie grundlegende Fehlerbehebungsschritte ausführen:
1. Prüfen Sie die Netzwerkverbindungen und/oder latenzbedingte Probleme zwischen dem primären und sekundären Prime Network Gateway.
2. Überprüfen Sie dieses Datenbankprotokoll auf Primär, 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 Hauptursache für die Datenbankreplikation könnte hauptsächlich das Problem der Netzwerkkommunikation zwischen der primären und sekundären Prime Central-Datenbank, beschädigte Datenbanken oder ähnliche datenbankbezogene Fehler sein.
Lösung
Schritt 1: Überprüfen Sie die ORACLE_SID auf dem primären und sekundären Gateway/den Datenbanken.
Auf primärem Gateway/Datenbank ORACLE_SID = primedb
Auf sekundärem Gateway/Datenbank ORACLE_SID = primdtdb
Wenn ORACLE_SID auf einem der primären oder sekundären Gateways nicht wie oben beschrieben angezeigt ist, konfigurieren Sie mit diesem Befehl die richtige SID:
setenv ORACLE_SID = <value>
Hinweis: Hier <Wert > = primedb oder primstdb basiert auf dem primären oder sekundären.
Schritt 2: Melden Sie sich unter Active Database (Aktive und Standby-Datenbank) als sysdba an, und suchen Sie den Verzeichnispfad zur Datendatei, führen Sie Protokolle erneut aus und archivieren Sie Protokolldateien.
Verwenden Sie folgende Befehle:
So suchen Sie die Datendateien:
SQL> select name from v$datafile;
So suchen Sie die REDO-Protokolldateien:
SQL> select member from v$logfile;
So suchen Sie das Archivprotokoll:
SQL> show parameter log_archive_dest_1;
Schritt 3: Um die Datenbank neu zu erstellen, führen Sie dieses Skript mit der richtigen Syntax aus, nachdem Sie das in Schritt 4 beschriebene richtige Szenario identifiziert haben.
sh PCoracleADG.ksh [PRIMARY] [STANDBY] [DB_TO_BE_DROPPED] [SYSTEM_PASSWD] [ORACLE_BASE]
[ORACLE_USER] [ARCHIVED_LOG_LOCATION] [ORACLE_DATA_FILES_LOCATION] [REDO_LOG_LOCATION]
Hinweis: Skript wird unter $ORACLE_BASE/Standby-Ordner kopiert und muss als Oracle-Benutzer ausgeführt werden.
Schritt 4: Identifizieren Sie jedes Szenario mit dem aktuellen Status Ihrer Einrichtung, und fahren Sie entsprechend fort:
Hinweis: Als Beispiel wird davon ausgegangen, dass HA1 das primäre Gateway/die primäre Datenbank und HA2 das sekundäre Gateway/die sekundäre Datenbank ist.
Szenario 1: HA1 ist aktiv und muss die Standby-Datenbank auf HA2 neu erstellen. Verwenden Sie diese Parameter, und führen Sie das in Schritt 3 erwähnte Skript aus. auf HA2.
PRIMARY = primedb
STANDBY = primstdb
DB_TO_BE_DROPPED = primstdb
SYSTEM_PASSWD = use Step 5
ORACLE_BASE = /orahome/oracle
ORACLE_USER = oracle
ARCHIVED_LOG_LOCATION = output of ‘show parameter log_archive_dest_1;&rsquo
ORACLE_DATA_FILES_LOCATION = output of ‘select name from v$datafile;&rsquo
REDO_LOG_LOCATION = output of ‘select member from v$logfile;’
Szenario 2: HA2 ist aktiv und muss die Standby-Datenbank auf HA1 neu erstellen. Verwenden Sie diese Parameter, und führen Sie das in Schritt 3 erwähnte Skript aus. auf HA1.
PRIMARY = primedb
STANDBY = primstdb DB_TO_BE_DROPPED = primedb SYSTEM_PASSWD = Step 5 ORACLE_BASE = /orahome/oracle ORACLE_USER = oracle ARCHIVED_LOG_LOCATION = Ausgabe von "show parameter log_archive_dest_1;&rsquo ORACLE_DATA_FILES_LOCATION = Ausgabe Name aus v$datafile auswählen;&rsquo REDO_LOG_LOCATION = Ausgabe von "select member from v$logfile";
Schritt 5: Mit diesem Verfahren erfahren Sie <SYSTEM_PASSWD>:
su - prime auf HA1 oder HA2
grep Embedded_SYSTEM_PASS= install/conf/.db.conf
Wenn es z. B. Embedded_SYSTEM_PASS=90f8006cd6bc0dde hat, dann:
- java -cp install/utils/encryptionUtil.jar EncodeDecode decrypt 90f8006cd6bc0dde.
- Prime Central gibt eine Ausgabestrategie zurück, die in Schritt 4 als SYSTEM_PASSWD verwendet wird.
Ü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 Active-Datenbank und in der Standby-Datenbank gleich sind.
2. Überprüfen Sie, ob Anzahl und Größe der Datendateien in der aktiven Datenbank und der Standby-Datenbank identisch sind.
3. Verwenden Sie diesen Befehl sowohl in der aktiven als auch in der Standby-Datenbank, um anzuzeigen, dass die aktuelle SCN in der Standby-Datenbank den Scanvorgang in der primären Datenbank abfangen kann:
sqlplus / as sysdba
SQL>select current_scn from v$database;
4. Überprüfen Sie, ob die Database_roleof Active-Datenbank PRIMARY und die Standby-Datenbank LOGICAL_STANDBY lautet.
sqlplus / as sysdba
SQL>select database_role from v$database;
5. Stellen Sie sicher, dass der open_mode der aktiven Datenbank READ WRITE und READ ONLY WITH APPLY auf Standby-Datenbank lautet.
sqlplus / as sysdba
SQL>select open_mode from v$database;
6. Stellen Sie sicher, dass der switchover_status von Active AUF STANDBY und NICHT ZULÄSSIG in der Standby-Datenbank lautet:
sqlplus / as sysdba
SQL>select switchover_status from v$database;
7. Überprüfen Sie, ob die Archivprotokolle übertragen werden:
In der aktivierten Datenbank:
SQL> alter system switch logfile;
In Standby-Datenbank:
Überprüfen Sie, ob eine neue Datei in ~/arch erstellt wurde.