国庆快乐。
今天遇到个adg主库归档满了的问题。因为是adg,所以不能粗暴的直接用rman去delete copy
,需要看归档日志是否传输到了备库,以及备库是否已经应用了才能删除。
查问题的步骤
- 查看主备库的日志传输情况
SELECT * FROM V$ARCHIVE_DEST WHERE STATUS='VALID';
- 检查归档进程:
确保归档进程 (ARCn) 在运行。
使用以下命令检查归档进程的状态:
SQL> select * from V$ARCHIVE_PROCESSES;
PROCESS STATUS LOG_SEQUENCE STAT ROLES
---------- ---------- ------------ ---- ------------------------------------
0 ACTIVE 0 IDLE
1 ACTIVE 6670 IDLE HEART_BEAT
2 ACTIVE 0 IDLE NO_FAL NO_SRL
3 ACTIVE 0 IDLE
4 ACTIVE 0 IDLE
5 ACTIVE 0 IDLE
6 ACTIVE 0 IDLE
7 ACTIVE 0 IDLE
8 STOPPED 0 IDLE
9 STOPPED 0 IDLE
...
...
29 STOPPED 0 IDLE
30 rows selected.
- 查询已经同步的最大日志序列号:
SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG where APPLIED='YES';
- 查看备库的日志应用情况
检查 MRP 进程:
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY;
PROCESS STATUS THREAD# SEQUENCE#
--------- ------------ ---------- ----------
ARCH CLOSING 1 6687
ARCH CLOSING 1 6688
ARCH CONNECTED 0 0
ARCH CLOSING 1 6684
MRP0 APPLYING_LOG 1 2567
RFS IDLE 0 0
RFS IDLE 1 6689
RFS IDLE 0 0
ARCH CONNECTED 0 0
ARCH CONNECTED 0 0
ARCH CONNECTED 0 0
ARCH CONNECTED 0 0
这个可以看到MRP0进程正在应用归档日志,目前应用到了2567号日志,当前主库最大的日志号是6689。
如果这里的查询结果为空,说明MRP进程没有被启动,这个是有问题的,需要手工启动MRP进程。方法如下:
STARTUP MOUNT;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS LIKE 'MRP%';
在启动 MRP 进程之前,请确保备库处于 MOUNT 状态。
如果备库已经在运行 MRP 进程,需要先停止它(shutdown immediate),然后再重新启动。停止 MRP 进程的命令是:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
如果环境中有多个线程(例如 RAC),需要为每个线程启动一个 MRP 进程。
启动 MRP 进程后,备库将开始从主数据库应用归档日志,确保数据在两个数据库之间保持同步。
- 在备库上查询是否有错误
SELECT DEST_ID,STATUS, ERROR FROM V$ARCHIVE_DEST WHERE TARGET='REMOTE';
- 在主备库上删除已经应用的归档日志
rman target /
DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE = <sequence_number>;
至此,解决了主备库因为磁盘慢而导致的数据不一致的问题,剩下的就是慢慢等待备库慢慢将归档日志应用起来追上最新的主库的日志。
如何提高ADG备库的归档日志应用速度
除此之外,我们应该有一个重要的想法,那就是:怎么提高备库的归档日志的应用速度!
- 首先是提高传输速度:
设置参数LOG_ARCHIVE_MAX_PROCESSES ,它定义了归档进程的数量,这些进程用于从在线重做日志文件中复制重做日志到归档日志目的地。增加 LOG_ARCHIVE_MAX_PROCESSES 的值可以提高归档日志从在线重做日志到归档日志目的地的复制速度,特别是当有多个归档日志目的地时。
如果主库生成重做日志的速度很快,增加归档进程的数量可以帮助减少归档日志的积压。
尽管 LOG_ARCHIVE_MAX_PROCESSES 不直接影响备库上的归档日志应用,但如果主库能够更快地将归档日志发送到备库,那么备库上的延迟将会减少。
SHOW PARAMETER LOG_ARCHIVE_MAX_PROCESSES;
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=8;
设置好之后,用以下SQL进行查询:
SELECT * FROM V$ARCHIVE_PROCESSES;
这将显示归档进程的状态和活动,看到与设置的归档进程数量相匹配的行数。
注意:
- 在增加归档进程数量之前,请确保系统有足够的资源来处理额外的进程。
- 调整归档进程数量可能会影响系统的性能,因此建议在更改生产环境之前先在测试环境中验证。
- 其次是提高应用速度:
LOG_ARCHIVE_MAX_PROCESSES参数决定了归档进程 (ARCn) 的数量,这些进程在 Oracle 数据库中负责从在线重做日志文件中复制重做日志到归档日志目的地。但是,这与备库上的归档日志的应用是两个不同的过程。备库上的归档日志的应用是由 Managed Recovery Process (MRP) 或 Redo Apply 进程完成的。
- 增加并行度:使用多个并行恢复进程可以加速日志的应用,通过设置 PARALLEL_MAX_SERVERS 参数来增加并行恢复进程的数量。
ALTER SYSTEM SET PARALLEL_MAX_SERVERS=8;
- 优化I/O性能:
- 确保备库的存储子系统性能良好。使用高性能的存储解决方案,如 SSD。
- 优化备库的 I/O 分布,确保归档日志、在线日志和数据文件位于不同的磁盘或 LUN 上。
- 调整Redo Apply参数:
- 使用
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
命令的 DISCONNECT 选项,允许日志应用在后台运行。 - 考虑使用实时应用 (REAL TIME APPLY),这允许日志记录在传输到备库后立即被应用,而不是等待整个归档日志文件传输完成。
- 使用
- 优化网络:
- 确保主库和备库之间的网络连接是高带宽和低延迟的。
- 使用压缩功能 (COMPRESSION=ENABLE) 可以减少传输的数据量,从而加速网络传输。
- 调整内存分配:
- 增加 LOG_BUFFER 的大小可以帮助提高日志应用的速度。
- 考虑增加 SGA 和 PGA 的大小,以提供更多的内存给恢复进程。
- 监控并解决任何等待事件:使用 Oracle 的等待事件界面,特别是
V$SESSION_WAIT
和V$SYSTEM_EVENT
视图,来识别和解决可能影响日志应用速度的任何瓶颈。 -
考虑使用快速增量恢复
其他一些需要注意的地方
参数的问题
删除的策略问题
如何设置备库的数据要晚一个归档日志