FAST_START_MTTR_TARGET parameter advice

Hello
I need some advice in setting the FAST_START_MTTR_TARGET initialization parameter. There is a lot of valuable documentation and blog posts out there but I am unable to find concrete guidance on this.
In reading the Checkpoint Tuning and Troubleshooting Guide (147468.1), there is mention of 4 total parameters (including FAST_START_MTTR_TARGET) that need to be visited in order to set this:
- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINTS_TO_ALERT
My current db server environment settings are as follows:
W2K8-R2-Std, 11g-11.2.0.1.0-Std
OS-block-size = 4096 bytes
The current initialization parameter settings are:
FAST_START_MTTR_TARGET = 0
LOG_CHECKPOINT_INTERVAL = 0
LOG_CHECKPOINT_TIMEOUT = 1800
LOG_CHECKPOINTS_TO_ALERT = FALSE
The current redo log files are set at 51,200KB.
The condition warranting this is these entries in the alert log:
Thread 1 cannot allocate new log, sequence 117424
Private strand flush not complete
Current log# 1 seq# 117423 mem# 0: K:\ORACLE_SID\REDOG1M1.LOG
Current log# 1 seq# 117423 mem# 1: L:\ORACLE_SID\REDOG1M2.LOG
Thread 1 advanced to log sequence 117424 (LGWR switch)
Current log# 3 seq# 117424 mem# 0: D:\APP\ORADATA\ORACLE_SID\REDOG3M1.LOG
Current log# 3 seq# 117424 mem# 1: L:\ORACLE_SID\REDOG3M2.LOG
Kindly advise. Thank you in advance.

Look in your alert log to see how long it is between redo switches during times of heavy usage. Multiply the size of the redo by how much it would take to switch every 30 minutes. For example, if you switch every 5 minutes, multiply by 6. Then make them much larger and rely on the 1800 second timeout (or better, do the figuring during maximal loading or batch update times). Let it run a few days then check the advisor as in http://docs.oracle.com/cd/E25178_01/server.1111/e16638/build_db.htm#autoId3
Here's the proper way to figure FSMT http://docs.oracle.com/cd/E25178_01/server.1111/e16638/instance_tune.htm#PFGRF13015
Don't bother changing dbw settings yet. Wait until you see some evidence you need to do that.

Similar Messages

Set FAST_START_MTTR_TARGET parameter

Hi experts,
I was set FAST_START_MTTR_TARGET parameter 14. and as per my understanding if i set FAST_START_MTTR_TARGET is 14 , it might mean, it will take 13 second for instance recover.
But when i had to applied it in real environment , it wasn't work. It was take more time. Can you please explain my understanding is rite or not. OR if i was rite then why it's take more time for recover instance.
SQL> sho parameter FAST_START_MTTR_TARGET
NAME                                 TYPE        VALUE
fast_start_mttr_target               integer     0
SQL> alter system set FAST_START_MTTR_TARGET=14 scope=both;
System altered.
SQL> sho parameter FAST_START_MTTR_TARGET
NAME                                 TYPE        VALUE
fast_start_mttr_target               integer     14Reg,
Harshit

Hi,
Firstly 14 seconds is what you would like to achieve. Doesn't mean that this is what you will achieve. This could be because of a number of reasons one of which might be the speed of the disks the database sits on.
By setting this parameter Oracle will checkpoint at intervals to try and keep your mttr to 14 seconds. A low setting isn't necessarily a good thing as you will have more frequent checkpoints which in turns means more I/O. Again this can be quite bad if your database is sitting on low performance disks.
Secondly you need to disable LOG_CHECKPOINT_INTERVAL.
alter system set log_checkpoint_interval=0 scope=both;

FAST_START_MTTR_TARGET parameter

What does FAST_START_MTTR_TARGET parameter exactly means?
Does it mean that how many dirty buffers exist before next checkpoint start? or how many seconds before the next checkpoint will start?
Thanks in advance

FAST_START_MTTR_TARGET enables you to specify the number of seconds the database takes to perform crash recovery of a single instance. When specified, FAST_START_MTTR_TARGET
Is overridden by FAST_START_IO_TARGET
Is overridden by LOG_CHECKPOINT_INTERVAL
This parameter was introduced in Oracle9i.
It replaces FAST_START_IO_TARGET and LOG_CHECKPOINT_INTERVAL in Oracle8i,
although the old parameters can still be set if required in Oracle9i.

Fast_start_mttr_target performance

