Again related to performance

94 views
Skip to first unread message

Raj

unread,
Aug 7, 2007, 6:10:29 AM8/7/07
to ORACLE_DBA_EXPERTS
Hello Davind and all,

I am running out of ideas for the below mentioned query which is
taking two seconds for one execution.

Will appreciate pointers to improve the performance. This query is a
part of trigger which is getting fired when any update or insert is
taking place on table.

SELECT a.fpl_id, a.pzug_id, a.pzv_key, a.ein, a.e_id, a.bst_rei,
count(*), b.zn FROM PV_BTE a, PPL_Z b
WHERE ( a.pzug_id=b.pzug_id ) GROUP BY a.fpl_id, a.pzug_id, a.pzv_key,
a.ein, a.e_id, a.bst_rei, b.zn HAVING count(*)>1

call count cpu elapsed disk query
current rows
------- ------ -------- ---------- ---------- ---------- ----------
----------
Parse 1 0.00 0.00 0 0
0 0
Execute 1 0.00 0.00 0 0
0 0
Fetch 1 0.52 2.03 607 14436
55 0
------- ------ -------- ---------- ---------- ---------- ----------
----------
total 3 0.52 2.03 607 14436
55 0

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 102

Rows Row Source Operation
------- ---------------------------------------------------
0 FILTER
82650 SORT GROUP BY
82649 NESTED LOOPS
6347 TABLE ACCESS FULL PPL_Z
82649 TABLE ACCESS BY INDEX ROWID PV_BTE
88995 INDEX RANGE SCAN (object id 50700)

Index on PPL_Z:

INDEX_NAME UNIQUENES COLUMN_NAME
------------------------------ ---------
------------------------------
FK1_PZUG_I NONUNIQUE FPL_ID

PZUG_PK UNIQUE PZUG_ID

PZUG_UK UNIQUE FPL_ID
UNIQUE ZN


Index on PV_BTE :

INDEX_NAME UNIQUENES COLUMN_NAME
------------------------------ ---------
------------------------------
PZVK_BSF_FK_I NONUNIQUE E_ID
NONUNIQUE BST_REI

PZVK_BST_FK_I NONUNIQUE BST_ID

PZVK_PK UNIQUE PZVK_ID

PZVK_PZV_FK_I NONUNIQUE PZUG_ID
NONUNIQUE PZV_KEY


Can somebody suggests ways to improve the performance of this
query....I am running out of ideas.

Thanks, raj

fitzj...@cox.net

unread,
Aug 7, 2007, 8:32:41 AM8/7/07
to ORACLE_DBA_EXPERTS

Two seconds is NOT unreasonable for a group by aggregate query.

Since this is 8.1.7 you have few options except to ensure your
statistics are current; my guess is they are not. Other than that
suggestion without further information on which init parameters are
set and to what values it will be difficult to offer any further
assistance.


David Fitzjarrell

Raj

unread,
Aug 7, 2007, 8:53:42 AM8/7/07
to ORACLE_DBA_EXPERTS

> David Fitzjarrell- Hide quoted text -
>
> - Show quoted text -

Hello David,

Thanks for your reply as usual.

That query is a part of trigger. On any insert and update command on
table...this query is looking for two paths/route for one train. If it
finds one, it throws error, as there can not be 2 paths/route for one
train.

We are storing the value of count(*) in str_cnt and doing below
mentioned comparison :

IF str_cnt > 1 THEN
RAISE NO_EIND_STR;
END IF;

Please see the parameter value pasted below :

SQL> sho parameter

NAME TYPE VALUE
------------------------------------ -------
------------------------------
active_instance_count integer
always_anti_join string NESTED_LOOPS
always_semi_join string standard
aq_tm_processes integer 0
audit_file_dest string ?/rdbms/audit
audit_trail string NONE
background_core_dump string partial
background_dump_dest string /usr/oracle/app/oracle/
admin/
ZTSS2/bdump
backup_tape_io_slaves boolean FALSE
bitmap_merge_area_size integer 1048576
blank_trimming boolean FALSE
buffer_pool_keep string
buffer_pool_recycle string
commit_point_strength integer 1
compatible string 8.0.5.0.0
control_file_record_keep_time integer 7
control_files string /tablespaces/control_1, /
table
spaces/control_2, /
tablespaces
/control_3
core_dump_dest string /usr/oracle/app/oracle/
admin/
ZTSS2/cdump
cpu_count integer 1
create_bitmap_area_size integer 8388608
cursor_sharing string EXACT
cursor_space_for_time boolean FALSE
db_block_buffers integer 4500
db_block_checking boolean FALSE
db_block_checksum boolean FALSE
db_block_lru_latches integer 1
db_block_max_dirty_target integer 4500
db_block_size integer 8192
db_domain string
db_file_direct_io_count integer 64
db_file_multiblock_read_count integer 32
db_file_name_convert string
db_files integer 50
dblink_encrypt_login boolean FALSE
db_name string ZTSS
dbwr_io_slaves integer 0
db_writer_processes integer 1
disk_asynch_io boolean TRUE
distributed_transactions integer 61
dml_locks integer 500
enqueue_resources integer 570
event string 4091 trace name context
foreve
r, level 10; name
systemstate
level 10; name
processstate le
vel 10; name errorstack
level
10
fast_start_io_target integer 4500
fast_start_parallel_rollback string LOW
fixed_date string
gc_defer_time integer 10
gc_files_to_locks string 1-5,8-9=1000EACH:
6=4000:7=800
gc_releasable_locks integer 4500
gc_rollback_locks string 1-8=200EACH
global_names boolean FALSE
hash_area_size integer 2097152
hash_join_enabled boolean TRUE
hash_multiblock_io_count integer 0
hi_shared_memory_address integer 0
hpux_sched_noage integer
hs_autoregister boolean TRUE
ifile file /usr/oracle/app/oracle/
admin/
ZTSS1/pfile/initZTSS.ora
instance_groups string
instance_name string ZTSS2
instance_number integer 2
java_max_sessionspace_size integer 0
java_pool_size string 20000K
java_soft_sessionspace_limit integer 0
job_queue_interval integer 60
job_queue_processes integer 1
large_pool_size string 0
license_max_sessions integer 0
license_max_users integer 0
license_sessions_warning integer 0
lm_locks integer 25627
lm_ress integer 23860
local_listener string
lock_name_space string
lock_sga boolean FALSE
log_archive_dest string
log_archive_dest_state_1 string enable
log_archive_dest_state_2 string enable
log_archive_dest_state_3 string enable
log_archive_dest_state_4 string enable
log_archive_dest_state_5 string enable
log_archive_dest_1 string
log_archive_dest_2 string
log_archive_dest_3 string
log_archive_dest_4 string
log_archive_dest_5 string
log_archive_duplex_dest string
log_archive_format string %t_%s.dbf
log_archive_max_processes integer 1
log_archive_min_succeed_dest integer 1
log_archive_start boolean FALSE
log_archive_trace integer 0
log_buffer integer 163840
log_checkpoint_interval integer 10000
log_checkpoints_to_alert boolean FALSE
log_checkpoint_timeout integer 1800
log_file_name_convert string
max_commit_propagation_delay integer 700
max_dump_file_size string 10240
max_enabled_roles integer 30
max_rollback_segments integer 49
mts_circuits integer 0
mts_dispatchers string
mts_listener_address string
mts_max_dispatchers integer 5
mts_max_servers integer 20
mts_multiple_listeners boolean FALSE
mts_servers integer 0
mts_service string ZTSS
mts_sessions integer 0
nls_calendar string
nls_comp string
nls_currency string
nls_date_format string DD.MM.YYYY HH24:MI:SS
nls_date_language string
nls_dual_currency string
nls_iso_currency string
nls_language string GERMAN
nls_numeric_characters string
nls_sort string
nls_territory string GERMANY
nls_time_format string
nls_timestamp_format string
nls_timestamp_tz_format string
nls_time_tz_format string
object_cache_max_size_percent integer 10
object_cache_optimal_size integer 102400
open_cursors integer 255
open_links integer 4
open_links_per_instance integer 4
ops_interconnects string
optimizer_features_enable string 8.1.7
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_max_permutations integer 80000
optimizer_mode string CHOOSE
optimizer_percent_parallel integer 0
oracle_trace_collection_name string
oracle_trace_collection_path string ?/otrace/admin/cdf
oracle_trace_collection_size integer 5242880
oracle_trace_enable boolean FALSE
oracle_trace_facility_name string oracled
oracle_trace_facility_path string ?/otrace/admin/fdf
os_authent_prefix string ops$
os_roles boolean FALSE
O7_DICTIONARY_ACCESSIBILITY boolean TRUE
parallel_adaptive_multi_user boolean FALSE
parallel_automatic_tuning boolean FALSE
parallel_broadcast_enabled boolean FALSE
parallel_execution_message_size integer 2148
parallel_instance_group string
parallel_max_servers integer 5
parallel_min_percent integer 0
parallel_min_servers integer 0
parallel_server boolean TRUE
parallel_server_instances integer 2
parallel_threads_per_cpu integer 2
partition_view_enabled boolean FALSE
plsql_v2_compatibility boolean FALSE
pre_page_sga boolean FALSE
processes integer 200
query_rewrite_enabled boolean FALSE
query_rewrite_integrity string enforced
rdbms_server_dn string
read_only_open_delayed boolean FALSE
recovery_parallelism integer 0
remote_dependencies_mode string TIMESTAMP
remote_login_passwordfile string NONE
remote_os_authent boolean FALSE
remote_os_roles boolean FALSE
replication_dependency_tracking boolean TRUE
resource_limit boolean FALSE
resource_manager_plan string
rollback_segments string r05, r06, r07, r08
row_locking string always
serializable boolean FALSE
serial_reuse string DISABLE
service_names string ZTSS
session_cached_cursors integer 0
session_max_open_files integer 10
sessions integer 225
shadow_core_dump string partial
shared_memory_address integer 0
shared_pool_reserved_size string 6400000
shared_pool_size string 64000000
sort_area_retained_size integer 65536
sort_area_size integer 1048576
sort_multiblock_read_count integer 2
sql_trace boolean FALSE
sql_version string NATIVE
sql92_security boolean FALSE
standby_archive_dest string ?/dbs/arch
star_transformation_enabled string FALSE
tape_asynch_io boolean TRUE
text_enable boolean FALSE
thread integer 2
timed_os_statistics integer 0
timed_statistics boolean TRUE
tracefile_identifier string
transaction_auditing boolean TRUE
transactions integer 247
transactions_per_rollback_segment integer 5
use_indirect_data_buffers boolean FALSE
user_dump_dest string /usr/oracle/app/oracle/
admin/
ZTSS2/udump
utl_file_dir string /usr/users/log/utl_files


Kindly let me hear your view.

Thanks, Raj


Raj

unread,
Aug 7, 2007, 8:57:33 AM8/7/07
to ORACLE_DBA_EXPERTS

On Aug 7, 2:32 pm, "fitzjarr...@cox.net" <fitzjarr...@cox.net> wrote:

> David Fitzjarrell- Hide quoted text -
>
> - Show quoted text -

Also, forgot to mention that when I am collecting stats, its resulting
in even bad performance. I am using below mentioned commands to
collect the statstics for both the tables:

EXECUTE dbms_stats.gather_table_stats (ownname=>'SAHN',
tabname=>'PPL_Z',estimate_percent=>null,cascade=>true);
EXECUTE dbms_stats.gather_table_stats (ownname=>'SAHN',
tabname=>'PV_BTE',estimate_percent=>null,cascade=>true);

Regards, Rajeev

fitzj...@cox.net

unread,
Aug 7, 2007, 10:10:07 AM8/7/07
to ORACLE_DBA_EXPERTS

On Aug 7, 7:53 am, Raj <rajeev.to...@gmail.com> wrote:
[snipped]


> optimizer_index_caching integer 0
> optimizer_index_cost_adj integer 100

[snipped]


> Kindly let me hear your view.
>
> Thanks, Raj

optimizer_index_caching should be set to a value similar to the Buffer
Cache Hit Ratio to tell Oracle what percentage of index blocks are
likely to be found in the cache.

optimizer_index_cost_adj should be set to 15 or 20; the default
setting of 100 indicates an index scan costs as much as a table scan.
You want to favor index scans in general.


David Fitzjarrell

fitzj...@cox.net

unread,
Aug 7, 2007, 10:18:39 AM8/7/07
to ORACLE_DBA_EXPERTS

> Regards, Rajeev- Hide quoted text -


>
> - Show quoted text -

This indicates either a poorly calculated clustering_factor or the
need for histograms; as your primary key is a single column histograms
should not be the issue, so I suspect it's a flaw in the way Oracle
has calculated the clustering factor. I would suggest you purchase
"Cost-based Oracle Fundamentals", Jonathan Lewis, Apress Publishing,
and read Chapter 5.


David Fitzjarrell

Raj

unread,
Aug 7, 2007, 11:20:22 AM8/7/07
to ORACLE_DBA_EXPERTS

David,

You seems to be correct in your analysys.

SQL> select t.blocks, i.clustering_factor, t.num_rows from user_tables
t, user_indexes i where t.table_name=i.table_name and
t.table_name='PPL_Z';

