Regarding Bulk Collect

Hi,
I have some problem in BULK binding.
See below code, we have three columns in pl/sql record and table based on that record is populated with rows.
Now requirement is like, I want to store two of the columns in table with the help of FORALL statement.
So tried with below code. But it is not working.
How we can achieve this with the help of forall statement.
Please comment...
declare
type p_ref is ref cursor;
ref1 p_ref;
type p_rec is record
(owner varchar2(100),
table_name varchar2(100),
tablespace_name varchar2(100));
type p_tab is table of p_rec;
tab1 p_tab;
begin
open ref1 for 'select 123,table_name,tablespace_name from user_tables where rownum<=10';
fetch ref1 bulk collect into tab1;
close ref1;
forall i in tab1.first..tab1.last
insert into test_tab1(table_name,tablespace_name)
values(tab1(i).table_name,tab1(i).tablespace_name);
end;
ERROR at line 19:
ORA-06550: line 19, column 8:
PLS-00436: implementation restriction: cannot reference fields of BULK In-BIND
table of records
ORA-06550: line 19, column 8:
PLS-00382: expression is of wrong type
ORA-06550: line 19, column 27:
PLS-00436: implementation restriction: cannot reference fields of BULK In-BIND
table of records
ORA-06550: line 19, column 27:
PLS-00382: expression is of wrong type
ORA-06550: line 19, column 8:
PL/SQL: ORA-22806: not an object or REF
ORA-06550: line 18, column 1:
PL/SQL: SQL Statement ignored

See below code, I do want to share one pl/sql for both table(test_tab1,test_tab) insertion.
SQL> desc test_tab1
Name Null? Type
TABLE_NAME NOT NULL VARCHAR2(30)
TABLESPACE_NAME VARCHAR2(30)
SQL> desc test_tab
Name Null? Type
OWNER NOT NULL VARCHAR2(30)
TABLE_NAME NOT NULL VARCHAR2(30)
TABLESPACE_NAME VARCHAR2(30)
declare
type p_ref is ref cursor;
ref1 p_ref;
type p_rec is record
(owner varchar2(100),
table_name varchar2(100),
tablespace_name varchar2(100));
type p_tab is table of p_rec;
tab1 p_tab;
opt number := &opt;
begin
IF opt =1 THEN
open ref1 for 'select 123,table_name,tablespace_name from user_tables where rownum<=10';
ELSE
open ref1 for 'select owner,table_name,tablespace_name from all_tables where rownum<=10';
END IF;
fetch ref1 bulk collect into tab1;
close ref1;
forall i in tab1.first..tab1.last
IF opt=1 THEN
insert into test_tab1(table_name,tablespace_name)
values(tab1(i).table_name,tab1(i).tablespace_name);
ELSE
insert into test_tab values(tab1(i));
END IF;
end;

Similar Messages

I need an help regarding Bulk collect

Can we use bulkcollect with sys_refursor ?
for ex :
create or replace procedure sampelpro ( recs out sys_refcursor) is
begin
execute immediate 'select * from table1' bulk collect into recs ;
end sampelpro;
Note : table1 has 1+ laks record
if the above code is not possible then let me know any possible ways ?

