Global temporary table in PL/SQL called from APEX page

I have a global temporary table in a PL/SQL procedure that is called from an APEX page.
The global temp table is populated with data as the procedure runs and then at the end of the procedure I do a create_collection_from_query_b to populate a collection with the data from the temp table. (I do this b/c it is much faster than creating the collection and doing an add_member for each row.)
The problem is that there are no commits in my procedure but I cannot get the bulk insert to work unless I define the temp table as on commit preserve rows.
Can anyone shed any light on this issue.
Thanks,
Andrew

alamantia wrote:
My PL/SQL procedure is called from an after submit page process. Does that imply that there is a commit happening after that process is successful?Ultimately, yes.
If the process calls the PL/SQL procedure and the temp table is in the procedure, wouldn't the commit fire after all the PL/SQL code is complete which would be after the bulk insert from the temp table to my collection?Yes, but at any point in the procedure containing code like
:APEX_ITEM := ...or
select ... into :APEX_ITEM from ...or
my_procedure(p_in => ..., p_out => :APEX_ITEM, ...);or
apex_util.set_session_state(...);then APEX will commit whilst maintaining session state.
If you don't have any of these events in the procedure, then test to see if the commit is occurring in <tt>apex_collection.create_collection_from_query_b</tt> prior to creation of the collection.

Similar Messages

Problem ! Calling report6 from forms6(run_product()) using global temporary table.

Requirement :
To generate stock movement report for certain selected items.
Background :
A Form is created with data block (tmp_item_master - a global temporary table)
when_new_form_instance :
inserting into tmp_item_master from item_master and then execute_query on tmp_item_master block.
User selects certain items using check box provided.
Now tmp_item_master is updated for ch_select_flag_yn = 'Y' for selected items
and commit.
Calling report from form(using run_product()).
Now the main query in report, is joined with tmp_item_master where ch_select_flag_yn = 'Y'
Here, we are unable to see the report for any item. As the global temporary table data is not visible in the report session.
How to resolve this problem ?
Note : global temporary table created with ON COMMIT PRESERVE ROWS
Thanking you,
From praful.
null

Hi,
You are using 'ON Commit Delete Rows' . Instead of Use ' ON COMMIT PRESERVE ROWS'
The ON COMMIT DELETE ROWS clause indicates that the data should be deleted at the end of the transaction.
CREATE GLOBAL TEMPORARY TABLE my_temp_table (
column1 NUMBER,
column2 NUMBER
) ON COMMIT DELETE ROWS;
In contrast, the ON COMMIT PRESERVE ROWS clause indicates that rows should be preserved until the end of the session.
CREATE GLOBAL TEMPORARY TABLE my_temp_table (
column1 NUMBER,
column2 NUMBER
) ON COMMIT PRESERVE ROWS;
Edited by: Mrucha on Nov 26, 2012 6:06 AM

Global Temporary table is Not working For Pdf Reports

Hi all
we are using oracle db-10g, developer suite-10g.
While generating the Report for the satisfying several conditions we are fetching the data into
Global temporary table
On commit preserve rows
from this temp tables excel is generated properly. but pdf is not generating can anybody exaplain why it is not generating and what to do for that
Thank you

query and view are not possible
here i am giving one of the requirement
my project is belongs to inventory project.
report should be generated on the different selection criteria like
1)user can select one or more product codes
2)for that product code one or more item codes can select
like this so many different selection are there more than 12 selections from different tables
For this each different selection product code into gtt_prod_cd and item_cd into gtt_item_cd. after that performed the query and in where clause we are comparing the values with gtt.
can you please suggest me what to do for PDF Reports

Weird issue: Partial data inserted when reading from Global temporary table

I have a complex sql query that fetches 88k records. This query uses a global temporary table which is the replica of one of our permanent tables. When I do Create table..select... using this query it inserts only fewer records (66k or lesser). But when I make the query point to the permanent table it inserts all 88k records.
1. I tried running the select query separately using temp and perm table. Both retrieves 88k records.
2. From debugging I found that this problem occurred when we were trying to perform a left outer join on an inline view.
However this problem got resolved when I used the /*+ FIRST_ROWS */ hint.
From my limited oracle knowledge I assume that it is the problem with the query and how it is processed in the memory.
Can someone clarify what is happening behind the scenes and if there is a better solution?
Thanks

user3437160 wrote:
I have a complex sql query that fetches 88k records. This query uses a global temporary table which is the replica of one of our permanent tables. When I do Create table..select... using this query it inserts only fewer records (66k or lesser). But when I make the query point to the permanent table it inserts all 88k records.
1. I tried running the select query separately using temp and perm table. Both retrieves 88k records.
2. From debugging I found that this problem occurred when we were trying to perform a left outer join on an inline view.
However this problem got resolved when I used the /*+ FIRST_ROWS */ hint.
From my limited oracle knowledge I assume that it is the problem with the query and how it is processed in the memory.
Can someone clarify what is happening behind the scenes and if there is a better solution?
Thanksmight specifics be OS & Oracle version dependent?
How to ask question
SQL and PL/SQL FAQ

Datas deletion from Global Temporary table when clear command is given

Dear All,
How to Delete datas from global temporary Table when clear command is given in forms
Suggest me syntax..
Pls help..
Regards,
Gokul.B

http://psoug.org/reference/gtt.html
Francois

Auditing data from global temporary table

Hi I have a process that uses a global temporary table.
What it does it serve a consolidation point to merge a lot of data.
Some the former designer decides to use a global temporary table and the row will be gone once it got commit.
However, the data is corrupted occasionally. And ideally we would like to fix the upstream source data but this is too complicated and not feasible.
So we decide to audit the data going into the global temporary table. We want to generate a report on the corrupted data.
However, whenever I commit, the data is gone from the global temporary table and we do not want to set it to commit preserve rows for the global temporary table
Even with autonomous transaction this is not working out as once it commits the data is gone.
Any idea how this can be done. Here are the prototype that I build to demo this:
drop table gt_tst1;
--this is the table its data needs to get audit
create global temporary table gt_tst1(id number); --on commit preserve rows;
drop table not_gt_tst1;
--this table is used for storign the corrupt data and generate report
create table not_gt_tst1 as select * from gt_tst1;
CREATE OR REPLACE PROCEDURE tst_gt_tst1 IS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
--if there is a way to do the insert and select once. but it seems it is not working for global temporay table unless change it to on commit preserve rows
INSERT
when m2 = 0 THEN
INTO not_gt_tst1(id)values(object_id)
when m3 = 0 THEN
INTO gt_tst1(id) values (object_id)
select object_id,mod(object_id,2) m2, mod(object_id,3) m3 from dba_objects where rownum < 101;
COMMIT;
END tst_gt_tst1;
select sysdate from dual;
truncate table gt_tst1;
truncate table not_gt_tst1;
select * from gt_tst1;
select * from not_gt_tst1;
execute tst_gt_tst1;
select * from gt_tst1; -- data gone
select * from not_gt_tst1;
--commit
select sysdate from dual;
spool off

