文档课题：运用备库数据文件rman备份对另一个备库单个坏块的恢复.
数据库：oracle 11.2.0.4
环境：rac(2节点)+dg(2个)
系统：rhel 7.9
应用场景：备库存在单个索引块损坏，此时DBA希望用另一个备库的rman备份对损坏的数据块所在的数据文件进行修复，此文章将对该场景进行测试.
1、建测试数据
1.1、建表空间
SYS@orcl1> create tablespace tbs_tst_idx datafile '+data' size 10m autoextend on;
Tablespace created.
SYS@orcl1> select name,bytes/1024/1024 "size(M)" from v$datafile;
NAME size(M)
------------------------------------------------------------ ----------
+DATA/orcl/datafile/system.259.1132745549 1060
+DATA/orcl/datafile/sysaux.260.1132745551 600
+DATA/orcl/datafile/undotbs1.261.1132745553 840
+DATA/orcl/datafile/undotbs2.263.1132745567 200
+DATA/orcl/datafile/users.264.1132745567 5
+DATA/orcl/datafile/users.285.1133862437 50
+DATA/orcl/datafile/users.284.1133862457 50
+DATA/orcl/datafile/users.283.1133862473 50
+DATA/orcl/datafile/users.282.1133862489 50
+DATA/orcl/datafile/users.281.1133862509 50
+DATA/orcl/datafile/users.280.1133862525 50
NAME size(M)
------------------------------------------------------------ ----------
+DATA/orcl/datafile/users.279.1133862553 50
+DATA/orcl/datafile/users.278.1133862571 50
+DATA/orcl/datafile/users.277.1133862585 50
+DATA/orcl/datafile/users.276.1133862603 50
+DATA/orcl/datafile/users.275.1133862625 50
+DATA/orcl/datafile/users.274.1133862645 50
+DATA/orcl/datafile/tbs_tst_idx.286.1134752063 10
18 rows selected.
1.2、建测试用户
SYS@orcl1> create user leo identified by leo;
User created.
SYS@orcl1> grant select on dba_objects to leo;
Grant succeeded.
SYS@orcl1> grant connect,resource,unlimited tablespace to leo;
Grant succeeded.
SYS@orcl1> grant create any index to leo;
Grant succeeded.
1.3、建测试表
SYS@orcl1> conn leo/leo;
Connected.
LEO@orcl1> create table tb_obj tablespace users as select * from dba_objects;
Table created.
LEO@orcl1> insert into tb_obj select * from tb_obj;
86291 rows created.
LEO@orcl1> insert into tb_obj select * from tb_obj;
172582 rows created.
LEO@orcl1> insert into tb_obj select * from tb_obj;
345164 rows created.
……
LEO@orcl1> commit;
Commit complete.
LEO@orcl1> select count(*) from tb_obj;
COUNT(*)
----------
2761312
--查表大小
SYS@orcl1> select blocks,bytes from dba_segments where owner='LEO' and segment_name='TB_OBJ';
BLOCKS BYTES
---------- ----------
39936 327155712
1.4、建测试索引
LEO@orcl1> create index IDX_OBJ_NAME on TB_OBJ(OBJECT_NAME) tablespace tbs_tst_idx;
Index created.
LEO@orcl1> col column_name for a15
LEO@orcl1> select index_name,table_name,column_name from user_ind_columns;
INDEX_NAME TABLE_NAME COLUMN_NAME
------------------------------ ------------------------------ ---------------
IDX_OBJ_NAME TB_OBJ OBJECT_NAME
LEO@orcl1> col index_name for a15
LEO@orcl1> col index_type for a15
LEO@orcl1> col table_owner for a15
LEO@orcl1> col table_name for a15
LEO@orcl1> select index_name,index_type,table_owner,table_name,table_type from user_indexes where table_name='TB_OBJ';
INDEX_NAME INDEX_TYPE TABLE_OWNER TABLE_NAME TABLE_TYPE
--------------- --------------- --------------- --------------- -----------
IDX_OBJ_NAME NORMAL LEO TB_OBJ TABLE
--查索引大小
SYS@orcl1> select blocks,bytes from dba_segments where owner='LEO' and segment_name='IDX_OBJ_NAME';
BLOCKS BYTES
---------- ----------
14336 117440512
1.5、表和索引相关信息
LEO@orcl1> select table_name,index_name,blevel,leaf_blocks,num_rows,last_analyzed,degree,status from user_indexes where table_name='TB_OBJ';
TABLE_NAME INDEX_NAME BLEVEL LEAF_BLOCKS NUM_ROWS LAST_ANALYZED DEGREE STATUS
--------------- --------------- ---------- ----------- ---------- ------------------ ---------------------------------------- --------
TB_OBJ IDX_OBJ_NAME 2 14318 2850580 06-MAY-23 1 VALID
--查索引及表的object_id
LEO@orcl1> select object_id from user_objects where object_name='IDX_OBJ_NAME';
OBJECT_ID
----------
87191
SYS@orcl1> select object_id,object_name from dba_objects where owner='LEO';
OBJECT_ID OBJECT_NAME
---------- ---------------
87190 TB_OBJ
87191 IDX_OBJ_NAME
2、模拟索引坏块
说明：备库orcldg使用dd命令模拟索引坏块。
2.1、查索引所在块
SYS@orcldg> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY
SYS@orcldg> col name for a60
SYS@orcldg> set line 200
SYS@orcldg> select file#,name,bytes/1024/1024 "size(M)" from v$datafile;
FILE# NAME size(M)
---------- ------------------------------------------------------------ ----------
1 /u01/app/oracle/oradata/system.259.1132745549 1060
2 /u01/app/oracle/oradata/sysaux.260.1132745551 620
3 /u01/app/oracle/oradata/undotbs1.261.1132745553 840
4 /u01/app/oracle/oradata/undotbs2.263.1132745567 200
5 /u01/app/oracle/oradata/users.264.1132745567 5
6 /u01/app/oracle/oradata/users.285.1133862437 50
7 /u01/app/oracle/oradata/users.284.1133862457 50
8 /u01/app/oracle/oradata/users.283.1133862473 50
9 /u01/app/oracle/oradata/users.282.1133862489 50
10 /u01/app/oracle/oradata/users.281.1133862509 50
11 /u01/app/oracle/oradata/users.280.1133862525 50
FILE# NAME size(M)
---------- ------------------------------------------------------------ ----------
12 /u01/app/oracle/oradata/users.279.1133862553 50
13 /u01/app/oracle/oradata/users.278.1133862571 50
14 /u01/app/oracle/oradata/users.277.1133862585 50
15 /u01/app/oracle/oradata/users.276.1133862603 50
16 /u01/app/oracle/oradata/users.275.1133862625 50
17 /u01/app/oracle/oradata/users.274.1133862645 50
18 /u01/app/oracle/oradata/tbs_tst_idx.286.1134752063 220
18 rows selected.
--以下查索引所在数据块
SYS@orcldg> select extent_id,file_id,block_id,blocks from dba_extents where owner='LEO' and segment_name='IDX_OBJ_NAME' order by 1;
EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
0 18 3848 8
1 18 3856 8
2 18 3864 8
3 18 3872 8
4 18 3880 8
5 18 3888 8
6 18 3896 8
7 18 3904 8
8 18 3912 8
9 18 3920 8
10 18 3928 8
EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
11 18 3936 8
12 18 3944 8
13 18 3952 8
14 18 3960 8
15 18 128 8
16 18 256 128
17 18 384 128
18 18 512 128
19 18 640 128
20 18 768 128
21 18 896 128
EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
22 18 1024 128
23 18 1152 128
24 18 1280 128
25 18 1408 128
26 18 1536 128
27 18 1664 128
28 18 1792 128
29 18 1920 128
30 18 2048 128
31 18 2176 128
32 18 2304 128
EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
33 18 2432 128
34 18 2560 128
35 18 2688 128
36 18 2816 128
37 18 2944 128
38 18 3072 128
39 18 3200 128
40 18 3328 128
41 18 3456 128
42 18 3584 128
43 18 3712 128
EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
44 18 3968 128
45 18 4096 128
46 18 4224 128
47 18 4352 128
48 18 4480 128
49 18 4608 128
50 18 4736 128
51 18 4864 128
52 18 4992 128
53 18 5120 128
54 18 5248 128
EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
55 18 5376 128
56 18 5504 128
57 18 5632 128
58 18 5760 128
59 18 5888 128
60 18 6016 128
61 18 6144 128
62 18 6272 128
63 18 6400 128
64 18 6528 128
65 18 6656 128
EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
66 18 6784 128
67 18 6912 128
68 18 7040 128
69 18 7168 128
70 18 7296 128
71 18 7424 128
72 18 7552 128
73 18 7680 128
74 18 7808 128
75 18 7936 128
76 18 8064 128
EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
77 18 8192 128
78 18 8320 128
79 18 8448 1024
80 18 9472 1024
81 18 10496 1024
82 18 11520 1024
83 18 12544 1024
84 18 13568 1024
85 rows selected.
2.2、损坏索引块
--运用dd命令损坏备库orcldg索引块.
[oracle@hisdbdg ~]$ dd of=/u01/app/oracle/oradata/tbs_tst_idx.286.1134752063 bs=8192 conv=notrunc seek=11521 <<EOF
> Corrupted block!
> EOF
0+1 records in
0+1 records out
17 bytes (17 B) copied, 0.000124453 s, 137 kB/s
2.3、验证索引块损坏
[oracle@hisdbdg ~]$ dbv file=/u01/app/oracle/oradata/tbs_tst_idx.286.1134752063
DBVERIFY: Release 11.2.0.4.0 - Production on Sat May 6 11:22:04 2023
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = /u01/app/oracle/oradata/tbs_tst_idx.286.1134752063
Page 11521 is marked corrupt
Corrupt block relative dba: 0x04802d01 (file 18, block 11521)
Bad header found during dbv:
Data in bad block:
type: 67 format: 7 rdba: 0x65747075
last change scn: 0x636f.6c622064 seq: 0x6b flg: 0x21
spare1: 0x72 spare2: 0x72 spare3: 0x0
consistency value in tail: 0x34082001
check value in block header: 0x10a
block checksum disabled
DBVERIFY - Verification complete
Total Pages Examined : 28160
Total Pages Processed (Data) : 0
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 26181
Total Pages Failing (Index): 0
Total Pages Processed (Other): 1844
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 134
Total Pages Marked Corrupt : 1
Total Pages Influx : 0
Total Pages Encrypted : 0
Highest block SCN : 1726162 (0.1726162)
[oracle@hisdbdg ~]$ rman target /
Recovery Manager: Release 11.2.0.4.0 - Production on Sat May 6 11:20:32 2023
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORCL (DBID=1660526279)
RMAN> backup check logical validate datafile 18;
Starting backup at 06-MAY-23
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=192 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00018 name=/u01/app/oracle/oradata/tbs_tst_idx.286.1134752063
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
18 FAILED 0 134 28161 1726162
File Name: /u01/app/oracle/oradata/tbs_tst_idx.286.1134752063
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 0
Index 0 26181
Other 1 1845
validate found one or more corrupt blocks
See trace file /u01/app/oracle/diag/rdbms/orcldg/orcldg/trace/orcldg_ora_2938.trc for details
Finished backup at 06-MAY-23
RMAN> exit
Recovery Manager complete.
[oracle@hisdbdg ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on Sat May 6 11:21:02 2023
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SYS@orcldg> select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
18 11521 1 0 CORRUPT
说明：如上所示，成功模拟出生产环境备库索引块的损坏.
3、备份数据文件
--在另一个备库sh_orcl备份损坏的数据文件.
SYS@sh_orcl> show parameter db_unique
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_unique_name string sh_orcl
SYS@sh_orcl> select open_mode,database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
READ ONLY WITH APPLY PHYSICAL STANDBY
[oracle@leo-shhisdbdg ~]$ rman target /
Recovery Manager: Release 11.2.0.4.0 - Production on Sat May 6 11:23:45 2023
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORCL (DBID=1660526279)
RMAN> backup as compressed backupset datafile 18 format '/home/oracle/backup/ForStandby18_%U' tag 'FORSTANDBY';
Starting backup at 06-MAY-23
using channel ORA_DISK_1
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00018 name=/u01/app/oracle/oradata/tbs_tst_idx.286.1134752063
channel ORA_DISK_1: starting piece 1 at 06-MAY-23
channel ORA_DISK_1: finished piece 1 at 06-MAY-23
piece handle=/home/oracle/backup/ForStandby18_281rff08_1_1 tag=FORSTANDBY comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07
Finished backup at 06-MAY-23
4、系统数据变化
说明：生产环境中在备库sh_orcl备份完毕后，主库很大可能在相应数据文件上有dml操作，使得数据与备份时不一致.
4.1、增加原有索引大小
--增加表leo.tb_obj记录，此时索引会自动维护，从而大小会发生变化.
SYS@orcl1> select blocks,bytes from dba_segments where owner='LEO' and segment_name='IDX_OBJ_NAME';
BLOCKS BYTES
---------- ----------
14336 117440512
SYS@orcl1> conn leo/leo;
Connected.
LEO@orcl1> select count(*) from tb_obj;
COUNT(*)
----------
2761312
LEO@orcl1> insert into tb_obj select * from tb_obj;
2761312 rows created.
LEO@orcl1> commit;
Commit complete.
LEO@orcl1> select count(*) from tb_obj;
COUNT(*)
----------
5522624
LEO@orcl1> conn / as sysdba
Connected.
SYS@orcl1> select blocks,bytes from dba_segments where owner='LEO' and segment_name='IDX_OBJ_NAME';
BLOCKS BYTES
---------- ----------
29696 243269632
说明：如上所示，索引大小由117440512 bytes增长到243269632 bytes.
4.2、添加索引
LEO@orcl1> create index idx_obj_timestamp on tb_obj(timestamp) tablespace tbs_tst_idx;
Index created.
LEO@orcl1> conn / as sysdba
Connected.
SYS@orcl1> select blocks,bytes from dba_segments where owner='LEO' and segment_name='IDX_OBJ_TIMESTAMP';
BLOCKS BYTES
---------- ----------
24576 201326592
说明：如上所示，主库新增名为IDX_OBJ_TIMESTAMP的索引，大小为201326592 bytes。
注意：增加索引IDX_OBJ_NAME大小，新建索引IDX_OBJ_TIMESTAMP均是在备库sh_orcl备份完之后发生的变化。
5、传输数据文件的备份集
[oracle@leo-shhisdbdg backup]$ ll
total 20296
-rw-r----- 1 oracle oinstall 20783104 May 6 11:25 ForStandby18_281rff08_1_1
[oracle@leo-shhisdbdg backup]$ scp ForStandby* oracle@192.168.133.215:/home/oracle/backup
6、执行恢复
6.1、复制原数据文件
--恢复18号数据文件之前，对其进行一个拷贝.
[oracle@hisdbdg oradata]$ cp tbs_tst_idx.286.1134752063 tbs_tst_idx_bak.286.1134752063
6.2、恢复数据文件
[oracle@hisdbdg backup]$ rman target /
Recovery Manager: Release 11.2.0.4.0 - Production on Sat May 6 11:37:28 2023
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORCL (DBID=1660526279)
RMAN> shutdown immediate;
using target database control file instead of recovery catalog
database closed
database dismounted
Oracle instance shut down
RMAN> startup mount;
connected to target database (not started)
Oracle instance started
database mounted
Total System Global Area 2455228416 bytes
Fixed Size 2255712 bytes
Variable Size 620758176 bytes
Database Buffers 1811939328 bytes
Redo Buffers 20275200 bytes
RMAN> catalog start with '/home/oracle/backup/ForStandby18_281rff08_1_1';
searching for all files that match the pattern /home/oracle/backup/ForStandby18_281rff08_1_1
List of Files Unknown to the Database
=====================================
File Name: /home/oracle/backup/ForStandby18_281rff08_1_1
Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /home/oracle/backup/ForStandby18_281rff08_1_1
RMAN> restore datafile 18;
Starting restore at 06-MAY-23
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=196 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00018 to /u01/app/oracle/oradata/tbs_tst_idx.286.1134752063
channel ORA_DISK_1: reading from backup piece /home/oracle/backup/ForStandby18_281rff08_1_1
channel ORA_DISK_1: piece handle=/home/oracle/backup/ForStandby18_281rff08_1_1 tag=FORSTANDBY
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
Finished restore at 06-MAY-23
7、备库验证
7.1、索引验证
--对索引的增量数据进行验证。
[oracle@hisdbdg backup]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on Fri May 5 16:18:02 2023
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SYS@orcldg> alter database open;
Database altered.
SYS@orcldg> alter database recover managed standby database using current logfile disconnect from session;
Database altered.
SYS@orcldg> select blocks,bytes from dba_segments where owner='LEO' and segment_name='IDX_OBJ_NAME';
BLOCKS BYTES
---------- ----------
29696 243269632
SYS@orcldg> select blocks,bytes from dba_segments where owner='LEO' and segment_name='IDX_OBJ_TIMESTAMP';
BLOCKS BYTES
---------- ----------
24576 201326592
说明：如上索引的增量数据成功显示.
7.2、坏块验证
[oracle@hisdbdg backup]$ rman target /
Recovery Manager: Release 11.2.0.4.0 - Production on Sat May 6 11:46:12 2023
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORCL (DBID=1660526279)
RMAN> backup check logical validate datafile 18;
Starting backup at 06-MAY-23
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=72 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00018 name=/u01/app/oracle/oradata/tbs_tst_idx.286.1134752063
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
18 OK 0 4051 57600 1864359
File Name: /u01/app/oracle/oradata/tbs_tst_idx.286.1134752063
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 0
Index 0 53004
Other 0 545
Finished backup at 06-MAY-23
RMAN> exit
Recovery Manager complete.
[oracle@hisdbdg backup]$ dbv file=/u01/app/oracle/oradata/tbs_tst_idx.286.1134752063
DBVERIFY: Release 11.2.0.4.0 - Production on Sat May 6 11:46:55 2023
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = /u01/app/oracle/oradata/tbs_tst_idx.286.1134752063
DBVERIFY - Verification complete
Total Pages Examined : 57600
Total Pages Processed (Data) : 0
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 53004
Total Pages Failing (Index): 0
Total Pages Processed (Other): 545
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 4051
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Total Pages Encrypted : 0
Highest block SCN : 1864359 (0.1864359)
[oracle@hisdbdg backup]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on Sat May 6 11:47:10 2023
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SYS@orcldg> select * from v$database_block_corruption;
no rows selected
说明：如上所示，备库orcldg的坏块成功修复.
8、告警日志
open备库时，告警日志如下：
Sat May 06 11:43:09 2023
alter database open
AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access
Beginning Standby Crash Recovery.
Serial Media Recovery started
Managed Standby Recovery starting Real Time Apply
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_2_93_l5clbsro_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_218_l5ck92ns_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_219_l5clbn71_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_220_l5clbr93_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_221_l5clbvbb_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_2_94_l5clc5ss_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_222_l5clby87_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_223_l5clc1g3_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_224_l5clc4mj_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_225_l5clc7st_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_2_95_l5clcgrv_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_226_l5clcc0g_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_227_l5clcgc6_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_228_l5clckfp_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_2_96_l5clctsb_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_229_l5clcno8_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_230_l5clcr39_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_231_l5clcvbk_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_2_97_l5cld3sw_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_232_l5clcykp_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_233_l5cld1od_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_234_l5cld4xg_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_2_98_l5cldlvo_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_235_l5cld8hb_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_236_l5cldk4o_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_237_l5cldvf5_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_2_99_l5clfn05_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_238_l5clf7bt_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_239_l5clfmp9_.arc
Sat May 06 11:43:19 2023
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_240_l5clfxdp_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_2_100_l5clgl0s_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_241_l5clg6bm_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_242_l5clgjqn_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_243_l5clgqg8_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_2_101_l5clh73c_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_244_l5clgx69_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_245_l5clh4xf_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_246_l5clhbfr_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_2_102_l5clp8s5_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_247_l5clp337_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_248_l5clp724_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_249_l5clpcly_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_2_103_l5clpqtc_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_250_l5clpgr3_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_251_l5clpnkh_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_1_252_l5cly20g_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/ORCLDG/archivelog/2023_05_06/o1_mf_2_104_l5clxz9o_.arc
Incomplete Recovery applied until change 1864392 time 05/06/2023 11:37:40
Completed Standby Crash Recovery.
Sat May 06 11:43:25 2023
SMON: enabling cache recovery
Dictionary check beginning
Dictionary check complete
Database Characterset is AL32UTF8
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Physical standby database opened for read only access.
Completed: alter database open
Sat May 06 11:43:26 2023
db_recovery_file_dest_size of 10240 MB is 13.40% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup. 0
点赞
收藏
分享
运用备库数据文件rman备份对另一个备库单个坏块的恢复
相关推荐
0 条评论