On 10.2.0.3 database fast_start_mttr_target is set to 300 and OPTIMAL_LOGFILE_SIZE from V$INSTANCE_RECOVERY shows 6762M after a morning of heavy database activity. My quesiton is this: Does the fast_start_mttr_target parameter have any performance impact on the database or is it primarily for calculating and suggesting optimal log size? Does increasing the fast_start_mttr_target affect log switching? If I increased the fast_start_mttr_target to 900 or 1800 would this help log performance (i.e. not switching too often)? I will increase log size as well, but does fast_start_mttr_target setting have performance implications?
Curt Swartzlander
[email protected]

Yes I found the answer in this documentation!!
To reduce the checkpoint frequency and optimize runtime performance, you can do the following:
Set the value of FAST_START_MTTR_TARGET to 3600. This enables Fast-Start checkpointing and the Fast-Start Fault Recovery feature, but minimizes its effect on runtime performance while avoiding the need for performance tuning of FAST_START_MTTR_TARGET.
Thank you and please reply to this threas so I can give you a "correct" star. I meant to do this to your reply but did something wrong.
Curt

Fast_start_mttr_target x standard edition

Hi guys,
Do you know if there are problems to use the "fast_start_mttr_target" parameter in a Oracle Standard Edition?
Thanks,
Paulo.

Not sure what the differences are between std and ent editions for this feature.
Standard is missing some functionality according to this view description and fast-start is also mentioned in the feature availability list.

Why disable few parameters when fast_start_mttr_target set to non zero.

When fast_start_mttr_target set to non zero value why do we need to disable log_checkpoint_interval, log_checkpoint_timeout and fast_start_io_target?

These parameters were replaced in 9i only by the fast_start_mttr_target parameter. And the recommendation to not to use them now is because, if set , these parameters would override the FSMTT parameter and also would disable the auto-tuning of the incremental checkpointing which is there because of FSMTT.
HTH
Aman....

Managing ARCHIVE Logs in Oracle 10.2.0.3

I am working with a customer who seems to think there is a way of controling the database other than a custom JOB, script or RMAN in how it creates, manages and deletes its archive logs while running in archivelog mode. He wants the database to automatically delete obsolete archive logs. He also wants to control the duration in time between each time an archive log is written in order to stop the growth of archive logs and filling up disk space.
I am saying this is not possible. You either configure RMAN to delete the obsolete or expired archive logs based on your retention policy or do it manually in the Enterprise Manager or Grid Control Console by deletenig obsolete or expired logs.
Am I correct or am I off base here?

4.1.3 Sizing Redo Log Files
The size of the redo log files can influence performance, because the behavior of the database writer and archiver processes depend on the redo log sizes. Generally, larger redo log files provide better performance. Undersized log files increase checkpoint activity and reduce performance.
Although the size of the redo log files does not affect LGWR performance, it can affect DBWR and checkpoint behavior. Checkpoint frequency is affected by several factors, including log file size and the setting of the FAST_START_MTTR_TARGET initialization parameter. If the FAST_START_MTTR_TARGET parameter is set to limit the instance recovery time, Oracle automatically tries to checkpoint as frequently as necessary. Under this condition, the size of the log files should be large enough to avoid additional checkpointing due to under sized log files. The optimal size can be obtained by querying the OPTIMAL_LOGFILE_SIZE column from the V$INSTANCE_RECOVERY view. You can also obtain sizing advice on the Redo Log Groups page of Oracle Enterprise Manager Database Control.
It may not always be possible to provide a specific size recommendation for redo log files, but redo log files in the range of a hundred megabytes to a few gigabytes are considered reasonable. Size your online redo log files according to the amount of redo your system generates. A rough guide is to switch logs at most once every twenty minutes.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/build_db.htm#sthref237
If you are talking about data guard then:
4.1.3 Sizing Redo Log Files
The size of the redo log files can influence performance, because the behavior of the database writer and archiver processes depend on the redo log sizes. Generally, larger redo log files provide better performance. Undersized log files increase checkpoint activity and reduce performance.
Although the size of the redo log files does not affect LGWR performance, it can affect DBWR and checkpoint behavior. Checkpoint frequency is affected by several factors, including log file size and the setting of the FAST_START_MTTR_TARGET initialization parameter. If the FAST_START_MTTR_TARGET parameter is set to limit the instance recovery time, Oracle automatically tries to checkpoint as frequently as necessary. Under this condition, the size of the log files should be large enough to avoid additional checkpointing due to under sized log files. The optimal size can be obtained by querying the OPTIMAL_LOGFILE_SIZE column from the V$INSTANCE_RECOVERY view. You can also obtain sizing advice on the Redo Log Groups page of Oracle Enterprise Manager Database Control.
It may not always be possible to provide a specific size recommendation for redo log files, but redo log files in the range of a hundred megabytes to a few gigabytes are considered reasonable. Size your online redo log files according to the amount of redo your system generates. A rough guide is to switch logs at most once every twenty minutes.
Automatic Deletion of Applied Archive Logs
Archived logs, once they are applied on the logical standby database, will be automatically deleted by SQL Apply.
This feature reduces storage consumption on the logical standby database and improves Data Guard manageability.
See also:
Oracle Data Guard Concepts and Administration for details
http://download.oracle.com/docs/cd/B19306_01/server.102/b14214/chapter1.htm#sthref269

