Oracle数据库从Window XP迁移到Win7的诡异问题

       最近公司的所有的操作系统都统一升级到Win7系统。我们公司有一个做工程计划的ORACLE 的一个产品软件叫Primavera Six(简称P6). 所以我需要把P6 的数据库从XP迁移到Win7系统。因为以前也做过从XP 到 XP系统的P6数据库的迁移成功过，而且是一次成功，没有出什么问题的。这次就没有在做迁移之前做测试。呵呵，有点自信过度了，以后一定要先做测试，否则如果是限制时间做数据库迁移的话，尤其是帮客户做项目的话，那可就被领导和客户批评了，还好我这次是自己公司的数据库，而且对时间要求不限制。我可以有几天的时间去查找回复不成功的原因。下面我来说说这个迁移的故事吧。

       2014年4月10日早上就写邮件给相关用P6系统的同事，告诉他们，我从4月10号到4月11号做服务器的数据库迁移，所以在此其间数据库用不了。其实要不了这么长时间，主要是我们公司安装卸载程序还需要专门的人员授权才可以操作软件，所有的软件都不能在没有授权的情况下安装或者卸载，有点变态哦，哈哈。这也好，我就吧迁移时间说长点。我4月10日就和IT说，我4月11日要升级OS到WIN7，我今天把数据库和相关的软件做好备份，当然这个服务器里还有MYSQL数据库等信息。今天重点是说ORACLE的数据库的备份。MYSQL我自己写了个每天自动备份的小批处理，基本迁移到WIN7没有问题。于是我就把数据库做了几下日志切换:alter system switch logfile。我还是做两手准备吧，因为数据库比较小。

开始做迁移：

1，所以做一个全库冷备

a, 把数据库关闭 shutdown immediate 。

b,把所有的数据文件都拷贝下了, 包括tempfile,datafile,redo logile,controlfile等等

2，在数据库mount下用RMAN做一个全库备份。

a, RMAN的配置如下：

RMAN> configure channel device type disk format 'd:\bak\backupset\%U';

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP on;
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'd:\bak\ctrlbak\%F';

RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 5;
RMAN> CONFIGURE RETENTION POLICY TO recovery window of 5 days;
RMAN> backup as compressed backupset database plus archivelog;

 

b,从上面可以看出我备份的文件路径分别是：

控制文件自动备份的配置给设置好：CONFIGURE CONTROLFILE AUTOBACKUP on;

控制文件路径：d:\bak\ctrlbak

数据文件路径：d:\bak\backupset

 

C， 开始用RMAN做备份

RMAN〉BACKUP DATABASE;

备份完毕后，把d:\bak下的文件拷贝起来，同时把online redo log文件也拷贝下来，这个到后面，回复的时候我会告诉你的用处。再把其他的要备份的备份到移动硬盘上去。

4月10日就这样结束了，等待4月11日IT给吧XP的系统给抹掉，装上WIN7 系统再做回复。

 

4月11日，IT从早上一直搞到下午3点，才把OS升级到WIN7。于是，我就立即准备把MySQL安装上，把MYSQL的数据库回复上，MYSQL数据库恢复一切顺利，不到1个小时搞定，再把我自己开发的客户端程序安装下，连接下MYSQL数据库，一切正常。我开发的信息系统顺利连接上MYSQL数据库，客户端程序运行正常。下面就是开始着手安装Primavera Six,当然这个软件是自动的把ORACLE的数据库一起安装的，这个软件依然用的是ORACLE10.2.0.1.0的版本。用了差不多30分钟，P6安装好了。这个安装P6其实也是有一段很有趣的故事的，下面我来讲讲次故事：

因为我们的WIN7不是不一天安装的，公司人比较多，IT分了三个星期的时间分批安装，我一个同事在一周前安装P6的时候，发现不能用。后来让我去看下是什么原因，我查了下数据库，当我做数据库连接配置的时候，系统竟然说我没有权限在C:\Program Files (x86)\ ，具体的目录记不得了，写文件。连接数据库的配置是需要写数据库配置信息到本来磁盘的，竟然说我没有权限写的权限，我自己的电脑啊，我很纳闷，于是问我们的IT，他们说是公司的POLICY，所有的用户都没有administrator的超级用户的权限，这个权限在他们IT那。我当场晕死，奇葩吧。呵呵！没有办法，公司的POLICY，我们必须遵守。于是我尝试到C:\Program Files (x86)目录下创建一个文件夹，系统提示我需要输入用户名和密码验证，又一次当场晕倒，不让我建立目录，需要检验，怪不得程序没有办法写信息到此目录，于是我返回到C盘根目录下尝试创建一个文件夹，不需要验证，证明我是可以在C盘根目录下有写的权限的。你有可能会问我，为什么把数据库和系统盘安装在一个磁盘即C盘啊，这个我也不愿意啊，我们所有的电脑都只有一个分区盘即只有一个C盘。是不时觉得奇怪，你可能会问，难道不怕中病毒吧系统盘给搞坏了，那数据库不遭殃了啊。这个您放心，我们公司的杀毒软件还是可以的，监控不错。当然如果是磁盘坏了，我也没有办法了。通过上面的分析，我就分析，我们在用C:\Program Files (x86)下的权限有问题，由于很多安装程序都是默认安装到C:\Program Files (x86)下面的，所以导致了我们没有权限和没有办写数据库配置文件到本地的受权限控制的目录。所以我把P6卸载了重新安装，此时我把安装目录放到C盘的根目录下，花了20分钟，安装成功。当然，这个时候配置数据库也是成功的。此故事讲完了。

接着上面数据库恢复的事情，数据库安装好了后，我就把我用RMAN备份的数据拷贝到这个电脑的C:\bak\下。我就准备用RMAN做恢复操作，具体步骤如下：

a, 把数据库打到nomount 状态下。

SQL>startup nomount;

b,  用命令行启动RMAN接口, 具体命令是：

C:\>RMAN TARGET  sys/pwd  

b, 恢复备份的控制文件,具体命令如下：

RMAN>restore controlfile from 'disk path';

C, 控制文件恢复好了，我就可以把数据库置到mount状态了，这个样RMAN就可以读控制文件里的信息来恢复数据库了，我用的是controlfile，没有用catalog。所以这些信息都是存储在control file里的。把数据库置为MOUNT下，在RMAN里操作的命令如下：

RMAN〉sql ' alter database mount';

mount成功我就可以开始restore database了。

D，还原数据库

RMAN>restore database;

还原失败，如下图：

从上面的提示可以预测到是没有找打备份集文件。我是有备份文件的啊，文件的就在c:\bak\backupset  和c:\bak\ctrlbak里分别是数据文件和控制文件的最新备份啊。为什么没有找到呢？ 于是我就是RMAN肯定是通过control file里的记录信息来找备份文件的路径的，于是我就猜测RMAN记录的路径里没有文件可能。我可以用list backup来看下备份集的路径在哪里。

请看下图：

从上面可以看出，控制文件里记录的备份集路径是d:\bak\backupset目录。而我的备份文件是拷贝在c:\bak\backupset里的，当然RAMN会出现上面的错误了，说找不到备份文件。但是现在我有又悲剧了，上面说过我们的电脑只有一个C盘，没有其他的盘符了。没有办法只有想办法把数据拷贝移动硬盘上，然后想办法把移动硬盘我需要的备份数据的盘符设置为D盘，然后再上面建立bak\backupset路径，并且把备份文件拷贝到此目录下，进行恢复了。等路径都设置好了后，再次重新restore database.如下图：

 

 从上面的显示(reading from backup piece d:\bak\backupset\3AP5A2E3_1_1)可以看出这个时候读取的文件就是我备份的文件。正常情况下应该是会成功的。

 从上面可以看出restore是成功的。下面我们再来进行recover database

RMAN>recover database;

 我recover database的时候，提示少了一个log，应该是少了在线redo log.这个也就是我在上面说的要把redo log也拷贝备份下的原因。把备份的online redo log拷贝到相应的位置，继续做recover database,如下图：

这次recover database成功了。

下面再打开数据库，由于数据库做了recover，所以需要用resetlogs打开数据库了，命令如下：

RMAN>sql 'alter database open resetlogs';

到此我用RMAN恢复数据库成功了。此时心里很高兴。但是我的悲剧是是没有结束，且看下面我的悲剧又来了。

既然数据库都恢复成功了，那我就打开P6的应用程序看下能否使用，当我打开的时候，一开始程序加载数据是没有问题的，但是加载了一会儿后，就突然跳出一个窗口如下：

 

 

上面的错误提示出现了，我只能从上面判断是应用程序没有成功的把数据库成功加载。不知道是什么原因导致的。我第一反应是是不是XP系统到WIN7的原因，于是我找IT找了台XP的系统，并且在上面做了一下上面同样的恢复动作，同样是数据库恢复没有问题，打开P6应用程序出现的时同样的错误提示，于是排除和操作系统有关系的原因。

这个时候我开始通过SQLPLUS登陆到数据库，查询下相关的表

我查dba_data-files没有问题，

我查dba_temp_files 时出现一个错误说我TEMP文件损坏不可以读取。具体的截图当时没有截屏下来，于是我恍然大悟，是临时表空间坏了，导致P6系统在登陆的时候，提示一个诡异的错误，说数据加载不成功，因为加载数据的时候需要用到临时表空间做排序等等动作。于是我重新建立了一个临时表空间，命令如下：

Create temporary tablespace TEMP1 tempfile 'C:\oraclexe\oradata\XE\TEMP1.DBF' size 64M autoextend on maxsize 2G

extent management local uniform size 1M

把TEMP1设置为数据库默认临时表空间：

alter database default temporary tablespace TEMP1;

再把TEMP的损坏的临时表空间给删除掉。

Drop tablespace TEMP including contents and datafiles;

再次登陆P6客户端应用程序，终于成功了。

 

对这次的故事我做出以下的总结：可以说是自己的一个lessons learned吧。

A， 做正式数据库迁移之前一定要模拟的尝试测试下，免得会在正式迁移的时候，出现奇怪诡异的问题，不知所措。

B， source database 的服务器和Target database的服务器一定要最好是盘符，路径规划都一样。就不会出现我的恢复的过程中，出现找不到备份文件的问题。

C， RMAN 做备份的时候一定要把online redo log备份下，否则我出现我上面最后recover database出现找不到log的问题

D， 数据库恢复到Target服务器上后，一定要检查下数据库的逻辑文件是否都正确，例如：dba_data_files, dba_temp_files 等等，否则会出现我的TEMP文件坏了，出现奇怪的问题。

 

到此整个ORACLE 从XP到WIN7迁移的诡异的故事结束，谢谢！