One way to identify the causes of poor performance in the database is to review AWR, ADDR, and ASH reports. They should be for a period of 60 or more minutes, covering the poor performance period.
. To generate the AWR report, execute the following script and select two snapshots:
SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql
>> Choose the TXT format or the HTML format.
. To generate the ADDM report, execute:
SQL> @$ORACLE_HOME/rdbms/admin/addmrpt
>> Choose the TXT format or the HTML format.
. To generate the ASH report, execute:
SQL> @$ORACLE_HOME/rdbms/admin/ashrpt
>> Choose the TXT format or the HTML format.
Tuesday, January 26, 2010
Friday, January 8, 2010
REDO log sizing
Online redo log sizing is very important. If it is too small, the LGWR, ARCH and DBWR background processes will be busy by the frequent log switches and increase CPU usage. It it is too big, the database risks losing data during an instance crash.
In Oracle 10G, Oracle advisory utility makes recommendation on optimal redo log size. To use this feature, an initialization parameter FAST_START_MTTR_TARGET parameter must be set to a nonzero value, which specifies a target (bounded) time (in seconds) to complete the cache recovery phase of recovering. Using this parameter, Oracle database can now self-tune checkpointing to achieve good recovery times with low impact on normal throughput. DBAs no longer have to set any checkpoint-related parameters and should disable (set to 0) the following parameters:
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINT_INTERVAL
- FAST_START_IO_TARGET
View v$instance_recovery holds the MTTR (mean time to recovery ) information with following columns:
optimal_logfile_size -- the suggested size in megabytes
target_mttr -- MTTR target in effect in seconds
estimated_mttr -- the estimated MTTR if a crash happens right now
The data reported in this view may change frequently, based on the DML load on the database. DBAs can use the suggested size when the database is relatively stable to build the redo log properly.
Grid Control also gives the suggested size. The navigation is
Adminstration --> Storage --> Redo Log Group --> Actions dropdown: Sizing advice --> Go.
Oracle Database Backup and Recovery Advanced User's Guide (10gR2, B14191-01) has details on Oracle recovery process and on FAST_START_MTTR_TARGET sizing.
Note 276103.1 has more on Advisors.
In Oracle 10G, Oracle advisory utility makes recommendation on optimal redo log size. To use this feature, an initialization parameter FAST_START_MTTR_TARGET parameter must be set to a nonzero value, which specifies a target (bounded) time (in seconds) to complete the cache recovery phase of recovering. Using this parameter, Oracle database can now self-tune checkpointing to achieve good recovery times with low impact on normal throughput. DBAs no longer have to set any checkpoint-related parameters and should disable (set to 0) the following parameters:
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINT_INTERVAL
- FAST_START_IO_TARGET
View v$instance_recovery holds the MTTR (mean time to recovery ) information with following columns:
optimal_logfile_size -- the suggested size in megabytes
target_mttr -- MTTR target in effect in seconds
estimated_mttr -- the estimated MTTR if a crash happens right now
The data reported in this view may change frequently, based on the DML load on the database. DBAs can use the suggested size when the database is relatively stable to build the redo log properly.
Grid Control also gives the suggested size. The navigation is
Adminstration --> Storage --> Redo Log Group --> Actions dropdown: Sizing advice --> Go.
Oracle Database Backup and Recovery Advanced User's Guide (10gR2, B14191-01) has details on Oracle recovery process and on FAST_START_MTTR_TARGET sizing.
Note 276103.1 has more on Advisors.
Subscribe to:
Posts (Atom)