"checkpoint not complete" in alert log file.

Hi, all.
I have got a message of "Checkpoint not complete" in alert log file.
Thread 2 advanced to log sequence 531
Current log# 7 seq# 531 mem# 0: \\.\REDO231
Current log# 7 seq# 531 mem# 1: \\.\REDO232
Thread 2 cannot allocate new log, sequence 532
Checkpoint not complete
Current log# 7 seq# 531 mem# 0: \\.\REDO231
Current log# 7 seq# 531 mem# 1: \\.\REDO232
I searched "Checkpoint not complete" issue in this forum.
As solutions,
1. add more redo log groups
2. increase the size of redo log
3. check I/O contention
4. set LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT or
FAST_START_MTTR_TARGET
I think No.4 is the possible first approach in our environment.
I think No.1 and No2 are not the ploblems in our environment.
I ask the above issue oracle support center, but
I was told that "if you are not getting this message frequently, you do not need to worry about it" from an oracle engineer.
Is this true?? If I am not getting this message frequently, there is no problem
in terms of database integrity, consistency, and performance?
I will be waiting for your advice and experience in real life.
Thanks and Regards.

Redo Log Tuning Advisory and Automatic Checkpoint Tuning are new features introduced in Oracle 10G, if you are on 10g you may benefit from these features.
The size of the redo log files can influence performance, because the behavior of the database writer and archiver processes depend on the redo log sizes. Generally, larger redo log files provide better performance, however it must balanced out with the expected recovery time. Undersized log files increase checkpoint activity and increase CPU usage. As rule of thumb switching logs at most once every fifteen minutes.
Checkpoint frequency is affected by several factors, including log file size and the setting of the FAST_START_MTTR_TARGET initialization parameter. If the FAST_START_MTTR_TARGET parameter is set to limit the instance recovery time, Oracle automatically tries to checkpoint as frequently as necessary. Under this condition, the size of the log files should be large enough to avoid additional checkpointing due to under sized log files.
The redo logfile sizing advisory is specified by column optimal_logfile_size of v$instance_recovery. This feature require setting the parameter "fast_start_mttr_target" for the advisory to take effect and populate the column optimal_logfile_size.
Also you can obtain redo sizing advice on the Redo Log Groups page of Oracle Enterprise Manager Database Control.
To enable automatic checkpoint tuning, unset FAST_START_MTTR_TARGET or set it to a nonzero value(This is measured in seconds and by default, this feature is not enabled, because FAST_START_MTTR_TARGET has a default value of 0). If you set this parameter to zero this feature will be disabled. When you enable fast-start checkpointing, remove or disable(set to 0) the following initialization parameters:
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- FAST_START_IO_TARGET
Enabling fast-start checkpointing can be done statically using the initialization files or dynamically using -
SQL> alter system set FAST_START_MTTR_TARGET=10;
Best regards.

Private strand flush not complete how to find optimal size of redo log file

