Gelegentlich kann es vorkommen, dass eine Datenbank „so wie sie ist“ auf einen anderen Server verschoben werden soll. Kann man dabei eine Downtime in Kauf nehmen, stellt sich die Sache als relativ simpel dar:

Auf dem Zielsystem muss exakt dieselbe Verzeichnisstruktur wie auf dem Quellsystem geschaffen werden; insbesondere die Dump-Verzeichnisse (bdump, udump, etc.), die Control-Files, die Redo-Logs und natürlich die Datenfiles müssen an dieselbe Stelle verschoben werden. Nicht zu vergessen das SPFILE (sofern vorhanden), die INIT.ORA und das Password-File; alle drei Dateien befinden sich überlicherweise unter $ORACLE_HOME/dbs bzw. /database.

Auf Windows-Systemen ist ein weiterer Schritt erforderlich: hier muss der Dienst neu angelegt werden, der die Instanz erzeugt. Dies geschieht mit dem Oracle-Tool ORADIM.

oradim -new -sid orcl

„ORCL“ ist hierbei die zu vergebende SID. Im Dienstemanager von Windows taucht dann sofort der Dienst „OracleServiceORCL“ auf. Nun stellt man diesen ggf. noch auf „Automatisch starten“ und schon kann man die verschobene Datenbank hochfahren.

Im Netzwerk bzw. auf den Clients muss dann noch die Net8-Konfiguration geändert werden, damit die Clients auch wissen, wo sich die neue Datenbank befindet.

Heute hat mich ein Fehler bei der Installation des GridControl 10.2.0.1 aufgehalten (komplette Installation mit neuer Datenbank): Nachdem die Dateien für das RDBMS installiert und verlinkt wurden, bricht der Installer beim Kopieren der Dateien für die „Oracle Enterprise Manager Grid Control Console“ mit einem Laufzeitfehler ab:

Im Logfile steht so etwas wie

INFO: Exception occured during spawning :java.io.IOException: /u01/app/oracle/product/10.2.0/oms10g/bin/OracleAS_Relink_Patch.sh: cannot execute
INFO: Spawning the modified command :/u01/app/oracle/product/10.2.0/oms10g/bin/OracleAS_Relink_Patch.sh
INFO: Ausnahme von Aktion: Spawn
Name der Ausnahme: RuntimeException
Zeichenfolge der Ausnahme: Fehler während der Laufzeit.
Ausnahmegrad: 0

Des Rätsels Lösung: die aktuelle Installation nicht (!) beenden und in einem weiteren Terminalfenster

chmod +x /u01/app/oracle/product/10.2.0/oms10g/bin/OracleAS_Relink_Patch.sh

ausführen. Dann mit „Wiederholen“ die Installation fortsetzen.

Anschließend ereilt uns folgende Meldung:

Hier muss man die Installation aller Komponenten stoppen und den Installer erneut starten. Dann wählt man „Nicht abgeschlossene Installation wiederaufnehmen“. Dann klappt’s.

Weitere Infos hier.

Mit den folgenden Abfragen kann man ganz elegant DDL-Scripte eines oder mehrerer User aus der Datenbank extrahieren:

SQL> select dbms_metadata.get_ddl('USER','TEST') from dual;
DBMS_METADATA.GET_DDL('USER','TEST')
--------------------------------------------------------------------------------
   CREATE USER "TEST" IDENTIFIED BY VALUES 'S:BB9F382BFDA8AF92EE4AFC033609CAB510
1E5ED198D7CB942F4E9ABDD038;8CF86D821FB0249F'
      DEFAULT TABLESPACE "USERS"
      TEMPORARY TABLESPACE "TEMP"

SQL> select dbms_metadata.get_granted_ddl('ROLE_GRANT','TEST') from dual;
DBMS_METADATA.GET_GRANTED_DDL('ROLE_GRANT','TEST')
--------------------------------------------------------------------------------
   GRANT "CONNECT" TO "TEST"
   GRANT "RESOURCE" TO "TEST"

