前言:在迁移Oracle数据库的过程中,我们会遇到很多种情况,例如32位操作系统下的数据库迁移到64位,不同操作系统平台之间的迁移,那么怎么选择迁移工具呢,首先我们需要确认迁移源端和目标端的环境,再次停机时间,数据量大小,相对而言,逻辑迁移更稳妥一点,不管是手动的expdp/impdp还是借助其他工具,OGG之类,像高水位这样的问题也会得到缓解。 rman也是一项工具,那么什么时候选择呢,或者选择的利弊呢?版本限制、bug有点多,rman能把数据库的环境完全复制过来,在一些场景中是需要的。
成都创新互联公司专注于网站建设|成都网站维护|优化|托管以及网络推广,积累了大量的网站设计与制作经验,为许多企业提供了网站定制设计服务,案例作品覆盖成都墙体彩绘等行业。能根据企业所处的行业与销售的产品,结合品牌形象的塑造,量身策划品质网站。
下面做个测试,源端环境: Windows2008 64位+Oracle11.2.0.1+ filesystem
目标端环境:Redhat6.7
x64+oracle11.2.0.4+ASM
首先我们确认一下字节:
下面开始通过rman执行迁移工作
在Windows环境下执行备份:
通过以下语句生成pfile文件:
create pfile='d:\pfile20171029.ora' from spfile;
将备份文件、归档日志、pfile文件、密码文件拷贝至目标端(Linux)
目标端相关操作:
首先编辑参数文件,修改相关路径、参数等,并且创建相关目录
例如:
mkdir -p
/home/oracle/archivelog
mkdir -p /u02/app/oracle/admin/orcl/adump
启动数据库到nomount状态
export
ORACLE_SID=orcl
sqlplus / as sysdba
startup nomount pfile='/home/oracle/rmanbackup/pfile20171029.ora'
开始恢复控制文件(注意,初始化参数文件中已更改控制文件存放到ASM磁盘中)
*恢复控制文件并启动到mount阶段:
*注册备份文件
执行恢复数据库操作,此处注意,首先需要清理rman中无效备份,如果不清理,需要制定,不然恢复时首先找的是原来备份,如下:
*此处执行检查备份、并清理无效、过期备份(简图)
再次执行恢复操作:
OK,我们执行recover
Recovery Manager complete. 此处注意,这里执行的是recover database,也未应用之后的归档日志,再个,在线日志并没有原来的目录,数据库open时会默认给创建到dbs目录中,open后需要更改redo log位置。
recover完成,下面开始open
SQL> alter database open resetlogs upgrade; -- upgrade版本由11201到11204
Database altered.
打开了,可以啊,完事了? redo
log没做,还有什么 想想……
首先我们需要把数据库根本的正好,来执行几个脚本,来完成最终的数据库升级
需要执行以下三个脚本, 顺序要求,首先执行catupgrd.sql,再依次执行utlrp.sql catbundle.sql
还要注意一点:执行catupgrd.sql之前,需要重建临时表空间,步骤如下:
create
temporary tablespace temp01 tempfile '+DATA' SIZE 1G;
alter database default temporary tablespace temp01;
drop tablespace temp including contents and datafiles cascade constraints;
ok,可以执行啦
SQL>
@?/rdbms/admin/catbundle.sql psu apply
SQL>@?/rdbms/admin/utlrp.sql
SQL>@?/rdbms/admin/catupgrd.sql --第一个执行,它会频繁切换归档,俺的测试空间已爆
为什么需要执行这三个呢,我们看一下这几个脚本的描述
第一个,这个主要目的是将补丁信息更新到sql中,也会执行其他东西,也就是视图dba_registry_history
第二个,重新编译无效对象
最终要的,就是第三个,必须执行,这里说的是10.2及之前的版本,本次环境为11.2.0.1到 11.2.0.4 ,也是必须执行的脚本,如果你不想每次shutdown数据库后,startup时还需要 alter database open
upgrade 那就执行此步骤。
脚本执行完成,我们来看看版本信息:
红色部分为升级的一部分,可以忽略。第二行为执行脚本catupgrd.sql 生成,描述信息:Upgraded from 11.2.0.1.0
第三行为脚本catbundle.sql执行结果
还有什么收尾工作吗,对了,在线日志路径还未更改,那就查看更改吧
基本步骤如下:
select
group#,status from v$log;
alter system archive log current;
alter
database drop logfile group 3;
alter database add logfile group 3 ('+DATA') size 100m;
alter database drop logfile group 1;
alter database add logfile group 1 ('+DATA') size 100m;
alter database drop logfile group 2;
alter database add logfile group 2 ('+DATA') size 100m;
更改完成,还需要执行以下命令
create spfile from pfile='/home/oracle/rmanbackup/pfile01.ora';
再次重启数据库验证,数据库正常。
等等,我们需要追加归档日志恢复……
读取归档日志报错,终于用上了MOS文章中提到的失败,那么如果源目标归档日志都采用ASM方式存储呢?会出现吗? 留着吧不能用追加归档日志方式,就使用增量备份呗
虽然说使用逻辑方式迁移看似简单,例如expdp/impdp ,其实需要准备的东西并不少,有兴趣的可以测试下,迁移我们就可能遇到不同的操作系统、不同的版本甚至32位到64位, 不知道Oracle18C 能解决不?
折腾半天,最后以600结束,也算无憾 ,其实挺扯淡……
就这样吧,周一愉快