Hallo muzel!
Ich stimme mit BerndW und tomh darin überein, dass das Problem in bestehenden Locks besteht, DEN update sollte jedes System, auf dem sich Oracle überhaupt erst installieren lässt in Nullkommanix schaffen.
Die Tabelle habe ich analysiert,
Gut. Entschuldige, wenn ich nochmal zurückfrage, Du weißt,
wie…? Analyze Table usw…?
DBMS_STATS ist hier übrigens unbedingt vorzuziehen, allerdings weiss ich nicht auswendig, ob das unter 8i schon verfügbar war…
Ganz sicher jedenfalls sieht es nicht danach aus, als könnte der update von Marion irgendetwas anderes als einen FTS machen, insofern sind die Statistiken hier ohnehin egal.
es werden keine Redo-Logs erzeugt
Wenn das wirklich wahr sein sollte, kann kein Update
funktionieren.
Ääähm, das ist schlicht und ergreifend falsch! Ich denke du verwechselst hier Redo (vulgo Logging) mit Undo (vulgo Rollback). Ich habe hier viiieeeele Tabellen, die keinen Redo generieren, die sich trotzdem bestens updaten lassen, und das sogar noch schneller als mit Redo (eh logisch…).
…Jetzt werde ich 'mal versuchen, einen Ausführungsplan zu finden.
Acuh ohne Tools kannst du (Marion) dir den übrigens mittels EXPLAIN PLAN FOR erstellen lassen. Er wird dann in der Tabelle plan_table abgelegt (evtl. muss dein DBA zuvor noch $ORACLE_HOME/rdbms/admin/utlxplan.sql laufen lassen).
Hmm. Hast Du den Enterprise Manager installiert? Da könnte man
mal genauer analysieren, wo die DB krank ist
Das geht auch ohne den EM (ich mag die Klickibunti - Tools alle nicht, aber das ist ohnehin eine andere Diskussion).
ob vielleicht
gerade ein Tablespace überzulaufen droht,
Welcher Tablespace sollte hier überlaufen? Marion setzt einen numerischen Wert auf einen anderen numerischen Wert, d.h. die betreffende Row braucht danach genausoviel Platz wie zuvor. Einzige Möglichkeit: Rollback/Undo. Aber auch das sollte keine Stunden in Anspruch nehmen.
ob genug
TEMP-Tablespace vorhanden ist
Den braucht der Update nicht (er sortiert nicht, macht keine Joins, kurz: nix, wofür er TEMP-Space verwenden müsste).
genug Hauptspreicher reserviert
ist,
Auch das wird kaum einen Einfluss haben.
überhaupt alle Initialisierungsparameter.
Bist du dir sicher? Das sind (unter 9i) ca. 250 (dokumentierte) Stück, wovon schätzungsweise 200 keinen Einfluss auf das genannte Statement haben dürften (zumindest nicht, ohne eine eingehende Analyse des Sessionstatus beim Absetzen des Updates), z.B. alle Java-Parameter.
Auf anderem Wege ist das etwas mühsam.
Der Meinung bin ich nicht, aber wie schon gesagt, ich schreibe mir eben lieber meine eigenen Scripts…
Hast Du die DB schonmal neu gestartet?
Was hast Du vor dem Update gemacht? Schon 99 andere
Updates/Inserts/Deletes, vielleicht ohne commit oder rollback
?
Es dürfte eher die Frage sein, was eine andere Session gemacht hat oder dabei ist zu tun. Die eigene Session sollte eher egal sein (wenn man mal von Rollback-Usage absieht).
Gruß auch,
Martin