Cursor Bulk Collect

Question

Hello All,
I have a doubt regarding Cursor bulk collect. Both the versions are working fine.
1st Version:
DECLARE
  CURSOR c1 IS (SELECT t2 FROM test10);
  TYPE typ_tbl IS TABLE OF c1%rowtype;
  v typ_tbl;
BEGIN
  OPEN c1; 
    FETCH c1 BULK COLLECT INTO v;
  CLOSE c1;
  FOR i IN v.first..v.last
  LOOP
    DBMS_OUTPUT.PUT_LINE(v(i).t2);
  END LOOP; 
END;
2nd version:
DECLARE
  CURSOR c1 IS (SELECT t2 FROM test10);
  TYPE typ_tbl IS TABLE OF c1%rowtype;
  v typ_tbl;
BEGIN
  OPEN c1;
  LOOP                                                 --Loop added
    FETCH c1 BULK COLLECT INTO v;
    EXIT WHEN c1%NOTFOUND;
  END LOOP;
  CLOSE c1;
  FOR i IN v.first..v.last
  LOOP
    DBMS_OUTPUT.PUT_LINE(v(i).t2);
  END LOOP; 
END; Is it necessary to have a loop and exit when cursor notfound statementwhen used with Bulk Collect?
Edited by: SamFisher on Feb 14, 2012 1:26 PM

Answer 1

Echoing Tubby, if you do a BULK COLLECT without a LIMIT (unless you are certain that the result set is going to be trivially small), you're doing something wrong. If you code your own loop using explicit cursors, you should always do something like
OPEN cursor_name;
LOOP
  FETCH cursor_name
   BULK COLLECT INTO collection_name
   LIMIT some_limit;
  EXIT WHEN collection_name.count = 0;
  <<do something with the collection>>
END LOOP;
CLOSE cursor_name;Unless your <<do something>> happens to be doing a FORALL using the collection you just populated, an implicit cursor is going to involve a lot less code (and a lot fewer places where you can potentially create a bug) and isn't going to be noticably slower. The most efficient LIMIT for your bulk collect is generally somewhere between 100 and 1000 so the implicit cursor's limit of 100 is generally pretty close to optimal. You might get marginally more performance by explicitly tuning the LIMIT for your particular process. But once you've eliminated 99% of the time spend on context shifts by letting the implicit cursor fetch in groups of 100, it's relatively unlikely that you're going to see any noticable performance improvements from eliminating the last 1% of context shift time. Since Oracle is going to spend more time managing the collection the larger it gets (particularly depending on how you use the collection), performance starts going down at some point once the LIMIT is too large.
Justin