hi,
i am using oracle 10.2.0 on unix system and getting Private strand flush not complete in the alert log file. i know this is due to check point is not completed.
I need to increase the size of redo log files or add new group to the database. i have log file switch (checkpoint incomplete) in the top 5 wait event.
i can't change any parameter of database. i have three redo log group and log files are of 250MB size. i want to know the suitable size to avoid problem.
select * from v$instance_recovery;
RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS TARGET_REDO_BLKS LOG_FILE_SIZE_REDO_BLKS LOG_CHKPT_TIMEOUT_REDO_BLKS LOG_CHKPT_INTERVAL_REDO_BLKS FAST_START_IO_TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR CKPT_BLOCK_WRITES OPTIMAL_LOGFILE_SIZE ESTD_CLUSTER_AVAILABLE_TIME WRITES_MTTR WRITES_LOGFILE_SIZE WRITES_LOG_CHECKPOINT_SETTINGS WRITES_OTHER_SETTINGS WRITES_AUTOTUNE WRITES_FULL_THREAD_CKPT
625 9286 9999 921600 9999 0 9 112166207 0 0 219270206 0 3331591 5707793please suggest me or tell me the way how to find out suitable size to avoid problem.
thanks
umesh

How often should a database archive its logs
Re: Redo log size increase and performance
Please read the above thread and great replies by HJR sir. I think if you wish to get concept knowledge, you should add in your notes.
"If the FAST_START_MTTR_TARGET parameter is set to limit the instance recovery time, Oracle automatically tries to checkpoint as frequently as necessary. Under this condition, the size of the log files should be large enough to avoid additional checkpointing due to under sized log files. The optimal size can be obtained by querying the OPTIMAL_LOGFILE_SIZE column from the V$INSTANCE_RECOVERY view. You can also obtain sizing advice on the Redo Log Groups page of Oracle Enterprise Manager Database Control."
Source:http://download-west.oracle.com/docs/cd/B13789_01/server.101/b10752/build_db.htm#19559
Pl also see ML Doc 274264.1 (REDO LOGS SIZING ADVISORY) on tips to calculate the optimal size for redo logs in 10g databases
Source:Re: Redo Log Size in R12
HTH
Girish Sharma

How to reduced instance recovery time

Hello Friends how are you all. I hope you all will be fine. friends I want to reduced the instance recovery time but i don't know which views or parameters which could helpful for me. Please tell me the way how can i reduced the instance recovery time.
Thanks & Best Wishes

Hi,
Reduced instance recovery time
check ur DB size, is it connected many users.
my advice is do not set the reduced instance recovery time, it may be decreased run-time peformance.
the following procedure
-) Frequent checkpoints
-) reduce instance recovery time
-) set FAST_START_MTTR_TARGET parameter
-) size the Online redo log files
-) Implent manual checkpoints
-) reduce log_buffer size
-) Decrease run-time performance

Oracle 10G Checkpoint not complete Cannot allocate new log

We have an oracle 10G database that has 4 groups of 200M redo logs. We are constantly seeing Checkpoint not complete followed by Cannot allocate new log.. messages in the alert log. When I look at the v$instance_recovery table I see this:
SQL> select WRITES_MTTR, WRITES_LOGFILE_SIZE, WRITES_LOG_CHECKPOINT_SETTINGS, WRITES_OTHER_SETTINGS,
2 WRITES_AUTOTUNE, WRITES_FULL_THREAD_CKPT from v$instance_recovery;
WRITES_MTTR WRITES_LOGFILE_SIZE WRITES_LOG_CHECKPOINT_SETTINGS
WRITES_OTHER_SETTINGS WRITES_AUTOTUNE WRITES_FULL_THREAD_CKPT
0 0 66329842
0 309461 41004
It seems most of our checkpointing is being caused by the log_checkpoint_interval being set to 10000, which means we are doing 20 checkpoints during one redo log since our OS blocksize is 1024. What I'm thinking about doing is first adding two more redo log groups, and then either increasing the log_checkpoint_interval to 40000 (5 checkpoints for one redo log) or unsetting log_checkpoint_interval and setting fast_start_mttr_target to 600. Which would be the recommended parameter change? I think Oracle recommends using the fast_start_mttr_target. Are there any other suggestions?

Hi
>>unsetting log_checkpoint_interval and setting fast_start_mttr_target to 600.
its a better idea,look on it
http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams068.htm#REFRN10058
Just set fast_start_mttr_target parameter.it will resolve ur problem.
Thanks
Kuljeet

Increased logfile size and now get cannot allocate new log

Because we were archiving up to 6 and 7 times per minute, I increased our logfiles from size from 13M to 150M. I also increased the number of groups from 3 to 5.
Because we want to ensure recoverability within a certain timeframe, I also have a script that runs every 15 minutes and issues 2 commands: ALTER SYSTEM SWITCH LOGFILE; and ALTER SYSTEM CHECKPOINT;
I am now seeing in my alert.log file the following, almost every time we do a log switch.
Thread 1 cannot allocate new log, sequence 12380
Private strand flush not complete
No other changes have been made to the database.
Why would this now be doing this?
Should I not be doing both the ALTER SYSTEM SWITCH LOGFILE and the ALTER SYSTEM CHECKPOINT?
Is there something else I should be looking at?
Any suggestions/answers would be greatly appreciated.
Db version: 11.1.0.7
OS: OEL 5.5