The data is poor and the code is poor and the dev and QA env is also poor..
And the business asks us to fix the data..However..we do not have an environment close enough to test it out before it got put into production that is the bottom line.
Heres the dev and QA env cannot be trust to the extent that I can sign off and say it will give the same behavior as the production env
So we would like to minimize the risk as there are other process uses these table and we are not sure if changing this would lead to UN-expected behavior.
We cannot tell some other process rely on the fact that these table got empty out after commit.
Edited by: vxwo0owxv on Jan 23, 2012 12:18 PM
Edited by: vxwo0owxv on Jan 23, 2012 12:20 PM

Doubt with Global Temporary table

hi,
i have created a global temporary table with ON COMMIT DELETE ROWS option. in my Function in a loop i m inserting values into this Table, after that loop closes and then i m selecting some other values from DB. and in the last i am returning a ref cursor which is selecting values from temporary table i hav created.
now the thing is i m not getting any values in the cursor.
later I have created the table with ON COMMIT PRESERVE ROWS option, in this case cursor returning values,
can anyone explain me the functionality, as per my knowledge global temporary table values are session specific so why i m not getting the values in the 1st case when i used ON COMMIT DELETE ROWS (same session).
Thanks
Piyush

Ok, here's a simple example, like we'd like to see from you not working....
First create a GTT with ON COMMIT DELETE ROWS...
SQL> ed
Wrote file afiedt.buf
1* create global temporary table mytable (x number) on commit delete rows
SQL> /
Table created.Now a simple function that populates the GTT and returns a ref cursor to the data without doing any commits (hence the data should be there!)
SQL> ed
Wrote file afiedt.buf
1 create or replace function pop_table return sys_refcursor is
2    v_rc sys_refcursor;
3 begin
4    insert into mytable
5    select rownum from dual connect by rownum <= 10;
6    OPEN v_rc FOR SELECT x FROM mytable;
7    RETURN v_rc;
8* end;
SQL> /
Function created.So now we call the function and get a reference to our ref cursor...
SQL> var v_a refcursor;
SQL> exec :v_a := pop_table();
PL/SQL procedure successfully completed.So, in principle, because no commits have been issued the ref cursor should return data...
SQL> print v_a;
         X
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
10 rows selected.... which it does.
Now, what happens if we do that again...
SQL> commit;
Commit complete.
SQL> exec :v_a := pop_table();
PL/SQL procedure successfully completed.... but this time we commit before retrieving the data...
SQL> commit;
Commit complete.
SQL> print v_a;
ERROR:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_1], [0], [0], [1], [], [], [], []
no rows selected
SQL>Oracle has (correctly) lost reference to the data because of the commit.
So show us what yours is doing.

Direct Path Loading Issues with Global Temporary Tables - OCI & OCILib

I am writing some code to import data into a warehouse from a CPU grid which computes risk data. Due to the fact a computing grid is used there will be many clients which can load the data concurrently and at any point in time.
Currently the import uses Binding in OCCI and chunking with a prepared statement to import the data into a global temporary table in a staging area after which a stored procedure is called within the same session which will process the data and load the data into a star schema.
The GTT has the advantage that if any clients have issues no dirty data will be left and each client only sees their own instance of the data.
I have been looking at using direct path loading to increase the performance of the load and have written some OCI code to perform the same task. I have manged to import the data into a regular heap based table using the OCI direct path apis. However when I try and use the same code to import against a Global Temporary Table I get an OCI Error (ORA-00600: internal error code, arguments: [6979], [16], [1], [1318528], [], [], [], [], [], [], [], [])
I get error when the function OCIDirPathPrepare is executed. The same issue occurs in both OCI and OCILib.
Is it not possible to use Direct Path Loading against a Global Temporry Table ? Because you can use the /*+ APPEND */ hint and load global temporary tables this way from tools like SQL Devloper / toad which is surely informing the SQL Engine to use Direct Path ?
Looking at the table USER_OBJECTS I can see that for a Global Temporary Table the DATA_OBJECT_ID is null. Does this mean that it is impossible to us a direct path load into Global Temporary Tables ?
Any ideas / suggestions would be really appreciated. If this means redesigning the application then I would appreciate suggestions which would allow many client to quick write processes in a parallel fashion. If this means creating a new parition in a Heap Table for each writer and direct path loading into this table then so be it.
Thanks
H
Edited by: 813640 on 19-Nov-2010 11:08

Replying to my own message in case anyone else is interested.
I have now managed to successfully load data using direct path into a global temporary table with OCI. There appears to be no reason why this approach will not work.
I loaded data into the temporary table and then issued a select count(*) on the table from within the session and from a new session. The results were as expected.
The resaon for the ORA-006000 error was due to the fact that I had enabled table level parallel loading
ie
OCIAttrSet((dvoid *) context, (ub4) OCI_HTYPE_DIRPATH_CTX, *(ub1) 1*, (ub4)0, (ub4) OCI_ATTR_DIRPATH_PARALLEL, errhp)
When loading a Global Temporary Table the OCI_ATTR_DIRPATH_PARALLEL attribute needs to be zero
This makes sense, since the temp table does not have any partitions so it would not be possible to write in parallel to multiple paritions.
Edited by: 813640 on 22-Nov-2010 08:42

Java Error while Using GLobal Temporary Tables

Hi,
Am having a global temporary table in my application with ON COMMIT DELETE ROWS option.
I use it in a procedure to remove previous records, populate new ones and return a ref cursor
Am calling this procedure from a java bean. In this call, the procedure gets executed successfully but when i try to access the RefCursor Object, I get an SQL Exception that the object no longer exists.
Here are some inputs for reference:
My DB Call:
cstmt = myConn.prepareCall ("{ call MYPACKAGE.GTT_PROCEDURE(?,?,?,?,?, ?,?,?,?,?, ?,?,?,?,?)}");
My RefCursor Access:
rsRuleSet = (ResultSet)cstmt.getObject(11);
The SQLException:
java.sql.SQLException: ORA-08103: object no longer exists
Please note that the SQLException shown as per Java Stack trace is on the line with the RefCursor Access
If anybody has any idea, then do reply
Thanks in Advance,
Piyush

A couple of thoughts...
Have you tried calling this procedure from PL/SQL to verify that the REF CURSOR returned is valid?
Is your Java application set to autocommit, or do handle transactions yourself. If the container is handling transactions, it may committing as soon as the stored procedure finishes running, which would clear your temp table.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

Deadlock with CREATE GLOBAL TEMPORARY TABLE

I got this error
ORA-00604: error occurred at recursive SQL level 1
ORA-00060: deadlock detected while waiting for resource
while trying to create global temporary table.
Table creation command:
CREATE GLOBAL TEMPORARY TABLE ITUSER.T_0091FBDG ("GOD" char(4) DEFAULT (' ') NOT NULL,"UNKUM" number(10,0) DEFAULT (0) NOT NULL,[a lot of other fields]) ON COMMIT PRESERVE ROWS
There is no outer references in command. So does somebody know where does deadlock come from?
I'm using Oracle 10g.
Edited by: LeopoldStoch on Apr 13, 2010 7:04 AM

