Oracle 11.2 slow with range scan
L.S.,
I have an issue with performance with select.
The select only selects 40 objects via index. The table is generated by SAP, but in customer namespace.
With ST05 the explain shows:
SELECT
FROM
"ZCSNN_CAS"
WHERE
"MANDT" = :A0 AND "BUSOBJ_TYPE" = :A1 AND "BUSOBJ_ID" IN ( :A2 , :A3 , :A4 , :A5 , :A6 , :A7 ,
:A8 , :A9 , :A10 , :A11 , :A12 , :A13 , :A14 , :A15 , :A16 , :A17 , :A18 , :A19 , :A20 , :A21 ,
:A22 , :A23 , :A24 , :A25 , :A26 , :A27 , :A28 , :A29 , :A30 , :A31 , :A32 , :A33 ) AND
"BUSOBJ_VERSDATE" >= :A34 AND "STATUS_VERSION" = :A35 AND "STATUS_WORK" = :A36 AND
"FLG_CANCEL_VERS" = :A37 AND "FLG_CANCEL_OBJ" <> :A38
The execution plan is:
SELECT STATEMENT ( Estimated Costs = 68 , Estimated #Rows = 4 )
3 INLIST ITERATOR
2 TABLE ACCESS BY INDEX ROWID ZCSNN_CAS
( Estim. Costs = 67 , Estim. #Rows = 4 )
Estim. CPU-Costs = 735.327 Estim. IO-Costs = 67
Filter Predicates
1 INDEX RANGE SCAN ZCSNN_CAS~Z02
( Estim. Costs = 7 , Estim. #Rows = 316 )
Search Columns: 3
Estim. CPU-Costs = 213.909 Estim. IO-Costs = 7
Access Predicates Filter Predicates
Then then following fetches show long runtimes:
Runtime Object Operation Returncode
329 ZCSNN_CAS PREPARE 0
2 ZCSNN_CAS OPEN 0
150.678 ZCSNN_CAS FETCH 46 0
194.637 ZCSNN_CAS FETCH 46 0
157.639 ZCSNN_CAS FETCH 46 0
12.707 ZCSNN_CAS FETCH 46 0
90.340 ZCSNN_CAS FETCH 46 0
138.845 ZCSNN_CAS FETCH 46 0
49.715 ZCSNN_CAS FETCH 46 0
137.186 ZCSNN_CAS FETCH 46 0
204.770 ZCSNN_CAS FETCH 46 0
339.622 ZCSNN_CAS FETCH 46 0
173.157 ZCSNN_CAS FETCH 14 1403
To me it looks like an Oracle issue? Changes in the ABAP-code did not help.
Can Oracle be tweaked?
Regards,
Walter
First of all, thanks for all the responses!
Below the requested data for starters!
Table ZCSNN_ACT
Last statistics date 05.12.2011
Analyze Method Sample 344.222 Rows
Number of rows 34.422.200
Number of blocks allocated 416.900
Number of empty blocks 0
Average space 0
Chain count 0
Average row length 82
Partitioned NO
UNIQUE Index ZCSNN_ACT~0
Column Name
#Distinct
MANDT
1
IMPORT_YEAR
9
CASE_ID
2.459.014
CASE_VERS
3
ACT_POS
30
Last statistics date 05.12.2011
Analyze Method Sample 362.683 Rows
Levels of B-Tree 3
Number of leaf blocks 294.140
Number of distinct keys 36.268.300
Average leaf blocks per key 1
Average data blocks per key 1
Clustering factor 8.322.500
Similar Messages
-
Oracle Forms loading slower with Sun JRE in Oracle E-Business Suite 11i
Hi,
After Deploying Sun JRE (Native Plug-in) for Windows Clients in Oracle E-Business Suite 11i (Note 290807.1) we find that Oracle Forms are loading slower than using Jinitiator.
Also the PDF reports are opening in a minimized fashion. Meaning the PDF reports are opening correctly in new browser window (as expected) but is minimized.
Customer is not willing to go live with Sun JRE due to these issues.
Plz advice is there is any additional configuration I need to do.
Rgds,
ThiruWhen the JRE was installed/configured on the workstations was the jar cache placed on a LAN drive instead of the local drive? We have experienced poor performance with both the JRE and Jinitiator when the Workstation Sysadmins configured the jar cache to be located on a LAN drive. Also is the size of the jar cache on the workstation sufficient to hold all of your required jar files. It could be downloading the jar files all the time.
Overall our performance with the JRE is comparible to the Jinitiator.
Sorry I have not experienced the problem that you are having with you pdf reports so I can't provide any comments on it. -
Issues with reverse key indexes and range scan
I have a question. Why is it that reverse key indexes do not work in a range scan?
ThanksChris, well said in simple terms.
Extract from metalink:
Oracle8 provides the ability to create reverse key indexes. Reverse key indexes
reverse the bytes of each indexed column with the exception of ROWID and still
maintains the column order. Reverse key indexes are useful for Oracle Parallel
Server environments.
In an OPS environment, modifications to indexes are focused on a small
set of leaf blocks. Reversing the keys of the index allows insertions to be
distributed across all the leaf keys in the index. Reverse key indexes prevent
queries from performing an index range scan since lexically adjacent keys
are not stored next to each other. Reverse key indexes can also be used in
situations where users insert ascending values and delete lower values from the
table, thus helping to prevent skewed indexes.
===
Good discussion at
http://asktom.oracle.com/pls/ask/f?p=4950:8:2737861489787945222::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:627823669999
http://asktom.oracle.com/pls/ask/f?p=4950:8:2737861489787945222::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:6163160472530
Jaffar
Message was edited by:
The Human Fly -
Scanning VERY slow with HP C4380 via WiFi
Hi there,
Since leopard (now 10.6.3) scanning is really terribly slow with my C4380 via WiFi, it actually takes about an hour (NO JOKE) to scan a page on 600dpi. WHAT THE HECK IS WRONG.
Can't find any solution anywhere..., drives me mad, help me out pls!
DanielGo into your computer and see what the Wireless Network Settings such as Security Type (WPA, WPA2, WEP etc), Data Encryption (AES, PSK, TKIP etc) and what mode is the router using 802.11 d, g or n. PlayBook prefers WPA or WPA2, AES Encryption, Mode g. It does not support Mode n with TKIP. Also try a reboot of your router.
On your PB tap the wifi icon, tap connect manually, enter the same Security type setting as in the router, select dual band, check auto obtain IP Address, check Allow Inter Access Point Handover and enter the network key. Reboot the PB .Try these suggestings and report back. -
Why is Oracle Response time getting slow with time.
Hi,
I have DB which was very fast initially with the response time for one of the query < 5 sec.
I have been using the DB for the last 15 days. Now the same query is taking 10 minutes. In the DB there are lot of operations of additions and deletions been done on the table where the query is being made. The no. of records in the table is constant at around 3 million records from the first day.
If I import the DB into a new setup then again the response time becomes very good in the new setup.
What should be the problem of the DB getting slow with the time.
Thanks,
TuhinIt all depends on several factors.
Are your tables,indexes have upto-date statistics?
I have DB which was very fast initially with the response time for one of the query < 5 sec. Initially there might be small amount of data later data might have increased,you dont have proper indexes.
It could be that your indexes got fragmented to due to heavey deletes? It might need reorg.
My suggestion would to look into your execution plan of the quries and see where your kernals are waiting.
As other suggested you, use explain plan, event 10046 and tkprof.
Jaffar -
I have a problem with full table scans that make very slow the performance of a report.
The test case is below. It looks that when the column is called from the table, the index is in use. If I use the same select from the view, then I get a table scan.
I would appreciate any idea on how to optimize it.
Thanks a lot for the help.
mj
<pre>
create table test1 (id1 number , id2 number, id3 number, col1 varchar(10),col2 varchar(50), col3 varchar(100));
create table test2 (id4 number , id5 number, id6 number, col4 varchar(10),col5 varchar(50), col6 varchar(100));
ALTER TABLE test1 ADD CONSTRAINT PK_test1 PRIMARY KEY(ID1) USING INDEX REVERSE;
create index index1 on test1(ID2);
create index index2 on test1(ID3,col2 );
ALTER TABLE test2 ADD CONSTRAINT PK_test2 PRIMARY KEY(ID4) USING INDEX REVERSE;
create or replace view test_view as select t1.*,
case (select t2.id4 from test2 t2 where t1.id2 = t2.id5 and t2.id6 = -1)
when t1.id2 then t1.id3
else t1.id2
end as main_id
from test1 t1 ;
create or replace view test_view2 as select * from test_view; --(requred by security levels)
select * from test1 where id2 =1000;
select * from test_view where id2 = 1000;
select * from test_view2 where id2 = 1000;
SQL> select * from test_view where id2 = 1000;
Elapsed: 00:00:00.00
Execution Plan
Plan hash value: 1970977999
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 125 | 1 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL | TEST2 | 1 | 39 | 2 (0)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| TEST1 | 1 | 125 | 1 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | INDEX1 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("T2"."ID5"=:B1 AND "T2"."ID6"=(-1))
3 - access("T1"."ID2"=1000)
SQL> select * from test_view where main_id = 1000;
Elapsed: 00:00:00.03
Execution Plan
Plan hash value: 3806368241
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 125 | 4 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL | TEST2 | 1 | 39 | 2 (0)| 00:00:01 |
|* 2 | FILTER | | | | | |
| 3 | TABLE ACCESS FULL| TEST1 | 1 | 125 | 2 (0)| 00:00:01 |
|* 4 | TABLE ACCESS FULL| TEST2 | 1 | 39 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("T2"."ID5"=:B1 AND "T2"."ID6"=(-1))
2 - filter(CASE WHEN "T1"."ID2"= (SELECT /*+ */ "T2"."ID4" FROM
MJ42."TEST2" "T2" WHERE "T2"."ID5"=:B1 AND "T2"."ID6"=(-1)) THEN
"T1"."ID3" ELSE "T1"."ID2" END =1000)
4 - filter("T2"."ID5"=:B1 AND "T2"."ID6"=(-1))
SQL>
</pre>If you think about what the two queries are doing, it is easy to see why the first uses an index and the second does not.
Your first query:
SELECT * FROM test_view WHERE id2 = 1000explicitly uses an indexed column from test1 in the predicate. Oracle can use the index to identify the correct row from test1. Having found that single row in test1, it uses the FULL SCAN test2 to resolve the case statement.
Your second query:
SELECT * FROM test_view WHERE main_id = 1000uses the result of the case statement as the predicate. Oracle has no way of determing what row from test1 to use initially, so it must full scan both tables.
John -
I have 2 queries that I do an "union all" and then an order by after the "union all" This seems to be extremely slow. But when I run the queries individually, they are really fast. Could some help me out with this please.
SELECT *
FROM (SELECT a.*, ROWNUM rnum
FROM (SELECT COLS......
FROM (((SELECT from tables with joins)
UNION ALL
(SELECT from tables and view with joins))
order by colname)
) a
WHERE ROWNUM <= 500)
WHERE rnum >= 1
PLAN_TABLE_OUTPUT
Plan hash value: 3988534528
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 500 | 1600K| | 3634M (1)|999:59:59 | | |
|* 1 | VIEW | | 500 | 1600K| | 3634M (1)|999:59:59 | | |
|* 2 | COUNT STOPKEY | | | | | | | | |
| 3 | VIEW | | 4277K| 13G| | 3634M (1)|999:59:59 | | |
|* 4 | SORT ORDER BY STOPKEY | | 4277K| 311M| 1095M| 3634M (1)|999:59:59 | | |
| 5 | UNION-ALL | | | | | | | | |
PLAN_TABLE_OUTPUT
|* 6 | FILTER | | | | | | | | |
|* 7 | HASH JOIN | | 212K| 15M| | 153K (1)| 00:03:37 | | |
|* 8 | HASH JOIN RIGHT OUTER | | 507 | 22308 | | 6 (17)| 00:00:01 | | |
| 9 | TABLE ACCESS FULL | DIR | 143 | 3861 | | 2 (0)| 00:00:01 | | |
| 10 | TABLE ACCESS FULL | USER | 507 | 8619 | | 3 (0)| 00:00:01 | | |
| 11 | PARTITION RANGE ITERATOR | | 212K| 6645K| | 153K (1)| 00:03:37 | KEY | KEY |
| 12 | TABLE ACCESS BY LOCAL INDEX ROWID | FL | 212K| 6645K| | 153K (1)| 00:03:37 | KEY | KEY |
|* 13 | INDEX RANGE SCAN | I_FL_ID | 382K| | | 38943 (2)| 00:00:56 | KEY | KEY |
|* 14 | COUNT STOPKEY | | | | | | | | |
|* 15 | FILTER | | | | | | | | |
| 16 | PARTITION RANGE ITERATOR | | 1 | 22 | | 856 (1)| 00:00:02 | KEY | KEY |
PLAN_TABLE_OUTPUT
|* 17 | TABLE ACCESS BY LOCAL INDEX ROWID| PAY | 1 | 22 | | 856 (1)| 00:00:02 | KEY | KEY |
|* 18 | INDEX RANGE SCAN | I_PAY_FLID | 1 | | | 855 (1)| 00:00:02 | KEY | KEY |
|* 19 | FILTER | | | | | | | | |
|* 20 | HASH JOIN RIGHT OUTER | | 25019 | 3029K| | 138K (1)| 00:03:17 | | |
| 21 | TABLE ACCESS FULL | DIR | 143 | 3861 | | 2 (0)| 00:00:01 | | |
|* 22 | HASH JOIN | | 25019 | 2369K| | 138K (1)| 00:03:17 | | |
| 23 | TABLE ACCESS FULL | USER | 507 | 8619 | | 3 (0)| 00:00:01 | | |
|* 24 | HASH JOIN | | 25019 | 1954K| | 138K (1)| 00:03:17 | | |
| 25 | INDEX FULL SCAN | PK_HO | 278 | 1112 | | 1 (0)| 00:00:01 | | |
|* 26 | HASH JOIN | | 25019 | 1856K| | 138K (1)| 00:03:17 | | |
| 27 | INDEX FULL SCAN | PK_HO | 278 | 1112 | | 1 (0)| 00:00:01 | | |
PLAN_TABLE_OUTPUT
| 28 | NESTED LOOPS | | 25019 | 1759K| | 138K (1)| 00:03:17 | | |
| 29 | PARTITION RANGE ITERATOR | | 25018 | 830K| | 63575 (1)| 00:01:30 | KEY | KEY |
|* 30 | TABLE ACCESS BY LOCAL INDEX ROWID | PAY | 25018 | 830K| | 63575 (1)| 00:01:30 | KEY | KEY |
|* 31 | INDEX RANGE SCAN | I_PAY_TIME_ID | 1493K| | | 9052 (2)| 00:00:13 | KEY | KEY |
|* 32 | TABLE ACCESS BY GLOBAL INDEX ROWID | FL | 1 | 38 | | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 33 | INDEX UNIQUE SCAN | PK_FL | 1 | | | 2 (0)| 00:00:01 | | |
SELECT *
FROM (SELECT a.*, ROWNUM rnum
FROM ( SELECT from tables with joins order by colname) a
WHERE ROWNUM <= 500)
WHERE rnum >= 1
PLAN_TABLE_OUTPUT
Plan hash value: 3503998222
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 500 | 1228K| 222K (1)| 00:05:15 | | |
|* 1 | VIEW | | 500 | 1228K| 222K (1)| 00:05:15 | | |
|* 2 | COUNT STOPKEY | | | | | | | |
| 3 | VIEW | | 520 | 1271K| 222K (1)| 00:05:15 | | |
|* 4 | FILTER | | | | | | | |
| 5 | NESTED LOOPS OUTER | | 26 | 1976 | 54 (0)| 00:00:01 | | |
PLAN_TABLE_OUTPUT
| 6 | NESTED LOOPS | | 26 | 1274 | 48 (0)| 00:00:01 | | |
| 7 | PARTITION RANGE ITERATOR | | 212K| 6645K| 22 (0)| 00:00:01 | KEY | KEY |
| 8 | TABLE ACCESS BY LOCAL INDEX ROWID | FL | 212K| 6645K| 22 (0)| 00:00:01 | KEY | KEY |
|* 9 | INDEX RANGE SCAN | I_FL_START_ID | 47 | | 8 (0)| 00:00:01 | KEY | KEY |
|* 10 | COUNT STOPKEY | | | | | | | |
|* 11 | FILTER | | | | | | | |
| 12 | PARTITION RANGE ITERATOR | | 1 | 22 | 856 (1)| 00:00:02 | KEY | KEY |
|* 13 | TABLE ACCESS BY LOCAL INDEX ROWID| PAY | 1 | 22 | 856 (1)| 00:00:02 | KEY | KEY |
|* 14 | INDEX RANGE SCAN | I_PAY_ID | 1 | | 855 (1)| 00:00:02 | KEY | KEY |
| 15 | TABLE ACCESS BY INDEX ROWID | USER | 1 | 17 | 1 (0)| 00:00:01 | | |
|* 16 | INDEX UNIQUE SCAN | PK_USER | 1 | | 0 (0)| 00:00:01 | | |
PLAN_TABLE_OUTPUT
| 17 | TABLE ACCESS BY INDEX ROWID | DIR | 1 | 27 | 1 (0)| 00:00:01 | | |
|* 18 | INDEX UNIQUE SCAN | PK_DIR | 1 | | 0 (0)| 00:00:01 | | |
SELECT *
FROM (SELECT a.*, ROWNUM rnum
FROM ( SELECT from tables and view with joins order by colname) a
WHERE ROWNUM <= 500)
WHERE rnum >= 1
PLAN_TABLE_OUTPUT
Plan hash value: 1786470271
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 500 | 1600K| 1696 (1)| 00:00:03 | | |
|* 1 | VIEW | | 500 | 1600K| 1696 (1)| 00:00:03 | | |
|* 2 | COUNT STOPKEY | | | | | | | |
| 3 | VIEW | | 501 | 1596K| 1696 (1)| 00:00:03 | | |
|* 4 | FILTER | | | | | | | |
| 5 | NESTED LOOPS | | 501 | 60120 | 1696 (1)| 00:00:03 | | |
PLAN_TABLE_OUTPUT
| 6 | NESTED LOOPS | | 501 | 58116 | 1696 (1)| 00:00:03 | | |
| 7 | NESTED LOOPS OUTER | | 501 | 56112 | 1695 (1)| 00:00:03 | | |
| 8 | NESTED LOOPS | | 501 | 42585 | 1689 (1)| 00:00:03 | | |
| 9 | NESTED LOOPS | | 501 | 34068 | 1550 (1)| 00:00:03 | | |
| 10 | PARTITION RANGE ITERATOR | | 829K| 23M| 42 (0)| 00:00:01 | KEY | KEY |
| 11 | TABLE ACCESS BY LOCAL INDEX ROWID| PAY | 829K| 23M| 42 (0)| 00:00:01 | KEY | KEY |
|* 12 | INDEX RANGE SCAN | I_PAY_TIME_ID | 902 | | 9 (0)| 00:00:01 | KEY | KEY |
|* 13 | TABLE ACCESS BY GLOBAL INDEX ROWID| FL | 1 | 38 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 14 | INDEX UNIQUE SCAN | PK_FL | 1 | | 2 (0)| 00:00:01 | | |
| 15 | TABLE ACCESS BY INDEX ROWID | USER | 1 | 17 | 1 (0)| 00:00:01 | | |
|* 16 | INDEX UNIQUE SCAN | PK_USER | 1 | | 0 (0)| 00:00:01 | | |
PLAN_TABLE_OUTPUT
| 17 | TABLE ACCESS BY INDEX ROWID | DIR | 1 | 27 | 1 (0)| 00:00:01 | | |
|* 18 | INDEX UNIQUE SCAN | PK_DIR | 1 | | 0 (0)| 00:00:01 | | |
|* 19 | INDEX UNIQUE SCAN | PK_HO | 1 | 4 | 0 (0)| 00:00:01 | | |
|* 20 | INDEX UNIQUE SCAN | PK_HO | 1 | 4 | 0 (0)| 00:00:01 | | |
---------------------------------------------------------------------------------------------------------------------------------------------Can you limit the number of rows coming out of each part of the UNION ALL before limiting the number of rows you're trying to return? So that you end up with something like
SELECT *
FROM (<<Get first 500 rows from first query>>
UNION ALL
<<Get first 500 rows from second query>>)
WHERE rownum <= 500It appears from the query plan that your problem is that Oracle is sorting the entire result of the UNION ALL before finding the first 500 rows. That's obviously rather time consuming since the two queries return 10's of GB of data. Individually, the two queries are fast because you're limiting each of them to 500 rows, so Oracle can do a quick index scan (presumably on the sort column) that would find those rows.
And depending on what's behind the queries, I'd look to see whether you can put some additional filter conditions in place to look for data with dates in the past day or two in order to at least limit the worst case if Oracle does have to sort everything.
Justin -
Same table, Oracle 5 times slower than MySQL
Hi
I have several sites with the same aplication using a database as a log device and to later retrieve reports from. Some tables are for setup and one are for all the log data. The log data table has the following columns: LINEID, TAG, DATE_, HOUR_, VALUE, TIME_ and CHANGED. Typical data is: 122345, PA01_FT1_ACC, 2008-08-01, 10, 985642, "", 0.
Index (TAG,DATE_)
When calling a report the software querys for typical 3-5 select querys like the following, only different TAG: SELECT * FROM table WHERE TAG='PA01_FT1_ACC' AND DATE_ BETWEEN '2008-08-01' AND '2008-08-31' AND HOUR_=24
Since our customers have different preferences some sites have Oracle and some have MySQL. And I have registered that the sites running Oracle uses 24-30 sec on the report, MySQL uses 3-6 sec on a similar report with the same tables and querying software.
How is this?
Is there anything I can do to make Oracle work faster?
Should HOUR_ also be in the index?
Since I guess this slowness is not something consistant in Oracle, there must be something to do.
Thanks for any help.Histograms on varchar2 columns are based on the
first 6 bytes of the column. If the database is using
a character set that uses 1 byte per character, every
entry in the DATE_ column since the beginning of the
year looks like '2008-0' to the optimizer when
determining cardinality to produce the "best"
execution plan. For character sets that require
multiple bytes per character, the situation is worse
- every entry in the column representing this century
appears to be the same value to the optimizer when
determining cardinality
That's a very good point and I didnt know about it
before, about first 6 bytes being used. Can you point
me in the docs where it is listed if its there or
some other document/s which has this detail?Aman,
I am having a bit of trouble finding the information in the documentation about the number of bytes used by a histogram on a VARCHAR2 column.
References:
http://www.freelists.org/archives/oracle-l/08-2006/msg00199.html
"Cost-Based Oracle Fundamentals" page 117 shows a demonstration, and describes the use of ENDPOINT_ACTUAL_VALUE starting on Oracle 9i.
"Cost-Based Oracle Fundamentals" page 118-120 describes selectivity problems when histograms are not used and a date is placed into a VARCHAR2 column.
"Troubleshooting Oracle Performance", likely around page 130-140 also indicates that histograms only use the first 6 bytes.
See section "Followup November 12, 2005 - 4pm US/Eastern"
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:707586567563
An interesting test setup that almost shows what I intended - but Oracle 10.2.0.2 was a little smarter than I expected, even though it selected to use an index to retrieve more than 50% of a table... Take a look at the TO_CHAR representation of the ENDPOINT_VALUE from DBA_TAB_HISTOGRAMS to understand what I was trying to decribe in my original post in this thread.
CREATE TABLE T1 (DATE_ VARCHAR2(10));
INSERT INTO T1
SELECT
TO_CHAR(TO_DATE('2008-01-01','YYYY-MM-DD')+ROWNUM-1,'YYYY-MM-DD')
FROM
DUAL
CONNECT BY
LEVEL<=250;
250 rows created.
COMMIT;
CREATE INDEX IND_T1 ON T1(DATE_);
SELECT
MIN(DATE_),
MAX(DATE_)
FROM
T1;
MIN(DATE_) MAX(DATE_)
2008-01-01 2008-09-06
SELECT
COLUMN_NAME,
NUM_DISTINCT,
NUM_BUCKETS,
HISTOGRAM
FROM
DBA_TAB_COL_STATISTICS
WHERE
OWNER=USER
AND TABLE_NAME='T1';
no rows selected
SELECT
SUBSTR(COLUMN_NAME,1,10) COLUMN_NAME,
ENDPOINT_NUMBER,
ENDPOINT_VALUE,
SUBSTR(ENDPOINT_ACTUAL_VALUE,1,10) ENDPOINT_ACTUAL_VALUE
FROM
DBA_TAB_HISTOGRAMS
WHERE
OWNER=USER
AND TABLE_NAME='T1';
no rows selected
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T1',METHOD_OPT=>'FOR COLUMNS SIZE 254 DATE_',CASCADE=>TRUE);
PL/SQL procedure successfully completed.
SELECT
COLUMN_NAME,
NUM_DISTINCT,
NUM_BUCKETS,
HISTOGRAM
FROM
DBA_TAB_COL_STATISTICS
WHERE
OWNER=USER
AND TABLE_NAME='T1';
COLUMN_NAME NUM_DISTINCT NUM_BUCKETS HISTOGRAM
DATE_ 250 250 HEIGHT BALANCED
SELECT
SUBSTR(COLUMN_NAME,1,10) COLUMN_NAME,
ENDPOINT_NUMBER,
ENDPOINT_VALUE,
SUBSTR(ENDPOINT_ACTUAL_VALUE,1,10) ENDPOINT_ACTUAL_VALUE
FROM
DBA_TAB_HISTOGRAMS
WHERE
OWNER=USER
AND TABLE_NAME='T1'
ORDER BY
ENDPOINT_NUMBER;
COLUMN_NAM ENDPOINT_NUMBER ENDPOINT_VALUE ENDPOINT_A
DATE_ 1 2.6059E+35 2008-01-01
DATE_ 2 2.6059E+35 2008-01-02
DATE_ 3 2.6059E+35 2008-01-03
DATE_ 4 2.6059E+35 2008-01-04
DATE_ 5 2.6059E+35 2008-01-05
DATE_ 6 2.6059E+35 2008-01-06
DATE_ 7 2.6059E+35 2008-01-07
DATE_ 8 2.6059E+35 2008-01-08
DATE_ 9 2.6059E+35 2008-01-09
DATE_ 10 2.6059E+35 2008-01-10
DATE_ 243 2.6059E+35 2008-08-30
DATE_ 244 2.6059E+35 2008-08-31
DATE_ 245 2.6059E+35 2008-09-01
DATE_ 246 2.6059E+35 2008-09-02
DATE_ 247 2.6059E+35 2008-09-03
DATE_ 248 2.6059E+35 2008-09-04
DATE_ 249 2.6059E+35 2008-09-05
DATE_ 250 2.6059E+35 2008-09-06
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
SELECT
DATE_
FROM
T1
WHERE
DATE_<='2008-01-15';
15 rows selected.
From the 10053 trace:
BASE STATISTICAL INFORMATION
Table Stats::
Table: T1 Alias: T1
#Rows: 250 #Blks: 5 AvgRowLen: 11.00
Index Stats::
Index: IND_T1 Col#: 1
LVLS: 0 #LB: 1 #DK: 250 LB/K: 1.00 DB/K: 1.00 CLUF: 1.00
SINGLE TABLE ACCESS PATH
Column (#1): DATE_(VARCHAR2)
AvgLen: 11.00 NDV: 250 Nulls: 0 Density: 0.002
Histogram: HtBal #Bkts: 250 UncompBkts: 250 EndPtVals: 250
Table: T1 Alias: T1
Card: Original: 250 Rounded: 15 Computed: 15.00 Non Adjusted: 15.00
Access Path: TableScan
Cost: 3.01 Resp: 3.01 Degree: 0
Cost_io: 3.00 Cost_cpu: 85607
Resp_io: 3.00 Resp_cpu: 85607
Access Path: index (index (FFS))
Index: IND_T1
resc_io: 2.00 resc_cpu: 49621
ix_sel: 0.0000e+000 ix_sel_with_filters: 1
Access Path: index (FFS)
Cost: 2.00 Resp: 2.00 Degree: 1
Cost_io: 2.00 Cost_cpu: 49621
Resp_io: 2.00 Resp_cpu: 49621
Access Path: index (IndexOnly)
Index: IND_T1
resc_io: 1.00 resc_cpu: 10121
ix_sel: 0.06 ix_sel_with_filters: 0.06
Cost: 1.00 Resp: 1.00 Degree: 1
Best:: AccessPath: IndexRange Index: IND_T1
Cost: 1.00 Degree: 1 Resp: 1.00 Card: 15.00 Bytes: 0
============
Plan Table
============
| Id | Operation | Name | Rows | Bytes | Cost | Time |
| 0 | SELECT STATEMENT | | | | 1 | |
| 1 | INDEX RANGE SCAN | IND_T1 | 15 | 165 | 1 | 00:00:01 |
Predicate Information:
1 - access("DATE_"<='2008-01-15')
INSERT INTO T1
SELECT
TO_CHAR(TO_DATE('2008-09-07','YYYY-MM-DD')+ROWNUM-1,'YYYY-MM-DD')
FROM
DUAL
CONNECT BY
LEVEL<=250;
COMMIT;
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T1',METHOD_OPT=>'FOR COLUMNS SIZE 254 DATE_',CASCADE=>TRUE);
PL/SQL procedure successfully completed.
SELECT
COLUMN_NAME,
NUM_DISTINCT,
NUM_BUCKETS,
HISTOGRAM
FROM
DBA_TAB_COL_STATISTICS
WHERE
OWNER=USER
AND TABLE_NAME='T1';
COLUMN_NAME NUM_DISTINCT NUM_BUCKETS HISTOGRAM
DATE_ 500 254 HEIGHT BALANCED
SELECT
SUBSTR(COLUMN_NAME,1,10) COLUMN_NAME,
ENDPOINT_NUMBER,
TO_CHAR(ENDPOINT_VALUE) ENDPOINT_VALUE,
SUBSTR(ENDPOINT_ACTUAL_VALUE,1,10) ENDPOINT_ACTUAL_VALUE
FROM
DBA_TAB_HISTOGRAMS
WHERE
OWNER=USER
AND TABLE_NAME='T1'
ORDER BY
ENDPOINT_NUMBER;
COLUMN_NAM ENDPOINT_NUMBER ENDPOINT_VALUE ENDPOINT_A
DATE_ 0 260592218925307000000000000000000000 2008-01-01
DATE_ 1 260592218925307000000000000000000000 2008-01-02
DATE_ 2 260592218925307000000000000000000000 2008-01-04
DATE_ 3 260592218925307000000000000000000000 2008-01-06
DATE_ 4 260592218925307000000000000000000000 2008-01-08
DATE_ 5 260592218925307000000000000000000000 2008-01-10
DATE_ 6 260592218925307000000000000000000000 2008-01-12
DATE_ 7 260592218925307000000000000000000000 2008-01-14
DATE_ 8 260592218925307000000000000000000000 2008-01-16
DATE_ 9 260592218925307000000000000000000000 2008-01-18
DATE_ 10 260592218925307000000000000000000000 2008-01-20
DATE_ 242 260592219234792000000000000000000000 2009-04-26
DATE_ 243 260592219234792000000000000000000000 2009-04-28
DATE_ 244 260592219234792000000000000000000000 2009-04-29
DATE_ 245 260592219234792000000000000000000000 2009-05-01
DATE_ 246 260592219234792000000000000000000000 2009-05-02
DATE_ 247 260592219234792000000000000000000000 2009-05-04
DATE_ 248 260592219234792000000000000000000000 2009-05-05
DATE_ 249 260592219234792000000000000000000000 2009-05-07
DATE_ 250 260592219234792000000000000000000000 2009-05-08
DATE_ 251 260592219234792000000000000000000000 2009-05-10
DATE_ 252 260592219234792000000000000000000000 2009-05-11
DATE_ 253 260592219234792000000000000000000000 2009-05-13
DATE_ 254 260592219234792000000000000000000000 2009-05-14
SELECT
DATE_
FROM
T1
WHERE
DATE_ BETWEEN '2008-01-15' AND '2008-09-15';
245 rows selected.
From the 10053 trace:
BASE STATISTICAL INFORMATION
Table Stats::
Table: T1 Alias: T1
#Rows: 500 #Blks: 5 AvgRowLen: 11.00
Index Stats::
Index: IND_T1 Col#: 1
LVLS: 1 #LB: 2 #DK: 500 LB/K: 1.00 DB/K: 1.00 CLUF: 2.00
SINGLE TABLE ACCESS PATH
Column (#1): DATE_(VARCHAR2)
AvgLen: 11.00 NDV: 500 Nulls: 0 Density: 0.002
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 255
Table: T1 Alias: T1
Card: Original: 500 Rounded: 240 Computed: 240.16 Non Adjusted: 240.16
Access Path: TableScan
Cost: 3.01 Resp: 3.01 Degree: 0
Cost_io: 3.00 Cost_cpu: 148353
Resp_io: 3.00 Resp_cpu: 148353
Access Path: index (index (FFS))
Index: IND_T1
resc_io: 2.00 resc_cpu: 111989
ix_sel: 0.0000e+000 ix_sel_with_filters: 1
Access Path: index (FFS)
Cost: 2.01 Resp: 2.01 Degree: 1
Cost_io: 2.00 Cost_cpu: 111989
Resp_io: 2.00 Resp_cpu: 111989
Access Path: index (IndexOnly)
Index: IND_T1
resc_io: 2.00 resc_cpu: 62443
ix_sel: 0.48031 ix_sel_with_filters: 0.48031
Cost: 2.00 Resp: 2.00 Degree: 1
Best:: AccessPath: IndexRange Index: IND_T1
Cost: 2.00 Degree: 1 Resp: 2.00 Card: 240.16 Bytes: 0
============
Plan Table
============
| Id | Operation | Name | Rows | Bytes | Cost | Time |
| 0 | SELECT STATEMENT | | | | 2 | |
| 1 | INDEX RANGE SCAN | IND_T1 | 240 | 2640 | 2 | 00:00:01 |
Predicate Information:
1 - access("DATE_">='2008-01-15' AND "DATE_"<='2008-09-15')I am sure that there are much better examples than the above, as the above generates a very small data set, and is still an incomplete test setup.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Dblink + local function: INDEX RANGE SCAN not used
Hi All,
I have an sql query to remote database:
SELECT N FROM [email protected] WHERE cd_n = 60
It works with INDEX RANGE SCAN for "N" field of table "tab", it's ok.
Now I'm replacing the constant value with the local database function:
SELECT N FROM [email protected] WHERE cd_n = dannis.foo()
Then 'INDEX RANGE SCAN' is removed out from query execution plan :-(
I've tried some tricks as
/*+ rule index(user.tab TAB$PK) */,
driving_site(tab),
to_number(dannis.foo()),
(select dannis.foo from [email protected])
and so on...
but INDEX RANGE SCAN wasn't appear while using the local function.
Is it true when dblink is used in combination with local function then INDEX RANGE SCAN will never used?
/Oracle 9.0.1.2/
Thanx,
dannis.See Optimizer not taking the hint
-
Index Range Scan / Deleted Leaf Blocks
Hello guys,
i have such a scenario on a big index / table which i can not reproduce on my test database, so i need to know how oracle handles the index range scan.
For example:
TABLE TAB with the following columns NR (number), I_DATE (date), TEXT (VARCHAR2(50))
INDEX I_TAB on the column I_DATE.
Now the index has blevel 2 and many leaf blocks. And now my question.
Query: SQL> SELECT * from TAB WHERE I_DATE < 10.10.2004
The index had stored some values which are a less than 2003 but these ones are already deleted (so the leaf blocks are gone to the freelist), but it was not reorganized.
The execution plan is a INDEX RANGE SCAN on the INDEX I_TAB. Does the branch block still have pointers to the deleted leaf blocks which contained only 2003 values before (and so the INDEX RANGE SCAN scans all these blocks too) or are the pointers to these leaf blocks deleted in the branch block?
Thanks and Regards
StefanYou can verify it by yourself. See following:
SELECT count(*) FROM index_test;
==> 1569408
SELECT count(*) FROM index_test WHERE id <= 2;
==> 12
-- Delete all except first 12 rows
DELETE FROM index_test WHERE id > 2;
-- Query and SQL Trace
BEGIN
FOR C IN (SELECT /*+index(index_test index_test_idx) deleted */ * FROM INDEX_TEST WHERE ID < 1000000) LOOP
NULL;
END LOOP;
END;
SELECT /*+index(index_test index_test_idx) deleted */ *
FROM
INDEX_TEST WHERE ID < 1000000
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 3490 0 12
total 3 0.00 0.01 0 3490 0 12
==> 3490 logical reads only for 12 rows and range scan??
-- Index tree dump
ALTER SESSION SET EVENTS 'IMMEDIATE TRACE NAME TREEDUMP LEVEL 67513'
----- begin tree dump
branch: 0x1000124 16777508 (0: nrow: 6, level: 2)
branch: 0x100b1ca 16822730 (-1: nrow: 557, level: 1)
leaf: 0x1000125 16777509 (-1: nrow: 512 rrow: 12)
leaf: 0x1000126 16777510 (0: nrow: 484 rrow: 0)
leaf: 0x1000127 16777511 (1: nrow: 479 rrow: 0)
leaf: 0x1000128 16777512 (2: nrow: 479 rrow: 0)
leaf: 0x1000139 16777529 (3: nrow: 479 rrow: 0)
leaf: 0x100013a 16777530 (4: nrow: 478 rrow: 0)
branch: 0x100b401 16823297 (0: nrow: 558, level: 1)
leaf: 0x100b1c9 16822729 (-1: nrow: 449 rrow: 0)
leaf: 0x100b1cb 16822731 (0: nrow: 449 rrow: 0)
leaf: 0x100b1cc 16822732 (1: nrow: 449 rrow: 0)
==> leaf:3488, branch: 7
This means that almost all the branch and leaf nodes are read only for 12 keys.
You can cross check this with the result of "10200" event which traces cr reads. You would find out that the blocks that are read by the query are exactly same as all the index blocks.
This is what you mean? that the deleted leaf blocks(which contain no actual data) are read by range scan? Through the simple test, the anwer is "yes". -
Index range scan cost change in 10.2.0.1
SQL> create table t1 as
2 select
3 rpad('x',40) ind_pad,
4 trunc(dbms_random.value(0,25)) n1,
5 trunc(dbms_random.value(0,25)) n2,
6 lpad(rownum,10,'0') small_vc,
7 rpad('x',200) padding
8 from
9 all_objects
10 where
11 rownum <= 10000
12 ;
Table created.
SQL> create index t1_i1 on t1(ind_pad,n1,n2)
2 pctfree 91
3 ;
Index created.
SQL> set autot trace exp
SQL> alter session set optimizer_features_enable='10.2.0.1';
Session altered.
SQL> exec dbms_stats.gather_table_stats(user,'T1',method_opt=>'for all columns size 1');
PL/SQL procedure successfully completed.
SQL> select
2 t1.small_vc
3 from
4 t1
5 where
6 t1.ind_pad = rpad('x',40)
7 and t1.n1 = 0
8 and t1.n2 = 4
9 ;
Execution Plan
Plan hash value: 1429545322
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
0 SELECT STATEMENT 16 928 20 (0)00:00
:01
1 TABLE ACCESS BY INDEX ROWIDT1 16 928 20 (0)00:00
:01
* 2 INDEX RANGE SCAN T1_I1 16 4 (0)00:00
:01
Predicate Information (identified by operation id):
2 - access("T1"."IND_PAD"='x' AND
"T1"."N1"=0 AND "T1"."N2"=4)
SQL> update t1 set n2=n1; //now t1 and t2 are correlated
10000 rows updated.
SQL> commit;
Commit complete.
SQL> exec dbms_stats.gather_table_stats(user,'T1',method_opt=>'for all columns size 1');
PL/SQL procedure successfully completed.
SQL> select
2 t1.small_vc
3 from
4 t1
5 where
6 t1.ind_pad = rpad('x',40)
7 and t1.n1 = 0
8 and t1.n2 = 4
9 ;
Execution Plan
Plan hash value: 3617692013
Id Operation Name Rows Bytes Cost (%CPU)Time
0 SELECT STATEMENT 16 928 84 (2)00:00:02 * 1 TABLE ACCESS FULLT1 16 928 84 (2)00:00:02
Predicate Information (identified by operation id):
1 - filter("T1"."N1"=0 AND "T1"."N2"=4 AND "T1"."IND_PAD"='x
SQL> exec dbms_stats.delete_table_stats(user,'T1');
//delete table stats test dynamic sampling
PL/SQL procedure successfully completed.
SQL> select
2 t1.small_vc
3 from
4 t1
5 where
6 t1.ind_pad = rpad('x',40)
7 and t1.n1 = 0
8 and t1.n2 = 4
9 ;
Execution Plan
Plan hash value: 1429545322
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
0 SELECT STATEMENT 1 60 1 (0)00:00
:01
1 TABLE ACCESS BY INDEX ROWIDT1 1 60 1 (0)00:00
:01
* 2 INDEX RANGE SCAN T1_I1 1 1 (0)00:00
:01
Predicate Information (identified by operation id):
2 - access("T1"."IND_PAD"='x' AND
"T1"."N1"=0 AND "T1"."N2"=4)
Note
- dynamic sampling used for this statement
//under dynamic sampling ,oracle choose true explain plan
SQL> exec dbms_stats.gather_table_stats(user,'T1',method_opt=>'for all columns size 1');
PL/SQL procedure successfully completed.
SQL> select /*+ index(t1) */
2 t1.small_vc
3 from
4 t1
5 where
6 t1.ind_pad = rpad('x',40)
7 and t1.n1 = 0
8 and t1.n2 = 4
9 ;
Execution Plan
Plan hash value: 1429545322
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
0 SELECT STATEMENT 16 928 256 (0)00:00
:04
1 TABLE ACCESS BY INDEX ROWIDT1 16 928 256 (0)00:00
:04
* 2 INDEX RANGE SCAN T1_I1 400 7 (0)00:00
:01
Predicate Information (identified by operation id):
2 - access("T1"."IND_PAD"='x' AND
"T1"."N1"=0 AND "T1"."N2"=4)
SQL> set autot off
SQL> select blevel,leaf_blocks,clustering_factor from user_indexes where table_name='T1';
BLEVEL LEAF_BLOCKS CLUSTERING_FACTOR
2 119 6201
//index selectity and table selectity are 0.4
index cost=2+119/25=7
table cost=7+6201/25=256
SQL> alter session set optimizer_features_enable='10.1.0.4';
Session altered.
SQL> set autot trace exp
SQL> select /*+ index(t1) */
2 t1.small_vc
3 from
4 t1
5 where
6 t1.ind_pad = rpad('x',40)
7 and t1.n1 = 0
8 and t1.n2 = 4
9 ;
Execution Plan
Plan hash value: 1429545322
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
0 SELECT STATEMENT 16 928 13 (0)00:00
:01
1 TABLE ACCESS BY INDEX ROWIDT1 16 928 13 (0)00:00
:01
* 2 INDEX RANGE SCAN T1_I1 16 3 (0)00:00
:01
Predicate Information (identified by operation id):
2 - access("T1"."IND_PAD"='x' AND
"T1"."N1"=0 AND "T1"."N2"=4)
//change optimizer to 10.1,then cbo caculate index selectity and table selectity 1/625>
Very interesting again. I can reproduce your test case in 10.2.0.4, and it looks like you're right. I don't know whether it's intended behaviour or not, but in this particular case, when a index-only access is possible (and the table is not required) then the old selectivity formula is used (in this case 1/10000 * 1/10000), and it ignores the DISTINCT_KEYS of the index.
The trace file shows that the index selectivity is actually determined as 1/10000 but it's obviously not used for the calculation.
Interestingly, repeating the same test case in 11.1.0.7 shows that it uses the DISTINCT_KEYS again in the case you're using the entire index:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Session altered.
SQL>
SQL> drop table m purge;
Table dropped.
SQL>
SQL> create table m(id int,id1 int);
Table created.
SQL>
SQL> insert into m select rownum,rownum+1 from dba_objects where rownum<10001;
10000 rows created.
SQL>
SQL> insert into m select * from m;
10000 rows created.
SQL>
SQL> insert into m select * from m;
20000 rows created.
SQL>
SQL> insert into m select * from m;
40000 rows created.
SQL>
SQL> insert into m select * from m;
80000 rows created.
SQL>
SQL> commit;
Commit complete.
SQL>
SQL> select count(*) from m;
COUNT(*)
160000
SQL>
SQL> create index i_m_1 on m(id,id1);
Index created.
SQL>
SQL> exec dbms_stats.gather_table_stats(user,'M',method_opt=>'for all columns si
ze 1', estimate_percent => null);
PL/SQL procedure successfully completed.
SQL>
SQL> set autotrace traceonly
SQL>
SQL> select * from m where id=1;
16 rows selected.
Execution Plan
Plan hash value: 3644412196
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 16 | 112 | 2 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| I_M_1 | 16 | 112 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("ID"=1)
Statistics
1 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
670 bytes sent via SQL*Net to client
427 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
16 rows processed
SQL>
SQL> select * from m where id=1 and id1=2;
16 rows selected.
Execution Plan
Plan hash value: 3644412196
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 16 | 112 | 1 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| I_M_1 | 16 | 112 | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("ID"=1 AND "ID1"=2)
Statistics
1 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
670 bytes sent via SQL*Net to client
427 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
16 rows processed
SQL>
SQL>So in 11.1.0.7 it seems to be consistent behaviour to take the DISTINCT_KEYS for an access using the entire index, but not in 10.2.
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/ -
Optimizer=ALL_ROWS, PARTITION HASH, INDEX (RANGE SCAN) POOR PERFORMANCE?
Our os is;
SunOS 5.9
and database is;
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit
Our autotrace outputs are below also we have 10046 trace outputs;
08:41:04 tcell_dev@SCME > set timing on
08:41:19 tcell_dev@SCME > set autot on
08:41:21 tcell_dev@SCME > SELECT lnpessv.PROFILE_ID FROM SCME.LNK_PROFILEENTITY_SUBSSERVVAR lnpessv
08:41:25 2 WHERE lnpessv.SUBSCRIPTION_SERVICEVARIANT_ID = 1695083 ;
PROFILE_ID
1.400E+14
1.600E+14
Elapsed: 00:00:03.07
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=3 Bytes=51)
1 0 PARTITION HASH (ALL) (Cost=3 Card=3 Bytes=51)
2 1 INDEX (RANGE SCAN) OF 'PK_PROFILEENTITY_SUBSSERVVAR' (INDEX (UNIQUE)) (Cost=
3 Card=3 Bytes=51)
Statistics
1 recursive calls
0 db block gets
1539 consistent gets
514 physical reads
0 redo size
258 bytes sent via SQL*Net to client
273 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
08:41:32 tcell_dev@SCME > SELECT lnpessv.PROFILE_ID FROM SCME.LNK_PROFILEENTITY_SUBSSERVVAR lnpessv
08:41:43 2 WHERE lnpessv.SUBSCRIPTION_SERVICEVARIANT_ID = 169508 ;
PROFILE_ID
1.400E+14
1.600E+14
Elapsed: 00:00:04.01
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=3 Bytes=51)
1 0 PARTITION HASH (ALL) (Cost=3 Card=3 Bytes=51)
2 1 INDEX (RANGE SCAN) OF 'PK_PROFILEENTITY_SUBSSERVVAR' (INDEX (UNIQUE)) (Cost=
3 Card=3 Bytes=51)
Statistics
1 recursive calls
0 db block gets
1537 consistent gets
512 physical reads
0 redo size
258 bytes sent via SQL*Net to client
273 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
Here we see 97% wait time, and responce time is unexceptable; These are the waits from 10046 trace file;
WAIT #1: nam='gc cr grant 2-way' ela= 783 p1=341 p2=67065 p3=1 obj#=169530 tim=571610438395
WAIT #1: nam='db file sequential read' ela= 6924 file#=341 block#=67065 blocks=1 obj#=169530 tim=571610445466
WAIT #1: nam='gc cr grant 2-way' ela= 564 p1=294 p2=86263 p3=1 obj#=169531 tim=571610446493
WAIT #1: nam='db file sequential read' ela= 6629 file#=294 block#=86263 blocks=1 obj#=169531 tim=571610453158
INDEX RANGE SCAN PK_PROFILEENTITY_SUBSSERVVAR PARTITION: 1 512 (cr=1537 pr=512 pw=0 time=4272017 us)
This is the related tables properties;
OWNER SCME
TABLE_NAME LNK_PROFILEENTITY_SUBSSERVVAR
TABLESPACE_NAME DATA01
STATUS VALID
PCT_FREE 10
INI_TRANS 10
MAX_TRANS 255
INITIAL_EXTENT 65536
MIN_EXTENTS 1
MAX_EXTENTS 2147483645
LOGGING NO
BACKED_UP N
NUM_ROWS 239587420
BLOCKS 1587288
EMPTY_BLOCKS 0
AVG_SPACE 0
CHAIN_CNT 0
AVG_ROW_LEN 41
AVG_SPACE_FREELIST_BLOCKS 0
NUM_FREELIST_BLOCKS 0
DEGREE 1
INSTANCES 1
CACHE N
TABLE_LOCK ENABLED
SAMPLE_SIZE 71876226
LAST_ANALYZED 29.05.2006 23:21:24
PARTITIONED NO
TEMPORARY N
SECONDARY N
NESTED NO
BUFFER_POOL DEFAULT
ROW_MOVEMENT DISABLED
GLOBAL_STATS YES
USER_STATS NO
SKIP_CORRUPT DISABLED
MONITORING YES
DEPENDENCIES DISABLED
COMPRESSION DISABLED
DROPPED NO
We are suspecting rac configuration and hash partition and index usage with rac.
Any comments will be welcomed,
Thank you.
Tonguçthis is the output of dbms_metadata.get_ddl for the table;
CREATE TABLE "SCME"."LNK_PROFILEENTITY_SUBSSERVVAR"
( "SUBSCRIPTION_SERVICEVARIANT_ID" NUMBER NOT NULL ENABLE NOVALIDATE,
"PROFILE_ID" NUMBER NOT NULL ENABLE NOVALIDATE,
"CREATED_BY_ID" NUMBER,
"CREATED_DATE" DATE DEFAULT SYSDATE,
"UPDATED_BY_ID" NUMBER,
"UPDATED_DATE" DATE,
CONSTRAINT "PK_PROFILEENTITY_SUBSSERVVAR" PRIMARY KEY ("SUBSCRIPTION_SERVICEVARIANT_ID", "PROFILE_ID")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 NOLOGGING
STORAGE(INITIAL 4194304
BUFFER_POOL DEFAULT)
TABLESPACE "INDX02" GLOBAL PARTITION BY HASH ("SUBSCRIPTION_SERVICEVARIANT_ID","PROFILE_ID")
(PARTITION "SYS_P52989"
TABLESPACE "INDX02",
PARTITION "SYS_P52990"
TABLESPACE "INDX02",
PARTITION "SYS_P54010"
TABLESPACE "INDX02",
PARTITION "SYS_P54011"
TABLESPACE "INDX02",
PARTITION "SYS_P54012"
TABLESPACE "INDX02") ;
CREATE UNIQUE INDEX "SCME"."PK_PROFILEENTITY_SUBSSERVVAR" ON "SCME"."LNK_PROFILEENTITY_SUBSSERVVAR" ("SUBSCRIPTION_SERVICEVARIANT_ID", "PROFILE_ID")
PCTFREE 10 INITRANS 2 MAXTRANS 255 NOLOGGING
STORAGE(INITIAL 4194304
BUFFER_POOL DEFAULT)
TABLESPACE "INDX02" GLOBAL PARTITION BY HASH ("SUBSCRIPTION_SERVICEVARIANT_ID","PROFILE_ID")
(PARTITION "SYS_P52989"
TABLESPACE "INDX02",
PARTITION "SYS_P52990"
TABLESPACE "INDX02",
PARTITION "SYS_P53499"
TABLESPACE "INDX02",
PARTITION "SYS_P53500"
TABLESPACE "INDX02") ENABLE NOVALIDATE,
CONSTRAINT "FK_LNK_PROF_REFERENCE_SDP_SUBS" FOREIGN KEY ("SUBSCRIPTION_SERVICEVARIANT_ID")
REFERENCES "SCME"."SDP_SUBSCRIPTIONSERVICEVARIANT" ("SUBSCRIPTION_SERVICEVARIANT_ID") DEFERRABLE INITIALLY DEFERRED ENABLE NOVALIDATE
) PCTFREE 10 PCTUSED 40 INITRANS 10 MAXTRANS 255 NOCOMPRESS NOLOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "DATA01" ;
CREATE INDEX "SCME"."LNK_PROFILEENTITY_SUB_HNDX3" ON "SCME"."LNK_PROFILEENTITY_SUBSSERVVAR" ("SUBSCRIPTION_SERVICEVARIANT_ID")
PCTFREE 10 INITRANS 2 MAXTRANS 255 NOLOGGING
STORAGE(INITIAL 2097152
BUFFER_POOL DEFAULT)
TABLESPACE "INDX02" GLOBAL PARTITION BY HASH ("SUBSCRIPTION_SERVICEVARIANT_ID")
(PARTITION "SYS_P53501"
TABLESPACE "INDX02",
PARTITION "SYS_P53502"
TABLESPACE "INDX02",
PARTITION "SYS_P53499"
TABLESPACE "INDX02",
PARTITION "SYS_P53500"
TABLESPACE "INDX02") ;
CREATE INDEX "SCME"."PROFILE_ID_NDX43" ON "SCME"."LNK_PROFILEENTITY_SUBSSERVVAR" ("PROFILE_ID")
PCTFREE 10 INITRANS 2 MAXTRANS 255 NOLOGGING COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "INDX03" ;
ALTER TABLE "SCME"."LNK_PROFILEENTITY_SUBSSERVVAR" ADD CONSTRAINT "PK_PROFILEENTITY_SUBSSERVVAR" PRIMARY KEY ("SUBSCRIPTION_SERVICEVARIANT_ID", "PROFILE_ID")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 NOLOGGING
STORAGE(INITIAL 4194304
BUFFER_POOL DEFAULT)
TABLESPACE "INDX02" GLOBAL PARTITION BY HASH ("SUBSCRIPTION_SERVICEVARIANT_ID","PROFILE_ID")
(PARTITION "SYS_P52989"
TABLESPACE "INDX02",
PARTITION "SYS_P52990"
PARTITION "SYS_P53498"
TABLESPACE "INDX02",
PARTITION "SYS_P53499"
TABLESPACE "INDX02",
PARTITION "SYS_P53500"
TABLESPACE "INDX02") ENABLE NOVALIDATE;
ALTER TABLE "SCME"."LNK_PROFILEENTITY_SUBSSERVVAR" MODIFY ("SUBSCRIPTION_SERVICEVARIANT_ID" NOT NULL ENABLE NOVALIDATE);
ALTER TABLE "SCME"."LNK_PROFILEENTITY_SUBSSERVVAR" MODIFY ("PROFILE_ID" NOT NULL ENABLE NOVALIDATE); -
Direct Path Reads instead of Sequential Reads for index range scan
Database is 11.2. I have two development schemas, with the same table loaded in each schema - a 5 million row table. The execution path for the sql statement is the same against both tables; it's doing an index range scan.
But it would appear Oracle performs a direct path read against one schema, and performs sequential reads against the other schema. I don't understand why I'm seeing different behavior when the execution plan is the same. Any ideas? These are two different schemas in the same database.There is not enough information.So you even these tables located same database and you gathered statistics it is not mean both run time wait event statistics must be same.Really they are different tables.If both query use INDEX RANGE SCAN the it is not mean these plans are same.What about table and their index statistics? are they same? for example num_row or num_blocks of both tables are same? also about indexes.In additionally if you want to get exact reason you can enable sql trace(using dbms_monitor or setting sql_trace parameter to true according session) and need analyze result trace file using tkprof utility.In additionally in 11g here when query execution time oracle automatically choose direct read path(serial) based on size of tables and size of buffer cache(also here is available some hidden parameter to controlling this behavior).
-
Wrong cardinality estimate for range scan
select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE 11.2.0.2.0 Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - ProductionSQL : select * from GC_FULFILLMENT_ITEMS where MARKETPLACE_ID=:b1 and GC_FULFILLMENT_STATUS_ID=:b2;
Plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 474K| 99M| 102 (85)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| GC_FULFILLMENT_ITEMS | 474K| 99M| 102 (85)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | I_GCFI_GCFS_ID_SDOC_MKTPLID | 474K| | 91 (95)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("GC_FULFILLMENT_STATUS_ID"=TO_NUMBER(:B2) AND "MARKETPLACE_ID"=TO_NUMBER(:B1))
filter("MARKETPLACE_ID"=TO_NUMBER(:B1))If i use literals than CBO uses cardinality =1 (I believe this is due it fix control :5483301 which i set to off In my environment)
select * from GC_FULFILLMENT_ITEMS where MARKETPLACE_ID=5 and GC_FULFILLMENT_STATUS_ID=2;
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 220 | 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| GC_FULFILLMENT_ITEMS | 1 | 220 | 3 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | I_GCFI_GCFS_ID_SDOC_MKTPLID | 1 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("GC_FULFILLMENT_STATUS_ID"=2 AND "MARKETPLACE_ID"=5)
filter("MARKETPLACE_ID"=5)Here is column distribution and histogram information
Enter value for column_name: MARKETPLACE_ID
COLUMN_NAME ENDPOINT_VALUE CUMMULATIVE_FREQUENCY FREQUENCY ENDPOINT_ACTUAL_VALU
MARKETPLACE_ID 1 1 1
MARKETPLACE_ID 3 8548 8547
MARKETPLACE_ID 4 15608 7060
MARKETPLACE_ID 5 16385 777 --->
MARKETPLACE_ID 35691 16398 13
MARKETPLACE_ID 44551 16407 9
6 rows selected.
Enter value for column_name: GC_FULFILLMENT_STATUS_ID
COLUMN_NAME ENDPOINT_VALUE CUMMULATIVE_FREQUENCY FREQUENCY ENDPOINT_ACTUAL_VALU
GC_FULFILLMENT_STATUS_ID 5 19602 19602
GC_FULFILLMENT_STATUS_ID 6 19612 10
GC_FULFILLMENT_STATUS_ID 8 19802 190
3 rows selected.
Actual distribution
select MARKETPLACE_ID,count(*) from GC_FULFILLMENT_ITEMS group by MARKETPLACE_ID order by 1;
MARKETPLACE_ID COUNT(*)
1 2099
3 16339936
4 13358682
5 1471839 --->
35691 33623
44551 19881
78931 40273
101611 1
6309408
9 rows selected.
BHAVIK_DBA: GC1EU> select GC_FULFILLMENT_STATUS_ID,count(*) from GC_FULFILLMENT_ITEMS group by GC_FULFILLMENT_STATUS_ID order by 1;
GC_FULFILLMENT_STATUS_ID COUNT(*)
1 880
2 63 --->
3 24
5 37226908
6 22099
7 18
8 325409
9 343
8 rows selected.10053 trace
SINGLE TABLE ACCESS PATH
Table: GC_FULFILLMENT_ITEMS Alias: GC_FULFILLMENT_ITEMS
Card: Original: 36703588.000000 Rounded: 474909 Computed: 474909.06 Non Adjusted: 474909.06
Best:: AccessPath: IndexRange
Index: I_GCFI_GCFS_ID_SDOC_MKTPLID
Cost: 102.05 Degree: 1 Resp: 102.05 Card: 474909.06 Bytes: 0
Outline Data:
/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('11.2.0.2')
DB_VERSION('11.2.0.2')
OPT_PARAM('_b_tree_bitmap_plans' 'false')
OPT_PARAM('_optim_peek_user_binds' 'false')
OPT_PARAM('_fix_control' '5483301:0')
ALL_ROWS
OUTLINE_LEAF(@"SEL$F5BB74E1")
MERGE(@"SEL$2")
OUTLINE(@"SEL$1")
OUTLINE(@"SEL$2")
INDEX_RS_ASC(@"SEL$F5BB74E1" "GC_FULFILLMENT_ITEMS"@"SEL$2" ("GC_FULFILLMENT_ITEMS"."GC_FULFILLMENT_STATUS_ID" "GC_FULFILLMENT_ITEMS"."SHIP_DELIVERY_OPTION_CODE" "GC_FULFILLMENT_ITEMS"."MARKETPLACE_ID"))
END_OUTLINE_DATA
*/Is there any reason why CBO is using card=474909.06 ? Having fix control () in place, it should have set card=1 if it is considering GC_FULFILLMENT_STATUS_ID= 2 as "rare" value..isn't it ?OraDBA02 wrote:
You are right Charles.
I was reading one of your blog and saw that.
As you said, it is an issue with SQLPLUS.
However, plan for the sql which is comming from application still shows the same (wrong cardinality) plan. It does not have TO_NUMBER function because of the reason that it does not experience data-type conversion that SQLPLUS has.
But YES...Plan is exactly the same with/without NO_NUMBER.OraDBA02,
I believe that some of the other people responding to this thread might have already described why the execution plan in the library cache is the same plan that you are seeing. One of the goals of using bind variables in SQL statements is to reduce the number of time consuming (and resource intensive) hard parses. That also means that a second goal is to share the same execution plan for future executions of the same SQL statement, even through bind variable values have changed. The catch here is that bind variable peeking, introduced with Oracle Database 9.0.1 (may be disabled by modifying a hidden parameter), helps the optimizer select the "best" (lowest calculated cost) execution plan for those specific bind variable values - the same plan may not be the "best" execution plan for other sets of bind variable values on future executions.
Histograms on one or more of the columns in the WHERE clause could either help or hinder the situation further. It might further help the first execution, but might further hinder future executions with different bind variable values. Oracle Database 11.1 introduced something called adaptive cursor sharing (and 11.2 introduced cardinality feedback) that in theory addresses issues where the execution plan should change for later executions with different bind variable values (but the SQL statement must execute poorly at least once).
There might be multiple child cursors in the library cache for the same SQL statement, each potentially with a different execution plan. I suggest finding the SQL_ID of the SQL statement that the application is submitting (you can do this by checking V$SQL or V$SQLAREA). Once you have the SQL_ID, go back to the SQL statement that I suggested for displaying the execution plan:
SELECT * FROM TABLE (DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'TYPICAL'));The first NULL in the above SQL statement is where you would specify the SQL_ID. If you leave the second NULL in place, the above SQL statement will retrieve the execution plan for all child cursors with that SQL_ID.
For instance, if the SQL_ID was 75chksrfa5fbt, you would execute the following:
SELECT * FROM TABLE (DBMS_XPLAN.DISPLAY_CURSOR('75chksrfa5fbt',NULL,'TYPICAL'));Usually, you can take it a step further to see the bind variables that were used during the optimization phase. To do that, you would add the +PEEKED_BINDS format parameter:
SELECT * FROM TABLE (DBMS_XPLAN.DISPLAY_CURSOR('75chksrfa5fbt',NULL,'TYPICAL +PEEKED_BINDS'));Note that there are various optimizer parameters that affect the optimizer's decisions, for instance, maybe the optimizer mode is set to FIRST_ROWS. Also possibly helpful is the +OUTLINE format parameter that might provide a clue regarding the value of some of the parameters affecting the optimizer. The SQL statement that you would then enter is similar to the following:
SELECT * FROM TABLE (DBMS_XPLAN.DISPLAY_CURSOR('75chksrfa5fbt',NULL,'TYPICAL +PEEKED_BINDS +OUTLINE'));Additional information might be helpful. Please see the following two forum threads to see what kind of information you should gather:
When your query takes too long… : When your query takes too long ...
How to post a SQL statement tuning request: HOW TO: Post a SQL statement tuning request - template posting
Charles Hooper
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
SECURITY query running slow with Prompts!!
Hello All,
Version: PeopleSoft HRMS 9 with PeopleTools 8.49.09
DB Version: 10.2.0.3 (Oracle)
My client is running a security query, given below, with and without prompts. Without prompts it is completing in 35 seconds but with prompts (even if the values in the prompts are blank!), the query is taking more than 4-5 hours but not completing!!
SELECT /*+ OPT_PARAM('_optimizer_mjc_enabled', 'false')
opt_param('_optimizer_cartesian_enabled', 'false') opt_param('optimizer_index_caching', 0) opt_param('optimizer_index_cost_adj', 0)*/ B.OPRID, A.EMPLID, A.PWCUK_LEGACY_ID, A.NAME, A.EMPL_STATUS, A.EMPL_CLASS,
to_char(to_date( TO_CHAR(A.HIRE_DT, 'YYYY-MM-DD'), 'yyyy-mm-dd'), 'dd/mm/yyyy'),
to_char(to_date(decode( TO_CHAR(A.REHIRE_DT, 'YYYY-MM-DD'), '',
TO_CHAR(A.HIRE_DT, 'YYYY-MM-DD'), TO_CHAR(A.REHIRE_DT, 'YYYY-MM-DD')), 'yyyy-mm-dd'), 'dd/mm/yyyy'),
to_char(to_date( TO_CHAR(A.TERMINATION_DT, 'YYYY-MM-DD'), 'yyyy-mm-dd'), 'dd/mm/yyyy'), A.DEPTID, A.DEPT_DESCR, A.PWCUK_BUSINESSUNIT, A.PWCUK_BU_DESCR, A.PWCUK_SUBREGION, A.PWCUK_SR_DESCR,
A.PWCUK_REGION, A.PWCUK_R_DESCR, B.ROWSECCLASS, E.CLASSDEFNDESC, C.ROLENAME, D.DESCR,
Case C.ROLENAME When 'UK_OTG_Query_Access' then 'Y' When 'UK_Self_Service_Query_Access' then 'Y' When 'UK_Prtner_Affairs_Query_Acces' then 'Y' When 'UK_SelfServ_Sens_Basic_Query' then 'Y' When 'UK_ESC_Extra_Query_Access' then 'Y' When 'UK_BCI_Query_Access' then 'Y' When 'UK_Self_Service_Non_Sens_Q Acc' then 'Y' Else 'N' END, TO_CHAR(A.EFFDT, 'YYYY-MM-DD'),
TO_CHAR(A.EFFDT, 'YYYY-MM-DD'), D.ROLENAME FROM PS_PWCUK_EMP_C_VW A, PS_PERS_SRCH_QRY A1, PSOPRDEFN B, PS_ROLEU SER_VW C, PSROLEDEFN D, PSCLASSDEFN E WHERE A.EMPLID = A1.EMPLID
AND A1.OPRID = 'kcooper001a' AND ( B.OPRID = A.PWCE_GUID AND B.OPRID = C.OPRID AND C.ROLENAME NOT IN ('Orbit User', 'PWCUK_LOS_ADMIN_PLANNER', 'Query Designer', 'Query User', 'PWCE_EMEA_AUDIT_RLE_NO_BSE_TBL', 'PWCE_REPORT_DIST', 'EOPP_USER', 'PAPP_USER', 'PWCUK_XMLP_REPORT_DEVELOPER', 'GBR_PEOPLE_MANAGER_CONFIG_UPD', 'PWCUK_EX_EMPLOYEE', 'ReportSuperUser', 'PWCE JOBCODE LOAD UTILITY',
'PWCE EMPLOYEE RVW LOAD ACCESS', 'PwCE Bonus Upload Access', 'GBR_EP_SYSADMIN') AND ( C.ROLENAME NOT LIKE 'PWCUK_EP%' OR C.ROLENAME = 'PWCUK_EP_ADMIN') AND C.ROLENAME NOT LIKE 'PWCUK_SP%' AND C.ROLENAME NOT LIKE 'GBR_PMGR%' AND 0 < INSTR(:1, decode(trim(:2), null, ' ', B.OPRID)) AND 0 < INSTR(:3, decode(trim(:4), null, ' ', B.EMPLID)) AND 0 < INSTR(:5, decode(trim(:6), null, ' ', A.PWCUK_LEGACY_ID)) A
ND 0 < INSTR(:7, decode(trim(:8), null, ' ', C.ROLENAME)) AND 0 < INSTR(:9, decode(trim(:10), null, ' ', E.CLASSID)) AND C.ROLENAME = D.ROLENAME AND E.CLASSID = B.ROWSECCLASS ) ORDER BY 4, 20Below are some more useful information I have gathered from DB level for this query:
+--------------------------------------------------------------------------------------------------+
|Plan HV Min Snap Max Snap Execs LIO PIO CPU Elapsed |
+--------------------------------------------------------------------------------------------------+
|770792495 39602 39747 5 1,181,648,326 6,823 7,433.93 7,481.60 |
+--------------------------------------------------------------------------------------------------+
========== PHV = 770792495==========
First seen from "10/19/12 10:00:44" (snap #39602)
Last seen from "10/25/12 11:00:28" (snap #39747)
Execs LIO PIO CPU Elapsed
===== === === === =======
5 1,181,648,326 6,823 7,433.93 7,481.60
Plan hash value: 770792495
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 35 (100)| |
| 1 | SORT ORDER BY | | 1 | 645 | 35 (6)| 00:00:01 |
| 2 | NESTED LOOPS | | 1 | 645 | 34 (3)| 00:00:01 |
| 3 | NESTED LOOPS | | 6 | 1122 | 10 (10)| 00:00:01 |
| 4 | NESTED LOOPS | | 1 | 165 | 5 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 122 | 4 (0)| 00:00:01 |
| 6 | NESTED LOOPS | | 1 | 81 | 3 (0)| 00:00:01 |
| 7 | NESTED LOOPS | | 552 | 29256 | 2 (0)| 00:00:01 |
| 8 | INDEX FULL SCAN | PSAPSROLEUSER | 550 | 15950 | 1 (0)| 00:00:01 |
| 9 | TABLE ACCESS BY INDEX ROWID | PS_ROLEXLATOPR | 1 | 24 | 1 (0)| 00:00:01 |
| 10 | INDEX UNIQUE SCAN | PS_ROLEXLATOPR | 1 | | 1 (0)| 00:00:01 |
| 11 | TABLE ACCESS BY INDEX ROWID | PSOPRDEFN | 1 | 28 | 1 (0)| 00:00:01 |
| 12 | INDEX UNIQUE SCAN | PS_PSOPRDEFN | 1 | | 1 (0)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID | PSCLASSDEFN | 1 | 41 | 1 (0)| 00:00:01 |
| 14 | INDEX UNIQUE SCAN | PS_PSCLASSDEFN | 1 | | 1 (0)| 00:00:01 |
| 15 | TABLE ACCESS BY INDEX ROWID | PSROLEDEFN | 1 | 43 | 1 (0)| 00:00:01 |
| 16 | INDEX UNIQUE SCAN | PS_PSROLEDEFN | 1 | | 1 (0)| 00:00:01 |
| 17 | VIEW | PS_PERS_SRCH_QRY | 483 | 10626 | 5 (20)| 00:00:01 |
| 18 | SORT UNIQUE | | 483 | 62790 | 5 (20)| 00:00:01 |
| 19 | NESTED LOOPS | | 483 | 62790 | 4 (0)| 00:00:01 |
| 20 | NESTED LOOPS | | 483 | 49749 | 3 (0)| 00:00:01 |
| 21 | NESTED LOOPS | | 1 | 67 | 2 (0)| 00:00:01 |
| 22 | TABLE ACCESS BY INDEX ROWID| PSOPRDEFN | 1 | 40 | 1 (0)| 00:00:01 |
| 23 | INDEX UNIQUE SCAN | PS_PSOPRDEFN | 1 | | 1 (0)| 00:00:01 |
| 24 | TABLE ACCESS BY INDEX ROWID| PS_SJT_OPR_CLS | 1 | 27 | 1 (0)| 00:00:01 |
| 25 | INDEX RANGE SCAN | PS_SJT_OPR_CLS | 1 | | 1 (0)| 00:00:01 |
| 26 | TABLE ACCESS BY INDEX ROWID | PS_SJT_CLASS_ALL | 482 | 17352 | 1 (0)| 00:00:01 |
| 27 | INDEX RANGE SCAN | PS_SJT_CLASS_ALL | 1158 | | 1 (0)| 00:00:01 |
| 28 | INDEX RANGE SCAN | PS_SJT_PERSON | 1 | 27 | 1 (0)| 00:00:01 |
| 29 | VIEW | PS_PWCUK_EMP_C_VW | 1 | 458 | 4 (0)| 00:00:01 |
| 30 | UNION ALL PUSHED PREDICATE | | | | | |
| 31 | TABLE ACCESS BY INDEX ROWID | PS_PWCUK_EMPLOYEES | 1 | 169 | 1 (0)| 00:00:01 |
| 32 | INDEX RANGE SCAN | PS_PWCUK_EMPLOYEES | 1 | | 1 (0)| 00:00:01 |
| 33 | FILTER | | | | | |
| 34 | NESTED LOOPS OUTER | | 1 | 220 | 3 (0)| 00:00:01 |
| 35 | NESTED LOOPS OUTER | | 1 | 208 | 2 (0)| 00:00:01 |
| 36 | TABLE ACCESS BY INDEX ROWID | PS_PWCUK_EX_EMPLS | 1 | 161 | 1 (0)| 00:00:01 |
| 37 | INDEX RANGE SCAN | PS_PWCUK_EX_EMPLS | 1 | | 1 (0)| 00:00:01 |
| 38 | TABLE ACCESS BY INDEX ROWID | PS_PWCE_EP_ROLES | 1 | 47 | 1 (0)| 00:00:01 |
| 39 | INDEX RANGE SCAN | PS_PWCE_EP_ROLES | 1 | | 1 (0)| 00:00:01 |
| 40 | INDEX RANGE SCAN | PS_PWCUK_EMPLOYEES | 1 | 12 | 1 (0)| 00:00:01 |
| 41 | SORT AGGREGATE | | 1 | 23 | | |
| 42 | INDEX RANGE SCAN | PS_PWCE_EP_ROLES | 1 | 23 | 1 (0)| 00:00:01 |
Summary Execution Statistics Over Time
Avg Avg
Snapshot Avg LIO Avg PIO CPU (secs) Elapsed (secs)
Time Execs Per Exec Per Exec Per Exec Per Exec
19-OCT 10:00 1 374,309,812.00 1,469.00 2,286.32 2,291.32
25-OCT 10:00 3 86,033,085.00 1,567.67 543.68 546.11
25-OCT 11:00 1 549,239,259.00 651.00 3,516.56 3,551.96
avg 336,527,385.33 1,229.22 2,115.52 2,129.80
sum 5
Per-Plan Execution Statistics Over Time
Avg Avg
Plan Snapshot Avg LIO Avg PIO CPU (secs) Elapsed (secs)
Hash Value Time Execs Per Exec Per Exec Per Exec Per Exec
770792495 19-OCT 10:00 1 374,309,812.00 1,469.00 2,286.32 2,291.32
25-OCT 10:00 3 86,033,085.00 1,567.67 543.68 546.11
25-OCT 11:00 1 549,239,259.00 651.00 3,516.56 3,551.96
avg 336,527,385.33 1,229.22 2,115.52 2,129.80
sum 5I'm not at all proficient in PeopleSoft.
Please advice how we can get faster runs for this query.
Note: We have already checked all other possibilities, like network, application, web services, etc, and they look normal.
Thanks,
SuddhasatwaIf the hints are there only for the "cost", then I'm sorry to say, but they are useless. Did you say that was not efficient to the Oracle Support ?
I asked earlier if that query already ran in a reasonnable time, is it the case, or always took that time ? Is it a change of behaviour after a db upgrade ?
Have you tried to work with AWR snapshots with a short gap in between ? I mean between the AWR snapshots (every 15 minutes or so), not between the runs of the query.
If there's no values for the bind variables, I assume this is what you mean when you said "no prompts", then Oracle can go much faster because of the few (or no?) data repartition to retrieve.
However, when given values to some (all?) of the bind variables, then all the problem will be on the data repartition. That's why I was asking how you gathered statistics on the involved objects, in other words, the histograms may be wrong somehow.
There's a lot of litterature on this, have a look to the Jonathan Lewis blog for more information.
Anyway, I think there's not enough information here and does not look easy to work on it in that state from the other side of the network.
Nicolas.
Maybe you are looking for
-
Read and display the field values in the table control
Hi Experts, I am new to the Table Control. I have created table control using the wizard where i have mentioned the ztable while creating which consist of the following fields. Item Number Material number Material Description Net Price. I would like
-
Creative Cloud for Designers | Learn Creative Cloud | Adobe TV
Evangelist Paul Trani shares new workflows for Designers made possible with Creative Cloud. http://adobe.ly/LAfIbL
-
My lock button is jammed and I can't restore my iPhone
I Need help
-
TopLink inserts when it should update, unique constraint exception
The title says most of it. I am creating a series of objects and then updating them in rapid succession. It would be great to handle all the values during the insert, but it's not possible for this process. The majority of the time, the cached object
-
I cannot install flash player on my computer using Windows 7
Please give me some suggestions for installing flash player on my computer using Windows 7. I have tried several things but nothing seems to work. It downloads but then won't run.