===== Eine Oracle Datenbank 11g R2 mit RMAN "DUPLICATE TARGET DATABASE TO xxxx FROM ACTIVE DATABASE " klonen === **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: * TARGET => die Quelle für den Klone, die Produktionsdatenbank, im Beispiel PRDDB * AUXILIARY => die neue Datenbank Umgebung, Im Beispiel die NEWDB **Ablauf:** * Plattenplatz zwischen TARGET und AUXILIARY prüfen, min. 10% mehr Plattenplatz auf AUXILIARY einplanen (inkl. Flashrecovery Area!) * Sicherstellen, dass alle Archvielogs vom Start des Clone bis zum öffnen des Clone auf der Target Seite zur Verfügung stehen * Netzwerkverbindung zwischen den Servern prüfen, Minimum: TARGET => AUXILIARY über SQL*Net Protokoll auf Listener Port Nummer der AUXILIARY! * Falls Upgrade auf AUXILIARY Seite geplannt: * Upgrade Script auf Target Seite laufen lassen * Auf die Timezone Definition achten, AUXILIARY sollte sich gleich dem Target einstellen lassen! * Listener auf der AUXILIARY konfigurieren * Vorbereiten der neuen Datenbank Umgebung * PFile aus dem SPFile der TARGET Datenbank erzeugen * PFile bzgl. der neuen Umgebung konfigurieren und auf die neue DB Umgebung kopieren * Password Datei der Target DB in das "$ORACLE_HOME/dbs" Verzeichnis kopieren * Aufsetzen einer neuen Instance ohne Datendateien und Controlfile ( die AUXILIARY Instance ) * TNS Alias auf genau TARGET und AUXILIARY setzen * AUXILIARY über sqlplus starten (damit wird auch getestet ob das später für RMAN funktioniert!) * Skripts für Aufruf über Crontab/AT Job auf der TARGET erstellen * Clone Prozess starten * DB prüfen === Lizenzüberlegung === "DUPLICATE TARGET DATABASE TO xxxx FROM ACTIVE DATABASE" steht für Oracle Standard Edition und Enterprise Edition zur Verfügung. ==== Plattenplatz ==== 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! ====Archivelogs der TARGET zur Verfügung stellen ==== 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.)! ===Backup Scripte anpassen=== * Archive dürfen erst nach X Tagen gelöscht werden ("delete archivelog until time 'trunc(sysdate) - 5';") * Archive dürfen nur einmal gesichert werden ("backup archivelog all not backed up 1 times;") damit nicht bei jedem Backup alle vorhandenen Archive doppelt gesichert werden! * Backup sollte nicht pauschal gelöscht werden! (Test ob ein "delete obsolete; im Script eingesetzt wird!) === Überlegungen zu Kopierlaufzeiten === 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: {{ :dba:rman_clone_archivelog_ueberlegungen_v01.png?600 | Überlegungen zu RMAN Clone}} ==== Netzwerkverbindung ==== 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://: # 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 ==== Upgrade der DB auf AUXILIARY Seite geplannt ==== 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: * Upgrade Script auf Target vor dem Clone Prozess laufen lassen (kann online in der Produktion erfolgen) * Hinweise befolgen * Auf die Timezone Definitions achten! Zur Not alte Timezone files von der Target zur Auxillary kopieren ===== Listener auf der AUXILIARY konfigurieren ==== 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. ==== Neue DB Umgebung vorbereiten (AUXILIARY) ==== === SPfile als Pfile erstellen === **Target** create pfile='D:\temp\initAUXILIARY.ora' from spfile; === Pfile anpassen === * Cluster Modus aus, falls RAC Umgebung * Datennamen konvertieren, falls unterschiedliche ASM Group Namen * Je nach Bedarf weitere Parameter anpassen 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' .. * Den evtl. Parameter für die compatible Einstellung "*.compatible='11.2.0.2'" sollte im ersten Schritt so bleiben,auch wenn die Software auf der AUXILIARY eine neuere Version hat! Die DB Version muss für den Clone Vorgang übereinstimmen. === Password Datei der Target DB in das "$ORACLE_HOME/dbs" bzw. "%ORACLE_HOME%\database" Verzeichnis kopieren === 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! === Neue DB Instance auf dem AUXILIARY Server konfigurieren === * Editiertes Pfile in das dbs Verzeichnis auf dem AUXILIARY Server kopieren und auf den Namen der neuen DB editieren (init.ora!) * Pfade und Verzeichniss im spfile prüfen und je nach Bedarf auf dem neuen Server diese anlegen und rechte vergeben * Auf die Location der Controlfiles achten! * Linux: * SID in der Umgebung setzen und DB Instance mit "startup nomount" starten * Windows: * Window Service mit oradim anlegen, autostart der instance vorerst auschalten, DB Instance mit "startup nomount" starten set ORACLE_SID=AUXDB set ORACLE_HOME=d:\oracle\product\11.2.0.3\db_1 oradim -NEW -SID AUXDB * Um den Startmode zu kontrollieren siehe [[dba:start_db_windows|Start der Oracle Instance unter Windows]] * Spfile aus dem text Pfile erzeugen: sqlplus / as sysdba create spfile from pfile; ==== TNS Alias auf TARGET und AUXILIARY setzen ===== 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) ==== AUXILIARY über sqlplus starten ==== Vor dem starten des Clone Vorgangs die AUXILIARY DB im nomount Status starten/prüfen. 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 FROM ACTIVE DATABASE NOFILENAMECHECK; ==== Clone Prozess starten - Scripts für Crontab aufrufen ===== 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 ===== DB prüfen: * TEMP Tablespase - Pürfen ob groß genug ist oder ob ein autoexent Wert gesetzt werden muss ===== Weitere mögliche Fehler ===== === ORA-01618: redo thread is not enabled === 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 ===TNS-00505: Operation timed out - ORA-00600: internal error code, arguments: [17183], [0x45353453554], [], [], [], [], [], [], [], [], [], [] === 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: * RMAN active duplicate ORA-19558 ORA-19557 ORA-17627 ORA-01041 ORA-03113 ORA-600 [17183] (Doc ID 1332601.1) ===ORA-17628: Oracle-Fehler 17630 von Remote Oracle-Server zurückgegeben=== 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: * Copying File Across Remote Servers: ASMCMD-8016, ORA-17628, ORA-17630, ORA-06512 (Doc ID 1918906.1) === DB läßt sich nicht öffnen === 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; === Mehr RAC Knoten als zu vor === Neu anlegen: * Redo log Gruppen für die neuen Knoten * ( alter database add logfile thread 3 group 10 size 1G;) * Threads enablen * (alter database enable public thread 2; ) * Undo Tablespace für die neuen Knoten * ( create undo tablespace undo3 .... ) ===== Quellen ===== Oracle Support: * RMAN 'Duplicate From Active Database' Feature in 11G (Doc ID 452868.1) * Known issues with RMAN DUPLICATE FROM ACTIVE DATABASE (Doc ID 1366290.1) * Step by Step Guide on Creating Physical Standby Using RMAN DUPLICATE...FROM ACTIVE DATABASE (Doc ID 1075908.1) * RMAN 'Duplicate Database' Feature in Oracle9i / 10G and 11.1 (Doc ID 228257.1) Oracle Doku: * http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmdupdb.htm#BRADV010 Weitere Beispiele: * http://www.oracle-base.com/articles/11g/duplicate-database-using-rman-11gr2.php#active_database_duplication * http://farooqkhalid.blogspot.de/2011/03/duplicating-oracle-11gr2-database-using.html * http://www.dba-oracle.com/t_integrating_streams_replication_standby_databases.htm