Setting fast_start_mttr_target on 10.2.0.4

Hi there,
Can anyone please tell me how to set fast_start_mttr_target on 10.2.0.4. In 10g, by setting this parameter we override log_checkpoint_timeout. By doing so, we will have only incremental checkpoints. Does a higher value of fast_start_mttr_target cause more checkpoints causing DBWR slowness? On what basis do we set this value. Obviously, we want any production database to recover from crash ASAP. Can we set this parameter to 150 seconds for 2 TB size database and also for 200 GB size database? What are the implications of having low and high fast_start_mttr_target? Any guidelines?
Thanks,
Madhav

In 10g, by setting this parameter we override log_checkpoint_timeoutWrong - at least [per docs|http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams068.htm#REFRN10058]:
When specified, FAST_START_MTTR_TARGET is overridden by LOG_CHECKPOINT_INTERVAL.
By doing so, we will have only incremental checkpointsNo, not only. Normal checkpointing during log switch isn't vanished.
Does a higher value of fast_start_mttr_target cause more checkpoints causing DBWR slowness?Exactly opposite: with higher value FSMT DB will perform less incremental checkpointing.
Can we set this parameter to 150 seconds for 2 TB size database and also for 200 GB size database?Yes, why not?
What are the implications of having low and high fast_start_mttr_target? Any guidelines?Low FSMT == you want your DB to sync data in buffer cache with data on disk very frequently, i.e. more frequent incremental checkpoints and less time to recover (as abbreviation says: MTTR - mean time to recover)
High FSMT == you are allowed to wait for instance recovery and this time is not a big deal for you.
It is discussed in documentation in details.

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;

Set fast_start_mttr_target

Hello All,
I am using Oracle 11gR2 (11.2.0.3).
I want to select the value optimal_logfile_size from v$instance_recovery.
To do that i need to set the parameter fast_start_mttr_target.
My question is there any disadvantage of setting this parameter? is there anything that should be taken into consideration?
Regards,

The site you're referring to is a commercial site.
I would do some other searches as well, for example:
"The FAST_START_IO_TARGET, LOG_CHECKPOINT_INTERVAL and LOG_CHECKPOINT_TIMEOUT parameters should not be set as they may interfere with the process.
The FAST_START_IO_TARGET initialization parameter is used to specify the maximum number of dirty blocks in the buffer cache. Its use has been deprecated in favour of the FAST_START_MTTR_TARGET." (Oracle 9i)
http://www.oracle-base.com/articles/9i/recovery-enhancements-9i.php#Fast-StartTime-BasedRecovery
You can find some other perhaps useful threads on http://asktom.oracle.com
for example: http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:767225834393#41500913648750
should i set LOG_CHECKPOINT_TIMEOUT to 0 also ?Yes. Disable or remove them.
See also: http://docs.oracle.com/cd/E11882_01/server.112/e16638/instance_tune.htm#PFGRF13014

FAST_START_MTTR_TARGET & Redo Log Advisor in 10g Standard Edition

OS: Oracle Enterprise Linux 5 Update 2 (64-bit)
DB: 10.2.0.4
I've been trying to set the FAST_START_MTTR_TARGET in my 10.2.0.4 Standard Edition database. As well as wanting the value set for recovery reasons, I'd also like to use the Redo Advisor Log to determine the best size for my redo logs.
[oracle@scgamadb01pl ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Thu Oct 16 15:04:32 2008 Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
SQL> ALTER SYSTEM SET fast_start_mttr_target=300;
ALTER SYSTEM SET fast_start_mttr_target=300
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-00439: feature not enabled: Fast-Start Fault RecoveryOracle Support tells me that Fast-Start Fault Recovery is not available in 10g Standard Edition so I'm unable to set FAST_START_MTTR_TARGET. I'm confused because in my 9i Standard Edition iinstance I have the value set and can adjust it.
Has anybody else run into this? Is there a workaround other than manually adjusting all the checkpoint-related parameters?

In 9i, it's also not suppose to be working for SE
Oracle either ignored the parameter or it's a bug not detecting the setting.
http://download.oracle.com/docs/cd/B10501_01/server.920/a96531/ch5_edit.htm#66165
You can use LOG_CHECKPOINT_INTERVAL instead
http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams109.htm#REFRN10095

Configuring FAST_START_MTTR_TARGET !!

Hi, all.
I have a 2 node RAC database on windows 2003 EE SP1.
I am getting the following message from an alert log file.
Mon Aug 27 07:59:57 2007
Thread 2 advanced to log sequence 698
Current log# 6 seq# 698 mem# 0: \\.\REDO221
Current log# 6 seq# 698 mem# 1: \\.\REDO222
Thread 2 cannot allocate new log, sequence 699 (<-- ●)
Checkpoint not complete
Current log# 6 seq# 698 mem# 0: \\.\REDO221
Current log# 6 seq# 698 mem# 1: \\.\REDO222
The following is the result of "select * from v$log".
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARCHIVED STATUS
1 1 699 2097152000 2 YES ACTIVE
2 1 701 2097152000 2 YES ACTIVE
3 1 702 2097152000 2 NO CURRENT
4 1 700 2097152000 2 YES ACTIVE
5 2 697 2097152000 2 YES ACTIVE
6 2 698 2097152000 2 NO CURRENT
7 2 695 2097152000 2 YES ACTIVE
8 2 696 2097152000 2 YES ACTIVE
As you see in the aboves, one redo group is current and all others are active status. Thus, the operations related to logswich is being failed.
FAST_START_MTTR_TARGET is effective for the above issue?
And what is FAST_START_IO_TARGET for?
Thanks and Regards.
Message was edited by:
user507290

Assuming you are using Oralce 10g, this version has self tune checkpointing capabilities if FAST_START_MTTR_TARGET is set to a non-zero value. FAST_START_IO_TARGET is used in 8i to reduce MTTR. Setting FAST_START_MTTR_TARGET to a low value makes checkpointing more aggressive. Increasing the size of the redo logs or add another redo log member may solve your problem. Your error could be caused due to a large transaction spanning multiple redo logs.

"FAST_START_MTTR_TARGET " vs "log_checkpoint_timeout"

Dear Friends,
I know that when I configure FAST_START_MTTR_TARGET , then it should be disable the "log_checkpoint_timeout " parameter , i.e, "log_checkpoint_timeout=0" .Is it mean that , "FAST_START_MTTR_TARGET" parameters works for "log_checkpoint_timeout" parameter ?
If it is true then my question is , If I set FAST_START_MTTR_TARGET=600, (which helps to perform crash recovery of a single instance within 600 seconds) then what will be the minimum time to occur a checkpoint, since "log_checkpoint_timeout=0" .
I think u understand my question .
Thx .. . .. . .

Well you need to look back in the history ,
Log_checkpoint_timeout
This is the time that is after the last checkpoint which has occurred. So , for example, if the last checkpoint occurred 10seconds before, with value of 10 for this parameter, another will occur after 10 seconds.
Log_checkpoint_interval
This is the number of blocks that could exist between one increemntal checkpoint and the last block which is written to the redo log.
It was a little cumbersome to get a balance between the two parameters. So oracle decided to make them club together and gave , Fast_start_mttr_Target. This was a more simple one. Now you mentioned that the other parameter should be disabled. Well , just so you know, the other two are still there and are perfectly valid even. The only issue is if you are going to set anyone of them, they override the FSMT parameter. That's why it is suggested that you use only the new parameter and not the old one.
This parameter basically governs that for how much time, a dirty buffer can stay in the cache. AFter that time period, with the incrementbacl checkpointing kicking in, this would be flushed out to the data files. The more faster instanace recovery can happen only when there are minimal number of blocks left over for being recovered. This incremental checkpointing algorithm helps in achieving that. So if you set the value of this to 600seconds, the incremntal checkpoint will occur after these many seconds. Now just remember one more thing that this is not the "only" point or event to make the checkpoint happen. It may happen due to various other factors as well for example LRUW list become full.
Though this parameter was designed to optimize the performance of instance recovery but this is not so easy. The parameter shoots up the physical ios which are there becaus of the checkpointing. The more higher writes to the datafile , the less number of blocks to be recovered. But the more higher writes, more IO and more slow you can be. So from oracle 10.2(if I am correct) , oracle has taken away the control from you. Now this parameter is "auto-tuned" depending on the workload of the system.
HTH
Aman....

FAST_START_MTTR_TARGET and checkpoint

DB version : 11.2
If I set
FAST_START_MTTR_TARGET=0
LOG_CHECKPOINT_INTERVAL=0
LOG_CHECKPOINT_TIMEOUT=1800Then how often does checkpoint occurs ? -- ignoring Manual log switch and ALTER SYSTEM CHECKPOINT command

TeslaMan wrote:
DB version : 11.2
If I set
FAST_START_MTTR_TARGET=0
LOG_CHECKPOINT_INTERVAL=0
LOG_CHECKPOINT_TIMEOUT=1800Then how often does checkpoint occurs ? -- ignoring Manual log switch and ALTER SYSTEM CHECKPOINT commandThese parameter affects the checkpoints, but if you are thinking that why checkpoint occurs when I am having above setting then, you are bit confused, because happening of checkpoint is another thing and having the values of the above parameter is different. When your current redo log becomes full, then there will be logswitch and logswitch is the cause of checkpoint. Checkpoint automatically occurs at a log switch.
Now if the question is why there is so much log switch, then simple answer is generation of more redo, more transactions. Further question turns into different direction that why there is more redo generation and its answer is far away from this current one.
Regards
Girish Sharma

FAST_START_MTTR_TARGET - Optimal File Size

I have set Fast_Start_MTTR_Target to 3600 (1 hour)...when I query v$instance_recovery view it says that 17929 MB is my suggested log file size. They are now sized at 300MB. This can't be correct, can it? I can't have a 17GB log file. This is Oracle JD Edwards though....but what else should I look at? I know 300MB is too small.

kirkladb wrote:
I have set Fast_Start_MTTR_Target to 3600 (1 hour)...when I query v$instance_recovery view it says that 17929 MB is my suggested log file size. They are now sized at 300MB. This can't be correct, can it? I can't have a 17GB log file. This is Oracle JD Edwards though....but what else should I look at? I know 300MB is too small. I Beleieve you have to FSMT to too high value i.e 1hr. I dont think you will wait your database to startup after instance crash for 1hr?????? This is i believe is not a gud settings. I would rather go with default value initially
Now you have set FSMT to 1hr and oracle would think that it has to do incremental checkpoint after 1hr (to flush dirty block from buffer cache to disk) . So due to this configuration you are seeing too high value in v$instance_recovery i.e 17929.
Please be notes that value of Optimal_logfile_size is very dynamic in nature and changes its value depending upon the load on system. So you cannot basically rely on this value if your system experience dynamic load.
Looking upon Load in database and amount of redolog file switches per sec/min, If they happen to be too frequent for example 2-3logfile switches per 20 mins, then its considered to be overswitching. Oracle recommends for optimal performance every logfile switch should not happen before 15-20 mins.
So good approach is to first see your alert.log and find out that how many log switches are happening then take a decision to increase the logfile size.
Please check with your organization what they suggest how much time they need to wait while instance do its recovery and then change value from default to higher.
Edited by: 909592 on Mar 29, 2012 11:45 AM

Oracle 10G New Feature........Part 1

Dear all,
from last couple of days i was very busy with my oracle 10g box,so i think this is right time to
share some intresting feature on 10g and some internal stuff with all of you.
Have a look :-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Oracle 10g Memory and Storage Feature.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1.Automatic Memory Management.
2.Online Segment Shrink
3.Redolog Advisor, checkpointing
4.Multiple Temporary tablespace.
5.Automatic Workload Repository
6.Active Session History
7.Misc
a)Rename Tablespace
b)Bigfile tablespace
c)flushing buffer cache
8.ORACLE INTERNAL
a)undocumented parameter (_log_blocks_during_backup)
b)X$ view (x$messages view)
c)Internal Structure of Controlfile
1.Automatic memory management
================================
This feature reduce the overhead of oracle DBA.previously mostly time we need to set diff oracle SGA parameter for
better performance with the help of own experience,advice views and by monitoring the behaviour
of oracle database.
this was just time consuming activity.........
Now this feature makes easy life for oracle DBA.
Just set SGA_TARGET parameter and it automatically allocate memory to different SGA parameter.
it focus on DB_CACHE_SIZE
SHARED_POOL_SIZE
LARGE_POOL
JAVA_POOL
and automatically set it as
__db_cache_size
__shared_pool_size
__large_pool_size
__java_pool_size
check it in alert_log
MMAN(memory manager) process is new in 10g and this is responsible for sga tuning task.
it automatically increase and decrease the SGA parameters value as per the requirement.
Benefit:- Maximum utlization of available SGA memory.
2.Online Segment Shrink.
==========================
hmmmmm again a new feature by oracle to reduce the downtime.Now oracle mainly focus on availablity
thats why its always try to reduce the downtime by intrducing new feature.
in previous version ,reducing High water mark of table was possible by
Exp/imp
or
alter table move....cmd. but on these method tables was not available for normal use for long hrs if it has more data.
but in 10g with just few command we can reduce the HWmark of table.
this feature is available for ASSM tablespaces.
1.alter table emp enable row movement.
2.alter table emp shrink space.
the second cmd have two phases
first phase is to compact the segment and in this phase DML operations are allowed.
second phase(shrink phase)oracle shrink the HWM of table, DML operation will be blocked at that time for short duration.
So if want to shrink the HWM of table then we should use it with two diff command
first compact the segment and then shrink it on non-peak hrs.
alter table emp shrink space compact. (This cmd doesn't block the DML operation.)
and alter table emp shrink space. (This cmd should be on non-peak hrs.)
Benefit:- better full table scan.
3.Redolog Advisor and checkpointing
================================================================
now oracle will suggest the size of redo log file by V$INSTANCE_RECOVERY
SELECT OPTIMAL_LOGFILE_SIZE
FROM V$INSTANCE_RECOVERY
this value is influence with the value of FAST_START_MTTR_TARGET .
Checkpointing
Automatic checkpointing will be enable after setting FAST_START_MTTR_TARGET to non-zero value.
4.Multiple Temporary tablespace.
==================================
Now we can manage multiple temp tablespace under one group.
we can create a tablespace group implicitly when we include the TABLESPACE GROUP clause in the CREATE TEMPORARY TABLESPACE or ALTER TABLESPACE statement and the specified tablespace group does not currently exist.
For example, if group1 is not exists,then the following statements create this groups with new tablespace
CREATE TEMPORARY TABLESPACE temp1 TEMPFILE '/u02/oracle/data/temp01.dbf'
SIZE 50M
TABLESPACE GROUP group1;
--Add Existing temp tablespace into group by
alter tablespace temp2 tablespace group group1.
--we can also assign the temp tablespace group on database level as default temp tablespace.
ALTER DATABASE <db name> DEFAULT TEMPORARY TABLESPACE group1;
benefit:- Better I/O
One sql can use more then one temp tablespace
5.AWR(Automatic Workload Repository):-
================================== AWR is built in Repository and Central point of Oracle 10g.Oracle self managing activities
is fully dependent on AWR.by default after 1 hr, oracle capure all database uses information and store in AWR with the help of
MMON process.we called it Memory monitor process.and all these information are kept upto 7 days(default) and after that it automatically purge.
we can generate a AWR report by
SQL> @?/rdbms/admin/awrrpt
Just like statspack report but its a advance and diff version of statspack,it provide more information of Database as well as OS.
it show report in Html and Text format.
we can also take manually snapshot for AWR by
BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
END;
**The STATISTICS_LEVEL initialization parameter must be set to the TYPICAL or ALL to enable the Automatic Workload Repository.
[oracle@RMSORA1 oracle]$ sqlplus / as sysdba
SQL*Plus: Release 10.1.0.2.0 - Production on Fri Mar 17 10:37:22 2006
Copyright (c) 1982, 2004, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> @?/rdbms/admin/awrrpt
Current Instance
~~~~~~~~~~~~~~~~
DB Id DB Name Inst Num Instance
4174002554 RMSORA 1 rmsora
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Would you like an HTML report, or a plain text report?
Enter 'html' for an HTML report, or 'text' for plain text
Defaults to 'html'
Enter value for report_type: text
Type Specified: text
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name Instance Host
* 4174002554 1 RMSORA rmsora RMSORA1
Using 4174002554 for database Id
Using 1 for instance number
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing <return> without
specifying a number lists all completed snapshots.
Listing the last 3 days of Completed Snapshots
Snap
Instance DB Name Snap Id Snap Started Level
rmsora RMSORA 16186 16 Mar 2006 17:33 1
16187 16 Mar 2006 18:00 1
16206 17 Mar 2006 03:30 1
16207 17 Mar 2006 04:00 1
16208 17 Mar 2006 04:30 1
16209 17 Mar 2006 05:00 1
16210 17 Mar 2006 05:31 1
16211 17 Mar 2006 06:00 1
16212 17 Mar 2006 06:30 1
16213 17 Mar 2006 07:00 1
16214 17 Mar 2006 07:30 1
16215 17 Mar 2006 08:01 1
16216 17 Mar 2006 08:30 1
16217 17 Mar 2006 09:00 1
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 16216
Begin Snapshot Id specified: 16216
Enter value for end_snap: 16217
End Snapshot Id specified: 16217
Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is awrrpt_1_16216_16217.txt. To use this name,
press <return> to continue, otherwise enter an alternative.
Benefit:- Now DBA have more free time to play games.....................:-)
Advance version of statspack
more DB and OS information with self managing capabilty
New Automatic alert and database advisor with the help of AWR.
6.Active Session History:-
==========================
V$active_session_history is view that contain the recent session history.
the memory for ASH is comes from SGA and it can't more then 5% of Shared pool.
So we can get latest and active session report from v$active_session_history view and also get histortical data of
of session from DBA_HIST_ACTIVE_SESS_HISTORY.
v$active_session_history include some imp column like:-
~SQL identifier of SQL statement
~Object number, file number, and block number
~Wait event identifier and parameters
~Session identifier and session serial number
~Module and action name
~Client identifier of the session
7.Misc:-
========
Rename Tablespace:-
=================
in 10g,we can even rename a tablespace by
alter tablespace <tb_name> rename to <tb_name_new>;
This command will update the controlfile,data dictionary and datafile header,but dbf filename will be same.
**we can't rename system and sysaux tablespace.
Bigfile tablespace:-
====================
Bigfile tablespace contain only one datafile.
A bigfile tablespace with 8K blocks can contain a 32 terabyte datafile.
Bigfile tablespaces are supported only for locally managed tablespaces with automatic segment-space management.
we can take the advantage of bigfile tablespace when we are using ASM or other logical volume with RAID.
without ASM or RAID ,it gives poor response.
syntax:-
CREATE BIGFILE TABLESPACE bigtbs
Flushing Buffer Cache:-
======================
This option is same as flushing the shared pool,but only available with 10g.
but i don't know, whats the use of this command in prod database......
anyway we can check and try it on test server for tuning n testing some query etc....
SQL> alter system flush buffer_cache;
System altered.
++++++++++++++++++
8.Oracle Internal
++++++++++++++++++
Here is some stuff that is not related with 10g but have some intresting things.
a)undocumented parameter "_log_blocks_during_backup"
++++++++++++++++++++++++
as we know that oracle has generate more redo logs during hotbackup mode because
oracle has to maintain the a complete copy of block into redolog due to split block.
we can also change this behaviour by setting this parameter to False.
If Oracle block size equals the operating system block size.thus reducing the amount of redo generated
during a hot backup.
WITHOUT ORACLE SUPPORT DON'T SET IT ON PROD DATABASE.THIS DOCUMENT IS JUST FOR INFORMATIONAL PURPOSE.
b)some X$ views (X$messages)
++++++++++++++++
if you are intresting in oracle internal architecture then x$ view is right place for getting some intresting things.
X$messages :-it show all the actions that a background process do.
select * from x$messages;
like:-
lock memory at startup MMAN
Memory Management MMAN
Handle sga_target resize MMAN
Reset advisory pool when advisory turned ON MMAN
Complete deferred initialization of components MMAN
lock memory timeout action MMAN
tune undo retention MMNL
MMNL Periodic MQL Selector MMNL
ASH Sampler (KEWA) MMNL
MMON SWRF Raw Metrics Capture MMNL
reload failed KSPD callbacks MMON
SGA memory tuning MMON
background recovery area alert action MMON
Flashback Marker MMON
tablespace alert monitor MMON
Open/close flashback thread RVWR
RVWR IO's RVWR
kfcl instance recovery SMON
c)Internal Structure of Controlfile
++++++++++++++++++++++++++++++++++++
The contents of the current controlfile can be dumped in text form.
Dump Level Dump Contains
1 only the file header
2 just the file header, the database info record, and checkpoint progress records
3 all record types, but just the earliest and latest records for circular reuse record types
4 as above, but includes the 4 most recent records for circular reuse record types
5+ as above, but the number of circular reuse records included doubles with each level
the session must be connected AS SYSDBA
alter session set events 'immediate trace name controlf level 5';
This dump show lots of intresting information.
it also show rman recordes if we used this controlfile in rman backup.
Thanks
Kuljeet Pal Singh