SQL> select dbms_metadata.get_granted_ddl('SYSTEM_GRANT','TEST') from dual;
DBMS_METADATA.GET_GRANTED_DDL('SYSTEM_GRANT','TEST')
--------------------------------------------------------------------------------
  GRANT UNLIMITED TABLESPACE TO "TEST"

SQL> select dbms_metadata.get_granted_ddl( 'OBJECT_GRANT', 'TEST') from dual;
DBMS_METADATA.GET_GRANTED_DDL('OBJECT_GRANT','TEST')
--------------------------------------------------------------------------------
  GRANT SELECT ON "SYS"."SYS_DUMMY" TO "TEST"

Setzt man alle vier Abfragen untereinander, hat man ein funktionsfähiges Script, um einen bestehenden User zu „klonen“:

select dbms_metadata.get_ddl('USER','TEST') from dual
union
select dbms_metadata.get_granted_ddl('ROLE_GRANT','TEST') from dual
union
select dbms_metadata.get_granted_ddl('SYSTEM_GRANT','TEST') from dual
union
select dbms_metadata.get_granted_ddl( 'OBJECT_GRANT', 'TEST') from dual;

Der Nachteil dieser Vorgehensweise ist die hässliche Eigenart von Oracle, dass, wenn ein Aufruf von GET_GRANTED_DDL keinen Wert zurückliefert (wenn z.B. keine Rechte vergeben sind), folgende Fehlermeldung erscheint:

SQL>  select dbms_metadata.get_granted_ddl( 'OBJECT_GRANT', 'SCOTT' ) from dual;
ERROR:
ORA-31608: Angegebenes Objekt vom Typ OBJECT_GRANT nicht gefunden
ORA-06512: in "SYS.DBMS_SYS_ERROR", Zeile 86
ORA-06512: in "SYS.DBMS_METADATA", Zeile 3915
ORA-06512: in "SYS.DBMS_METADATA", Zeile 5826
ORA-06512: in Zeile 1

Es wurden keine Zeilen ausgewahlt

Wie man das o.g. Script so ergänzen kann, dass diese Meldung vorher abgefangen werden, erfährt man bspw. hier und hier.

Ein interessantes Projekt, das zeigt, wie schnell Kennwörter unter Oracle geknackt werden können:

http://ops.conus.info/

Der Algorithmus schafft ~60 Millionen potenzielle Passwörter pro Sekunde.

Beim Einsatz von Data Pump ab 10g mag sich mancher wundern, wo der CONSISTENT-Parameter geblieben ist. Dieser Parameter stellte beim EXP-Tool die Konsistenz der Daten während des gesamten Exports sicher — kein völlig unwichtiges Feature also.

Bei Data Pump (EXPDP / IMPDP) übernehmen diese Funktion die Parameter FLASHBACK_SCN und FLASHBACK_TIME. Diese Parameter schließen sich bei Benutzung gegenseitig aus. Der Einsatz von FLASHBACK_SCN sichert die Konsistenz eines Exports zu einer bestimmten SCN, und FLASHBACK_TIME zu einem bestimmten Zeitpunkt. Üblicherweise würde man hier SYSDATE bevorzugen.

Das Ganze liest sich dann wie folgt:

#> expdp system/passwd directory=flsh dumpfile=user001_2.dmp
  logfile=user001_2.log schemas=usr001
  flashback_time="TO_TIMESTAMP (TO_CHAR (SYSDATE, 'YYYY-MM-DD HH24:MI:SS'),
    'YYYY-MM-DD HH24:MI:SS')"

Hierzu wird übrigens das Feature „Flashback Query“ herangezogen, die FLASHBACK AREA muss hierfür nicht definiert sein. „Flashback Query“ bedient sich aus dem UNDO-Tablespace.

Interessant hierzu ist der Metalink Artikel 377218.1: Expdp Message „FLASHBACK automatically enabled“ Does Not Guarantee Export Consistency. Demnach wirft EXPDP die Meldung „FLASHBACK automatically enabled“ aus, was aber nicht automatisch heißt, dass der gerade gestartete Export konsistent ist. Um dies zu erreichen, muß immer mit den Parametern FLASHBACK_SCN oder FLASHBACK_TIME gearbeitet werden.

