Gather stats

Question

Hi All,
I want to add DBMS_STATS.gather_table_stats on table command to my scripts.
Just got confuse on the position.
Consider as follows step and sequences
1. Table ABC is created without a record.
2. Table ABC is inserted with data
3. Table ABC is inserted with SOME MORE data
4. DBMS_STATS.gather_table_stats is execited
5. Table ABC is Select
6. Table ABC is UPDATE
7. Table ABC is DELETED
8. Table ABC is inserted with SOME MORE data
Do I require DBMS_STATS.gather_table_stats command to be between step 6 and 7 and 8.
rgds
saaz

Answer 1

Rakesh jayappa wrote:
Hi,
I want to add DBMS_STATS.gather_table_stats on table command to my scripts.
Just got confuse on the position.
Consider as follows step and sequences
1. Table ABC is created without a record.
2. Table ABC is inserted with data
3. Table ABC is inserted with SOME MORE data
4. DBMS_STATS.gather_table_stats is execited
5. Table ABC is Select
6. Table ABC is UPDATE
7. Table ABC is DELETED
8. Table ABC is inserted with SOME MORE data
Do I require DBMS_STATS.gather_table_stats command to be between step 6 and 7 and 8.
Let me tell you the golden rule
sql> desc dba_tab_modifications;
select insert,delete,update from dba_tab_modifications where table_name='ABC';
lets assume 50 20 30
10+10+10=30
sql> select count(*) from ABC;
50
if 10% of data got modified then oracle suggest to collect the stats if the query is performing slowly
Hope this answers your question
Kind Regards,
Rakesh JayappaLet me tell you the platinum rule
The optimizer uses as much information as it can to decide on an access plan for the data. If the information is accurate for the query, performance may or may not be good, though normally it is. If it is not accurate, performance may or may not be good.
It is entirely possible that the information gathered in statistcs will not be accurate. It is possible that different queries will need different plans to get good performance, and the optimizer could be mistaken for some.
The optimizer is geared toward a steady state, not mass changes as described. Even so, it is possible to have a situation where a small change in data leads to a significant change in plan, with a consequent change in performance. Bind variable peeking means you can have a significant change in performance without changing the plan, simply from different values in the query.
For this scripted situation, you need to be explicit about what queries will be used and the best plan for each in the varying data situations. You can use hints, which may be a maintenance problem down the road and requires a deep understanding of each query. You can use plan stability, which uses hints. You can lock the statistics, which may or may not be appropriate depending on the different queries. You cannot state that any percentage data change will have a predictable result. You cannot predict what will happen just by gathering statistics at varying points in the process. You can test, test, test, and still not hit a real production situation.
So, it depends.