Oracle 10g performance is slow

Dear Exports
how we can imporve the Oracle 10g performance........we are upgrading from Oracle 8 to Oracle 10g. Windows platform. and using Oracle developer 6 as front end .
thanks in advance

Do you have statistics gathered on the tables in the 8i database? Can you post the explain plan for the query in both databases?
Since you know what SQL is having poor performance you can use TKPROF and SQL TRACE to see where your query is spending its time.
Try the following:
alter session set timed_statistics=true;
alter session set max_dump_file_size=unlimited;
alter session set tracefile_identifier='BAD_SQL';
alter session set events '10046 trace name context forever, level 12';
<insert sql with poor response time>
disconnect
Use the TKPROF utility on the file found in USER_DUMP_DEST that contains the string BAD_SQL.
For information on how to interrupt the TKPROF output, see the following link.
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14211/sqltrace.htm

Similar Messages

Query can run in Oracle 10g but very slow in 11g

Hi,
We've just migrated to Oracle 11g and we noticed that some of our view are very slow (it takes seconds in 10g and takes 30 minutes in 11g), and the tables are using the local table.
Do any of you face the same issue?
This is our query:
SELECT
A.wellbore
,a.depth center
,d.MD maxbc
,d.XDELT xbc
,d.YDELT ybc
,e.MD minac
,e.XDELT xac
,e.YDELT yac
from
table_A d,table_A e, table_B a
where a.wellbore = d.WELLBORE (+)
and a.wellbore = e.WELLBORE(+)
and d.MD = (select max(MD) from table_A b where b.MD < a.depth and
d.wellBORE = b.wellBORE)
and e.md = (select min(md) from table_A c where c.MD > a.depth and
e.wellBORE = c.wellBORE);

Thanks I will move to the correct one..
Rafi,
Build the Indexes and it is still slow. I am querying from a view from another database, which is in 10g instances.
Moved: Query can run in Oracle 10g but very slow in 11g
Edited by: 924400 on Apr 1, 2012 6:03 PM
Edited by: 924400 on Apr 1, 2012 6:26 PM

Oracle 10G Performance Tuning Documents

Hi all
Can any one tell where can I get the oracle 10G Performance Tuning materials(PDF),Documents.
Thanks in advance

http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14211.pdf

Oracle Forms Performance very slow on the internet

Hi ,
We have developed a form application with forms Developer 10g and deployed it on a ORACLE 10g AS. If the user runs our application over intranet there is no any network problem or not any performance decrease occurs. However if we deploy our application over WAN or internet, the startup time of the forms become Very Slow.
What we can use to make it faster , is there any other tools we have to learn like APEX or JDeveloper , what is the best solution , should we forget the Developer for ever and starting with other tools with fast performance on the internet , if so , what we have to learn , please help us , its common problem .
any help please ,

Interesting thread....
You asked whether "Forms" is the right product for the job. Well, the answer to that question will depend entirely on exactly what functionality you need and your skill-set. One advantage of using Forms over other Oracle products is that, in my opinion, Forms allows you to create simple or complex applications very quickly, with limited development experience. The downside to using Forms however, is that it does use a fairly thick client making startup slower than other applications. Generally, Forms is not very well suited for Internet deployments although it can and has been done. If your goal is to use a product which is easy to work with and is appropriate for Internet deployment, you may want to consider Apex. The downside to Apex is that unlike Forms, Apex generates what I like to call static html pages. Meaning once a page is displayed for the end-user, the data on it remains the same until the user forces interaction with the server again, but in this case the entire page would be refreshed in order to realize the changes. In the case of Forms, any content displayed to the end-user can be change without completely refreshing their view. I like to refer to Forms as a living application because unlike Apex, it can easily respond to most user inputs and/or server side changes almost in real-time. If you want this "live" experience, Forms might be the way to go, although at the cost of some startup performance. Alternatively, Oracle ADF can also give you a similar live-like experience. However, ADF will require a broader skill-set (pl/sql, java, html, etc), whereas with Forms you could get away with only knowing pl/sql although java knowledge would be helpful.
The views expressed in this thread are my own and do not necessarily reflect the views of Oracle.

Oracle 10g performance issues