Set the FAST_START_MTTR_TARGET parameter to the instance recovery time in seconds that you want...
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=upto 10; this will make sure that the redo logs are copied faster....
The sizing redo log files can influence performance because DBWR, LGWR and ARCH are all working during high DML periods.
A too small online redo log file size can cause slowdowns from excessive DBWR and checkpointing behavior. A high checkpointing frequency and the "log file switch (checkpoint incomplete) can also cause slowdowns.
Add additional log writer processes (LGWR).
Ensure that the archived redo log filesystem resides on a separate physical disk spindle.
Put the archived redo log filesystem on super-fast solid-state disks.

Redo log tuning - improving insert rate

Dear experts!
We've an OLTP system which produces large amount of data. After each record written to our 11.2 database (standard edition) a commit is performed (the system architecture can't be changed - for example to commit every 10th record).
So how can we speed up the insert process? As the database in front of the system gets "mirrored" to our datawarehouse system it is running in NOARCHIVE mode. I've already tried placing the redo log files on SSD disks which speeded up the insert process.
Another idea is putting the table on a seperate tablespace with NOLOGGING option. What do you think about this?
Further more I heard about tuning the redo latches parameter. Does anyone have information about this way?
I would be grateful for any information!
Thanks
Markus

We've an OLTP system which produces large amount of data. After each record written to our 11.2 database (standard edition) a commit is >>performed (the system architecture can't be changed - for example to commit every 10th record).Doing commit after each insert (or other DML command) doesn't means that dbwriter process is actually writing this data immediately in db files.
DBWriter process is using an internal algorithm to decide where to apply changes to db files. You can adjust the writing frequency into db files by using "fast_start_mttr_target" parameter.
So how can we speed up the insert process? As the database in front of the system gets "mirrored" to our datawarehouse system it is running >>in NOARCHIVE mode. I've already tried placing the redo log files on SSD disks which speeded up the insert process.Placing the redo log files on SSD disks is indeed a good action. Also you can check buffer cache hit rate and size. Also stripping for filesystems where redo files resides should be taken into account.
Another idea is putting the table on a seperate tablespace with NOLOGGING option. What do you think about this?It's an extremely bad idea. NOLOGGING option for a tablespace will lead to an unrecovearble tablespace and as I stated on first sentence will not increase the insert speed.
Further more I heard about tuning the redo latches parameter. Does anyone have information about this way?I don't think you need this.
Better check indexes associated with tables where you insert data. Are they analyzed regularly, are all of them used indeed (many indexes are created for some queries but after a while they are left unused but at each DML all indexes are updated as well).

Sizing the redo log files using optimal_logfile_size view.

