SQLTRACE AND DB_FILE_SEQUENTIAL_READ [message #164295] |
Wed, 22 March 2006 17:42 |
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 |
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 #164441 is a reply to message #164308] |
Thu, 23 March 2006 08:31 |
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 #164464 is a reply to message #164451] |
Thu, 23 March 2006 09:36 |
|
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 |
|
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 |
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 |
|
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
|
|
|