Auditing data from global temporary table

Question

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

Answer 1

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