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.

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.

„Wrong results can occur from subquery unnesting if there is aPL/SQL function in a subquery with no columns as an argument(ie: all constants).

Workaround: Disable subquery unnesting in that subquery.„

Bug 6192202 vom 04.06.2008, Metalink Note 6192202.8