大家好，我是 JiekeXu,江湖人称“强哥”，青学会 MOP 技术社区主席，荣获 Oracle ACE Pro 称号，墨天轮 MVP，墨天轮年度“墨力之星”，拥有 Oracle OCP/OCM 认证,MySQL 5.7/8.0 OCP 认证以及 PCA、PCTA、OBCA、OGCA、金仓KCA、KCP 等众多国产数据库认证证书,今天和大家一起来看看 如何快速诊断 Oracle RAC 启动问题,欢迎关注我的微信公众号“JiekeXu DBA之路”，然后点击右上方三个点“设为星标”置顶，更多干货文章才能第一时间推送，谢谢！
目 录
配置最佳实践
坏块预防
ADG 备库启用闪回
使用 Force Logging 模式
配置 Standby AWR
ADG 调优和故障排除
验证传输延迟并了解重做传输配置
重做应用故障排除和调整
验证 apply 延迟
查看每个归档生成率
检测和监控数据损坏
参考链接
配置最佳实践
坏块预防
当检测到数据损坏时，Oracle Data Guard、块介质恢复和数据文件介质恢复可恢复数据。由于人为或应用程序错误造成的全数据库逻辑损坏可通过 Oracle 闪回技术恢复。还有一些工具可用于主动验证逻辑数据结构。例如，SQL*Plus ANALYZE TABLE 语句可检测块间损坏。利用这些最佳实践实现最全面的数据损坏预防和检测。
坏块初始化参数设置 Block-Corruption Initialization Parameter Settings
| 主库设置 | 备库设置 |
|---|---|
| DB_BLOCK_CHECKSUM=MEDIUM or FULL | DB_BLOCK_CHECKSUM=MEDIUM or FULL |
| DB_LOST_WRITE_PROTECT=TYPICAL | DB_LOST_WRITE_PROTECT=TYPICAL |
| DB_BLOCK_CHECKING=FALSE | DB_BLOCK_CHECKING=MEDIUM or FULL |
建议将主库上的 DB_BLOCK_CHECKING 设置为 “MEDIUM ”或 “FULL”，但只有在与应用程序一起进行全面性能评估后才能这样做。每次块更改都会产生性能开销，因此在设置 DB_BLOCK_CHECKING 参数时，性能测试尤为重要。Oracle 强烈建议在主库或备库上最小设置 DB_BLOCK_CHECKING=MEDIUM（对数据块进行块检查，但不对索引块进行检查）。如果在主库上将 DB_BLOCK_CHECKING 设置为 “MEDIUM ”或 “FULL ”造成的性能开销无法接受，那么在备库上将 DB_BLOCK_CHECKING 设置为 “MEDIUM ”或 “FULL”。
--on Oracle Data Guard
SQL> show parameter db_block_check
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_block_checking string FALSE
db_block_checksum string TYPICAL
SQL> show parameter db_lost_writ
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_lost_write_protect string TYPICAL
alter system set db_block_checksum=full;
alter system set db_lost_write_protect=typical;
alter system set db_block_checking=full;
以下建议也有助于防止数据损坏。
使用 Oracle 自动存储管理（Oracle ASM）提供磁盘镜像以防止磁盘故障。
使用 Oracle ASM 高冗余来优化损坏修复。对磁盘组使用 Oracle ASM 冗余可提供镜像扩展，数据库在遇到 I/O 错误或损坏时可使用这些扩展。为了提供持续保护，Oracle ASM 冗余提供了在发生 I/O 错误时将扩展移动到磁盘上不同区域的功能。如果有坏扇区返回介质错误，Oracle ASM 冗余机制将非常有用。
启用闪回技术（Flashback Technologies），以便从通常由人为错误造成的逻辑损坏中进行快速时间点恢复，并在故障切换后快速恢复主数据库。
在备份和恢复操作过程中使用 RMAN 进行额外的块检查。使用恢复管理器 (RMAN) 实施备份和恢复策略，并定期使用 RMAN BACKUP VALIDATE CHECK LOGICAL 扫描来检测损坏。
ADG 备库启用闪回
当进行主备切换时，如果在切换过程中出现故障，那么启用闪回数据库后就可以很容易地逆转故障。
另外，如果使用闪回数据库从用户错误或逻辑损坏中进行快速时间点恢复，请将 DB_FLASHBACK_RETENTION_TARGET 设置为与应恢复数据库的过去最远时间相等的值。如果可以在 24 小时内检测并修复逻辑损坏，则应将 DB_FLASHBACK_RETENTION_TARGET 设置为最少 1440（分钟）。
-- 开启关闭 ADG 闪回 alter database flashback off;
SQL> alter database flashback on;
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
YES
SQL> show parameter db_flashback
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target integer 1440
使用 Force Logging 模式
当主数据库处于 FORCE LOGGING 模式时，所有数据库数据更改都会被记录。FORCE LOGGING 模式可确保备用数据库与主数据库保持一致。如果因为需要 NOLOGGING 操作的加载性能而无法使用该模式，则请参阅启用适当的日志记录模式了解其他选项。
可以通过发布 ALTER DATABASE FORCE LOGGING 语句立即启用强制日志记录。如果指定 FORCE LOGGING，Oracle 将等待所有正在进行的非日志操作完成。
SQL> ALTER DATABASE FORCE LOGGING;
配置 Standby AWR
自 Oracle Database 12c (12.2) 以来，可以拍摄备库的自动工作负载存储库 (AWR) 快照。备库 AWR 是确定 Active Data Guard 备库中恢复和报告工作负载性能问题的最佳工具。
有关配置和管理备用 AWR 的详细信息，请参阅管理 Active Data Guard 备库中的自动工作负载库。https://docs.oracle.com/en/database/oracle/oracle-database/23/tgdba/gathering-database-statistics1.html#GUID-309C107F-DC42-4119-9904-9504E9748B84
ADG Standby 的 AWR 快照默认已启用（Oracle Database 23ai）。无需运行 dbms_workload_repository.enable_snapshot_service() 即可启用。它将启用 CDB 根和 ADG 中所有 PDB 的自动快照。快照保留时间默认为 8 天。要更改保留时间，请使用 dbms_workload_repository.modify_snapshot_settings(retention)。
以下是在 ADG 备用数据库中管理 AWR 的主要步骤：
- 配置远程管理框架 (RMF)
- 管理 Active Data Guard 备用数据库的快照
- 查看 Active Data Guard 备用数据库中的 AWR 数据
此过程需要配置主备库间的 dblink，感兴趣的可查看DBA 实战运维小技巧~在 ADG 中配置 AWR。
ADG 调优和故障排除
对于具有对称硬件和配置的备用数据库，以及经过良好调整的网络配置，传输延迟应少于 10 秒，大多数情况下少于 1 秒。
验证传输延迟并了解重做传输配置
要确定备用数据库是否存在延迟，以及这种延迟是传输延迟还是应用延迟，请查询 V$DATAGUARD_STATS 视图。
set linesize 234;
set pagesize 9999;
column name format a13;
column value format a20;
column unit format a30;
column TIME_COMPUTED format a28;
select name,value,unit,datum_time,time_computed from v$dataguard_stats where name like '%lag'；
DATUM_TIME 列是收到用于计算指标的数据时备用数据库的本地时间。延迟指标是根据定期从主库接收的数据计算的。如果此列中的值在多次查询中保持不变，则表明备库没有从主库接收数据。在这种情况下，潜在的数据丢失时间是从 V$DATAGUARD_STATS 的最后基准时间到备库的当前时间。
要获取显示自上次启动备用实例以来传输或应用延迟值历史记录的直方图，请查询 V$STANDBY_EVENT_HISTOGRAM 视图。要评估一个时间段内的传输或应用延迟情况，可在该时间段开始时拍摄 V$STANDBY_EVENT_HISTOGRAM 的快照，并将该快照与该时间段结束时拍摄的快照进行比较。
SQL> select * from v$standby_event_histogram where name like '%lag' and count >0;
NAME TIME UNIT COUNT LAST_TIME_UPDATED CON_ID
------------- ---------- ------------------------------ ---------- -------------------- ----------
apply lag 0 seconds 3171020 09/27/2024 16:17:30 0
apply lag 1 seconds 187634 09/27/2024 16:16:39 0
apply lag 2 seconds 15141 09/27/2024 16:16:40 0
apply lag 3 seconds 7416 09/27/2024 16:16:41 0
apply lag 4 seconds 2110 09/27/2024 16:13:37 0
apply lag 5 seconds 548 09/27/2024 10:26:55 0
apply lag 6 seconds 173 09/27/2024 08:00:32 0
apply lag 7 seconds 89 09/27/2024 08:00:16 0
apply lag 8 seconds 59 09/27/2024 08:00:17 0
apply lag 9 seconds 53 09/27/2024 08:00:18 0
apply lag 10 seconds 46 09/27/2024 08:00:19 0
apply lag 11 seconds 49 09/27/2024 08:00:20 0
apply lag 12 seconds 47 09/27/2024 08:00:21 0
apply lag 13 seconds 39 09/27/2024 08:00:22 0
apply lag 14 seconds 44 09/27/2024 08:00:23 0
apply lag 15 seconds 39 09/27/2024 08:00:24 0
apply lag 16 seconds 38 09/27/2024 08:00:25 0
apply lag 17 seconds 38 09/27/2024 08:00:26 0
apply lag 18 seconds 34 09/27/2024 08:00:27 0
apply lag 19 seconds 26 09/27/2024 08:00:28 0
apply lag 20 seconds 22 09/27/2024 08:00:29 0
apply lag 21 seconds 21 09/27/2024 08:00:30 0
apply lag 22 seconds 20 09/27/2024 08:00:31 0
apply lag 23 seconds 12 09/26/2024 04:00:32 0
apply lag 24 seconds 12 09/25/2024 14:47:58 0
apply lag 25 seconds 5 09/25/2024 14:47:59 0
apply lag 26 seconds 9 09/25/2024 14:48:05 0
apply lag 27 seconds 5 09/25/2024 14:48:01 0
apply lag 28 seconds 4 09/25/2024 14:48:02 0
apply lag 29 seconds 1 09/25/2024 14:48:03 0
apply lag 30 seconds 1 09/25/2024 14:48:04 0
31 rows selected.
收集信息以排除传输延迟故障
观察到不可接受的重做传输延迟时，收集以下信息并调查问题：
- 传输延迟是何时发生的？视图 V$DATAGUARD_STATS 和 V$STANDBY_EVENT_HISTOGRAM 的数据记录，以显示延迟开始的时间以及延迟随时间的变化情况。
- 传输延迟是否发生在特定时间段，如每日批处理操作的每日午夜 12 点、大型批处理操作的每月或季度末？
- 检查任何已启用 Oracle Data Guard 传输的 LOG_ARCHIVE_DEST 设置，并验证是否已启用重做 COMPRESSION 或 ENCRYPTION。整体重做传输吞吐量可能会受到负面影响，因为重做日志必须在发送前进行压缩或加密，然后在备用机上接收时进行解压缩或解密。验证该更改是否是最近发生的，以及是否可以测试禁用这些设置属性。
- 检查 Oracle Net 设置，评估是否启用了 Oracle Net 加密。如果启用了 Oracle Net 加密，何时启用以及启用的级别？Oracle Net 加密可能会大大降低重做吞吐量，因为重做日志在发送前已加密，而在备机上接收重做日志后又未加密。可选择禁用或降低加密级别，看看重做日志传输滞后是否会减少。
比较主库的重做生成率历史记录
在某些情况下，主库的重做生成率会在短时间内特别高，例如在大型批处理作业、数据加载、数据泵操作、以选择方式创建表格、PDML 操作或月末、季度末或年末批处理更新期间。
从主数据库获取重做生成历史记录，并将其与重做传输或重做应用滞后开始的时间进行比较。检查重做生成率是否因为额外的工作负载（如添加新的可插拔数据库或新的应用服务）而特别高。这样，可能需要进行额外的调整来适应这种额外的负载。
作为故障排除的一部分，收集以下信息或解决以下问题：
- 使用此查询收集 主库 重做生成率的每日历史记录
select trunc(completion_time) as "DATE", count(*) as "LOG SWITCHES", round(sum(blocks*block_size)/1024/1024) as "REDO PER DAY (MB)"
from v$archived_log
where dest_id=1
group by trunc(completion_time) order by 1;
DATE LOG SWITCHES REDO PER DAY (MB)
------------------- ------------ -----------------
2024-09-15 00:00:00 151 12015
2024-09-16 00:00:00 159 14950
2024-09-17 00:00:00 157 14460
2024-09-18 00:00:00 158 15768
2024-09-19 00:00:00 159 15445
2024-09-20 00:00:00 160 15799
2024-09-21 00:00:00 150 11688
2024-09-22 00:00:00 150 11541
2024-09-23 00:00:00 161 16775
2024-09-24 00:00:00 163 17182
2024-09-25 00:00:00 183 20806
2024-09-26 00:00:00 170 19048
2024-09-27 00:00:00 112 12915
- 从任何重做日志或传输延迟开始前 6 小时起，收集每个redo日志的生成率
select thread#,sequence#,blocks*block_size/1024/1024 MB,(next_time-first_time)*86400 sec,(blocks*block_size/1024/1024)/((next_time-first_time)*86400) "MB/s" from v$archived_log
where ((next_time-first_time)*86400<>0)
and first_time between to_date('2025/02/06 08:00:00','YYYY/MM/DD HH24:MI:SS')
and to_date('2025/02/06 11:00:00','YYYY/MM/DD HH24:MI:SS')
and dest_id=1 order by first_time;
在任何重做日志或传输延迟开始前 6 小时，从自动工作负载库 (AWR) 报告中收集重做日志生成率的每小时快照。默认情况下，Oracle 数据库每小时自动生成一次快照；但是，您可能需要手动创建快照，以便在不同于自动生成快照的时间捕获统计数据。要查看有关现有快照的信息，请使用 DBA_HIST_SNAPSHOT 视图。有关 AWR 以及生成快照和 AWR 报告的完整信息，请参阅《Oracle 数据库性能调优指南》中的创建快照。
与以前的历史记录相比，主库重做日志生成率是否特别高？如果可能，请确定与高重做生成率相对应的工作负载，并评估其是否是瞬时的或是否可以调整。例如，对于大型清除操作，可考虑截断或丢弃分区操作，以减少重做日志生成量。
评估传输网络并进行调整
重做日志传输包括主库实例后台进程向备库后台进程发送重做日志。您可以评估网络是否针对 Oracle Data Guard 重做传输进行了优化。
如果配置了异步重做传输，重做数据将以大数据包的形式异步流式传输到备库。要调整网络上的异步重做传输，需要优化单进程网络传输。
如果配置了同步重做传输，则每次 redo 写入都必须得到主库和备库的确认，然后才能进行下一次重做写入。您可以将 FASTSYNC 属性作为 LOG_ARCHIVE_DEST 设置的一部分来优化备用同步传输，但较高的网络延迟（例如 > 5 毫秒）会影响整个重做传输吞吐量。
在继续之前，请首先参阅评估和优化网络性能：
评估是否有足够的网络带宽来支持主处理器的重做生成率
确定调整重做传输的最佳 TCP 套接字缓冲区大小
调整操作系统对套接字缓冲区大小的限制，以调整重做传输
确定重做写入大小的最佳 MTU 设置
调整 MTU 以提高重做传输的网络吞吐量
如果网络配置已调整，请评估传输延迟（请参阅验证传输延迟和了解重做传输配置）是否降低到可接受的水平。如果是这样，说明已经达到目标，可以停止。否则，请继续调整和故障排除部分的其余内容。
收集和监控系统资源
收集 Oracle Linux OSwatcher 或 Oracle Exadata Exawatcher 数据以分析系统资源。收集的数据包括操作系统统计数据（如 iostat）、单元统计数据 (cellsrvstat) 和网络统计数据。
OSWatcher (oswbb) 是一组 UNIX shell 脚本，用于收集和存档操作系统和网络指标，以帮助支持人员诊断性能问题。作为最佳实践，应在有运行 Oracle 实例的每个节点上安装并运行 OSWatcher。如果出现性能问题，Oracle 支持人员可以使用这些数据帮助诊断数据库外部的性能问题。您可以从 OSWatcher（文档 ID 301137.1）下载 OSWatcher。
调整以满足 Data Guard 资源要求
如果出现以下情况，重做传输会受到影响
- 主数据库或备用数据库的 CPU 已完全耗尽
- 主用或备用数据库 I/O 系统饱和
- 网络拓扑结构无法支持重做生成率
评估主库系统是否有
- 有足够的 CPU 利用率供日志写入程序 (LGWR) 高效发布前台信息
- 足够的 I/O 带宽，以便本地日志写入在峰值时保持较低的 I/O 延迟
- 网络接口能够处理峰值重做速率卷以及同一接口上的任何其他网络活动
- 从主数据库收集自动工作负载存储库 (AWR)、活动会话历史 (ASH) 和 OSwatcher 或 Exawatcher 数据，用于调整和故障排除
评估备库系统是否具有
- 远程文件服务器 (RFS) 有足够的 CPU 利用率，该服务器是在备用数据库接收重做的 Oracle Data Guard 进程，可有效写入备用重做日志
- 足够的 I/O 带宽，使本地日志写入在峰值速率期间保持较低的 I/O 延迟
- 网络接口，可接收峰值重做速率卷以及同一接口上的任何其他网络活动
- 从备用数据库收集的 AWR、ASH 和 OSwatcher 或 Exawatcher 数据，用于调整和故障排除
高级故障排除： 使用异步重做传输确定网络时间
在继续之前，请首先查看评估和优化网络性能。
如果有足够的资源，尤其是网络带宽，异步重做传输可以与非常高的工作负载保持同步。在资源有限的情况下，异步重做传输可能会开始落后，导致备库上的传输滞后越来越严重。
异步重做传输（ASYNC）与事务承诺异步传输重做数据。事务提交时无需等待确认，即事务生成的重做数据已成功传输到远程备库。有了 ASYNC，即使有限的带宽使先前事务的重做数据无法立即发送到备库，主库日志写入进程（LGWR）也会继续确认提交成功（就像水槽中的水溢出的速度比排水的速度快）。
ASYNC 使用 TT00 进程直接从主库的日志缓冲区传输重做日志。如果 TT00 进程跟不上进度，在重做被传输到备库之前日志缓冲区就被回收，那么 TT00 进程就会自动过渡到从磁盘上的联机重做日志文件 (online redo log file ORL) 读取和发送。一旦 TT00 的传输赶上了当前重做的生成，它就会自动转回直接从日志缓冲区读取和发送。
如果在 TT00 完成发送原始 online redo log file ORL 之前有两个或更多日志切换，TT00 仍会转回读取当前联机日志文件的内容。在原始 ORL 和当前 ORL 之间存档的任何 ORL 都会使用 Oracle Data Guard 的重做间隙解决流程自动传输。
充足的资源（如主库和备库上的网络带宽、CPU、内存和日志文件 I/O）对异步 Data Guard 配置的性能至关重要。
要确定限制异步传输的资源，可使用 krsb stats，通过在主库和备库上设置事件 16421 来启用该功能：
alter session set events '16421 trace name context forever, level 3';
该事件非常轻量级，不会影响主库或备库的性能。
应在所有主库和备库实例上设置此动态事件，它会在给定序列的出货完成后将统计信息写入 TT00 或远程文件服务器 (RFS) 跟踪文件。在跟踪文件中，您会看到文件开头和结尾处的 krsb_end 统计信息。文件末尾的统计信息可让您深入了解异步传输在哪些方面花费了时间。
krsb_end: Begin stats dump for T-1.S-593
max number of buffers in use 10
Operation elapsed time (micro seconds) 474051333
File transfer time (micro seconds) 474051326
Network Statistics
LOG_ARCHIVE_DEST_2 : OCI REQUEST
Total count : OCI REQUEST 2748
Total time : OCI REQUEST 81374
Average time : OCI REQUEST 29
LOG_ARCHIVE_DEST_2 : NETWORK SEND
Total count : NETWORK SEND 2748
Total time : NETWORK SEND 286554724
Average time : NETWORK SEND 104277
Total data buffers queued 9644
Total data buffers completed 9644
Total bytes written 9885272064
Total bytes completed synchronously 9885272064
Average network send size (blocks) 7025
Average network send buffers 3.51
Average buffer turnaround time 240889
Throughput (MB/s) 19.89
Total network layer time 286636098
Percentage of time in network 60.47
Disk Statistics
Total count : DISK READ 11531
Total time : DISK READ 12335132
Average time : DISK READ 1069
Read-ahead blocks 14151680
Log buffer blocks 266915
Disk stall blocks 4888576
Total count : BUFFER RELEASE 9643
Total time : BUFFER RELEASE 7229
Average time : BUFFER RELEASE 0
Total disk layer time 12342361
Percentage of time in disk layer 2.60
Data Guard Processing Statistics
Total count : SLEEP 198
Total time : SLEEP 172351312
Average time : SLEEP 870461
Total DG layer time 175072867
Percentage of time in DG layer 36.93
Remote Server-Side Network Statistics
LOG_ARCHIVE_DEST_2 : NETWORK GET
Total count : NETWORK GET 8242
Total bytes : NETWORK GET 9885272064
Total time : NETWORK GET 453233790
Average time : NETWORK GET 54990
Total server-side network layer time 453233790
Percentage of time in network 95.61
Remote Server-Side Disk Statistics
LOG_ARCHIVE_DEST_2 : DISK WRITE
Total count : DISK WRITE 9644
Total time : DISK WRITE 8731303
Average time : DISK WRITE 905
LOG_ARCHIVE_DEST_2 : DISK NOSTALL REAP
Total count : DISK NOSTALL REAP 9644
Total time : DISK NOSTALL REAP 579066
Average time : DISK NOSTALL REAP 60
LOG_ARCHIVE_DEST_2 : BUFFER GET
Total count : BUFFER GET 9644
Total time : BUFFER GET 3607
Average time : BUFFER GET 0
Total server-side disk layer time 9313976
Percentage of time in disk layer 1.96
Remote Server-Side Data Guard Processing Statistics
LOG_ARCHIVE_DEST_2 : PUBLISH RTA BOUNDARY
Total count : PUBLISH RTA BOUNDARY 8948
Total time : PUBLISH RTA BOUNDARY 3665841
Average time : PUBLISH RTA BOUNDARY 409
LOG_ARCHIVE_DEST_2 : VALIDATE BUFFER
Total count : VALIDATE BUFFER 9644
Total time : VALIDATE BUFFER 1403088
Average time : VALIDATE BUFFER 145
Total Server-Side DG layer time 11503560
Percentage of time in DG layer 2.43
krsb_end: End stats dump
上述输出来自一次测试运行，在这次测试中，传输延迟刚刚开始出现。您可以观察到网络拥塞导致的滞后增加，网络层的等待时间增加到 50% 以上。如果传输滞后是压缩或加密造成的，那么在数据保护层花费的时间百分比将占大多数。
要禁用 krsb 统计，请将事件 16421 设置为 1 级：
alter session set events '16421 trace name context forever, level 1';
调整同步重做传输并排除故障
在继续之前，请首先查看评估和优化网络性能。
以下主题将介绍如何评估同步重做传输。
- 了解同步传输如何确保数据完整性
- 评估同步重做传输环境中的性能
- 日志文件同步等待事件为何具有误导性
- 了解导致异常值的原因
- 同步重做传输远程写入的影响
- 同步重做传输性能故障排除示例
了解同步传输如何确保数据完整性
以下算法可确保 Oracle Data Guard 同步重做传输配置中的数据一致性。
-
日志写入程序 (LGWR) 对主库联机重做日志的重做写入与 Data Guard 网络服务服务器 (NSS) 对备库重做日志的重做写入完全相同。
-
除非 redo log 已写入主库联机重做日志，否则备库 Data Guard 受管恢复进程 Managed Recovery Process (MRP) 无法应用重做日志，唯一的例外是在 Data Guard 故障切换操作期间（当主库消失时）。
In addition to shipping redo synchronously, NSS and LGWR exchange information regarding the safe redo block boundary that standby recovery can apply up to from its standby redo logs (SRLs). This prevents the standby from applying redo it may have received, but which the primary has not yet acknowledged as committed to its own online redo logs.
除了同步传输重做外，NSS 和 LGWR 还会交换有关安全重做块边界的信息，备库恢复最多可从其备库重做日志 (SRL) 中应用重做。这可防止备库恢复应用其可能已收到、但主库恢复尚未确认已提交到其自身在线重做日志中的重做日志。
可能出现的故障情况包括:
-
如果主库 LGWR 无法写入联机重做日志，那么 LGWR 和实例就会崩溃。实例或崩溃恢复将恢复到联机重做日志中最后提交的事务，并回滚任何未提交的事务。当前日志将完成并存档。
-
在备库日志中，部分备库重做日志将以正确的大小值完成，以匹配相应的联机重做日志。如果备库重做日志中缺少任何重做块，这些重做块将被运送过去（而不会重新运送整个重做日志）。
-
如果主库崩溃导致自动或手动零数据丢失故障切换，那么 Data Guard 故障切换操作的一部分将执行 “终端恢复”，并读取和恢复当前的备库重做日志。
一旦恢复完成应用备库重做日志中的所有重做日志，新的主库就会启动并归档新完成的日志组。所有新的和现有的备库都会丢弃在线重做日志中的任何重做日志，闪回到一致的系统变更号 (SCN)，并只应用来自新的主库的存档。Data Guard 环境再次与（新）主库同步。
评估同步重做传输环境中的性能
评估 Oracle Data Guard 同步重做传输环境 (SYNC) 中的性能时，了解不同等待事件之间的关系非常重要。启用同步重做传输的影响因应用程序而异。
要了解其原因，请参阅日志写入器进程 (LGWR) 在发出提交时执行的以下工作描述。
- 前台进程发布 LGWR 以进行提交（“日志文件同步 ”启动）。如果有并发的提交请求排队等候，LGWR 会将所有未处理的提交请求批处理在一起，形成连续的重做。
- LGWR 等待 CPU。
- LGWR 开始重做写入（“重做写入时间 ”开始）。
- 对于 Oracle RAC 数据库，LGWR 会向其他实例广播当前写入情况。
- 预处理后，如果有 SYNC 待机，LGWR 会启动远程写入（“SYNC 远程写入 ”开始）。
- LGWR 发出本地写入（“日志文件并行写 log file parallel write”）。
- 如果存在 SYNC 待机，则 LGWR 等待远程写入完成。
- 检查 I/O 状态后，LGWR 结束 “重写时间/SYNC 远程写入”。
- 对于 Oracle RAC 数据库，LGWR 会等待广播应答。
- LGWR 更新磁盘上的 SCN。
- LGWR 发布前台。
- 前台等待 CPU。
- 前台结束 “日志文件同步 log file sync”。
使用以下方法评估性能。
-
对于批量加载，最重要的因素是监控已用时间，因为这些进程大多必须在固定时间内完成。这些操作的数据库工作负载与正常的 OLTP 工作负载有很大不同。例如，写入的大小可能大得多，因此使用日志文件同步平均值无法提供准确的视图或比较。
-
对于 OLTP 工作负载，可监控每秒事务量（来自自动工作负载存储库 (AWR)）和来自 AWR 报告的重做率（每秒重做大小）。通过这些信息，您可以清楚地了解应用程序吞吐量以及启用同步重做传输对其产生的影响。
重做应用故障排除和调整
大多数 Oracle Data Guard 配置应能够通过故障排除和重做应用调整最大限度地减少应用延迟。重做应用性能直接取决于备库系统的性能。
此处提供的指导假定遵循了 MAA 配置最佳实践。作为前提条件，确保实施 Oracle Data Guard 配置最佳实践。
要全面提高应用性能，请利用以下主题中介绍的数据收集和故障排除方法。
了解重做应用和重做应用性能预期
备库恢复是重放所有 DML 和 DDL 操作的过程。高级流程是：
- 从主库接收重做，并将其写入备库重做日志 standby redo logs(SRL)。当数据库是 Oracle RAC 数据库时，每个线程（实例）都存储在其分配的 SRL 中。
- 日志合并进程（有时也称为恢复协调器）会合并重做线程，并将由此产生的变更向量放入内存缓冲区。
- 恢复工作进程会确定需要哪些数据块，并将尚未存在的数据块读入缓冲区缓存。然后，工作进程将变更向量应用到缓冲缓存中的数据块。
- 在检查点时间，数据库写入进程会将经过验证的缓冲区更改写入数据文件，并将数据库的检查点时间戳（称为系统提交编号 (SCN)）提前。检查点可能是恢复过程中最大的 I/O 负载。
重做应用性能预期
性能和由此产生的应用率主要取决于正在恢复的工作负载类型，以及分配给恢复和可用于恢复的系统资源。
Oracle 建议主库和备库系统是对称的（即所有配置完全一样），包括同等的 I/O 子系统、内存和 CPU 资源。提出这一建议的主要原因是，无论哪个数据库是主库，应用程序都能以相同的水平运行；不过，重做应用性能也能从对称的主库和备库中大大受益。数据保护（DB_BLOCK_CHECKING、DB_BLOCK_CHECKSUM、DB_LOST_WRITE_PROTECT）等功能需要 CPU 和 I/O 资源，使用 Oracle Active Data Guard 对备库进行报告也是如此。
在大多数情况下，重做应用性能应能跟上重做生成率，因此在系统资源对称的情况下，应用滞后几乎为零。在高峰工作负载期间，可能会出现轻微的重做应用差距，一旦工作负载恢复到正常水平，这种差距就会自然缩小到接近于零。
OLTP 工作负载
在线事务处理 (OLTP) 工作负载的恢复可能会非常密集 I/O，因为 OLTP 工作负载会对许多不同的数据块执行小的更改。这就导致在恢复期间，缓冲缓存中会有大量的小随机块读取。随后，数据库写入程序会运行大批量的写入 I/O，以维护缓冲缓存并定期检查数据库。因此，OLTP 工作负载的恢复需要存储子系统处理大量每秒 I/Os (IOPS)，以达到最佳速率。这也是建议主库和备库系统对称的另一个原因。
在没有资源瓶颈的 Oracle Exadata 数据库四分之一机架系统上进行的 OLTP 工作负载恢复测试（由 swingbench 生成）达到了约 150 MB/秒的应用速率。客户在较大的 Exadata 系统上观察到，单实例重做应用的速度超过了 200 MB/秒。由于 I/O 和网络吞吐量较低，在非 Exadata 系统中实现这些速率更具挑战性。
批处理工作负载
与 OLTP 工作负载恢复相比，批处理工作负载恢复的效率更高，因为批处理工作负载由大量顺序读写组成。在读取和修改明显较少的数据块时，会发生更多的重做更改，因此重做应用率要比 OLTP 工作负载快得多。此外，批量直接加载操作恢复优化可提高效率和恢复率。
在没有阻碍系统资源瓶颈的情况下，使用批量负载或并行 DML（PDML）工作负载，在小型 Exadata 数据库四分之一机架系统上进行内部重做应用测试，结果应用率约为 200-300 MB/秒。在大型 Exadata 系统的批处理工作负载中，客户观察到单实例重做应用的应用率超过 600 MB/秒。非 Exadata 系统也能达到这些速率，但需要系统资源容量以及可扩展的网络和 I/O 子系统来处理这些要求苛刻的工作负载。
混合工作负载
OLTP 和批处理恢复性能配置文件之间的差异以及不同的系统形状解释了为什么混合了 OLTP 和批处理工作负载的应用程序在备用数据库中会有不同的恢复率，即使主库的重做生成率相似。客户在使用各种 Exadata 系统时，通过各种混合工作负载实现了 100-1100 MB/秒的重做应用率。非 Exadata 系统也能达到这些速率，但需要系统资源容量和可扩展的数据库计算、网络和 I/O 子系统来处理这些要求苛刻的工作负载。非 Exadata 系统很少能达到这些极高的重做应用速度。
追赶重做应用性能预期
与实时重做应用相比，“追赶 ”期间的重做应用可能需要更多的系统资源。如果存在较大的重做差距，请参阅 “处理非常大的重做应用差距 ”以获取建议。
验证 apply 延迟
恢复性能会随工作负载类型和主库的重做生成率而变化。较低的应用率并不一定表明存在恢复性能问题。但是，持续或不断增加的应用延迟（不伴有传输延迟）是恢复性能瓶颈的最佳指示。
要确定并量化应用延迟和传输延迟，请查询备用数据库中的 V$DATAGUARD_STATS 视图。
SQL> select name, value, time_computed, datum_time from v$dataguard_stats where name like '%lag';
DATUM_TIME 列是收到用于计算指标的数据时备用数据库的本地时间。延迟指标是根据定期从主数据库接收的数据计算的。如果此列中的值在多次查询中保持不变，则表明备用数据库没有从主库接收数据。在这种情况下，潜在的数据丢失时间是从 V$DATAGUARD_STATS 的最后基准时间到备用数据库的当前时间。
要获取显示自上次启动备用实例以来传输或应用延迟值历史记录的直方图，请查询 V$STANDBY_EVENT_HISTOGRAM 视图。
SQL> select * from v$standby_event_histogram where name like '%lag' and count >0;
要评估一个时间段内的传输或应用延迟情况，可在该时间段开始时拍摄备库中 V$STANDBY_EVENT_HISTOGRAM 的快照，并将该快照与该时间段结束时拍摄的快照进行比较。
SQL> col NAME format a10
SQL> select NAME,TIME,UNIT,COUNT,LAST_TIME_UPDATED from V$STANDBY_EVENT_HISTOGRAM
where name like '%lag' and count >0 order by LAST_TIME_UPDATED;
NAME TIME UNIT COUNT LAST_TIME_UPDATED
---------- ------ ---------- ----- -------------------
apply lag 23 seconds 3 02/05/2022 16:30:59
apply lag 135 seconds 1 02/05/2022 16:31:02
apply lag 173 seconds 2 02/05/2022 16:32:03
apply lag 295 seconds 2 02/05/2022 16:34:04
查看每个归档生成率
该查询在现有数据库上运行时计算每个日志的重做生成率。（根据需要更改时间戳）
SELECT THREAD#, SEQUENCE#, BLOCKS*BLOCK_SIZE/1024/1024 MB,
(NEXT_TIME-FIRST_TIME)*86400 SEC,
(BLOCKS*BLOCK_SIZE/1024/1024)/((NEXT_TIME-FIRST_TIME)*86400) "MB/S"
FROM V$ARCHIVED_LOG
WHERE ((NEXT_TIME-FIRST_TIME)*86400<>0)
AND FIRST_TIME BETWEEN TO_DATE('2024/09/15 08:00:00','YYYY/MM/DD HH24:MI:SS')
AND TO_DATE('2024/09/15 11:00:00','YYYY/MM/DD HH24:MI:SS')
AND DEST_ID=1 ORDER BY FIRST_TIME;
THREAD# SEQUENCE# MB SEC MB/s
------- --------- ---------- ---------- ----------
2 2291 29366.1963 831 35.338383
1 2565 29365.6553 781 37.6000708
2 2292 29359.3403 537 54.672887
1 2566 29407.8296 813 36.1719921
2 2293 29389.7012 678 43.3476418
2 2294 29325.2217 1236 23.7259075
1 2567 11407.3379 2658 4.29169973
2 2295 24682.4648 477 51.7452093
2 2296 29359.4458 954 30.7751004
2 2297 29311.3638 586 50.0193921
1 2568 3867.44092 5510 .701894903
在这个简短的例子中，最高速率约为 52MB/s。理想情况下，网络将支持此应用的最大速率加上 30% 或 68MB/s。
检测和监控数据损坏
如果损坏的数据写入磁盘，或者如果组件故障导致良好数据在写入后会损坏，那么需要检测损坏的块。
要监视数据库的错误和警报，请执行以下作：
-
查询 V$DATABASE_BLOCK_CORRUPTION 视图自动在检测到或修复块损坏时更新。
-
配置数据恢复顾问，以自动诊断数据故障、确定和提供适当的修复选项，并根据您的要求执行修复操作。
请注意，Data Recovery Advisor 与 Oracle Enterprise Manager Support Workbench（支持工作台）、Health Monitor 和 RMAN 集成。
- 使用 Data Guard 检测物理损坏并检测丢失的写入。
当应用进程因损坏的块而停止或检测到写入丢失时，Data Guard 可检测到物理损坏。
使用 Enterprise Manager 管理和监控 Data Guard 配置。
利用自动块介质恢复功能，在使用 Active Data Guard 选项时，可以自动修复在主数据库或物理备用数据库中发现的损坏块。
- 使用 SQL*Plus 检测数据文件损坏和块间损坏。
运行以下 SQL*Plus 语句：
sqlplus> ANALYZE TABLE table_name VALIDATE STRUCTURE CASCADE;
发现损坏后，可以重新创建表或采取其他措施。
Recovery Manager (RMAN) 备份和恢复策略可以检测物理块损坏。
使用以下命令进行更深入的 RMAN 检查可以检测逻辑块损坏。
RMAN> BACKUP VALIDATE CHECK LOGICAL;
本文节选自 Oracle 官方文档《高可用性概述和最佳实践》第四部分 “Oracle Data Guard 最佳实践”，这里仅是抛砖引玉，更多精彩内容请感兴趣的读者自行探索，谢谢！ https://docs.oracle.com/en/database/oracle/oracle-database/23/haovw/oracle-data-guard-best-practices.html#GUID-9A616956-9053-4502-895A-724773D6F84F
参考链接
https://docs.oracle.com/en/database/oracle/oracle-database/23/haovw/plan-oracle-data-guard-deployment.html#GUID-7354549E-C8CC-437B-BF52-F0F76522F432
https://docs.oracle.com/en/database/oracle/oracle-database/23/haovw/tune-and-troubleshoot-oracle-data-guard.html#GUID-304DC1A2-1820-4D68-A174-B97567D48A4E
全文完，希望可以帮到正在阅读的你，如果觉得有帮助，可以分享给你身边的朋友，同事，你关心谁就分享给谁，一起学习共同进步~~~
❤️ 欢迎关注我的公众号【JiekeXu DBA之路】，一起学习新知识！
——————————————————————————
公众号：JiekeXu DBA之路
墨天轮：https://www.modb.pro/u/4347
CSDN ：https://blog.csdn.net/JiekeXu
ITPUB：https://blog.itpub.net/69968215
腾讯云：https://cloud.tencent.com/developer/user/5645107
——————————————————————————
