Benutzer-Werkzeuge

Webseiten-Werkzeuge

Action disabled: index

dba:db_clone_rman_active_database_online

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:

 Ü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://<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

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<SID>.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 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 <NEW_SID> 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:

Weitere Beispiele:

Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
"Autor: Gunther Pipperr"
dba/db_clone_rman_active_database_online.txt · Zuletzt geändert: 2015/12/06 17:38 von gpipperr