Sorry ihr 2, ich habe mich wohl nicht genau genug ausgedrückt.
PL/
SQL Tabelle <>
DB Tabelle -> es ist eher so etwas wie eine Collection oder ein Array
Mein Problem ist die Kombi Bulk SELECT und dyn. Cursor.
Würde ich auf das Bulk SELECT verzichten könnte ich es so machen:
SQL-Code:
create or replace procedure TestDynCurNoBulk
(
pOwner in varchar2
,pTable in varchar2
) is
-- constants
Lf char(1) := Chr(10);
-- cursors
type WeakTypedDynCur is ref cursor;
DynCur WeakTypedDynCur;
-- Bulk tables
type ShortChrTab is table of varchar2(20) index by binry_integer;
a ShortChrTab;
b ShortChrTab;
c ShortChrTab;
begin
open DynCur for
'SELECT a' || Lf ||
' ,b' || Lf ||
' ,c' || Lf ||
'FROM ' || pOwner || '.' || pTable;
a(0) := null;
b(0) := null;
c(0) := null;
loop
fetch DynCur
INTO a(a.Last + 1)
,b(b.Last + 1)
,c(c.Last + 1);
EXIT When DynCur%NotFound;
end loop;
close DynCur;
end;
Aber die ständigen Context switches zwischen PL/
SQL und
SQL würden wie eine angezogene Handbremse wirken.
Per Bulk DML bekomme ich mehrere 100.000 Datensätze in t < 70 ms. Wenn ich durch den Cursor iteriere würde es mehr als 1 Sekunde dauern!
Das Problem ist bei den ersten 2 Varianten im ersten Post, dass Oracle im voraus wissen muss, wie der Cursor "aussieht" um das Bulk SELECT vorbereiten zu können. Er schiebt dabei schließlich in einem Schritt die gesamte Abfrage in die 3 Collections.
Ich fürchte ich muss mit der 3. Variante leben, auch wenn dabei ein kompletter Block kompiliert werden muss -> das kostet wieder min. 10ms
