一次RAC的存储间迁移

作者：李海天(Aibo)

中国OCM之家联合发起人、Oracle 11g/12c OCM认证获得者，已培养OCP/OCM数百人，从业7年以上，资深数据库专家，Oracle高级顾问。

近期公司置购了二台EMC高端存储，领导想把一些比较重要的核心数据库及其备份迁移至新的存储上设备上，服务器保持不变。对于单实例的数据库迁移我相信很多童鞋都已经非常熟悉了并且各自掌握的迁移手段也有很多套路也是千变万化。但是对于RAC的迁移还需要了解一些集群层面的概念和考虑一些集群层面的文件OCR、VOTING Disk、ASM Spfile。

本案例使用虚拟机模拟真实生产环境，对应介质版本：gi&db11.2.0.4，ocr&voting disk存储asm中，如果你的环境不同与我的环境可能命令方面会有些差异，无伤大雅重要的是思路。

检查OCR存储路径：

检查VOTING DISK存储路径： 

检查ASM  SPFILE存储路径： 

检查DB  SPFILE存储路径： 

检查CONTROLFILE存储路径：

检查DATAFILE&&TEMPFILE存储路径： 

检查LOGFILE存储路径：

检查fast_recovery_file_dest&&archivelog location： 

以上文件或路径均需迁移定义到新存储设备上。

在新存储设备上创建ASM磁盘组(DG_OCR、DG_DATA、DG_FRA)，这里设置的磁盘组名字比较相似，主要是为了方便快速阅读与理解。 

迁移OCR文件至DG_OCR磁盘组：

由于OCR文件创建时只有1份后续也没有增加冗余，所以无法采用replace方式迁移OCR，只能采用添加一个再删除一个的笨方法。如果你的OCR文件有多份，那么可以直接使用replace方式来完成。 

迁移VOTING DISK文件至DG_OCR磁盘组：

创建VOTING DISK时保留3分，所以这里可以直接使用replace方式迁移，从图中可以看出replace方式也采用是先增加后再删除方式来完成的。

迁移ASM SPFILE文件至DG_OCR磁盘组：

迁移ASM SPFILE需要关心3个问题：

• 如何把ASM SPFILE移动到新的磁盘组中；

• 如何让OCR知道ASM SPFILE的新路径；

• 如何重启ASM实例使之生效。

1. 使用ASMCMD方式登入ASM实例管理磁盘组后普通的CP命令是无法将ASM SPFILE拷贝到其它磁盘组中的，这里ASMCMD提供了一个新的命令SPCOPY完成ASM SPFILE的拷贝工作。

2. 即使ASM SPFILE已经移动到新的磁盘组中，但是OCR还不知道这件事情，需要让OCR文件识别ASM SPFILE最新的路径,使用ASMCMD中的SPSET命令完成此操作。这里可以看出11gR2中的ASMCMD功能还是蛮强大的，阅读手册get更多ASMCMD下的其它功能。

3. 在RAC环境下是无法单独关闭ASM实例的，由于OCR文件存放在ASM磁盘组中，使ASM实例始终被占用，需要关闭CRS服务才可以关闭ASM实例。

尝试关闭ASM实例失败： 

在集群中任意节点使用ASMCMD更改ASM SPFILE路径即可，CRSD进程会同步到所有节点的OCR CACHE中。

重启所有节点CRS服务，检查ASM SPFILE是否已经成功迁移：  

迁移DB SPFILE至DG_DATA磁盘组：

首先需要把SPFILE拷贝至DG_DATA磁盘组中，这个时候还需要修改每个节点的本地PFILE文件指向新的SPFILE路径，当再一次启动RAC数据库时你会发现数据库的SPFILE并没有使用最新设置的路径而是使用原来的路径，观察一下所有节点本地的PFILE会发现又指向回原来的SPFILE路径了，Oracle会把刚才修改过的PFILE更改一个名字，在本地重新生成一个PFILE指向原来的路径。需要了解的是RAC的SPFILE位置是记录在OCR中并由集群软件进行管理，所以要改变SPFILE的路径就必须要更新OCR配置。RAC在每次数据库启动时，首先是尝试读取OCR记录的SPFILE位置，找不到对应参数文件或文件损坏会继续在本地读取参数文件。