Hi and welcome to the forum
Can we use bulkcollect with sys_refursor ?No, and you shouldn't.
Your signature says that OUT parameter is a cursor. A cursor is not a resultset, but rather a pointer to one.
So your best choice is probably just to use that, and not try to select into a collection.
Note : table1 has 1+ laks recordEven more important then not to return a collection, but a cursor. (Although I don't remember what a lak is)
Example on how to use:
create or replace procedure sampelpro (recs out sys_refcursor)
is
begin
    open recs for 'select empno, ename from emp';
end sampelpro;
Procedure er oprettetAnd a test. Imagine this being a Java client or something the like
SQL> var c refcursor
SQL> exec sampelpro(:c)
PL/SQL-procedure er udf°rt.
SQL> print c
     EMPNO ENAME
      7369 SMITH
      7499 ALLEN
      7521 WARD
      7566 JONES
      7654 MARTIN
      7698 BLAKE
      7782 CLARK
      7788 SCOTT
      7839 KING
      7844 TURNER
      7876 ADAMS
     EMPNO ENAME
      7900 JAMES
      7902 FORD
      7934 MILLER
14 rµkker er valgt.
SQL>Blushadow has a nice post on cursors here:
PL/SQL 101 : Understanding Ref Cursors
Regards
Peter

Regarding Bulk Collect Operations

I would like to know what things need to be considered in order to implement the bulk collect operations. I have tables with >100,000 rows, for which I am planning to use Bulk collect. Am I correct in saying that bulk collect is a memory intensive operation.
Any help would be appreciated.
Thanks

You will want to use the LIMIT clause to only bulk collect up to 1000 rows or so at a time.
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:5918938803188

Any way to use cursor values inside other cursor by bulk collect?

hi,
Is there any way to use cursor get_tables value insdide loop get column if i am using bulk collect in both cursors?
I tried a lot but i am nt able to do it.kindly help...
create or replace procedure MULTIPLE_CURSORS_PROC is
v_owner varchar2(40);
v_table_name varchar2(40);
v_column_name varchar2(100);
cursor get_tables is
select distinct tbl.owner, tbl.table_name
from all_tables tbl
where tbl.owner = 'SYSTEM';
cursor get_columns is
select distinct col.column_name
from all_tab_columns col
where col.owner = v_owner
and col.table_name = v_table_name;
begin
open get_tables;
loop
fetch get_tables into v_owner, v_table_name;
open get_columns;
loop
fetch get_columns into v_column_name;
end loop;
close get_columns;
end loop;
close get_tables;
end ;

hi there
Refer this
CREATE OR REPLACE PROCEDURE MULTIPLE_CURSORS_PROC
IS
   TYPE scol IS VARRAY (10000) OF VARCHAR2 (32767);
   v_table_name    scol;
   v_column_name   scol;
   TYPE curtyp IS REF CURSOR;
   get_columns     curtyp;
   CURSOR get_tables
   IS
      SELECT   DISTINCT tbl.table_name
        FROM   all_tables tbl
       WHERE   tbl.owner = 'SYSTEM';
BEGIN
   OPEN get_tables;
   LOOP
      FETCH get_tables BULK COLLECT INTO   v_table_name;
      FOR indx IN v_table_name.FIRST .. v_table_name.LAST
      LOOP
         SELECT   DISTINCT col.column_name
           BULK   COLLECT
           INTO   v_column_name
           FROM   all_tab_columns col
          WHERE   col.table_name = v_table_name (indx);
         FOR ind IN v_column_name.FIRST .. v_column_name.LAST
         LOOP
            DBMS_OUTPUT.put_line (v_column_name (ind));
         END LOOP;
      END LOOP;
      EXIT WHEN get_tables%NOTFOUND;
   END LOOP;
   CLOSE get_tables;
END MULTIPLE_CURSORS_PROC;regards
Hitesh

Use of FOR Cursor and BULK COLLECT INTO

Dear all,
in which case we prefer to use FOR cursor and cursor with BULK COLLECT INTO? The following contains two block that query identically where one is using FOR cursor, the other is using BULK COLLECT INTO . Which one that performs better given in the existing task? How do we measure performance between these two?
I'm using sample HR schema:
declare
l_start number;
BEGIN
l_start:= DBMS_UTILITY.get_time;
dbms_lock.sleep(1);
FOR employee IN (SELECT e.last_name, j.job_title FROM employees e,jobs j
where e.job_id=j.job_id and e.job_id LIKE '%CLERK%' AND e.manager_id > 120 ORDER BY e.last_name)
LOOP
DBMS_OUTPUT.PUT_LINE ('Name = ' || employee.last_name || ', Job = ' || employee.job_title);
END LOOP;
DBMS_OUTPUT.put_line('total time: ' || to_char(DBMS_UTILITY.get_time - l_start) || ' hsecs');
END;
declare
l_start number;
type rec_type is table of varchar2(20);
name_rec rec_type;
job_rec rec_type;
begin
l_start:= DBMS_UTILITY.get_time;
dbms_lock.sleep(1);
SELECT e.last_name, j.job_title bulk collect into name_rec,job_rec FROM employees e,jobs j
where e.job_id=j.job_id and e.job_id LIKE '%CLERK%' AND e.manager_id > 120 ORDER BY e.last_name;
for j in name_rec.first..name_rec.last loop
DBMS_OUTPUT.PUT_LINE ('Name = ' || name_rec(j) || ', Job = ' || job_rec(j));
END LOOP;
DBMS_OUTPUT.put_line('total time: ' || to_char(DBMS_UTILITY.get_time - l_start) || ' hsecs');
end;
/In this code, I put timestamp in each block, but they are useless since they both run virtually instantaneous...
Best regards,
Val

If you want to get 100% benifit of bulk collect then it must be implemented as below
declare
     Cursor cur_emp
     is
     SELECT     e.last_name, j.job_title
     FROM     employees e,jobs j
     where     e.job_id=j.job_id
               and e.job_id LIKE '%CLERK%'
               AND e.manager_id > 120
     ORDER BY e.last_name;
     l_start number;
     type rec_type is table of varchar2(20);
     name_rec rec_type;
     job_rec rec_type;
begin
     l_start:= DBMS_UTILITY.get_time;
     dbms_lock.sleep(1);
     /*SELECT e.last_name, j.job_title bulk collect into name_rec,job_rec FROM employees e,jobs j
     where e.job_id=j.job_id and e.job_id LIKE '%CLERK%' AND e.manager_id > 120 ORDER BY e.last_name;
     OPEN cur_emp;
     LOOP
          FETCH cur_emp BULK COLLECT INTO name_rec LIMIT 100;
          EXIT WHEN name_rec.COUNT=0;
          FOR j in 1..name_rec.COUNT
          LOOP
               DBMS_OUTPUT.PUT_LINE ('Name = ' || name_rec(j) || ', Job = ' || job_rec(j));
          END LOOP;
          EXIT WHEN cur_emp%NOTFOUND;
     END LOOP;
        CLOSE cur_emp;
     DBMS_OUTPUT.put_line('total time: ' || to_char(DBMS_UTILITY.get_time - l_start) || ' hsecs');
end;
/

Is there a way to BULK COLLECT with FOR UPDATE and not lock ALL the rows?

Currently, we fetch a cursor on a few million rows using BULK COLLECT.
In a FORALL loop, we update the rows.
What is happening now, is that we run this procedure at the same time, and there is another session running a MERGE statement on the same table, and a DEADLOCK is created between them.
I'd like to add to the cursor the FOR UPDATE clause, but from what i've read,
it seems that this will cause ALL the rows in the cursor to become locked.
This is a problem, as the other session is running MERGE statements on the table every few seconds, and I don't want it to fail with ORA-0054 (resource busy).
What I would like to know is if there is a way, that only the rows in the
current bulk will be locked, and all the other rows will be free for updates.
To reproduce this problem:
1. Create test table:
create table TEST_TAB
ID1 VARCHAR2(20),
ID2 VARCHAR2(30),
LAST_MODIFIED DATE
2. Add rows to test table:
insert into TEST_TAB (ID1, ID2, LAST_MODIFIED)
values ('416208000770698', '336015000385349', to_date('15-11-2009 07:14:56', 'dd-mm-yyyy hh24:mi:ss'));
insert into TEST_TAB (ID1, ID2, LAST_MODIFIED)
values ('208104922058401', '336015000385349', to_date('15-11-2009 07:11:15', 'dd-mm-yyyy hh24:mi:ss'));
insert into TEST_TAB (ID1, ID2, LAST_MODIFIED)
values ('208104000385349', '336015000385349', to_date('15-11-2009 07:15:13', 'dd-mm-yyyy hh24:mi:ss'));
3. Create test procedure:
CREATE OR REPLACE PROCEDURE TEST_PROC IS
TYPE id1_typ is table of TEST_TAB.ID1%TYPE;
TYPE id2_typ is table of TEST_TAB.ID2%TYPE;
id1_arr id1_typ;
id2_arr id2_typ;
CURSOR My_Crs IS
SELECT ID1, ID2
FROM TEST_TAB
WHERE ID2 = '336015000385349'
FOR UPDATE;
BEGIN
OPEN My_Crs;
LOOP
FETCH My_Crs bulk collect
INTO id1_arr, id2_arr LIMIT 1;
Forall i in 1 .. id1_arr.COUNT
UPDATE TEST_TAB
SET LAST_MODIFIED = SYSDATE
where ID2 = id2_arr(i)
and ID1 = id1_arr(i);
dbms_lock.sleep(15);
EXIT WHEN My_Crs%NOTFOUND;
END LOOP;
CLOSE My_Crs;
COMMIT;
EXCEPTION
WHEN OTHERS THEN
RAISE_APPLICATION_ERROR(-20000,
'Test Update ' || SQLCODE || ' ' || SQLERRM);
END TEST_PROC;
4. Create another procedure to check if table rows are locked:
create or replace procedure check_record_locked(p_id in TEST_TAB.ID1%type) is
cursor c is
select 'dummy'
from TEST_TAB
WHERE ID2 = '336015000385349'
and ID1 = p_id
for update nowait;
e_resource_busy exception;
pragma exception_init(e_resource_busy, -54);
begin
open c;
close c;
dbms_output.put_line('Record ' || to_char(p_id) || ' is not locked.');
rollback;
exception
when e_resource_busy then
dbms_output.put_line('Record ' || to_char(p_id) || ' is locked.');
end check_record_locked;
5. in one session, run the procedure TEST_PROC.
6. While it's running, in another session, run this block:
begin
check_record_locked('208104922058401');
check_record_locked('416208000770698');
check_record_locked('208104000385349');
end;
7. you will see that all records are identified as locked.
Is there a way that only 1 row will be locked, and the other 2 will be unlocked?
Thanks,
Yoni.

I don't have database access on weekends (look at it as a template)
suppose you
create table help_iot
(bucket number,
id1    varchar2(20),
constraint help_iot_pk primary key (bucket,id1)
organization index;not very sure about the create table syntax above.
declare
maximal_bucket number := 10000; -- will update few hundred rows at a time if you must update few million rows
the_sysdate date := sysdate;
begin
truncate table help_iot;
insert into help_iot
select ntile(maximal_bucket) over (order by id1) bucket,id1
    from test_tab
   where id2 = '336015000385349';
for i in 1 .. maximal_bucket
loop
    select id1,id2,last_modified
      from test_tab
     where id2 = '336015000385349'
       and id1 in (select id1
                     from help_iot
                    where bucket = i
       for update of last_modified;
    update test_tab
       set last_modified = the_sysdate
     where id2 = '336015000385349'
       and id1 in (select id1
                     from help_iot
                    where bucket = i
    commit;
    dbms_lock.sleep(15);
end loop;
end;Regards
Etbin
introduced the_sysdate if last_modified must be the same for all updated rows
Edited by: Etbin on 29.11.2009 16:48

ORA-01722: invalid number error with Bulk collect

Hi ,
I have been using the script to delete old seasonal data from my application DB tables. The stored procedure has been created successfully but when i try to run the proc it has been throwing 'ORA-01722: invalid number' exception at line 'FETCH C1_CUR BULK COLLECT INTO C1_TYPE_VAR LIMIT v_bulklimit;'.
Could you please help me here?
Below is the stored proc:
CREATE OR REPLACE PROCEDURE clean_old_season_data(P_SEASON VARCHAR2) AS
CURSOR C1_CUR IS SELECT ROWID RID,pro.* FROM PROPS pro where pro.ITEMPK IN
(SELECT sve.pk FROM SAVEDVALUEENTRY sve WHERE sve.p_parent IN
(SELECT s.pk FROM SAVEDVALUES s WHERE s.P_MODIFIEDITEM IN
(SELECT a.PK
FROM products a
WHERE a.p_season IN (select s.pk from Seasons s where s.P_code=P_SEASON)
) ) ) and rownum<5;
CURSOR C2_DEL IS SELECT RID FROM PROPS_HISTORY;
TYPE C1_TYPE IS TABLE OF C1_CUR%ROWTYPE;
C1_TYPE_VAR C1_TYPE;
TYPE C2_TYPE IS TABLE OF UROWID;
C2_TYPE_VAR C2_TYPE;
ex_dml_errors EXCEPTION;
PRAGMA EXCEPTION_INIT(ex_dml_errors, -24381);
l_error_count NUMBER;
err_num NUMBER;
err_msg VARCHAR2 (300);
COMMIT_VARIABLE PLS_INTEGER:=0;
v_bulklimit NUMBER:=2;
BEGIN
/*------------------ Data Selection and INSERTION IN HISTORY TABLE ---------------------------------------*/
OPEN C1_CUR;
LOOP
DBMS_OUTPUT.put_line('Cursor opend now in loop');
FETCH C1_CUR BULK COLLECT INTO C1_TYPE_VAR LIMIT v_bulklimit;//ERROR OCCURS HERE
DBMS_OUTPUT.put_line('Cursor count is'|| C1_TYPE_VAR.COUNT);
FORALL I IN 1..C1_TYPE_VAR.COUNT SAVE EXCEPTIONS
INSERT INTO PROPS_HISTORY VALUES C1_TYPE_VAR(I);
COMMIT_VARIABLE := COMMIT_VARIABLE + v_bulklimit;
DBMS_OUTPUT.put_line('Commit variable'|| COMMIT_VARIABLE.COUNT);
IF COMMIT_VARIABLE = v_bulklimit THEN
COMMIT;
COMMIT_VARIABLE := 0;
END IF;
EXIT WHEN C1_CUR%NOTFOUND;
END LOOP;
DBMS_OUTPUT.put_line('Cursor closed now in loop and data inserted in history table');
CLOSE C1_CUR;
/*------------------ Data Selection and DELETION IN Live TABLE ---------------------------------------*/
COMMIT_VARIABLE := 0;
OPEN C2_DEL;
LOOP
FETCH C2_DEL BULK COLLECT INTO C2_TYPE_VAR LIMIT 2;
FORALL I IN 1..C2_TYPE_VAR.COUNT SAVE EXCEPTIONS
DELETE FROM PROPS WHERE ROWID = C2_TYPE_VAR(I);
COMMIT_VARIABLE := COMMIT_VARIABLE + 2;
IF COMMIT_VARIABLE = 2 THEN
COMMIT;
COMMIT_VARIABLE := 0;
END IF;
EXIT WHEN C2_DEL%NOTFOUND;
END LOOP;
CLOSE C2_DEL;
END;

Although there are many things which should not have been done in the posted code, I could not find any reason why the Invalid number error should occur at the Fetch clause.
I would suggest you to Insert into Table by providing the Order of Columns i.e. Insert into table (col1, ... colN) values (coll(i).col1...col(i).colN);
I tested below code and it did not give any errors.
drop table test_table;
create table test_Table
rid   varchar2(100),
emp_id number(5),
fname   varchar2(20),
lname   varchar2(50)
set serveroutput on;
declare
cursor c_cur is
      select rowid rid, e.*
        from employees e
       where rownum < 10;
type typ_cur is table of c_cur%rowtype;
typ typ_cur;
l_bulk_limit    number := 5;
begin
open c_cur;
loop
    fetch c_cur bulk collect into typ limit l_bulk_limit;
    dbms_output.put_line('Collection Count :: ' || typ.count);
    forall i in 1..typ.count --typ.first..typ.last
      insert into test_Table (rid, emp_id, fname, lname) values (typ(i).rid,typ(i).employee_id,typ(i).first_name,typ(i).last_name);
    dbms_output.put_line('Processed ' || l_bulk_limit || ' records.');
    exit when c_cur%notfound;
end loop;
commit;
end;
select * from test_table;PS:- 1. When you are processing only 4 Records, then why are you breaking them in 2 Loops?
2. Why Commit every time you are processing a DML? Why not maintain an Error Flag and Rollback the Transaction as soon as error is encountered?
3. Use "{code}" (Exclude Double Quotes) to format the code. I am not sure if works.
Regards,
P.

Procedure failed while using bulk collect into clause and works with cursor

hi all,
I am using "BULK collect into" clause in my procedure and it is failing after 21 minutes and gives the error "end of file communication channel".
after this error comes when i tried to connect database it is giving following error.
ORA -01034 - Oracle not available.
ORA- 27101 - shared memory realm does not exist.
svr4- error :2 : No such file or directory.
when i use cursor instead of BULK COLLECT INTO clause it is running successful.
Following code is working with cursor.
procedure work_kiosk_full(an_jobid in number ,ac_sqlcode out varchar2 ,ac_sqlerrm out varchar2) is
ld_curr_time Date;
cursor cur_work_kiosk is
select distinct jt.jt_id AS jt_id,
NVL ((ROUND ((jt_date_completed - jt_date_requested) * 24, 2)
0
) AS actual_hrs_to_complete,
NVL ((ROUND ((jt_date_responded - jt_date_requested) * 24, 2)
0
) AS actual_hrs_to_respond,
peo1.peo_name AS agent_name,
peo1.peo_user_name AS asagent_soe_id,
le.lglent_desc AS ap_system,
' ' AS assign_work_request_comment,
DECODE (jt.jt_bill_id,
138802, 'CLIENT BILLABLE',
138803, 'CONTRACTED',
138804, 'INTERNAL BILLABLE',
NULL, ' '
) AS billable,
bl.bldg_name_cc AS building, bl.bldg_id_ls AS building_id,
DECODE (bl.bldg_active_cc,
'Y', 'ACTIVE',
'INACTIVE'
) AS building_status,
DECODE (jt.jt_wrk_cause_id,
141521, 'STANDARD WEAR AND TEAR',
141522, 'NEGLIGENCE',
141523, 'ACCIDENTAL',
141524, 'MECHANICAL MALFUNCTION',
141525, 'OVERSIGHT',
141526, 'VANDAL',
141527, 'STANDARD',
141528, 'PROJECT WORK',
6058229, 'TEST',
NULL, ' '
) AS cause_type,
' ' AS comments, peo3.peo_name AS completed_by,
jt.jt_requestor_email AS contact_email,
jt.jt_requestor_name_first
|| ' '
|| jt.jt_requestor_name_last AS contact_name,
jt.jt_requestor_phone AS contact_phone,
cc.cstctrcd_apcode AS corp_code,
cc.cstctrcd_code AS cost_center,
jt.jt_date_closed AS date_closed,
jt.jt_date_completed AS date_completed,
jt.jt_date_requested AS date_requested,
jt.jt_date_responded AS date_responded,
jt.jt_date_response_ecd AS date_response_ecd,
jt.jt_date_scheduled AS date_scheduled,
DECODE (jt.jt_def_id,
139949, 'WTG VENDOR RESPONSE',
139950, 'WAITING ON PARTS',
139951, 'LABOR AVAILABILITY',
139952, 'DEFERRED- HI PRI WORK',
139953, 'WTG APPROVAL',
139954, 'FUNDING REQUIRED',
139955, 'ACCESS DENIED',
139956, 'WTG MATERIAL',
NULL, ' '
) AS deferral_reason,
jt.jt_description AS description,
jt.jt_date_resched_ecd AS ecd,
fmg.facility_manager AS facility_manager,
fl.floors_text AS FLOOR, gl.genled_desc AS general_ledger,
' ' AS kiosk_date_requested, ' ' AS kiosk_dispatch_confirmed,
' ' AS kiosk_dispatched,
eqp.equip_customer_code AS linked_equipment_alias,
eqp.equip_id AS linked_equipment_id,
eqp.equip_text AS linked_equipment_name,
DECODE (jt_originator_type_id,
1000, 'PROJECT MOVE REQUEST',
138834, 'CUSTOMER INITIATED CORRECTION',
138835, 'CUSTOMER INITIATED REQUEST',
138836, 'CORRECTIVE MAINTENANCE',
138837, 'CONFERENCE ROOM BOOKING',
138838, 'PROJECT INITIATED REQUEST',
138839, 'PLANNED PREVENTIVE MAINTENANCE',
138840, 'SELF INITATED REQUEST',
NULL, ' '
) AS originator_type,
' ' AS payment_terms, priority_text AS priority_code,
swoty.sworktype_text AS problem_type,
prop.property_name_cc AS property,
jt.jt_cost_quote_total AS quote_total,
par.levels_name AS region,
DECODE (jt.jt_repdef_id,
141534, 'ADJUSTED SETTING',
141535, 'TRAINING FOR END',
141536, 'NEW REQUEST',
141537, 'NO REPAIR REQUIR',
141538, 'REPLACED PARTS',
141539, 'REPLACE EQUIPMEN',
1000699, 'NEW REQUEST',
NULL, ' '
) AS repair_definitions,
jt.jt_repairdesc AS repair_description,
jt.jt_requestor AS requestor, ' ' AS requestor_cost_center,
jt.jt_requestor_email AS requestor_email,
jt.jt_requestor_name_first AS requestor_name,
jt.jt_requestor_phone AS requestor_phone,
' ' AS response_time, rm.room_name_cc AS room,
p1.peo_provider_code1 AS service_provider,
p1.peo_address_1 AS service_provider_address,
peocity.city_text service_provider_city,
p1.peo_provider_code1 AS service_provider_code,
peocity.city_country_name AS service_provider_country,
peocur.currency_text AS service_provider_currency,
p1.peo_name AS service_provider_description,
p1.peo_dispatch_method AS serv_prov_dispatc_hmethod,
p1.peo_rate_double AS serv_prov_double_time_rate,
p1.peo_email AS service_provider_email,
p1.peo_emergency_phone AS serv_prov_emergency_phone,
p1.peo_fax AS service_provider_fax_number,
p1.peo_home_phone AS service_provider_home_phone,
p1.peo_rate_hourly AS service_provider_hourly_rate,
p1.peo_title AS service_provider_job_title,
p1.peo_method_id AS service_provider_method,
p1.peo_cell_phone AS service_provider_mobile_phone,
p1.peo_pager AS service_provider_pager,
p1.peo_rate_differential AS service_provider_rates,
p1.peo_rate_differential AS ser_prov_shift_differential,
peocity.city_state_prov_text AS serv_prov_state_province,
DECODE (p1.peo_active,
'Y', 'ACTIVE',
'INACTIVE'
) AS service_provider_status,
p1.peo_url AS serv_prov_web_site_address,
p1.peo_phone AS service_provider_work_phone,
p1.peo_postal_code AS serv_prov_zip_postal_code, ' ' AS shift,
' ' AS skill,
DECODE (jt.jt_bigstatus_id,
138813, 'NEW',
138814, 'PENDING',
138815, 'OPEN',
138816, 'COMPLETED',
138817, 'CLOSED',
138818, 'CANCELLED',
NULL, ' '
) AS status,
lev.levels_name AS subregion, ' ' AS trade,
p1.peo_ls_interface_code1 AS vendor_id,
p1.peo_fax AS vendor_purchasing_fax,
p1.peo_vendor_site_code AS vendor_sitecode,
jt.jt_id AS vendor_ticket, p1.peo_name AS vendor_companyname,
jt.jt_requestor_vip AS vip, wo.wo_id AS work_order_no,
jt.jt_id AS work_request,
jt.jt_class_id AS work_request_class,
woty.worktype_text AS work_type, ' ' AS wr_cost,
jt.jt_description AS wr_description,
' ' AS wr_dispatch_method,
DECODE (jt.jt_bigstatus_id,
138813, 'NEW',
138814, 'PENDING',
138815, 'OPEN',
138816, 'COMPLETED',
138817, 'CLOSED',
138818, 'CANCELLED',
NULL, ' '
) AS wr_status,
ctry.country_name AS country
FROM citi.jobticket jt,
citi.property prop,
citi.bldg bl,
citi.bldg_levels bldglvl,
citi.LEVELS lev,
citi.LEVELS par,
(SELECT crstools.stragg (peo_name) facility_manager,
bldgcon_bldg_id
FROM citi.bldg_contacts, citi.people
WHERE bldgcon_peo_id = peo_id
AND bldgcon_contype_id IN (40181, 10142)
GROUP BY bldgcon_bldg_id) fmg,
citi.floors fl,
citi.room rm,
citi.general_ledger gl,
citi.legal_entity le,
citi.cost_center_codes cc,
citi.equipment eqp,
citi.worktype woty,
citi.subworktype swoty,
citi.work_order wo,
citi.jt_workers jtwo,
citi.priority,
citi.country ctry,
citi.people p1,
citi.people peo3,
citi.people peo1,
citi.city peocity,
citi.currency peocur
WHERE jt.jt_bldg_id = bl.bldg_id
AND bl.bldg_id = bldglvl.bldg_levels_bldg_id
AND bldglvl.bldg_levels_levels_id = lev.levels_id
AND lev.levels_parent = par.levels_id(+)
AND prop.property_id = bl.bldg_property_id
AND bl.bldg_active_ls <> 'N'
AND jt.jt_floors_id = fl.floors_id(+)
AND jt.jt_room_id = rm.room_id(+)
AND jt.jt_bldg_id = fmg.bldgcon_bldg_id(+)
AND jt.jt_genled_id = gl.genled_id(+)
AND gl.genled_lglent_id = le.lglent_id(+)
AND jt.jt_cstctrcd_id = cc.cstctrcd_id(+)
AND jt.jt_equip_id = eqp.equip_id(+)
AND jt.jt_id = jtwo.jtw_jt_id(+)
AND jt.jt_worktype_id = woty.worktype_id(+)
AND jt.jt_sworktype_id = swoty.sworktype_id(+)
AND jt.jt_wo_id = wo.wo_id
AND jt.jt_priority_id = priority_id(+)
--AND jt.jt_date_requested >= ADD_MONTHS (SYSDATE, -12)
AND jt.jt_last_update >= ADD_MONTHS (ld_curr_time, -12)
AND bl.bldg_country_id = ctry.country_id
AND jtwo.jtw_peo_id = p1.peo_id(+)
AND p1.peo_city_id = peocity.city_id(+)
AND jt.jt_completed_by_peo_id = peo3.peo_id(+)
AND p1.peo_rate_currency_id = peocur.currency_id(+)
AND jt.jt_agent_peo_id = peo1.peo_id(+);
BEGIN
execute immediate 'truncate table crstools.drt_bom_work_kiosk';
select sysdate into ld_curr_time from dual;
FOR cur_rec in cur_work_kiosk LOOP
IF MOD(cur_work_kiosk%rowcount,10000 ) = 0 then
COMMIT;
END IF;
INSERT INTO crstools.drt_bom_work_kiosk
( JT_ID
,ACTUAL_HRS_TO_COMPLETE
,ACTUAL_HRS_TO_RESPOND
,AGENT_NAME
,ASAGENT_SOE_ID
,AP_SYSTEM
,ASSIGN_WORK_REQUEST_COMMENT
,BILLABLE
,BUILDING
,BUILDING_ID
,BUILDING_STATUS
,CAUSE_TYPE
,COMMENTS
,COMPLETED_BY
,CONTACT_EMAIL
,CONTACT_NAME
,CONTACT_PHONE
,CORP_CODE
,COST_CENTER
,DATE_CLOSED
,DATE_COMPLETED
,DATE_REQUESTED
,DATE_RESPONDED
,DATE_RESPONSE_ECD
,DATE_SCHEDULED
,DEFERRAL_REASON
,DESCRIPTION
,ECD
,FACILITY_MANAGER
,FLOOR
,GENERAL_LEDGER
,KIOSK_DATE_REQUESTED
,KIOSK_DISPATCH_CONFIRMED
,KIOSK_DISPATCHED
,LINKED_EQUIPMENT_ALIAS
,LINKED_EQUIPMENT_ID
,LINKED_EQUIPMENT_NAME
,ORIGINATOR_TYPE
,PAYMENT_TERMS
,PRIORITY_CODE
,PROBLEM_TYPE
,PROPERTY
,QUOTE_TOTAL
,REGION
,REPAIR_DEFINITIONS
,REPAIR_DESCRIPTION
,REQUESTOR
,REQUESTOR_COST_CENTER
,REQUESTOR_EMAIL
,REQUESTOR_NAME
,REQUESTOR_PHONE
,RESPONSE_TIME
,ROOM
,SERVICE_PROVIDER
,SERVICE_PROVIDER_ADDRESS
,SERVICE_PROVIDER_CITY
,SERVICE_PROVIDER_CODE
,SERVICE_PROVIDER_COUNTRY
,SERVICE_PROVIDER_CURRENCY
,SERVICE_PROVIDER_DESCRIPTION
,SERV_PROV_DISPATC_HMETHOD
,SERV_PROV_DOUBLE_TIME_RATE
,SERVICE_PROVIDER_EMAIL
,SERV_PROV_EMERGENCY_PHONE
,SERVICE_PROVIDER_FAX_NUMBER
,SERVICE_PROVIDER_HOME_PHONE
,SERVICE_PROVIDER_HOURLY_RATE
,SERVICE_PROVIDER_JOB_TITLE
,SERVICE_PROVIDER_METHOD
,SERVICE_PROVIDER_MOBILE_PHONE
,SERVICE_PROVIDER_PAGER
,SERVICE_PROVIDER_RATES
,SER_PROV_SHIFT_DIFFERENTIAL
,SERV_PROV_STATE_PROVINCE
,SERVICE_PROVIDER_STATUS
,SERV_PROV_WEB_SITE_ADDRESS
,SERVICE_PROVIDER_WORK_PHONE
,SERV_PROV_ZIP_POSTAL_CODE
,SHIFT
,SKILL
,STATUS
,SUBREGION
,TRADE
,VENDOR_ID
,VENDOR_PURCHASING_FAX
,VENDOR_SITECODE
,VENDOR_TICKET
,VENDOR_COMPANYNAME
,VIP
,WORK_ORDER_NO
,WORK_REQUEST
,WORK_REQUEST_CLASS
,WORK_TYPE
,WR_COST
,WR_DESCRIPTION
,WR_DISPATCH_METHOD
,WR_STATUS
,COUNTRY
,CREATE_DATE
VALUES
(cur_rec.jt_id
,cur_rec.ACTUAL_HRS_TO_COMPLETE
,cur_rec.ACTUAL_HRS_TO_RESPOND
,cur_rec.AGENT_NAME
,cur_rec.ASAGENT_SOE_ID
,cur_rec.AP_SYSTEM
,cur_rec.ASSIGN_WORK_REQUEST_COMMENT
,cur_rec.BILLABLE
,cur_rec.BUILDING
,cur_rec.BUILDING_ID
,cur_rec.BUILDING_STATUS
,cur_rec.CAUSE_TYPE
,cur_rec.COMMENTS
,cur_rec.COMPLETED_BY
,cur_rec.CONTACT_EMAIL
,cur_rec.CONTACT_NAME
,cur_rec.CONTACT_PHONE
,cur_rec.CORP_CODE
,cur_rec.COST_CENTER
,cur_rec.DATE_CLOSED
,cur_rec.DATE_COMPLETED
,cur_rec.DATE_REQUESTED
,cur_rec.DATE_RESPONDED
,cur_rec.DATE_RESPONSE_ECD
,cur_rec.DATE_SCHEDULED
,cur_rec.DEFERRAL_REASON
,cur_rec.DESCRIPTION
,cur_rec.ECD
,cur_rec.FACILITY_MANAGER
,cur_rec.FLOOR
,cur_rec.GENERAL_LEDGER
,cur_rec.KIOSK_DATE_REQUESTED
,cur_rec.KIOSK_DISPATCH_CONFIRMED
,cur_rec.KIOSK_DISPATCHED
,cur_rec.LINKED_EQUIPMENT_ALIAS
,cur_rec.LINKED_EQUIPMENT_ID
,cur_rec.LINKED_EQUIPMENT_NAME
,cur_rec.ORIGINATOR_TYPE
,cur_rec.PAYMENT_TERMS
,cur_rec.PRIORITY_CODE
,cur_rec.PROBLEM_TYPE
,cur_rec.PROPERTY
,cur_rec.QUOTE_TOTAL
,cur_rec.REGION
,cur_rec.REPAIR_DEFINITIONS
,cur_rec.REPAIR_DESCRIPTION
,cur_rec.REQUESTOR
,cur_rec.REQUESTOR_COST_CENTER
,cur_rec.REQUESTOR_EMAIL
,cur_rec.REQUESTOR_NAME
,cur_rec.REQUESTOR_PHONE
,cur_rec.RESPONSE_TIME
,cur_rec.ROOM
,cur_rec.SERVICE_PROVIDER
,cur_rec.SERVICE_PROVIDER_ADDRESS
,cur_rec.SERVICE_PROVIDER_CITY
,cur_rec.SERVICE_PROVIDER_CODE
,cur_rec.SERVICE_PROVIDER_COUNTRY
,cur_rec.SERVICE_PROVIDER_CURRENCY
,cur_rec.SERVICE_PROVIDER_DESCRIPTION
,cur_rec.SERV_PROV_DISPATC_HMETHOD
,cur_rec.SERV_PROV_DOUBLE_TIME_RATE
,cur_rec.SERVICE_PROVIDER_EMAIL
,cur_rec.SERV_PROV_EMERGENCY_PHONE
,cur_rec.SERVICE_PROVIDER_FAX_NUMBER
,cur_rec.SERVICE_PROVIDER_HOME_PHONE
,cur_rec.SERVICE_PROVIDER_HOURLY_RATE
,cur_rec.SERVICE_PROVIDER_JOB_TITLE
,cur_rec.SERVICE_PROVIDER_METHOD
,cur_rec.SERVICE_PROVIDER_MOBILE_PHONE
,cur_rec.SERVICE_PROVIDER_PAGER
,cur_rec.SERVICE_PROVIDER_RATES
,cur_rec.SER_PROV_SHIFT_DIFFERENTIAL
,cur_rec.SERV_PROV_STATE_PROVINCE
,cur_rec.SERVICE_PROVIDER_STATUS
,cur_rec.SERV_PROV_WEB_SITE_ADDRESS
,cur_rec.SERVICE_PROVIDER_WORK_PHONE
,cur_rec.SERV_PROV_ZIP_POSTAL_CODE
,cur_rec.SHIFT
,cur_rec.SKILL
,cur_rec.STATUS
,cur_rec.SUBREGION
,cur_rec.TRADE
,cur_rec.VENDOR_ID
,cur_rec.VENDOR_PURCHASING_FAX
,cur_rec.VENDOR_SITECODE
,cur_rec.VENDOR_TICKET
,cur_rec.VENDOR_COMPANYNAME
,cur_rec.VIP
,cur_rec.WORK_ORDER_NO
,cur_rec.WORK_REQUEST
,cur_rec.WORK_REQUEST_CLASS
,cur_rec.WORK_TYPE
,cur_rec.WR_COST
,cur_rec.WR_DESCRIPTION
,cur_rec.WR_DISPATCH_METHOD
,cur_rec.WR_STATUS
,cur_rec.COUNTRY
,ld_curr_time
END LOOP;
COMMIT;
exception
when others then
rollback;
dbms_output.put_line('SQLCODE :'||sqlcode ||' Error :'||sqlerrm);
end work_kiosk_full;
Note : total record inserted 849000.
The same code does not work with bulk collect into caluse.
Please help me out why this is happening.
Thanks & regards
shyam~

Shyam,
I agree with Billy.
Why are you not using an INSERT..SELECT ?
Also, what are you trying to achieve by
- incremental commits?
- copying data from one table to another (using expensive I/O)?
- using dynamic DML?
Most of these approaches are typically wrong - and not recommended for scalable and performant Oracle applications.I could see you using a CURSOR FOR LOOP if you were changing the data being inserted in such a way that you couldn't encapsulate the changes in a query, but you are doing a straight insert into the table from your Cursor. A much more efficient way would be to use the following modifications I made to your code example:
PROCEDURE WORK_KIOSK_FULL(AN_JOBID   IN NUMBER,
                          AC_SQLCODE OUT VARCHAR2,
                          AC_SQLERRM OUT VARCHAR2) IS
BEGIN
   EXECUTE IMMEDIATE 'truncate table crstools.drt_bom_work_kiosk';
   /* Note: The APPEND hint forces a Direct Path INSERT (see Link below code sample) and is combined with the NOLOGGING Hint */
   /*        To dramtically increase performance. The Direct Path INSERT inserts records above the High-Water Mark on the table. */
   INSERT /*+ APPEND NOLOGGING */ INTO CRSTOOLS.DRT_BOM_WORK_KIOSK
      (JT_ID
      ,ACTUAL_HRS_TO_COMPLETE
      ,ACTUAL_HRS_TO_RESPOND
      ,AGENT_NAME
      ,ASAGENT_SOE_ID
      ,AP_SYSTEM
--      ,ASSIGN_WORK_REQUEST_COMMENT     /* I commented out this COLUMN because it doesn't make sense to me to insert */
      ,BILLABLE                          /* a couple of space characters into a table.   If the intent is to leave the column NULL */
      ,BUILDING                          /* don't include it in your INSERT statement and it will be NULL. If there is a valid reason */
      ,BUILDING_ID                       /* for inserting the spaces, then remove the "line comments" from the insert and select statments */
      ,BUILDING_STATUS
      ,CAUSE_TYPE
--      ,COMMENTS
      ,COMPLETED_BY
      ,CONTACT_EMAIL
      ,CONTACT_NAME
      ,CONTACT_PHONE
      ,CORP_CODE
      ,COST_CENTER
      ,DATE_CLOSED
      ,DATE_COMPLETED
      ,DATE_REQUESTED
      ,DATE_RESPONDED
      ,DATE_RESPONSE_ECD
      ,DATE_SCHEDULED
      ,DEFERRAL_REASON
      ,DESCRIPTION
      ,ECD
      ,FACILITY_MANAGER
      ,FLOOR
      ,GENERAL_LEDGER
--      ,KIOSK_DATE_REQUESTED
--      ,KIOSK_DISPATCH_CONFIRMED
--      ,KIOSK_DISPATCHED
      ,LINKED_EQUIPMENT_ALIAS
      ,LINKED_EQUIPMENT_ID
      ,LINKED_EQUIPMENT_NAME
      ,ORIGINATOR_TYPE
--      ,PAYMENT_TERMS
      ,PRIORITY_CODE
      ,PROBLEM_TYPE
      ,PROPERTY
      ,QUOTE_TOTAL
      ,REGION
      ,REPAIR_DEFINITIONS
      ,REPAIR_DESCRIPTION
      ,REQUESTOR
--      ,REQUESTOR_COST_CENTER
      ,REQUESTOR_EMAIL
      ,REQUESTOR_NAME
      ,REQUESTOR_PHONE
--      ,RESPONSE_TIME
      ,ROOM
      ,SERVICE_PROVIDER
      ,SERVICE_PROVIDER_ADDRESS
      ,SERVICE_PROVIDER_CITY
      ,SERVICE_PROVIDER_CODE
      ,SERVICE_PROVIDER_COUNTRY
      ,SERVICE_PROVIDER_CURRENCY
      ,SERVICE_PROVIDER_DESCRIPTION
      ,SERV_PROV_DISPATC_HMETHOD
      ,SERV_PROV_DOUBLE_TIME_RATE
      ,SERVICE_PROVIDER_EMAIL
      ,SERV_PROV_EMERGENCY_PHONE
      ,SERVICE_PROVIDER_FAX_NUMBER
      ,SERVICE_PROVIDER_HOME_PHONE
      ,SERVICE_PROVIDER_HOURLY_RATE
      ,SERVICE_PROVIDER_JOB_TITLE
      ,SERVICE_PROVIDER_METHOD
      ,SERVICE_PROVIDER_MOBILE_PHONE
      ,SERVICE_PROVIDER_PAGER
      ,SERVICE_PROVIDER_RATES
      ,SER_PROV_SHIFT_DIFFERENTIAL
      ,SERV_PROV_STATE_PROVINCE
      ,SERVICE_PROVIDER_STATUS
      ,SERV_PROV_WEB_SITE_ADDRESS
      ,SERVICE_PROVIDER_WORK_PHONE
      ,SERV_PROV_ZIP_POSTAL_CODE
--      ,SHIFT
--      ,SKILL
      ,STATUS
      ,SUBREGION
--      ,TRADE
      ,VENDOR_ID
      ,VENDOR_PURCHASING_FAX
      ,VENDOR_SITECODE
      ,VENDOR_TICKET
      ,VENDOR_COMPANYNAME
      ,VIP
      ,WORK_ORDER_NO
      ,WORK_REQUEST
      ,WORK_REQUEST_CLASS
      ,WORK_TYPE
--      ,WR_COST
      ,WR_DESCRIPTION
--      ,WR_DISPATCH_METHOD
      ,WR_STATUS
      ,COUNTRY
      ,CREATE_DATE
   VALUES
      (SELECT DISTINCT
          JT.JT_ID AS JT_ID
         ,NVL((ROUND((JT_DATE_COMPLETED - JT_DATE_REQUESTED) * 24,2)),0) AS ACTUAL_HRS_TO_COMPLETE
         ,NVL((ROUND((JT_DATE_RESPONDED - JT_DATE_REQUESTED) * 24,2)),0) AS ACTUAL_HRS_TO_RESPOND
         ,PEO1.PEO_NAME AS AGENT_NAME
         ,PEO1.PEO_USER_NAME AS ASAGENT_SOE_ID
         ,LE.LGLENT_DESC AS AP_SYSTEM
--         ,' ' AS ASSIGN_WORK_REQUEST_COMMENT
         ,DECODE(JT.JT_BILL_ID,138802,'CLIENT BILLABLE'
                              ,138803,'CONTRACTED'
                              ,138804,'INTERNAL BILLABLE',NULL,' ') AS BILLABLE
         ,BL.BLDG_NAME_CC AS BUILDING
         ,BL.BLDG_ID_LS AS BUILDING_ID
         ,DECODE(BL.BLDG_ACTIVE_CC, 'Y', 'ACTIVE', 'INACTIVE') AS BUILDING_STATUS
         ,DECODE(JT.JT_WRK_CAUSE_ID,141521,'STANDARD WEAR AND TEAR'
                                   ,141522,'NEGLIGENCE'
                                   ,141523,'ACCIDENTAL'
                                   ,141524,'MECHANICAL MALFUNCTION'
                                   ,141525,'OVERSIGHT'
                                   ,141526,'VANDAL'
                                   ,141527,'STANDARD'
                                   ,141528,'PROJECT WORK'
                                   ,6058229,'TEST',NULL,' ') AS CAUSE_TYPE
--         ,' ' AS COMMENTS
         ,PEO3.PEO_NAME AS COMPLETED_BY
         ,JT.JT_REQUESTOR_EMAIL AS CONTACT_EMAIL
         ,JT.JT_REQUESTOR_NAME_FIRST || ' ' ||JT.JT_REQUESTOR_NAME_LAST AS CONTACT_NAME
         ,JT.JT_REQUESTOR_PHONE AS CONTACT_PHONE
         ,CC.CSTCTRCD_APCODE AS CORP_CODE
         ,CC.CSTCTRCD_CODE AS COST_CENTER
         ,JT.JT_DATE_CLOSED AS DATE_CLOSED
         ,JT.JT_DATE_COMPLETED AS DATE_COMPLETED
         ,JT.JT_DATE_REQUESTED AS DATE_REQUESTED
         ,JT.JT_DATE_RESPONDED AS DATE_RESPONDED
         ,JT.JT_DATE_RESPONSE_ECD AS DATE_RESPONSE_ECD
         ,JT.JT_DATE_SCHEDULED AS DATE_SCHEDULED
         ,DECODE(JT.JT_DEF_ID,139949,'WTG VENDOR RESPONSE'
                             ,139950,'WAITING ON PARTS'
                             ,139951,'LABOR AVAILABILITY'
                             ,139952,'DEFERRED- HI PRI WORK'
                             ,139953,'WTG APPROVAL'
                             ,139954,'FUNDING REQUIRED'
                             ,139955,'ACCESS DENIED'
                             ,139956,'WTG MATERIAL',NULL,' ') AS DEFERRAL_REASON
         ,JT.JT_DESCRIPTION AS DESCRIPTION
         ,JT.JT_DATE_RESCHED_ECD AS ECD
         ,FMG.FACILITY_MANAGER AS FACILITY_MANAGER
         ,FL.FLOORS_TEXT AS FLOOR
         ,GL.GENLED_DESC AS GENERAL_LEDGER
--         ,' ' AS KIOSK_DATE_REQUESTED
--         ,' ' AS KIOSK_DISPATCH_CONFIRMED
--         ,' ' AS KIOSK_DISPATCHED
         ,EQP.EQUIP_CUSTOMER_CODE AS LINKED_EQUIPMENT_ALIAS
         ,EQP.EQUIP_ID AS LINKED_EQUIPMENT_ID
         ,EQP.EQUIP_TEXT AS LINKED_EQUIPMENT_NAME
         ,DECODE(JT_ORIGINATOR_TYPE_ID,1000,'PROJECT MOVE REQUEST'
                                      ,138834,'CUSTOMER INITIATED CORRECTION'
                                      ,138835,'CUSTOMER INITIATED REQUEST'
                                      ,138836,'CORRECTIVE MAINTENANCE'
                                      ,138837,'CONFERENCE ROOM BOOKING'
                                      ,138838,'PROJECT INITIATED REQUEST'
                                      ,138839,'PLANNED PREVENTIVE MAINTENANCE'
                                      ,138840,'SELF INITATED REQUEST',NULL,' ') AS ORIGINATOR_TYPE
--         ,' ' AS PAYMENT_TERMS
         ,PRIORITY_TEXT AS PRIORITY_CODE
         ,SWOTY.SWORKTYPE_TEXT AS PROBLEM_TYPE
         ,PROP.PROPERTY_NAME_CC AS PROPERTY
         ,JT.JT_COST_QUOTE_TOTAL AS QUOTE_TOTAL
         ,PAR.LEVELS_NAME AS REGION
         ,DECODE(JT.JT_REPDEF_ID,141534,'ADJUSTED SETTING'
                                ,141535,'TRAINING FOR END'
                                ,141536,'NEW REQUEST'
                                ,141537,'NO REPAIR REQUIR'
                                ,141538,'REPLACED PARTS'
                                ,141539,'REPLACE EQUIPMEN'
                                ,1000699,'NEW REQUEST',NULL,' ') AS REPAIR_DEFINITIONS
         ,JT.JT_REPAIRDESC AS REPAIR_DESCRIPTION
         ,JT.JT_REQUESTOR AS REQUESTOR
--         ,' ' AS REQUESTOR_COST_CENTER
         ,JT.JT_REQUESTOR_EMAIL AS REQUESTOR_EMAIL
         ,JT.JT_REQUESTOR_NAME_FIRST AS REQUESTOR_NAME
         ,JT.JT_REQUESTOR_PHONE AS REQUESTOR_PHONE
--         ,' ' AS RESPONSE_TIME
         ,RM.ROOM_NAME_CC AS ROOM
         ,P1.PEO_PROVIDER_CODE1 AS SERVICE_PROVIDER
         ,P1.PEO_ADDRESS_1 AS SERVICE_PROVIDER_ADDRESS
         ,PEOCITY.CITY_TEXT SERVICE_PROVIDER_CITY
         ,P1.PEO_PROVIDER_CODE1 AS SERVICE_PROVIDER_CODE
         ,PEOCITY.CITY_COUNTRY_NAME AS SERVICE_PROVIDER_COUNTRY
         ,PEOCUR.CURRENCY_TEXT AS SERVICE_PROVIDER_CURRENCY
         ,P1.PEO_NAME AS SERVICE_PROVIDER_DESCRIPTION
         ,P1.PEO_DISPATCH_METHOD AS SERV_PROV_DISPATC_HMETHOD
         ,P1.PEO_RATE_DOUBLE AS SERV_PROV_DOUBLE_TIME_RATE
         ,P1.PEO_EMAIL AS SERVICE_PROVIDER_EMAIL
         ,P1.PEO_EMERGENCY_PHONE AS SERV_PROV_EMERGENCY_PHONE
         ,P1.PEO_FAX AS SERVICE_PROVIDER_FAX_NUMBER
         ,P1.PEO_HOME_PHONE AS SERVICE_PROVIDER_HOME_PHONE
         ,P1.PEO_RATE_HOURLY AS SERVICE_PROVIDER_HOURLY_RATE
         ,P1.PEO_TITLE AS SERVICE_PROVIDER_JOB_TITLE
         ,P1.PEO_METHOD_ID AS SERVICE_PROVIDER_METHOD
         ,P1.PEO_CELL_PHONE AS SERVICE_PROVIDER_MOBILE_PHONE
         ,P1.PEO_PAGER AS SERVICE_PROVIDER_PAGER
         ,P1.PEO_RATE_DIFFERENTIAL AS SERVICE_PROVIDER_RATES
         ,P1.PEO_RATE_DIFFERENTIAL AS SER_PROV_SHIFT_DIFFERENTIAL
         ,PEOCITY.CITY_STATE_PROV_TEXT AS SERV_PROV_STATE_PROVINCE
         ,DECODE(P1.PEO_ACTIVE, 'Y', 'ACTIVE', 'INACTIVE') AS SERVICE_PROVIDER_STATUS
         ,P1.PEO_URL AS SERV_PROV_WEB_SITE_ADDRESS
         ,P1.PEO_PHONE AS SERVICE_PROVIDER_WORK_PHONE
         ,P1.PEO_POSTAL_CODE AS SERV_PROV_ZIP_POSTAL_CODE
--         ,' ' AS SHIFT
--         ,' ' AS SKILL
         ,DECODE(JT.JT_BIGSTATUS_ID,138813,'NEW'
                                   ,138814,'PENDING'
                                   ,138815,'OPEN'
                                   ,138816,'COMPLETED'
                                   ,138817,'CLOSED'
                                   ,138818,'CANCELLED',NULL,' ') AS STATUS
         ,LEV.LEVELS_NAME AS SUBREGION
--         ,' ' AS TRADE
         ,P1.PEO_LS_INTERFACE_CODE1 AS VENDOR_ID
         ,P1.PEO_FAX AS VENDOR_PURCHASING_FAX
         ,P1.PEO_VENDOR_SITE_CODE AS VENDOR_SITECODE
         ,JT.JT_ID AS VENDOR_TICKET
         ,P1.PEO_NAME AS VENDOR_COMPANYNAME
         ,JT.JT_REQUESTOR_VIP AS VIP
         ,WO.WO_ID AS WORK_ORDER_NO
         ,JT.JT_ID AS WORK_REQUEST
         ,JT.JT_CLASS_ID AS WORK_REQUEST_CLASS
         ,WOTY.WORKTYPE_TEXT AS WORK_TYPE
--         ,' ' AS WR_COST
         ,JT.JT_DESCRIPTION AS WR_DESCRIPTION
--         ,' ' AS WR_DISPATCH_METHOD
         ,DECODE(JT.JT_BIGSTATUS_ID,138813,'NEW'
                                   ,138814,'PENDING'
                                   ,138815,'OPEN'
                                   ,138816,'COMPLETED'
                                   ,138817,'CLOSED'
                                   ,138818,'CANCELLED',NULL,' ') AS WR_STATUS
         ,CTRY.COUNTRY_NAME AS COUNTRY
         ,SYSDATE --LD_CURR_TIME
     FROM CITI.JOBTICKET JT,
          CITI.PROPERTY PROP,
          CITI.BLDG BL,
          CITI.BLDG_LEVELS BLDGLVL,
          CITI.LEVELS LEV,
          CITI.LEVELS PAR,
          (SELECT CRSTOOLS.STRAGG(PEO_NAME) FACILITY_MANAGER,
                  BLDGCON_BLDG_ID
             FROM CITI.BLDG_CONTACTS, CITI.PEOPLE
            WHERE BLDGCON_PEO_ID = PEO_ID
              AND BLDGCON_CONTYPE_ID IN (40181, 10142)
            GROUP BY BLDGCON_BLDG_ID) FMG,
          CITI.FLOORS FL,
          CITI.ROOM RM,
          CITI.GENERAL_LEDGER GL,
          CITI.LEGAL_ENTITY LE,
          CITI.COST_CENTER_CODES CC,
          CITI.EQUIPMENT EQP,
          CITI.WORKTYPE WOTY,
          CITI.SUBWORKTYPE SWOTY,
          CITI.WORK_ORDER WO,
          CITI.JT_WORKERS JTWO,
          CITI.PRIORITY,
          CITI.COUNTRY CTRY,
          CITI.PEOPLE P1,
          CITI.PEOPLE PEO3,
          CITI.PEOPLE PEO1,
          CITI.CITY PEOCITY,
          CITI.CURRENCY PEOCUR
    WHERE JT.JT_BLDG_ID = BL.BLDG_ID
      AND BL.BLDG_ID = BLDGLVL.BLDG_LEVELS_BLDG_ID
      AND BLDGLVL.BLDG_LEVELS_LEVELS_ID = LEV.LEVELS_ID
      AND LEV.LEVELS_PARENT = PAR.LEVELS_ID(+)
      AND PROP.PROPERTY_ID = BL.BLDG_PROPERTY_ID
      AND BL.BLDG_ACTIVE_LS = 'N'
      AND JT.JT_FLOORS_ID = FL.FLOORS_ID(+)
      AND JT.JT_ROOM_ID = RM.ROOM_ID(+)
      AND JT.JT_BLDG_ID = FMG.BLDGCON_BLDG_ID(+)
      AND JT.JT_GENLED_ID = GL.GENLED_ID(+)
      AND GL.GENLED_LGLENT_ID = LE.LGLENT_ID(+)
      AND JT.JT_CSTCTRCD_ID = CC.CSTCTRCD_ID(+)
      AND JT.JT_EQUIP_ID = EQP.EQUIP_ID(+)
      AND JT.JT_ID = JTWO.JTW_JT_ID(+)
      AND JT.JT_WORKTYPE_ID = WOTY.WORKTYPE_ID(+)
      AND JT.JT_SWORKTYPE_ID = SWOTY.SWORKTYPE_ID(+)
      AND JT.JT_WO_ID = WO.WO_ID
      AND JT.JT_PRIORITY_ID = PRIORITY_ID(+)
         --AND jt.jt_date_requested >= ADD_MONTHS (SYSDATE, -12)
      AND JT.JT_LAST_UPDATE >= ADD_MONTHS(LD_CURR_TIME, -12)
      AND BL.BLDG_COUNTRY_ID = CTRY.COUNTRY_ID
      AND JTWO.JTW_PEO_ID = P1.PEO_ID(+)
      AND P1.PEO_CITY_ID = PEOCITY.CITY_ID(+)
      AND JT.JT_COMPLETED_BY_PEO_ID = PEO3.PEO_ID(+)
      AND P1.PEO_RATE_CURRENCY_ID = PEOCUR.CURRENCY_ID(+)
      AND JT.JT_AGENT_PEO_ID = PEO1.PEO_ID(+)
   COMMIT;
EXCEPTION
   WHEN OTHERS THEN
      ROLLBACK;
      DBMS_OUTPUT.PUT_LINE('SQLCODE :' || SQLCODE || ' Error :' || SQLERRM);
END WORK_KIOSK_FULL;Here's the link for infor on the [Oracle Direct-Path INSERT |http://download.oracle.com/docs/cd/B10501_01/server.920/a96524/c21dlins.htm#10778].
Also, if you are truly intent on using a CURSOR FOR LOOP with the BULK COLLECT, I suggest you read Steven Feuerstein's article [PL/SQL Practices: On BULK COLLECT |http://www.oracle.com/technology/oramag/oracle/08-mar/o28plsql.html].
Hope this helps.
Craig...
If my response or the response of another was helpful, please mark it accordingly

How to call BULK COLLECT using JDBC in JSP?

Hi
I am using BULK COLLECT instead of CURSOR in my Stored Procedure.
How to use these stuff in JDBC.
If i am using CURSOR means
cs.registerOutParameter(1,oracle.jdbc.driver.OracleTypes.CURSOR);
is used.
Which types i have to use?
I am retriving morethan one record using FOR. LOOP in SP and before that
BULK COLLECT is used in SELECT query..
Can you give jsp code for this?
Thanks

you may find related sample jdbc code on otn - http://www.oracle.com/technology/sample_code/tech/java/sqlj_jdbc/index.html
Best regards.

Where to put the commit in the FORALL BULK COLLECT LOOP

Hi,
Have the following LOOP code using FORALL and bulk collect, but didnt know where to put the
'commit' :
open f_viewed;
LOOP
fetch f_viewed bulk collect into f_viewed_rec LIMIT 2000;
forall i in 1..f_viewed_rec.count
insert into jwoodman.jw_job_history_112300
values f_viewed_rec(i);
--commit; [Can I put this 'commit' here? - Jenny]
EXIT when f_viewed%NOTFOUND;
END LOOP;
commit;
Thanks,
- Jenny

mc**** wrote:
Bulk collect normally used with large data sets. If you have less dataset such as 1000-2000 records then you canot get such a performance improvent using bulk collect.(Please see oracle documents for this)
When you update records Oracle acquire exclusive lock for that. So if you use commit inside the loop then it will process number of records defined by limit parameter at ones and then commit those changes.
That will release all locks acquired by Oracle and also teh memory used to keep those uncommited transactions.
If you use commit outside the loop,
Just assume that you insert 100,000 records, all those records will store in oracle memory and it will affect all other users performance as well.
Further more if you update 100,000 records then it will hold exclusive lock for all 100,000 records addtion to the usage of the oracle memory.
I am using this for telco application which we process over 30 million complex records (one row has 234 columns).
When we work with large data sets we do not depends with the oracle basic rollback function. because when you keep records without commit itb uses oracle memory and badly slowdown all other processes.Hi mc****,
What a load of dangerous and inaccurate rubbish to be telling a new Oracle developer. Commit processing should be driven by the logical unit of a transaction. This should hold true whether that transaction involves a few rows or millions. If, and only if, the transaction is so large that it affects the size constraints of the database resources, in particular, rollback or redo space, then you can consider breaking that transaction up to smaller transactions.
Why is frequent committing undesirable I hear you ask?
First of all it is hugely wasteful of rollback or redo space. This is because while the database is capable of locking at a row level, redo is written at a block level, which means that if you update, delete or insert a million rows and commit after each individual statement, then that is a million blocks that need to go into redo. As many of these rows will be in the same block, if you instead do these as one transaction, then the same block in redo can be transacted upon, making the operation more efficient. True, locks will be held for longer, but if this is new data being done in batches then users will rarely be inconvenienced. If locking is a problem then I would suggest that you should be looking at how you are doing your processing.
Secondly, committing brings into play one of the major serialization points in the database, log sync. When a transaction is committed, the log buffer needs to be written to disc. This occurs serially for multiple commits. Each commit has to wait until the commit before has completed. This becomes even more of a bottleneck if you are using Data Guard in SYNC mode, as the commit cycle does not complete until the remote log is notified as written.
This then brings us two rules of thumb that will always lead a developer in the right direction.
1. Commit as infrequently as possible, usually at the logical unit of a transaction
2. When building transactions, first of all seek to do it using straight SQL (CTAS, insert select, update where etc). If this can't be easily achieved, then use PL/SQL bulk operations.
Regards
Andre

BULK COLLECT QUERY REWRITE

I understand that Oracle 10g will rewrite your CURSOR FOR LOOP statements into a BULK COLLECT statement.
I am contemplating no longer explicitly writing the BULK COLLECT from now on as it reduces the number of lines of code and greatly simplifies code.
Can anyone see any serious flaws in this strategy?
Kind Regards
Chris

> I also think it is a good idea if people do take the
time to decide their strategy. You seem to be
suggesting that it is a bad idea to stop and think
about what you require from your loop.
Well, that depends on the type of programmer. When one deals with programmers that are not true PL/SQL developers and view PL/SQL.. well, as some kind of inferior database language (compared to something like Java for example).. you want to have templates and stuff to enforce best practises.
> I also don't agree with the 'package tuning knob'.
Each query may have different requirements and, as
with most things in programming, fixing one thing can
have a negative effect on another. It is about the
only place where would not advocate constants.
You have a point - but even so, defining these as constants (even if it has to be inside the actual proc doing the bulk fetch, one per bulk fetch) make it a lot easier to maintain than having to search out the actual bulk fetch statements in the code.
> But i would suggest that analysis is performed on a
close-to-live enviroment with a production level
server, large body of test data and multiple users. I
think we agree on that point.
Yeah.. but the problem there is that I have never really seen such an environment. Usually due to costs. How do you for example duplicate a large RAC, terabytes of SAN space, 1000's of users, for use as a close-to-live enviroment?
The usual approach (by management) is to spend as little as possible on development and Q&A platforms. Which at times means that the performance of dev vs. production can vary a lot.
So we have to play the hand we're dealt with unfortunately.
> Hmmm cmegar and I have never once said "don't worry
about, PL/SQL does it for you".
Yes - of course not. I'm just rambling on in general describing the usual attitudes I see when it comes to features like this.
It is managable in small dev team, but larger ones.. not really. There this attitude is often previlant in my experience. The "silver bullet" bullet syndrome.
> Would you use the same argument with regard to unit
testing. There are not many pl/sql developers who
unit test but should that prevent me using the
technique?
Well.. to be honest, I do not think that a developer that writes at least some basic unit tests for his/her code can be called a developer.
> >[i]Relying on implicit features to "fix" code for
you negates a deeper and better understanding of the
language and what you writeI don't see how using an implicit bulk collect is
fixing code.
Which is why I put it in brackets - "fixing" ito making it more performant, or "fixing" it as a FOR loop contains DMLs that can be changed to FORALLs.
> Don't tell me you've never
updated older code to take advangate of a new
feature.
I can never stop the urge to refactor old code I'm working with. :-)
> >[i]I think of features as an implicit bulk collect
behind the scenes, as crutches for mediocre
programmers.I take it that statement is suggesting that cmedgar
and I are mediocre programmers? Not a nice way to end
an otherwise constructive argument.
How does that saying go? You claim the cloth that I cut? :-)
My sincere apologies to both you guys - I did not intend that statement to personal at all.
Besides, I'm usually more blunt than that what it comes to throwing personal insults around. ;-)
This statement was just a general observation going back to my early days of writing Cobol and Natural. Programmers at time do not seem to care about grokking the features and apply them correctly. Actually I want to say "most programmers" and "a lot of times", but then I would be accused of generalisation. ;-)
I simply find it very frustrating dealing with programmers that does not simply love to write code. Programmers that see it as a mere job.
Someone once said that he never starts out to write beautiful code. But when he is done and the code is not beautiful and elegant (and simple), he knows he has screwed up.
In my experience.. many programmers will not understand this.

Bulk collect into compound array

Hi guys,
just having a bit of an issue here. here's what I've got so far (simplified):
declare
type t_rec is record(foo_rec foo%rowtype,
                             id number);
type t_tab is table of t_rec index by pls_integer;
w_footab t_tab;
begin
select foo.*,
         3
bulk collect into w_footab
from foo;
end;but I get the error pls00597 expression w_footab in the INTO list is of wrong type.
oracle version: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi

Hi WhiteHat,
You can't select into a layered PL/SQL structure like this.
SQL> create table foo (col1,col2) as select 1,2 from dual
2 /
Tabel is aangemaakt.
SQL> declare
2    type t_rec is record
3    ( foo_rec foo%rowtype
4    , id number
5    );
6    type t_tab is table of t_rec index by pls_integer;
7    w_footab t_tab;
8 begin
9    select foo.*
10         , 3
11           bulk collect into w_footab
12      from foo
13    ;
14 end;
15 /
         bulk collect into w_footab
FOUT in regel 11:
.ORA-06550: line 11, column 28:
PLS-00597: expression 'W_FOOTAB' in the INTO list is of wrong type
ORA-06550: line 12, column 5:
PL/SQL: ORA-00904: : invalid identifier
ORA-06550: line 9, column 3:
PL/SQL: SQL Statement ignoredWhen you flatten it out, it works:
SQL> declare
2    type t_rec is record
3    ( col1 foo.col1%type
4    , col2 foo.col2%type
5    , id number
6    );
7    type t_tab is table of t_rec index by pls_integer;
8    w_footab t_tab;
9 begin
10    select foo.*
11         , 3
12           bulk collect into w_footab
13      from foo
14    ;
15 end;
16 /
PL/SQL-procedure is geslaagd.Or use SQL types, and you can use any structure you want:
SQL> create type foorec is object
2 ( foo_col1 number
3 , foo_col2 number
4 );
5 /
Type is aangemaakt.
SQL> declare
2    type t_rec is record
3    ( foo_rec foorec
4    , id number
5    );
6    type t_tab is table of t_rec index by pls_integer;
7    w_footab t_tab;
8 begin
9    select foorec(foo.col1,foo.col2)
10         , 3
11           bulk collect into w_footab
12      from foo
13    ;
14 end;
15 /
PL/SQL-procedure is geslaagd.Regards,
Rob.

Cursor Bulk Collect

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

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

Cursor with bulk collect ...

Hi experts,
CURSOR ZIP_CUR IS SELECT * FROM ZIP_MASTER WHERE ..(SUBQUERY)
OPEN ZIP_CUR;
LOOP
     EXIT WHEN C1%NOTFOUND;
     FETCH ZIP_CUR BULK COLLECT INTO ZIP_REC LIMIT 1000;
          FOR I IN ZIP_REC.FIRST..ZIP_REC.LAST
          LOOP
END LOOP
END LOOP
If there is no data in cusor then the looping after bulk collect is throughing VALUE_ERROR
but why EXIT WHEN C1%NOTFOUND not terminating procedure??
now i am using the same select statement in cursor to find the data and raise user defined exception..
is there any other way to handle in execption??
Many thanks,
Kalinga..

You can try something like this -
satyaki>
satyaki>declare
2   CURSOR c_emp
3   IS
4     SELECT *
5     FROM emp_s
6     WHERE deptno in (
7                       SELECT deptno
8                       from emp_s
9                       where job = 'ANALYST'
10                     );
11
12   type emp_tt is table of emp_s%rowtype index by pls_integer;
13
14   emp_rec emp_tt;
15 begin
16
17   OPEN c_emp;
18   LOOP
19    EXIT WHEN c_emp%NOTFOUND;
20    FETCH c_emp BULK COLLECT INTO emp_rec LIMIT 1000;
21    FOR I IN 1..emp_rec.COUNT
22    LOOP
23      dbms_output.put_line('Empno: '||emp_rec(I).empno);
24      dbms_output.put_line('Ename: '||emp_rec(I).ename);
25      dbms_output.put_line('Mgr: '||emp_rec(I).mgr);
26    END LOOP;
27   END LOOP;
28 exception
29    when others then
30      dbms_output.put_line(sqlerrm);
31 end;
32 /
Empno: 7902
Ename: FORD
Mgr: 7566
Empno: 7839
Ename: KING
Mgr: 7839
Empno: 7788
Ename: SCOTT
Mgr: 7566
Empno: 7698
Ename: BLAKE
Mgr: 7839
PL/SQL procedure successfully completed.
satyaki>Regards.
Satyaki De.

Which is better??? for loop or bulk collect

declare
cursor test is
select * from employees;
begin
open test;
loop
exit when test%notfound;
fetch test into myvar_a(i); CASE A
i:=i+1;
end loop;
close test;
open test;
fetch test bulk collect into myvar_b; CASE B
close test;
end;
Which case is better?? A or B?
Edited by: Kakashi on May 31, 2009 12:54 AM

Depends on the meaning of better.
Generally case B should be faster although a bit more elaborate code is required.
But there may be exceptions. I think I read somewhere (I'm home now and I cannot find it at the moment) that in 10g (or 11g - not sure) 100 rows at a time are pre-fetched behind scenes even when you use case A. So using case B with a low limit could well be slower.
If I can express an additional opinion case F(irst) is nearly always the best i.e. plain SQL (no loops at all). I'm aware that sometimes it cannot be used, but should be the first approach to be tried.
Regards
Etbin
FOUND: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:213366500346264333
CONTAINS
Hey Tom, love the site. I noticed in your first fetch, which was in the first for loop that did an unconditional exit:
2 for x in ( select rownum r, t1.* from big_table.big_table t1 )
3 loop
4 exit;
5 end loop;
In looking at the TKPROF output for that query, it shows the number of rows being fetched as 100. Does that prove / demonstrate the bulk collecting optimization that Oracle added in 10g, where it implicitly and automatically does a bulk collect of limit 100 behind the scenes?
This came up at a discussion at my site very recently, and I think I can just point them to your example here as a demo rather than creating my own. I assume that if you ran the same thing in 9iR2, then that first fetch of rows in TKPROF would only show 1?
Followup April 18, 2007 - 1pm US/Eastern:
yes, that demonstrates the implicit array fetch of 100 rows...
in 9i, it would show 1 row fetched.
Edited by: Etbin on 31.5.2009 10:38

Regarding Bulk Collect

Similar Messages

Maybe you are looking for