本文分享了一次真实的迁移案例,将某业务系统生产环境Oracle数据库进行迁移,数据库版本为11.2.0.4。数据库迁移之前部署在RedHat6.5操作系统中,以单机单实例文件系统部署;迁移之后部署在Solaries11操作系统中,以ASM双节点RAC集群部署。本文分享的主要内容是迁移过程中对生产环境的变更和调整思路,以及迁移过程中遇到问题的解决方案,整个迁移过程包括测试环境验证、备份策略验证、生产环境切换等三大步骤,并未涉及数据库的安装部署。希望文章的整体处理思路对读者有帮助。
备份策略验证的目的如下:
(1)调整生产数据库参数。
(2)增加控制文件、日志文件。
(3)部署RMAN备份策略
(4)模拟故障演练
目录结构抢先看
1.在线重做日志调整
2.控制文件调整
3.内存参数调整
4.调整其他参数
5.开启数据库归档
6.定义RMAN备份策略
7.部署备份脚本和crontab
8.手工执行RMAN全量备份
9.控制文件损坏测试
10.spfile文件损坏测试
11.重做日志损坏测试
12.数据损坏测试
13.其他问题处理
下面是操作全流程:
1.在线重做日志调整
(注: 每组一个,增加组数为8,调整大小为1G)
SQL> set linesize 300;SQL> col member for a50; SQL> select * from v$logfile; GROUP# STATUS TYPE MEMBER IS_ ---------- ------- ------- -------------------------------------------------- --- 2 ONLINE +DATADG/cams/onlinelog/group_2.292.989624633 NO 1 ONLINE +DATADG/cams/onlinelog/group_1.256.989624629 NO 3 ONLINE +DATADG/cams/onlinelog/group_3.296.989624869 NO 4 ONLINE +DATADG/cams/onlinelog/group_4.295.989624875 NO 5 ONLINE +DATADG/cams/onlinelog/group_5 NO 6 ONLINE +DATADG/cams/onlinelog/group_6 NO 7 ONLINE +DATADG/cams/onlinelog/group_7 NO 8 ONLINE +DATADG/cams/onlinelog/group_8 NO 8 rows selected. SQL> select GROUP#,BYTES,MEMBERS,STATUS from v$log; GROUP# BYTES MEMBERS STATUS ---------- ---------- ---------- ---------------- 1 1073741824 1 INACTIVE 2 1073741824 1 INACTIVE 3 1073741824 1 CURRENT 4 1073741824 1 INACTIVE 5 1073741824 1 CURRENT 6 1073741824 1 INACTIVE 7 1073741824 1 INACTIVE 8 1073741824 1 INACTIVE 8 rows selected.
2.控制文件调整
(注: 调整控制文件为3个,存在在不同路径下)
SQL> set linesize 300;SQL> col name for a55; SQL> select * from v$controlfile; STATUS NAME IS_ BLOCK_SIZE FILE_SIZE_BLKS ------- ------------------------------------------------------- --- ---------- -------------- +DATADG/cams/controlfile/controlfile1/controlfile1 NO 16384 1128 +DATADG/cams/controlfile/controlfile2/controlfile2 NO 16384 1128 +DATADG/cams/controlfile/current.303.989624627 NO 16384 1128
3.内存参数调整
(注:每个节点的内存都为64G,开启AMM)
SQL> show parameter memory;NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ hi_shared_memory_address integer 0 memory_max_target big integer 32256M memory_target big integer 32256M shared_memory_address integer 0 SQL> show parameter sga; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ lock_sga boolean FALSE pre_page_sga boolean FALSE sga_max_size big integer 32256M sga_target big integer 0 SQL> show parameter pga; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ pga_aggregate_target big integer 0
4.调整其他参数
调整
job_queue_processes,
log_buffer,
db_block_checking,
processes,
session_cached_cursors,
open_cursors,
undo_retention
等参数,符合生产规范。
5. 开启数据库归档
SQL> archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination +DATADG Oldest online log sequence 8 Next log sequence to archive 11 Current log sequence 11
6.定义RMAN备份策略
(1)设置数据库自动备份控制文件
(2)每周日做RMAN 0级全库备份
(3)每日(除周日)做RMAN 1级增量备份
(4)在主服务器上只保留2周的全库备份、增量备份
(5)将两周前的全库备份、增量备份copy至其他环境中
7. 部署备份脚本和crontab
(注:按照客户要求,这里将RMAN备份到ASM磁盘中)
先创建RMAN备份目录“+DATADG/CAMS/RMAN”
脚本存放目录:/u01/app/oracle/backup/rman
日志存放目录:/u01/app/oracle/backup/rman/logs
在oracle用户下执行:crontab -e,每天凌晨3点执行备份
0 3 * * 0-6 /u01/app/oracle/backup/rman/start_rman.sh >> /u01/app/oracle/backup/rman/start_rman.log
8.手工执行RMAN全量备份
手工执行RMAN 0级备份脚本,对数据库做全量RMAN备份。
9.控制文件损坏测试
(1)关闭数据库
(2)修改其中一个控制文件名字
(3)启动数据库(提示错误信息)
(4)使用RMAN恢复控制文件
(5)启动数据库
(6)检查控制文件信息
10. spfile文件损坏测试
(1)关闭数据库
(2)修改spfile文件名字
(3)启动数据库(提示错误信息)
(4)使用RMAN恢复spfile文件
(5)重启数据库
(6)检查数据库状态
11. 重做日志损坏测试
(1)关闭数据库
(2)修改redo文件名字
(3)启动数据库(提示错误信息)
(4)使用RMAN完全恢复
(5)在sqlplus中recover数据库
(6)打开数据库
(7)检查数据库状态
12. 数据损坏测试
(1)完全恢复
RMAN>startup mount; RMAN>restore database; RMAN>recover database; RMAN>alter database open;
(2)不完全恢复
oracle@cwgsdb1:~$ srvctl stop database -d cams oracle@cwgsdb1:~$ srvctl start database -d cams -o mount oracle@cwgsdb1:~$ export NLS_DATE_FORMAT="yyyy-mm-dd hh24:mi:ss" $ rman target / RMAN>restore database until time "to_date('2018-10-25 01:07:18','yyyy-mm-dd hh24:mi:ss')"; RMAN>recover database until time "to_date('2018-10-25 01:08:06','yyyy-mm-dd hh24:mi:ss')"; RMAN>alter database open resetlogs; RMAN>exit
13.其它问题处理
Solaries系统时间与互联网时间不一致,因为是测试环境,切换时会清理后重新导入生产数据,所以直接修改系统时间解决。
如果生产环境发现该问题,建议将硬件与系统时间同步关掉,停库一天,等时间超过当前时间,然后开系统,时间同步,然后再起数据库。
至此,备份策略验证完毕。下一步的工作是进行生产环境数据库切换 。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31394774/viewspace-2219306/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/31394774/viewspace-2219306/