尊敬的客户您好:
一般来说:
- 就像之前更新的那样,根据级联备库的工作原理 - 它只能应用已经归档的日志,因此通常意义上无法做到零数据丢失。
- 要实现零数据丢失,在 12c 上可以通过 far sync 做到对主库性能影响最小;而在 11.2上则一定会影响主库性能。
- 通过 real-time apply 的方式,11.2的备库可以做到仅丢失很少数据(但不能是级联类型的备库)
不过通过上一个更新中的 Test Case,我们验证了您提到的方式-在级联备库中应用主库的online redo logfile,也可以做到零数据丢失。
具体的测试步骤您可以参考上一个 ODM Test Case 的更新。
Thank you, Feng Gao, Oracle Customer Services
Oracle Support - Sunday [ODM Test Case]
Test Case:
-
创建一个主库: pridb
-
建立一个 real-time apply standby: stdydb
-
创建一个级联备库: casdb
-
在主库上做一些变更
conn feng/feng
drop table test4 purge
备库可以很快就看到变更
SQL> select * from tab;
TNAME TABTYPE CLUSTERID
TEST TABLE
TEST2 TABLE <===备库上已经没有 test4 这个表了
但是级联备库必须要等备库的standby redo log切换才能看到这个变更
所以仍能看到表test4
SQL> select * from tab;
TNAME TABTYPE CLUSTERID
TEST TABLE
TEST2 TABLE
TEST4 TABLE <===级联备库上还可以看到 test4 这个表
-
把 pridb 和 stdydb 杀死,破坏 datafile 和 controlfile
-
按照客户提到的思路来操作:
a). 在级联备库上生成一个创建 controlfile 的命令并停掉级联备库
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
生成的trace会生成两种重建 controlfile 的命令,我们使用第一种 Set #1. NORESETLOGS case 的模式。
因为我们知道主库的最新的 redo log 还在,并且要应用在级联备库上,所以不需要 resetlogs
========================
若是RAC DB, 需要先备份RAC 实例的 initcasdb1.ora (此内容只有指向 共享目录的 spfile 信息),然后再生成 initcasdb1.ora ,
再将 initcasdb1.ora 中 cluster_database 的值 修改为 false ; 否则下面重建控制文件时会报错ORA-12720: operation requires database is in EXCLUSIVE mode。
$ cd $ORACLE_HOME/dbs
$ mv initcasdb1.ora initcasdb1.ora.bak
SQL>show parameter spfile
SQL>create pfile='/oracle/product/11.2.0.1/dbs/initcasdb1.ora' from spfile;
接下来停掉级联备库
b). 然后把当前级联备库上的 controlfile 重命名,我们稍后需要重建它
mv /data01/casdb/control01.ctl /data01/casdb/control01.ctl.bak
c). 然后把当前级联备库上的 redo log 重命名,我们稍后会使用主库的 online log 来替代它们
bash-4.1$ mv casdbredo01.log casdbredo01.log.bak
bash-4.1$ mv casdbredo02.log casdbredo02.log.bak
bash-4.1$ mv casdbredo03.log casdbredo03.log.bak
d). 把主库的 online log 拷贝到级联备库的redolog 所在的目录
e). 按照步骤 a) 得到的第一部分"Set #1. NORESETLOGS case "里重建 controlfile 的命令来启动数据库
SQL> STARTUP NOMOUNT
ORACLE instance started.
Total System Global Area 784998400 bytes
Fixed Size 2257352 bytes Variable Size 515903032 bytes
Database Buffers 264241152 bytes
Redo Buffers 2596864 bytes
SQL> CREATE CONTROLFILE REUSE DATABASE "PRIDB" NORESETLOGS FORCE LOGGING ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/data01/casdbredo01.log' SIZE 50M BLOCKSIZE 512,
GROUP 2 '/data01/casdbredo02.log' SIZE 50M BLOCKSIZE 512,
GROUP 3 '/data01/casdbredo03.log' SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
-- GROUP 4 '/data01/casdbstandby_redo04.log' SIZE 50M BLOCKSIZE 512,
-- GROUP 5 '/data01/casdbstandby_redo05.log' SIZE 50M BLOCKSIZE 512,
-- GROUP 6 '/data01/casdbstandby_redo06.log' SIZE 50M BLOCKSIZE 512,
-- GROUP 7 '/data01/casdbstandby_redo07.log' SIZE 50M BLOCKSIZE 512
DATAFILE
'/data01/casdbsystem01.dbf',
'/data01/casdbsysaux01.dbf',
'/data01/casdbundotbs01.dbf',
'/data01/casdbusers01.dbf',
'/data01/casdbtbs1',
'/data01/casdbtbs1_1.dbf',
'/data01/casdbtbs1_2.dbf',
'/data01/casdbtbs1_3.dbf'
CHARACTER SET AL32UTF8
;
Control file created.
SQL> RECOVER DATABASE <===然后 recover database
Media recovery complete.
SQL> ALTER SYSTEM ARCHIVE LOG ALL;
System altered.
SQL> ALTER DATABASE OPEN; <===然后 open database
Database altered.
========================
DB 重建 tempfile
SQL>
ALTER TABLESPACE TEMP ADD TEMPFILE '/oradata/casdb/temp01.dbf'
SIZE 10G REUSE AUTOEXTEND ON NEXT 16M;
========================
f). 在级联备库上验证之前主库刚做的变更是否已经可以看到了
SQL> conn feng/feng
Connected.
SQL> select * from tab;
TNAME TABTYPE CLUSTERID
TEST TABLE
TEST2 TABLE <===主库拷过来的redo已经被应用了
结论:重建controlfile后并把主库的online redo logfile 拷贝到级联备库,就没有数据丢失了
========================
若是 RAC DB ,还需如下操作。
对于 RAC DB ,上面使用pfile 在 CLUSTER_DATABASE=false 下 才可重建控制文件,启动 DB,恢复数据后,现在需要
使用 spfile 在 CLUSTER_DATABASE=true 状态下,开启RAC DB。
关闭数据库
SQL > shutdown immediate
改名 initcasdb1.ora ,并编辑之
$ mv initcasdb1.ora initcasdb1.ora.bak1
$ vi initcasdb1.ora
SPFILE='/oradata/casdb/spfilecasdb.ora'
然后启动 RAC DB
srvctl start database -d tspcdb
检查参数 cluster_database=true
export ORACLE_SID=tspcint1
sqlplus / as sysdba
SQL>show parameter cluster_database
g). 这样做完之后,还要梳理一下级联备库中的初始化参数,比如
重新 review db_file_name_convert, LOG_ARCHIVE_DEST_* 等