OGG在RAC上的初始化(下)-- OGG初始化
发表于:2026-11-02 作者:千家信息网编辑
千家信息网最后更新 2026年11月02日,上篇地址http://blog.itpub.net/29047826/viewspace-1284906/1,源端执行RMAN全库备份备份路径为节点node1的本地磁盘。为了将该备份复制到灾备端,此次
千家信息网最后更新 2026年11月02日OGG在RAC上的初始化(下)-- OGG初始化上篇地址http://blog.itpub.net/29047826/viewspace-1284906/
1,源端执行RMAN全库备份
备份路径为节点node1的本地磁盘。为了将该备份复制到灾备端,此次备份不能保存在ASM上。
2,查看controlfile所在的备份片。灾备端恢复的时候也从这个备份片中读取controlfile。
3,获取不活动的(INACTIVE)的已经归档的日志的最后一个SCN号,如果有多个已归档的INACTIVE的组,取最大的FIRST_CHANGE# 1260645
该SCN号作为灾备端recover database until 的SCN,并且在复制进程重新启动后也要参照这个SCN。
4,将源端备份复制到灾备端
[oracle@node1 ~]$ scp /backup/* oracle@172.16.228.103:/backup/
5,停止灾备端的复制进程准备恢复数据库
GGSCI (node3) 4> stop rt1
Sending STOP request to REPLICAT RT1 ...
Request processed.
停止复制进程后,可以在源端继续执行一些DML操作。这些操作会正常的通过抽取进程获取,并有投递进程投递到灾备端的remote trail目录,只是暂时不用复制进程追加而已。
6,关闭灾备端数据库
[root@node3 ~]# srvctl stop database -d prod
7,灾备端从RMAN启动数据库到nomount状态
8,灾备端从RMAN恢复控制文件
9,灾备端控制文件加载复制过来的备份集信息,核对控制文件信息
RMAN> catalog start with '/backup/';
RMAN> list backup;
10,灾备端从RMAN恢复数据库
RMAN> restore database;
11,灾备端从RMAN恢复归档日志
RMAN> run{
allocate channel c1 type disk;
allocate channel c2 type disk;
restore archivelog all;
release channel c1;
release channel c2;
}
12,灾备端从RMAN指定SCN恢复。该SCN是源端数据库执行RMAN备份后状态为INACTIVE中数值最大的SCN。
RMAN> recover database until scn 1260645
13,灾备端在mount状态下通过控制文件查看文件头的scn是否一致
14,灾备端resetlogs方式开启数据库
alter database open resetlogs;
[root@node3 ~]# srvctl start database -d prod
15,灾备端重新配置checkpoint
16,灾备端重新启动复制进程,从SCN为1260645开始
注意这个单词不要写错aftercsn
17,灾备端通过sqlplus查询恢复数据库期间生成的DML是否被成功追加
sqlplus / as sysdba
select * from snow.t1
本次初始化演练到此结束。
1,源端执行RMAN全库备份
备份路径为节点node1的本地磁盘。为了将该备份复制到灾备端,此次备份不能保存在ASM上。
| run { allocate channel ch01 device type disk; allocate channel ch02 device type disk; backup format '/backup/full_%d_%s_%T_%p.bak' database include current controlfile; sql 'alter system archive log current'; backup archivelog all format '/backup/arch_%d_%s_%T_%p'; release channel ch02; release channel ch01; } |
2,查看controlfile所在的备份片。灾备端恢复的时候也从这个备份片中读取controlfile。
| RMAN> list backup of controlfile; List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ ------------------- 37 Full 17.80M DISK 00:00:00 2014-09-28 23:53:06 BP Key: 37 Status: AVAILABLE Compressed: NO Tag: TAG20140928T235259 Piece Name: /backup/full_PROD_36_20140928_1.bak Control File Included: Ckp SCN: 1260618 Ckp time: 2014-09-28 23:53:06 |
3,获取不活动的(INACTIVE)的已经归档的日志的最后一个SCN号,如果有多个已归档的INACTIVE的组,取最大的FIRST_CHANGE# 1260645
该SCN号作为灾备端recover database until 的SCN,并且在复制进程重新启动后也要参照这个SCN。
| SYS@PROD1 > select inst_id,group#,thread#,sequence#,archived,status,first_change# from gv$log order by status; INST_ID GROUP# THREAD# SEQUENCE# ARC STATUS FIRST_CHANGE# ---------- ---------- ---------- ---------- --- ---------------- ------------- 1 3 2 25 NO CURRENT 1260660 2 3 2 25 NO CURRENT 1260660 1 1 1 29 NO CURRENT 1260655 2 1 1 29 NO CURRENT 1260655 1 2 1 28 YES INACTIVE 1260638 1 4 2 24 YES INACTIVE 1260645 2 2 1 28 YES INACTIVE 1260638 2 4 2 24 YES INACTIVE 1260645 |
4,将源端备份复制到灾备端
[oracle@node1 ~]$ scp /backup/* oracle@172.16.228.103:/backup/
5,停止灾备端的复制进程准备恢复数据库
GGSCI (node3) 4> stop rt1
Sending STOP request to REPLICAT RT1 ...
Request processed.
停止复制进程后,可以在源端继续执行一些DML操作。这些操作会正常的通过抽取进程获取,并有投递进程投递到灾备端的remote trail目录,只是暂时不用复制进程追加而已。
6,关闭灾备端数据库
[root@node3 ~]# srvctl stop database -d prod
7,灾备端从RMAN启动数据库到nomount状态
| [root@node3 ~]# su - oracle [oracle@node3 ~]$ rman target / RMAN> startup nomount; Oracle instance started Total System Global Area 672256000 bytes Fixed Size 2256272 bytes Variable Size 520094320 bytes Database Buffers 146800640 bytes Redo Buffers 3104768 bytes |
8,灾备端从RMAN恢复控制文件
| RMAN> restore controlfile from '/backup/full_PROD_24_20140928_1.bak'; Starting restore at 2014-09-28 20:14:13 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=34 instance=PROD1 device type=DISK channel ORA_DISK_1: restoring control file channel ORA_DISK_1: restore complete, elapsed time: 00:00:01 output file name=+DATA/prod/controlfile/current.260.859387343 output file name=+ARCH/prod/controlfile/current.256.859387345 Finished restore at 2014-09-28 20:14:14 |
9,灾备端控制文件加载复制过来的备份集信息,核对控制文件信息
RMAN> catalog start with '/backup/';
RMAN> list backup;
10,灾备端从RMAN恢复数据库
RMAN> restore database;
11,灾备端从RMAN恢复归档日志
RMAN> run{
allocate channel c1 type disk;
allocate channel c2 type disk;
restore archivelog all;
release channel c1;
release channel c2;
}
12,灾备端从RMAN指定SCN恢复。该SCN是源端数据库执行RMAN备份后状态为INACTIVE中数值最大的SCN。
RMAN> recover database until scn 1260645
13,灾备端在mount状态下通过控制文件查看文件头的scn是否一致
| SYS@PROD1 > select checkpoint_change# from v$datafile_header; CHECKPOINT_CHANGE# ------------------ 1260645 1260645 1260645 1260645 1260645 1260645 1260645 7 rows selected. SYS@PROD1 > select checkpoint_change# from v$datafile; CHECKPOINT_CHANGE# ------------------ 1260645 1260645 1260645 1260645 1260645 1260645 1260645 |
14,灾备端resetlogs方式开启数据库
alter database open resetlogs;
[root@node3 ~]# srvctl start database -d prod
15,灾备端重新配置checkpoint
| [oracle@node3 goldengate]$ ggsci GGSCI (node3) 1> DBLOGIN USERID oggadmin,PASSWORD oggadmin GGSCI (node3) 2> ADD CHECKPOINTTABLE oggadmin.checkpointtable GGSCI (node3) 14> DELETE REPLICAT rt1 GGSCI (node3) 15> ADD REPLICAT rt1, EXTTRAIL /goldengate/dirdat/rt, checkpointtable oggadmin.checkpointtable |
16,灾备端重新启动复制进程,从SCN为1260645开始
注意这个单词不要写错aftercsn
| GGSCI (node3) 16> start rt1 aftercsn 1260645 Sending START request to MANAGER ... REPLICAT RT1 starting |
17,灾备端通过sqlplus查询恢复数据库期间生成的DML是否被成功追加
sqlplus / as sysdba
select * from snow.t1
本次初始化演练到此结束。
备份
数据
数据库
进程
文件
控制
状态
最大
信息
日志
端的
一致
成功
上篇
不用
单词
只是
地址
多个
并有
数据库的安全要保护哪些东西
数据库安全各自的含义是什么
生产安全数据库录入
数据库的安全性及管理
数据库安全策略包含哪些
海淀数据库安全审计系统
建立农村房屋安全信息数据库
易用的数据库客户端支持安全管理
连接数据库失败ssl安全错误
数据库的锁怎样保障安全
高科技互联网
中国互联网科技股
A股互联网金融科技公司
疫情对互联网科技公司影响
中资互联网科技
北京互联网科技
互联网科技上市公司
隆华科技工业互联网
茂名市互联网科技产业园
彤创互联网科技有限公司
搜狐科技互联网
徐州市互联网科技有限公司
科技互联网海报
中天科技中国工业互联网
广东鹅鹅鹅互联网科技有限公司
云南互联网科技学费
三亚科技创新互联网基地
上海旺乐尼互联网科技有限公司
广东猫王互联网科技有限公司电话
高科技和互联网的现代国家
中国互联网科技股
互联网科技卖菜
港股互联网科技股
嘟嘟瓜互联网科技
互联网科技排名
安徽鑫晟辉互联网科技
成都狮子座互联网科技
科技类公司包括互联网吗
互联网公司高科技产品
科技互联网公司两年变化