BLOCKS CLUSTERING_FACTOR NUM_ROWS
---------- ----------------- ----------
34 55 6346
34 68 6346
34 4878 6346

Cluster factor is not proper. For sure I will go through that book,
but can you suggest some ways to correct it in quick go...??

Again I am saying, I will go through that book.

Thanks much.

Regards, Raj

fitzj...@cox.net

unread,
Aug 7, 2007, 11:58:46 AM8/7/07
to ORACLE_DBA_EXPERTS

> Regards, Raj- Hide quoted text -


>
> - Show quoted text -

Which index is showing this 'improper clustering factor'? It may not
be 'improper' at all given the columns indexed and the data
distribution. You could run the following query to see what your
clustering factor could be:

select /*+ cursor_sharing_exact
no_monitoring
no_expand
index(ppl_z, fk1_pzug_i)
noparallel_index(ppl_z, fk1_pzug_i)
*/
sys_op_countchg(substrb(rowid, 1, 15), 32) clf
from ppl_z
where fpl_id is not null;

You might find the clustering_factor to be exactly where it is
supposed to be; you may find otherwise.

We can go further with this after you run the query and post the
results.


David Fitzjarrell

Charles Hooper

unread,
Aug 7, 2007, 12:41:25 PM8/7/07
to ORACLE_DBA_EXPERTS

Just a couple questions for the OP:
If this query is being executed in a trigger, shouldn't there be come
kind of restriction on the two tables, so that Oracle does not need to
always join at least 6,347 rows from PPL_Z with at least 82,649 rows
from PV_BTE? It would seem that you could restrict the number of rows
involved in the join based on the action that caused the trigger to
fire. Is PZUG_ID (or a related column) available to the trigger?

db_block_buffers is set at 4500, which should be reserving roughly
36MB for caching DB block buffers. I dislike reading TKPROF output (I
prefer raw trace data), but it appears that 607 physical reads were
required, which may have accounted for the majority of the 2.03
seconds.

hash_area_size is roughly 2MB, which may be a bit small. While the
query is not using a hash join, such a join *may* be faster than a
nested loops join in this case.

java_pool_size is roughly 20MB, if you are not using server side Java,
consider setting this value to 1MB and using that memory for something
else (maybe DB block buffers).

sort_area_retained_size is not the same value as sort_area_size. In
the book that David references, Jonathan Lewis describes how this
might be a problem during sort result retrieval. You might try
experimenting with different values of sort_area_size to see if it
makes a difference. Oracle 8i performs an implicit sort during a
GROUP BY, and this sort is likely spilling to the temp tablespace.

I noticed this in the parameters: event 4091 trace name context
forever, level 10; name systemstate level 10; name processstate level
10; name errorstack level 10 - any idea what the intention of this
might be? Do you think it may be slowing down the database
performance?

Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Raj

unread,
Aug 8, 2007, 4:53:35 AM8/8/07
to ORACLE_DBA_EXPERTS

Hello David,

Problem seems to be in PZUG_UK index on PPL_Z. Please see the output.

SQL> select t.blocks, i.clustering_factor, t.num_rows, i.index_name


from user_tables t, user_indexes i where t.table_name=i.table_name and
t.table_name='PPL_Z';

BLOCKS CLUSTERING_FACTOR NUM_ROWS INDEX_NAME
---------- ----------------- ---------- ------------------------------
34 55 6346 FK1_PZUG_I
34 68 6346 PZUG_PK
34 4878 6346 PZUG_UK

I am trying to run your query, but getting error Invalid column name :

SQL> select /*+ cursor_sharing_exact
2 no_monitoring
3 no_expand
4 index(PPL_Z,FK1_PZUG_I)
5 noparallel_index(PPL_Z,FK1_PZUG_I)
6 */
7 sys_op_countchg(substrb(rowid, 1, 15), 32) clf
8 from PPL_Z
9 where fpl_id is not null;


sys_op_countchg(substrb(rowid, 1, 15), 32) clf

*
ERROR at line 7:
ORA-00904: invalid column name

Please let me hear from you.

Regards, Raj


fitzj...@cox.net

unread,
Aug 8, 2007, 8:44:48 AM8/8/07
to ORACLE_DBA_EXPERTS

The sys_op_countchg procedure is available in 9iR2 and later releases;
unfortunately it isn't present in 8.1.7 which is the release you're
apparently using (I found this information in another thread of yours;
THIS is precisely why the Oracle release MUST be specified when you
ask your questions).

Simply because your clustering_factor is a large number doesn't make
it suspect; it may be an accurate reflection of the data distribution
in your table/index.

I would start looking at the data distribution in that column, were I
you:

select fpl_id, count(*)
from ppl_z
group by fpl_id;

See if you have exceptionally high counts for selected fpl_id values
relative to the total number of rows in that table; this MAY be a good
candidate for histograms.


David Fitzjarrell

Raj

unread,
Aug 8, 2007, 9:10:24 AM8/8/07
to ORACLE_DBA_EXPERTS

Hello David,

Thanks for your reply once again.

SQL> select fpl_id , count(*) from ppl_z group by fpl_id;

FPL_ID COUNT(*)
---------- ----------
569 1123
571 1055
572 1067
573 855
574 1123
584 1123

With this data, it seems there is no need of histograms... What you
say ??

Also, is it advisable to set clustering factors with the help
dbms_stats.set_index_stats procedure...??

Regards, Rajeev

Raj

unread,
Aug 8, 2007, 9:11:40 AM8/8/07
to ORACLE_DBA_EXPERTS

> K&M Machine-Fabricating, Inc.- Hide quoted text -


>
> - Show quoted text -

Hello Charles,

Thanks for your valuable input.

I will check your suggestions and will let you know in detail.

Regards, Raj

Raj

unread,
Aug 8, 2007, 9:58:59 AM8/8/07
to ORACLE_DBA_EXPERTS

On Aug 7, 6:41 pm, Charles Hooper <hooperc2...@yahoo.com> wrote:

> K&M Machine-Fabricating, Inc.- Hide quoted text -


>
> - Show quoted text -

Charles,

Also please see the execution plan with the help from autotrace :

----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=634 Card=4133 Bytes=
169453)

1 0 FILTER
2 1 SORT (GROUP BY) (Cost=634 Card=4133 Bytes=169453)
3 2 HASH JOIN (Cost=47 Card=82649 Bytes=3388609)
4 3 TABLE ACCESS (FULL) OF 'PPL_Z' (Cost=3 Card=6346
Bytes=69806)

5 3 TABLE ACCESS (FULL) OF 'PV_BTE' (Cost=32 Card=
82649 Bytes=2479470)

Regards, Raj

fitzj...@cox.net

unread,
Aug 8, 2007, 10:27:16 AM8/8/07
to ORACLE_DBA_EXPERTS

You have no method of computing a replacement clustering_factor value
so I would advise against such action. The sys_op_countchg() function
would have provided a possibly more reasonable value for the
clustering_factor and given you something to use as a test value.
Absent that functionality I cannot recommend you change such
statistics.

Charles has brought forth some excellent points; when we hear back
from you on those we can go further.


David Fitzjarrell

Raj

unread,
Aug 8, 2007, 12:35:37 PM8/8/07
to ORACLE_DBA_EXPERTS

On Aug 7, 6:41 pm, Charles Hooper <hooperc2...@yahoo.com> wrote:

> K&M Machine-Fabricating, Inc.- Hide quoted text -


>
> - Show quoted text -

Hello Charles,

Hash join is not making any difference to the performance. Please see
the output below :

I performed the test with the below mentioned parameter :

SQL> sho parameter hash

NAME TYPE VALUE
------------------------------------ -------
------------------------------

hash_area_size integer 10485760
hash_join_enabled boolean TRUE
hash_multiblock_io_count integer 32

SQL> sho parameter optimizer_index

NAME TYPE VALUE
------------------------------------ -------
------------------------------

optimizer_index_caching integer 99
optimizer_index_cost_adj integer 15

SQL> sho parameter java_pool_size

NAME TYPE VALUE
------------------------------------ -------
------------------------------

java_pool_size string 2000K

SQL> sho parameter db_block_buffers

NAME TYPE VALUE
------------------------------------ -------
------------------------------

db_block_buffers integer 9000


SELECT /*+ USE_HASH(PPL_Z,PV_BTE) */ a.fpl_id, a.pzug_id, a.pzv_key,
a.einbruchzeit, a.strecke_id, a.bst_reihenfolge, count(*), b.zn
FROM
PV_BTE a,PPL_Z b WHERE (a.pzug_id=b.pzug_id ) GROUP BY a.fpl_id,
a.pzug_id, a.pzv_key, a.einbruchzeit, a.strecke_id,
a.bst_reihenfolge,
b.zn HAVING count(*)>1

SQL explain plan :

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=625 Card=4133 Bytes=
169453)

1 0 FILTER
2 1 SORT (GROUP BY) (Cost=625 Card=4133 Bytes=169453)
3 2 HASH JOIN (Cost=38 Card=82649 Bytes=3388609)


4 3 TABLE ACCESS (FULL) OF 'PPL_Z' (Cost=3 Card=6346
Bytes=69806)

5 3 TABLE ACCESS (FULL) OF 'PV_BTE' (Cost=32 Card=
82649 Bytes=2479470)

Statistiken
----------------------------------------------------------
449 recursive calls
98 db block gets
697 consistent gets
574 physical reads
10160 redo size
590 bytes sent via SQL*Net to client
319 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
1 sorts (disk)
0 rows processed

Please let me know if you have some input on this ??

Regards, Raj

Raj

unread,
Aug 8, 2007, 12:38:34 PM8/8/07
to ORACLE_DBA_EXPERTS

> You have- Hide quoted text -
>
> - Show quoted text -...
>
> read more »

Hello David,

I was planning to buy the book you suggessted, but thought to search
on internet first and luckily got the chapter 5 URL :

http://www.apress.com/ApressCorporate/supplement/1/10081/1590596366-3080.pdf

I am sending this link to the group, so that people can read it (if
they dont want to invest)...:-)

It's really wonderful to go through such unknown things/concepts.

Thanks much.

Regards, Raj

Charles Hooper

unread,
Aug 8, 2007, 1:32:39 PM8/8/07
to ORACLE_DBA_EXPERTS

> SELECT /*+ USE_HASH(PPL_Z,PV_BTE) */ a.fpl_id, a.pzug_id, a.pzv_key,

To find the real source of the problem (and the solution), you will
likely need to use a 10046 trace at level 8, otherwise we will be
making somewhat blind guesses. The following is a snippet of a 10046
trace at level 8 from an Oracle 8.1.7.3 database:
PARSING IN CURSOR #10 len=107 dep=0 uid=78 oct=3 lid=78 tim=369800045
hv=3449954084 ad='9ac4ae0'
select max(schedule_rank) from workorder_audit
where schedule_id = :1
END OF STMT
PARSE #10:c=0,e=0,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=0,tim=369800045
WAIT #10: nam='SQL*Net message to client' ela= 0 p1=1413697536 p2=1
p3=0
WAIT #10: nam='SQL*Net message from client' ela= 0 p1=1413697536 p2=1
p3=0
EXEC #10:c=0,e=0,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=369800045
WAIT #10: nam='SQL*Net message to client' ela= 0 p1=1413697536 p2=1
p3=0
WAIT #10: nam='SQL*Net message from client' ela= 0 p1=1413697536 p2=1
p3=0
WAIT #10: nam='db file scattered read' ela= 3 p1=3 p2=13011 p3=3
WAIT #10: nam='db file sequential read' ela= 0 p1=3 p2=13018 p3=1
WAIT #10: nam='db file sequential read' ela= 0 p1=3 p2=13021 p3=1
WAIT #10: nam='file open' ela= 0 p1=0 p2=0 p3=0
WAIT #10: nam='db file sequential read' ela= 2 p1=4 p2=151050 p3=1
WAIT #10: nam='db file sequential read' ela= 0 p1=4 p2=151055 p3=1
WAIT #10: nam='db file sequential read' ela= 1 p1=3 p2=165047 p3=1
WAIT #10: nam='db file scattered read' ela= 2 p1=4 p2=209661 p3=4
WAIT #10: nam='SQL*Net message to client' ela= 0 p1=1413697536 p2=1
p3=0
FETCH #10:c=3,e=8,p=12,cr=115,cu=4,mis=0,r=1,dep=0,og=4,tim=369800053
WAIT #10: nam='SQL*Net message from client' ela= 0 p1=1413697536 p2=1
p3=0
STAT #10 id=1 cnt=1 pid=0 pos=0 obj=0 op='SORT AGGREGATE '
STAT #10 id=2 cnt=13801 pid=1 pos=1 obj=4010 op='TABLE ACCESS FULL
WORKORDER_AUDIT '

Note the wait events: "'db file scattered read' ela= 3 p1=3 p2=13011
p3=3", "'db file sequential read' ela= 0 p1=3 p2=13018 p3=1" - from
this I can determine the amount of time spent in each operation, I can
determine the object being read, and I can tell the number of blocks
read.

The EXEC and FETCH lines are also helpful:
"EXEC #10:c=0,e=0,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=369800045"
"FETCH
#10:c=3,e=8,p=12,cr=115,cu=4,mis=0,r=1,dep=0,og=4,tim=369800053"

