设计网站公司名称tk域名官方网站

归档重做日志 (明显) 比重做日志文件小。 (文档 ID 1356604.1)

日志切换将由于以下原因发生：

1. 由于在重做日志文件已满之前强制创建存档而记录和设计的行为

1. SQL> alter system switch logfile;
2. SQL> alter system archive log current;
3. RMAN> backup archivelog all;
4. RMAN> backup database plus archivelog;
5. ARCHIVE_LAG_TARGET : limits the amount of data that can be lost and effectively increases the availability of the standby database by forcing a log switch after the specified amount of time elapses. you can see this aswell in RAC with an idle/low-load instance. ADG下定期自动切换

2. 未记录但设计好的行为：

1. BUG 9272059 - 由于 CMT CPU，重做日志切换大小为 1/8
2. BUG 10354739 - REDOLOGSIZE 未完全使用
3. BUG 12317474 - 频繁重做日志切换生成小型存档日志 
4. BUG 5450861 - 生成的存档日志比重做日志文件小
5. BUG 7016254 - 减少日志切换时控制文件入队等待时间
6. BUG 29221745 - 删除由代理发起的日志切换

解释 ：

根据Bug: 5450861 (已关闭为“非 Bug”)：

* 存档日志的大小不必相等。这是很久以前就决定的，当时停止了存档日志的空白填充，理由很充分 - 为了节省磁盘空间。
* 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.redo 没有用满的话不会写入archived log 

* 当重做日志文件已 100% 满时，不会发生日志切换。有一个内部算法可以确定日志切换时刻。这也有一个很好的理由 - 在最后一刻进行日志切换可能会导致性能问题（出于各种原因，超出了本文的范围）。因此，在发生日志切换后，归档程序只会从重做日志文件中复制实际信息。由于日志切换后重做日志并非 100% 满，并且复制操作完成后存档日志未填充空白，因此会导致文件比原始重做日志文件不均匀且更小。

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

有许多因素共同决定了日志切换频率。以下是本例中最相关的因素：

a) RDBMS 参数 LOG_BUFFER_SIZE

如果 DBA 没有明确设置，则我们使用默认值；在实例启动时，RDBMS 将共享重做线程数计算为 ncpus/16，每个线程的大小为 128Kb * ncpus（其中 ncpus 是系统中的 CPU 数量）。日志缓冲区大小是线程数乘以线程大小。计算或指定的大小四舍五入为 SGA 中内存段粒度的倍数。对于 11.2，如果

SGA 大小 >= 128GB，则颗粒大小为 512MB
64GB <= SGA 大小 < 128GB，则颗粒大小为 256MB
32GB <= SGA 大小 < 64GB，则颗粒大小为 128MB
16GB <= SGA 大小 < 32GB，则颗粒大小为 64MB
8GB <= SGA 大小 < 16GB，则颗粒大小为 32MB
1GB <= SGA 大小 < 8GB，则颗粒大小为 16MB
SGA 大小 < 1GB，则颗粒大小为 4MB

有一些强制执行的最低限度和最高限度。

b) 系统负载
STRAND翻译：線, （線、繩等的）縷，股

最初只使用一个重做 strand，即“活动”重做 strand 的数量为 1，所有进程将其重做复制到该 strand 中。当/如果对该 strand 存在争用，则活动重做 strand 的数量将增加到 2。随着对活动 strand 的争用增加，活动 strand 的数量也会增加。活动重做 strand 的最大可能数量是日志缓冲区中最初分配的 strand 数量。（此功能称为“动态 strand”，有一个隐藏参数可以禁用它，然后允许进程从一开始就使用所有 strand）。
 

c) 日志文件大小

这是 DBA 在创建日志文件时决定的日志文件大小。

d) 日志文件空间预留算法

当 RDBMS 切换到新的联机重做日志文件时，所有日志缓冲区重做线程内存都会“映射”到日志文件空间( 此功能称为“动态 strand”，有一个隐藏参数可以禁用它，然后允许进程从一开始就使用所有 strand,    这样的话就不会有用不满的情况了)。如果日志文件大于日志缓冲区，则每个线程将映射/保留其线程大小的日志文件空间，剩余的日志文件空间（“日志残留”）仍然可用。如果日志文件小于日志缓冲区，则整个日志文件空间在所有线程之间 平均分配/映射/保留，并且没有未保留的空间（即没有日志残留）。当任何进程填充线程，使得该线程的所有保留的底层日志文件空间都被使用，并且没有日志残留时，将安排日志切换。

示例：128 个 CPU，因此 RDBMS 分配一个大小为 128Mb 的 log_buffer，其中包含 8 个大小为 16Mb 的共享线程。它可能比 128Mb 稍大，因为它四舍五入到 SGA 粒度边界。日志文件为 100Mb，因此当 RDBMS 切换到新的在线重做日志文件时，每个 strand 会保留 100Mb/8 = 25600 ( 12.5MB=12.5*1024*1024B/512B(redo 块大小就是512B，datafile blocksize默认8k)=25600)个块，并且没有日志残留。如果系统负载较低，则只有一个重做 strand 处于活动状态/使用状态，当该 strand 中的 25600 个块已满时，将安排日志切换 - 创建的存档日志的大小约为 25600 个块。

在实例启动时，RDBMS 将共享重做线程数计算为 ncpus/16，每个线程的大小为 128Kb * ncpus（其中 ncpus 是系统中的 CPU 数量）。日志缓冲区大小是线程数乘以线程大小。 128/16=8  128*128=16384=16MB       log buffer=  8*16=128MB

在其他所有条件保持不变（128 个 CPU 和低负载）的情况下，使用更大的日志文件不会真正减少请求日志切换时未填充空间的数量，但它会使未填充空间占总日志文件空间的百分比降低，例如

- 对于 100Mb 的日志文件，日志切换发生在 7 x 16Mb=112MB 日志文件空间未填充的情况下（即，请求日志切换时日志文件已满 10%） 这里错了应该是7*100/8吧，反正是1/8

- 对于 1Gb 的日志文件，日志切换将在 7 x 16Mb 日志文件空间未填充的情况下发生（即，请求日志切换时日志文件已满 90%）
1GB的情况下 初次映射了8*16MB，只有一个16MB在不停的增加，所以
1000MB/16MB=62.5 个有7个是不能用的，所以总共损失了 62.5-7/62.5= 88%

如果 CPU_COUNT 较高、负载较低且重做日志文件大小小于重做日志缓冲区，您可能会看到较小的归档日志文件，因为日志切换的大小约为定义日志文件大小的 1/8。这是因为 CPU_COUNT 定义了重做线程的数量 (ncpus/16)。如果负载较低，则只能使用单个线程。如果重做日志文件大小小于重做日志缓冲区，则日志文件空间将划分为可用线程。例如，当仅使用单个活动线程时，当该线程已满时，日志切换可能已经发生。
(最初只使用一个重做 strand，即“活动”重做 strand 的数量为 1，所有进程将其重做复制到该 strand 中。当/如果对该 strand 存在争用，则活动重做 strand 的数量将增加到 2。随着对活动 strand 的争用增加，活动 strand 的数量也会增加。活动重做 strand 的最大可能数量是日志缓冲区中最初分配的 strand 数量。（此功能称为“动态 strand”，有一个隐藏参数可以禁用它，然后允许进程从一开始就使用所有 strand）。)