专业编程教程与实战项目分享平台

网站首页 > 技术文章 正文

10TB级 Oracle 11g dataguard备库重建步骤分享

ins518 2024-10-19 07:03:08 技术文章 18 ℃ 0 评论


前言

近日,笔者接触到一个故障修复案例,网络状况是一套Oracle 11g rac 搭配一个单节点的dg备库,由于用户几个月没有对dg备库进行巡检,导致主备库之间失去同步性,而两边都有部署归档文件自动清理脚本,所以只能对备库进行重建,这都很常见,但是这次接触到的主库的数据量达到了10TB,也由此引发了一些特殊的故障。


重建步骤

1. 首先对主库进行一次全备,以防不测。

2. 由于备库长期归档文件未清理,为避免因空间不足导致重建失败,故先清理操作系统空间。

直接到目录下删除数据文件(*前面千万别加斜杠!!!)

rm -f *

利用rman删除备库的归档文件,由于操作系统锁定无法正常删除,需要带上force参数才能成功删除。

delete noprompt force archivelog all completed before ‘sysdate-1’;

3. 关掉备库,等不及的可以加上abort

shutdown immediate

4. 启动备库到nomount

startup nomount

5. 因为是重建,许多搭建dg备库的前提工作都是现成的,所以rman直接连接主备库

rman target sys/***@primary auxiliary sys/***@standby

6. 无视文件检查,直接复制,简单粗暴

duplicate target database for standby from active database nofilenamecheck;


注:

因复制时间较长,毕竟10T的数据,所以笔者写了个小脚本让复制任务后台执行

nohup sh duplicate.sh &
内容如下
$ORACLE_HOME/bin/rman target sys/***@ primary auxiliary sys/***@standby <<EOF
run{
allocate channel d1 type disk;
allocate channel d2 type disk;
allocate channel d3 type disk;
allocate channel d4 type disk;
allocate auxiliary channel c1 type disk;
allocate auxiliary channel c2 type disk;
allocate auxiliary channel c3 type disk;
allocate auxiliary channel c4 type disk;

duplicate target database for standby from active database nofilenamecheck;}
exit;
EOF

通过观察nohup.out文件,可以查看实时的复制进展

7. 复制完毕后,出现报错如图所示


8. 尝试打开数据库,收获报错ora-10458

9. 笔者结合nohup.out的报错提示,判断是由于10T的数据传输过久,网络波动导致部分数据文件未成功传输到备库

10. 此时查看Alert日志,数据库很诚实的告诉我,缺了哪些数据文件,大概有十五个左右,我老老实实的拿笔把所有的数据文件号给记了下来。

11. 马上登陆到主库,由于数据文件是存放在ASM磁盘上的,无法使用操作系统的scp命令,所以登陆到rman对数据文件进行备份。

backup datafile 1 format ‘/home/oracle/%U’;
backup datafile 2 format ‘/home/oracle/%U’;
backup datafile 3 format ‘/home/oracle/%U’;

12. 回到备库,使用scp把主库刚才备份的数据文件给拷贝回来

scp oracle@xx.xx.xx.xx:/x/x/* /x/x/

13. 登陆到rman,注册刚才拷贝过来的数据备份集

catalog start with ‘x/x/x’;

14. 还原数据文件

restore datafile 1;
restore datafile 2;
restore datafile 3;

15. 关闭数据库

shutdown immediate

16. 打开数据库,同时观察alert日志的写入情况

17. 此时可以看到,备库数据库正在接受来自主库的归档文件,正在努力追赶主库的进度

18. 完成后,数据库就打开了

19. 开启实时同步

alter database recover managed standby database using current logfile disconnect;

20. 备库完成重建

21. 验证测试


后话

面对数据库较大的主库,在重建备库的时候,建议还是拷贝全备到备库恢复的方法。如果实在不得已要用duplicate复制的方法,在网络不佳的情况下,就要做好丢失数据文件的打算。不过没关系,得益于rman的强大,只要文件齐全,都能给你恢复回来,就是麻烦了点。

Tags:

本文暂时没有评论,来添加一个吧(●'◡'●)

欢迎 发表评论:

最近发表
标签列表