Bei EXP/IMP kannte nur EXP den CONSISTENT-Parameter, bei Datapump sind es sowohl EXPDP wie auch IMPDP — schließlich kann IMPDP via Network-Link auch „exportieren“.

Im Rahmen einer Migration bin ich heute über den Bug 4513695 gestolpert: der Datapump-Export braucht unter Umständen sehr lange für das Bestimmen der Tabellen-Größen, noch bevor der eigentliche Export angefangen hat.

Genau genommen handelt es sich hier ja um den Datapump-Import, da der NETWORK_LINK-Parameter nur beim IMPDP möglich ist.

Jedenfalls scheint der IMPDP hier ewig lange festzuhängen, ohne dass sich etwas bewegen würde:

Starting "SYSTEM"."SYS_IMPORT_SCHEMA_04":  system/******** LOGFILE=imdp.log PARALLEL=4
  REMAP_SCHEMA=scott:scott_clone SCHEMAS=scott network_link=orcl

Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA

Und dann war’s das für lange, lange Zeit.

Die Lösung des Problems steht u.a. in Metalink Note 416238.1: Impdp With NETWORK_LINK Runs Very Slowly at Estimate Stage.
Die Lösung des Problems ist einfach:

ALTER SYSTEM SET CURSOR_SHARING='EXACT';

in der Zieltabelle ausführen und dann geht’s. Eine Übersicht, welche Datenbank welchen Parameter „verträgt“, findet man in Metalink-Note 421441.1.

Oracle hat mit Datapump ab 10g ein neues Tool eingeführt, das die alteingesessenen, aber bewährten Tools EXP und IMP ablösen soll. Dabei ist es deutlich mächtiger, bringt aber auch einige Einschränkungen im Vergleich zur bisherigen Vorgehensweise mit sich. Doch dazu in einem späteren Artikel mehr.

Datapump kann hervorragend zum Klonen ganzer Schemata (neudeutsch auch Schemas) benutzt werden, und das sogar ohne eine Export-Datei anzulegen.

Hierzu bedient man sich der NETWORK_LINK-Funktionalität von Datapump, in dem es unter Umgehung des Filesystems die zu importierenden Daten direkt aus der Quelldatenbank saugt. Notwendig hierzu ist ein DATABASE LINK auf die Quelldatenbank. Will man ein Schema in der gleichen Datenbank klonen, legt man einfach einen Link auf die eigene Datenbank an (loopback).

Beispiel: wir möchten die Schemas SCOTT und EMILY in die Schemas SCOTT_CLONE und EMILY_CLONE klonen. Quell- und Zieldatenbank sind identisch: ORCL.

Zunächst wird der Database Link angelegt, z.B. mit

CREATE PUBLIC DATABASE LINK "TO_ORCL" CONNECT TO "SYSTEM" IDENTIFIED by "manager" USING 'orcl'

Wie der Dokumentation zu entnehmen ist, sollte für das Logfile ein Directory-Objekt vorhanden sein:

CREATE DIRECTORY "DATA_PUMP_DIR" AS '/u01/oracle/admin/ORCL/dpdump'

Dann startet man den IMport, denn der EXport wird bei Verwendung des Network-Modus impliziert:

impdp system network_link=to_orcl logfile=cloning.log
remap_schema='SCOTT':'SCOTT_CLONE','EMILY':'ELIMY_CLONE' schemas=SCOTT,EMILY

Dies ist ein Beispiel mit zwei zu klonenden Schemas, das funktioniert natürlich auch mit einem oder auch drei equivalent.

Wichtig ist, dass man SCHEMAS=… angibt, sonst kopiert Datapump die gesamte Datenbank (was nicht funktionieren würde), und remappt dabei die angegebenen Schemas.

Heute stellen wir ein typisches RMAN-Backup-Script vor, dass man in einer 10g-Umgebung zur vollständigen Datenbanksicherung benutzen kann. Zunächst meldet man sich beim RMAN an (ORACLE_SID ist gesetzt):

rman target /

Hier wird das Controlfile als Katalog benutzt, kein Katalog-Repository. Die aktuellen Einstellungen lässt man sich mit

RMAN> show all;

ausgeben.

Wir ändern die grundlegenden Einstellungen:

RMAN> configure channel device type disk format ‘z:\backup\rman_%d_t%t_s%s_p%p’;
=> Bestimmt das Zielverzeichnis für die Sicherung und den Aufbau der Dateinamen.

RMAN> configure controlfile autobackup format for device type disk to ‘z:\backup\%F’;
=> Bestimmt das Zielverzeichnis für das Controlfile-Autobackup. %F ist die DBID und sollte im Namen vorkommen.

RMAN> configure controlfile autobackup on;
=> Das automatische Backup des Controlfiles wird eingeschaltet.

RMAN> configure retention policy to redundancy 2;
=> Es werden 2 Backup-Sätze aufbewahrt.

RMAN> configure backup optimization on;
=> Es werden nur neue Archivelogs gesichert, nicht immer alle.

Mit diesem Script starten wir das Backup:

RMAN> run {
backup database plus archivelog delete all input;
backup current controlfile;
backup spfile;
}

Zunächst werden alle Datendateien gesichert. Dann wird das aktuelle Logfile archiviert, die Archivelogs gesichert, das dann aktuelle Logfile ebenfalls archiviert und auch gesichert. (Diesen ganzen Vorgang steuert ab 10g das ‘plus archivelog’-Statement.) Zu guter Letzt werden die gesicherten Archivelogs aus dem Quellverzeichnis (z.B. der Flash Recovery Area) gelöscht.

Das „backup current controlfile“ benötigt man eigentlich nicht, wenn „autobackup controlfile“ aktiviert ist, aber doppelt genäht hält einfach besser. Außerdem ist man als DBA grundsätzlich mißtrauisch.

Am Ende wird das SPFILE gesichert, was natürlich nur Sinn macht, wenn die Datenbank auch mit einem SPFILE gestartet wurde.

Überprüfen kann man das Backup z.B. mit

RMAN> report need backup;

Hier darf es kein Ergebnis geben, sofern das Kommando zeitnah nach dem Backup ausgeführt wird.

RMAN> list backup summary;

…listet alle Backups auf.

RMAN> restore database validate;

…prüft, ob die Datenbank im Fehlerfall wieder vollständig zurückgeholt werden könnte.

Achtung: RMAN sichert unter Windows nicht auf Netzlaufwerken und/oder in UNC-Pfaden. Ein Backup muss auf eine lokale Platte stattfinden, anschließend kann z.B. mit ROBOCOPY das lokale Backup-Verzeichnis mit einem Pfad im Netzwerk abgeglichen werden.

Wer wissen möchte, wie sich seine Tablespaces in den letzten Wochen speicherplatzmäßig entwickelt haben, kann dies ganz einfach durch ein einfaches Query herausfinden, ohne dazu teure Zusatztools bemühen zu müssen:

select ts.name „Tablespace“,
vor_4_wochen.full „FULL%_4_WEEKS_AGO“,
letzte_woche.full „FULL%_LAST_WEEK“,
heute.full „FULL%_TODAY“
from (select tsu.tablespace_id,
round(
tsu.tablespace_usedsize/tsu.tablespace_maxsize*100,0) as
full
from wrh$_tablespace_space_usage tsu
where to_date(substr(tsu.rtime,1,13),’MM/DD/YYYY
HH24′)=to_date(to_char(trunc(sysdate),’MM/DD/YYYY
HH24′),’MM/DD/YYYY HH24′)
) heute,
(select tsu.tablespace_id,
round(
tsu.tablespace_usedsize/tsu.tablespace_maxsize*100,0) as
full
from wrh$_tablespace_space_usage tsu
where to_date(substr(tsu.rtime,1,13),’MM/DD/YYYY
HH24′)=to_date(to_char(trunc(sysdate-7),’MM/DD/YYYY
HH24′),’MM/DD/YYYY HH24′)
) letzte_woche,
(select tsu.tablespace_id,
round(
tsu.tablespace_usedsize/tsu.tablespace_maxsize*100,0) as
full
from wrh$_tablespace_space_usage tsu
where to_date(substr(tsu.rtime,1,13),’MM/DD/YYYY
HH24′)=to_date(to_char(trunc(sysdate-28),’MM/DD/YYYY
HH24′),’MM/DD/YYYY HH24′)
) vor_4_wochen,
v$tablespace ts
where ts.ts# = heute.tablespace_id
and ts.ts# = letzte_woche.tablespace_id
and ts.ts# = vor_4_wochen.tablespace_id
order by 4 desc;

Wichtig ist, dass die Datenhaltungszeit der ADDM-Statistiken > 28 Tage eingestellt ist und dass die Statistiken stündlich (alle 60 Minuten) gesammelt werden. Ansonsten liefert das Script eine leere Menge zurück.

Aus dem Sekretariat kam folgende Anforderung: ändert sich die Spalte einer bestimmten Tabelle auf einen bestimmten Wert, soll eine E-Mail mit Informationen dieser Transaktion versendet werden.

Die Herangehensweise ist klar: ein On-Update-Trigger ruft UTL_MAIL (oder UTL_SMTP vor 10g) auf und versendet die E-Mail. Dieser Lösungsweg ist aber nur dann akzeptabel, wenn sichergestellt ist, dass der Benutzer diese Transaktion nicht mehr rückgängig machen kann, z.B. wenn die Applikation kein Rollback zulässt.

Wenn nämlich ein Rollback erfolgt, hat die Spalte wieder ihren ursprünglichen Wert, der Versand der E-Mail ist allerdings bereits erfolgt und kann nicht mehr rückgängig gemacht werden.

Tom „AskTom“ Kyte beschreibt im Oracle Magazine und in seinem Blog eine Vorgehensweise, die dieses Verhalten verhindert:

Die Idee ist, dass man statt des E-Mail-Versandes einen Eintrag in die Queue von DMBS_JOBS vornimmt, die sich um den Versand der Post kümmert. Der Insert in die Job-Queue ist ja auch eine Transaktion, wird also nur vorgenommen, wenn die ursprüngliche Transaktion (die, die den Trigger auslöst) commited wird. Im Detail funktioniert das so:

SQL> create table do_ddl (job number primary key, stmt varchar2(4000));
Table created.

Diese Tabelle beinhaltet die Jobnummern und die Statements, die im jeweiligen Job ausgeführt werden sollen. In unserem Fall z.B. UTL_MAIL.SEND (…).

Anschließend liegen wir eine Stored Procedure an, die die Jobtabelle ausliest und die dort hinterlegten Statements ausführt:

SQL> create or replace procedure do_ddl_safely (p_job in number) is
2   l_rec do_ddl%rowtype;
3   begin
4     select * into l_rec from do_ddl where job = p_job;
5     execute immediate l_rec.stmt;
6   end;
7   /
Procedure created.

Im Trigger schließlich wird der Job in der Queue angelegt:

SQL> declare
2   l_job number;
3   begin
4     dbms_job.submit (l_job, 'do_ddl_safely (JOB);' );
5     insert into do_ddl (job, stmt) values (l_job, 'begin utl_mail.send (...) end;');
6   end;
7   /

Was passiert also?

1. Der Trigger legt einen Job an und schreibt das Statement mit der Jobnummer in die Tabelle DO_DDL.
2. Da für die ursprüngliche Transaktion noch kein Commit vorliegt, wird weder das DBMS_JOB.SUBMIT noch der Insert in die Tabelle wirklich ausgeführt.
3. Beim Rollback wird die ursprüngliche Transaktion (das Ändern des Spaltenwertes) sowie Schritt 1 rückgängig gemacht
   oder
   beim Commit wird die Änderung in der Spalte festgeschrieben, der Job wird erstellt und die Tabelle DO_DDL befüllt.
4. Der Job wird kurzzeitig nach dem Commit ausgeführt und die E-Mail wird versendet.

Diese Vorgehensweise ist natürlich nicht nur auf den Versand von E-Mails beschränkt, sondern eignet sich hervorragend, um ganz allgemein DDL in Triggern auszuführen.

Denn wie schreibt Mr. Kyte so schön:

Whenever you are tempted to do something nontransactional in a trigger, think 500 times more about it and then always decide againt it. It can lead only to really bad things.