Hi,
We were using Oracle 9i in Solaris 5.8 and it was working fine with some minor performance issues. We formatted the Solaris server with new Solaris 5.10 and installed Oracle 10g.
Now we are experiencing some performance issues in Oracle 10g. This issue is arising when using through Websphere 5.1.
We have analyzed the schema, index is rebuild, SGA is 4.5 GB, PGA is 2.0 GB, Solaris RAM is 16 GB. Also we are having some Mat Views (possibly this may cause performance issues - not sure) due to refresh.
Also I have changed some parameters in init.ora file like query_rewrite = STALE_TOLERATED, open_cursors = 1500 etc.
Is is something due to driver from which the data is accessed. I guess it is not utilizing the indexes on the table.
Can anyone please suggest, what could be the issue ?

There are a lot of changes to the optimizer in the upgrade from 9i to 10g, and you need to be aware of them. There are also a number of changes to the default stats collection mechanism, so after your upgrade your statistics (hence execution paths) could change dramatically.


Greg Rahn has a useful entry on his blog about stats collection, and the blog al,so points to an Oracle white paper which will give you a lot of ideas about where the optimizer changes - which may help you spot your critical issues.

Otherwise, follow triggb's advice about using Statspack to find the SQL that is the most expensive - it's reasonably likely to be this SQL that has changed execution plans in the upgrade.

Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

Oracle 10g performance tuning tools

hi,
can anyone please suggest me any oracle database tuning tool to use for improving the performance of the database?(oracle 10g)

Hi,
Do you want a tuning tool that does not require the user to have in-depth Oracle knowledge? If so, try here:
http://images.google.com/images?&q=ouija+board&um=1&ie=UTF-8&sa=N&tab=wi
Seriously, I like to use AWR and STATSPACK reports, and there are some freeware tools to help analyze them, one that I sponsor:
http://www.statspackanalyzer.com
For online tools, Oracle SQL Developer is a great way to get started, as-is the Oracle performance pack:
http://www.oracle.com/technology/products/database/sql_developer/index.html
For third-party tuning tools, look at Confio, quite good:
http://www.confio.com/
Hope this helps. . .
Don Burleson
Oracle Press author
Author of “Oracle Tuning: The Definitive Reference”
http://www.dba-oracle.com/bp/s_oracle_tuning_book.htm

Oracle 10G performance problems

Hello,
we have a lot of performance problems with oracle 10G. Especially tables scan on DRAW or AEN1 have long response times. It seems that the CBO uses the wrong strategy. The latest merge fix is already installed. Any idea to solve the problem is welcome.
Best regards
Juergen Remmert

We had similar performance issues in our environment, once we upgraded from 9.2.0.2 to 10.2.0.2.
Oracle: 10.2.0.2
SAP: 4.7x110
OS: SOLARIS 9 64bit
The above mentioned notes were very helpful. We had to install an oracle patch as well (found on marketplace) -- 6321245
and make the following oracle parameters changes:
pga_aggregate_target - 144MB (default = 25MB)
*.event="10027 trace name context forever, level 1"
*.event="10028 trace name context forever, level 1"
*.event="10162 trace name context forever, level 1"
*.event="10183 trace name context forever, level 1"
*.event="10191 trace name context forever, level 1"
*.event="10629 trace name context forever, level 32"
*.event="38068 trace name context forever, level 100"
*.event="38043 trace name context forever, level 1"
*.optimizer_index_caching=50
*.optimizer_index_cost_adj=20
*.parallel_execution_message_size=16384
*._b_tree_bitmap_plans=FALSE
*._index_join_enabled=FALSE
*._optim_peek_user_binds=FALSE
*._optimizer_mjc_enabled=FALSE
*._sort_elimination_cost_ratio=10
Remove
*.optimizer_features_enable='9.2.0'
HTH

ORACLE 10g PERFORMANCE ON SOLARIS 10

