Tkprof in 11g
hello *
how is treated (or meant to be treated) TKPROF tool in 11g version?
there are lots of GUI/API tools for tuning and monitoring (all kinds of advisors and checkers, AWR, ADDM), and I wonder if average DBA should bother about it.
I can imagine it is still handy for many people, but to be honest - is it superior (and how if somehow) over 11g advisors?
Can TKPROF be fully replaced with 11g GUI/API features?
I'm asking mainly those who used both solutions and can compare them. thx
The biggest problem with Tkprof is that it needs "you" to be knowledgeable enough to interpret what it reveals and that's what Oracle is trying to improve with the self-tuning components that it has introduced in the past two releases. See this thread on Asktom where Tom tells how to use Tkprof effectively and what its all about,
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:969160000346108326
HTH
Aman....
Similar Messages
-
Has anyone else experienced extremely long parse times for Oracle 11G versus 10G? We are experiencing at least a 10 times increase in the parsing of our SQL statements. This is causing our customers to complain when running reports which contain several SQL statements that aren't in the SGA due to the infrequent use. I have opened a Service Request and development stated that this is to be expected with Oracle 11G due to the new optimizer features. I have tried to disable the features by settting the optimizer version to anything but 11G and no setting has helped. To make thing even worse, this increased parse time is on a new server that should be 2.5 times faster than the server that is running the 10G database. I do get at least a 2.5 times increase, larger if I/O intensive, in almost every other aspect of the database except for the parse times.
user5999814 wrote:
I wondered what the resolution was to this issue. We currently experiencing this will our Oracle 11.1.0.7 database with a small but important set of queries and it seems to be getting worse. We first noticed it with a query that went from taking 3.5 seconds to 7 seconds. A SQLTrace / TKProf revealed that 99% of the time was being spent during the parsing. A second similar query that brings in more data is taking around 1.5 minutes to parse then only a few seconds to actually execute. These are queries that are part of on online web transaction so this is not acceptable. We are able to replicate the behavior in multiple database instances.As a starting point it would be interesting to see the tkprof output from :
alter session set events '10046 trace name context forever, level 8';
+your select statement+
exitWhen posting the output, use the "code" tags (see below) to make the output readable.
Regards
Jonathan Lewis
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.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
+"I believe in evidence. I believe in observation, measurement, and reasoning, confirmed by independent observers. I'll believe anything, no matter how wild and ridiculous, if there is evidence for it. The wilder and more ridiculous something is, however, the firmer and more solid the evidence will have to be."+
Isaac Asimov -
Performance issue with 11g vs. 10gR2
Experts,
One of my customers did some performance comparisons between oracle 10gR2 and 11gR2.
While in general, they are quite happy with improved performance in 11g over 10g, there is one query of their test sequence which performs approx. 20% slower.
The query in question is of the type "select count(*) from emp, emp, emp, emp, ..." which - I think - all of us have already used to do a quick and dirty test of DB performance, CPU speed or similar.
The customer is fully aware of the fact, that this test is very artificial and not representative, but they still want to better understand, why this is running significantly slower consistently on several platforms, during peak hours as well as off peak in both 11.1 and 11.2 than it did in 10.2
Thank you for any hints
ErwinHello!
My company is the customer Erwin mentioned in his first post.
We've now carried out additional testing and here are the results:
This script was used:
set lines 120
set autotrace off
set timing off
select * from v$version;
drop table cpt;
create table cpt (rn number, text varchar2(10)) ;
insert into cpt values(1, 'alpha');
insert into cpt values(10,'kappa');
commit;
exec dbms_stats.gather_table_stats(ownname => 'SYSTEM', tabname => 'CPT', estimate_percent => 100, method_opt => 'FOR ALL COLUMNS');
set timing on
set autotrace traceonly explain statistics
select count(*) from cpt, cpt, cpt, cpt, cpt, cpt, cpt, cpt;
set autotrace off
ALTER SESSION SET tracefile_identifier='CPT_PERF';
exec dbms_monitor.session_trace_enable(null, null, true, true);
select count(*) from cpt, cpt, cpt, cpt, cpt, cpt, cpt, cpt;
exec dbms_monitor.session_trace_disable(null, null);For the 10g database we get:
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for IBM/AIX RISC System/6000: Version 10.2.0.4.0 - Productio
NLSRTL Version 10.2.0.4.0 - Production
[...preparation...]
Elapsed: 00:00:07.80
[...first execution plan...]
Statistics
1 recursive calls
0 db block gets
24 consistent gets
0 physical reads
0 redo size
522 bytes sent via SQL*Net to client
488 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
7 sorts (memory)
0 sorts (disk)
1 rows processed
PROFAHR:SQL> /
Elapsed: 00:00:08.03
Execution Plan
Plan hash value: 2108355742
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 3675K (1)| 14:17:31 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | MERGE JOIN CARTESIAN | | 100M| 3675K (1)| 14:17:31 |
| 3 | MERGE JOIN CARTESIAN | | 10M| 367K (1)| 01:25:46 |
| 4 | MERGE JOIN CARTESIAN | | 1000K| 36760 (1)| 00:08:35 |
| 5 | MERGE JOIN CARTESIAN | | 100K| 3683 (1)| 00:00:52 |
| 6 | MERGE JOIN CARTESIAN | | 10000 | 374 (0)| 00:00:06 |
| 7 | MERGE JOIN CARTESIAN | | 1000 | 42 (0)| 00:00:01 |
| 8 | MERGE JOIN CARTESIAN| | 100 | 7 (0)| 00:00:01 |
| 9 | TABLE ACCESS FULL | CPT | 10 | 2 (0)| 00:00:01 |
| 10 | BUFFER SORT | | 10 | 5 (0)| 00:00:01 |
| 11 | TABLE ACCESS FULL | CPT | 10 | 1 (0)| 00:00:01 |
| 12 | BUFFER SORT | | 10 | 42 (0)| 00:00:01 |
| 13 | TABLE ACCESS FULL | CPT | 10 | 0 (0)| 00:00:01 |
| 14 | BUFFER SORT | | 10 | 374 (0)| 00:00:06 |
| 15 | TABLE ACCESS FULL | CPT | 10 | 0 (0)| 00:00:01 |
| 16 | BUFFER SORT | | 10 | 3683 (1)| 00:00:52 |
| 17 | TABLE ACCESS FULL | CPT | 10 | 0 (0)| 00:00:01 |
| 18 | BUFFER SORT | | 10 | 36759 (1)| 00:08:35 |
| 19 | TABLE ACCESS FULL | CPT | 10 | 0 (0)| 00:00:01 |
| 20 | BUFFER SORT | | 10 | 367K (1)| 01:25:46 |
| 21 | TABLE ACCESS FULL | CPT | 10 | 0 (0)| 00:00:01 |
| 22 | BUFFER SORT | | 10 | 3675K (1)| 14:17:31 |
| 23 | TABLE ACCESS FULL | CPT | 10 | 0 (0)| 00:00:01 |
Statistics
0 recursive calls
0 db block gets
24 consistent gets
0 physical reads
0 redo size
522 bytes sent via SQL*Net to client
488 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
7 sorts (memory)
0 sorts (disk)
1 rows processed
COUNT(*)
100000000
Elapsed: 00:00:24.56
-- trace file output (profahr_ora_33161638_CPT_PERF.trc)
Dump file /oracle/oradata/PROFAHR/admin/udump/profahr_ora_33161638_CPT_PERF.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /oracle/product/10204
System name: AIX
Node name: as07902
Release: 1
Version: 6
Machine: 00C52E704C00
Instance name: PROFAHR
Redo thread mounted by this instance: 1
Oracle process number: 20
Unix process pid: 33161638, image: oracle@as07902 (TNS V1-V3)
*** 2011-06-14 10:34:29.296
*** SESSION ID:(45.14300) 2011-06-14 10:34:29.296
*** SERVICE NAME:(SYS$USERS) 2011-06-14 10:34:29.296
*** MODULE NAME:(SQL*Plus) 2011-06-14 10:34:29.296
*** ACTION NAME:() 2011-06-14 10:34:29.296
PARSING IN CURSOR #24 len=59 dep=0 uid=5 oct=3 lid=5 tim=7913167696462 hv=1413788073 ad='16668590'
select count(*) from cpt, cpt, cpt, cpt, cpt, cpt, cpt, cpt
END OF STMT
PARSE #24:c=10000,e=14470,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=7913167696460
BINDS #24:
EXEC #24:c=0,e=51,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=7913167696555
WAIT #24: nam='SQL*Net message to client' ela= 0 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=7913167696614
FETCH #24:c=19020000,e=23797054,p=0,cr=24,cu=0,mis=0,r=1,dep=0,og=1,tim=7913191493688
WAIT #24: nam='SQL*Net message from client' ela= 381 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=7913191494477
FETCH #24:c=0,e=1,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=7913191494529
WAIT #24: nam='SQL*Net message to client' ela= 3 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=7913191494547
WAIT #24: nam='SQL*Net message from client' ela= 435 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=7913191494997
STAT #24 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=24 pr=0 pw=0 time=23797048 us)'
STAT #24 id=2 cnt=100000000 pid=1 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=24 pr=0 pw=0 time=246 us)'
STAT #24 id=3 cnt=10000000 pid=2 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=21 pr=0 pw=0 time=220 us)'
STAT #24 id=4 cnt=1000000 pid=3 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=18 pr=0 pw=0 time=165 us)'
STAT #24 id=5 cnt=100000 pid=4 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=15 pr=0 pw=0 time=146 us)'
STAT #24 id=6 cnt=10000 pid=5 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=12 pr=0 pw=0 time=127 us)'
STAT #24 id=7 cnt=1000 pid=6 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=9 pr=0 pw=0 time=106 us)'
STAT #24 id=8 cnt=100 pid=7 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=6 pr=0 pw=0 time=183 us)'
STAT #24 id=9 cnt=10 pid=8 pos=1 obj=53251 op='TABLE ACCESS FULL CPT (cr=3 pr=0 pw=0 time=181 us)'
STAT #24 id=10 cnt=100 pid=8 pos=2 obj=0 op='BUFFER SORT (cr=3 pr=0 pw=0 time=42 us)'
STAT #24 id=11 cnt=10 pid=10 pos=1 obj=53251 op='TABLE ACCESS FULL CPT (cr=3 pr=0 pw=0 time=11 us)'
STAT #24 id=12 cnt=1000 pid=7 pos=2 obj=0 op='BUFFER SORT (cr=3 pr=0 pw=0 time=55 us)'
STAT #24 id=13 cnt=10 pid=12 pos=1 obj=53251 op='TABLE ACCESS FULL CPT (cr=3 pr=0 pw=0 time=6 us)'
STAT #24 id=14 cnt=10000 pid=6 pos=2 obj=0 op='BUFFER SORT (cr=3 pr=0 pw=0 time=489 us)'
STAT #24 id=15 cnt=10 pid=14 pos=1 obj=53251 op='TABLE ACCESS FULL CPT (cr=3 pr=0 pw=0 time=10 us)'
STAT #24 id=16 cnt=100000 pid=5 pos=2 obj=0 op='BUFFER SORT (cr=3 pr=0 pw=0 time=4588 us)'
STAT #24 id=17 cnt=10 pid=16 pos=1 obj=53251 op='TABLE ACCESS FULL CPT (cr=3 pr=0 pw=0 time=9 us)'
STAT #24 id=18 cnt=1000000 pid=4 pos=2 obj=0 op='BUFFER SORT (cr=3 pr=0 pw=0 time=46335 us)'
STAT #24 id=19 cnt=10 pid=18 pos=1 obj=53251 op='TABLE ACCESS FULL CPT (cr=3 pr=0 pw=0 time=5 us)'
STAT #24 id=20 cnt=10000000 pid=3 pos=2 obj=0 op='BUFFER SORT (cr=3 pr=0 pw=0 time=459465 us)'
STAT #24 id=21 cnt=10 pid=20 pos=1 obj=53251 op='TABLE ACCESS FULL CPT (cr=3 pr=0 pw=0 time=7 us)'
STAT #24 id=22 cnt=100000000 pid=2 pos=2 obj=0 op='BUFFER SORT (cr=3 pr=0 pw=0 time=4616973 us)'
STAT #24 id=23 cnt=10 pid=22 pos=1 obj=53251 op='TABLE ACCESS FULL CPT (cr=3 pr=0 pw=0 time=9 us)' And now for the 11g database:
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 IBM/AIX RISC System/6000: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
[...preparation...]
Elapsed: 00:00:09.51
[...first execution plan...]
Statistics
1 recursive calls
0 db block gets
16 consistent gets
0 physical reads
0 redo size
526 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
7 sorts (memory)
0 sorts (disk)
1 rows processed
PDIGIT:SQL> /
Elapsed: 00:00:09.08
Execution Plan
Plan hash value: 2108355742
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 3020K (1)| 10:04:10 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | MERGE JOIN CARTESIAN | | 100M| 3020K (1)| 10:04:10 |
| 3 | MERGE JOIN CARTESIAN | | 10M| 302K (1)| 01:00:26 |
| 4 | MERGE JOIN CARTESIAN | | 1000K| 30218 (1)| 00:06:03 |
| 5 | MERGE JOIN CARTESIAN | | 100K| 3029 (1)| 00:00:37 |
| 6 | MERGE JOIN CARTESIAN | | 10000 | 308 (1)| 00:00:04 |
| 7 | MERGE JOIN CARTESIAN | | 1000 | 35 (0)| 00:00:01 |
| 8 | MERGE JOIN CARTESIAN| | 100 | 6 (0)| 00:00:01 |
| 9 | TABLE ACCESS FULL | CPT | 10 | 2 (0)| 00:00:01 |
| 10 | BUFFER SORT | | 10 | 4 (0)| 00:00:01 |
| 11 | TABLE ACCESS FULL | CPT | 10 | 0 (0)| 00:00:01 |
| 12 | BUFFER SORT | | 10 | 35 (0)| 00:00:01 |
| 13 | TABLE ACCESS FULL | CPT | 10 | 0 (0)| 00:00:01 |
| 14 | BUFFER SORT | | 10 | 308 (1)| 00:00:04 |
| 15 | TABLE ACCESS FULL | CPT | 10 | 0 (0)| 00:00:01 |
| 16 | BUFFER SORT | | 10 | 3028 (1)| 00:00:37 |
| 17 | TABLE ACCESS FULL | CPT | 10 | 0 (0)| 00:00:01 |
| 18 | BUFFER SORT | | 10 | 30217 (1)| 00:06:03 |
| 19 | TABLE ACCESS FULL | CPT | 10 | 0 (0)| 00:00:01 |
| 20 | BUFFER SORT | | 10 | 302K (1)| 01:00:26 |
| 21 | TABLE ACCESS FULL | CPT | 10 | 0 (0)| 00:00:01 |
| 22 | BUFFER SORT | | 10 | 3020K (1)| 10:04:10 |
| 23 | TABLE ACCESS FULL | CPT | 10 | 0 (0)| 00:00:01 |
Statistics
0 recursive calls
0 db block gets
16 consistent gets
0 physical reads
0 redo size
526 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
7 sorts (memory)
0 sorts (disk)
1 rows processed
COUNT(*)
100000000
Elapsed: 00:00:28.85
-- trace file output (PDIGIT_ora_27066482_CPT_PERF.trc)
Trace file /oracle/oradata/PDIGIT/diag/rdbms/pdigit/PDIGIT/trace/PDIGIT_ora_27066482_CPT_PERF.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /oracle/product/11202
System name: AIX
Node name: as07902
Release: 1
Version: 6
Machine: 00C52E704C00
Instance name: PDIGIT
Redo thread mounted by this instance: 1
Oracle process number: 31
Unix process pid: 27066482, image: oracle@as07902 (TNS V1-V3)
*** 2011-06-14 10:24:50.724
*** SESSION ID:(331.21951) 2011-06-14 10:24:50.724
*** CLIENT ID:() 2011-06-14 10:24:50.724
*** SERVICE NAME:(SYS$USERS) 2011-06-14 10:24:50.724
*** MODULE NAME:(SQL*Plus) 2011-06-14 10:24:50.724
*** ACTION NAME:() 2011-06-14 10:24:50.724
PARSING IN CURSOR #4578508928 len=59 dep=0 uid=5 oct=3 lid=5 tim=8102505154564 hv=1413788073 ad='70000002e203ff8' sqlid='fqkgnaja49cd9'
select count(*) from cpt, cpt, cpt, cpt, cpt, cpt, cpt, cpt
END OF STMT
PARSE #4578508928:c=10000,e=18215,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=2108355742,tim=8102505154562
EXEC #4578508928:c=0,e=65,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2108355742,tim=8102505154716
WAIT #4578508928: nam='SQL*Net message to client' ela= 6 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=8102505154838
FETCH #4578508928:c=21270000,e=28828643,p=0,cr=16,cu=0,mis=0,r=1,dep=0,og=1,plh=2108355742,tim=8102533983509
STAT #4578508928 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=16 pr=0 pw=0 time=28828629 us)'
STAT #4578508928 id=2 cnt=100000000 pid=1 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=16 pr=0 pw=0 time=73243303 us cost=3020823 size=0 card=100000000)'
STAT #4578508928 id=3 cnt=10000000 pid=2 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=14 pr=0 pw=0 time=8010638 us cost=302092 size=0 card=10000000)'
STAT #4578508928 id=4 cnt=1000000 pid=3 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=12 pr=0 pw=0 time=818447 us cost=30218 size=0 card=1000000)'
STAT #4578508928 id=5 cnt=100000 pid=4 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=10 pr=0 pw=0 time=86497 us cost=3029 size=0 card=100000)'
STAT #4578508928 id=6 cnt=10000 pid=5 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=8 pr=0 pw=0 time=9531 us cost=308 size=0 card=10000)'
STAT #4578508928 id=7 cnt=1000 pid=6 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=6 pr=0 pw=0 time=1519 us cost=35 size=0 card=1000)'
STAT #4578508928 id=8 cnt=100 pid=7 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=4 pr=0 pw=0 time=327 us cost=6 size=0 card=100)'
STAT #4578508928 id=9 cnt=10 pid=8 pos=1 obj=22700 op='TABLE ACCESS FULL CPT (cr=2 pr=0 pw=0 time=353 us cost=2 size=0 card=10)'
STAT #4578508928 id=10 cnt=100 pid=8 pos=2 obj=0 op='BUFFER SORT (cr=2 pr=0 pw=0 time=176 us cost=4 size=0 card=10)'
STAT #4578508928 id=11 cnt=10 pid=10 pos=1 obj=22700 op='TABLE ACCESS FULL CPT (cr=2 pr=0 pw=0 time=27 us cost=0 size=0 card=10)'
STAT #4578508928 id=12 cnt=1000 pid=7 pos=2 obj=0 op='BUFFER SORT (cr=2 pr=0 pw=0 time=436 us cost=35 size=0 card=10)'
STAT #4578508928 id=13 cnt=10 pid=12 pos=1 obj=22700 op='TABLE ACCESS FULL CPT (cr=2 pr=0 pw=0 time=8 us cost=0 size=0 card=10)'
STAT #4578508928 id=14 cnt=10000 pid=6 pos=2 obj=0 op='BUFFER SORT (cr=2 pr=0 pw=0 time=2941 us cost=308 size=0 card=10)'
STAT #4578508928 id=15 cnt=10 pid=14 pos=1 obj=22700 op='TABLE ACCESS FULL CPT (cr=2 pr=0 pw=0 time=8 us cost=0 size=0 card=10)'
STAT #4578508928 id=16 cnt=100000 pid=5 pos=2 obj=0 op='BUFFER SORT (cr=2 pr=0 pw=0 time=27468 us cost=3028 size=0 card=10)'
STAT #4578508928 id=17 cnt=10 pid=16 pos=1 obj=22700 op='TABLE ACCESS FULL CPT (cr=2 pr=0 pw=0 time=8 us cost=0 size=0 card=10)'
STAT #4578508928 id=18 cnt=1000000 pid=4 pos=2 obj=0 op='BUFFER SORT (cr=2 pr=0 pw=0 time=240715 us cost=30217 size=0 card=10)'
STAT #4578508928 id=19 cnt=10 pid=18 pos=1 obj=22700 op='TABLE ACCESS FULL CPT (cr=2 pr=0 pw=0 time=7 us cost=0 size=0 card=10)'
STAT #4578508928 id=20 cnt=10000000 pid=3 pos=2 obj=0 op='BUFFER SORT (cr=2 pr=0 pw=0 time=2462884 us cost=302092 size=0 card=10)'
STAT #4578508928 id=21 cnt=10 pid=20 pos=1 obj=22700 op='TABLE ACCESS FULL CPT (cr=2 pr=0 pw=0 time=7 us cost=0 size=0 card=10)'
STAT #4578508928 id=22 cnt=100000000 pid=2 pos=2 obj=0 op='BUFFER SORT (cr=2 pr=0 pw=0 time=21633068 us cost=3020822 size=0 card=10)'
STAT #4578508928 id=23 cnt=10 pid=22 pos=1 obj=22700 op='TABLE ACCESS FULL CPT (cr=2 pr=0 pw=0 time=9 us cost=0 size=0 card=10)'
WAIT #4578508928: nam='SQL*Net message from client' ela= 513 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=8102533985627
FETCH #4578508928:c=0,e=7,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=2108355742,tim=8102533985752
WAIT #4578508928: nam='SQL*Net message to client' ela= 7 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=8102533985803
WAIT #4578508928: nam='SQL*Net message from client' ela= 485 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=8102533986331
CLOSE #4578508928:c=0,e=35,dep=0,type=0,tim=8102533986415 Remarks:
a) I omited the autoexplain plan for the first execution as it is exactly the same as the second one.
b) Several non relevant messages from sql*plus were also eliminated.
c) I also deleted some non relevant lines out of the trace files.
d) No tkprof is added because it delivers no additional value.
Observations:
1) Execution time is
Version 1st 2nd trace
10g 7.80 8.03 24.56
11g 9.51 9.08 28.85
detla 22% 13% 17%2) Execution time increases significantly when tracing is enabled, although the generated trace file is really tiny.
Thanks for your help!
Regards,
Daniel -
"Rows" statistics from STAT in trace event 10046, Oracle 11g.
Hi, all!
Why "Rows" statistics in STAT are different for 10g and 11g?
I have two database with version 10g and 11g, with the same data.
I executed some pl/sql code with tracing 10046 level 8.
And I have different result when obtain raw trace.
In 10g I obtain rows statistics for all executions - Rows= 7.
In 11g I obtain rows statistics for first executions - Rows= 1. Why?
See my example:
declare
type t_name_tbl is table of varchar2(30) index by binary_integer;
v_name_tbl t_name_tbl;
v_len number := 10;
begin
execute immediate 'alter session set timed_statistics = true ';
execute immediate 'alter session set statistics_level=all ';
execute immediate 'alter session set max_dump_file_size = unlimited ';
execute immediate 'alter session set events ''10046 trace name context forever,level 8'' ';
loop
select cour_name bulk collect
into v_name_tbl
from country t
where length(t.cour_name) = v_len;
exit when v_len = 0;
v_len := v_len - 1;
for i in 1 .. v_name_tbl.count loop
dbms_output.put_line(v_name_tbl(i));
end loop;
end loop;
end;Result Tkprof for Oracle 10g:
SELECT COUR_NAME
FROM
COUNTRY T WHERE LENGTH(T.COUR_NAME) = :B1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 11 0.00 0.00 0 0 0 0
Fetch 11 0.01 0.00 0 44 0 7
total 23 0.01 0.00 0 44 0 7
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 649 (recursive depth: 1)
Rows Row Source Operation
7 TABLE ACCESS FULL COUNTRY (cr=44 pr=0 pw=0 time=1576 us)Result Tkprof for Oracle 11g:
SQL ID: 3kqmkg8jp5nwk
Plan Hash: 1371235632
SELECT COUR_NAME
FROM
COUNTRY T WHERE LENGTH(T.COUR_NAME) = :B1
call count cpu elapsed disk query current rows
Parse 1 0.01 0.00 0 0 0 0
Execute 11 0.02 0.01 0 0 0 0
Fetch 11 0.00 0.01 3 44 0 7
total 23 0.03 0.02 3 44 0 7
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 82 (recursive depth: 1)
Rows Row Source Operation
1 TABLE ACCESS FULL COUNTRY (cr=4 pr=3 pw=0 time=0 us cost=2 size=44 card=2)Were can I read about it?Oracle 11g by default writes the execution plan (the STAT lines in the raw trace file) after the first execution of the SQL statement, while prior to 11g the execution plan is written only when the cursor is closed.
The behavior in 11g can be controlled by changing the PLAN_STAT parameter of the call that enables the trace from the default value of FIRST_EXECUTION to ALL_EXECUTIONS:
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28419/d_sessio.htm#i1010518
Charles Hooper
Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.
Edited by: Charles Hooper on Aug 9, 2010 3:33 PM
Default value on 11g is FIRST_EXECUTION, while the behavior prior to 11g is ALL_EXECUTIONS - corrected the incomplete sentence. -
Importing Statistics - Oracle 11g upgrade
Hi,
We are in the middle for planning for migration of oracle 9.2.0.8 database hosted in HP-UX to oracle 11gR2 to Linix. The database size is 1 TB ( 400GB of table data & 600GB of index data).
Please let us know whether we can use the option of import/export the statistics from the Oraclr 9i to oradle 11g database. The database is highly OLTP/Batch. Will it be any Query performance problem due to the statistics import from oracle 9i to oracle 11g.
Any suggestion are welcome and let me know if you need any more information.
thanks,
MaheshHello,
Please let us know whether we can use the option of import/export the statistics from the Oraclr 9i to oradle 11g databaseIf I were you, when the data are imported to the 11g Database I would refresh the Statistics by using the dbms_stats Package.
Then, you can test the most common queries on the new Database. If some perfomance troubles appear, you can use classical tools (Statspack, Explain Plan, TKPROF,...) or some useful tools you have in 11g as SQL Tuning Advisor or SQL Access Advisor :
http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/sql_tune.htm#PFGRF028
http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/advisor.htm#PFGRF008
Hope this help.
Best regards,
Jean-Valentin -
SQL performance slow -- oracle 10g to oracle 11g
Hi,
We are have two development server, here we can call server10 and server11.
Server’s having same hardware and OS, but different oracle version, server 10 and server 11 having oracle 10g and oracle 11g respectively.
Problem, when you run sql query in oracle 11g it’s very slow compare to oracle 10g server.
Here I have checked
1)     sga size – comparatively 11g size is big
2)Â Â Â Â Â no full table scan
OS – SUN
DB: 11.1.0.7.0, 10.2.0.4.0mmee wrote:
Hi,
We are have two development server, here we can call server10 and server11.
Server’s having same hardware and OS, but different oracle version, server 10 and server 11 having oracle 10g and oracle 11g respectively.
Problem, when you run sql query in oracle 11g it’s very slow compare to oracle 10g server.
Here I have checked
1)     sga size – comparatively 11g size is big
2)Â Â Â Â Â no full table scan
OS – SUN
DB: 11.1.0.7.0, 10.2.0.4.0If the query is running slow, the sga size should not be the first thing to check. PLease post the execution plans of the queries from both the servers. Please try to post the tkprof output of the trace of both. The reason for this that explain plan may lie to us about what has happened but trace would be the real picture only.
HTH
Aman....
PS: Don't forget to use the code tag and using the Preview tab to see how the code looks. A better formatted post would most likely get better attention and response. -
Performance Tuning for BAM 11G
Hi All
Can anyone guide me for any documents or any tips realted to performance tuning for BAM 11G on on LinuxIt would help to know if you have any specific issue. There are number of tweaks all they way from DB to Browser.
Few key things to follow:
1. Make sure you create index on DO. If there are too much old data in the DO and not useful then periodically delete it. Similar to relational database indexes, defining indexes in Oracle BAM creates and maintains an ordered list of data object elements for fast retrieval.
2. Ensure that IE setup to do automatic caching. This will help with reducing server round trips.
3. Tune DB performance. This would typically require DBA. Identify the SQL statements most likely to be causing the waits by looking at
the drilldown Top SQL Statements Ordered by Wait Time. Use SQL Analyze, EXPLAIN PLAN, or the tkprof utility to tune the queries that were identified.
Check the Dataobject tables involved in the query for missing indexes.
4. Use batching (this is on by default for most cases)
5. Fast network
6. Use profilers to look at machine load/cpu usage and distribute components on different boxes if needed.
7. Use better server AND client hardware. BAM dashboard are heavy users of ajax/javascript logic on the client -
Tkprof output -- 10.2.0.4
Hi All,
I am facing a problem at the client side.The EOD process is taking long time.The database version is 10.2.0.4 and the OS is windows server 2003 R1
03:57:20database >show parameter optimizer
NAME TYPE VALUE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.4
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 10
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
03:57:20database >
03:57:20database >show parameter db_file_multi
NAME TYPE VALUE
db_file_multiblock_read_count integer 64
03:57:20database >
03:57:20database >show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192
03:57:20database >
03:57:20database >column sname format a20
03:57:20database >column pname format a20
03:57:20database >column pval2 format a20
03:57:20database >
03:57:20database >select
03:57:20 2 sname
03:57:20 3 , pname
03:57:20 4 , pval1
03:57:20 5 , pval2
03:57:20 6 from
03:57:20 7 sys.aux_stats$;
SNAME PNAME PVAL1 PVAL2
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 03-14-2008 19:37
SYSSTATS_INFO DSTOP 03-14-2008 19:37
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 1171.76471
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SYSSTATS_MAIN MAXTHR
SYSSTATS_MAIN SLAVETHR
13 rows selected.
04:01:38database >sho sga
Total System Global Area 872415232 bytes
Fixed Size 1299660 bytes
Variable Size 327158580 bytes
Database Buffers 536870912 bytes
Redo Buffers 7086080 bytes
SGA_TARGET is set to 876609536
============================================================
TKPROF: Release 10.2.0.4.0 - Production on Fri Apr 3 20:00:02 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: E:\oracle\product\10.2.0\admin\user\udump\user_ora_456.trc
Sort options: default
SELECT *
FROM
CITY_CODES_UTI
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 7750 5.39 5.06 0 0 0 0
Fetch 7750 14.48 14.35 0 23250 0 31000
total 15500 19.87 19.42 0 23250 0 31000
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 61 (user) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 TABLE ACCESS MODE: ANALYZED (FULL) OF 'CITY_CODES_UTI' (TABLE)
SELECT BIN,BANK_CODE
FROM
BIN_BANK ORDER BY BANK_CODE
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 7750 5.53 5.55 0 0 0 0
Fetch 7750 14.60 14.07 0 7750 0 69750
total 15500 20.14 19.63 0 7750 0 69750
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 61 (user) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 SORT (ORDER BY)
0 INDEX MODE: ANALYZED (FULL SCAN) OF 'BIN_BANK_IDX' (INDEX)
SELECT *
FROM
BANK_CURRENCY WHERE BANK_CODE=:B2 AND CUR_CODE=:B1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 7750 5.48 4.97 0 0 0 0
Fetch 7750 4.29 3.85 0 7750 0 7750
total 15500 9.78 8.83 0 7750 0 7750
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 61 (user) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'PK_BANK_CUR_CODE'
(INDEX (UNIQUE))
SELECT CARD_NO
FROM
TEST_CARDS WHERE CARD_NO=:B1 ORDER BY CARD_NO
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 54346 45.56 41.30 0 0 0 0
Fetch 54346 124.48 122.01 0 163038 0 70
total 108692 170.04 163.31 0 163038 0 70
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 61 (user) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 SORT (ORDER BY)
0 TABLE ACCESS MODE: ANALYZED (FULL) OF 'TEST_CARDS' (TABLE)
SELECT NVL(DCC_FLAG,'N')
FROM
BANK_MASTER WHERE BANK_CODE = :B1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 27208 18.57 17.01 0 0 0 0
Fetch 27208 15.62 13.78 0 54416 0 27208
total 54416 34.20 30.80 0 54416 0 27208
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 61 (user) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'BANK_MASTER'
(TABLE)
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'SYS_C006437' (INDEX
(UNIQUE))
SELECT DQP_VALIDATION
FROM
BANK_RPTFORMAT WHERE BANK_CODE = :B1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 27208 17.87 16.04 0 0 0 0
Fetch 27208 30.71 29.51 0 81624 0 27208
total 54416 48.59 45.55 0 81624 0 27208
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 61 (user) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 TABLE ACCESS MODE: ANALYZED (FULL) OF 'BANK_RPTFORMAT' (TABLE)
SELECT SUBSTR(TRANS, 4, 2)
FROM
RAW_BTH WHERE BTHSEQ = :B1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 42708 30.01 27.46 0 0 0 0
Fetch 42708 82.06 6168.61 2014 170918 0 42708
total 85416 112.07 6196.08 2014 170918 0 42708
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 61 (user) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'RAW_BTH'
(TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'RAW_BTH_IDX' (INDEX)
SELECT BTH_KEY,BTH_NO
FROM
BTH_REG WHERE BTH_KEY = :B1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 8219 6.09 5.21 0 0 0 0
Fetch 8219 4.60 4.54 0 16559 0 1266
total 16438 10.70 9.75 0 16559 0 1266
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 61 (user) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'BTH_REG_BTH_KEY_IDX'
(INDEX)
SELECT COUNT(*)
FROM
BTH_REG WHERE BTH_KEY=:B2 ||:B1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 8195 6.93 6.52 0 0 0 0
Fetch 8195 5.70 4.88 0 16454 0 8195
total 16390 12.64 11.41 0 16454 0 8195
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 61 (user) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 SORT (AGGREGATE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'BTH_REG_IDX' (INDEX)
SELECT *
FROM
ME_UTI WHERE MID_UTI=:B1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 8195 6.37 6.20 0 0 0 0
Fetch 8195 8983.73 9067.57 0 13595505 0 7750
total 16390 8990.10 9073.78 0 13595505 0 7750
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 61 (user) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 VIEW OF 'index$_join$_002' (VIEW)
0 HASH JOIN
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'COMP' (INDEX)
0 INDEX MODE: ANALYZED (FAST FULL SCAN) OF
'CMPPK_MERCHANT_MASTER' (INDEX (UNIQUE))
SELECT TRANS,BANK_CODE,BTHSEQ,VALIDITY_FLAG
FROM
RAW_BTH ORDER BY BANK_CODE,BTHSEQ
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 536 12.39 13.24 1819 0 0 53600
total 536 12.39 13.24 1819 0 0 53600
Misses in library cache during parse: 0
Parsing user id: 61 (user) (recursive depth: 1)
UPDATE BTH_REG SET BTH_NO=:B3
WHERE
BTH_KEY=:B2 ||:B1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1242 5.78 5.52 0 2504 8755 1242
Fetch 0 0.00 0.00 0 0 0 0
total 1242 5.78 5.52 0 2504 8755 1242
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 61 (user) (recursive depth: 1)
Rows Execution Plan
0 UPDATE STATEMENT MODE: ALL_ROWS
0 UPDATE OF 'BTH_REG'
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'BTH_REG_BTH_KEY_IDX'
(INDEX)
SELECT TRANS,BANK_CODE,BTHSEQ
FROM
RAW_BTH WHERE BTHSEQ >= :B2 AND BTHSEQ <= :B1 ORDER BY BANK_CODE,BTHSEQ
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 469 0.28 0.33 0 0 0 0
Fetch 472 154.29 156.48 124 495389 0 3146
total 941 154.57 156.81 124 495389 0 3146
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 61 (user) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 FILTER
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'RAW_BTH'
(TABLE)
0 INDEX MODE: ANALYZED (FULL SCAN) OF
'RAW_BTH_BKCODE_SEQ_IDX' (INDEX)
********************************************************************************Especially in the below query the logical I/O is alot along with the elapsed time
SELECT *
FROM
ME_UTI WHERE MID_UTI=:B1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 8195 6.37 6.20 0 0 0 0
Fetch 8195 8983.73 9067.57 0 13595505 0 7750
total 16390 8990.10 9073.78 0 13595505 0 7750
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 61 (user) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 VIEW OF 'index$_join$_002' (VIEW)
0 HASH JOIN
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'COMP' (INDEX)
0 INDEX MODE: ANALYZED (FAST FULL SCAN) OF
'CMPPK_MERCHANT_MASTER' (INDEX (UNIQUE))
04:16:43database >@index_col
Enter value for table_name: ACQ_MERCHANT_MASTER
Enter value for owner: user
TABLE_NAME INDEX_NAME COLUMN_NAME COLUMN_POSITION
ACQ_MERCHANT_MASTER COMP DBANAME 2
ACQ_MERCHANT_MASTER COMP MCC 3
ACQ_MERCHANT_MASTER COMP BRANCH_CODE 4
ACQ_MERCHANT_MASTER COMP MISC10 5
ACQ_MERCHANT_MASTER COMP FIRC_FLAG 6
ACQ_MERCHANT_MASTER COMP MCA_FLAG 7
ACQ_MERCHANT_MASTER MEMASTTERMINALID TERMINAL_ID 1
ACQ_MERCHANT_MASTER CMPPK_MERCHANT_MASTER MERCHANT_CODE 1
ACQ_MERCHANT_MASTER CMPPK_MERCHANT_MASTER BANK_CODE 2
ACQ_MERCHANT_MASTER COMP BANK_CODE 1
10 rows selected.The ME_UTI is a view. The text of the view is
04:07:41database >select VIEW_NAME,TEXT from dba_views where view_name='ME_UTI';
VIEW_NAME TEXT
ME_UTI Select substr(lpad(merchant_code,15,'0'),4,12) MID_UTI,substr(dbaname,1,40) ME_NAME
from ACQ_MERCHANT_MASTER
where bank_code='00013'What are your suggestions????? What can be done.
Anand>
Anand,
first of all I think that the row-by-row processing issue identified by others is much more significant to your batch processing run time than any of the things that I've mentioned. So you quite likely achieve the biggest gain in performance by re-writing the process to use plain SQL as much as possible instead of PL/SQL loops.
That said, the parameters that I've questioned might be very reasonable for your particular environment. I just wanted to ask how you arrived at these values, e.g. measured your average index / block caching pattern to arrive at these values or similar.
I agree with you.Higher db_file_multiblock_read_count and lower optimizer_index_cost_adj will make FTS more cheaper.No, not really. Your index based costs are 10 times lower, but your FTS costs are not even two times lower compared to default settings, so your current settings actually favor index access significantly.
Consider:
SQL>
SQL> exec dbms_random.seed(0)
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.01
SQL>
SQL> drop table t1 purge;
Table dropped.
Elapsed: 00:00:00.16
SQL>
SQL> create table t1
2 pctfree 99
3 pctused 1
4 -- tablespace test_2k
5 -- tablespace test_4k
6 tablespace test_8k
7 -- tablespace test_16k
8 as
9 with generator as (
10 select --+ materialize
11 rownum id
12 from all_objects
13 where rownum <= 3000
14 )
15 select
16 /*+ ordered use_nl(v2) */
17 rownum id,
18 trunc(100 * dbms_random.normal) val,
19 rpad('x',100) padding
20 from
21 generator v1,
22 generator v2
23 where
24 rownum <= 10000
25 ;
Table created.
Elapsed: 00:00:02.53
SQL>
SQL> begin
2 dbms_stats.gather_table_stats(
3 user,
4 't1',
5 cascade => true,
6 estimate_percent => null,
7 method_opt => 'for all columns size 1'
8 );
9 end;
10 /
PL/SQL procedure successfully completed.
Elapsed: 00:00:02.58
SQL>
SQL> select
2 sum(bytes)/1024/1024 as size_mb
3 from
4 user_segments
5 where
6 segment_name = 'T1';
SIZE_MB
79
Elapsed: 00:00:00.24
SQL>
SQL> -- default NOWORKLOAD system statistics
SQL> column sname format a20
SQL> column pname format a20
SQL> column pval2 format a20
SQL>
SQL> select
2 sname
3 , pname
4 , pval1
5 , pval2
6 from
7 sys.aux_stats$;
SNAME PNAME PVAL1 PVAL2
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 03-19-2009 18:28
SYSSTATS_INFO DSTOP 03-19-2009 18:28
SYSSTATS_INFO FLAGS 0
SYSSTATS_MAIN CPUSPEEDNW 408,478
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SYSSTATS_MAIN MAXTHR
SYSSTATS_MAIN SLAVETHR
13 rows selected.
Elapsed: 00:00:00.03
SQL>
SQL> alter session set db_file_multiblock_read_count = 8;
Session altered.
Elapsed: 00:00:00.01
SQL>
SQL> explain plan for
2 select
3 max(val)
4 from
5 t1;
Explained.
Elapsed: 00:00:00.01
SQL>
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3724264953
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 4 | 2725 (1)| 00:00:33 |
| 1 | SORT AGGREGATE | | 1 | 4 | | |
| 2 | TABLE ACCESS FULL| T1 | 10000 | 40000 | 2725 (1)| 00:00:33 |
9 rows selected.
Elapsed: 00:00:00.12
SQL>
SQL> rollback;
Rollback complete.
Elapsed: 00:00:00.01
SQL>
SQL> alter session set db_file_multiblock_read_count = 64;
Session altered.
Elapsed: 00:00:00.01
SQL>
SQL> explain plan for
2 select
3 max(val)
4 from
5 t1;
Explained.
Elapsed: 00:00:00.02
SQL>
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3724264953
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 4 | 1814 (1)| 00:00:22 |
| 1 | SORT AGGREGATE | | 1 | 4 | | |
| 2 | TABLE ACCESS FULL| T1 | 10000 | 40000 | 1814 (1)| 00:00:22 |
9 rows selected.
Elapsed: 00:00:00.12
SQL>
SQL> rollback;
Rollback complete.
Elapsed: 00:00:00.01
SQL>
SQL> create index t1_idx on t1 (id);
Index created.
Elapsed: 00:00:01.70
SQL>
SQL> alter table t1 modify id not null;
Table altered.
Elapsed: 00:00:01.63
SQL>
SQL> alter session set optimizer_index_cost_adj = 100;
Session altered.
Elapsed: 00:00:00.00
SQL>
SQL> explain plan for
2 select /*+ index (t1) */
3 *
4 from
5 t1
6 order by
7 id;
Explained.
Elapsed: 00:00:00.07
SQL>
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 510677707
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 10000 | 1054K| 10037 (1)| 00:02:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T1 | 10000 | 1054K| 10037 (1)| 00:02:01 |
| 2 | INDEX FULL SCAN | T1_IDX | 10000 | | 22 (0)| 00:00:01 |
9 rows selected.
Elapsed: 00:00:00.14
SQL>
SQL> rollback;
Rollback complete.
Elapsed: 00:00:00.01
SQL>
SQL> alter session set optimizer_index_cost_adj = 10;
Session altered.
Elapsed: 00:00:00.00
SQL>
SQL> -- no hint required, will use index anyway
SQL> explain plan for
2 select
3 *
4 from
5 t1
6 order by
7 id;
Explained.
Elapsed: 00:00:00.01
SQL>
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 510677707
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 10000 | 1054K| 1004 (1)| 00:00:13 |
| 1 | TABLE ACCESS BY INDEX ROWID| T1 | 10000 | 1054K| 1004 (1)| 00:00:13 |
| 2 | INDEX FULL SCAN | T1_IDX | 10000 | | 2 (0)| 00:00:01 |
9 rows selected.
Elapsed: 00:00:00.10
SQL>
SQL> rollback;
Rollback complete.
Elapsed: 00:00:00.00
SQL> As you can see the index costs are lower by an order of magnitude, making the optimizer favor the index full scan instead of the FTS (full table scan) when using the OICA (optimizer_index_cost_adj) setting of 10, even when using the MBRC (db_file_multiblock_read_count) setting of 64, because the higher MBRC setting reduces the FTS costs only from ~2700 to ~1800.
The moderate reduction in FTS costs is caused by the formula used by the NOWORKLOAD system statistics to derive the MREADTIM and SREADTIM values from the IOSEEKTIM, MBRC, DB_BLOCK_SIZE and IOTFRSPEED values.
When MBRC = 8:
SREADTIM = IOSEEKTIM + DB_BLOCK_SIZE/IOTFRSPEED = 10 + 8192 / 4096 = 10 + 2 = 12ms
MREADTIM = IOSEEKTIM + MBRC * DB_BLOCK_SIZE/IOTFRSPEED = 10 + 8 * 8192 / 4096 = 10 + 16 = 26ms
FTS cost for reading 10,000 blocks (80MB):
10,000 / 8 * MREADTIM / SREADTIM = 1,250 * 26 / 12 = 2,709 (+ CPU cost)
When MBRC = 64:
SREADTIM = IOSEEKTIM + DB_BLOCK_SIZE/IOTFRSPEED = 10 + 8192 / 4096 = 10 + 2 = 12ms
MREADTIM = IOSEEKTIM + MBRC * DB_BLOCK_SIZE/IOTFRSPEED = 10 + 64 * 8192 / 4096 = 10 + 128 = 138ms
FTS cost for reading 10,000 blocks (80MB):
10,000 / 64 * MREADTIM / SREADTIM = 157 * 138 / 12 = 1,806 (+ CPU cost)
So in a nutshell using NOWORKLOAD system statistics the derived MREADTIM is quite large, therefore the net reduction in cost is moderate when increasing the MBRC.
Furthermore when using a low OICA setting you have the inherent risk that due to the reduction in index cost multiple indexes can end up with the same cost making the optimizer choose a bad index over an good index since indexes having the same cost will be chosen by index name...
That's one of the major drawbacks of low OICA settings.
How did you know that we are using default NOWORKLOAD system statistics.
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096These are the default settings, a seek time of 10ms and 4096 bytes per millisecond transfer speed, which is a very conservative assumption (4MB/sec. transfer speed)
because it looks like that your trace file doesn't contain any STATS lines because all cursors were still held open when the tracing was disabledCan you elaborate more.Up to 10.2 Oracle writes STAT lines into the trace file only if the corresponding cursor got closed. Since your PL/SQL procedure obviously benefits from the PL/SQL cursor cache I assume that the cursors have not been closed. You can check the generated trace file for STAT lines representing the actual row source operation statistics.
Note that 11g changes this, and the default behaviour is to write the STAT lines at first execution, which is basically a good idea but it can be misleading (as STAT statistics for further executions of the same child cursor might be missing from the trace file). For more information, see e.g. here:
http://antognini.ch/2009/02/11g-new-feature-in-dbms_monitor/
You don't need to use the EXPLAIN option of TKPROF, having the "Row Source Operations" recorded in the trace file is of much more valueWhy?The "Row Source Operation" tells you for each operation of the actual execution plan used the number of logical I/Os, physical I/Os and elapsed time, which tells you very exactly which step of the execution caused what kind of work.
The EXPLAIN PLAN output of TKPROF only shows an EXPLAIN PLAN, therefore it can be quite different from the actual execution plan used, especially if bind variables are used, which is the default when using static SQL in PL/SQL.
Can i have your email id.Follow the provided links, these include contact information if required.
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/ -
11g Client result set caching in OCI
I'm trying out this feature in the 11.1.0.6 release. My understanding of this feature is that when enabled with the appropriate server-side init.ora parameters, a 11g OCI client connecting to the instance will cache SQL results locally in some fixed amount of RAM on the client. The idea is that network roundtrips would simply disappear in this situation.
I'm not sure if it's working--or how to tell if it is. I have a 11g instance running and put the 11g client incl. sqlplus on a separate box, setting up TNS connectivity from client to server. Pretty standard stuff. I can connect fine and run the same query over and over, but I see incrementing execution counts on the database side and network traffic between the client and server so I'm guessing that the client-side caching isn't happening. There doesn't seem to be a ton of clear documentation on this feature so I wanted to see if anyone else has kicked it around.
BobI am also facing the same issue (enabling client result set caching). I am using Oracle Database 11g Release 11.2.0.2.0.
I have made the below configuration changes
1. Enabled the client result set cache by setting the server side parameter 'client_result_cache_size' to 10485760 (10 MB)
2. Restarted the oracle instance after setting the above parameter
3. Added a table annotation by executing the statement ALTER TABLE emp RESULT_CACHE (MODE FORCE). I verified that the annotation is applied by query the user table later.
4. Enabled statement caching on the client side i.e. on the JDBC driver.
5. Used prepared statements to execute the query so that statement caching kicks in. From the driver logs I verified that execution of subsequent queries after the first one used the same statement handle.
After executing the select prepared statement query for three times I checked the CLIENT_RESULT_CACHE_STATS$ view. But this view didn't result in any rows.
As part of troubleshooting I even tried adding the /*+ RESULT_CACHE */ hint to the query but the view didn't gave any result.
Also on enabling sql trace I could see from tkprof that every execution of the query increased the number of rows fetched on the server which indicates that the client result set caching in OCI isn't working.
Are there any steps which I have missed?
Thanks in advance. -
Link to download sqlloader and tkprof
Hi,
I installed oracle 11g in my machine from oracle site ,but not able to open tkprof and sqlldr . When click it open and disappear immediately . Where do i get these , i want to download it.
Thanks
Vasudevanuser5003725 wrote:
When click it open and disappear immediately Sqlldr and tkprof are not GUI's. These are to be accessed from command prompt. It is better to learn what it does and how it works before actually trying to use it.
HTH,
Prazy -
NULL and Unspecified in Dashboard prompts after upgrading 10g to 11g OBIEE
Hi All,
We are working on OBI upgradation project from 10g to 11.1.1.6.5. We are facing one issue in Dashboard prompt level. If we can create Dashboard prompt on a column, its giving "NULL", "Unspecified" additionally. But, in 10g there are no extra values.
And the 10g, 11g instances are pointing to the same database and there are no NULL, Unspecified values in Database level.
Through some blogs and articles we found some solutions n are below.
To remove NULL:
-->Go to the Physical Column properties in Physical Layer and Disable the Nullable option by uncheck the box.
-->Go to the Database Features in Physical Layer and disable value to NULL_SUPPORTED.
-->Go to Edit Dashboard Prompt, in Choice List Values drop-down list select SQL Results.
To remove Unspecified:
-->Go to Edit Dashboard Prompt, in Choice List Values drop-down list select SQL Results, then write the SQL statements as columnname is not equals to "Unspecfied" ( In this way we can able to remove Null's also.)
-->Go to Content tab of LTS, in Where clause write an SQL query to restrict Unspecified values.
Note: CHeck with ETL, because if they maintains the Default value is Null when the Datatype is Character and they can maintain 9999 or #### if the datatype is Numeric. And check the Physical query and debug it carefully.
But, we have very big Repository and we have huge no.of Dashboard prompts. So, its not an easy thing to manage by using above solutions. Correct me if there are any mistakes in above.
Any ideas on this...?
Appreciate your help on this..!
Thanks in Advance,
Raghu NagadasariHi Frnds,
As of now, i found the only solution for the above mentioned issue that how to avoid NULL in dashboard prompt level:
Go to the Physical Column properties in Physical Layer and Disable the Nullable option by uncheck the box.
We have done this manually for all tables.
Appreciate if u have any other ideas.!!
Thanks,
Raghu Nagadasari -
Installation Problem on 11g, RHEL 5 - Unable to generate temporary script
Hello all,
This is for the first time i am encountering this kind of error on 11g. Half way through installation i get this error.
All parameters set correct, used the official installation technique (works fine previously), except for this time i am getting a weird error, which does not allow me to continue with the installation.
Please help.
Environment
Oracle 11g
RHEL 5
Error on GUI -
OUI-10053: Unable to generate temporary script: {0}. Unable to continue install
Error on command prompt -
OUI-10053:Unable to generate temporary script: /u01/app/oraInventory/orainstRoot.sh. Unable to continue install.
Help appreciated.
ThanksHi Monu Koshy
Can you please control the user rights and also the df ?
ls -al /u01/app/oraInventory/
df -h /u01/app/oraInventory/
Regards,
Hub -
Problem with links in deployed ADF application to Weblogic Server 11g
Hi everyone !
I have a query here, firstly, I have created an ADF application using Jdeveloper 11g and have successfully deployed (EAR file) onto the weblogic server.
However, after testing out the application, the linking within the application does not seem to work. Whenever I click on a link or button, the page refreshes but the result is not displayed.
What could have cause the problem?
Thanks
GavinAre the ADF runtime libraries installed into the WebLogic server?
-
Report performance issue in oracle database 10g to 11g
Hi All,
We have one test instance for database 10g where the report is working fine below is the plan for report.
SELECT STATEMENT
VIEW APPS
SORT UNIQUE
UNION-ALL
HASH JOIN
TABLE ACCESS BY INDEX ROWID INV.MTL_SYSTEM_ITEMS_B
NESTED LOOPS
MERGE JOIN CARTESIAN
TABLE ACCESS FULL INV.MTL_PARAMETERS
BUFFER SORT
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_LOOKUP_VALUES
INDEX RANGE SCAN APPLSYS.FND_LOOKUP_VALUES_U2
INDEX RANGE SCAN INV.MTL_SYSTEM_ITEMS_B_XX1
TABLE ACCESS FULL ONT.OE_ORDER_LINES_ALL
NESTED LOOPS ANTI
HASH JOIN
TABLE ACCESS BY INDEX ROWID MRP.MRP_GROSS_REQUIREMENTS
INDEX SKIP SCAN MRP.MRP_GROSS_REQUIREMENTS_N2
TABLE ACCESS BY INDEX ROWID INV.MTL_SYSTEM_ITEMS_B
NESTED LOOPS
MERGE JOIN CARTESIAN
TABLE ACCESS FULL INV.MTL_PARAMETERS
BUFFER SORT
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_LOOKUP_VALUES
INDEX RANGE SCAN APPLSYS.FND_LOOKUP_VALUES_U2
INDEX RANGE SCAN INV.MTL_SYSTEM_ITEMS_B_XX1
TABLE ACCESS BY INDEX ROWID ONT.OE_ORDER_LINES_ALL
INDEX RANGE SCAN ONT.OE_ORDER_LINES_N3
We have one more instance whose database is 11g and the same report is migrated but it is taking too long time to execute the report output. Please advise why it is happening even why the plan is difference.
SELECT STATEMENT
VIEW APPS
SORT UNIQUE
UNION-ALL
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
INDEX RANGE SCAN INV.MTL_ITEM_CATEGORIES_U1
INDEX UNIQUE SCAN INV.MTL_CATEGORY_SETS_B_U1
TABLE ACCESS BY INDEX ROWID INV.MTL_CATEGORIES_B
INDEX UNIQUE SCAN INV.MTL_CATEGORIES_B_U1
INDEX UNIQUE SCAN INV.MTL_CATEGORIES_TL_U1
INDEX UNIQUE SCAN INV.MTL_CATEGORY_SETS_TL_U1
TABLE ACCESS BY INDEX ROWID INV.MTL_CATEGORY_SETS_TL
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID BOM.BOM_STRUCTURES_B
INDEX RANGE SCAN BOM.BOM_STRUCTURES_B_N2
SORT AGGREGATE
INDEX RANGE SCAN BOM.BOM_OPERATIONAL_ROUTINGS_U2
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID BOM.CST_ITEM_COSTS
INDEX UNIQUE SCAN BOM.CST_ITEM_COSTS_U1
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID BOM.CST_ITEM_COSTS
INDEX UNIQUE SCAN BOM.CST_ITEM_COSTS_U1
SORT AGGREGATE
FILTER
NESTED LOOPS
NESTED LOOPS
MERGE JOIN CARTESIAN
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_HEADERS_TL
INDEX RANGE SCAN QP.QP_LIST_HEADERS_TL_U1
INDEX UNIQUE SCAN QP.QP_LIST_HEADERS_B_PK
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_HEADERS_B
BUFFER SORT
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX SKIP SCAN QP.QP_PRICING_ATTRIBUTES_N11
INDEX UNIQUE SCAN QP.QP_LIST_LINES_PK
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_LINES
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
SORT AGGREGATE
FILTER
NESTED LOOPS
NESTED LOOPS
MERGE JOIN CARTESIAN
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_HEADERS_TL
INDEX RANGE SCAN QP.QP_LIST_HEADERS_TL_U1
INDEX UNIQUE SCAN QP.QP_LIST_HEADERS_B_PK
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_HEADERS_B
BUFFER SORT
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX SKIP SCAN QP.QP_PRICING_ATTRIBUTES_N11
INDEX UNIQUE SCAN QP.QP_LIST_LINES_PK
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_LINES
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
SORT AGGREGATE
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID MRP.MRP_ASSIGNMENT_SETS
INDEX UNIQUE SCAN MRP.MRP_ASSIGNMENT_SETS_U2
INDEX RANGE SCAN MRP.MRP_SR_ASSIGNMENTS_N3
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID PO.PO_APPROVED_SUPPLIER_LIST
INDEX RANGE SCAN PO.PO_APPROVED_SUPPLIER_LIST_N1
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID INV.MTL_ONHAND_QUANTITIES_DETAIL
INDEX RANGE SCAN INV.MTL_ONHAND_QUANTITIES_N6
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID INV.MTL_ONHAND_QUANTITIES_DETAIL
INDEX RANGE SCAN INV.MTL_ONHAND_QUANTITIES_N6
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID ONT.OE_ORDER_LINES_ALL
INDEX RANGE SCAN ONT.OE_ORDER_LINES_N3
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID ONT.OE_ORDER_LINES_ALL
INDEX RANGE SCAN ONT.OE_ORDER_LINES_N3
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
INDEX RANGE SCAN INV.MTL_ITEM_CATEGORIES_U1
TABLE ACCESS BY INDEX ROWID INV.MTL_CATEGORIES_B
INDEX UNIQUE SCAN INV.MTL_CATEGORIES_B_U1
INDEX UNIQUE SCAN INV.MTL_CATEGORY_SETS_TL_U1
TABLE ACCESS BY INDEX ROWID INV.MTL_CATEGORY_SETS_TL
HASH JOIN
NESTED LOOPS
NESTED LOOPS
MERGE JOIN CARTESIAN
TABLE ACCESS FULL INV.MTL_PARAMETERS
BUFFER SORT
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_LOOKUP_VALUES
INDEX RANGE SCAN APPLSYS.FND_LOOKUP_VALUES_U2
INDEX RANGE SCAN INV.MTL_SYSTEM_ITEMS_B_XX1
TABLE ACCESS BY INDEX ROWID INV.MTL_SYSTEM_ITEMS_B
TABLE ACCESS FULL ONT.OE_ORDER_LINES_ALL
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
INDEX RANGE SCAN INV.MTL_ITEM_CATEGORIES_U1
INDEX UNIQUE SCAN INV.MTL_CATEGORY_SETS_B_U1
TABLE ACCESS BY INDEX ROWID INV.MTL_CATEGORIES_B
INDEX UNIQUE SCAN INV.MTL_CATEGORIES_B_U1
INDEX UNIQUE SCAN INV.MTL_CATEGORIES_TL_U1
INDEX UNIQUE SCAN INV.MTL_CATEGORY_SETS_TL_U1
TABLE ACCESS BY INDEX ROWID INV.MTL_CATEGORY_SETS_TL
TABLE ACCESS BY INDEX ROWID BOM.BOM_STRUCTURES_B
INDEX RANGE SCAN BOM.BOM_STRUCTURES_B_N2
INDEX RANGE SCAN BOM.BOM_OPERATIONAL_ROUTINGS_U2
TABLE ACCESS BY INDEX ROWID BOM.CST_ITEM_COSTS
INDEX UNIQUE SCAN BOM.CST_ITEM_COSTS_U1
TABLE ACCESS BY INDEX ROWID BOM.CST_ITEM_COSTS
INDEX UNIQUE SCAN BOM.CST_ITEM_COSTS_U1
FILTER
NESTED LOOPS
NESTED LOOPS
MERGE JOIN CARTESIAN
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_HEADERS_TL
INDEX RANGE SCAN QP.QP_LIST_HEADERS_TL_U1
INDEX UNIQUE SCAN QP.QP_LIST_HEADERS_B_PK
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_HEADERS_B
BUFFER SORT
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX SKIP SCAN QP.QP_PRICING_ATTRIBUTES_N11
INDEX UNIQUE SCAN QP.QP_LIST_LINES_PK
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_LINES
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
FILTER
NESTED LOOPS
NESTED LOOPS
MERGE JOIN CARTESIAN
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_HEADERS_TL
INDEX RANGE SCAN QP.QP_LIST_HEADERS_TL_U1
INDEX UNIQUE SCAN QP.QP_LIST_HEADERS_B_PK
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_HEADERS_B
BUFFER SORT
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX SKIP SCAN QP.QP_PRICING_ATTRIBUTES_N11
INDEX UNIQUE SCAN QP.QP_LIST_LINES_PK
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_LINES
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
SORT UNIQUE NOSORT
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID MRP.MRP_ASSIGNMENT_SETS
INDEX UNIQUE SCAN MRP.MRP_ASSIGNMENT_SETS_U2
INDEX RANGE SCAN MRP.MRP_SR_ASSIGNMENTS_N3
SORT UNIQUE NOSORT
TABLE ACCESS BY INDEX ROWID PO.PO_APPROVED_SUPPLIER_LIST
INDEX RANGE SCAN PO.PO_APPROVED_SUPPLIER_LIST_N1
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID INV.MTL_ONHAND_QUANTITIES_DETAIL
INDEX RANGE SCAN INV.MTL_ONHAND_QUANTITIES_N6
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID INV.MTL_ONHAND_QUANTITIES_DETAIL
INDEX RANGE SCAN INV.MTL_ONHAND_QUANTITIES_N6
SORT AGGREGATE
INDEX RANGE SCAN MRP.MRP_GROSS_REQUIREMENTS_N1
SORT AGGREGATE
INDEX RANGE SCAN MRP.MRP_GROSS_REQUIREMENTS_N1
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
INDEX RANGE SCAN INV.MTL_ITEM_CATEGORIES_U1
TABLE ACCESS BY INDEX ROWID INV.MTL_CATEGORIES_B
INDEX UNIQUE SCAN INV.MTL_CATEGORIES_B_U1
INDEX UNIQUE SCAN INV.MTL_CATEGORY_SETS_TL_U1
TABLE ACCESS BY INDEX ROWID INV.MTL_CATEGORY_SETS_TL
NESTED LOOPS ANTI
HASH JOIN
TABLE ACCESS BY INDEX ROWID MRP.MRP_GROSS_REQUIREMENTS
INDEX SKIP SCAN MRP.MRP_GROSS_REQUIREMENTS_N2
NESTED LOOPS
NESTED LOOPS
MERGE JOIN CARTESIAN
TABLE ACCESS FULL INV.MTL_PARAMETERS
BUFFER SORT
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_LOOKUP_VALUES
INDEX RANGE SCAN APPLSYS.FND_LOOKUP_VALUES_U2
INDEX RANGE SCAN INV.MTL_SYSTEM_ITEMS_B_XX1
TABLE ACCESS BY INDEX ROWID INV.MTL_SYSTEM_ITEMS_B
TABLE ACCESS BY INDEX ROWID ONT.OE_ORDER_LINES_ALL
INDEX RANGE SCAN ONT.OE_ORDER_LINES_N3
}Hi All,
We have one test instance for database 10g where the report is working fine below is the plan for report.
SELECT STATEMENT
VIEW APPS
SORT UNIQUE
UNION-ALL
HASH JOIN
TABLE ACCESS BY INDEX ROWID INV.MTL_SYSTEM_ITEMS_B
NESTED LOOPS
MERGE JOIN CARTESIAN
TABLE ACCESS FULL INV.MTL_PARAMETERS
BUFFER SORT
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_LOOKUP_VALUES
INDEX RANGE SCAN APPLSYS.FND_LOOKUP_VALUES_U2
INDEX RANGE SCAN INV.MTL_SYSTEM_ITEMS_B_XX1
TABLE ACCESS FULL ONT.OE_ORDER_LINES_ALL
NESTED LOOPS ANTI
HASH JOIN
TABLE ACCESS BY INDEX ROWID MRP.MRP_GROSS_REQUIREMENTS
INDEX SKIP SCAN MRP.MRP_GROSS_REQUIREMENTS_N2
TABLE ACCESS BY INDEX ROWID INV.MTL_SYSTEM_ITEMS_B
NESTED LOOPS
MERGE JOIN CARTESIAN
TABLE ACCESS FULL INV.MTL_PARAMETERS
BUFFER SORT
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_LOOKUP_VALUES
INDEX RANGE SCAN APPLSYS.FND_LOOKUP_VALUES_U2
INDEX RANGE SCAN INV.MTL_SYSTEM_ITEMS_B_XX1
TABLE ACCESS BY INDEX ROWID ONT.OE_ORDER_LINES_ALL
INDEX RANGE SCAN ONT.OE_ORDER_LINES_N3
We have one more instance whose database is 11g and the same report is migrated but it is taking too long time to execute the report output. Please advise why it is happening even why the plan is difference.
SELECT STATEMENT
VIEW APPS
SORT UNIQUE
UNION-ALL
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
INDEX RANGE SCAN INV.MTL_ITEM_CATEGORIES_U1
INDEX UNIQUE SCAN INV.MTL_CATEGORY_SETS_B_U1
TABLE ACCESS BY INDEX ROWID INV.MTL_CATEGORIES_B
INDEX UNIQUE SCAN INV.MTL_CATEGORIES_B_U1
INDEX UNIQUE SCAN INV.MTL_CATEGORIES_TL_U1
INDEX UNIQUE SCAN INV.MTL_CATEGORY_SETS_TL_U1
TABLE ACCESS BY INDEX ROWID INV.MTL_CATEGORY_SETS_TL
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID BOM.BOM_STRUCTURES_B
INDEX RANGE SCAN BOM.BOM_STRUCTURES_B_N2
SORT AGGREGATE
INDEX RANGE SCAN BOM.BOM_OPERATIONAL_ROUTINGS_U2
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID BOM.CST_ITEM_COSTS
INDEX UNIQUE SCAN BOM.CST_ITEM_COSTS_U1
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID BOM.CST_ITEM_COSTS
INDEX UNIQUE SCAN BOM.CST_ITEM_COSTS_U1
SORT AGGREGATE
FILTER
NESTED LOOPS
NESTED LOOPS
MERGE JOIN CARTESIAN
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_HEADERS_TL
INDEX RANGE SCAN QP.QP_LIST_HEADERS_TL_U1
INDEX UNIQUE SCAN QP.QP_LIST_HEADERS_B_PK
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_HEADERS_B
BUFFER SORT
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX SKIP SCAN QP.QP_PRICING_ATTRIBUTES_N11
INDEX UNIQUE SCAN QP.QP_LIST_LINES_PK
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_LINES
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
SORT AGGREGATE
FILTER
NESTED LOOPS
NESTED LOOPS
MERGE JOIN CARTESIAN
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_HEADERS_TL
INDEX RANGE SCAN QP.QP_LIST_HEADERS_TL_U1
INDEX UNIQUE SCAN QP.QP_LIST_HEADERS_B_PK
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_HEADERS_B
BUFFER SORT
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX SKIP SCAN QP.QP_PRICING_ATTRIBUTES_N11
INDEX UNIQUE SCAN QP.QP_LIST_LINES_PK
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_LINES
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
SORT AGGREGATE
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID MRP.MRP_ASSIGNMENT_SETS
INDEX UNIQUE SCAN MRP.MRP_ASSIGNMENT_SETS_U2
INDEX RANGE SCAN MRP.MRP_SR_ASSIGNMENTS_N3
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID PO.PO_APPROVED_SUPPLIER_LIST
INDEX RANGE SCAN PO.PO_APPROVED_SUPPLIER_LIST_N1
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID INV.MTL_ONHAND_QUANTITIES_DETAIL
INDEX RANGE SCAN INV.MTL_ONHAND_QUANTITIES_N6
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID INV.MTL_ONHAND_QUANTITIES_DETAIL
INDEX RANGE SCAN INV.MTL_ONHAND_QUANTITIES_N6
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID ONT.OE_ORDER_LINES_ALL
INDEX RANGE SCAN ONT.OE_ORDER_LINES_N3
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID ONT.OE_ORDER_LINES_ALL
INDEX RANGE SCAN ONT.OE_ORDER_LINES_N3
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
INDEX RANGE SCAN INV.MTL_ITEM_CATEGORIES_U1
TABLE ACCESS BY INDEX ROWID INV.MTL_CATEGORIES_B
INDEX UNIQUE SCAN INV.MTL_CATEGORIES_B_U1
INDEX UNIQUE SCAN INV.MTL_CATEGORY_SETS_TL_U1
TABLE ACCESS BY INDEX ROWID INV.MTL_CATEGORY_SETS_TL
HASH JOIN
NESTED LOOPS
NESTED LOOPS
MERGE JOIN CARTESIAN
TABLE ACCESS FULL INV.MTL_PARAMETERS
BUFFER SORT
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_LOOKUP_VALUES
INDEX RANGE SCAN APPLSYS.FND_LOOKUP_VALUES_U2
INDEX RANGE SCAN INV.MTL_SYSTEM_ITEMS_B_XX1
TABLE ACCESS BY INDEX ROWID INV.MTL_SYSTEM_ITEMS_B
TABLE ACCESS FULL ONT.OE_ORDER_LINES_ALL
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
INDEX RANGE SCAN INV.MTL_ITEM_CATEGORIES_U1
INDEX UNIQUE SCAN INV.MTL_CATEGORY_SETS_B_U1
TABLE ACCESS BY INDEX ROWID INV.MTL_CATEGORIES_B
INDEX UNIQUE SCAN INV.MTL_CATEGORIES_B_U1
INDEX UNIQUE SCAN INV.MTL_CATEGORIES_TL_U1
INDEX UNIQUE SCAN INV.MTL_CATEGORY_SETS_TL_U1
TABLE ACCESS BY INDEX ROWID INV.MTL_CATEGORY_SETS_TL
TABLE ACCESS BY INDEX ROWID BOM.BOM_STRUCTURES_B
INDEX RANGE SCAN BOM.BOM_STRUCTURES_B_N2
INDEX RANGE SCAN BOM.BOM_OPERATIONAL_ROUTINGS_U2
TABLE ACCESS BY INDEX ROWID BOM.CST_ITEM_COSTS
INDEX UNIQUE SCAN BOM.CST_ITEM_COSTS_U1
TABLE ACCESS BY INDEX ROWID BOM.CST_ITEM_COSTS
INDEX UNIQUE SCAN BOM.CST_ITEM_COSTS_U1
FILTER
NESTED LOOPS
NESTED LOOPS
MERGE JOIN CARTESIAN
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_HEADERS_TL
INDEX RANGE SCAN QP.QP_LIST_HEADERS_TL_U1
INDEX UNIQUE SCAN QP.QP_LIST_HEADERS_B_PK
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_HEADERS_B
BUFFER SORT
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX SKIP SCAN QP.QP_PRICING_ATTRIBUTES_N11
INDEX UNIQUE SCAN QP.QP_LIST_LINES_PK
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_LINES
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
FILTER
NESTED LOOPS
NESTED LOOPS
MERGE JOIN CARTESIAN
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_HEADERS_TL
INDEX RANGE SCAN QP.QP_LIST_HEADERS_TL_U1
INDEX UNIQUE SCAN QP.QP_LIST_HEADERS_B_PK
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_HEADERS_B
BUFFER SORT
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX SKIP SCAN QP.QP_PRICING_ATTRIBUTES_N11
INDEX UNIQUE SCAN QP.QP_LIST_LINES_PK
TABLE ACCESS BY INDEX ROWID QP.QP_LIST_LINES
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
TABLE ACCESS BY INDEX ROWID QP.QP_PRICING_ATTRIBUTES
INDEX RANGE SCAN QP.QP_PRICING_ATTRIBUTES_N3
SORT UNIQUE NOSORT
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID MRP.MRP_ASSIGNMENT_SETS
INDEX UNIQUE SCAN MRP.MRP_ASSIGNMENT_SETS_U2
INDEX RANGE SCAN MRP.MRP_SR_ASSIGNMENTS_N3
SORT UNIQUE NOSORT
TABLE ACCESS BY INDEX ROWID PO.PO_APPROVED_SUPPLIER_LIST
INDEX RANGE SCAN PO.PO_APPROVED_SUPPLIER_LIST_N1
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID INV.MTL_ONHAND_QUANTITIES_DETAIL
INDEX RANGE SCAN INV.MTL_ONHAND_QUANTITIES_N6
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID INV.MTL_ONHAND_QUANTITIES_DETAIL
INDEX RANGE SCAN INV.MTL_ONHAND_QUANTITIES_N6
SORT AGGREGATE
INDEX RANGE SCAN MRP.MRP_GROSS_REQUIREMENTS_N1
SORT AGGREGATE
INDEX RANGE SCAN MRP.MRP_GROSS_REQUIREMENTS_N1
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
INDEX RANGE SCAN INV.MTL_ITEM_CATEGORIES_U1
TABLE ACCESS BY INDEX ROWID INV.MTL_CATEGORIES_B
INDEX UNIQUE SCAN INV.MTL_CATEGORIES_B_U1
INDEX UNIQUE SCAN INV.MTL_CATEGORY_SETS_TL_U1
TABLE ACCESS BY INDEX ROWID INV.MTL_CATEGORY_SETS_TL
NESTED LOOPS ANTI
HASH JOIN
TABLE ACCESS BY INDEX ROWID MRP.MRP_GROSS_REQUIREMENTS
INDEX SKIP SCAN MRP.MRP_GROSS_REQUIREMENTS_N2
NESTED LOOPS
NESTED LOOPS
MERGE JOIN CARTESIAN
TABLE ACCESS FULL INV.MTL_PARAMETERS
BUFFER SORT
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_LOOKUP_VALUES
INDEX RANGE SCAN APPLSYS.FND_LOOKUP_VALUES_U2
INDEX RANGE SCAN INV.MTL_SYSTEM_ITEMS_B_XX1
TABLE ACCESS BY INDEX ROWID INV.MTL_SYSTEM_ITEMS_B
TABLE ACCESS BY INDEX ROWID ONT.OE_ORDER_LINES_ALL
INDEX RANGE SCAN ONT.OE_ORDER_LINES_N3
} -
[Migrating from 6i to 11G] HTML viewer
Hi,
There used to be a program to display the output of a report in 6i. When the report was displayed, it used page breaks (ESC characters) to allow the user to view the next page and print a range of pages from a report.
In 11G, these control characters are not interpreted by Internet Explorer:
>
height 85
width 94
before report esc "&l%%0O" esc "&l8D" esc "(s12H"
after report esc "E"
after page control(L)
[End Quote]
So how could I migrate the printer definition files in order to get after page control in 11G?
Many thanks for your help.As my old college profession used to say - "The only stupid question is the one that doesn't get asked!" Forms 11g only supports web deployment. This means you will need the OAS with the Forms and Reports Services installed as well. Typically, the setup is three tiered ( 1 server = Database, 1 server = Application Server, 1 server = Infrastructure server ). You don't have to set up the technology stack multitiered - all three could reside on the same server or you could have the all three on the same machine but is not recommended. I would at least have the database on a server seperate from OAS.
Here are a few links to get you started.
Oracle Documentation
* Check out: Development Tools - Oracle Forms, Middleware - Applications Server - Oracle Fusion Middleware 11g and Middleware - Data Warehousing and Business Intelligence - Oracle Reports
Since you will be upgrading from Forms 6i to 11g, be sure to visit the Oracle Forms-Upgrading Forms 6i to Forms 11g documentation.
BTW, welcome to the forums!
Craig
If a response is helpful or correct, please mark it accordingly.
Edited by: CraigB on May 6, 2010 2:09 PM
Maybe you are looking for
-
I can understand that is not possible to see all the bugs, but this is kinda bothering me, because is not exactly a bug that require a lot of efforts at all....here we go, maybe you know about it so iw ould love to know when it will be fixed. format
-
Get a connection error when running a BODS job
Hi All, I have BODS system setup in my environment. There are quite some jobs that run everyday. The jobs have stopped running since the last days. The jobs arn't failing, but they do not run. When I try to Execute a job, I get the error "Connection
-
Failed creation of deployable proxy upon wsdl containing "soapenc" types
Hello all, I've tried to create deployable proxy upon wsdl file Creation process has failed and following exception was logged: com.sap.engine.services.webservices.jaxrpc.exceptions.ProxyGeneratorException: Proxy Generator Error. Proxy generation pro
-
Hey Gurus I've just shot a seminar, three cameras, Cannon's reasonably new XA20HD's. File format 1920X1080 MP4 17mbs 25 frames. Am running PremProCS6. I import the files into Prem, they come in ok but will not display. Got a yellow bar and a yellow M
-
Problem in Updating a field in corpNAB resource through workflows
Hi, I am working in Sun Java system identity manager 7.1 version. I have created one workflow which sends a list of Ids to a sub work flow,The sub workflow updates a field called user name in person document of corpNAB resource for each user. Usernam