Linux下DataGuard无法应用归档日志的处理过程

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了Linux下DataGuard无法应用归档日志的处理过程，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含4770字，纯文字阅读大概需要7分钟。

内容图文

OS:Red Hat Linux As 5DB:11.2.0.1今天发现在主库的表上写入了数据,且做了日志切换后发现数据没有传输到备库,查看备库的alert报如

环境:
OS:Red Hat Linux As 5
DB:11.2.0.1

今天发现在主库的表上写入了数据,且做了日志切换后发现数据没有传输到备库,查看备库的alert报如下错误:

Datafiles are recovered to a consistent state at change 2610390 but controlfile is ahead at change 2610391.
Database remains open for continuous queries. Please continue recovery.
Errors in file /u01/app/Oracle/diag/rdbms/oraclbak/oraclbak/trace/oraclbak_mrp0_4332.trc:
ORA-01237: cannot extend datafile 4
ORA-01110: data file 4: '/u01/app/oracle/oradata/oracl/users01.dbf'
ORA-19502: write error on file "/u01/app/oracle/oradata/oracl/users01.dbf", block number 723584 (block size=8192)
ORA-27072: File I/O error
Linux Error: 25: Inappropriate ioctl for device
看到以上错误,应该是users表空间不足导致的,但users表空间的数据文件是自动扩展的呀,数据文件怎么会报无法扩展呢,想了一会,在主库和备库使用df查看磁盘空间,发现数据文件user01.dbf所在的目录已经用满,这个时候马上清理该目录下的文件,腾出一些空间.过程处理如下.

1.查看主库和备库磁盘使用情况
[oracle@stdby oracl]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 6146832 4321584 1507968 75% /
tmpfs 2097152 400408 1696744 20% /dev/shm
/dev/sdb1 20635700 19525276 62188 100% /u01
/dev/sdc1 8254240 6356052 1478896 82% /u02

发现存放数据文件的目录/u01已经使用了100%.

2.在备库上查看日志使用情况
Select Sequence#, Name, Applied From V$archived_Log Order By Sequence#;
------------------------------------------------------------------------
SEQUENCE# NAME APPLIED
9 /u02/archive_log/1_9_792174458.dbf YES
10 /u02/archive_log/1_10_792174458.dbf YES
11 /u02/archive_log/1_11_792174458.dbf YES
12 /u02/archive_log/1_12_792174458.dbf YES
13 /u02/archive_log/1_13_792174458.dbf YES
14 /u02/archive_log/1_14_792174458.dbf YES
15 /u02/archive_log/1_15_792174458.dbf YES
16 /u02/archive_log/1_16_792174458.dbf YES
17 /u02/archive_log/1_17_792174458.dbf YES
18 /u02/archive_log/1_18_792174458.dbf YES
19 /u02/archive_log/1_19_792174458.dbf YES
20 /u02/archive_log/1_20_792174458.dbf YES
21 /u02/archive_log/1_21_792174458.dbf YES
22 /u02/archive_log/1_22_792174458.dbf YES
23 /u02/archive_log/1_23_792174458.dbf YES
24 /u02/archive_log/1_24_792174458.dbf YES
25 /u02/archive_log/1_25_792174458.dbf YES
26 /u02/archive_log/1_26_792174458.dbf YES
27 /u02/archive_log/1_27_792174458.dbf YES
28 /u02/archive_log/1_28_792174458.dbf YES
29 /u02/archive_log/1_29_792174458.dbf YES
30 /u02/archive_log/1_30_792174458.dbf YES
31 /u02/archive_log/1_31_792174458.dbf YES
32 /u02/archive_log/1_32_792174458.dbf YES
33 /u02/archive_log/1_33_792174458.dbf YES
34 /u02/archive_log/1_34_792174458.dbf NO
35 /u02/archive_log/1_35_792174458.dbf NO

发现34和35没有使用

3.主备库腾出部分空间后,在备库上使用如下命令应用日志
recover managed standby database disconnect from session;

4.这个时候看到日志应用的进程
select process,status,sequence# from v$managed_standby;
--------------------------------------------------
PROCESS STATUS SEQUENCE#
ARCH CLOSING 34
ARCH CLOSING 35
ARCH CLOSING 31
ARCH CONNECTED 0
MRP0 APPLYING_LOG 35
RFS IDLE 0
RFS IDLE 0
RFS IDLE 36

5.再次查询备库日志应用情况
Select Sequence#, Name, Applied
From V$archived_Log Order By Sequence#;
-----------------------------------------
SEQUENCE# NAME APPLIED
9 /u02/archive_log/1_9_792174458.dbf YES
10 /u02/archive_log/1_10_792174458.dbf YES
11 /u02/archive_log/1_11_792174458.dbf YES
12 /u02/archive_log/1_12_792174458.dbf YES
13 /u02/archive_log/1_13_792174458.dbf YES
14 /u02/archive_log/1_14_792174458.dbf YES
15 /u02/archive_log/1_15_792174458.dbf YES
16 /u02/archive_log/1_16_792174458.dbf YES
17 /u02/archive_log/1_17_792174458.dbf YES
18 /u02/archive_log/1_18_792174458.dbf YES
19 /u02/archive_log/1_19_792174458.dbf YES
20 /u02/archive_log/1_20_792174458.dbf YES
21 /u02/archive_log/1_21_792174458.dbf YES
22 /u02/archive_log/1_22_792174458.dbf YES
23 /u02/archive_log/1_23_792174458.dbf YES
24 /u02/archive_log/1_24_792174458.dbf YES
25 /u02/archive_log/1_25_792174458.dbf YES
26 /u02/archive_log/1_26_792174458.dbf YES
27 /u02/archive_log/1_27_792174458.dbf YES
28 /u02/archive_log/1_28_792174458.dbf YES
29 /u02/archive_log/1_29_792174458.dbf YES
30 /u02/archive_log/1_30_792174458.dbf YES
31 /u02/archive_log/1_31_792174458.dbf YES
32 /u02/archive_log/1_32_792174458.dbf YES
33 /u02/archive_log/1_33_792174458.dbf YES
34 /u02/archive_log/1_34_792174458.dbf YES
35 /u02/archive_log/1_35_792174458.dbf YES

这个时候34,35都已经应用了,应用层的数据,主库和备库已经保持一致了.

-- The End --

，

内容总结

以上是互联网集市为您收集整理的Linux下DataGuard无法应用归档日志的处理过程全部内容，希望文章能够帮你解决Linux下DataGuard无法应用归档日志的处理过程所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---