I have grabbed log files. But it make me even more curious. Here it is:
alert_itdb.log
Thread 1 advanced to log sequence 253 (LGWR switch)
Current log# 1 seq# 253 mem# 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ITDB\REDO01.LOG
Tue Apr 13 10:53:09 2010
Thread 1 advanced to log sequence 254 (LGWR switch)
Current log# 2 seq# 254 mem# 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ITDB\REDO02.LOG
Tue Apr 13 10:55:32 2010
Thread 1 advanced to log sequence 255 (LGWR switch)
Current log# 3 seq# 255 mem# 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ITDB\REDO03.LOG
Tue Apr 13 10:55:49 2010
ORA-00060: Deadlock detected. More info in file c:\oracle\product\10.2.0\admin\itdb\udump\itdb_ora_3868.trc.
Tue Apr 13 11:01:58 2010
Thread 1 advanced to log sequence 256 (LGWR switch)
Current log# 1 seq# 256 mem# 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ITDB\REDO01.LOG
Tue Apr 13 11:03:29 2010
Thread 1 advanced to log sequence 257 (LGWR switch)
Current log# 2 seq# 257 mem# 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ITDB\REDO02.LOG
Tue Apr 13 11:14:16 2010
itdb_ora_3868.trc
Dump file c:\oracle\product\10.2.0\admin\itdb\udump\itdb_ora_3868.trc
Tue Apr 13 10:55:48 2010
ORACLE V10.2.0.4.0 - Production vsnsta=0
vsnsql=14 vsnxtr=3
Oracle Database 10g Release 10.2.0.4.0 - Production
Windows NT Version V5.2 Service Pack 2
CPU : 2 - type 586, 1 Physical Cores
Process Affinity : 0x00000000
Memory (Avail/Total): Ph:3568M/8188M, Ph+PgF:7889M/12090M, VA:579M/2799M
Instance name: itdb
Redo thread mounted by this instance: 1
Oracle process number: 18
Windows thread id: 3868, image: ORACLE.EXE (SHAD)
*** 2010-04-13 10:55:48.874
*** ACTION NAME:() 2010-04-13 10:55:48.811
*** MODULE NAME:(5436,20100413105316,82100) 2010-04-13 10:55:48.811
*** SERVICE NAME:(ITDB) 2010-04-13 10:55:48.811
*** SESSION ID:(145.52602) 2010-04-13 10:55:48.811
DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-00080011-0000198d 18 145 X 17 158 S
TX-0006001c-0000192d 17 158 X 18 145 S
session 145: DID 0001-0012-00000164 session 158: DID 0001-0011-000005F5
session 158: DID 0001-0011-000005F5 session 145: DID 0001-0012-00000164
Rows waited on:
Session 158: obj - rowid = 00000000 - D/////AACAAAKy6AAA
(dictionary objn - 0, file - 2, block - 44218, slot - 0)
Session 145: obj - rowid = 00000000 - D/////AACAAAABJAAA
(dictionary objn - 0, file - 2, block - 73, slot - 0)
Information on the OTHER waiting sessions:
Session 158:
pid=17 serial=2727 audsid=241067 user: 60/ITUSER
O/S info: user: VSC03\it_appsrv, term: VSC03, ospid: 2328:2640, machine: WORKGROUP\VSC03
program: AppServer.exe
client info: ELIZ-041.R#046IKSANOV.RIKSANOV.VSC03:8223.2328.5-1-2600.IT_APPSR
application name: 5436,20100413105322,82000, hash value=3107059750
Current SQL Statement:
CREATE GLOBAL TEMPORARY TABLE ITUSER.T_009EFBDN ("GOD" char(4) DEFAULT (' ') NOT NULL,"UNKUM" number(10,0) DEFAULT (0) NOT NULL,"CENA" number(15,5) DEFAULT (0) NOT NULL,"EDI" number(3,0) NULL,"EDI2" number(3,0) NULL,"KOL" number(14,5) DEFAULT (0) NOT NULL,"KOL2" number(14,5) DEFAULT (0) NOT NULL,"SUMMA" number(16,2) DEFAULT (0) NOT NULL,"KOL_N1" number(14,5) DEFAULT (0) NOT NULL,"KOL_N2" number(14,5) DEFAULT (0) NOT NULL,"KOL_N3" number(14,5) DEFAULT (0) NOT NULL,"KOL_N4" number(14,5) DEFAULT (0) NOT NULL,"KOL_N5" number(14,5) DEFAULT (0) NOT NULL,"KOL_N6" number(14,5) DEFAULT (0) NOT NULL,"KOL_N7" number(14,5) DEFAULT (0) NOT NULL,"KOL_N8" number(14,5) DEFAULT (0) NOT NULL,"KOL_N9" number(14,5) DEFAULT (0) NOT NULL,"KOL_N10" number(14,5) DEFAULT (0) NOT NULL,"KOL_N11" number(14,5) DEFAULT (0) NOT NULL,"KOL_N12" number(14,5) DEFAULT (0) NOT NULL,"KOL_N13" number(14,5) DEFAULT (0) NOT NULL,"KOL2N1" number(14,5) DEFAULT (0) NOT NULL,"KOL2N2" number(14,5) DEFAULT (0) NOT NULL,"KOL2N3" number(14,5) DEFAULT (0) NOT NULL,"KOL2N4" number(14,5) DEFAULT (0) NOT NULL,"KOL2N5" number(14,5) DEFAULT (0) NOT NULL,"KOL2N6" number(14,5) DEFAULT (0) NOT NULL,"KOL2N7" number(14,5) DEFAULT (0) NOT NULL,"KOL2N8" number(14,5) DEFAULT (0) NOT NULL,"KOL2N9" number(14,5) DEFAULT (0) NOT NULL,"KOL2N10" number(14,5) DEFAULT (0) NOT NULL,"KOL2N11" number(14,5) DEFAULT (0) NOT NULL,"KOL2N12" number(14,5) DEFAULT (0) NOT NULL,"KOL2N13" number(14,5) DEFAULT (0) NOT NULL,"SUM_N1" number(16,2) DEFAULT (0) NOT NULL,"SUM_N2" number(16,2) DEFAULT (0) NOT NULL,"SUM_N3" number(16,2) DEFAULT (0) NOT NULL,"SUM_N4" number(16,2) DEFAULT (0) NOT NULL,"SUM_N5" number(16,2) DEFAULT (0) NOT NULL,"SUM_N6" number(16,2) DEFAULT (0) NOT NULL,"SUM_N7" number(16,2) DEFAULT (0) NOT NULL,"SUM_N8" number(16,2) DEFAULT (0) NOT NULL,"SUM_N9" number(16,2) DEFAULT (0) NOT NULL,"SUM_N10" number(16,2) DEFAULT (0) NOT NULL,"SUM_N11" number(16,2) DEFAULT (0) NOT NULL,"SUM_N12" number(16,2) DEFAULT (0) NOT NULL,"SUM_N13" number(16,2) DEFAULT (0) NOT NULL,"DATE_REST" date NULL,"KOL_PRI" number(14,5) DEFAULT (0) NOT NULL,"KOL2PRI" number(14,5) DEFAULT (0) NOT NULL,"SUM_PRI" number(16,2) DEFAULT (0) NOT NULL,"DATE_FPRI" date NULL,"NDOC_FPRI" char(20) DEFAULT (' ') NOT NULL,"KOL_PRIG" number(14,5) DEFAULT (0) NOT NULL,"KOL2PRIG" number(14,5) DEFAULT (0) NOT NULL,"SUM_PRIG" number(16,2) DEFAULT (0) NOT NULL,"KOL_PRIT" number(14,5) DEFAULT (0) NOT NULL,"KOL2PRIT" number(14,5) DEFAULT (0) NOT NULL,"KOL_RAS" number(14,5) DEFAULT (0) NOT NULL,"KOL2RAS" number(14,5) DEFAULT (0) NOT NULL,"SUM_RAS" number(16,2) DEFAULT (0) NOT NULL,"DATE_LRAS" date NULL,"NDOC_LRAS" char(20) DEFAULT (' ') NOT NULL,"KOL_RASG" number(14,5) DEFAULT (0) NOT NULL,"KOL2RASG" number(14,5) DEFAULT (0) NOT NULL,"SUM_RASG" number(16,2) DEFAULT (0) NOT NULL,"KOL_RAST" number(14,5) DEFAULT (0) NOT NULL,"KOL2RAST" number(14,5) DEFAULT (0) NOT NULL,"KOL_PRIREZ" number(14,5) DEFAULT (0) NOT NULL,"KOL2PRIREZ" number(14,5) DEFAULT (0) NOT NULL,"SUM_PRIREZ" number(16,2) DEFAULT (0) NOT NULL,"KOL_RASREZ" number(14,5) DEFAULT (0) NOT NULL,"KOL2RASREZ" number(14,5) DEFAULT (0) NOT NULL,"SUM_RASREZ" number(16,2) DEFAULT (0) NOT NULL,"PRC_RAS" number(3,0) DEFAULT (0) NOT NULL,"KSSM" char(5) NULL,"COMM" char(40) DEFAULT (' ') NOT NULL,"KDM3" char(1) DEFAULT (' ') NOT NULL,"KDM4" char(1) DEFAULT (' ') NOT NULL,"KOL_INV" number(14,5) DEFAULT (0) NOT NULL,"KOL2INV" number(14,5) DEFAULT (0) NOT NULL,"CENA_INV" number(15,5) DEFAULT (0) NOT NULL,"SUM_INV" number(16,2) DEFAULT (0) NOT NULL,"DATE_INV" date NULL,"KSBG" char(3) DEFAULT (' ') NOT NULL,"KOL_C" number(14,5) DEFAULT (0) NOT NULL,"KOL2C" number(14,5) DEFAULT (0) NOT NULL,"SUM_C" number(16,2) DEFAULT (0) NOT NULL,"KBLS" char(5) DEFAULT (' ') NOT NULL,"BS_ZATR" char(10) NULL,"KAU_ZATR" char(12) DEFAULT (' ') NOT NULL,"MECEXPL" number(3,0) DEFAULT (0) NOT NULL,"SUM_IZNOS" number(14,2) DEFAULT (0) NOT NULL,"SUM_IMEC" number(14,2) DEFAULT (0) NOT NULL,"NINKAS" number(10,0) DEFAULT (0) NOT NULL,"DATE_D" date NULL,"FIO_D" char(10) DEFAULT (' ') NOT NULL,"DATE_K" date NULL,"FIO_O" char(10) DEFAULT (' ') NOT NULL,"STDCURR" char(1) DEFAULT (' ') NOT NULL) ON COMMIT PRESERVE ROWS
End of information on OTHER waiting sessions.
Current SQL statement for this session:
insert into col$(obj#,name,intcol#,segcol#,type#,length,precision#,scale,null$,offset,fixedstorage,segcollength,deflength,default$,col#,property,charsetid,charsetform,spare1,spare2,spare3)values(:1,:2,:3,:4,:5,:6,decode(:5,182/*DTYIYM*/,:7,183/*DTYIDS*/,:7,decode(:7,0,null,:7)),decode(:5,2,decode(:8,-127/*MAXSB1MINAL*/,null,:8),178,:8,179,:8,180,:8,181,:8,182,:8,183,:8,231,:8,null),:9,0,:10,:11,decode(:12,0,null,:12),:13,:14,:15,:16,:17,:18,:19,:20)
===================================================
PROCESS STATE
Process global information:
process: 5F28A1F8, call: 5F3A8E98, xact: 5DFF8B40, curses: 5F37D6A8, usrses: 5F375F38
SO: 5F28A1F8, type: 2, owner: 00000000, flag: INIT/-/-/0x00
(process) Oracle pid=18, calls cur/top: 5F3A8E98/5F3A75B8, flag: (0) -
int error: 0, call error: 0, sess error: 0, txn error 0
(post info) last post received: 0 0 117
last post received-location: kcbzww
last process to post me: 5f289c00 93 0
last post sent: 0 0 117
last post sent-location: kcbzww
last process posted by me: 5f289c00 93 0
(latch info) wait_event=0 bits=0
Process Group: DEFAULT, pseudo proc: 5F2BC4EC
O/S info: user: SYSTEM, term: VSC03, ospid: 3868
OSD pid info: Windows thread id: 3868, image: ORACLE.EXE (SHAD)
Dump of memory from 0x5F276E78 to 0x5F276FFC
5F276E70 0000000B 5E1231B8 [.....1.^]
5F276E80 00000010 000313A9 5F3A75B8 00000003 [.........u:_....]
5F276E90 000313A9 5F4B92D4 0000000B 000313A9 [......K_........]
5F276EA0 5F375F38 00000004 0003129D 5DE1FFA4 [8_7_...........]]
5F276EB0 00000007 000313A9 5DE20028 00000007 [........(..]....]
5F276EC0 000313A9 5DE200BC 00000007 000313A9 [.......]........]
5F276ED0 5DE20140 00000007 000313A9 5DE201C4 [@..]...........]]
5F276EE0 00000007 000313A9 5DE20248 00000007 [........H..]....]
5F276EF0 000313A9 5DE202CC 00000007 000313A9 [.......]........]
5F276F00 00000000 00000000 00000000 00000000 [................]
Repeat 14 times
5F276FF0 00000000 00000000 00000000 [............]
(FOB) flags=2 fib=5DEEEC98 incno=0 pending i/o cnt=0
fname=C:\ORACLE\PRODUCT\10.2.0\ORADATA\ITDB\UNDOTBS01.DBF
fno=2 lblksz=8192 fsiz=311040
(FOB) flags=2 fib=5DEEE608 incno=0 pending i/o cnt=0
fname=C:\ORACLE\PRODUCT\10.2.0\ORADATA\ITDB\CONTROL03.CTL
fno=2 lblksz=16384 fsiz=430
(FOB) flags=2 fib=5DEEE2C8 incno=0 pending i/o cnt=0
fname=C:\ORACLE\PRODUCT\10.2.0\ORADATA\ITDB\CONTROL02.CTL
fno=1 lblksz=16384 fsiz=430
(FOB) flags=2 fib=5DEEDF88 incno=0 pending i/o cnt=0
fname=C:\ORACLE\PRODUCT\10.2.0\ORADATA\ITDB\CONTROL01.CTL
fno=0 lblksz=16384 fsiz=430
(FOB) flags=2 fib=5DEEF658 incno=0 pending i/o cnt=0
fname=C:\ORACLE\PRODUCT\10.2.0\ORADATA\ITDB\ITDATA01.DBF
fno=5 lblksz=8192 fsiz=2109440
(FOB) flags=2 fib=5DEEE948 incno=0 pending i/o cnt=0
fname=C:\ORACLE\PRODUCT\10.2.0\ORADATA\ITDB\SYSTEM01.DBF
fno=1 lblksz=8192 fsiz=79360
(FOB) flags=2 fib=5DEEFCE8 incno=0 pending i/o cnt=0
fname=C:\ORACLE\PRODUCT\10.2.0\ORADATA\ITDB\TEMP01.DBF
fno=201 lblksz=8192 fsiz=43776
SO: 5F375F38, type: 4, owner: 5F28A1F8, flag: INIT/-/-/0x00
(session) sid: 145 trans: 5D06D4B0, creator: 5F28A1F8, flag: (8100041) USR/- BSY/-/-/-/-/-
DID: 0001-0012-00000164, short-term DID: 0000-0000-00000000
txn branch: 00000000
oct: 1, prv: 0, sql: 50B2BAC0, psql: 57554078, user: 60/ITUSER
service name: ITDB
O/S info: user: VSC03\it_appsrv, term: VSC03, ospid: 3668:3616, machine: WORKGROUP\VSC03
program: AppServer.exe
client info: ELIZ-041.R#046IKSANOV.RIKSANOV.VSC03:8223.3668.5-1-2600.IT_APPSR
application name: 5436,20100413105316,82100, hash value=3093400541
last wait for 'enq: TX - allocate ITL entry' blocking sess=0x5F386200 seq=4256 wait_time=2999487 seconds since wait started=2
name|mode=54580004, usn<<16 | slot=6001c, sequence=192d
Dumping Session Wait History
for 'enq: TX - allocate ITL entry' count=1 wait_time=2999487
name|mode=54580004, usn<<16 | slot=6001c, sequence=192d
for 'buffer busy waits' count=1 wait_time=10
file#=1, block#=f923, class#=1
for 'buffer busy waits' count=1 wait_time=53
file#=1, block#=d1ff, class#=1
for 'buffer busy waits' count=1 wait_time=36
file#=1, block#=19, class#=4
for 'buffer busy waits' count=1 wait_time=28
file#=1, block#=19, class#=4
for 'buffer busy waits' count=1 wait_time=27
file#=1, block#=f923, class#=1
for 'buffer busy waits' count=1 wait_time=13
file#=1, block#=ec86, class#=1
for 'buffer busy waits' count=1 wait_time=29
file#=1, block#=f923, class#=1
for 'buffer busy waits' count=1 wait_time=15
file#=1, block#=f95d, class#=1
for 'buffer busy waits' count=1 wait_time=215
file#=1, block#=d1ff, class#=1
temporary object counter: 1
UOL used : 0 locks(used=2, free=10)
KGX Atomic Operation Log 69405330
Mutex 00000000(0, 0) idn 0 oper NONE
Cursor Parent uid 145 efd 5 whr 11 slp 0
oper=NONE pt1=A4744BC4 pt2=6842B2F4 pt3=A4744B94
pt4=00000000 u41=0 stt=0
KGX Atomic Operation Log 69405358
Mutex 50B2BB74(0, 1) idn 0 oper NONE
Cursor Stat uid 145 efd 8 whr 1 slp 0
oper=NONE pt1=50B2BAC0 pt2=00000000 pt3=00000000
pt4=00000000 u41=0 stt=8
KGX Atomic Operation Log 69405380
Mutex 00000000(0, 0) idn 0 oper NONE
Library Cache uid 145 efd 0 whr 0 slp 0
SO: 5C5A6334, type: 53, owner: 5F375F38, flag: INIT/-/-/0x00
LIBRARY OBJECT LOCK: lock=5c5a6334 handle=5e9a6868 mode=N
call pin=00000000 session pin=00000000 hpc=0000 hlc=0000
htl=5C5A6384[5C76A228,5C59D1D0] htb=5C59D1D0 ssga=5C59CD04
user=5f375f38 session=5f37d6a8 count=1 flags=CBK[0020] savepoint=0x0
LIBRARY OBJECT HANDLE: handle=5e9a6868 mtx=5E9A691C(0) cdp=0
namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
kkkk-dddd-llll=0000-0001-0001 lock=N pin=S latch#=1 hpc=c742 hlc=c742
lwt=5E9A68C4[5E9A68C4,5E9A68C4] ltm=5E9A68CC[5E9A68CC,5E9A68CC]
pwt=5E9A68A8[5E9A68A8,5E9A68A8] ptm=5E9A68B0[5E9A68B0,5E9A68B0]
ref=5E9A68E4[662DCE3C,662DCE3C] lnd=5E9A68F0[5E9A68F0,5E9A68F0]
LIBRARY OBJECT: object=51e6451c
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
DEPENDENCIES: count=1 size=16
AUTHORIZATIONS: count=1 size=16 minimum entrysize=18
ACCESSES: count=1 size=16
TRANSLATIONS: count=1 size=16
DATA BLOCKS:
data# heap pointer status pins change whr
0 a1f966d4 51e645b4 I/P/A/-/- 0 NONE 00
6 662dcce4 a24e2534 I/P/A/-/E 0 NONE 00
KGX Atomic Operation Log 50C2014C
Mutex 662DCC54(0, 2) idn d64ee82 oper SHRD
Cursor Pin uid 145 efd 0 whr 3 slp 0
opr=4 pso=5C5A6334 flg=0
pcs=662DCC54 nxt=5B9C77F4 flg=18 cld=0 hd=5E9A6868 par=54763C50
ct=2 hsh=0 unp=00000000 unn=0 hvl=662dcff0 nhv=0 ses=00000000
hep=662DCCA0 flg=80 ld=1 ob=51E6451C ptr=A24E2534 fex=A24E16F8
SO: 5C76A1D8, type: 53, owner: 5F375F38, flag: INIT/-/-/0x00
LIBRARY OBJECT LOCK: lock=5c76a1d8 handle=5a67b168 mode=N
call pin=00000000 session pin=00000000 hpc=0000 hlc=0000
htl=5C76A228[5C59D1D0,5C5A6384] htb=5C59D1D0 ssga=5C59CD04
user=5f375f38 session=5f37d6a8 count=1 flags=[0000] savepoint=0x4bc41571
LIBRARY OBJECT HANDLE: handle=5a67b168 mtx=5A67B21C(2) cdp=2
name=
insert into col$(obj#,name,intcol#,segcol#,type#,length,precision#,scale,null$,offset,fixedstorage,segcollength,deflength,default$,col#,property,charsetid,charsetform,spare1,spare2,spare3)values(:1,:2,:3,:4,:5,:6,decode(:5,182/*DTYIYM*/,:7,183/*DTYIDS*/,:7,decode(:7,0,null,:7)),decode(:5,2,decode(:8,-127/*MAXSB1MINAL*/,null,:8),178,:8,179,:8,180,:8,181,:8,182,:8,183,:8,231,:8,null),:9,0,:10,:11,decode(:12,0,null,:12),:13,:14,:15,:16,:17,:18,:19,:20)
hash=012a6293ef607cee606b82dc0d64ee82 timestamp=04-08-2010 17:06:19
namespace=CRSR flags=RON/KGHP/TIM/PN0/LRG/KST/DBN/MTX/[100100d1]
kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=1 hpc=c298 hlc=c298
lwt=5A67B1C4[5A67B1C4,5A67B1C4] ltm=5A67B1CC[5A67B1CC,5A67B1CC]
pwt=5A67B1A8[5A67B1A8,5A67B1A8] ptm=5A67B1B0[5A67B1B0,5A67B1B0]
ref=5A67B1E4[5A67B1E4,5A67B1E4] lnd=5A67B1F0[5A67B1F0,5A67B1F0]
LIBRARY OBJECT: object=54763bb8
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
CHILDREN: size=16
child# table reference handle
0 662dd020 662dce3c 5e9a6868
1 662dd020 5b9c7940 5eb1fdbc
DATA BLOCKS:
data# heap pointer status pins change whr
0 54c98590 54763c50 I/P/A/-/- 0 NONE 00
SO: 5C5AFBCC, type: 53, owner: 5F375F38, flag: INIT/-/-/0x00
LIBRARY OBJECT LOCK: lock=5c5afbcc handle=6ad6312c mode=N
call pin=00000000 session pin=00000000 hpc=0000 hlc=0000
htl=5C5AFC1C[5C61B52C,5C59D0B0] htb=5C59D0B0 ssga=5C59CD04
user=5f375f38 session=5f37d6a8 count=1 flags=[0000] savepoint=0x0
LIBRARY OBJECT HANDLE: handle=6ad6312c mtx=6AD631E0(0) cdp=0
namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=2 hpc=b9a0 hlc=b9a0
lwt=6AD63188[6AD63188,6AD63188] ltm=6AD63190[6AD63190,6AD63190]
pwt=6AD6316C[6AD6316C,6AD6316C] ptm=6AD63174[6AD63174,6AD63174
SO: 5C5A5C34, type: 53, owner: 5F375F38, flag: INIT/-/-/0x00
LIBRARY OBJECT LOCK: lock=5c5a5c34 handle=69731e20 mode=N
call pin=00000000 session pin=00000000 hpc=0000 hlc=0000
htl=5C5A5C84[5C59D4D0,5C6074B0] htb=5C59D4D0 ssga=5C59CD04
user=5f375f38 session=5f37d6a8 count=1 flags=[0000] savepoint=0x4bc41571
LIBRARY OBJECT HANDLE: handle=69731e20 mtx=69731ED4(2) cdp=2
name=update con$ set con#=:3 where owner#=:1 and name=:2
hash=cb0043a665029adc35682cfd8f583ce2 timestamp=04-08-2010 17:10:17
namespace=CRSR flags=RON/KGHP/TIM/PN0/SML/KST/DBN/MTX/[120100d0]
kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=2 hpc=ac50 hlc=ac50
lwt=69731E7C[69731E7C,69731E7C] ltm=69731E84[69731E84,69731E84]
pwt=69731E60[69731E60,69731E60] ptm=69731E68[69731E68,69731E68]
ref=69731E9C[69731E9C,69731E9C] lnd=69731EA8[69731EA8,69731EA8]
LIBRARY OBJECT: object=66177404
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
CHILDREN: size=16
child# table reference handle
0 5887c454 5887c270 69641ffc
1 5887c454 5887c400 693d29b4
DATA BLOCKS:
data# heap pointer status pins change whr
0 57178070 6617749c I/P/A/-/- 0 NONE 00
SO: 5C62D288, type: 53, owner: 5F375F38, flag: INIT/-/-/0x00
LIBRARY OBJECT LOCK: lock=5c62d288 handle=5734d800 mode=N
call pin=00000000 session pin=00000000 hpc=0000 hlc=0000
htl=5C62D2D8[5C59D590,5C59D590] htb=5C59D590 ssga=5C59CD04
user=5f375f38 session=5f375f38 count=0 flags=LRU/[4000] savepoint=0x17ee5af
LIBRARY OBJECT HANDLE: handle=5734d800 mtx=5734D8B4(0) cdp=0
name=SYS._default_auditing_options_
hash=fab1a450ca8625c88d7aa501cb042efa timestamp=03-14-2008 18:46:51
namespace=TABL flags=KGHP/TIM/SML/[02000000]
kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=1 hpc=3e1e hlc=3e1e
lwt=5734D85C[5734D85C,5734D85C] ltm=5734D864[5734D864,5734D864]
pwt=5734D840[5734D840,5734D840] ptm=5734D848[5734D848,5734D848]
ref=5734D87C[5734D87C,5734D87C] lnd=5734D888[5734D888,5734D888]
LIBRARY OBJECT: object=69e8d9e4
type=TABL flags=EXS/LOC[0005] pflags=[0000] status=VALD load=0
DATA BLOCKS:
data# heap pointer status pins change whr
0 572f55b0 69e8da7c I/-/A/-/- 0 NONE 00
SO: 5C62CA38, type: 53, owner: 5F375F38, flag: INIT/-/-/0x00
LIBRARY OBJECT LOCK: lock=5c62ca38 handle=54e2b2d0 mode=N
call pin=00000000 session pin=00000000 hpc=0000 hlc=0000
htl=5C62CA88[5C7875E0,5C59D458] htb=5C59D458 ssga=5C59CD04
user=5f375f38 session=5f37d6a8 count=1 flags=[0000] savepoint=0x0
LIBRARY OBJECT HANDLE: handle=54e2b2d0 mtx=54E2B384(0) cdp=0
namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=1 hpc=cb1c hlc=cb1c
lwt=54E2B32C[54E2B32C,54E2B32C] ltm=54E2B334[54E2B334,54E2B334]
pwt=54E2B310[54E2B310,54E2B310] ptm=54E2B318[54E2B318,54E2B318]
ref=54E2B34C[66147E34,66147E34] lnd=54E2B358[54E2B358,54E2B358]
LIBRARY OBJECT: object=51e651ac
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
DEPENDENCIES: count=1 size=16
AUTHORIZATIONS: count=1 size=16 minimum entrysize=18
ACCESSES: count=1 size=16
TRANSLATIONS: count=1 size=16
DATA BLOCKS:
data# heap pointer status pins change whr
0 6a86de6c 51e65244 I/P/A/-/- 0 NONE 00
6 66147cdc 9dabe588 I/-/A/-/E 0 NONE 00
SO: 5C787590, type: 53, owner: 5F375F38, flag: INIT/-/-/0x00
LIBRARY OBJECT LOCK: lock=5c787590 handle=57422b64 mode=N
call pin=00000000 session pin=00000000 hpc=0000 hlc=0000
htl=5C7875E0[5C59D458,5C62CA88] htb=5C59D458 ssga=5C59CD04
user=5f375f38 session=5f37d6a8 count=1 flags=[0000] savepoint=0x4bc41571
LIBRARY OBJECT HANDLE: handle=57422b64 mtx=57422C18(2) cdp=2
name=insert into obj$(owner#,name,namespace,obj#,type#,ctime,mtime,stime,status,remoteowner,linkname,subname,dataobj#,flags,oid$,spare1,spare2)values(:1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,:15,:16, :17)
hash=8876f3fed7222711572e6a76e623c9d3 timestamp=04-08-2010 17:06:19
namespace=CRSR flags=RON/KGHP/TIM/PN0/MED/KST/DBN/MTX/[500100d0]
kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=1 hpc=60c0 hlc=60c0
lwt=57422BC0[57422BC0,57422BC0] ltm=57422BC8[57422BC8,57422BC8]
pwt=57422BA4[57422BA4,57422BA4] ptm=57422BAC[57422BAC,57422BAC]
ref=57422BE0[57422BE0,57422BE0] lnd=57422BEC[57422BEC,57422BEC]
LIBRARY OBJECT: object=6a7276e4
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
CHILDREN: size=16
child# table reference handle
0 66148018 66147e34 54e2b2d0
1 66148018 5896c0ec 6af7d37c
DATA BLOCKS:
data# heap pointer status pins change whr
0 696b76e0 6a72777c I/P/A/-/- 0 NONE 00
SO: 5C78B970, type: 53, owner: 5F375F38, flag: INIT/-/-/0x00
LIBRARY OBJECT LOCK: lock=5c78b970 handle=54fbd288 mode=N
call pin=00000000 session pin=00000000 hpc=0000 hlc=0000
htl=5C78B9C0[5C787B90,5C59D1B0] htb=5C59D1B0 ssga=5C59CD04
user=5f375f38 session=5f37d6a8 count=1 flags=[0000] savepoint=0x0
LIBRARY OBJECT HANDLE: handle=54fbd288 mtx=54FBD33C(0) cdp=0
namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=3 hpc=f79a hlc=f79a
lwt=54FBD2E4[54FBD2E4,54FBD2E4] ltm=54FBD2EC[54FBD2EC,54FBD2EC]
pwt=54FBD2C8[54FBD2C8,54FBD2C8] ptm=54FBD2D0[54FBD2D0,54FBD2D0]
ref=54FBD304[5BF92EF0,5BF92EF0] lnd=54FBD310[54FBD310,54FBD310]
LIBRARY OBJECT: object=541e8b98
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
DEPENDENCIES: count=1 size=16
AUTHORIZATIONS: count=1 size=16 minimum entrysize=16
ACCESSES: count=1 size=16
TRANSLATIONS: count=1 size=16
DATA BLOCKS:
data# heap pointer status pins change whr
0 693cb454 541e8c30 I/P/A/-/- 0 NONE 00
6 5bf92e34 a021d62c I/-/A/-/E 0 NONE 00
SO: 5C787B40, type: 53, owner: 5F375F38, flag: INIT/-/-/0x00
LIBRARY OBJECT LOCK: lock=5c787b40 handle=5eb09aec mode=N
call pin=00000000 session pin=00000000 hpc=0000 hlc=0000
htl=5C787B90[5C59D1B0,5C78B9C0] htb=5C59D1B0 ssga=5C59CD04
user=5f375f38 session=5f37d6a8 count=1 flags=[0000] savepoint=0x4bc41571
LIBRARY OBJECT HANDLE: handle=5eb09aec mtx=5EB09BA0(2) cdp=2
name=select o.owner#,o.name,o.namespace,o.remoteowner,o.linkname,o.subname,o.dataobj#,o.flags from obj$ o where o.obj#=:1
hash=ae93e4a5100360375a3ff87632f4667e timestamp=04-02-2010 10:17:58
namespace=CRSR flags=RON/KGHP/TIM/PN0/MED/KST/DBN/MTX/[500100d0]
kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=3 hpc=d23e hlc=d23e
lwt=5EB09B48[5EB09B48,5EB09B48] ltm=5EB09B50[5EB09B50,5EB09B50]
pwt=5EB09B2C[5EB09B2C,5EB09B2C] ptm=5EB09B34[5EB09B34,5EB09B34]
ref=5EB09B68[5EB09B68,5EB09B68] lnd=5EB09B74[5EB09B74,5EB09B74]
LIBRARY OBJECT: object=5bf92fd4
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
CHILDREN: size=16
child# table reference handle
0 5bf92f60 5bf92d7c 5eb099a8
1 5bf92f60 5bf92ef0 54fbd288
2 5bf92f60 5b9aa120 576a80c8
3 5bf92f60 5b9aa284 54f7a6d0
DATA BLOCKS:
data# heap pointer status pins change whr
0 5eb09a7c 5bf9306c I/P/A/-/- 0 NONE 00

Using Global Temporary Table in Discoverer.

Hi All
I am currently working on a Disco report, where I am initializing a package at the disco condition level which inserts data in to a Global Temporary Table.
The global temporary table will be having data based on the parameter entered by the user. But the problem occurs when we are trying to use the same GTT in the select statement as shown below. The desktop is not giving me the otuput but the GTT is getting populated with data.
see below
SELECT bla1,
bla2,
bla3
FROM GTT (global temp table)
WHERE 1= PACKAGE.FUNCTION(par1, par2, par3...) <- here we are trying to insert into GTT based on the paramenters passed.
Can you please suggest how this can be achieved. Or is there any way to trigger the insertion in to GTT other than the calling it in the condition level.
Thanks
Arun

Hi,
You cannot use a GTT like this because you cannot write and read from the GTT using a single SQL statement. You must either have the insert in a separate worksheet and tell the users to run this worksheet first, or you wrap it all up in a table function called from within a view. The table function can then insert and select from the GTT using two statements.
Which method is best depends on what you are trying to do and why you want to use a GTT.
Rod West

Global Temporary table and REDO

Dear Friends,
In my production database we are facing problem of excessive redo generation. After initial analysis, we realised that we are using a lot global temporary tables for storing temp data/calculations and they are generating redo.
I know that GTT doesn’t create redo but as it creates UNDO and undo is protected by redo therefore it creates some redo but lesser than normal table.
Solution:
I google and found that if I use direct path insertion (using APPEND hint) into Global temporary table the I can avoid this redo generation as specified in this link (http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:15826034070548)
I tried this solution in my GTT but its not making any difference with APPEND clause. Please check following results. Could you please guide me if I am doing something wrong or any other way to avoid redo on GTT.
JM@ORA10G>insert into JM_temp values(1,'aaaaaaaaaaaaaaaaaaaaaaa');
1 row created.
Elapsed: 00:00:00.00
Execution Plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | INSERT STATEMENT | | 1 | 100 | 1 (0)| 00:00:01 |
Statistics
0 recursive calls
2 db block gets
1 consistent gets
0 physical reads
*280 redo size*
918 bytes sent via SQL*Net to client
967 bytes received via SQL*Net from client
6 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed
JM@ORA10G>rollback ;
Rollback complete.
JM@ORA10G>insert * into JM_temp values(1,'aaaaaaaaaaaaaaaaaaaaaaa');
1 row created.
Elapsed: 00:00:00.00
Execution Plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | INSERT STATEMENT | | 1 | 100 | 1 (0)| 00:00:01 |
Statistics
0 recursive calls
2 db block gets
1 consistent gets
0 physical reads
*280 redo size*
917 bytes sent via SQL*Net to client
981 bytes received via SQL*Net from client
6 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed

Hi,
I tried avoiding GTT in my code but I realised that they are so tightly integrated that i cannot remove them. Operations which I am perfroming on my GTT are
1. Insertion of data
2. Fetch data from main tables with joins on GTT
3. Update GTT with calculated values.
My understanding it Update steps are generating maximum redo.
Please help me how can i reduce my redo generation in such scenarios.
Thanks.

Global temporary table screwing up execution plan

Hello
I have a process I'm trying to optimise. The first part of the process opens a cursor, bulk collects, and then inserts the data into a table using FORALL. The next part uses another FORALL statement to insert into another table, using 4 of those collections populated by the bulk collect to control a select statement i.e.
FORALL i IN 1..Collection1.COUNT
    INSERT
    INTO
         table
    SELECT
         t1.col1,
         t2.col2,
         t3.col3,
         Collection4(i)
    FROM
       table1 t1,
       table2 t2,
       table3 t3
    WHERE
       t1.pk = Collection1(i)
    AND
       t2.fk = t1.pk
    AND
       t3.fk = t1.pk;This statement is executed 50k+ times and takes about an hour. The execution plan for the select is fine, the time is just down to the number of itterations. Anyway, to try and make this quicker, I created a global temporary table to store the contents of the collections of interest, and then in a new cursor using the above select (replacing the collections with the columns in the temporary table), I bulk collect that into new collections and do the inserts. The problem is, that the optimiser assumes that the temporary table has 2 million+ rows in it for some strange reason, and so this completely changes the executions plan to give a cost of 180k! I can't analyze a temporary table so does anyone have an idea as to what I can do to make this work and bring the cost down to something more reasonable? Maybe an alternative strategy?
Cheers

<<I can't analyze a temporary table>>
What version of Oracle do you use?
SQL> create global temporary table mytable(col1 number,
2 col2 date) on commit preserve rows;
Table created.
SQL> begin
2 for i in 1..1000 loop
3 insert into mytable values(i,sysdate);
4 end loop;
5 end;
6 /
PL/SQL procedure successfully completed.
SQL> select count(1) from mytable;
COUNT(1)
      1000
SQL> set autot traceonly
SQL> select count(1) from mytable;
Execution Plan
   0      SELECT STATEMENT Optimizer=RULE
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'MYTABLE'
Statistics
          0 recursive calls
          0 db block gets
          5 consistent gets
          0 physical reads
          0 redo size
        199 bytes sent via SQL*Net to client
        277 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> ALTER SESSION SET OPTIMIZER_GOAL = ALL_ROWS;
Session altered.
SQL> select count(1) from mytable;
Execution Plan
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=11 Card=1)
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'MYTABLE' (Cost=11 Card=8168)
Statistics
          5 recursive calls
          0 db block gets
         10 consistent gets
          0 physical reads
          0 redo size
        211 bytes sent via SQL*Net to client
        277 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          2 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL>
SQL> ANALYZE TABLE MYTABLE COMPUTE STATISTICS;
Table analyzed.
SQL> select count(1) from mytable;
Execution Plan
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1)
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'MYTABLE' (Cost=2 Card=1000)
Statistics
          0 recursive calls
          0 db block gets
          5 consistent gets
          0 physical reads
          0 redo size
        210 bytes sent via SQL*Net to client
        277 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> disconnect
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.3.0 - 64bit Production
With the Partitioning option
JServer Release 9.2.0.3.0 - Production

Global Temporary Table - Nulls Returned.

Hello,
I have written a search, which has one text box and scans across many different fields in a table. If you have multiple search terms separated by commas, I look for the results to have BOTH. The same would apply for even more search terms.
To accomplish this I do the following:
-- 1.) split the string with function, receive array of search terms.
-- 2.) LOOP: Open Loop and move to first element of Array.
-- 3.) find individual term (array element) in table (fields in question use CONTEXT indexing).
-- 4.) Place list of results (PK) into Global Temporary table.
-- 5.) Move to next array position.
-- 6.) Repeat steps 3,4,5 until array is exhausted
-- 7.) END LOOP:
-- 8.) select PK list having COUNT(*) = # of terms in array.
-- 9.) Select data from main table where pk in (list of terms from temp table).
The procedure works fine in PL/SQL Developer and Toad. The results are reliable and accurate.
When we try to run this through JDeveloper - we have problems. Either we get a return set of "NULL", or we get odd results that imply that the search has run through only one term of the two.
We have researched this and setAutoCommit off.
I am reaching out for suggestions on additional things which might be interfering with the Java connection, before I attempt to place a support call to Oracle.

Not sure were can help you as this its a complicated use case which can't be rebuild easily by us.
Still, you should medium your jdev version and how you call the pl /sql function which produces three results in the global Temp table.
Can you please explain when exactly you get null or funny results?
I have worked with temp take a while back and had no such issues.
Timo

Use of global temporary tables in Procedures

Hi
I am using global temporary tables in the procedures. Loading data in the same table through many procedures. I am fetching the data from the global temporary table in PRO-C by a cursor. Will this degrade performance?
Please help me..
Thanks in Advance...

Will this degrade performance?That depends... in comparison to what?
Loading data into temporary tables will generally be more efficient than loading data into permanent tables because Oracle needs to do less to protect this data since it is inherently transient. On the other hand, loading the data into a table in the first place tends to be more expensive than alternatives like using a single SQL statement, a pipelined table function, or an in memory collection.
Justin

Global temporary table in PL/SQL called from APEX page

Similar Messages

Maybe you are looking for