You can find each doc in html and pdf format on the Documentation Library<br>
You can too download all the documentation in html format to have all on your own computer here (445.8MB)<br>
<br>
Nicolas.

How to increase the size of Redo log files?

Hi All,
I have 10g R2 RAC on RHEL. As of now, i have 3 redo log files of 50MB size. i have used redo log size advisor by setting fast_start_mttr_target=1800 to check the optimal size of the redologs, it is showing 400MB. Now, i want to increase the size of redo log files. how to increase it?
If we are supposed to do it on production, how to do?
I found the following in one of the article....
"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."
I did not understand the the point however it must balanced out with the expected recovery time in the above given paragraph.
Can anybody help me?
Thanks,
Praveen.

You dont have to shutdown the database before dropping redo log group but make sure you have atleast two other redo log groups. Also note that you cannot drop active redo log group.
Here is nice link,
http://www.idevelopment.info/data/Oracle/DBA_tips/Database_Administration/DBA_34.shtml
And make sure you test this in test database first. Production should be touched only after you are really comfortable with this procedure.

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

Oracle 11g takes way too long to start

I find that Oracle 11g 11.1 takes much longer to start than Oracle 10g or 9g. I am on HP UNIX 11i server, Have others observed similar issue. Are they any init.ora parameters to speed up startup.
Thanks.