During the fetch, 3/100 of a second of CPU time was consumed, 8/100 of
a second of elapsed (clock) time was consumed, 12 blocks were read by
a physical read, 115 blocks read by a consistent get, 4 blocks read in
current mode (most efficient), and one row was returned. Something
must have caused the 5/100 seconds difference between the CPU time and
the elapsed time, and that was likely the physical read.

Let's take a look at what you posted.
* Hash_area_size defaults to twice the sort_area_size. Your query has
one sort to disk that happened during the implicit sort of the GROUP
BY, but you did not adjust the sort_area_size - you might try
increasing the size of the sort_area_size.
* The query reads roughly half of the blocks from disk, and the other
half from the buffer cache.
* Redo size appears in the statistics, which is probably a sign of
delayed block cleanout - dirty blocks had to be forced from the buffer
cache to allow the 574 blocks needed by the query to be read into the
buffer cache.
* The explain plan changed from an index lookup with another tablescan
to two tablescans - typically blocks that are read by a full tablescan
end up at the LRU end of the buffer cache, so they are among the first
to be flushed from the buffer cache. This can be addressed.
* 449 recursive calls (SQL execution calls) - those are things that
Oracle is performing in the background for you to execute the query.
This number might have to do with the "event 4091 trace name
context..." that I pointed out in my initial response.

Raj

unread,
Aug 9, 2007, 3:48:46 AM8/9/07
to ORACLE_DBA_EXPERTS

> read more »- Hide quoted text -
>
> - Show quoted text -...

Hello Charles,

Thanks for such a detailed reply and help.

I have removed the 4091 trace event from the init.ora file and have
changed the sort parameters as pasted below :

SQL> sho parameter even

NAME TYPE VALUE
------------------------------------ -------
------------------------------

event string

SQL> sho parameter sort

NAME TYPE VALUE
------------------------------------ -------
------------------------------

nls_sort string
sort_area_retained_size integer 5242880
sort_area_size integer 5242880

Also, I am keeping above mentioned parameters in previous posts )
unchanged.

