irfanyell

 Profile Answers by irfanyell 

• Jun 18th, 2008

 

we have to take the sql trace. but it cannot be read by us. so we have to take the tkprof of this file which can be read by us. to take the sql trace fire the below command

SQL>alter session set sql_trace=true;

then fire that sql statement

SQL>select count(*) from [tablename];

it will generate a trace file in udump

then stop the trace by following command

SQL>alter session set sql_trace=false;

then produce a tkprof

$tkprof [filename] [kprof filename]

regards
irfan

baala

 Profile Answers by baala 

• Aug 11th, 2008

 

Probably there occured a plan flip, look for changes in the plan using the AWR views.

baala

 Profile Answers by baala 

• Aug 11th, 2008

 

Have a look into the following tables :

DBA_HIST_SQLSTAT
dba_hist_snapshot

by doing natural joins on these views for the SQL_ID, you will know about any plan changes happened.

Do corrective actions as per the findings.

sonaligujral1

 Profile Answers by sonaligujral1 

• Aug 7th, 2010

 

Block corruption error may happen

vijender reddy

 Profile Answers by vijender reddy 

• Aug 12th, 2010

 

First we must check for any locks on the objects, if we get any locks then just
release that lock.
Here is how you can know if there is a lock on an object

1.
Find sid
SQL>select distinct sid from v$mystat;
we get some sid example 3
SQL>select sql_has_value from v$session where sid=;

2. Find hash_value
SQL>select sql_text from v$sqltext where hash_value=<'some no'>
SQL>desc v$locked_object;
SQL>desc dba_objects;