本节提供配置数据库实例重做日志时应考虑的准则，并包含以下主题：
- 多路复用重做日志文件
- 将重做日志成员放在不同的磁盘上
- 规划重做日志文件的大小
- 规划重做日志文件的块大小
- 选择重做日志文件的数量
- 控制档案滞后
多路复用重做日志文件
为了防止涉及重做日志本身的故障，Oracle数据库允许多路复用重做日志，这意味着重做日志的两个或多个相同副本可以自动保存在不同的位置。为了最大的好处，这些位置应位于不同的磁盘上。但是，即使重做日志的所有副本都在同一磁盘上，冗余也可以帮助防止I / O错误，文件损坏等。当多路复用重做日志文件时，LGWR会将相同的重做日志信息同时写入多个相同的重做日志文件，从而消除单点重做日志失败。
通过创建重做日志文件组来实现多路复用。组由重做日志文件及其多路复用副本组成。据说每个相同的副本都是该组的成员。每个重做日志组都由一个数字定义，例如组1，组2等。
Figure 12-2 Multiplexed Redo Log Files
在图12-2中，A_LOG1和B_LOG1都是组1的成员，A_LOG2和B_LOG2都是组2的成员，依此类推。组中的每个成员必须具有相同的大小。
日志文件组的每个成员同时处于活动状态 - 即由LGWR同时写入 - 由LGWR分配的相同日志序列号指示。在图12-2中，第一个LGWR同时写入A_LOG1和B_LOG1。然后它同时写入A_LOG2和B_LOG2，依此类推。 LGWR永远不会同时写入不同组的成员（例如，A_LOG1和B_LOG2）。
Oracle建议您复用重做日志文件。如果需要恢复，丢失日志文件数据可能是灾难性的。请注意，在复用重做日志时，数据库必须增加它执行的I / O量。根据您的配置，这可能会影响整体数据库性能。
响应重做日志失败
每当LGWR无法写入组的成员时，数据库会将该成员标记为INVALID，并将错误消息写入LGWR跟踪文件和数据库警报日志，以指示不可访问文件的问题。当重做日志成员不可用时，LGWR的具体反应取决于缺乏可用性的原因，如下表所示。
| Condition | LGWR Action |
| LGWR可以成功写入组中的至少一个成员 | 写作正常进行。 LGWR写入组的可用成员并忽略不可用的成员。 |
| LGWR无法在日志交换机上访问下一个组，因为该组必须已归档 | 数据库操作暂时停止，直到该组可用或存档组为止。 |
| 由于介质故障，LGWR在日志切换时无法访问下一组的所有成员 |
Oracle数据库返回错误，数据库实例关闭。 在这种情况下，您可能需要在丢失重做日志文件的情况下对数据库执行介质恢复。 如果数据库检查点已超出丢失的重做日志，则无需进行介质恢复，因为数据库已将重做日志中记录的数据保存到数据文件中。 您只需删除无法访问的重做日志组。 如果数据库未归档错误日志，请使用ALTER DATABASE CLEAR LOFGILE UNARCHIVED禁用归档，然后才能删除日志。 |
| 当LGWR写信给他们时，一群人的所有成员突然无法进入 |
Oracle数据库返回错误，数据库实例立即关闭。 在这种情况下，您可能需要执行介质恢复。 如果包含日志的介质实际上没有丢失 - 例如，如果无意中关闭了日志驱动器 - 可能不需要介质恢复。 在这种情况下，您只需要重新打开驱动器并让数据库执行自动实例恢复。 |
合法和非法配置
在大多数情况下，多路复用重做日志应该是对称的：重做日志的所有组应该具有相同数量的成员。但是，数据库不要求多路复用重做日志是对称的。例如，一个组只能有一个成员，其他组可以有两个成员。此配置可防止磁盘故障暂时影响某些重做日志成员但保留其他成员完整。
实例重做日志的唯一要求是它至少有两个组。图12-3显示了合法和非法的多路复用日志配置。第二种配置是非法的，因为它只有一个组。
Figure 12-3 Legal and Illegal Multiplexed Redo Log Configuration
将重做日志成员放在不同的磁盘上
设置多路复用重做日志时，请将组成员放在不同的物理磁盘上。如果单个磁盘发生故障，则只有一个组的一个成员对LGWR不可用，而LGWR仍可访问其他成员，因此该实例可以继续运行。
如果归档重做日志，请在磁盘上传播重做日志成员，以消除LGWR和ARCn后台进程之间的争用。例如，如果您有两组多路复用重做日志成员（双工重做日志），请将每个成员放在不同的磁盘上，并将归档目标设置为第五个磁盘。这样做可以避免LGWR（写入成员）和ARCn（阅读成员）之间的争用。
规划重做日志文件的大小
同一多路复用重做日志组的所有成员必须具有相同的大小。不同组的成员可以有不同的大小。但是，在组之间改变文件大小没有任何优势。如果未在日志切换之间设置检查点，请使所有组的大小相同，以保证检查点定期发生。
重做日志文件允许的最小大小为4 MB。
特定于操作系统的Oracle文档。重做日志文件的默认大小取决于操作系统。
规划重做日志文件的块大小
与数据库块大小（介于2K和32K之间）不同，重做日志文件始终默认为块大小，该大小等于磁盘的物理扇区大小。从历史上看，这通常是512字节（512B）。
一些较新的高容量磁盘驱动器提供4K字节（4K）扇区大小，以增加ECC功能和提高格式效率。大多数Oracle数据库平台都能够检测到更大的扇区大小。然后，数据库会自动在这些磁盘上创建4K块大小的重做日志文件。
但是，块大小为4K时，重做浪费会增加。实际上，4K块中的重做浪费量与512B块相比非常重要。您可以通过查看存储在V $ SESSTAT和V $ SYSSTAT视图中的统计信息来确定重做浪费的数量。
SQL> SELECT name, value FROM v$sysstat WHERE name = 'redo wastage'; NAME VALUE -------------------------------- ---------- redo wastage 17941684
为避免额外的重做浪费，如果您使用仿真模式磁盘 - 在磁盘接口上模拟512B扇区大小的4K扇区磁盘驱动器 - 您可以通过指定512B块大小覆盖重做日志的默认4K块大小或对于某些平台，1K块大小。但是，当重做日志写入与4K物理扇区的开头不对齐时，会导致性能显着下降。由于4K物理扇区中的八个512B插槽中的七个未对齐，因此通常会发生性能下降。因此，在4K扇区大小仿真模式磁盘上规划重做日志块大小时，必须评估性能和磁盘浪费之间的权衡。
从Oracle Database 11g第2版开始，您可以使用CREATE DATABASE，ALTER DATABASE和CREATE CONTROLFILE语句中的BLOCKSIZE关键字指定联机重做日志文件的块大小。允许的块大小为512,1024和4096。
以下语句添加块大小为512B的重做日志文件组。 BLOCKSIZE 512子句有效，但对于512B扇区大小的磁盘不是必需的。对于4K扇区大小的仿真模式磁盘，BLOCKSIZE 512子句会覆盖默认的4K大小。
ALTER DATABASE orcl ADD LOGFILE GROUP 4 ('/u01/logs/orcl/redo04a.log','/u01/logs/orcl/redo04b.log') SIZE 100M BLOCKSIZE 512 REUSE;
要确定重做日志文件块大小，请运行以下查询：
SQL> SELECT BLOCKSIZE FROM V$LOG; BLOCKSIZE --------- 512
有关ALTER DATABASE命令的信息，请参见“Oracle数据库SQL语言参考”。
有关V $ SESSTAT和V $ SYSSTAT视图的信息，请参见Oracle数据库参考
选择重做日志文件的数量
确定数据库实例的重做日志文件数量的最佳方法是测试不同的配置。在不妨碍LGWR编写重做日志信息的情况下，最佳配置具有最少的组。
在某些情况下，数据库实例可能只需要两个组。在其他情况下，数据库实例可能需要其他组来保证LGWR始终可以使用回收组。在测试期间，确定当前重做日志配置是否令人满意的最简单方法是检查LGWR跟踪文件和数据库警报日志的内容。如果消息指示LGWR经常因为检查点尚未完成或组尚未归档而必须等待组，请添加组。
在设置或更改实例重做日志的配置之前，请考虑可以限制重做日志文件数的参数。以下参数限制了可以添加到数据库的重做日志文件的数量：
- CREATE DATABASE语句中使用的MAXLOGFILES参数确定每个数据库的最大重做日志文件组数。组值的范围可以从1到MAXLOGFILES。当兼容级别设置为早于10.2.0时，覆盖此上限的唯一方法是重新创建数据库或其控制文件。因此，在创建数据库之前考虑此限制很重要。当兼容性设置为10.2.0或更高版本时，您可以超出MAXLOGFILES限制，并根据需要扩展控制文件。如果没有为CREATE DATABASE语句指定MAXLOGFILES，则数据库使用特定于操作系统的默认值。
- CREATE DATABASE语句中使用的MAXLOGMEMBERS参数确定每个组的最大成员数。与MAXLOGFILES一样，覆盖此上限的唯一方法是重新创建数据库或控制文件。因此，在创建数据库之前考虑此限制很重要。如果没有为CREATE DATABASE语句指定MAXLOGMEMBERS参数，则数据库使用操作系统默认值。
您的操作系统特定Oracle文档，用于MAXLOGFILES和MAXLOGMEMBERS参数的默认值和合法值。
控制档案滞后
您可以强制所有启用的重做日志线程以固定的时间间隔切换其当前日志。在主/备用数据库配置中，通过在主站点上归档重做日志然后将它们发送到备用数据库，可以对备用数据库进行更改。备用数据库正在应用的更改可能会滞后于主数据库上发生的更改，因为备用数据库必须等待主数据库重做日志中的更改存档（进入存档的重做日志），然后运到它。要限制此延迟，可以设置ARCHIVE_LAG_TARGET初始化参数。通过设置此参数，您可以以秒为单位指定该延迟的长度。
设置ARCHIVE_LAG_TARGET初始化参数
设置ARCHIVE_LAG_TARGET初始化参数时，会导致数据库定期检查实例的当前重做日志。如果满足以下条件，则实例将切换日志：
- 当前日志是在n秒前创建的，当前日志的估计存档时间是m秒（与当前日志中使用的重做块数成比例），其中n + m超过ARCHIVE_LAG_TARGET初始化参数的值。
- 当前日志包含重做记录
在Oracle Real Application Clusters环境中，如果实例落后，该实例还会导致其他线程切换和归档日志。当群集中的一个实例比其他实例更空闲时（例如，当您运行Oracle Real Application Clusters的双节点主/辅助配置时），这可能特别有用。
ARCHIVE_LAG_TARGET初始化参数提供了数据库当前日志可以跨越多长时间（以秒为单位）的上限。由于还会考虑估计的存档时间，因此这不是确切的日志切换时间。
以下初始化参数设置将日志切换间隔设置为30分钟（典型值）。
ARCHIVE_LAG_TARGET = 1800
值为0将禁用此基于时间的日志切换功能。这是默认设置。
即使没有备用数据库，也可以设置ARCHIVE_LAG_TARGET初始化参数。例如，可以专门设置ARCHIVE_LAG_TARGET参数以强制切换和存档日志。
ARCHIVE_LAG_TARGET是一个动态参数，可以使用ALTER SYSTEM SET语句进行设置。
必须在Oracle Real Application Clusters环境的所有实例中将ARCHIVE_LAG_TARGET参数设置为相同的值。如果不这样做会导致不可预测的行为。
影响ARCHIVE_LAG_TARGET设置的因素
在确定是否要设置ARCHIVE_LAG_TARGET参数以及确定此参数的值时，请考虑以下因素。
- 切换（以及归档）日志的开销
- 由于日志已满，导致正常日志切换的频率
- 备用数据库中允许多少重做丢失
如果自然日志切换比指定的间隔更频繁地发生，则设置ARCHIVE_LAG_TARGET可能不是非常有用。然而，在重做生成速度不规则的情况下，该间隔确实为每个当前日志覆盖的时间范围提供上限。
如果ARCHIVE_LAG_TARGET初始化参数设置为非常低的值，则可能会对性能产生负面影响。这可能会导致频繁的日志切换。将参数设置为合理的值，以免降低主数据库的性能。
参考资料
https://docs.oracle.com/cd/E11882_01/server.112/e25494/onlineredo.htm#ADMIN11308