After putting 10046 trace on session ( ALTER SESSION SET EVENTS '10046
trace name context forever, level 8';), executed the query. Could see
trace file in udump directory. Contents are pasted below :

Dump file /usr/oracle/app/oracle/admin/ZTSS2/udump/ora_28315.trc
Oracle8i Enterprise Edition Release 8.1.7.3.0 - Production
With the Parallel Server option
JServer Release 8.1.7.3.0 - Production
ORACLE_HOME = /usr/oracle/app/oracle/product/8.1.7
System name: Linux
Node name: mcnode2
Release: 2.2.16
Version: #1 Tue Nov 27 14:47:58 CET 2001
Machine: i?86
Instance name: ZTSS2
Redo thread mounted by this instance: 2
Oracle process number: 14
Unix process pid: 28315, image: oracle@mcnode2 (TNS V1-V3)

*** 2007-08-09 09:12:22.735
*** SESSION ID:(10.21) 2007-08-09 09:12:22.735
APPNAME mod='SQL*Plus' mh=3669949024 act='' ah=4029777240
=====================
PARSING IN CURSOR #1 len=69 dep=0 uid=102 oct=42 lid=102 tim=0
hv=89553408 ad='5390950c'
ALTER SESSION SET EVENTS '10046 trace name context forever, level 8'
END OF STMT
EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=0
WAIT #1: nam='SQL*Net message to client' ela= 0 p1=1650815232 p2=1
p3=0
*** 2007-08-09 09:12:45.700
WAIT #1: nam='SQL*Net message from client' ela= 0 p1=1650815232 p2=1
p3=0
=====================
PARSING IN CURSOR #1 len=280 dep=0 uid=102 oct=3 lid=102 tim=0
hv=4091191153 ad='539d2b54'
SELECT a.fpl_id, a.pzug_id, a.pzv_key, a.einbruchzeit, a.strecke_id,
a.bst_reihenfolge, count(*), b.zn FROM PV_BTE a, PPL_Z b WHERE


( a.pzug_id=b.pzug_id ) GROUP BY a.fpl_id, a.pzug_id, a.pzv_key,

a.einbruchzeit, a.strecke_id, a.bst_reihenfolge, b.zn HAVING
count(*)>1

END OF STMT
PARSE #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=0
EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=0
WAIT #1: nam='SQL*Net message to client' ela= 0 p1=1650815232 p2=1
p3=0
WAIT #1: nam='global cache cr request' ela= 0 p1=7 p2=21803 p3=11201
WAIT #1: nam='global cache cr request' ela= 0 p1=7 p2=21803 p3=11201
WAIT #1: nam='file open' ela= 0 p1=0 p2=0 p3=0
WAIT #1: nam='db file sequential read' ela= 0 p1=7 p2=21803 p3=1
WAIT #1: nam='global cache cr request' ela= 0 p1=7 p2=24199 p3=11197
WAIT #1: nam='global cache cr request' ela= 0 p1=7 p2=24199 p3=11197
WAIT #1: nam='db file sequential read' ela= 0 p1=7 p2=24199 p3=1
WAIT #1: nam='enqueue' ela= 0 p1=1414791172 p2=3 p3=16
WAIT #1: nam='enqueue' ela= 0 p1=1398013958 p2=0 p3=0
=====================
PARSING IN CURSOR #2 len=36 dep=1 uid=0 oct=3 lid=0 tim=0
hv=1705880752 ad='539b1a7c'
select file# from file$ where ts#=:1
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=17 op='TABLE ACCESS BY INDEX ROWID
FILE$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=39 op='INDEX RANGE SCAN '
WAIT #1: nam='row cache lock' ela= 0 p1=4 p2=0 p3=5
WAIT #1: nam='row cache lock' ela= 0 p1=4 p2=0 p3=5
=====================
PARSING IN CURSOR #2 len=94 dep=1 uid=0 oct=3 lid=0 tim=0
hv=1839874543 ad='539acfd0'
select file#,block#,length from uet$ where ts#=:1 and segfile#=:2 and
segblock#=:3 and ext#=:4
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
WAIT #2: nam='global cache cr request' ela= 0 p1=1 p2=3464 p3=462
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=0
STAT #2 id=1 cnt=0 pid=0 pos=0 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=2 cnt=1 pid=1 pos=1 obj=9 op='INDEX UNIQUE SCAN '
WAIT #1: nam='enqueue' ela= 0 p1=1414725638 p2=3 p3=16777868
WAIT #1: nam='row cache lock' ela= 0 p1=2 p2=0 p3=5
=====================
PARSING IN CURSOR #2 len=190 dep=1 uid=0 oct=3 lid=0 tim=0
hv=4059714361 ad='53ad1c7c'
select
type#,blocks,extents,minexts,maxexts,extsize,extpct,user#,iniexts,NVL(lists,
65535),NVL(groups,65535),cachehint,hwmincr, NVL(spare1,0) from seg$
where ts#=:1 and file#=:2 and block#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=0
STAT #2 id=1 cnt=0 pid=0 pos=0 obj=14 op='TABLE ACCESS CLUSTER SEG$ '
STAT #2 id=2 cnt=1 pid=1 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================
PARSING IN CURSOR #2 len=254 dep=1 uid=0 oct=2 lid=0 tim=0
hv=4003880563 ad='539a94a4'
insert into seg$
(file#,block#,type#,ts#,blocks,extents,minexts,maxexts,extsize,extpct,user#,iniexts,lists,groups,cachehint,bitmapranges,scanhint,
hwmincr, spare1) values (:
1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,:15,0,0,:16,DECODE(:
17,0,NULL,:17))
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
WAIT #2: nam='enqueue' ela= 0 p1=1414332419 p2=14 p3=0
WAIT #2: nam='global cache lock null to x' ela= 0 p1=1 p2=5091 p3=89
WAIT #2: nam='file open' ela= 0 p1=0 p2=0 p3=0
WAIT #2: nam='db file sequential read' ela= 0 p1=1 p2=5091 p3=1
WAIT #2: nam='global cache lock open x' ela= 0 p1=1 p2=3464 p3=462
WAIT #2: nam='db file sequential read' ela= 0 p1=1 p2=3464 p3=1
WAIT #2: nam='global cache lock null to x' ela= 0 p1=1 p2=5953 p3=951
WAIT #2: nam='db file sequential read' ela= 0 p1=1 p2=5953 p3=1
WAIT #2: nam='global cache lock s to x' ela= 0 p1=3 p2=3092 p3=13406
EXEC #2:c=0,e=0,p=3,cr=3,cu=20,mis=0,r=1,dep=1,og=4,tim=0
=====================
PARSING IN CURSOR #2 len=101 dep=1 uid=0 oct=2 lid=0 tim=0
hv=3687396716 ad='539a8474'
insert into uet$
(segfile#,segblock#,ext#,ts#,file#,block#,length)values (:1, :2, :3, :
4, :5, :6, :7)
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=2,cu=1,mis=0,r=1,dep=1,og=4,tim=0
=====================
PARSING IN CURSOR #2 len=56 dep=1 uid=0 oct=7 lid=0 tim=0
hv=1877781575 ad='5399ae98'
delete from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
WAIT #2: nam='enqueue' ela= 0 p1=1414332419 p2=12 p3=0
WAIT #2: nam='global cache cr request' ela= 0 p1=1 p2=5059 p3=57
WAIT #2: nam='global cache lock open x' ela= 0 p1=1 p2=5059 p3=57
WAIT #2: nam='db file sequential read' ela= 0 p1=1 p2=5059 p3=1
EXEC #2:c=0,e=0,p=1,cr=4,cu=1,mis=0,r=1,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=7 op='INDEX UNIQUE SCAN '
WAIT #1: nam='file open' ela= 0 p1=0 p2=0 p3=0
WAIT #1: nam='enqueue' ela= 0 p1=1398013958 p2=0 p3=0
=====================
PARSING IN CURSOR #2 len=36 dep=1 uid=0 oct=3 lid=0 tim=0
hv=1705880752 ad='539b1a7c'
select file# from file$ where ts#=:1
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=17 op='TABLE ACCESS BY INDEX ROWID
FILE$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=39 op='INDEX RANGE SCAN '
=====================
PARSING IN CURSOR #2 len=94 dep=1 uid=0 oct=3 lid=0 tim=0
hv=1839874543 ad='539acfd0'
select file#,block#,length from uet$ where ts#=:1 and segfile#=:2 and
segblock#=:3 and ext#=:4
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=0,dep=1,og=4,tim=0
STAT #2 id=1 cnt=0 pid=0 pos=0 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=9 op='INDEX UNIQUE SCAN '
WAIT #1: nam='global cache lock s to x' ela= 0 p1=1 p2=44 p3=13435
WAIT #1: nam='global cache lock s to x' ela= 0 p1=1 p2=44 p3=13435
=====================
PARSING IN CURSOR #2 len=101 dep=1 uid=0 oct=2 lid=0 tim=0
hv=3687396716 ad='539a8474'
insert into uet$
(segfile#,segblock#,ext#,ts#,file#,block#,length)values (:1, :2, :3, :
4, :5, :6, :7)
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=2,cu=2,mis=0,r=1,dep=1,og=4,tim=0
=====================
PARSING IN CURSOR #2 len=56 dep=1 uid=0 oct=7 lid=0 tim=0
hv=1877781575 ad='5399ae98'
delete from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=4,cu=1,mis=0,r=1,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=7 op='INDEX UNIQUE SCAN '
=====================
PARSING IN CURSOR #2 len=283 dep=1 uid=0 oct=6 lid=0 tim=0
hv=2249281901 ad='5399cf64'
update seg$ set type#=:4,blocks=:5,extents=:6,minexts=:7,maxexts=:
8,extsize=:9,extpct=:10,user#=:11,iniexts=:12,lists=decode(:13, 65535,
NULL, :13),groups=decode(:14, 65535, NULL, :14), cachehint=:15,
hwmincr=:16, spare1=DECODE(:17,0,NULL,:17) where ts#=:1 and file#=:2
and block#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=6,cu=1,mis=0,r=1,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='UPDATE SEG$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=14 op='TABLE ACCESS CLUSTER SEG$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
WAIT #1: nam='enqueue' ela= 0 p1=1398013958 p2=0 p3=0
=====================
PARSING IN CURSOR #2 len=36 dep=1 uid=0 oct=3 lid=0 tim=0
hv=1705880752 ad='539b1a7c'
select file# from file$ where ts#=:1
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=17 op='TABLE ACCESS BY INDEX ROWID
FILE$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=39 op='INDEX RANGE SCAN '
WAIT #1: nam='row cache lock' ela= 0 p1=4 p2=0 p3=5
WAIT #1: nam='row cache lock' ela= 0 p1=4 p2=0 p3=5
=====================
PARSING IN CURSOR #2 len=94 dep=1 uid=0 oct=3 lid=0 tim=0
hv=1839874543 ad='539acfd0'
select file#,block#,length from uet$ where ts#=:1 and segfile#=:2 and
segblock#=:3 and ext#=:4
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=0,dep=1,og=4,tim=0
STAT #2 id=1 cnt=0 pid=0 pos=0 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================
PARSING IN CURSOR #2 len=101 dep=1 uid=0 oct=2 lid=0 tim=0
hv=3687396716 ad='539a8474'
insert into uet$
(segfile#,segblock#,ext#,ts#,file#,block#,length)values (:1, :2, :3, :
4, :5, :6, :7)
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=2,cu=2,mis=0,r=1,dep=1,og=4,tim=0
=====================
PARSING IN CURSOR #2 len=56 dep=1 uid=0 oct=7 lid=0 tim=0
hv=1877781575 ad='5399ae98'
delete from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=4,cu=1,mis=0,r=1,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=7 op='INDEX UNIQUE SCAN '
=====================
PARSING IN CURSOR #2 len=283 dep=1 uid=0 oct=6 lid=0 tim=0
hv=2249281901 ad='5399cf64'
update seg$ set type#=:4,blocks=:5,extents=:6,minexts=:7,maxexts=:
8,extsize=:9,extpct=:10,user#=:11,iniexts=:12,lists=decode(:13, 65535,
NULL, :13),groups=decode(:14, 65535, NULL, :14), cachehint=:15,
hwmincr=:16, spare1=DECODE(:17,0,NULL,:17) where ts#=:1 and file#=:2
and block#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=6,cu=1,mis=0,r=1,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='UPDATE SEG$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=14 op='TABLE ACCESS CLUSTER SEG$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
WAIT #1: nam='enqueue' ela= 0 p1=1398013958 p2=0 p3=0
=====================
PARSING IN CURSOR #2 len=36 dep=1 uid=0 oct=3 lid=0 tim=0
hv=1705880752 ad='539b1a7c'
select file# from file$ where ts#=:1
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=17 op='TABLE ACCESS BY INDEX ROWID
FILE$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=39 op='INDEX RANGE SCAN '
=====================
PARSING IN CURSOR #2 len=94 dep=1 uid=0 oct=3 lid=0 tim=0
hv=1839874543 ad='539acfd0'
select file#,block#,length from uet$ where ts#=:1 and segfile#=:2 and
segblock#=:3 and ext#=:4
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=0,dep=1,og=4,tim=0
STAT #2 id=1 cnt=0 pid=0 pos=0 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================
PARSING IN CURSOR #2 len=101 dep=1 uid=0 oct=2 lid=0 tim=0
hv=3687396716 ad='539a8474'
insert into uet$
(segfile#,segblock#,ext#,ts#,file#,block#,length)values (:1, :2, :3, :
4, :5, :6, :7)
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=2,cu=2,mis=0,r=1,dep=1,og=4,tim=0
=====================
PARSING IN CURSOR #2 len=56 dep=1 uid=0 oct=7 lid=0 tim=0
hv=1877781575 ad='5399ae98'
delete from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=4,cu=1,mis=0,r=1,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=7 op='INDEX UNIQUE SCAN '
=====================
PARSING IN CURSOR #2 len=283 dep=1 uid=0 oct=6 lid=0 tim=0
hv=2249281901 ad='5399cf64'
update seg$ set type#=:4,blocks=:5,extents=:6,minexts=:7,maxexts=:
8,extsize=:9,extpct=:10,user#=:11,iniexts=:12,lists=decode(:13, 65535,
NULL, :13),groups=decode(:14, 65535, NULL, :14), cachehint=:15,
hwmincr=:16, spare1=DECODE(:17,0,NULL,:17) where ts#=:1 and file#=:2
and block#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=6,cu=1,mis=0,r=1,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='UPDATE SEG$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=14 op='TABLE ACCESS CLUSTER SEG$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
WAIT #1: nam='enqueue' ela= 0 p1=1398013958 p2=0 p3=0
WAIT #1: nam='enqueue' ela= 0 p1=1398013958 p2=0 p3=0
=====================
PARSING IN CURSOR #2 len=36 dep=1 uid=0 oct=3 lid=0 tim=0
hv=1705880752 ad='539b1a7c'
select file# from file$ where ts#=:1
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=17 op='TABLE ACCESS BY INDEX ROWID
FILE$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=39 op='INDEX RANGE SCAN '
=====================
PARSING IN CURSOR #2 len=84 dep=1 uid=0 oct=3 lid=0 tim=0 hv=904892542
ad='539d1b08'
select file#,block#,length from fet$ where length>=:1 and ts#=:
2 and file#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=1,dep=1,og=4,tim=0
WAIT #1: nam='row cache lock' ela= 0 p1=1 p2=0 p3=5
WAIT #1: nam='row cache lock' ela= 0 p1=1 p2=0 p3=5
=====================
PARSING IN CURSOR #3 len=63 dep=1 uid=0 oct=3 lid=0 tim=0
hv=2913840444 ad='539b02f8'
select length from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT
PARSE #3:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #3:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #3:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=0
STAT #3 id=1 cnt=1 pid=0 pos=0 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #3 id=2 cnt=1 pid=1 pos=1 obj=7 op='INDEX UNIQUE SCAN '
STAT #2 id=1 cnt=2 pid=0 pos=0 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=2 cnt=1 pid=1 pos=1 obj=7 op='INDEX UNIQUE SCAN '
WAIT #1: nam='row cache lock' ela= 0 p1=4 p2=0 p3=5
=====================
PARSING IN CURSOR #2 len=94 dep=1 uid=0 oct=3 lid=0 tim=0
hv=1839874543 ad='539acfd0'
select file#,block#,length from uet$ where ts#=:1 and segfile#=:2 and
segblock#=:3 and ext#=:4
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=0,dep=1,og=4,tim=0
STAT #2 id=1 cnt=0 pid=0 pos=0 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================
PARSING IN CURSOR #2 len=101 dep=1 uid=0 oct=2 lid=0 tim=0
hv=3687396716 ad='539a8474'
insert into uet$
(segfile#,segblock#,ext#,ts#,file#,block#,length)values (:1, :2, :3, :
4, :5, :6, :7)
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=2,cu=2,mis=0,r=1,dep=1,og=4,tim=0
=====================
PARSING IN CURSOR #2 len=56 dep=1 uid=0 oct=7 lid=0 tim=0
hv=1877781575 ad='5399ae98'
delete from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=4,cu=1,mis=0,r=1,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=7 op='INDEX UNIQUE SCAN '
=====================
PARSING IN CURSOR #2 len=283 dep=1 uid=0 oct=6 lid=0 tim=0
hv=2249281901 ad='5399cf64'
update seg$ set type#=:4,blocks=:5,extents=:6,minexts=:7,maxexts=:
8,extsize=:9,extpct=:10,user#=:11,iniexts=:12,lists=decode(:13, 65535,
NULL, :13),groups=decode(:14, 65535, NULL, :14), cachehint=:15,
hwmincr=:16, spare1=DECODE(:17,0,NULL,:17) where ts#=:1 and file#=:2
and block#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=6,cu=1,mis=0,r=1,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='UPDATE SEG$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=14 op='TABLE ACCESS CLUSTER SEG$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
WAIT #1: nam='direct path write' ela= 0 p1=4 p2=1984 p3=21
WAIT #1: nam='direct path write' ela= 0 p1=4 p2=2006 p3=1
WAIT #1: nam='direct path read' ela= 0 p1=4 p2=2006 p3=1
WAIT #1: nam='direct path read' ela= 0 p1=4 p2=653 p3=128
WAIT #1: nam='direct path read' ela= 0 p1=4 p2=3252 p3=1
WAIT #1: nam='direct path read' ela= 0 p1=4 p2=2862 p3=1
WAIT #1: nam='direct path read' ela= 0 p1=4 p2=1302 p3=1
WAIT #1: nam='direct path read' ela= 0 p1=4 p2=1952 p3=1
WAIT #1: nam='enqueue' ela= 0 p1=1414791172 p2=3 p3=16
WAIT #1: nam='enqueue' ela= 0 p1=1398013958 p2=0 p3=0
=====================
PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=3 lid=0 tim=0
hv=2913840444 ad='539b02f8'
select length from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=0
STAT #2 id=1 cnt=0 pid=0 pos=0 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=7 op='INDEX UNIQUE SCAN '
WAIT #1: nam='row cache lock' ela= 0 p1=1 p2=0 p3=5
WAIT #1: nam='row cache lock' ela= 0 p1=1 p2=0 p3=5
=====================
PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=3 lid=0 tim=0
hv=2913840444 ad='539b02f8'
select length from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=0
STAT #2 id=1 cnt=0 pid=0 pos=0 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=7 op='INDEX UNIQUE SCAN '
=====================
PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=3 lid=0 tim=0
hv=2913840444 ad='539b02f8'
select length from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=0
STAT #2 id=1 cnt=0 pid=0 pos=0 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=7 op='INDEX UNIQUE SCAN '
WAIT #1: nam='row cache lock' ela= 0 p1=1 p2=0 p3=5
WAIT #1: nam='row cache lock' ela= 0 p1=1 p2=0 p3=5
=====================
PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=3 lid=0 tim=0
hv=2913840444 ad='539b02f8'
select length from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=0
STAT #2 id=1 cnt=0 pid=0 pos=0 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=7 op='INDEX UNIQUE SCAN '
=====================
PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=3 lid=0 tim=0
hv=2913840444 ad='539b02f8'
select length from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=0
STAT #2 id=1 cnt=0 pid=0 pos=0 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=7 op='INDEX UNIQUE SCAN '
=====================
PARSING IN CURSOR #2 len=56 dep=1 uid=0 oct=7 lid=0 tim=0
hv=2363676478 ad='53992bf0'
delete from seg$ where ts#=:1 and file#=:2 and block#=:3
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=5,cu=3,mis=0,r=1,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE SEG$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=14 op='TABLE ACCESS CLUSTER SEG$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================
PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=2 lid=0 tim=0
hv=3230982141 ad='53991afc'
insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=1,cu=1,mis=0,r=1,dep=1,og=4,tim=0
=====================
PARSING IN CURSOR #2 len=74 dep=1 uid=0 oct=7 lid=0 tim=0 hv=528349613
ad='5398ef18'
delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 and
ext#=:4
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=5,cu=1,mis=0,r=1,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================
PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=2 lid=0 tim=0
hv=3230982141 ad='53991afc'
insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=1,cu=1,mis=0,r=1,dep=1,og=4,tim=0
=====================
PARSING IN CURSOR #2 len=74 dep=1 uid=0 oct=7 lid=0 tim=0 hv=528349613
ad='5398ef18'
delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 and
ext#=:4
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=5,cu=1,mis=0,r=1,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================
PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=2 lid=0 tim=0
hv=3230982141 ad='53991afc'
insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=1,cu=1,mis=0,r=1,dep=1,og=4,tim=0
=====================
PARSING IN CURSOR #2 len=74 dep=1 uid=0 oct=7 lid=0 tim=0 hv=528349613
ad='5398ef18'
delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 and
ext#=:4
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=5,cu=1,mis=0,r=1,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================
PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=2 lid=0 tim=0
hv=3230982141 ad='53991afc'
insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=1,cu=1,mis=0,r=1,dep=1,og=4,tim=0
=====================
PARSING IN CURSOR #2 len=74 dep=1 uid=0 oct=7 lid=0 tim=0 hv=528349613
ad='5398ef18'
delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 and
ext#=:4
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=5,cu=1,mis=0,r=1,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================
PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=2 lid=0 tim=0
hv=3230982141 ad='53991afc'
insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=1,cu=1,mis=0,r=1,dep=1,og=4,tim=0
=====================
PARSING IN CURSOR #2 len=74 dep=1 uid=0 oct=7 lid=0 tim=0 hv=528349613
ad='5398ef18'
delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 and
ext#=:4
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0
EXEC #2:c=0,e=0,p=0,cr=5,cu=1,mis=0,r=1,dep=1,og=4,tim=0
STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
FETCH #1:c=0,e=0,p=579,cr=686,cu=112,mis=0,r=0,dep=0,og=4,tim=0
WAIT #1: nam='log file sync' ela= 0 p1=185 p2=0 p3=0
WAIT #1: nam='log file sync' ela= 0 p1=185 p2=0 p3=0
WAIT #1: nam='SQL*Net message from client' ela= 0 p1=1650815232 p2=1
p3=0
STAT #1 id=1 cnt=0 pid=0 pos=0 obj=0 op='FILTER '
STAT #1 id=2 cnt=82650 pid=1 pos=1 obj=0 op='SORT GROUP BY '
STAT #1 id=3 cnt=82649 pid=2 pos=1 obj=0 op='HASH JOIN '
STAT #1 id=4 cnt=6346 pid=3 pos=1 obj=50660 op='TABLE ACCESS FULL
PPL_Z '
STAT #1 id=5 cnt=82649 pid=3 pos=2 obj=50664 op='TABLE ACCESS FULL
PV_BTE '
XCTEND rlbk=0, rd_only=1

Please let me know your view.

I am also trying to learn how to read this output, and find the
possible problem areas.

Thanks, Raj

Raj

unread,
Aug 9, 2007, 4:21:22 AM8/9/07
to ORACLE_DBA_EXPERTS

> read more »- Hide quoted text -
>
> - Show quoted text -...

It seems, I am doing mistake in taking event trace. I am saying this
because when I am converting *.trc file to *.trf with tkprof it is
showing following output, which is showing 0 seconds for the query
executed :

