Datenbank Duplizieren Vintage Style

von Robert Marz (Kommentare: 0)

Datenbank Klone

Wenn es um das Duplizieren von Oracle Datenbanken geht, sind heutzutage RMAN Backups oder Volume-Snapshots die Mittel der Wahl.
Dabei wird gerne vergessen, dass es auch anders geht, ja gehen muss, wenn die Datenbank nicht auf einem SAN abgelegt ist und es keine RMAN-Backups gibt.

Die Aufgabe

Eine Datenbank auf einem Windows Server - nennen wir sie DBGI - soll für Testzwecke auf dem selben Server unter dem Namen DBGI2 geklont werden.

Es gibt ein Downtime-Fenster, das für die Arbeiten benutzt werden kann.

Erster Schritt: Offline Backup

Als erstes erfolgt ein Offline-Backup der Original-Datenbank, das nicht auf dem Datenbank-Server verwahrt wird.

Dieser Schritt steht in beinahe jeder Anleitung und wird gerne ignoriert.
In unserem Fall ist er aber ernorm wichtig:
Eine kleine Unachtsamkeit bei einem der nächsten Schritte kann beide Datenbanken - Original und Duplikat - komplett unbrauchbar machen.

Flußdiagramm - Komplett

Copy Controlfile

Zunächst werden die Informationen aus der Original-Datenbank gesammelt.

Den Anfang macht das Controlfile:
Controlfiles enthalten Informationen über alle Dateien, aus denen eine Datenbank besteht. Wir wollen einen Klon unter anderem Namen erstellen, dessen Datendateien in anderen Verzeichnissen liegen, als das Original.
Deswegen können wir die Controlfiles nicht einfach kopieren. Sie müssen neu erzeugt werden. Die Datenbank gibt uns das Werkzeug in die Hand, ein entrpechendes Skript zu generieren:

alter database
  backup controlfile to trace;

Dieses Kommando schreibt das Skript ins Alert.log, aus dem es herauskopiert werden kann. Bequemer ist es, das Ergebnis direkt als Skript generieren zu lassen:

alter database
  backup controlfile to trace
  as 'D:\Oracle\admin\DBGI2\scripts\copy_controlfile.sql';

Auswahl der Skript-Variante

In der erzeugten Datei sind zwei Sets von Skripten angelegt:

  1. NOResetLogs
  2. ResetLogs

Uns interessiert der zweite Fall.
Also bearbeiten wir das Skript, in dem wir zunächst alle Zeilen vom Start der Datei bis zur Zeile

--     Set #2. RESETLOGS case

löschen:

--     Set #2. RESETLOGS case
--
-- The following commands will create a new control file and use it
-- to open the database.
-- Data used by Recovery Manager will be lost.
-- The contents of online logs will be lost and all backups will
-- be invalidated. Use this only if online logs are damaged.

-- After mounting the created controlfile, the following SQL
-- statement will place the database in the appropriate
-- protection mode:
--  ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "DBGI" RESETLOGS  NOARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 6626
LOGFILE
  GROUP 1 'D:\ORACLE\ORADATA\DBGI\REDO1.LOG'  SIZE 500M BLOCKSIZE 512,
  GROUP 2 'D:\ORACLE\ORADATA\DBGI\REDO2.LOG'  SIZE 500M BLOCKSIZE 512,
  GROUP 3 'D:\ORACLE\ORADATA\DBGI\REDO3.LOG'  SIZE 500M BLOCKSIZE 512,
  GROUP 4 'D:\ORACLE\ORADATA\DBGI\REDO4.LOG'  SIZE 500M BLOCKSIZE 512,
  GROUP 5 'D:\ORACLE\ORADATA\DBGI\REDO5.LOG'  SIZE 500M BLOCKSIZE 512,
  GROUP 6 'D:\ORACLE\ORADATA\DBGI\REDO6.LOG'  SIZE 1000M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
  'D:\ORACLE\ORADATA\DBGI\SYSTEM01.DBF',
  'D:\ORACLE\ORADATA\DBGI\SYSAUX01.DBF',
  'D:\ORACLE\ORADATA\DBGI\UNDOTBS01.DBF',
  'D:\ORACLE\ORADATA\DBGI\USERS01.DBF',
  -- [...Alle weiteren Datenfiles...]
CHARACTER SET WE8MSWIN1252
;

-- Configure RMAN configuration record 1
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILE AUTOBACKUP','ON');
-- Commands to re-create incarnation table
-- Below log names MUST be changed to existing filenames on
-- disk. Any one log file from each branch can be used to
-- re-create incarnation records.
-- ALTER DATABASE REGISTER LOGFILE 'D:\ORACLE\FLASH_RECOVERY_AREA\DBGI\ARCHIVELOG\2016_07_06\O1_MF_1_1_%U_.ARC';
-- Recovery is required if any of the datafiles are restored backups,
-- or if the last shutdown was not normal or immediate.
RECOVER DATABASE USING BACKUP CONTROLFILE

-- Database can now be opened zeroing the online logs.
ALTER DATABASE OPEN RESETLOGS;

-- Commands to add tempfiles to temporary tablespaces.
-- Online tempfiles have complete space information.
-- Other tempfiles may require adjustment.
ALTER TABLESPACE TEMP ADD TEMPFILE 'D:\ORACLE\ORADATA\DBGI\TEMP01.DBF'
     SIZE 32767M REUSE AUTOEXTEND ON NEXT 655360  MAXSIZE 32767M;
ALTER TABLESPACE TEMP ADD TEMPFILE 'D:\ORACLE\ORADATA\DBGI\TEMP02.DBF'
     SIZE 2900M REUSE AUTOEXTEND ON NEXT 209715200  MAXSIZE 32767M;