Hi all,
In sunfire v890 we have installed oracle 10g release 2 on solaris 10.
prstat -a command shows :
NPROC USERNAME SIZE RSS MEMORY TIME CPU
105 root 9268M 6324M 20% 1:21:57 0.4%
59 oracle 24G 22G 71% 0:04:33 0.1%
2 nobody4 84M 69M 0.2% 0:11:32 0.0%
2 esbuser 13M 9000K 0.0% 0:00:46 0.0%
1 smmsp 7560K 1944K 0.0% 0:00:00 0.0%
4 daemon 12M 7976K 0.0% 0:00:00 0.0%
and top utility shows :
last pid: 8639; load avg: 0.09, 0.09, 0.09; up 2+06:05:29 17:07:50
171 processes: 170 sleeping, 1 on cpu
CPU states: 98.7% idle, 0.7% user, 0.7% kernel, 0.0% iowait, 0.0% swap
Memory: 32G phys mem, 22G free mem, 31G swap, 31G free swap
therefore from prstat we come to know that memory used by oracle is 71%
where as top says 31.25% used.....
which one is true in this scenario.....
shall we go ahead in trusting top utility????
Advance thanks to you.

therefore from prstat we come to know that memory
used by oracle is 71%
where as top says 31.25% used.....
which one is true in this scenario.....
shall we go ahead in trusting top utility????In this case top is more accurate. prstat pretends all the memory used by each Oracle process is used only by that process. But lots of the memory used by Oracle is shared between several processes. prstat is counting that shared memory over and over for each process... resulting in the higher figure.
http://forum.java.sun.com/thread.jspa?threadID=5114263&tstart=105
Regards,
[email protected]
http://www.HalcyonInc.com

Oracle 10g performance issue

Hi all,
In sunfire v890 we have installed oracle 10g release 2 on solaris 10.
prstat -a command shows :
NPROC USERNAME SIZE RSS MEMORY TIME CPU
105 root 9268M 6324M 20% 1:21:57 0.4%
59 oracle 24G 22G 71% 0:04:33 0.1%
2 nobody4 84M 69M 0.2% 0:11:32 0.0%
2 esbuser 13M 9000K 0.0% 0:00:46 0.0%
1 smmsp 7560K 1944K 0.0% 0:00:00 0.0%
4 daemon 12M 7976K 0.0% 0:00:00 0.0%
and top utility shows :
last pid: 8639; load avg: 0.09, 0.09, 0.09; up 2+06:05:29 17:07:50
171 processes: 170 sleeping, 1 on cpu
CPU states: 98.7% idle, 0.7% user, 0.7% kernel, 0.0% iowait, 0.0% swap
Memory: 32G phys mem, 22G free mem, 31G swap, 31G free swap
therefore from prstat we come to know that memory used by oracle is 71%
where as top says 31.25% used.....
which one is true in this scenario.....
shall we go ahead in trusting top utility????
Advance thanks to you.

Hi darren
The main thing is,, prstat -a command showing oracle
user occupied 70%.In top utility showing 22gb memory
free out of 32 gb.That means 10gb was occupied by all
users.In percentage calculation its comes
31.25%...i.e top shows all users occupied only
31.25%Right. That's all memory in use, correct? From your first message I thought you meant it said that was the amount used by Oracle.
It's easy to calculate total memory in use.
It's hard to calculate memory in use by a subset of processes (perhaps those owned by a particular user).
but prstat -t command shows 70% occupied by oracle.
which one i want to believe??????The prstat command showing memory in use by a user will be incorrect because it does not calculated shared pages properly.
As far as I am aware, 'top' has no similar display.
Darren

Oracle 10G Performance Tuning

A colleague of mine supplied me with a tuning script to help in my performance analysis of a 10.2.0.1 Oracle database. The script is called:
responsetimebreakdown.sql
Apparently this was designed for 8i as it cannot find the sys.x_$ksles (session events) view or table in my Oracle 10.2.0.1 database. I receive:
ORA-00942: table or view does not exist
Any one know the equivalent of this object in 10G or has access to this script designed for use against a 10.2.0.1 Oracle database?
Thanks.

I don't know what your script does, but here's the table you're looking for. 
SQL> select name from v$fixed_table where name like '%KSLES%';
 
 
NAME 
------------------------------ 
X$KSLES 
If you really want to tune, you should also try 
SQL> @$ORACLE_HOME/rdbms/admin/awrrpt
 
Dave 
Lehr.servehttp.com
Message was edited by:
DaveLehr

Oracle 10g Reports running slow

On one server we have an issue with some reports of 2pages taking 2 minutes or more to run, but on another server with the same data transferred across the same report runs in about 3-5 seconds.
The reports we are having issues with contain graphs.
The server spec is better on the slower running report server than the other report server.
How can I fix this?

