您的位置:首页 > 数据库 > Oracle

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

2015-10-10 10:20 471 查看
运维的过程是不断产生新的问题,需要不断研究和前进的过程。十一假期刚过客户就电话告知之前的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
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: