Planning to start the performance tuning but....

Question

Friends,
Database OS: RHEL AS 3.0
Database: Oracle Release 9.2.0.4.0
Number of Tables: 503
TableSpace size - 1.8GB out of 3GB
Max.Records in a Table - 1 Million and its increasing..
Our DB Optimizer mode is - CHOOSE (is it RBO?)
We are not using enterprise manager and not installed any tuning scripts like statspack etc....
Currently we are taking user managed backup without any problem so we are continuing the same from 2004 onwards.
Now we want want to tune our database.(We have never tuned our database)
We would like to change our optimizer from RBO to CBO.
Can anybody tell me the first step for the performance tuning?
Please dont suggest me oracle doc im already studying.....its taking time....
In the mean time......
Step 1: Can i Analyze the table or dbms_stat package?
We have not at all used the analyze or dbms_stat. So can i start with any of the above or do u have any other suggestions for the 1st step?
Thanks

Answer 1

our manager feels that if we tune our db the performance will be more than compared to the current one.you have a mystique manager then, ask him what kind of "feelings" does he have about my database ;) there is no place for feelings in this game, this is life cycle to be successful ; testing->reporting->analyzing->take nedded actions->re-testing->reporting->analyzing..
so while you are surely reading the documentation;
Oracle9i Database Performance Planning Release 2 (9.2)
http://download.oracle.com/docs/cd/B10501_01/server.920/a96532/toc.htm
Oracle9i Database Performance Tuning Guide and Reference Release 2 (9.2)
http://download.oracle.com/docs/cd/B10501_01/server.920/a96533/toc.htm
first thing you have to do is to setup an appropriate test environment with same os-oracle releases, parameters;
-- some of them to check
SELECT NAME, VALUE
  FROM v$system_parameter a
WHERE a.NAME IN
       ('compatible', 'optimizer_features_enable',
        'optimizer_mode', 'pga_aggregate_target', 'workarea_size_policy',
        'db_file_multiblock_read_count', .. )and of course schema set and data amount. Then you run your application on load and take statspack snapshots and do the same after collecting statistics;
-- customize for your configuration, schema level object statistics
exec dbms_stats.gather_schema_stats( ownname =>'YOUR_SCHEMA', degree=>16, options=>'GATHER AUTO', estimate_percent=>dbms_stats.auto_sample_size, cascade=>TRUE, method_opt=>'FOR ALL COLUMNS SIZE AUTO', granularity=>'ALL');
-- check your system stats, with sys account
SELECT pname, pval1 FROM sys.aux_stats$ WHERE sname = 'SYSSTATS_MAIN';after you have the base report and the report after change compare the top 5 waits, the top queries which have dramatic logical I/O changes etc. At this point you go into session based tuning in order to understand why a specific query performs worser with CBO compared to RBO. You need to be able to create and read execution plans and i/o statistics at least. Here are some quick introductions;
http://www.bhatipoglu.com/entry/17/oracle-performance-analysis-tracing-and-performance-evaluation
http://psoug.org/reference/explain_plan.html
http://coskan.wordpress.com/2007/03/04/viewing-explain-plan/
and last words again goes to your manager; how does he "feel" about a 10gR2 migration? With Grid Control, AWR, ADDM and ASH performance tuning evolved a lot. Important note here, after 10g RBO is dead(unsupported).
Best Regards,
H.Tonguç YILMAZ
http://tonguc.yilmaz.googlepages.com/
Message was edited by:
TongucY