Ziel:
Eine bestehende Produktionsdatenbank (im Beispiel PRDDB )soll in eine neue Testumgebung (im Beispiel NEWDB) geklont werden. Die neue Umgebung kann auch bereits eine 12c Umgebung sein, allerdings bin ich hier auf einen bösen Bug unter MS Windows gelaufen.
Die Produktionsdatenbank ist aus RMAN Sicht das „TARGET“ die neue DB die AUXILLARY„ Umgebung.
Bei diesen Clone Vorgang wird der Name der Datenbank geändert und eine neue Location für die Daten konfiguriert.
Namensgebung:
Ablauf:
„DUPLICATE TARGET DATABASE TO xxxx FROM ACTIVE DATABASE“ steht für Oracle Standard Edition und Enterprise Edition zur Verfügung.
Darauf achten, dass auf beiden Seiten genügend Plattenplatz zur Verfügung steht, möglichst 10/20% mehr Platz in der AUXILIARY Umgebung.
Auch darauf achten, dass die FRA (Fast/Flash Recovery Area) in der AUXILIARY ausreichend (wenigstens gleich groß!) ist.
Die Archive werden nach dem Clone KOMPLETT erst auf die AUXILIARY DB kopiert und dann eingearbeitet! D.H. genügend Platz einplannen!
In der TARGET Umgebung sicherstellen, dass alle Archivelogs, die während des Clone Vorgangs anfallen, auf der Target Maschine im „normalen“ Zugriff von RMAN liegen, d.h. am besten als normales Archivelog noch auf der Platte verfügbar sind.
Diese gilt besonders dann, wenn per SBT auf Band gesichert wird und es unklar ist wie RMAN da wieder herankommen soll (Externer Dienstleister, Bandlaufwerk defekt etc.)!
Soll der Clone Prozess dazu dienen eine Produktive Umgebung von einem Rechenzentrum in ein anderes über eine Standby Zwischenlösung umzuziehen, sollte der folgende zeitliche Ablauf beachtet werden:
Sicherstellen, dass zwischen dem Target und der AUXILIARY das SQL*Net Protokoll auf dem Port des AUXILIARY Listeners freigeschaltet ist.
Target test mit curl falls kein telnet zur Verfügung steht:
# curl http://<IP_of_AUXILIARY>:<PORT> # like curl http://192.168.178.150:1521 # good curl: (52) Empty reply from server # bad curl: (7) couldn't connect to host
Falls die Möglichkeit besteht mit ssh die Leitung zu testen, lässt sich ein erstes Timing ermitteln:
# create testfile dd if=/dev/zero of=copy_test_file.dmp bs=1M count=1000 scp copy_test_file.dmp oracle@192.168.178.150:/tmp
Muss die DB auf der AUXILIARY auf die aktuelle Software Version der Oracle Software upgedateed werden, zum Beispiel von 11.2.0.2 auf 11.2.0.3:
Da eine gestoppte Instance per SQL*Net Protokoll beim Clone Prozess gestartet werden können muss, muss die SID der AUXILIARY Datenbank explizit im Listener eingetragen werden.
Um Verbindungs-Abbrüchen bei evtl. Time-outs vorzubeugen wird der Parameter INBOUND_CONNECT_TIMEOUT gesetzt.
listener.ora
# Dedicated Service SID_LIST_LISTENER= (SID_LIST= (SID_DESC= (GLOBAL_DBNAME=GPITESTDB) (SID_NAME=GPITESTDB) (ORACLE_HOME=D:\oracle\product\11.2.0\dbhome_1))) # set the timeout INBOUND_CONNECT_TIMEOUT_LISTENER= 120
sqlnet.ora
SQLNET.INBOUND_CONNECT_TIMEOUT = 120
See Metalink Node: ORA-17629: 'Cannot connect to the remote database server' with RMAN (Doc ID 1056174.1)
Ist noch kein Listener eingerichtet, muss dieser jetzt in der entsprechenden Umgebung gestartet werden.
Target
CREATE pfile='D:\temp\initAUXILIARY.ora' FROM spfile;
vi D:\temp\initAUXILIARY.ora .. cluster_database=FALSE DB_FILE_NAME_CONVERT='+DATA01','+DATA_NEU','+DATA02','+DATA_NEU' LOG_FILE_NAME_CONVERT='+REDO01','+REDO_NEU','+REDO02','+REDO_NEU' ..
Die Password Datei der TARGET Datenbank in des dbs Verzeichniss der AUXILIARY DB kopieren. Die SYS Passwörter müssen auf beiden Seiten immer gleich sein!
set ORACLE_SID=AUXDB set ORACLE_HOME=d:\oracle\product\11.2.0.3\db_1 oradim -NEW -SID AUXDB
sqlplus / AS sysdba CREATE spfile FROM pfile;
tnsnames.ora und sqlnet.ora auf TARGET und AUXILIARY Seite im DB Home UND im Listener Home (falls z.b. Listener im GRID Enviroment läuft) exakt gleich konfigurieren und testen.
tnsname.ora
AUX_DB = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.178.150)(PORT = 6832)) (CONNECT_DATA = (SERVER = DEDICATED) (SID = NEWDB) (UR = A) ) ) TARGET_DB = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.178.28)(PORT = 6832)) (CONNECT_DATA = (SERVER = DEDICATED) (SID = PRDDB) ) )
sqlnet.ora
SQLNET.INBOUND_CONNECT_TIMEOUT = 120
In allen Umgebungen genauestens testen (Verbindung mit sqlplus aufbauen, Instance starten/stoppen/starten):
# TARGET => AUXILIARY #DB HOME sqlplus sys@AUX_DB as sysdba sqlplus sys@TARGET_DB as sysdba # AUXILIARY => AUXILIARY #DB Home sqlplus sys@AUX_DB as sysdba #DB Listener Home sqlplus sys@AUX_DB as sysdba #Listener Home sqlplus sys@AUX_DB as sysdba sqlplus sys@TARGET_DB as sysdba
Gerade der Test auf der AUXILIARY auf sich selbst ist sehr wichtig! RMAN ermittelt die TNS_ADMIN Variable aus der Listener Umgebung!
Falls dieser Fehler auftritt, liegt es meist an einer fehlerhaften TNS Konfiguration:
#RMAN output RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of Duplicate Db command at 11/21/2013 17:11:16 RMAN-05501: aborting duplication of target database RMAN-03015: error occurred in stored script Memory Script RMAN-03009: failure of backup command on ORA_DISK_1 channel at 11/21/2013 17:10:50 RMAN-10032: unhandled exception during execution of job step 1: ORA-06512: at line 623 RMAN-10035: exception raised in RPC: ORA-17629: Anmeldung bei Remote-Datenbank-Server nicht moglich ORA-17627: ORA-12154: TNS: Angegebener Connect Identifier konnte nicht aufgelost werden ORA-17629: Anmeldung bei Remote-Datenbank-Server nicht moglich ORA-06512: in "SYS.DBMS_BACKUP_RESTORE", Zeile 1381
See Metalink Node : Duplicate From Active Database Errors : ORA-17629 and ORA-17627: ORA-12154: Tns:Could Not Resolve The C (Doc ID 1144273.1)
Da ein Clone je nach Leitung auch etwas dauern kann, wird der Job zum Clonen über die Crontab gestartet.
Aufruf Script:
#!/bin/bash # # Environment DAY_OF_WEEK=`date +"%m_%d_%y_%H_%M"` export DAY_OF_WEEK # where runs the script SCRIPTPATH=$(cd ${0%/*} && echo $PWD/${0##*/}) SCRIPTS_DIR=`dirname "$SCRIPTPATH{}"` #logfile LOG=${SCRIPTS_DIR}/run_rman_job_${DAY_OF_WEEK}.log #Oracle Settings ORACLE_SID=GPIDB1 ORACLE_HOME=/oracle/GPIDB/112 PATH=/oracle/GPIDB/112/bin: TNS_ADMIN=/oracle/GPIDB/112/network/admin export ORACLE_SID export ORACLE_HOME export PATH export TNS_ADMIN #Call RMAN echo ------------- START JOB at "`date`" ---- -------------- > "${LOG}" 2>&1 echo Script $SCRIPTPATH is called in directory ${SCRIPTS} >> "${LOG}" 2>&1 # call ${ORACLE_HOME}/bin/rman @${SCRIPTS_DIR}/do_rman_job.rman >> "${LOG}" 2>&1 echo ------------- finish JOB at "`date`" ---- -------------- >> "${LOG}" 2>&1
Rman Script:
CONNECT AUXILIARY sys/xxxxxxx@AUX_DB CONNECT TARGET sys/xxxxxxx@TARGET_DB CONFIGURE DEVICE TYPE DISK PARALLELISM 1; DUPLICATE TARGET DATABASE TO <NEW_SID> FROM ACTIVE DATABASE NOFILENAMECHECK;
mit „crontab -e“ den Aufruf des Scripts einrichten. Crontab Syntax siehe auch hier: http://www.pantz.org/software/cron/croninfo.html
Oder mit „at now“, Scriptname angeben, ^d beenden.
Nach dem Start per „tail -f run_rman_job_*.log“ die Ausführung überwachen.
DB prüfen:
In einer Clusterumgebung sollte immer von der selben instance ID in Traget und Auxiliary geclonet werden ( von Instance 1 nach Instance 1 usw.)
Hat die Auxillary mehr Knoten als die Target DB und wird nun von Target Instance 1 auf die Auxillery Instance 3 geclonnet, kann es zu folgenden Fehler kommen:
RMAN-06136: ORACLE error from auxiliary database: ORA-01618: redo thread 3 is not enabled - cannot mount
Steht zwischen der Target DB und der Auxiliary DB eine FW, kann es zu Abbrüchen des SQL*Net Protokolls kommen, wenn eine gewisse Zeit die Leitung idle ist.
Fehler im Alert log der Datenbank:
ORA-00600: internal error code, arguments: [17183], [0x45353453554], [], [], [], [], [], [], [], [], [], []
siehe Metalink:
Eine Datenbank soll per Clone nach 12c kopiert werden um dort später ein Update durchzuführen.
Problem 11.2.0.4 ⇒ 12.1.0.2
Fehler:
RMAN-05501: Duplizierung von Zieldatenbank wird abgebrochen RMAN-03015: Fehler im gespeicherten Skript Memory Script RMAN-03009: Fehler bei backup Befehl in ORA_DISK_1 Kanal auf 12/03/2015 11:23:44 ORA-17629: Anmeldung bei Remote-Datenbank-Server nicht m÷glich ORA-17628: Oracle-Fehler 17630 von Remote Oracle-Server zur³ckgegeben
Keine Lösung: Patch 18633374 (nur für eine 11.2.0.4.0 ohne Patch) mit CPU 2014 klappt das einspielen nicht!! 2. Versuch : aktuellen CPU von Herbst 2015 verwenden, gleicher Fehler, allerdings läßt sich der 11.2.0.4 18633374 läßt sich hier auch nicht einspielen! Auf der 12c Seite den aktuellen CPU (21821214) einspielen, keine Besserung …
Lösung: Call Oracle eröffnen ….. .-(
Siehe Metalink Node:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would GET error below ORA-01194: file 1 needs more recovery TO be consistent ORA-01110: DATA file 1: '+GPI/gpi/datafile/system.789.232322323'
DB mit folgenden Parameter versuchen zu öffnen:
#set this paramter (CREATE pfile, edit parameter, stop dB, CREATE spfile AND START DB IN mount STATUS) : _allow_resetlogs_corruption=TRUE startup mount; recover DATABASE DATABASE USING backup controlfile until cancel; # Answer cancel ALTER DATABASE OPEN resetlogs;
Neu anlegen:
Oracle Support:
Oracle Doku:
Weitere Beispiele: