Home » RDBMS Server » Performance Tuning » SQLTRACE AND DB_FILE_SEQUENTIAL_READ
SQLTRACE AND DB_FILE_SEQUENTIAL_READ [message #164295] Wed, 22 March 2006 17:42 Go to next message
sumang24
Messages: 10
Registered: July 2005
Junior Member
I have a very complex query that runs very fast in the QC env but in prodcution it takes almost 120 times more time. The query generates exactly the same plan in both the environments and the stats are also identical in both the envs. Prodcution env has more data compared to QC env . I would say almost 2 or 3 % more.

I did an sqltrace on the query and found that the

1) cardinality ( cr ) was very high for few tables in the query in production.
2) DB_FILE_SEQUENTIAL_READ was almost 26 times more in Production.

We are not analyzing the tables in either environment since the past couple of years.

My question is:

Is this problem due to the data being scattered in different blocks in production?
or due to stale statistics on the tables? ( the stats are identical in both the envs and they both generate exactly the same plan )

Thanks for your inputs!
Re: SQLTRACE AND DB_FILE_SEQUENTIAL_READ [message #164308 is a reply to message #164295] Wed, 22 March 2006 20:44 Go to previous messageGo to next message
rleishman
Messages: 3728
Registered: October 2005
Location: Melbourne, Australia
Senior Member
First thing I would do is check your assertion that the plan is the same and the data volumes differ by only 3%. One of these is most likely in error.

I would like to see the TK*Prof output of both queries that shows the plans are the same AND the number of rows differs by no more than 3%.

If this is true, then the rows in your QC environment must be in nearly the exact same order as the indexes, and Prod must be scattered horribly. Even so, it would be difficult to account for this amount of difference.

Is it possible that Prod is missing a column on a multi-column index?
_____________
Ross Leishman
Re: SQLTRACE AND DB_FILE_SEQUENTIAL_READ [message #164309 is a reply to message #164295] Wed, 22 March 2006 20:54 Go to previous messageGo to next message
Mahesh Rajendran
Messages: 10708
Registered: March 2002
Location: oracleDocoVille
Senior Member
Account Moderator
>>We are not analyzing the tables in either environment since the past couple of years.
seriously?
Or you mean to say that you collect stats with DBMS_STATS and not using ANALYZE ?
You need a decent statistics to start with.
All the rest to follow.
Please check the sticky.

[Updated on: Wed, 22 March 2006 21:10]

Report message to a moderator

Re: SQLTRACE AND DB_FILE_SEQUENTIAL_READ [message #164441 is a reply to message #164308] Thu, 23 March 2006 08:31 Go to previous messageGo to next message
sumang24
Messages: 10
Registered: July 2005
Junior Member
If can you send me your emailid I will send you the trace files.
I am 100% sure that the explain plans are identical. One weird thing I wanted to pint is that in the explain plan it shows an INDEX X on a table BIG_TABLE where as in the trace file it shows a different index on BIG_TABLE. How is this possible?

The cardinality is extremely high on some key tables in Production env.

Thanks
Re: SQLTRACE AND DB_FILE_SEQUENTIAL_READ [message #164451 is a reply to message #164441] Thu, 23 March 2006 09:01 Go to previous messageGo to next message
Mahesh Rajendran
Messages: 10708
Registered: March 2002
Location: oracleDocoVille
Senior Member
Account Moderator
>> trace file it shows a different index on BIG_TABLE. How is this possible?
Because EXPLAIN PLAN output is what you see NOW and trace output is what you see during the actual execution.
CARD is derived from available statistics and histograms.
without proper histograms CBO will start to hallucinate.
Re: SQLTRACE AND DB_FILE_SEQUENTIAL_READ [message #164460 is a reply to message #164451] Thu, 23 March 2006 09:28 Go to previous messageGo to next message
sumang24
Messages: 10
Registered: July 2005
Junior Member
Mahesh,

Thanks for your input. Do you suggest I should take stats on the index which has very high cardinality in Prod env? The stats have not been taken since the last couple of years.
Re: SQLTRACE AND DB_FILE_SEQUENTIAL_READ [message #164464 is a reply to message #164451] Thu, 23 March 2006 09:36 Go to previous messageGo to next message
Mahesh Rajendran
Messages: 10708
Registered: March 2002
Location: oracleDocoVille
Senior Member
Account Moderator
Please see the session.
.


scott@9i > select job,count(*) from emp group by job;

JOB         COUNT(*)
--------- ----------
ANALYST        65536
CLERK         131072
MANAGER        98304
PRESIDENT      32768
SALESMAN      131072

scott@9i > set autotrace traceonly exp
-- First collect statistics without proper histograms
scott@9i > exec dbms_stats.gather_table_stats('SCOTT','EMP');

PL/SQL procedure successfully completed.


-- this query should produce a card of approximately 32768
-- But it produces something else.

scott@9i > select count(*) from emp where job='PRESIDENT';

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=261 Card=1 Bytes=8)
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'EMP' (Cost=261 Card=91750 Bytes=
          734000)


--
-- Collect stats with histograms
-- You get exactly what you want.
-- This is just an example. In reality you may want to collect histogram 
-- only on indexed columns with a proper bucket size.
--
scott@9i > exec dbms_stats.gather_table_stats('SCOTT','EMP',METHOD_OPT=>'FOR ALL COLUMNS SIZE 250');

PL/SQL procedure successfully completed.

scott@9i > select count(*) from emp where job='PRESIDENT';

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=261 Card=1 Bytes=8)
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'EMP' (Cost=261 Card=32768 Bytes=
          262144)


And i just re-read this
>> 1) cardinality ( cr ) was

CR in trace out-put is not cardinality. It is number of oracle blocks you retrieved in a consistent mode. In a production environment, a HIGH Consistent get may mean that there are multiple sessions involved.
To give consistent image, oracle will rebuild the data from undosegments in your sessions. This will be shown as HIGH CONSISTENT GETS.
Please look here
http://www.orafaq.com/forum/m/124426/42800/?srch=consistent+gets#msg_124426


[Updated on: Thu, 23 March 2006 09:42]

Report message to a moderator

Re: SQLTRACE AND DB_FILE_SEQUENTIAL_READ [message #164465 is a reply to message #164464] Thu, 23 March 2006 09:41 Go to previous messageGo to next message
Mahesh Rajendran
Messages: 10708
Registered: March 2002
Location: oracleDocoVille
Senior Member
Account Moderator
And where did it that Card=91750 ???
Becuase of improper statistics.
scott@9i > compute AVG SUM of "count" on report
scott@9i > break on report
scott@9i > select job,count(*) "count" from emp group by job;

JOB            count
--------- ----------
ANALYST        65536
CLERK         131072
MANAGER        98304
PRESIDENT      32768
SALESMAN      131072
          ----------
avg          91750.4
sum           458752



>>Do you suggest I should take stats on the index
Collect statistics on table and index.

[Updated on: Thu, 23 March 2006 10:09]

Report message to a moderator

Re: SQLTRACE AND DB_FILE_SEQUENTIAL_READ [message #164750 is a reply to message #164465] Sat, 25 March 2006 08:36 Go to previous messageGo to next message
sumang24
Messages: 10
Registered: July 2005
Junior Member
Mahesh,

Thanks for your reply. If we have a big table with 4 million rows and the query plan generated is optimal, the query uses the best possible index. Is it possible that the query can take time to retrieve the result sets if the stats are not updated or stats are stale on the table / indexes being used?

Does oracle reads the blocks faster if the stats are uptodate. I was under the impression that stats give oracle the best possible plan to retrieve the result sets .

I have also seen from my experiences in the past if:

We have a table A with 4 million rows and emp_id is the primary key, if we have updated stats on the emp_id unique index then the query returns the count of the rows very fast :

select count(1) from
A;

But if the stats are not uptodate the query takes a long time to return the count.

Can you please clarify my doubt here?

Thanks
Re: SQLTRACE AND DB_FILE_SEQUENTIAL_READ [message #164752 is a reply to message #164750] Sat, 25 March 2006 08:56 Go to previous message
Mahesh Rajendran
Messages: 10708
Registered: March 2002
Location: oracleDocoVille
Senior Member
Account Moderator
We are repeating the same concept again and again.
Statistics decides all.
CBO decides the plan based on statistics.
Multiple plans are considered. But the plan with the lowest cost is chosen. This 'Cost' is based on statistics.
And it doesnt mean that, lowest cost plan is the 'fastest' plan

[Updated on: Sat, 25 March 2006 09:07]

Report message to a moderator

Previous Topic: Function taking very long to execute
Next Topic: How increase SGA more than 25% of physical memory
Goto Forum:
  


Current Time: Sat Nov 30 09:06:08 CST 2024