Regards
I have a specific question regarding logfile size. I have deployed a test database and i was exploring certain aspects with regards to selecting optimal size of redo logs for performance tuning using optimal_logfile_size view from v$instance_recovery. My main goal is to reduce the redo bytes required for instance recovery. Currently i have not been able to optimize the redo log file size. Here are the steps i followed:-
In order to use the advisory from v$instance_recovery i had to set fast_start_mttr_target parameter which is by default not set so i did these steps:-
1)SQL> sho parameter fast_start_mttr_target;
NAME TYPE VALUE
fast_start_mttr_target integer 0
2) Setting the fast_start_mttr_target requires nullifying following deferred parameters :-
SQL> show parameter log_checkpoint;
NAME TYPE VALUE
log_checkpoint_interval integer 0
log_checkpoint_timeout integer 1800
log_checkpoints_to_alert boolean FALSE
SQL> select ISSES_MODIFIABLE,ISSYS_MODIFIABLE,ISINSTANCE_MODIFIABLE,ISMODIFIED from v$parameter where name like'log_checkpoint_timeout';
ISSES_MODIFIABL ISSYS_MODIFIABLE ISINSTANCE_MODI ISMODIFIED
FALSE IMMEDIATE TRUE FALSE
SQL> alter system set log_checkpoint_timeout=0 scope=both;
System altered.
SQL> show parameter log_checkpoint_timeout;
NAME TYPE VALUE
log_checkpoint_timeout integer 0
3) Now setting fast_start_mttr_target
SQL> select ISSES_MODIFIABLE,ISSYS_MODIFIABLE,ISINSTANCE_MODIFIABLE,ISMODIFIED from v$parameter where name like'fast_start_mttr_target';
ISSES_MODIFIABL ISSYS_MODIFIABLE ISINSTANCE_MODI ISMODIFIED
FALSE IMMEDIATE TRUE FALSE
Setting the fast_mttr_target to 1200 = 20 minutes of checkpoint switching according to Oracle recommendation
Querying the v$instance_recovery view
4) SQL> select ACTUAL_REDO_BLKS,TARGET_REDO_BLKS,TARGET_MTTR,ESTIMATED_MTTR, OPTIMAL_LOGFILE_SIZE,CKPT_BLOCK_WRITES from v$instance_recovery;
ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE CKPT_BLOCK_WRITES
276 165888 *93* 59 361 16040
Here Target Mttr was 93 so i set the fast_mttr_target to 120
SQL> alter system set fast_start_mttr_target=120 scope=both;
System altered.
Now the logfile size suggested by v$instance_recovery is 290 Mb
SQL> select ACTUAL_REDO_BLKS,TARGET_REDO_BLKS,TARGET_MTTR,ESTIMATED_MTTR, OPTIMAL_LOGFILE_SIZE,CKPT_BLOCK_WRITES from v$instance_recovery;
ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE CKPT_BLOCK_WRITES
59 165888 93 59 290 16080
After altering the logfile size to 290 as show below by v$log view :-
SQL> select GROUP#,THREAD#,SEQUENCE#,BYTES from v$log;
GROUP# THREAD# SEQUENCE# BYTES
1 1 24 304087040
2 1 0 304087040
3 1 0 304087040
4 1 0 304087040
5 ) After altering the size i have observed the anomaly as redo log blocks to be applied for recovery has increased from *59 to 696* also now v$instance_recovery view is now suggesting the logfile size of *276 mb*. Have i misunderstood something
SQL> select ACTUAL_REDO_BLKS,TARGET_REDO_BLKS,TARGET_MTTR,ESTIMATED_MTTR, OPTIMAL_LOGFILE_SIZE,CKPT_BLOCK_WRITES from v$instance_recovery;
ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE CKPT_BLOCK_WRITES
*696* 646947 120 59 *276* 18474
Please clarify the above output i am unable to optimize the logfile size and have not been able to achieve the goal of reducing the redo log blocks to be applied for recovery, any help is appreciated in this regard.

sunny_123 wrote:
Sir oracle says that fast_start_mttr target can be set to 3600 = 1hour. As suggested by following oracle document
http://docs.oracle.com/cd/B10500_01/server.920/a96533/instreco.htm
I set mine value to 1200 = 20 minutes. Later i adjusted it to 120=2 minutes as Target_mttr suggested it to be around 100 (if fast_mttr_target value is too high or too low effective value is contained in target_mttr of v$instance_recovery)Just to add, you are reading the documentation of 9.2 and a lot has changed since then. For example, in 9.2 the parameter FSMTTR was introduced and explicitly required to be set and monitored by the DBA for teh additional checkpoint writes which might get caused by it. Since 10g onwards this parameter has been made automatically maintained by Oracle. Also it's been long that 9i has been desupported followed by 10g so it's better that you start reading the latest documentation of 11g and if not that, at least of 10.2.
Aman....

How to reduce redo space wait

