Offensichtliche Fehler
Geschrieben von Kay Liesenfeld - 4. Mai 2012
Oracle hat den Security Alert CVE-2012-1675 veröffentlicht, den man wirklich ernst nehmen sollte, denn hiernach ist ziemlich jede Datenbank so gut geschützt wie das berühmte offene Scheunentor.
Details erfährt man u.a. hier
Interessant ist, dass Oracle statt eines Patches einfach das bislang teuer verkaufte SSL-/TLS-Feature lizenzfrei abgibt.
Gefixt ist das ganze wohl, so hört man, in 12c.
Veröffentlicht in Bugs, Das kann doch wohl nicht wahr sein..., News | Kommentar schreiben »
Geschrieben von Kay Liesenfeld - 4. November 2009
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.
Veröffentlicht in Bugs, Das kann doch wohl nicht wahr sein... | Kommentar schreiben »
Geschrieben von Kay Liesenfeld - 23. Oktober 2009
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.
Veröffentlicht in Bugs, Migration, Tools | Kommentar schreiben »
Geschrieben von Kay Liesenfeld - 16. Juni 2008
“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
Veröffentlicht in Bugs | Getaggt mit: 11g, bug | Kommentar schreiben »