SELECT a.fpl_id, a.pzug_id, a.pzv_key, a.einbruchzeit, a.strecke_id,
a.bst_reihenfolge, count(*), b.zn
FROM


PV_BTE a, PPL_Z b WHERE ( a.pzug_id=b.pzug_id ) GROUP BY a.fpl_id,

a.pzug_id, a.pzv_key, a.einbruchzeit, a.strecke_id,
a.bst_reihenfolge,
b.zn HAVING count(*)>1

call count cpu elapsed disk query
current rows
------- ------ -------- ---------- ---------- ---------- ----------
----------
Parse 1 0.00 0.00 0 0
0 0
Execute 1 0.00 0.00 0 0
0 0

Fetch 1 0.00 0.00 575 548
61 0


------- ------ -------- ---------- ---------- ---------- ----------
----------

total 3 0.00 0.00 575 548
61 0

Misses in library cache during parse: 0


Optimizer goal: CHOOSE
Parsing user id: 102

Rows Row Source Operation
------- ---------------------------------------------------
0 FILTER
82650 SORT GROUP BY

82649 HASH JOIN
6346 TABLE ACCESS FULL PPL_Z
82649 TABLE ACCESS FULL PV_BTE

Please suggesst where I could be wrong.

Regardds, Raj

Raj

unread,
Aug 9, 2007, 5:38:43 AM8/9/07
to ORACLE_DBA_EXPERTS

> read more »- Hide quoted text -
>
> - Show quoted text -...

Finally, I got it right. Contents for 10046 trace events are pasted
below :

Dump file /usr/oracle/app/oracle/admin/ZTSS2/udump/ora_22210.trc


Oracle8i Enterprise Edition Release 8.1.7.3.0 - Production
With the Parallel Server option
JServer Release 8.1.7.3.0 - Production
ORACLE_HOME = /usr/oracle/app/oracle/product/8.1.7
System name: Linux
Node name: mcnode2
Release: 2.2.16
Version: #1 Tue Nov 27 14:47:58 CET 2001
Machine: i?86
Instance name: ZTSS2
Redo thread mounted by this instance: 2

Oracle process number: 11
Unix process pid: 22210, image: oracle@mcnode2 (TNS V1-V3)

*** 2007-08-09 11:29:15.367
*** SESSION ID:(10.13) 2007-08-09 11:29:15.366


APPNAME mod='SQL*Plus' mh=3669949024 act='' ah=4029777240
=====================
PARSING IN CURSOR #1 len=69 dep=0 uid=102 oct=42 lid=102

tim=2701058544 hv=89553408 ad='5355d2ac'


ALTER SESSION SET EVENTS '10046 trace name context forever, level 8'
END OF STMT

EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=2701058544


WAIT #1: nam='SQL*Net message to client' ela= 0 p1=1650815232 p2=1
p3=0

*** 2007-08-09 11:29:33.702
WAIT #1: nam='SQL*Net message from client' ela= 1834 p1=1650815232
p2=1 p3=0
=====================
PARSING IN CURSOR #1 len=319 dep=0 uid=102 oct=3 lid=102
tim=2701060378 hv=2934939745 ad='5395217c'
SELECT /*+ USE_HASH(PV_BTE,PPL_Z) */ a.fpl_id, a.pzug_id, a.pzv_key,


a.einbruchzeit, a.strecke_id, a.bst_reihenfolge, count(*), b.zn FROM

PV_BTE a, PPL_Z b WHERE ( a.pzug_id=b.pzug_id ) GROUP BY a.fpl_id,

a.pzug_id, a.pzv_key, a.einbruchzeit, a.strecke_id,
a.bst_reihenfolge, b.zn HAVING count(*)>1

END OF STMT
PARSE #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=2701060378
EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=2701060378


WAIT #1: nam='SQL*Net message to client' ela= 0 p1=1650815232 p2=1
p3=0

WAIT #1: nam='enqueue' ela= 0 p1=1414791172 p2=3 p3=16
WAIT #1: nam='enqueue' ela= 0 p1=1398013958 p2=0 p3=0
=====================

PARSING IN CURSOR #2 len=36 dep=1 uid=0 oct=3 lid=0 tim=2701060407
hv=1705880752 ad='539a6fa4'
select file# from file$ where ts#=:1
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=2701060407
FETCH #2:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=17 op='TABLE ACCESS BY INDEX ROWID
FILE$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=39 op='INDEX RANGE SCAN '
=====================

PARSING IN CURSOR #2 len=94 dep=1 uid=0 oct=3 lid=0 tim=2701060407
hv=1839874543 ad='539934c0'


select file#,block#,length from uet$ where ts#=:1 and segfile#=:2 and
segblock#=:3 and ext#=:4
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407
FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407


STAT #2 id=1 cnt=0 pid=0 pos=0 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=190 dep=1 uid=0 oct=3 lid=0 tim=2701060407
hv=4059714361 ad='53ad3098'


select
type#,blocks,extents,minexts,maxexts,extsize,extpct,user#,iniexts,NVL(lists,
65535),NVL(groups,65535),cachehint,hwmincr, NVL(spare1,0) from seg$
where ts#=:1 and file#=:2 and block#=:3
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407
FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407


STAT #2 id=1 cnt=0 pid=0 pos=0 obj=14 op='TABLE ACCESS CLUSTER SEG$ '

STAT #2 id=2 cnt=2 pid=1 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=254 dep=1 uid=0 oct=2 lid=0 tim=2701060407
hv=4003880563 ad='53991000'


insert into seg$
(file#,block#,type#,ts#,blocks,extents,minexts,maxexts,extsize,extpct,user#,iniexts,lists,groups,cachehint,bitmapranges,scanhint,
hwmincr, spare1) values (:
1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,:15,0,0,:16,DECODE(:
17,0,NULL,:17))
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407


WAIT #2: nam='enqueue' ela= 0 p1=1414332419 p2=14 p3=0
WAIT #2: nam='enqueue' ela= 0 p1=1414332419 p2=14 p3=0

EXEC #2:c=0,e=0,p=0,cr=2,cu=3,mis=0,r=1,dep=1,og=4,tim=2701060407
=====================
PARSING IN CURSOR #2 len=101 dep=1 uid=0 oct=2 lid=0 tim=2701060407
hv=3687396716 ad='5398db10'


insert into uet$
(segfile#,segblock#,ext#,ts#,file#,block#,length)values (:1, :2, :3, :
4, :5, :6, :7)
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407
EXEC #2:c=0,e=0,p=0,cr=2,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060407
=====================
PARSING IN CURSOR #2 len=56 dep=1 uid=0 oct=7 lid=0 tim=2701060407
hv=1877781575 ad='53982364'


delete from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407
WAIT #2: nam='enqueue' ela= 1 p1=1414332419 p2=12 p3=0
EXEC #2:c=0,e=1,p=0,cr=4,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060408


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=7 op='INDEX UNIQUE SCAN '

WAIT #1: nam='file open' ela= 0 p1=0 p2=0 p3=0


WAIT #1: nam='enqueue' ela= 0 p1=1398013958 p2=0 p3=0
=====================

PARSING IN CURSOR #2 len=36 dep=1 uid=0 oct=3 lid=0 tim=2701060416
hv=1705880752 ad='539a6fa4'
select file# from file$ where ts#=:1
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060416
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060416
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=2701060416
FETCH #2:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060416


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=17 op='TABLE ACCESS BY INDEX ROWID
FILE$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=39 op='INDEX RANGE SCAN '
WAIT #1: nam='row cache lock' ela= 0 p1=4 p2=0 p3=5
WAIT #1: nam='row cache lock' ela= 0 p1=4 p2=0 p3=5
=====================

PARSING IN CURSOR #2 len=94 dep=1 uid=0 oct=3 lid=0 tim=2701060416
hv=1839874543 ad='539934c0'


select file#,block#,length from uet$ where ts#=:1 and segfile#=:2 and
segblock#=:3 and ext#=:4
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060416
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060417
FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060417


STAT #2 id=1 cnt=0 pid=0 pos=0 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=101 dep=1 uid=0 oct=2 lid=0 tim=2701060417
hv=3687396716 ad='5398db10'


insert into uet$
(segfile#,segblock#,ext#,ts#,file#,block#,length)values (:1, :2, :3, :
4, :5, :6, :7)
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060417
EXEC #2:c=0,e=0,p=0,cr=2,cu=2,mis=0,r=1,dep=1,og=4,tim=2701060417
=====================
PARSING IN CURSOR #2 len=56 dep=1 uid=0 oct=7 lid=0 tim=2701060417
hv=1877781575 ad='53982364'


delete from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060417
EXEC #2:c=0,e=0,p=0,cr=4,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060417


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=7 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=283 dep=1 uid=0 oct=6 lid=0 tim=2701060417
hv=2249281901 ad='5397a958'


update seg$ set type#=:4,blocks=:5,extents=:6,minexts=:7,maxexts=:
8,extsize=:9,extpct=:10,user#=:11,iniexts=:12,lists=decode(:13, 65535,
NULL, :13),groups=decode(:14, 65535, NULL, :14), cachehint=:15,
hwmincr=:16, spare1=DECODE(:17,0,NULL,:17) where ts#=:1 and file#=:2
and block#=:3
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060417
EXEC #2:c=0,e=0,p=0,cr=6,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060417


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='UPDATE SEG$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=14 op='TABLE ACCESS CLUSTER SEG$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
WAIT #1: nam='enqueue' ela= 0 p1=1398013958 p2=0 p3=0
=====================

PARSING IN CURSOR #2 len=36 dep=1 uid=0 oct=3 lid=0 tim=2701060432
hv=1705880752 ad='539a6fa4'
select file# from file$ where ts#=:1
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060432
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060432
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=2701060432
FETCH #2:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060432


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=17 op='TABLE ACCESS BY INDEX ROWID
FILE$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=39 op='INDEX RANGE SCAN '
=====================

PARSING IN CURSOR #2 len=94 dep=1 uid=0 oct=3 lid=0 tim=2701060432
hv=1839874543 ad='539934c0'


select file#,block#,length from uet$ where ts#=:1 and segfile#=:2 and
segblock#=:3 and ext#=:4
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060432
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060432
FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060432


STAT #2 id=1 cnt=0 pid=0 pos=0 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=101 dep=1 uid=0 oct=2 lid=0 tim=2701060432
hv=3687396716 ad='5398db10'


insert into uet$
(segfile#,segblock#,ext#,ts#,file#,block#,length)values (:1, :2, :3, :
4, :5, :6, :7)
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060432
EXEC #2:c=0,e=0,p=0,cr=2,cu=2,mis=0,r=1,dep=1,og=4,tim=2701060432
=====================
PARSING IN CURSOR #2 len=56 dep=1 uid=0 oct=7 lid=0 tim=2701060432
hv=1877781575 ad='53982364'


delete from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060432
EXEC #2:c=0,e=0,p=0,cr=4,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060432


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=7 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=283 dep=1 uid=0 oct=6 lid=0 tim=2701060432
hv=2249281901 ad='5397a958'


update seg$ set type#=:4,blocks=:5,extents=:6,minexts=:7,maxexts=:
8,extsize=:9,extpct=:10,user#=:11,iniexts=:12,lists=decode(:13, 65535,
NULL, :13),groups=decode(:14, 65535, NULL, :14), cachehint=:15,
hwmincr=:16, spare1=DECODE(:17,0,NULL,:17) where ts#=:1 and file#=:2
and block#=:3
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060432
EXEC #2:c=0,e=0,p=0,cr=6,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060432


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='UPDATE SEG$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=14 op='TABLE ACCESS CLUSTER SEG$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
WAIT #1: nam='enqueue' ela= 0 p1=1398013958 p2=0 p3=0
WAIT #1: nam='enqueue' ela= 0 p1=1398013958 p2=0 p3=0
=====================

PARSING IN CURSOR #2 len=36 dep=1 uid=0 oct=3 lid=0 tim=2701060444
hv=1705880752 ad='539a6fa4'
select file# from file$ where ts#=:1
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060444
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060444
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=2701060444
FETCH #2:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060444


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=17 op='TABLE ACCESS BY INDEX ROWID
FILE$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=39 op='INDEX RANGE SCAN '
WAIT #1: nam='row cache lock' ela= 0 p1=4 p2=0 p3=5
WAIT #1: nam='row cache lock' ela= 0 p1=4 p2=0 p3=5
=====================

PARSING IN CURSOR #2 len=94 dep=1 uid=0 oct=3 lid=0 tim=2701060444
hv=1839874543 ad='539934c0'


select file#,block#,length from uet$ where ts#=:1 and segfile#=:2 and
segblock#=:3 and ext#=:4
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060444
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060444
FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060444


STAT #2 id=1 cnt=0 pid=0 pos=0 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=101 dep=1 uid=0 oct=2 lid=0 tim=2701060444
hv=3687396716 ad='5398db10'


insert into uet$
(segfile#,segblock#,ext#,ts#,file#,block#,length)values (:1, :2, :3, :
4, :5, :6, :7)
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060444
EXEC #2:c=0,e=0,p=0,cr=2,cu=2,mis=0,r=1,dep=1,og=4,tim=2701060444
=====================
PARSING IN CURSOR #2 len=56 dep=1 uid=0 oct=7 lid=0 tim=2701060444
hv=1877781575 ad='53982364'


