Antwortzeitverhalten bei cursorn

[Josephine Grace]

Hi,

in unserer Datenbank sind ca 1,9 Millionen Datensätze, die Weiterverarbeitet werden sollen.
Dabei soll ein Teil jedes einzelne Datensatz zuerst in eine Varibale gelesen und dann in einem Loop "gestückelt" werden.

Gibt es eine Alternative zu einem cursor?
Erfahrungsgemäß ist das Antortszeitverhalten für die Menge Datensätze zu schlecht.
Wäre eine PL/SQL Tabelle "schneller"?

Gruß
Jo

[Falk Prüfer]

Hallo Jo,

1,9 Mio Datensätze in "einem Rutsch" bearbeiten zu wollen, halte ich nicht für sehr sinnvoll. Auf alle Fälle sollten dafür die Rollback-Segmente "ausreichend dimensioniert" sein.
Nach meiner Erfahrung ist es aber günstiger mit einem Cursor und einer Loop immer nur "kleine Häppchen" zu bearbeiten und diese dann auch mit einem COMMIT abzuschließen.
<pre>
declare
CURSOR cHappen(pStartBei) is
SELECT ...
FROM ...
WHERE <I>Primary_Key</I> > pStartBei
AND ROWNUM <= 1000
FOR UPDATE; -- wenn die DS schon beim Select gelockt werden sollen
iLastPK <I>Tabelle.Primary_Key</I>%Type DEFAULT 0;
bNochmal Boolean;
begin
loop
bNochmal := False; -- wichtig falls gar kein DS gefunden wird.
for rHappen in cHappen(iLastPK)
loop
/* Deine Umwandlung */
iLastPK := rHappen.<I>Primary_Key</I>;
bNochmal := cHappen%ROWCOUNT = 1000;
end loop;
COMMIT;
exit when NOT bNochmal;
end loop;
end;
</pre>
Das ganze geht davon aus, das es in der zu bearbeitenden Tabelle <I>Tabelle</I> einen numerischen Primärschlüssel <I>Primary_Key</I> gibt. iLastPK wird mit einem Wert initalisiert, der kleiner als der kleinste Primärschlüsselwert der Tabelle ist. Die äußere Loop wird nun sooft durchlaufen und ruft über den Cursor immer die nächsten 1000 DS ab, bis irgendwann in der inneren Loop weniger als 1000 DS bearbeitet wurden, d.h. der letzte "Happen" durchgekaut wurde.

Das schont die Rollbacksegmente und vermeidet auch einen "snapshot to old".

Gruß Fal