os:x86_64 x86_64 x86_64 GNU/Linux
oracle:9.2.0.6
running : Data guard
Problem : Redo space wait is very high
Init.ora paramaeters
*.background_dump_dest='/u01/app/oracle/admin/PBPR01/bdump'
*.compatible='9.2.0'
*.control_files='/s410/oradata/PBPR01/control01.ctl','/s420/oradata/PBPR01/control02.ctl','/s430/oradata/PBPR01/control03.ctl'
*.core_dump_dest='/u01/app/oracle/admin/PBPR01/cdump'
*.cursor_space_for_time=true
*.db_block_size=8192
*.db_cache_size=576000000
*.db_domain='cc.com'
*.db_file_multiblock_read_count=16
*.db_files=150
*.db_name='PBPR01'
*.db_writer_processes=1
*.dbwr_io_slaves=2
*.disk_asynch_io=false
*.fast_start_mttr_target=1800
*.java_pool_size=10485760
*.job_queue_processes=5
*.log_archive_dest_1='LOCATION=/s470/oraarch/PBPR01'
*.log_archive_dest_3='service=DR_PBPR01 LGWR ASYNC=20480'
*.log_archive_format='PBPR01_%t_%s.arc'
*.log_archive_start=true
*.log_buffer=524288
*.log_checkpoints_to_alert=true
*.max_dump_file_size='500000'
*.object_cache_max_size_percent=20
*.object_cache_optimal_size=512000
*.open_cursors=500
*.optimizer_mode='CHOOSE'
*.processes=500
*.pga_aggregate_target=414187520
*.replication_dependency_tracking=false
*.undo_management=AUTO
*.undo_retention=10800
*.undo_tablespace=UNDOTBS1
*.undo_suppress_errors=TRUE
*.session_cached_cursors=20
*.shared_pool_size=450000000
*.user_dump_dest='/u01/app/oracle/admin/PBPR01/udump'
SGA :
SQL> show sga
Total System Global Area 1108839248 bytes
Fixed Size 744272 bytes
Variable Size 520093696 bytes
Database Buffers 587202560 bytes
Redo Buffers 798720 bytes
SQL>
I created log groups with 2 memebers each and with size 25 mb.
Redo space waits shows as
SQL> SELECT name, value
FROM v$sysstat
WHERE name = 'redo log space requests';
NAME VALUE
redo log space requests 152797
this is running between 140000 and 160000
some of the trace file error
[oracle@hipclora6b bdump]$ cat PBPR01_lns0_23689.trc
Dump file /u01/app/oracle/admin/PBPR01/bdump/PBPR01_lns0_23689.trc
Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production
ORACLE_HOME = /u01/app/oracle/product/9.2.0.6
System name: Linux
Node name: hipclora6b.clickipc.hipc.clickcommerce.com
Release: 2.4.21-37.EL
Version: #1 SMP Wed Sep 7 13:32:18 EDT 2005
Machine: x86_64
Instance name: PBPR01
Redo thread mounted by this instance: 1
Oracle process number: 34
Unix process pid: 23689, image: [email protected]
*** SESSION ID:(82.51071) 2008-04-14 23:40:04.122
*** 2008-04-14 23:40:04.122 46512 kcrr.c
NetServer 0: initializing for LGWR communication
NetServer 0: connecting to KSR channel
: success
NetServer 0: subscribing to KSR channel
: success
*** 2008-04-14 23:40:04.162 46559 kcrr.c
NetServer 0: initialized successfully
*** 2008-04-14 23:40:04.172 46819 kcrr.c
NetServer 0: Request to Perform KCRRNSUPIAHM
NetServer 0: connecting to remote destination DR_PBPR01
*** 2008-04-14 23:40:04.412 46866 kcrr.c
NetServer 0: connect status = 0
A Sample alert Log
Thread 1 advanced to log sequence 275496
Current log# 1 seq# 275496 mem# 0: /s420/oradata/PBPR01/redo01a.log
Current log# 1 seq# 275496 mem# 1: /s420/oradata/PBPR01/redo01b.log
Tue Apr 15 09:10:03 2008
ARC0: Evaluating archive log 4 thread 1 sequence 275495
ARC0: Archive destination LOG_ARCHIVE_DEST_3: Previously completed
ARC0: Beginning to archive log 4 thread 1 sequence 275495
Creating archive destination LOG_ARCHIVE_DEST_1: '/s470/oraarch/PBPR01/PBPR01_1_275495.arc'
Tue Apr 15 09:10:03 2008
Beginning global checkpoint up to RBA [0x43428.3.10], SCN: 0x0000.3c1594fd
Completed checkpoint up to RBA [0x43428.2.10], SCN: 0x0000.3c1594fa
Completed checkpoint up to RBA [0x43428.3.10], SCN: 0x0000.3c1594fd
Tue Apr 15 09:10:03 2008
ARC0: Completed archiving log 4 thread 1 sequence 275495
Tue Apr 15 09:29:15 2008
LGWR: Completed archiving log 1 thread 1 sequence 275496
Creating archive destination LOG_ARCHIVE_DEST_3: 'DR_PBPR01'
LGWR: Beginning to archive log 5 thread 1 sequence 275497
Beginning log switch checkpoint up to RBA [0x43429.2.10], SCN: 0x0000.3c15bc33
Tue Apr 15 09:29:16 2008
ARC1: Evaluating archive log 1 thread 1 sequence 275496
ARC1: Archive destination LOG_ARCHIVE_DEST_3: Previously completed
ARC1: Beginning to archive log 1 thread 1 sequence 275496
Creating archive destination LOG_ARCHIVE_DEST_1: '/s470/oraarch/PBPR01/PBPR01_1_275496.arc'
Tue Apr 15 09:29:16 2008
Thread 1 advanced to log sequence 275497
Current log# 5 seq# 275497 mem# 0: /s420/oradata/PBPR01/redo05a.log
Current log# 5 seq# 275497 mem# 1: /s420/oradata/PBPR01/redo05b.log
Tue Apr 15 09:29:16 2008
ARC1: Completed archiving log 1 thread 1 sequence 275496
Log file size
SQL> select GROUP#,MEMBERS ,sum(bytes)/(1024*1024) from v$log group by
2 GROUP#,MEMBERS;
GROUP# MEMBERS SUM(BYTES)/(1024*1024)
1 2 25
2 2 25
3 2 25
4 2 25
5 2 25
Pl. give your view what can be thought of to reduce redospace wait