delete from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060444
EXEC #2:c=0,e=0,p=0,cr=4,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060444


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=7 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=283 dep=1 uid=0 oct=6 lid=0 tim=2701060444
hv=2249281901 ad='5397a958'


update seg$ set type#=:4,blocks=:5,extents=:6,minexts=:7,maxexts=:
8,extsize=:9,extpct=:10,user#=:11,iniexts=:12,lists=decode(:13, 65535,
NULL, :13),groups=decode(:14, 65535, NULL, :14), cachehint=:15,
hwmincr=:16, spare1=DECODE(:17,0,NULL,:17) where ts#=:1 and file#=:2
and block#=:3
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060444
EXEC #2:c=0,e=1,p=0,cr=6,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060445


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='UPDATE SEG$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=14 op='TABLE ACCESS CLUSTER SEG$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
WAIT #1: nam='enqueue' ela= 0 p1=1398013958 p2=0 p3=0
=====================

PARSING IN CURSOR #2 len=36 dep=1 uid=0 oct=3 lid=0 tim=2701060461
hv=1705880752 ad='539a6fa4'
select file# from file$ where ts#=:1
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060461
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060461
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=2701060461
FETCH #2:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060461


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=17 op='TABLE ACCESS BY INDEX ROWID
FILE$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=39 op='INDEX RANGE SCAN '
=====================

PARSING IN CURSOR #2 len=94 dep=1 uid=0 oct=3 lid=0 tim=2701060461
hv=1839874543 ad='539934c0'


select file#,block#,length from uet$ where ts#=:1 and segfile#=:2 and
segblock#=:3 and ext#=:4
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060461
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060461
FETCH #2:c=0,e=1,p=0,cr=3,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060462


STAT #2 id=1 cnt=0 pid=0 pos=0 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=101 dep=1 uid=0 oct=2 lid=0 tim=2701060462
hv=3687396716 ad='5398db10'


insert into uet$
(segfile#,segblock#,ext#,ts#,file#,block#,length)values (:1, :2, :3, :
4, :5, :6, :7)
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060462
EXEC #2:c=0,e=0,p=0,cr=2,cu=2,mis=0,r=1,dep=1,og=4,tim=2701060462
=====================
PARSING IN CURSOR #2 len=56 dep=1 uid=0 oct=7 lid=0 tim=2701060462
hv=1877781575 ad='53982364'


delete from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060462
EXEC #2:c=0,e=0,p=0,cr=4,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060462


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=7 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=283 dep=1 uid=0 oct=6 lid=0 tim=2701060462
hv=2249281901 ad='5397a958'


update seg$ set type#=:4,blocks=:5,extents=:6,minexts=:7,maxexts=:
8,extsize=:9,extpct=:10,user#=:11,iniexts=:12,lists=decode(:13, 65535,
NULL, :13),groups=decode(:14, 65535, NULL, :14), cachehint=:15,
hwmincr=:16, spare1=DECODE(:17,0,NULL,:17) where ts#=:1 and file#=:2
and block#=:3
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060462
EXEC #2:c=0,e=0,p=0,cr=6,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060462


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='UPDATE SEG$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=14 op='TABLE ACCESS CLUSTER SEG$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '

WAIT #1: nam='direct path write' ela= 0 p1=4 p2=1334 p3=21
WAIT #1: nam='direct path write' ela= 0 p1=4 p2=1356 p3=1
WAIT #1: nam='direct path read' ela= 0 p1=4 p2=1356 p3=1
WAIT #1: nam='direct path read' ela= 0 p1=4 p2=1953 p3=128
WAIT #1: nam='direct path read' ela= 0 p1=4 p2=652 p3=1


WAIT #1: nam='direct path read' ela= 0 p1=4 p2=3252 p3=1
WAIT #1: nam='direct path read' ela= 0 p1=4 p2=2862 p3=1
WAIT #1: nam='direct path read' ela= 0 p1=4 p2=1302 p3=1

WAIT #1: nam='enqueue' ela= 0 p1=1398013958 p2=0 p3=0
WAIT #1: nam='enqueue' ela= 0 p1=1398013958 p2=0 p3=0
=====================

PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=3 lid=0 tim=2701060497
hv=2913840444 ad='539a6480'


select length from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497


STAT #2 id=1 cnt=0 pid=0 pos=0 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=7 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=3 lid=0 tim=2701060497
hv=2913840444 ad='539a6480'


select length from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497


STAT #2 id=1 cnt=0 pid=0 pos=0 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=7 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=3 lid=0 tim=2701060497
hv=2913840444 ad='539a6480'


select length from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497


STAT #2 id=1 cnt=0 pid=0 pos=0 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=7 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=3 lid=0 tim=2701060497
hv=2913840444 ad='539a6480'


select length from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497


STAT #2 id=1 cnt=0 pid=0 pos=0 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=7 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=3 lid=0 tim=2701060497
hv=2913840444 ad='539a6480'


select length from fet$ where file#=:1 and block#=:2 and ts#=:3
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497


STAT #2 id=1 cnt=0 pid=0 pos=0 obj=12 op='TABLE ACCESS CLUSTER FET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=7 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=56 dep=1 uid=0 oct=7 lid=0 tim=2701060497
hv=2363676478 ad='5397e05c'


delete from seg$ where ts#=:1 and file#=:2 and block#=:3
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
EXEC #2:c=0,e=0,p=0,cr=5,cu=3,mis=0,r=1,dep=1,og=4,tim=2701060497


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE SEG$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=14 op='TABLE ACCESS CLUSTER SEG$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=2 lid=0 tim=2701060497
hv=3230982141 ad='53977798'


insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
EXEC #2:c=0,e=0,p=0,cr=1,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060497
=====================
PARSING IN CURSOR #2 len=74 dep=1 uid=0 oct=7 lid=0 tim=2701060497
hv=528349613 ad='53973db4'


delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 and
ext#=:4
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
EXEC #2:c=0,e=0,p=0,cr=5,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060497


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=2 lid=0 tim=2701060497
hv=3230982141 ad='53977798'


insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
EXEC #2:c=0,e=0,p=0,cr=1,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060497
=====================
PARSING IN CURSOR #2 len=74 dep=1 uid=0 oct=7 lid=0 tim=2701060497
hv=528349613 ad='53973db4'


delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 and
ext#=:4
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
EXEC #2:c=0,e=0,p=0,cr=5,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060497


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=2 lid=0 tim=2701060497
hv=3230982141 ad='53977798'


insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
EXEC #2:c=1,e=0,p=0,cr=1,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060497
=====================
PARSING IN CURSOR #2 len=74 dep=1 uid=0 oct=7 lid=0 tim=2701060497
hv=528349613 ad='53973db4'


delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 and
ext#=:4
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
EXEC #2:c=0,e=0,p=0,cr=5,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060497


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=2 lid=0 tim=2701060497
hv=3230982141 ad='53977798'


insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
EXEC #2:c=0,e=0,p=0,cr=1,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060497
=====================
PARSING IN CURSOR #2 len=74 dep=1 uid=0 oct=7 lid=0 tim=2701060497
hv=528349613 ad='53973db4'


delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 and
ext#=:4
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060497
EXEC #2:c=0,e=0,p=0,cr=5,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060497


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
=====================

PARSING IN CURSOR #2 len=63 dep=1 uid=0 oct=2 lid=0 tim=2701060498
hv=3230982141 ad='53977798'


insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)
END OF STMT

PARSE #2:c=0,e=1,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060498
EXEC #2:c=0,e=0,p=0,cr=1,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060498
=====================
PARSING IN CURSOR #2 len=74 dep=1 uid=0 oct=7 lid=0 tim=2701060498
hv=528349613 ad='53973db4'


delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 and
ext#=:4
END OF STMT

PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060498
EXEC #2:c=0,e=0,p=0,cr=5,cu=1,mis=0,r=1,dep=1,og=4,tim=2701060498


STAT #2 id=1 cnt=1 pid=0 pos=0 obj=0 op='DELETE UET$ '
STAT #2 id=2 cnt=2 pid=1 pos=1 obj=13 op='TABLE ACCESS CLUSTER UET$ '
STAT #2 id=3 cnt=2 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN '
FETCH

#1:c=46,e=120,p=573,cr=682,cu=95,mis=0,r=0,dep=0,og=4,tim=2701060498
WAIT #1: nam='log file sync' ela= 0 p1=198 p2=0 p3=0
WAIT #1: nam='log file sync' ela= 0 p1=198 p2=0 p3=0
WAIT #1: nam='SQL*Net message from client' ela= 324 p1=1650815232 p2=1


p3=0
STAT #1 id=1 cnt=0 pid=0 pos=0 obj=0 op='FILTER '
STAT #1 id=2 cnt=82650 pid=1 pos=1 obj=0 op='SORT GROUP BY '
STAT #1 id=3 cnt=82649 pid=2 pos=1 obj=0 op='HASH JOIN '
STAT #1 id=4 cnt=6346 pid=3 pos=1 obj=50660 op='TABLE ACCESS FULL
PPL_Z '
STAT #1 id=5 cnt=82649 pid=3 pos=2 obj=50664 op='TABLE ACCESS FULL
PV_BTE '
XCTEND rlbk=0, rd_only=1


I see this statement in the end as the problem area :

WAIT #1: nam='SQL*Net message from client' ela= 324 p1=1650815232 p2=1
p3=0

What you say Charles and David ??

Regards, Raj

Raj

unread,
Aug 9, 2007, 4:58:43 AM8/9/07
to ORACLE_DBA_EXPERTS

> read more »- Hide quoted text -
>
> - Show quoted text -...

Also, I see following plan after I deleted the stats. One table is
using index and one doing full table scan.

SQL> SELECT a.fpl_id, a.pzug_id, a.pzv_key, a.einbruchzeit,
a.strecke_id, a.bst_reihenfolge, count(*), b.zn FROM PV_BTE a, PPL_Z b


WHERE ( a.pzug_id=b.pzug_id ) GROUP BY a.fpl_id, a.pzug_id, a.pzv_key,

a.einbruchzeit, a.strecke_id, a.bst_reihenfolge, b.zn HAVING

count(*)>1 ;

----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE

1 0 FILTER
2 1 SORT (GROUP BY)

3 2 NESTED LOOPS


4 3 TABLE ACCESS (FULL) OF 'PPL_Z'

5 3 TABLE ACCESS (BY INDEX ROWID) OF 'PV_BTE'
6 5 INDEX (RANGE SCAN) OF 'PZVK_PZV_FK_I' (NON-UNIQUE)


Statistiken
----------------------------------------------------------
470 recursive calls
102 db block gets
14574 consistent gets
577 physical reads
12540 redo size


590 bytes sent via SQL*Net to client
319 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
1 sorts (disk)
0 rows processed

regards, raj

fitzj...@cox.net

unread,
Aug 9, 2007, 8:15:55 AM8/9/07
to ORACLE_DBA_EXPERTS

> type#,blocks,extents,minexts,maxexts,extsize,extpct,user#,iniexts,NVL(lists­,


> 65535),NVL(groups,65535),cachehint,hwmincr, NVL(spare1,0) from seg$
> where ts#=:1 and file#=:2 and block#=:3
> END OF STMT
> PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407
> EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407
> FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407
> STAT #2 id=1 cnt=0 pid=0 pos=0 obj=14 op='TABLE ACCESS CLUSTER SEG$ '
> STAT #2 id=2 cnt=2 pid=1 pos=1 obj=9 op='INDEX UNIQUE SCAN '
> =====================
> PARSING IN CURSOR #2 len=254 dep=1 uid=0 oct=2 lid=0 tim=2701060407
> hv=4003880563 ad='53991000'
> insert into seg$

