Archive

Posts Tagged ‘execution plan’

generate dumps – overview

13. September 2011 Leave a comment

Some nice – important dump options 🙂

and still under constuction

find sga ID

in Unix environments with mutiple instances running within the same os-use (e.g. oracle) you cannot see which memory segment is allocated to which instance.

sqlplus  / as sysdba
oradebug setmypid
oradebug ipc
oradebug tracefile_name

the column Shmid shows the dependend memory structures

Read more…

Advertisements

init.ora – parameters

here some issues regarding init.ora parameters

show hidden parameters:

Read more…

invalidate cursor in shared pool

Sometimes it’s necessary to invalidate a specific cursor in shared pool.

In the past you had to flush the complete shared pool – which caues ALL sql statements were flushed 😦

In the package dbms_shared_pool you can flush a SINGLE cursor.

Read more…

sql plan management – how to fix an execution plan

in the past stored outlines were used to fix execution plans
in 11g the next level to control execution plans is implemented
its possible to force the optimizer to use one or more execution plans for a statement, uncontrolled plan changes are disabled.

take a closer look at the following examples – test it!
Read more…

event 10046 – tracing sessions

how to trace session by
– alter session
– oradebug
– logon trigger

tracefiles will be placed in user_dump_dest (10g) or in diag_dest/db/inst/trace (11g)

Session Tracing

alter session set max_dump_file_size = unlimited;
alter session set tracefile_identifier='tr10046';
alter session set events '10046 trace name context forever, level 12';

Read more…

Categories: diagnostic Tags: , ,

tkprof – analyze tracefiles

After creating some traces (e.g. via event 10046)  you can analyze those traces with tkprof

tkprof <input tracefile> <output file>  aggregate=no sys=no explain=username/password

sys=no                 hiddes the recursive calls
aggregate=no    doesn’t aggregate reoccured statements to one summary

with sort=xxxx,yyyy,zzzz you can sort the output

     prscnt  number of times parse was called
     prscpu  cpu time parsing
     prsela  elapsed time parsing
     prsdsk  number of disk reads during parse
     prsqry  number of buffers for consistent read during parse
     prscu   number of buffers for current read during parse
     prsmis  number of misses in library cache during parse

     execnt  number of execute was called
     execpu  cpu time spent executing
     exeela  elapsed time executing
     exedsk  number of disk reads during execute
     exeqry  number of buffers for consistent read during execute
     execu   number of buffers for current read during execute
     exerow  number of rows processed during execute
     exemis  number of library cache misses during execute

     fchcnt  number of times fetch was called
     fchcpu  cpu time spent fetching
     fchela  elapsed time fetching
     fchdsk  number of disk reads during fetch
     fchqry  number of buffers for consistent read during fetch
     fchcu   number of buffers for current read during fetch
     fchrow  number of rows fetched
Categories: diagnostic Tags: , ,

event 10053 – obtaining optimizer computations

to see how the oracle optimizer generates the execution plan  use the event 10053

alter session set max_dump_file_size = unlimited;
alter session set tracefile_identifier='tr10053';
alter session set events='10053 trace name context forever, level 1';

the tracefile will be written to user_dump_dest (10.2) or in <diag_dest>/rdbms/<database>/<instance>/trace