-- End of tempfile additions.
--

Anpassungen an der Datei

Das generierte Skript erzeugt die Controlfiles der Original-Datenbank neu.
Wir brauchen aber Controlfiles für den Klon.
Also führen wir folgende Änderugen an dem Skript durch:

  • In der Zeile "CREATE CONTROLFILE" ändern wir den Datenbanknamen "DBGI" auf den Namen des Klons "DBGI2".
  • Anschließend werden alle Pfade, die auf das Original zeigen, auf den Klon angepasst.

Zur Sicherheit empfiehlt es sich, die Datei im Anschluss nochmals auf den Original-Namen und die Original-Pfade zu durchsuchen.
Zeigt auch nur eine Datei noch auf das Original, wenn der Klon mit dem neuen Controlfile gestartet wird, wird die Original-Datenbank korrupt.

Die Config-Files

Eine Datenbank besteht neben den Datendateien und dem Controlfile aus weiteren Konfigurationsdateien:

  • init.ora
  • pwd.ora
  • listener.ora

Die ersten beiden liegen unter Windows im Verzeichnis %ORACLE_HOME%\database, bei allen anderen Betriebssystemen $ORACLE_HOME/dbs.

init.ora

Die init.ora - genauer init<ORACLE_SID>.ora enthält die Parameter der Datenbank. Wir könnten die original init.ora kopieren und anpassen.
Aber eigentlich brauchen wir ja nur die Parameter, die von den Default-Einstellungen abweichen. Diese werden in der Original-Datenbank mit folgendem Statement ermittelt:

select name||' = '||value
  from v$parameter
 where isdefault='FALSE';

Die Ausgabe dieses Skripts schreiben wir in die Datei initDBGI2.ora und sind beinahe fertig.
Auch in den Parametern verbergen sich Pfade, die unbedingt angepasst werden müssen.

pwd.ora

Die Password-Datei initDGBI2.ora enthält die Kennwörter der sysdba-User.
Wir können die Datei der Original-Datenbank einfach kopieren.

listener.ora

Dieser Schritt ist optional.

Die listenter.ora liegt im Verzeichnis ORACLE_HOME/network/admin.
Wenn die Klondatenbank aus der Ferne über den tnslistener gestartet werden soll, muss diesem die SID und das ORACLE_HOME bekannt gemacht werden.
Dies geschieht durch einen Eintrag in der Rubrik SID_LIST_LISTENER.

Kopieren der Datenbank-Dateien

Als letzter Vorbereitungsschritt werden die Dateien des Originals in die Verzeichnisstruktur des Klons kopiert. Dies geschieht im Offline-Modus: Die Original-Datenbank ist heruntergefahren.

Kopiert werden folgende Dateiarten:

  • Datendateien
  • Redologs
  • Tempfiles

Die Tempfiles sind optional - sie werden bei der Aktivierung des Klons entweder überschrieben oder neu angelegt.

Die Original-Controlfiles dürfen nicht kopiert werden:
Als Sicherheitsmechanismus wird die Oracle Datenbank sich weigern, bestehende Controlfiles zu überschreiben.

Nur bei Windows: Anlegen eines Services mit oradim

Unter Windows muss für jede Datenbank Instanz ein Service angelegt werden, damit der Oracle-Prozess auch weiterlaufen kann, wenn sich der Benutzer abmeldet.

Dies geschieht mit dem Tool oradim:

oradim -NEW -SID DBGI2 -STARTMODE manual

Anschließend wird der neue Service gestartet.

Aktivieren des Klons

Jetzt sind alle Vorbereitungen abgeschlossen.

Bevor wir den Klon das erste Mal hochfahren, starten wir die Original-Datenbank wieder. So haben wir noch eine letzte Chance festzustellen, ob Ressourcen in beiden Datenbanken doppelt genutzt werden sollen, weil uns beim Anpassen der Dateien eine Stelle durch die Lappen gegangen ist.

Zunächst wird die ORAClE_SID auf den Klon umgesetzt, dann eine SQLPlus Session als SYSDBA gestartet

set ORACLE_SID=DBGI2
sqlplus / as sysdba

SQLPlus muss sich jetzt melden mit "Connect to an idle instance".

Kommt die Meldung "Connected to ..." hat das Setzen der ORACLE_SID nicht funktioniert und SQLPlus hat sich an der Original-Datenbank angemeldet.

Das Ausführen des copy_controlfile.sql erledigt jetzt den Rest für uns:

SQL> @"D:\Oracle\admin\DBGI2\scripts\copy_controlfile.sql"

Auffrischen des Klons

Wenn der Klon aufgefrischt werden soll, reicht es

  • beide Datenbanken zu stoppen
  • die Datendateien erneut zu kopieren
  • die Control-Files des Klons löschen
  • das copy_controlfile.sql erneut auszuführen.

Wo die Kopien der Control-Files abgelegt sind, kann dem Parameter "control_files" aus der init.ora entnommen werden. Wenn zwischenzeitlich Datendateien hinzugekommen sind, muss das copy_controlfile.sql angepasst bzw. neu erzeugt werden.

Flußdiagramm - Auffrischen

Best Practices

Die neue Datenbank ist eine exakte Kopie - inkl. aller Kennwörter, DB-Links, etc.

Dadurch, dass die beiden Datenbanken beinahe gleich heißen und auf dem gleichen Server liegen, ist es sehr einfach, versehentlich Arbeiten auf der falschen Maschine durchzuführen.
Ich empfehle als zusätzliches Unterscheidungsmerkmal, die Kennwörter der gängigen Schemas zu ändern (ein Prä- oder Postfix reicht). Dann fällt es eher auf, wenn ein Skript gegen die falsche Instanz gestartet wird.

Zurück

Einen Kommentar schreiben