> (file#,block#,type#,ts#,blocks,extents,minexts,maxexts,extsize,extpct,user#­,iniexts,lists,groups,cachehint,bitmapranges,scanhint,

SQL*Net message from client waits are usually due to the end-user not
hitting the 'Return' or 'Enter' key. They are, therefore, usually
nothing to cause worry. SQL*Net message to client waits are more
likely problems to address. You see none of these.


David Fitzjarrell

Raj

unread,
Aug 9, 2007, 10:10:27 AM8/9/07
to ORACLE_DBA_EXPERTS

> > > increasing the size of the sort_area_size.

> > > * The query reads roughly half of the blocks from disk, and the other- Hide quoted text -


>
> - Show quoted text -...
>

> read more »

David, You are true.

But this line is saying the same story.

FETCH
#1:c=46,e=120,p=573,cr=682,cu=95,mis=0,r=0,dep=0,og=4,tim=2701060498

Also, when I try to check which datafile is involved in disk reads I
see the following result :

SQL> SELECT A.file_name, B.phyrds, B.phyblkrd FROM SYS.dba_data_files
A,v$filestat B WHERE B.file# = A.file_id ORDER BY A.file_id;

FILE_NAME PHYRDS PHYBLKRD
--------------------------------------------- ---------- ----------
/tablespaces/system 839 1088
/tablespaces/rbs_1_file_01 5 5
/tablespaces/rbs_2_file_01 9 9
/tablespaces/temp_1_file_01 1826 74899
/tablespaces/temp_2_file_01 1 1
/tablespaces/zdbpTableSpace 14 14
/tablespaces/zzloTableSpace 3854 3929
/tablespaces/reserveTableD 3 3
/tablespaces/reserveTableA 1 1

PHYRDS shows the number of reads from the data file since the instance
was started. PHYBLKRD shows the actual number of data blocks read.

It seems temp_1_file_01 datafile seems to be a bottleneck (for full
table scan). What you people say ??

Regards, Raj

fitzj...@cox.net

unread,
Aug 9, 2007, 10:42:33 AM8/9/07
to ORACLE_DBA_EXPERTS

It isn't, unless you have permanent objects in that tablespace. Your
TEMP tablespace should be reserved for temporary objects. I would be
checking your zzloTableSpace; it appears to have the most activity for
a permanent, production tablespace.


David Fitzjarrell

Charles Hooper

unread,
Aug 9, 2007, 11:12:49 AM8/9/07
to ORACLE_DBA_EXPERTS
<snip>
> type#,blocks,extents,minexts,maxexts,extsize,extpct,user#,iniexts,NVL(lists­,

> 65535),NVL(groups,65535),cachehint,hwmincr, NVL(spare1,0) from seg$
> where ts#=:1 and file#=:2 and block#=:3
> END OF STMT
> PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407
> EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407
> FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=0,dep=1,og=4,tim=2701060407
> STAT #2 id=1 cnt=0 pid=0 pos=0 obj=14 op='TABLE ACCESS CLUSTER SEG$ '
> STAT #2 id=2 cnt=2 pid=1 pos=1 obj=9 op='INDEX UNIQUE SCAN '
> =====================
> PARSING IN CURSOR #2 len=254 dep=1 uid=0 oct=2 lid=0 tim=2701060407
> hv=4003880563 ad='53991000'
> insert into seg$
> (file#,block#,type#,ts#,blocks,extents,minexts,maxexts,extsize,extpct,user#­,iniexts,lists,groups,cachehint,bitmapranges,scanhint,

Your other trace file showed this:


WAIT #10: nam='db file sequential read' ela= 2 p1=4 p2=151050 p3=1

The above trace file contained this line:


WAIT #1: nam='direct path write' ela= 0 p1=4 p2=1334 p3=21

db file sequential read: p1=file number, p2=first block#, p3=block cnt
I/O, SQL statement tuning: Poorly tuned SQL, Slow I/O system. A
sequential read is a single-block read, where a user process is
reading a buffer into the SGA buffer cache and waiting for a physical
I/O. Single block I/Os are usually the result of index scans.
Rarely, full table scans could get truncated to a single block call
due to extent boundaries, or buffers already present in the buffer
cache.

direct path write: p1=file number, p2=first block#, p3=block cnt
When a process is writing buffers directly from PGA, instead of DBWR
writing them from the buffer cache, the process waits on the direct
path write wait event for the write call to complete. A sort
operation being written to disk, parallel DML operations, direct path
INSERT, parallel create table as SELECT, some LOB operations.

Looking at the p1= values of the two waits, it looks like the same
tablespace that contains your index also contains the temp segments
used by the sort to disk. You should have a dedicated *temporary*
tablespace set up, and in Oracle 8.1.7.3 you need to specify this for
each user account.

On a related note, there seem to be a lot of enqueue waits, as well as
some row cache locks.


WAIT #1: nam='enqueue' ela= 0 p1=1414791172 p2=3 p3=16
WAIT #1: nam='enqueue' ela= 0 p1=1398013958 p2=0 p3=0

WAIT #2: nam='enqueue' ela= 0 p1=1414332419 p2=14 p3=0

WAIT #2: nam='enqueue' ela= 1 p1=1414332419 p2=12 p3=0

WAIT #1: nam='row cache lock' ela= 0 p1=4 p2=0 p3=5

enqueue: p1=name|mode, p2=id1, p3=id2
Enqueues are locks that coordinate access to database resources. This
event indicates that the session is waiting for a lock held by another
session. The name of the enqueue is included as part of the wait
event name. The V$EVENT_NAME view provides a complete list of all
enq: wait events. Look at V$ENQUEUE_STAT. Enqueue parameters in V
$SESSION_WAIT: P1 Lock Type (or name) and mode, P2 resource identifier
ID1 for the lock, P3 Resource ID2 for the lock. For every session
waiting for an event enqueue, there is a row in V$LOCK with
REQUEST<>0. To show cases where an enqueue is being waited on: SELECT
DECODE(REQUEST, 0, 'HOLDER: ', 'WAITER: '), SID SESS, ID1, ID2M LMODE,
REQUEST, TYPE FROM V$LOCK WHERE (ID1, ID2, TYPE_ IN (SELECT ID1, ID2,
TYPE FROM V$LOCK WHERE REQUEST > 0) ORDER BY ID1, REQUEST;

row cache lock: p1=cache id, p2=mode, p3=request
The session is trying to get a data dictionary lock.

From: http://www.jlcomp.demon.co.uk/faq/long_truncate.html
"and these operations are SERIAL, namely, only one session can be
performing this at a time. So if you have anything on your database
that could be "attacking" FET$ and UET$ (for example, sorting in a
permanent tablespace, dropping/adding objects frequently), then you
will get these kinds of problems occurring."

Profile:
--------------------------------------------------------
Cursor 2 Ver 37 Similar Cnt 3
|PARSEs 1|CPU S 0.000000|CLOCK S 0.000000|ROWs 0|
PHY RD BLKs 0|CON RD BLKs (Mem) 0|CUR RD BLKs
(Mem) 0|SHARED POOL MISs 0|
|EXECs 1|CPU S 0.010000|CLOCK S 0.000000|ROWs 1|
PHY RD BLKs 0|CON RD BLKs (Mem) 1|CUR RD BLKs
(Mem) 1|SHARED POOL MISs 0|
|FETCHs 0|CPU S 0.000000|CLOCK S 0.000000|ROWs 0|
PHY RD BLKs 0|CON RD BLKs (Mem) 0|CUR RD BLKs
(Mem) 0|SHARED POOL MISs 0|

Statement Depth 1 (Trigger Code)


hv=3230982141 ad='53977798'
insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)

Parse CPU Time 0.000000,Elapsed Time 0.000000,Rows Affected 0,Blks
from Buff 0,Blks from Disk 0,Goal=CHOOSE
Execute CPU Time 0.010000,Elapsed Time 0.000000,Rows Affected 1,Blks
from Buff 1+CU(1),Blks from Disk 0
--------------------------------------------------------

The lack of timing for most of the wait events will make it difficult
to find the complete source of the problem, but it looks like one of
the problems is the sort that is taking place in a permanent
tablespace. David is correct that in this case the 'SQL*Net message
from client' waits can be ignored. They can be important when
tracking the performance of an application that submits multiple SQL
statements, where it is difficult to determine if the client is at
fault for poor performance.

Raj

unread,
Aug 9, 2007, 11:15:20 AM8/9/07
to ORACLE_DBA_EXPERTS

> David Fitzjarrell- Hide quoted text -


>
> - Show quoted text -

Increased the tablespace size of zzloTableSpace from 300MB to 500MB
and restarted the database.

Please see the tablespace sizes below :

Tablesapce Size_Mb Used_Mb Free_Mb Used_%
------------------------------ --------- --------- --------- ---------
ZZLO_TS1 500.0 140.1 359.9 28.0
TS_RBS_1 512.0 128.8 383.2 25.1
TS_RBS_2 512.0 128.8 383.2 25.1
SYSTEM 256.0 54.4 201.6 21.2
ZDBP 1000.0 65.7 934.3 6.6
TS_TEMP_1 256.0 .0 256.0 .0
TS_TEMP_2 256.0 .0 256.0 .0


Stats just after Restart is pasted below :

SQL> SELECT A.file_name, B.phyrds, B.phyblkrd FROM SYS.dba_data_files
A,v$filestat B WHERE B.file# = A.file_id ORDER BY A.file_id;

FILE_NAME PHYRDS PHYBLKRD
-------------------------------------------------- --------- ---------
/tablespaces/system 267.0 558.0
/tablespaces/rbs_1_file_01 1.0 1.0
/tablespaces/rbs_2_file_01 8.0 8.0
/tablespaces/temp_1_file_01 1.0 1.0
/tablespaces/temp_2_file_01 1.0 1.0
/tablespaces/zdbpTableSpace 1.0 1.0
/tablespaces/zzloTableSpace 1.0 1.0
/tablespaces/reserveTableD 2.0 2.0
/tablespaces/reserveTableA 1.0 1.0


Stats after executing the below mentioned query is pasted below :

SQL> SELECT a.fpl_id, a.pzug_id, a.pzv_key, a.einbruchzeit,


a.strecke_id, a.bst_reihenfolge, count(*), b.zn FROM PV_BTE a, PPL_Z b
WHERE ( a.pzug_id=b.pzug_id ) GROUP BY a.fpl_id, a.pzug_id, a.pzv_key,
a.einbruchzeit, a.strecke_id, a.bst_reihenfolge, b.zn HAVING

count(*)>1 ;


SQL> SELECT A.file_name, B.phyrds, B.phyblkrd FROM SYS.dba_data_files
A,v$filestat B WHERE B.file# = A.file_id ORDER BY A.file_id;

FILE_NAME PHYRDS PHYBLKRD
-------------------------------------------------- --------- ---------
/tablespaces/system 353.0 644.0
/tablespaces/rbs_1_file_01 1.0 1.0
/tablespaces/rbs_2_file_01 8.0 8.0
/tablespaces/temp_1_file_01 14.0 573.0
/tablespaces/temp_2_file_01 1.0 1.0
/tablespaces/zdbpTableSpace 1.0 1.0
/tablespaces/zzloTableSpace 848.0 878.0
/tablespaces/reserveTableD 2.0 2.0
/tablespaces/reserveTableA 1.0 1.0

Even temp Tablespace is also playing some role in this query (may be
for sorting ). I don't see any change in performance. Can you please
suggest what I should check in zzloTableSpace ?

Regards, Raj

Charles Hooper

unread,
Aug 9, 2007, 1:13:35 PM8/9/07
to ORACLE_DBA_EXPERTS

The temp tablespace should not be showing in the above query - that
indicates that the temp tablespace was created as a *permanent*
tablespace. What is returned by the following:
SELECT
FILE_ID,
TABLESPACE_NAME,
BYTES
FROM
DBA_TEMP_FILES;

fitzj...@cox.net

unread,
Aug 9, 2007, 1:32:44 PM8/9/07
to ORACLE_DBA_EXPERTS

> Regards, Raj- Hide quoted text -


>
> - Show quoted text -

I had to look at one of the 8.1.7 databases I manage and, surely
enough, the TEMP tablespace is using tempfiles, not datafiles, and
this is possibly a big part of your problem. The temp tablespace
should be using tempfiles. I would create a proper temporary
tablespace:

create temporary tablespace newtemp
tempfile '<file spec here>' size <size here>;

and then reassign all of the users to the new temp tablespace. Drop
the old TEMP tablespace when all users have the new temp tablespace
assignment. Using datafiles for a temp tablespace in 8i and later
releases is administrative suicide, as it creates performance problems
as you can attest.


David Fitzjarrell

Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted

Raj

unread,
Aug 9, 2007, 2:53:41 PM8/9/07
to ORACLE_DBA_EXPERTS

Hello David and Charles

Currently, I am at home. Will send the required update tomorrow
morning, just after reaching office.

It seems solution is near by..:-)

As a matter of fact, I have received this database from other some
other group to improve the performance.

Thanks to both of you for help.

Regards, Raj

Raj

unread,
Aug 9, 2007, 3:00:15 PM8/9/07
to ORACLE_DBA_EXPERTS

Hello David and Charles,

Currently, I am at home and will update you people tomorrow just after
reaching to office.

It seems solution is near by..:-)

As a matter of fact, I have received this database from some other

Raj

unread,
Aug 10, 2007, 4:06:31 AM8/10/07
to ORACLE_DBA_EXPERTS

> K&M Machine-Fabricating, Inc.- Hide quoted text -


>
> - Show quoted text -

Hello Charles and David,

The below mentioned command which Charles asked me to execute is not
giving any output. Infact nothing is there in DBA_TEMP_FILES :

SQL> SELECT FILE_ID, TABLESPACE_NAME, BYTES FROM DBA_TEMP_FILES;
SQL> select * from DBA_TEMP_FILES;

But when I try to see the default and temporary tablespaces, I see
TS_TEMP_1 is assigned to user SAHN, which seems to be proper. I am
using SAHN only to execute this query.

SQL> select USERNAME,DEFAULT_TABLESPACE,TEMPORARY_TABLESPACE from
dba_users where username='SAHN';


USERNAME DEFAULT_TABLESPACE
TEMPORARY_TABLESPACE
------------------------------ ------------------------------
------------------------------
SAHN ZZLO_TS1 TS_TEMP_1

Any comments on this ??

Thanks, Raj

fitzj...@cox.net

unread,
Aug 10, 2007, 8:27:40 AM8/10/07
to ORACLE_DBA_EXPERTS

