环境:
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 —
，