Advice regarding how best to collect stats on 10G RAC Production system

Question

Friends,
I have read quite a lot of blogs and docs and need some help with the best way forward. I am a DBA new to RAC who has limited experience with busy 24@7 10g systems on the scale of my current employer.
Historically stats are gathered here as follows :-
exec dbms_stats.unlock_schema_stats('BP');
exec dbms_stats.gather_schema_stats(ownname => 'BP', cascade => true, estimate_percent => dbms_stats.auto_sample_size);
exec dbms_stats.lock_schema_stats('BP');
Then Flush shared pool ok ????
Because of previous issues with this - alll tables are currently locked and this process is recommended for every 1-2 months rather than daily.
EM Grid Control is used when performance is poor and the sql tuning advisor is run to generate recommendations from which a sql profile could be selected and enabled for the selected code.
My plan is to bring back gathering of stats every 1 to 2 months, my goal is make sure I can fix things quickly if it all goes to custard !!!!
From research it looks like sql_profile is like a hint and independent of gathering stats - it tells optimiser what hints to use when executing sql.
This thread is for advice from professional dba's in my shoes - how do you approach this so that any issues are quickly rectified ???
My thinking is to query dba_profiles and get list of profiles and statuses ... for all tables with sql profiles ..
This is so profiles can be disabled and then quickly enabled if there is a problem aftewr the tables are analyzed.
To revert all the schema stats :-
exec dbms_stats.unlock_schema_stats('BP');
exec dbms_stats.restore_schema_stats(ownname=>'BP',as_of_timestamp=>sysdate-1);
exec dbms_stats.lock_schema_stats('BP');
To revert a table's stats (this looks more finicky so not sure the way to go ...):-
Pre gather stats :-
select stats_update_time from user_tab_stats_history where table_name = ‘<EnterTabName>’;
exec dbms_stats.create_stat_table ( -‘SCOTT’, -‘stattab_new’);
exec dbms_stats.export_table_stats ( -‘SCOTT’, -‘DEPT’, -null, -‘stattab_new’, -null, -true, -‘SCOTT’);
Then later after gather stats :-
exec dbms_stats.restore_table_stats ( -‘SCOTT’, -‘DEPT’, -’21-JAN-09 11.00.00.000000 AM -05:00′);
Enable/Disable Profile
exec dbms_sqltune.alter_sql_profile('<Profile name>', 'STATUS', 'DISABLED');
exec dbms_sqltune.alter_sql_profile('<Profile name>', 'STATUS', 'ENABLED');
I will do the plan below on a test system first however load may not really identify problems until for real on the Prod system.
My plan is to :-
1 analyze all tables as per outline at start above (existing practice)
2 Disable the sql profiles that are in use on the analyzed tables
3 See what code is affected and what tables
If Profile exists for these sql statements then either apply existing profile (as disabled) or use tuning adviser to create another profile
(Advice welcome here - what do you do on big systems ????)
4 If its a catastrophe - I can restore the schema stats using (exec dbms_stats.restore_schema_stats(ownname=>'BP',as_of_timestamp=>sysdate-1);)
and then possibly re-enabling the sql_profiles that were in place before ....
I welcome any advice based on similar experiences that can help me get this right.
Many thanks,
cheers, Rob
Edited by: Diesel on Jun 27, 2012 10:51 PM

Answer 1

Useful Link:
http://www.oradev.com/create_statistics.jsp
## Gather schema stats
begin
dbms_stats.gather_schema_stats(ownname=>'SYSLOG');
end;
## Gather a particular table stats of a schema
begin
DBMS_STATS.gather_table_stats(ownname=>'syslog',tabname=>'logs');
end;
Regards
Asif Kabir
--mark the answer as correct/helpful