> Thanks, Raj- Hide quoted text -
>
> - Show quoted text -\

I will post this again in hopes you'll actually read it this time:

Raj

unread,
Aug 10, 2007, 9:29:03 AM8/10/07
to ORACLE_DBA_EXPERTS

Hello David,

I could not create the tablespace the way you said becuase of
compatible parameter. It is asking me to set the compatible parameter
8.1.0.0.0 in place of 8.0.5.0.0. To set this, I need to bring down
both the instances. So, I created the Dictionary managed tablespaces
(on this machine all tablespaces are dictionary managed only) as
mentioned below :


SQL> CREATE TABLESPACE TS_TEMP_2 DATAFILE '/tablespaces/
temp_2_file_01' size 256M DEFAULT STORAGE (INITIAL 2M NEXT 2M
MINEXTENTS 1 PCTINCREASE 0) TEMPORARY;

SQL> alter user SAHN TEMPORARY TABLESPACE TS_TEMP_2;

I assigned SAHN to this tablespace because I am running this query
from this user only.

Even Now, problem remains the same (now it's taking 1.18 Sec in place
of 1.39 Secs) .

Trace output is pasted below :


SELECT /*+ USE_HASH */ a.fpl_id, a.pzug_id, a.pzv_key, a.einbruchzeit,


a.strecke_id, a.bst_reihenfolge, count(*), b.zn
FROM
PV_BTE a, PPL_Z b WHERE ( a.pzug_id=b.pzug_id ) GROUP BY a.fpl_id,
a.pzug_id, a.pzv_key, a.einbruchzeit, a.strecke_id,
a.bst_reihenfolge,
b.zn HAVING count(*)>1

call count cpu elapsed disk query
current rows
------- ------ -------- ---------- ---------- ---------- ----------
----------
Parse 1 0.00 0.00 0 0
0 0
Execute 1 0.00 0.00 0 0
0 0

Fetch 1 0.53 1.18 572 14436
6 0


------- ------ -------- ---------- ---------- ---------- ----------
----------

total 3 0.53 1.18 572 14436
6 0

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 102

Rows Row Source Operation
------- ---------------------------------------------------
0 FILTER
82650 SORT GROUP BY
82649 NESTED LOOPS
6347 TABLE ACCESS FULL PPL_Z
82649 TABLE ACCESS BY INDEX ROWID PV_BTE
88995 INDEX RANGE SCAN (object id 50700)

SQL> SELECT a.fpl_id, a.pzug_id, a.pzv_key, a.einbruchzeit,


a.strecke_id, a.bst_reihenfolge, count(*), b.zn FROM PV_BTE a, PPL_Z b
WHERE ( a.pzug_id=b.pzug_id ) GROUP BY a.fpl_id, a.pzug_id, a.pzv_key,
a.einbruchzeit, a.strecke_id, a.bst_reihenfolge, b.zn HAVING
count(*)>1 ;

Es wurden keine Zeilen ausgewählt


Ausführungsplan


----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE

1 0 FILTER
2 1 SORT (GROUP BY)

3 2 NESTED LOOPS


4 3 TABLE ACCESS (FULL) OF 'PPL_Z'

5 3 TABLE ACCESS (BY INDEX ROWID) OF 'PV_BTE'
6 5 INDEX (RANGE SCAN) OF 'PZVK_PZV_FK_I' (NON-UNIQUE)


Statistiken
----------------------------------------------------------
8 recursive calls
6 db block gets
14439 consistent gets
572 physical reads


0 redo size
590 bytes sent via SQL*Net to client
319 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
1 sorts (disk)
0 rows processed

What should I do to minimize the disk reads. Shoudl I increase the
db_block_buffers beyond 9000 ?

Thanks, raj

fitzj...@cox.net

unread,
Aug 10, 2007, 9:51:29 AM8/10/07
to ORACLE_DBA_EXPERTS

> read more »- Hide quoted text -


>
> - Show quoted text -...

Part of your issue is the dictionary-managed temporary tablespace;
creating yet another dictionary-managed temporary tablespace won't
likely solve anything. Why is compatible set to 8.0.5.0.0 when this
actual release is 8.1.7? This is likely another part of the problem
you're experiencing as you've disabled much of the 8i functionality,
relying instead upon compatibility with a poorly executed release of
Oracle.

I'd be asking WHY you're at this compatible setting instead of using
the functionality Oracle intended for this release. And if you can't
get a really good reason I'd be pushing for a change to bring yourself
and your users to a functional level more in line with the release
you're using. Then I'd create a new TEMPORARY tablespace using
tempfiles as I instructed in prior posts, and drop the dictionary-
managed TEMP tablespaces you currently are using.

At that point other issues regarding performance can be addressed,
presuming they still exist.


David Fitzjarrell

Raj

unread,
Aug 10, 2007, 9:45:08 AM8/10/07
to ORACLE_DBA_EXPERTS

> read more »- Hide quoted text -


>
> - Show quoted text -...

I can see following change in trace :

Earliaer I was getting

449 recursive calls
98 db block gets
697 consistent gets
574 physical reads
10160 redo size

and now I am getting :

8 recursive calls
6 db block gets
14439 consistent gets

579 physical reads
0 redo size

Till now, I am at fail to understand how to reduce the "consistent
get" and "physical reads". Please let me know, if oyu have any idea.

Regards, Raj

fitzj...@cox.net

unread,
Aug 10, 2007, 9:54:53 AM8/10/07
to ORACLE_DBA_EXPERTS

The solution, or at least part of it, is in my prior post where you
need to ask WHY you're not using 8.1 functionality in an 8.1.7
database. This needs to be corrected, in my opinion, so you can have
a PROPER temporary tablespace with tempfiles, not datafiles.


David Fitzjarrell

Raj

unread,
Aug 10, 2007, 10:49:18 AM8/10/07
to ORACLE_DBA_EXPERTS

> > > Trace output is pasted- Hide quoted text -


>
> - Show quoted text -...
>
> read more »


As per your direction, after changing the compatible parameter I
created the tablespace after droping it:

SQL> CREATE TEMPORARY TABLESPACE TS_TEMP_2 TEMPFILE '/tablespaces/
temp_2_file_01' SIZE 256M;

SQL> alter user sahn TEMPORARY TABLESPACE TS_TEMP_2;

SQL> sho parameter comp

NAME TYPE VALUE
------------------------------------ -------
------------------------------

compatible string 8.1.0.0.0

Trace Details are pasted below :

SQL> SELECT /*+ USE_HASH */ a.fpl_id, a.pzug_id, a.pzv_key,


a.einbruchzeit, a.strecke_id, a.bst_reihenfolge, count(*), b.zn FROM
PV_BTE a, PPL_Z b WHERE ( a.pzug_id=b.pzug_id ) GROUP BY a.fpl_id,
a.pzug_id, a.pzv_key, a.einbruchzeit, a.strecke_id,

a.bst_reihenfolge, b.zn HAVING count(*)>1 ;


Ausführungsplan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 FILTER
2 1 SORT (GROUP BY)
3 2 NESTED LOOPS
4 3 TABLE ACCESS (FULL) OF 'PPL_Z'
5 3 TABLE ACCESS (BY INDEX ROWID) OF 'PV_BTE'
6 5 INDEX (RANGE SCAN) OF 'PZVK_PZV_FK_I' (NON-UNIQUE)


Statistiken
----------------------------------------------------------
0 recursive calls
6 db block gets
14436 consistent gets
572 physical reads
0 redo size


590 bytes sent via SQL*Net to client
319 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
1 sorts (disk)
0 rows processed

Tkprof output :

SELECT /*+ USE_HASH */ a.fpl_id, a.pzug_id, a.pzv_key, a.einbruchzeit,
a.strecke_id, a.bst_reihenfolge, count(*), b.zn
FROM
PV_BTE a, PPL_Z b WHERE ( a.pzug_id=b.pzug_id ) GROUP BY a.fpl_id,
a.pzug_id, a.pzv_key, a.einbruchzeit, a.strecke_id,
a.bst_reihenfolge,
b.zn HAVING count(*)>1


call count cpu elapsed disk query
current rows
------- ------ -------- ---------- ---------- ---------- ----------
----------
Parse 1 0.00 0.00 0 0
0 0
Execute 1 0.00 0.00 0 0
0 0

Fetch 1 0.54 1.15 572 14436
6 0


------- ------ -------- ---------- ---------- ---------- ----------
----------

total 3 0.54 1.15 572 14436
6 0

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 102

Rows Row Source Operation
------- ---------------------------------------------------
0 FILTER
82650 SORT GROUP BY
82649 NESTED LOOPS
6347 TABLE ACCESS FULL PPL_Z
82649 TABLE ACCESS BY INDEX ROWID PV_BTE
88995 INDEX RANGE SCAN (object id 50700)


Please let me know your view, how to reduce the consistent gets and
physical reads ..??

Thanks much for your conitnuous help.

Regards, Raj

fitzj...@cox.net

unread,
Aug 10, 2007, 11:01:28 AM8/10/07
to ORACLE_DBA_EXPERTS

You've just 'bounced' your database so all data blocks you had cached
are gone; the cache needs to rebuild and this requires physical
reads. As your cache 'settles in' you'll hopefully find that the
physical reads figure decreases as more of the data blocks required by
queries are found in the cache. That being said consistent gets is a
figure you don't necessarily want to have decrease, as those are reads
from the cache, not the disk, and for the most part these are good.
The db block gets and consistent gets values indicate data accessed
from the buffer cache; physical reads come from disk.

A quick read of the Concepts Guide for 8.1.7 is in order; you can find
it here:

http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a76965/c01intro.htm#12981

You might also want to read this:

http://oratips-ddf.blogspot.com/2007/07/bchr-follies-my-two-cents.html

David Fitzjarrell

Raj

unread,
Aug 10, 2007, 1:52:53 PM8/10/07
to ORACLE_DBA_EXPERTS

>
> > > > > > - Show quoted text -
>
> > > > > Hello David,
>
> > > > > I could not create the tablespace the way you said becuase of

> > > > > compatible parameter. It is asking me to set the compatible parameter- Hide quoted text -


>
> - Show quoted text -...
>
> read more »

Hello David and Charles,

Finally I could resolve the performance problem by increasing the hash
area size (14MB) and sort area size (7 MB) as mentioned below :

SQL> sho parameter sort_area

NAME TYPE VALUE
------------------------------------ -------
------------------------------

sort_area_retained_size integer 7340032
sort_area_size integer 7340032
SQL> sho parameter hash

NAME TYPE VALUE
------------------------------------ -------
------------------------------

hash_area_size integer 14680064

Trace details are mentioned below :

SQL> SELECT /*+ USE_HASH */ a.fpl_id, a.pzug_id, a.pzv_key,
a.einbruchzeit, a.strecke_id, a.bst_reihenfolge, count(*), b.zn FROM

PZV_BSTKETTE a, PFPL_ZUG b WHERE ( a.pzug_id=b.pzug_id ) GROUP BY


a.fpl_id, a.pzug_id, a.pzv_key, a.einbruchzeit, a.strecke_id,
a.bst_reihenfolge, b.zn HAVING count(*)>1 ;

Ausführungsplan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 FILTER
2 1 SORT (GROUP BY)
3 2 NESTED LOOPS

4 3 TABLE ACCESS (FULL) OF 'PFPL_ZUG'
5 3 TABLE ACCESS (BY INDEX ROWID) OF 'PZV_BSTKETTE'


6 5 INDEX (RANGE SCAN) OF 'PZVK_PZV_FK_I' (NON-UNIQUE)

Statistiken
----------------------------------------------------------
0 recursive calls

4 db block gets
14436 consistent gets
0 physical reads


0 redo size
590 bytes sent via SQL*Net to client
319 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client

1 sorts (memory)
0 sorts (disk)
0 rows processed

Please let me know your expert comments if this increase in parameter
is fine or it can have some side effects ?

Thanks much to both of you for your help without which this could not
have been resolved.

Again, it turned out to be a great learning expepriance for me
(offcourse under your guidance).

have a nice weekend.

Regards, Raj

fitzj...@cox.net

unread,
Aug 10, 2007, 2:07:41 PM8/10/07
to ORACLE_DBA_EXPERTS

Those settings should be fine.


David Fitzjarrell

Charles Hooper

unread,
Aug 10, 2007, 2:31:00 PM8/10/07
to ORACLE_DBA_EXPERTS

I agree with David. As long as your server has plenty of memory, the
settings are fine. If you are running on a 32 bit platform, and/or
your server has a limited amount of memory, you need to be careful
with the settings as they can quickly drain the server's available
memory as additional sessions connect and start executing SQL
statements. I used a 10MB sort_area_size for better than 4 years, and
when I switched to 10.2.0.2, I started experimenting with a 20MB
sort_area_size.

How long does it take the SQL statement to execute now?

Raj

unread,
Aug 15, 2007, 10:38:37 AM8/15/07
to ORACLE_DBA_EXPERTS

> K&M Machine-Fabricating, Inc.- Hide quoted text -


>
> - Show quoted text -

Hello Charles,

I was out of station, hence delayed reply.

Now it is taking .3 Seconds.

Regards, Raj

Reply all
Reply to author
Forward
0 new messages