Datenbank auf anderen Server migrieren

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.

Stolperfalle GridControl-Installation

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.

 

User-DDL extrahieren

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.

Oracle Password-Cracker

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.