Query hangs with outer query

Question

Hi,
OS: SPARC 64 bit
Oracle Version: 10.2.0.3.0 64 bit
My query hangs when I include the outer query. When I execute without outer query It comes out in a fraction of second but when I includes outer query it starts hang
Below is my original query which hangs
select * from (select raw_sql_.**, rownum raw_rnum_ from (SELECT /*+ FIRST_ROWS */ NETWORK_ID||'","'||CALLER_NUMBER||'","'||CALLED_NUMBER FROM CDR FROM CDR WHERE 1 = 1
AND day_of_year = 99 AND INTERFACE = 'TRAFIC' AND TIME_STAMP BETWEEN to_date('2009/04/08 00:00:00','yyyy/mm/dd hh24:mi:ss') AND to_date
('2009/04/09 00:00:00','yyyy/mm/dd hh24:mi:ss') AND NETWORK_ID IN (1025,1026) order by id desc) raw_sql_ WHERE rownum <= 10000) WHERE raw_rnum_ > 0;
when I execute this it will come out immediately
select raw_sql_.**, rownum raw_rnum_ from (SELECT /*+ FIRST_ROWS */ NETWORK_ID||'","'||CALLER_NUMBER||'","'||CALLED_NUMBER FROM CDR FROM CDR WHERE 1 = 1
AND day_of_year = 99 AND INTERFACE = 'TRAFIC' AND TIME_STAMP BETWEEN to_date('2009/04/08 00:00:00','yyyy/mm/dd hh24:mi:ss') AND to_date
('2009/04/09 00:00:00','yyyy/mm/dd hh24:mi:ss') AND NETWORK_ID IN (1025,1026) order by id desc) raw_sql_ WHERE rownum <= 10000
select * from (select raw_sql_.**, rownum raw_rnum_ from (SELECT /*+ FIRST_ROWS */ NETWORK_ID||'","'||CALLER_NUMBER||'","'||CALLED_NUMBER FROM CDR FROM CDR WHERE 1 = 1
AND day_of_year = 99 AND INTERFACE = 'TRAFIC' AND TIME_STAMP BETWEEN to_date('2009/04/08 00:00:00','yyyy/mm/dd hh24:mi:ss') AND to_date
('2009/04/09 00:00:00','yyyy/mm/dd hh24:mi:ss') AND NETWORK_ID IN (1025,1026) order by id desc) raw_sql_ WHERE rownum <= 10000) WHERE raw_rnum_ > 0;
but when I includes outer query I hangs it is really very weird for me?
Here is the explain plan for that query
Execution Plan
Plan hash value: 3493649369
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 2015 | 1 (0)| 00:00:01 | | |
|* 1 | VIEW | | 1 | 2015 | 1 (0)| 00:00:01 | | |
|* 2 | COUNT STOPKEY | | | | | | | |
| 3 | PARTITION RANGE SINGLE | | 1 | 5894 | 1 (0)| 00:00:01 | 99 | 99 |
| 4 | PARTITION LIST ALL | | 1 | 5894 | 1 (0)| 00:00:01 | 1 | 48 |
|* 5 | TABLE ACCESS BY LOCAL INDEX ROWID| CDR | 1 | 5894 | 1 (0)| 00:00:01 | 4705 | 4752 |
| 6 | BITMAP CONVERSION TO ROWIDS | | | | | | | |
|* 7 | BITMAP INDEX SINGLE VALUE | IX_CDR_INTERFACE | | | | | 4705 | 4752 |
Predicate Information (identified by operation id):
1 - filter("RAW_RNUM_">0)
2 - filter(ROWNUM<=10000)
5 - filter("DAY_OF_YEAR"=99 AND "TIME_STAMP">=TO_DATE('2009-04-08 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND
"TIME_STAMP"<=TO_DATE('2009-04-09 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND ("NETWORK_ID"=1025 OR
"NETWORK_ID"=1026))
7 - access("INTERFACE"='TRAFIC')
can one explain why it happen? what could be the reason? Is it a bug or something? what should I do now? Issue is critical in the production enviromentent
Waiting for your Valuable Reply
Thanks In Advance
With Regards
Boo

Answer 1

user454189 wrote:
I suspect the issue with the where clause (raw_rnum_ > 0)
Actually I using bitmap index on ' INTERFACE' column. Does it causing a prob or raw_rnum_ causing a problem?Boo,
a couple of comments:
1. Why do you use the deprecated FIRST_ROWS hint? From 9i on the FIRST_ROWS_n mode should be used instead, and since you're using a top-N query format the hint should be superfluous anyway since the optimizer should switch to FIRST_ROWS_n mode automatically.
2. Why do you use a BITMAP index and not a conventional b*tree index? Let me hazard a guess: Because the INTERFACE column has a small number of distinct values? That would be in most cases a bad idea.
3. What seems to be odd that you're accessing the data via the BITMAP index on INTERFACE, but request an ORDER BY ID DESC. But there is no order by in the execution plan posted. I wonder where the order should come from? Can you show us the DDL of the bitmap index?
4. What does the plan look like if you run only the inner query without the outer query?
You can always gain more information by tracing the statement execution or using the GATHER_PLAN_STATISTICS hint together with the DBMS_XPLAN.DISPLAY_CURSOR function.
Please read this HOW TO: Post a SQL statement tuning request - template posting that explains what you should provide if you have SQL statement tuning question and how to format it here so that the posted information is readable by others.
This accompanying blog post shows step-by-step instructions how to obtain that information.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/