How to stop bitmap conversion

Question

Hi All,
Here is the situation.
To get the reports one global temporary table has been created.
Whenever reports has to generate
1) It first insert records into temporary table from multiple tables based on select statement (here global temporary table is not analyzed after the inserts of millions records)
Insert into temp_table (select * from table_a,table_b where <condition) ;
number of records in temp_table = 5-10 millions
2) Now the reports are being generated with select statement that uses temporary table along with other table
Select <column_list> from temp_table , table_c where <some_condition>;
If I check the execution plan it includes bitmap conversion from row_id and to_id.
ID PARENT OPERATION OBJECT_NAME
0 SELECT STATEMENT
1 0 TABLE ACCESS BY INDEX ROWID LXRO_685993E3
2 1 NESTED LOOPS
3 2 INDEX FULL SCAN MXTEMPOID_MXOID_MXINDEX
4 2 BITMAP CONVERSION TO ROWIDS
5 4 BITMAP AND
6 5 BITMAP CONVERSION FROM ROWIDS
7 6 INDEX RANGE SCAN LXRO_685993E3_LXFROMLAT_INDEX
8 5 BITMAP CONVERSION FROM ROWIDS
9 8 INDEX RANGE SCAN LXRO_685993E3_LXTYPE_INDEX
To execute this query it takes long time compare to non bitmap conversion.
3) Whenevr I gather stats on the temp_table and see the new execution plan look like following (no bitmap conversion). Gathering stats only affect the subsequent queries not the current query which is running with bitmap conversion. Here I want to stop the bitmap conversion for the current query. I mean before it picks up the execution plan with bitmap conversion
ID PARENT OPERATION OBJECT_NAME
0 SELECT STATEMENT
1 0 TABLE ACCESS BY INDEX ROWID LXRO_685993E3
2 1 NESTED LOOPS
3 2 INDEX SKIP SCAN MXTEMPOID_MXOID_MXINDEX
4 2 INDEX RANGE SCAN LXRO_685993E3_TYPFLATFID_INDEX
4) Please explain how can I stop the bitmap conversion happening in execution plan. (had it been permanent table once the stats gathering is enough but as its temporary table)
5) after the report generation records from the temp tables are deleted immediately.
Thank you
-Anurag

Answer 1

user635138 wrote:
Hi Jonathan,
a) table is created as "on commit delete rows" (the default)
b) user is getting rid of the temporary data by deleting it,Not related to the index issue, but with "on commit delete rows", the users don't need to delete the GTT data, they can simply issue a "commit;" and their data will disappear. It's possible, of course, that the 3rd party application won't let you do this.
c) everyone who uses this table insert different volumes of data from different different select queriesSo we need to know if there are any statst generated at any time - perhaps by program, possibly by dynamic_sampling, that could cause plans to change when cursors were invalidated. Your early posts mentioned gathering stats on the GTT - but if you use any of the normal collection method with an "on commit delete rows" table, you should get stats showing no data in the table, and that is likely to affect the execution plan. What method are you using to generate the plan, by the way ?
d) What indexes exist on this table. for this see the syntax of table and index. it might help to come to solution
My mistake - I should have noticed that the bitmap conversion was happening on the other table, not the GTT. This suggests that you may need to consider the two-column index as a solution to the problem - but before you do that, take a look at the queries and data. You say that you get 5M to 10M rows in the GTT: that's quite a lot of "temporary" data - without looking at what the optimizer suggests, can you work out a sensible execution path for the query.
In passing - you have "conditions" in the where clause, but how variable are these, and are they only join coniditions or do you also have some flitering conditions on the non-GTT.
>
More over user executes MQL statement (this MQL is converted to SQL internally then comes on database) I have very little knowledge of MQl, don't know what change has to be made into MQL to add hints in SQL statement. no control over SQL. so only thing is, Is there any way to gather stats on table before report generation.
If you can load a real table with representative data, you could generate stats for it, then transfer the stats to the GTT. Another option - with the limitations of the dynamic_sampling hint - is to set the parameter optimizer_dynamic_sampling to the value 2, which will tell the optimizer to sample a few blocks from every table that has no stats (and this includes GTTs automatically). If you try this, remember that you seem to have collected zero stats on the GTT, so you may have to delete these before Oracle samples the table.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan