Step by Step – Oracle数据库物理迁移

今天早晨4:00完成客户数据库物理迁移,记录如下,如有错误,欢迎指正。

本次迁移工作为跨平台(Window->Linux)、跨版本(Oracle 11.1.0.7->11.2.0.2)、跨位数(32bit->64bit)。而且客户使用APEX作为网站开发工具,很多数据保存在SYSTEM,SYSAUX表空间中,我们选择物理迁移数据文件,重建控制文件的方式完成此次迁移。

物理迁移首先需要收集源库信息,然后在新库上进行操作。

首先要收集源数据库信息。
1. 打开cmd
a) 将gettrcname.sql脚本保存至cmd中当前路径。
脚本用于在导出控制文件的跟踪文件后,显示此跟踪文件位置。脚本内容为:

SELECT d.VALUE
|| '/'
|| LOWER (RTRIM (i.INSTANCE, CHR (0)))
|| '_ora_'
|| p.spid
|| '.trc' trace_file_name
FROM (SELECT p.spid
FROM v$mystat m, v$session s, v$process p
WHERE m.statistic# = 1 AND s.SID = m.SID AND p.addr = s.paddr) p,
(SELECT t.INSTANCE
FROM v$thread t, v$parameter v
WHERE v.NAME = 'thread'
AND (v.VALUE = 0 OR t.thread# = TO_NUMBER (v.VALUE))) i,
(SELECT VALUE
FROM v$parameter
WHERE NAME = 'user_dump_dest') d
/

2. 收集源数据库服务器信息
在这里,最重要的是字符集及数据库块大小信息。
—字符集信息

col parameter for a50
col value for a50
select * from nls_database_parameters;

—块大小信息

show parameter block

—将控制文件导出至跟踪文件

Alter database backup controlfile to trace;

—查找导出的trace文件位置

@gettrcname

根据提示的trace文件位置,查找到trace文件,并拷贝至MARSHALL文件夹中

—数据文件、表空间信息

Select name from v$datafile;
Select tablespace_name from dba_tablespaces;
Select member from v$logfile;

正常关闭数据库。

目标库操作
1. 在执行操作前,先将之前测试生成的文件清除。
包括以下目录及文件:
/u02/flash_recovery_area
/u01/app/oracle/diag/rdbms/marshall/MARSHALL/trace/
/u02/oradata/xe5/control01.ctl
/u02/oradata/xe5/TEMP01.DBF
2. 拷贝数据文件、重做日志文件至目标库
在$ORACLE_HOME/oradata下创建与源库名同名的文件夹,把源库上的文件(数据文件、重做日志文件)拷贝至此目录下。
将压缩文件解压至oradata目录

./rar/unrar x REDO110408.rar /u02/oradata/xe5/ &
./rar/unrar x DBF110408.rar /u02/oradata/xe5/ &

3. 根据当前目录环境,修改trace文件

cp marshall_ora_4484.trc createctl.sql
vi createctl.sql

修改如下文件内LOGFILE及DATAFILE的路径信息,与新库对应文件路径一致。

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "MARSHALL" NORESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 584
LOGFILE
GROUP 1 '/u02/oradata/xe5/REDO01.LOG' SIZE 50M,
GROUP 2 '/u02/oradata/xe5/REDO02.LOG' SIZE 50M,
GROUP 3 '/u02/oradata/xe5/REDO03.LOG' SIZE 50M
DATAFILE
'/u02/oradata/xe5/SYSTEM01.DBF',
'/u02/oradata/xe5/SYSAUX01.DBF',
'/u02/oradata/xe5/UNDOTBS01.DBF',
'/u02/oradata/xe5/USERS01.DBF',
'/u02/oradata/xe5/FLOW_1.DBF',
'/u02/oradata/xe5/FLOW_2.DBF',
'/u02/oradata/xe5/FLOW_3.DBF'
CHARACTER SET AL32UTF8;

4. 查看环境变量

echo $ORACLE_SID

5. 手工创建参数文件
在$ORACLE_HOME/dbs文件夹下有参数文件,根据数据库名,创建名为init.ora的参数文件。在文件内至少添加如下行:
Db_name= “MARSHALL”
//此名字可在源库上select name from v$datafile;查到

audit_file_dest='/u01/app/oracle/admin/orcl/adump'
db_recovery_file_dest='/u02/app/oracle/flash_recovery_area'
db_recovery_file_dest_size=2147483648
diagnostic_dest='/u01/app/oracle'
control_files='/u02/oradata/marshall/control01.ctl','/u02/flash_recovery_area/marshall/control02.ctl'

6. 重建控制文件
执行以下操作时,需要使用tailf命令观察告警日志信息同步变化情况。
@createctl.sql
这个时候,数据库出于MOUNTED状态。
7. 检查归档模式(需要在非归档模式下执行升级脚本)

archive log list

需要在mounted状态下更改archive mode

alter database noarchivelog;
archive log list

8. 重建控制文件后,关库重启

shutdown immediate
startup upgrade
archive log list

9. 添加Temp 文件(注意,单引号与Linux下不一致,不能直接拷贝使用)

 alter tablespace temp add tempfile '/u02/oradata/marshall/TEMP01.DBF' size 10M autoextend on maxsize unlimited;

10. 检查SGA区,share_pool大小
show parameter shared_pool
若shared_pool较小,可通过如下语句增大,shared_pool_size=新的shared_pool大小。

alter system set shared_pool_size=200M scope=both

11. 由于是升级到Oracle11.2,所以要先执行以下脚本,否则会报ORA-01722错误(执行utlu112i脚本也会报错,但是不执行的话会导致后面的utlirp执行不了)

nohup sqlplus "/ as sysdba" @?/rdbms/admin/utlu112i.sql &

备份执行utlu112i脚本生成的日志:

mv nohup.out utlu112i.log

执行utlirp脚本,然后备份日志。

nohup sqlplus "/ as sysdba" @?/rdbms/admin/utlirp.sql &

执行结束,会在log中给出以下提示:

DOC>#######################################################################
DOC>#######################################################################
DOC> utlirp.sql completed successfully. All PL/SQL objects in the
DOC> database have been invalidated.
DOC>
DOC> Shut down and restart the database in normal mode and run utlrp.sql to
DOC> recompile invalid objects.
DOC>#######################################################################
DOC>#######################################################################

注意,执行utlrp脚本,Log中提示以下错误:
ERROR:
ORA-03114: not connected to ORACLE
应直接执行catupgrd.sql升级脚本(我们这时还不能以normal模式启动数据库,因为数据库迁移,需先执行catupgrd脚本)。
12. 后台执行升级脚本

nohup sqlplus "/ as sysdba" @?/rdbms/admin/catupgrd.sql &

监视升级脚本运行情况

Tailf *.out

观察告警日志情况

Tailf alter_.log

13. 查看是否有INVALID对象

select count(*) from dba_objects where status ='INVALID';

如果没有INVALID对象,则可以跳过第12、13步。
14. 如不出意外,应该有相当多的INVALID对象,catupgrd脚本log最后也提示需要startup数据库并执行utlrp脚本编译INVALID对象:

nohup sqlplus "/ as sysdba" @?/rdbms/admin/utlrp.sql

15. 查看是否有INVALID对象

Select count(*) from dba_objects where status='INVALID';

如果有INVALID对象,亦无需”激动”。查看一下源数据库。在本次迁移中,客户源数据库上有519个INVALID对象,我们迁移编译之后只有5个INVALID对象。如果目标库上INVALID对象与源库上相同,则数据库理论上可正常运行。

set pages 1000 lines 180
col owner for a20
col object_id for a80
col object_type for a30
select owner,object_id,object_type from dba_objects where status='INVALID';

如果没有问题,关库,使用startup重启。
结束数据迁移工作。
16. 开启归档模式
在数据库mounted模式下执行:

Alter database archivelog;

17. 添加备份计划
18. 修改pfile

以上过程中,除去拷贝粘贴,最为耗时的为执行升级脚本catupgrd.sql,约花费2-3小时时间。在执行脚本中可以观察告警日志,通常Oracle的APEX是INVLIAD(通常也不是INVALID,因为客户库原来安装有问题,所以是INVALID),其他组件为VALID,但是今天在正式迁移过程中,遇到Oracle Rules Manager也是INVALID的情况,但是在随后执行utlrp脚本时消除。

感谢Eygle大师的指点!

总结:经历了8次模拟和2次测试,今天终于能够一遍迁移成功,且比预计时间缩短3小时。除去拷贝文件及解压以外,真正升级时间大约在3小时左右。这是一次远程实施迁移的案例,令我受益匪浅。再次谢谢大师的指点和同事的帮助。谢谢我最爱的姐姐陪我到很晚。ps,五谷道场的泡面价高量少,还是推荐今麦郎。

    • 你可以看下控制文件中的内容(http://www.ioracle.org/archives/243),控制文件是二进制文件,其中记录了数据库数据文件、重做日志文件的位置,还有SCN等信息。如果拿过来直接用,可想而知,Linux中这些文件位置与Windows中大不相同,由mount到open过程中,校验控制文件中对应文件中的位置,会一无所获,数据库也不会被打开。

  1. Pingback: iOracle » Step by Step – Oracle database physical migrate

普人特福的博客cnzz&51la for wordpress,cnzz for wordpress,51la for wordpress