Hi,
did you any exceptions you in the logs of report server??
Location:
$ORACLE_HOME/reports/logs/ <report_server> / .
Remove a trace,when your executing the graphical report.
It would help you to finding why the report is taking so much time
please follow the below link for tracing the reports in OAS 10g
http://docs.oracle.com/cd/B2501608/doc/dl/bi/B14048_02/B14048_02.pdf_
Regards
Fabian

Oracle 10g Performance

Hi All,
We have are facing some performance issue with Oracle. We have created an table with some fields and a BLOB object. Our application continuously inserts and deleted data from that table. These data operations at a very high rate. We have Enabled NoCache for the BLOB object and are BLOB object is stored in different tablespace. Using some monitoring tool we observed that inserts into the table is taking more time on further digging we found that the time is taken by the BLOB object. We also observed that the Waiting time is more for db file sequential read while doing an insert. As i mentioned Earlier we are also deleting records from this table that is done by other threads. Is this problem occuring as we are inserting and deleting the same data at a high rate. Also Oracle is doing a full table scan on inserts.
Please Help
Thanks in Advance.

No database version?
No table structures?
No example data?
No code?
No way we can really help unfortunately.
[How to post a SQL statement tuning request|http://forums.oracle.com/forums/thread.jspa?threadID=863295&tstart=0]
however, as it sounds a little more like a whole application issue rather than just a single SQL statement you may want to post all your details over in the Database-General forum where the DBA's tend to hang out.

Oracle 10g – Performance with BIG CONTEXT indexes

I would like to use Oracle XE 10.2.0.1.0 only for the full-text searching of the files residing outside the database on the FTP server.
Recently I have found out that size of the files to be indexed is 5GB.
As I have read somewhere on this forum before size of the index should be 30-40% of the indexed text files (so with formatted documents like PDF or DOC even less).
Lets say that the CONTEXT index size over these files will be 1.5-2GB.
Number of the concurrent user will be max. 5.
I can not easily test it my self yet.
Does anybody have any experience with Oracle XE or other Oracle Database edition performance with the CONTEXT index this BIG?
Will Oracle XE hardware resources license limitation be sufficient to handle one CONTEXT indexe this BIG?
(Oracle XE license limitations: 1 GB RAM and 1 CPU)
Regards.

That depends on at least three things:
(1) what is the range of words that will appear in the document set (wide range of documents = smaller resultsets = better performance)
(2) how precise are the user's queries likely to be (more precise = smaller resultsets = better performance)
(3) how many milliseconds are your users willing to wait for results
So, unfortunately, you'll probably have to experiment a bit before you'll know...

Oracle 10g performance degrades while concurrent inserts into a table

Hello Team,
I am trying to insert into single table via multiple threads, Some of these threads perform reasonably well but some will take really longer time, As the time goes on performance drastically degrades (even down by 500 to 600 times). With AWR report i see that there quite huge number of buffer gets there. I am not sure how can i reduce those. If i ran on a single thread this operation is consistent.
I tried quite a few options like
1. Increasing SGA Memory
2. Moving redo logs to another disk drive.
3. Trying it on a empty table
4. Trying it on a table which has huge data (4 Million rows)
5. I have even tried partitioning the table with HASH algoritm
Note: Each thread i am pupming equal amount of data (let say 25K rows).
Can any body suggest me a clue what could be the culprit here.
Thanks in Advance
Satish Kumar Ballepu

user11150696 wrote:
Can you please guide me how do i do that, I am not aware of how to generate explain plan for that query.Since you have the trace file already (and I don't mean the tkprof output), you could do the following:
Read the trace file to find the statement you're interested id - the line above it will be a +"PARSING"+ line, and will include a reference to the statement hash_value look like +'hv=3838377475845'+.
Use the hash_value to query v$sql to get the sql_id and child_number;
Use the sql_id and child number in a call to dbms_xplan.display_cursor:
PARSING IN CURSOR #7 len=68 dep=0 uid=55 oct=3 lid=55 tim=448839952404 *hv=3413100263* ad='2f6ede48'
select ... etc. (the statement I want the plan for)
SQL> select sql_id , child_number from v$sql where hash_value = *3413100263*;
SQL_ID        CHILD_NUMBER
053tyaz5qzjr7            0
SQL> select * from table(dbms_xplan.display_cursor(*'053tyaz5qzjr7'*,*0*));
PLAN_TABLE_OUTPUT
SQL_ID 053tyaz5qzjr7, child number 0
select /*+ use_concat */ small_vc from t1 where n1 = 1 or n2 = 2
Plan hash value: 82564388
| Id | Operation                    | Name | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT             |       |       |       |     4 |
|   1 | CONCATENATION               |       |       |       |       |
|   2 |   TABLE ACCESS BY INDEX ROWID| T1    |    10 |   190 |     2 |
|* 3 |    INDEX RANGE SCAN          | T1_N2 |    10 |       |     1 |
|* 4 |   TABLE ACCESS BY INDEX ROWID| T1    |    10 |   190 |     2 |
|* 5 |    INDEX RANGE SCAN          | T1_N1 |    10 |       |     1 |
Predicate Information (identified by operation id):
   3 - access("N2"=2)
   4 - filter(LNNVL("N2"=2))
   5 - access("N1"=1)
Note
   - cpu costing is off (consider enabling it)Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"For every expert there is an equal and opposite expert."
Arthur C. Clarke
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.

Oracle 10g Performance between (10.2.0.3.0 and 10.2.0.5.0): Platform solari

Hello all,
We have built our new UAT (10.2.0.5.0) using disk copy from old UAT(10.2.0.3.0). Ystem stats are all up to date. But one of the query takes very long time almost 6 hours in New UAT. But old UAT it takes only 20 minutes .
Can anybody tell why or what i shoudl check for?

Plan@OLD UAT
===============
1 One or more rows were retrieved using index SCHEMANMERR.XAK_BATCH_CONTROL_3 . The index was scanned in ascending order..
2 The rows from step 1 were inserted into using direct-load insert.
3 Rows were retrieved using the unique index SCHEMANMMAP.XPK_SOURCE_SYSTEM_FEED .
4 Rows from table SCHEMANMMAP.SCHEMANMF_SOURCE_SYSTEM_FEED were accessed using rowid got from an index.
5 Every row in the table SYS.SYS_TEMP_0FD9D6651_E9A50186 is read.
6 A view definition was processed, either from a stored view WEIJ. or as defined by steps 5.
7 One or more rows were retrieved using index SCHEMANMERR.XAK_BATCH_CONTROL_4 . The index was scanned in ascending order..
8 For each row retrieved by step 6, the operation in step 7 was performed to find a matching row.
9 The rows were sorted to support a group operation (MAX,MIN,AVERAGE, SUM, etc).
10 A view definition was processed, either from a stored view WEIJ. or as defined by steps 9.
11 Every row in the table SYS.SYS_TEMP_0FD9D6651_E9A50186 is read.
12 A view definition was processed, either from a stored view WEIJ. or as defined by steps 11.
13 One or more rows were retrieved using index SCHEMANMERR.XAK_BATCH_CONTROL_5 . The index was scanned in ascending order..
14 For each row retrieved by step 12, the operation in step 13 was performed to find a matching row.
15 The rows were sorted to support a group operation (MAX,MIN,AVERAGE, SUM, etc).
16 A view definition was processed, either from a stored view WEIJ. or as defined by steps 15.
17 For each row retrieved by step 10, the operation in step 16 was performed to find a matching row.
18 Every row in the table SYS.SYS_TEMP_0FD9D6651_E9A50186 is read.
19 A view definition was processed, either from a stored view WEIJ. or as defined by steps 18.
20 One or more rows were retrieved using index SCHEMANMERR.XAK_BATCH_CONTROL_5 . The index was scanned in ascending order..
21 For each row retrieved by step 19, the operation in step 20 was performed to find a matching row.
22 The rows were sorted to support a group operation (MAX,MIN,AVERAGE, SUM, etc).
23 A view definition was processed, either from a stored view WEIJ. or as defined by steps 22.
24 For each row retrieved by step 17, the operation in step 23 was performed to find a matching row.
25 One or more rows were retrieved using index SCHEMANMERR.XIE_BATCH_CONTROL_6 . The index was scanned in ascending order..
26 The rows were sorted to support a group operation (MAX,MIN,AVERAGE, SUM, etc).
27 For the rows returned by step 26, filter out rows depending on filter criteria.
28 Return all rows from steps 24, 27 - including duplicate rows.
29 A view definition was processed, either from a stored view WEIJ. or as defined by steps 28.
30 For each row retrieved by step 4, the operation in step 29 was performed to find a matching row.
31 The rows were sorted to support the join at step 37.
32 Rows were retrieved from concatenated index Partitions determined by Key Values without using the leading column(s).
33 Rows from table Partitions determined by Key Values were accessed using rowid got from a local (single-partition) index.
34 PARTITION LIST SINGLE
35 PARTITION RANGE ALL
36 The rows were sorted to support the join at step 37.
37 Join the sorted results sets provided from steps 31, 36.
38 Rows were retrieved using the unique index Partitions determined by Key Values.
39 Rows from table Partitions determined by Key Values were accessed using rowid got from a local (single-partition) index.
40 PARTITION LIST SINGLE
41 A range of partitions of steps 40 were accessed..
42 For each row retrieved by step 37, the operation in step 41 was performed to find a matching row.
43 Rows were retrieved using the unique index SCHEMANMADM.XPK_INSTRUMENT .
44 Rows from table SCHEMANMADM.INSTRUMENT were accessed using rowid got from an index.
45 For each row retrieved by step 42, the operation in step 44 was performed to find a matching row.
46 One or more rows were retrieved using index Partitions determined by Key Values. The index was scanned in ascending order..
47 PARTITION LIST SINGLE
48 A range of partitions of steps 47 were accessed..
49 For each row retrieved by step 45, the operation in step 48 was performed to find a matching row.
50 Rows from table SCHEMANMADM.INSTRUMENT_BALANCE were accessed using rowid got from a local (single-partition) index.
51 Every row in the table SCHEMANMINT.SCHEMANMF_ACCOUNTING_PERIOD is read.
52 The result sets from steps 50, 51 were joined (hash).
53 Every row in the table SYS.SYS_TEMP_0FD9D6651_E9A50186 is read.
54 A view definition was processed, either from a stored view WEIJ. or as defined by steps 53.
55 For each row retrieved by step 52, the operation in step 54 was performed to find a matching row.
56 The rows from step 55 were inserted into using direct-load insert.
57 Every row in the table SYS.SYS_TEMP_0FD9D6652_E9A50186 is read.
58 A view definition was processed, either from a stored view WEIJ. or as defined by steps 57.
59 Rows were retrieved using the unique index Partitions determined by Key Values.
60 Rows from table Partitions determined by Key Values were accessed using rowid got from a local (single-partition) index.
61 PARTITION LIST SINGLE
62 A range of partitions of steps 61 were accessed..
63 For each row retrieved by step 58, the operation in step 62 was performed to find a matching row.
64 Every row in the table SYS.SYS_TEMP_0FD9D6652_E9A50186 is read.
65 A view definition was processed, either from a stored view WEIJ. or as defined by steps 64.
66 Return all rows from steps 63, 65 - including duplicate rows.
67 TEMP TABLE TRANSFORMATION
68 Rows were returned by the SELECT statement.
++++++++++++++++++++++++++++++++++
Plan@NEW UAT
===============
1 One or more rows were retrieved using index SCHEMANMERR.XAK_BATCH_CONTROL_3 . The index was scanned in ascending order..
2 The rows from step 1 were inserted into using direct-load insert.
3 Rows were retrieved using the unique index SCHEMANMMAP.XPK_SOURCE_SYSTEM_FEED .
4 Rows from table SCHEMANMMAP.SCHEMANMF_SOURCE_SYSTEM_FEED were accessed using rowid got from an index.
5 Every row in the table Partitions determined by Key Values is read.
6 PARTITION LIST SINGLE
7 PARTITION RANGE ALL
8 For each row retrieved by step 4, the operation in step 7 was performed to find a matching row.
9 Rows were retrieved using the unique index Partitions determined by Key Values.
10 Rows from table Partitions determined by Key Values were accessed using rowid got from a local (single-partition) index.
11 PARTITION LIST SINGLE
12 A range of partitions of steps 11 were accessed..
13 For each row retrieved by step 8, the operation in step 12 was performed to find a matching row.
14 Rows were retrieved using the unique index SCHEMANMADM.XPK_INSTRUMENT .
15 Rows from table SCHEMANMADM.INSTRUMENT were accessed using rowid got from an index.
16 For each row retrieved by step 13, the operation in step 15 was performed to find a matching row.
17 One or more rows were retrieved using index Partitions determined by Key Values. The index was scanned in ascending order..
18 PARTITION LIST SINGLE
19 A range of partitions of steps 18 were accessed..
20 For each row retrieved by step 16, the operation in step 19 was performed to find a matching row.
21 Rows from table SCHEMANMADM.INSTRUMENT_BALANCE were accessed using rowid got from a local (single-partition) index.
22 Every row in the table SCHEMANMINT.SCHEMANMF_ACCOUNTING_PERIOD is read.
23 The result sets from steps 21, 22 were joined (hash).
24 Every row in the table SYS.SYS_TEMP_0FD9FC8FB_DC4EE804 is read.
25 A view definition was processed, either from a stored view WEIJ. or as defined by steps 24.
26 One or more rows were retrieved using index SCHEMANMERR.XAK_BATCH_CONTROL_4 . The index was scanned in ascending order..
27 The result sets from steps 25, 26 were joined (hash).
28 The rows were sorted to support a group operation (MAX,MIN,AVERAGE, SUM, etc).
29 A view definition was processed, either from a stored view WEIJ. or as defined by steps 28.
30 Every row in the table SYS.SYS_TEMP_0FD9FC8FB_DC4EE804 is read.
31 A view definition was processed, either from a stored view WEIJ. or as defined by steps 30.
32 One or more rows were retrieved using index SCHEMANMERR.XAK_BATCH_CONTROL_5 . The index was scanned in ascending order..
33 The result sets from steps 31, 32 were joined (hash).
34 The rows were sorted to support a group operation (MAX,MIN,AVERAGE, SUM, etc).
35 A view definition was processed, either from a stored view WEIJ. or as defined by steps 34.
36 For each row retrieved by step 29, the operation in step 35 was performed to find a matching row.
37 Every row in the table SYS.SYS_TEMP_0FD9FC8FB_DC4EE804 is read.
38 A view definition was processed, either from a stored view WEIJ. or as defined by steps 37.
39 One or more rows were retrieved using index SCHEMANMERR.XAK_BATCH_CONTROL_5 . The index was scanned in ascending order..
40 The result sets from steps 38, 39 were joined (hash).
41 The rows were sorted to support a group operation (MAX,MIN,AVERAGE, SUM, etc).
42 A view definition was processed, either from a stored view WEIJ. or as defined by steps 41.
43 For each row retrieved by step 36, the operation in step 42 was performed to find a matching row.
44 One or more rows were retrieved using index SCHEMANMERR.XIE_BATCH_CONTROL_6 . The index was scanned in ascending order..
45 The rows were sorted to support a group operation (MAX,MIN,AVERAGE, SUM, etc).
46 For the rows returned by step 45, filter out rows depending on filter criteria.
47 Return all rows from steps 43, 46 - including duplicate rows.
48 A view definition was processed, either from a stored view WEIJ. or as defined by steps 47.
49 For each row retrieved by step 23, the operation in step 48 was performed to find a matching row.
50 Every row in the table SYS.SYS_TEMP_0FD9FC8FB_DC4EE804 is read.
51 A view definition was processed, either from a stored view WEIJ. or as defined by steps 50.
52 For each row retrieved by step 49, the operation in step 51 was performed to find a matching row.
53 The rows from step 52 were inserted into using direct-load insert.
54 Every row in the table SYS.SYS_TEMP_0FD9FC8FC_DC4EE804 is read.
55 A view definition was processed, either from a stored view WEIJ. or as defined by steps 54.
56 Rows were retrieved using the unique index Partitions determined by Key Values.
57 Rows from table Partitions determined by Key Values were accessed using rowid got from a local (single-partition) index.
58 PARTITION LIST SINGLE
59 A range of partitions of steps 58 were accessed..
60 For each row retrieved by step 55, the operation in step 59 was performed to find a matching row.
61 Every row in the table SYS.SYS_TEMP_0FD9FC8FC_DC4EE804 is read.
62 A view definition was processed, either from a stored view WEIJ. or as defined by steps 61.
63 Return all rows from steps 60, 62 - including duplicate rows.
64 TEMP TABLE TRANSFORMATION
65 Rows were returned by the SELECT statement.

Oracle 10g performance is slow

Similar Messages

Maybe you are looking for