在DG_DATA磁盘组中生成SPFILE： 

不是所有的文件都可以存储在ASM磁盘组中，有哪些文件可以存储在ASM中是由Oracle严格规定的，简单理解就是ASM中存在一张文件类型列表，每个文件第一个块都会记录这个文件的属性信息(例如OS块)，当准备把文件传送到ASM磁盘组上时，Oracle会检测这个文件类型，匹配则可以存储。不匹配报错ASMCMD-8012: cannot determine file type for file。ASM自动开启OMF无需指定绝对路径，即使指定了绝对路径ASM也会自动创建一个连接文件。

DG_DATA磁盘组中查看SPIFILE绝对路径： 

用srvctl命令更新RAC数据库SPFILE存储路径，重启数据库使其生效，同时更新本地PFILE自动指向SPFILE最新路径。 

关闭RAC数据库下其它节点实例，只启动其中一个实例进行以下操作，首先修改一些参数，相信这些参数大家都很熟悉无需过解释。 

迁移CONTROLFILE至DG_DATA磁盘组：

使用镜像副本方式迁移数据文件至DG_DATA磁盘组：  

迁移LOGFILE至DG_DATA/DG_FRA磁盘组：

至此整个迁移过程结束，最后不要忘了还要删除OCR/DATA/FRA磁盘组。虽然RAC数据库已经不再使用DATA/FRA磁盘组，但ASM实例依然会显示被占用，没关系重启CRS清理一下缓存即可。 

重启后可以看到OCR/DATA/FRA磁盘组未被占用，可以开始删除磁盘组了。

删除ASM磁盘之前必须在所有的ASM实例中卸载该磁盘组。

删除OCR/DATA/FRA磁盘组：

本案例中使用ASMLIB方式创建ASM磁盘，需要删除ASM磁盘，如果使用udev方式也需要清理对应的规则。 

最后登入存储管理终端回收lun设备映射即可，此次存储间迁移工作结束。那么真的结束了吗？

重启CRS后发现数据库资源没有被CRSD自动启动。 

使用单实例方式启动数据库一切正常，那么CRS为什么不能启动数据库呢？尝试srvctl命令启动数据库，报错如下：

从报错信息中能清晰看到，启动VASTEDU数据库需要识别DATA和FRA磁盘组，DATA和FRA磁盘组已经卸载删除并回收对应的ASM磁盘了，一定不可能识别到它们的。前面的步骤已经把数据库中所有的数据迁移至新磁盘组中，那么这里Oracle为什么启动数据库时还需要去找这2个过期的磁盘组呢？

查看一下CRS组件资源列表： 

由于前面删除ASM磁盘组时，采用的是命令行的方式删除，删除后并没有更新OCR，需要手动更新OCR方可。如果这里使用了图形化方式删除磁盘组（ASMCA）那么Oracle会自动更新OCR配置。

更新OCR配置（集群层）： 

查看RAC数据库配置（应用层）： 

更新RAC数据库配置（应用层）： 

再次重启CRS后数据库资源正常启动：

本案例采用测试环境模拟，没有考虑到数据库备份，这里简单说一下关于数据库备份需要注意的地方：如果数据库的数据量和交易量可以接受迁移之后做一次数据库全备，如果数据库的数据量和交易量不可以接受，需要迁移备份文件并向控制文件注册元数据。最后修改备份脚本路径。

这回是真的结束了～～～～

总结：建议大家在日常工作中对RAC管理时思路和操作一定要和单实例的管理严格区分开，对一个项目实施完成后清理工作也是尤为重要的。

中国OCM之家

专注数据    共现梦想

QQ群：554334183