alter system set fast_start_mttr_target=300 scope=bothThis has nothing to do with the posters startup time - at least if he stops his database not with "shutdown abort" or "startup force".
@user12021554: What exactly is "long"? Can you compare these numbers to 10g or even 9i?
Can you further check the server is not swapping and database parameters are equal?
Ronny Egner
My Blog: http://blog.ronnyegner-consulting.de

Automatic Checkpoint Tuning in Oracle 10g

Hi ,
How to confirm if the database has been configured for automatic checkpoint tuning...????
Many thanks...
Sim

The log_checkpoint_timeout (default 1800) gives Oracle a time-based target, and the log_checkpoint_interval (default 0, meaning the action is based on the size of the current redo log file) give Oracle a 'volume-based' target.
The target affects the rate at which the database writer writes dirty blocks to disk. Every three seconds the database writer wakes up and checks the tail-end of the checkpoint queue and writes out any blocks that were attached to the queue too far in the past.
In this context, "too far in the past" means either "more seconds in the past than the[i] log_checkpoint timeout" or "made dirty by a change described in a redo block more than log_checkpoint_interval blocks back from the current block".
If you set fast_start_mttr_target to a non-zero number of seconds then Oracle tries to treat that as a request to write out dirty blocks sufficiently rapidly that crash recovery will take no more than that number of seconds. In effect this makes Oracle change the internal value of log_checkpoint_interval and log_checkpoint_timeout dynamically every few seconds.
Recoverty requires Oracle to apply the redo log from a known point - which means reading and applying a certain amount of redo to a number of "out of synch" blocks that have to be read from disk. So the fast_start_mttr_target code is constantly calculating how much redo would have to be read and applied, and how many data blocks would have to be read and fixed - and writing dirty blocks fast enough to make it possible to do that work within the given time limit.
Setting the parameter to zero is (as it is with many numerical parameters) equivalent to not setting it at all. If you try to set the parameter to a very small value (say 30 seconds) you may end up finding lots of messages in your alert log saying something like: "I can't honour your request to recover in 30 seconds, the best I can do is XXX".
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

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....

"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.

Setting fast_start_mttr_target on 10.2.0.4

Similar Messages

Maybe you are looking for