Below are my suggestion:
Increase log buffer between [ 5Mb and 15Mb]
differ the the commit: COMMIT_WRITE=NOWAIT,BATCH
You can also increase your redo log fil, but read the following
Sizing Redo Logs with Oracle 10g
Oracle has introduced a Redo Logfile Sizing Advisor that will recommend a size for our redo logs that limit excessive log switches, incomplete and excessive checkpoints, log archiving issues, DBWR performance and excessive disk I/O. All these issues result in transactions bottlenecking within redo and performance degradation. While many DBAs' first thought is throughput of the transaction base, not very many give thought to the recovery time required in relation to the size of redo generated or the actual size of the redo log groups. With the introduction of Oracle's Mean Time to Recovery features, DBAs can now specify through the FAST_START_MTTR_TARGET initialization variable just how long a crash recovery should take. Oracle will then try its best to issue the proper checkpoints during normal system operation to help meet this target. Since the size of redo logs and the checkpointing of data have a key role in Oracle's ability to recover within a desired time frame, Oracle will now use the value of FAST_START_MTTR_TARGET to suggest an optimal redo log size. In actuality, the setting of FAST_START_MTTR_TARGET is what triggers the new redo logfile sizing advisor, and if you do not set it, Oracle will not provide a suggestion for your redo logs. If you do not have any real time requirement for recovery you should at least set this to its maximum value of 3600 seconds, or one hour and you will then be able to take advantage of the advisory. After setting the FAST_START_MTTR_TARGET initialization parameter a DBA need only query the V$INSTANCE_RECOVERY view for the column OPTIMAL_LOGFILE_SIZE value, in MEG, and then rebuild the redo log groups with this recommendation.
Simple query to show the optimal size for redo logs
SQL> SELECT OPTIMAL_LOGFILE_SIZE
FROM V$INSTANCE_RECOVERY
OPTIMAL_LOGFILE_SIZE
64
A few notes about setting FAST_START_MTTR_TARGET
•     Specify a value in seconds (0-3600) that you wish Oracle to perform recovery within.
•     Is overridden by LOG_CHECKPOINT_INTERVAL:
Since LOG_CHECKPOINT_INTERVAL requests Oracle to checkpoint after a specified amount of redo blocks have been written, and FAST_START_MTTR_TARGET basically attempts to size the redo logs in such a way as to perform a checkpoint when they switch, you can easily see that these two parameters are of conflicting interest. You will need to unset LOG_CHECKPOINT_INTERVAL if you wish to use the redo log sizing advisor and have checkpoints occur with log switches. This is how it was recommended to be done in the v7 days and really I can't quite see any reason for anything else.
•     Is overridden by LOG_CHECKPOINT_TIMEOUT:
LOG_CHECKPOINT_TIMEOUT controls the amount of time in between checkpoints if a log switch or the amount of redo generated has not yet triggered a checkpoint. Since our focus is now on Mean Time to Recovery (MTTR) this parameter is no longer of concern because we are asking Oracle to determine when to checkpoint based on our crash recovery requirements.
•     Is overridden by FAST_START_IO_TARGET:
Actually, the FAST_START_IO_TARGET parameter is deprecated and you should switch over to the FAST_START_MTTR_TARGET parameter
Thanks

FAST_START_MTTR_TARGET parameter advice

Similar Messages

Maybe you are looking for