Goldengate for oracle 数据一致性初始化方案

运维的过程是不断产生新的问题，需要不断研究和前进的过程。十一假期刚过客户就电话告知之前的oracle 同步数据不一致需要处理，然而又不能停业务。

这里研究使用RMAN初始化方案

--不需要源数据库停机。

1.环境介绍：

客户三台数据库，三台之间相互同步DDL、DML

2.前言：

每个高可用的场景不一样，处理各有千秋，但是大致步骤雷同。我的故障不能直接就去处理这样的故障，需要先分析每个库的差异，哪个库的数据是正常的在初始化到其它数据库上，在启动同步。由于是生产环境，数据库的数据实时在变化，所以源端的抽取进程需要开启（传输进程可开），目标端的恢复停止，待初始化完成后再开启。

3.步骤如下：

生产端===============================================

1)使用oracle用户登录，执行rman备份

–备份数据库：

mkdir -p /data/backup /data/dbback/gpofullbak
chown -R oracle.oinstall /data/backup /data/dbback/gpofullbak
rman target /
run {
allocate channel ch00 type disk maxpiecesize 30g;
allocate channel ch01 type disk maxpiecesize 30g;
crosscheck backupset;
delete noprompt expired backupset;
sql ‘alter system archive log current‘;
backup as backupset skip inaccessible tag hot_db_bk_level0
full database
format ‘/data/backup/bk_%s_%p_%t‘;
release channel ch00;
release channel ch01;
}

–备份归档和控制文件：

run {
ALLOCATE CHANNEL ch00 TYPE DISK MAXPIECESIZE 30g;
ALLOCATE CHANNEL ch01 TYPE DISK MAXPIECESIZE 30g;
sql ‘alter system switch logfile‘;
sql ‘alter system switch logfile‘;
sql ‘alter system switch logfile‘;
sql ‘alter system archive log current‘;
BACKUP ARCHIVELOG ALL FORMAT ‘/data/backup/ARCH_%U‘;
BACKUP CURRENT CONTROLFILE FORMAT ‘/data/backup/bk_controlfile‘;
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
}

--在源机执行

SQL>select * from Gv$log;
   INST_ID    GROUP#        THREAD#  SEQUENCE#        BYTES        BLOCKSIZE    MEMBERS ARC STATUS          FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ ---------
         1            1              1        795  52428800              512          1 YES INACTIVE              17689009 09-OCT-15    17689018 09-OCT-15
         1            2              1        796  52428800              512          1 YES INACTIVE              17689018 09-OCT-15    17689026 09-OCT-15
         1            3              1        797  52428800              512          1 NO  CURRENT              17689026 09-OCT-15  2.8147E+14

记录该SCN号 17689018

========================================

SQL>create pfile=‘/tmp/initora11g.ora‘ from spfile ;
scp -rp /tmp/initora11g.ora root@192.168.80.71:/u01/app/oracle/product/11.2.0/db_1/dbs/
scp -rp /data/backup/ /data/dbback/ root@192.168.80.71:/data

目标端===============================================

2)启动数据库到nomount状态

SQL>startup nomount

3)启动RMAN恢复控制文件

rman target /
RMAN>restore controlfile from ‘/data/backup/bk_controlfile‘;

4)将数据库更改为mount状态

sqlplus / as sysdba
SQL>alter database mount;

5)启动RMAN恢复数据库

rman target /
RMAN>restore database;
RMAN>
run
{
   set archivelog destination to ‘/u01/app/oracle/flash_recovery_area‘;
   SET UNTIL SCN 17689018; #注意使用前面记录下的scn号
   RECOVER DATABASE;
}

6)查看

SQL> SELECT CHECKPOINT_CHANGE#,CHECKPOINT_TIME FROM V$DATAFILE_HEADER;
CHECKPOINT_CHANGE# CHECKPOIN
------------------ ---------
          17689018 09-OCT-15
          17689018 09-OCT-15
          17689018 09-OCT-15
          17689018 09-OCT-15
          17689018 09-OCT-15
          17689018 09-OCT-15
          17689018 09-OCT-15
          17689018 09-OCT-15
8 rows selected.
SQL>alter database open resetlogs;

到这里备份恢复已经完成。

7)启动恢复

start rini_1, aftercsn 17689018

8)开启目标端所以进程

本文出自 “每天一点点” 博客，请务必保留此出处http://perlin.blog.51cto.com/1202304/1701437

原文：http://perlin.blog.51cto.com/1202304/1701437