rac不到redo大小就切换是什么原因？
s10u10下的11.2.0.2 rac为什么归档日志没到redo大小就马上切换，如单机设置50M则差不多平均在45M左右就会切换生成一个，而rac中如果设置成50M则平均3M左右会切换一个，将原来50M全部删除，重新成200Mredo log，再增加一组200M，这样也会变成平均
12M左右切换一个，难道这是正常的？同样在pc服务器上安装的11.2.0.2 rac，重做日志用默认50M一个，也差不多平均20-40M左右
才会切换一个，同样采用asm来管理。这是什么原因？有没哪些大侠有遇到类似情况？怎么处理？ 1.
“如单机设置50M则差不多平均在45M左右就会切换生成一个”
Why?
redo wastage http://www.oracledatabase12g.com/archives/%E9%87%8D%E5%81%9A%E6%97%A5%E5%BF%97%E6%B5%AA%E8%B4%B9redo-wastage.html
2.
"rac中如果设置成50M则平均3M左右会切换一个，将原来50M全部删除，重新成200Mredo log，再增加一组200M，这样也会变成平均
12M左右切换一个，难道这是正常的？"
why?
force archive SCN
"Log switches may also be forced automatically in relatively idle threads of an Oracle parallel server database, to secure recoverability. Whenever a log file is reused in any thread, the force SCN recorded in the database entry of the controlfile is advanced to 1 beyond the high SCN of the reused log file (unless the force SCN was already higher). If the low SCN for the current log file in any enabled thread thereby falls behind the force SCN, a log switch is forced in that thread. This allows that log file to be archived. Until that log file is archived, newer redo in the archived copy of the recently reused log file might not be able to be applied in some recovery scenarios, or to a standby database.
If a thread requiring a forced log switch is not open, the instance that raised the force SCN will perform the log switch on behalf of the closed thread, and the first available ARCn process in any instance will archive the log file. However, if the thread is open, its instance is prompted to perform these actions itself. This is done by taking a KK instance lock. The LGWR process in each instance holds the KK instance lock on its own thread. The id2 field identifies the thread number. When this lock is taken by another instance, LGWR recognizes that a forced log switch is required. "
reference http://www.ixora.com.au/notes/log_switch_triggers.htm 理解有困难，关于2
换言之是否意味着，如果某个节点产生redo显著慢于其它节点，必将经常遭遇force archive? Archive logs can be different than the online log size. It is perfectly normal behaviour and nothing to be concerned of. Below note discuss the reason in details( no blank padding and log switch ):
Note 388627.1 : Archive logs are created with smaller, uneven size than the original redo logs. Why? Archive Logs Are Created With Smaller, Uneven Size Than The Original Redo Logs. Why? Applies to:
Oracle Server - Enterprise Edition - Version: 8.1.7.4 to 11.1.0.6 - Release: 8.1.7 to 11.1
Information in this document applies to any platform.
Goal
Archive logs are created with smaller, uneven size than the original redo logs.
Commands like:
ALTER SYSTEM SWITCH LOGFILE
or
ALTER SYSTEM ARCHIVE LOG ...
are not used to generate archive or switch the logfile. As well, there is no ARCHIVE_LAG_TARGET parameter set.
What else could cause such behaviour?
Solution
According to:
Bug: 5450861 : ARCHIVE LOGS ARE GENERATED WITH A SMALLER SIZE THAN THE REDO LOG FILES
the explanation for this situation has 2 main reasons:
1. The archive logs do not have to be even in size. This was decided a very long time ago, when blank padding the archive logs was stopped, for a very good reason - in order to save disk space.
2. The log switch does not occur when a redo log file is 100% full. There is an internal algorithm that determines the log switch moment. This also has a very good reason - doing the log switch at the last moment could incur performance problems (for various reasons, out of the scope of this note).
As a result, after the log switch occurs, the archivers are copying only the actual information from the redo log files. Since the redo logs are not 100% full after the log switch and the archive logs are not blank padded after the copy operation has finished, this results in uneven, smaller files than the original redo log files.
This is very conspicuous for very small redo log files (e.g. smaller than 10 MB), i.e. 2.5 MB archive logs generated from 5 MB redo logs are very visible.
Just note that at this moment, the default redo log files are 100 MB in size. If the resulting archive log files would be between 98 and 100 MB nobody would notice.
The main concern that one should have for the archive log files is an eventual corruption. This can be very easily checked by trying a test recovery. When this is ok, the uneven archive log size should be of no concern, as it's expected.
Please note that Bug: 5450861 has been closed as 'Not a Bug', just like related Bug reports Bug 9272059 and Bug 12317474.
In fact Bug 12317474 discusses an additional situation that could cause the same issue.
3. With a high CPU_COUNT, a low load and a redo log file size smaller than the redolog buffer, you may small archived log files because of log switches at about 1/8 of the size of the define log file size.
This is because CPU_COUNT defines the number of redo strands (ncpus/16). With a low load only a single strand may be used. With redo log file size smaller than the redolog buffer, the log file space is divided over the available strands. When for instance only a single active strand is used, a log switch can already occur when that strand is filled.
References
BUG:5450861 - ARCHIVE LOGS ARE GENERATED WITH A SMALLER SIZE THAN THE REDO LOG FILES
BUG:9272059 - REDO LOG SWITCH AT 1/8 OF SIZE DUE TO CMT CPU'S
BUG:12317474 - FREQUENT REDO LOG SWITCHES GENERATING SMALL SIZED ARCHIVELOGS 结论是 不管是 RAC或非RAC环境中 archivelog 归档日志的大小都 不是必须等于 重做日志大小的， 一般会 略微小于redo log size ， 但是也不排除 远远小于的情况。
造成这种现象的几点原因：
1. 节约不必要的磁盘浪费
2. 内部算法决定了何时切换日志(非ARCHIVE_LAG_TARGET)
3. 较高的CPU_COUNT 参数，因为cpu number 决定了redo strands (ncpus/16)的个数
主要是由于oracle内部算法所决定的， 一般不会造成实例 性能或可用性问题， 唯一的困扰可能是 生成了较多的小归档日志。 Maclean Liu(刘相兵 发表于 2012-1-24 22:39 static/image/common/back.gif
结论是 不管是 RAC或非RAC环境中 archivelog 归档日志的大小都 不是必须等于 重做日志大小的， 一般会 ...
这是啊造成很多小归档.以前ORACLE 10G 和9I 激发日志发生归档 是有些条件的.
如今11G 激发日志归档 还要加内部算法 ORACLE Instance posdb1 - Can not allocate log, archival required
每晚 10点 都要切换好多次
页:
[1]