目前计划对跨平台的数据库环境进行迁移，一来降低运维成本，二来更加可控。其实对于很多机器来说，如果机器跑了很多年，一直没有重启过，那么时间长了，一个直观的感受就是稳定，这也是小机口碑远远好于PC的一个重要原因吧，但是如果机器有一天出了问题，那么可能就会让大家坐立不安。其实这也能够折射出很多的运维管理的一些误区，很多问题没有发生，不代表不会发生，这个时候墨菲定律就是大家公认的运维法则了。而且小机虽好，但是超过了服役期，那么就有可能是定时炸弹，毕竟服役时间远远大于预期，于情于理都能说得通了。
当然也综合评估了很多的原因，一来是datapump迁移步骤相对简单，很多复杂的schema对象可以直接通过导入来完成，如果是全库导入，那么可操心的事情就更少了。用户，角色，表空间等等全部都有。而且另外一个方面是考虑到datapump的迁移模式，这种逻辑迁移完全可以支持跨平台跨数据库版本，所以灵活性很高。最后就是性能了，在中小型的数据迁移中还是留有一席之地的。
那么采用了datapump，我们做跨平台的迁移，之前的测试不到200G的数据迁移大概需要1个小时左右的时间，我们需要在这个基础上进行更多的优化，尽可能缩短窗口时间。
所以就有以下的几个地方需要考虑。
redo的大小，
数据库的归档模式
IO的优化
数据库级别的优化
对于这几个方面，自己也是做了一些工作，当然也做了详细的对比测试，对比了机械硬盘和PCIE-SSD在同样数据量的情况下的数据迁移性能数据。
为了能够多次重现对比测试的效果，采用了初始化的数据库环境做冷备，然后在其上部署新的数据结构（表空间等),然后使用datapump导入数据。
大体的步骤罗列如下：
系统级内核参数设置和修改 --
重新建库 --
数据库参数设置和修改 redo设置为500M --
冷备，或者rman备份 --
部署变更后的数据结构信息
机械硬盘使用datapump加载数据
冷备恢复
部署变更后的数据结构信息，切换到SSD
SSD使用datapump加载数据
迁移完毕，重启设置归档模式
完善检查脚本(dblink检查 )
所以步骤已经很清晰了，我们就先打好基础，然后开始对比测试。
1)系统级内核参数设置和修改
这个可以考虑关闭NUMA,设置hugepage,调整资源使用(/etc/security/limits.conf)
2)重新建库
使用dbca silent模式建库，当然需要重点考虑字符集，还有redo的设置。一个简单的例子如下：
dbca -silent -createDatabase -templateName $ORACLE_HOME/assistants/dbca/templates/General_Purpose.dbc -gdbname testdb -sid testdb -characterSet ZHS16GBK -redoLogFileSize 500 -nationalCharacterSet AL16UTF16
3)数据库参数设置和修改
比如在一个64G的环境中，我考虑的数据库参数变更如下，暂不考虑隐含参数的调整。
alter system set sga_max_size=40G scope=spfile;
alter system set sga_target=40G scope=spfile;
alter system set shared_pool_size=10G scope=spfile;
alter system set session_cached_cursors=200 scope=spfile;
alter system set deferred_segment_creation=false scope=spfile;
alter system set sec_case_sensitive_logon=false scope=spfile;
alter system set db_recovery_file_dest_size=200G scope=spfile;
alter system set open_cursors=1000 scope=spfile;
alter system set processes=3000 scope=spfile;
alter system set db_writer_processes=2 scope=spfile;
alter system set resource_limit=true scope=spfile;
4) 冷备，或者rman备份
然后做一个完整的冷备，尤其注意要备份控制文件。
5)部署变更后的数据结构信息
是否表空间，数据文件存在一些路径差异，需要初始化这些空间的设置。
6)机械硬盘使用datapump加载数据
使用datapump加载数据，得到基本的统计信息
7)冷备恢复
测试完毕，开始恢复数据库，把数据库都切换到SSD上去
8)部署变更后的数据结构信息，切换到SSD
重新部署数据结构的变化信息
9)SSD使用datapump加载数据
使用datapump来做完全一致的数据导入测试
10)迁移完毕，重启设置归档模式
11)完善检查脚本(dblink检查 )
当然这个过程中也着实准备了不少的脚本，方便工作，而且对于测试的步骤做了一些简单的总结。
当然测试的结果也是很有差距的，使用PCIE-SSD的速度可以比机械硬盘提高一倍，如果在非归档模式下，速度还能提高一倍。
当然也综合评估了很多的原因，一来是datapump迁移步骤相对简单，很多复杂的schema对象可以直接通过导入来完成，如果是全库导入，那么可操心的事情就更少了。用户，角色，表空间等等全部都有。而且另外一个方面是考虑到datapump的迁移模式，这种逻辑迁移完全可以支持跨平台跨数据库版本，所以灵活性很高。最后就是性能了，在中小型的数据迁移中还是留有一席之地的。
那么采用了datapump，我们做跨平台的迁移，之前的测试不到200G的数据迁移大概需要1个小时左右的时间，我们需要在这个基础上进行更多的优化，尽可能缩短窗口时间。
所以就有以下的几个地方需要考虑。
redo的大小，
数据库的归档模式
IO的优化
数据库级别的优化
对于这几个方面，自己也是做了一些工作，当然也做了详细的对比测试，对比了机械硬盘和PCIE-SSD在同样数据量的情况下的数据迁移性能数据。
为了能够多次重现对比测试的效果，采用了初始化的数据库环境做冷备，然后在其上部署新的数据结构（表空间等),然后使用datapump导入数据。
大体的步骤罗列如下：
系统级内核参数设置和修改 --
重新建库 --
数据库参数设置和修改 redo设置为500M --
冷备，或者rman备份 --
部署变更后的数据结构信息
机械硬盘使用datapump加载数据
冷备恢复
部署变更后的数据结构信息，切换到SSD
SSD使用datapump加载数据
迁移完毕，重启设置归档模式
完善检查脚本(dblink检查 )
所以步骤已经很清晰了，我们就先打好基础，然后开始对比测试。
1)系统级内核参数设置和修改
这个可以考虑关闭NUMA,设置hugepage,调整资源使用(/etc/security/limits.conf)
2)重新建库
使用dbca silent模式建库，当然需要重点考虑字符集，还有redo的设置。一个简单的例子如下：
dbca -silent -createDatabase -templateName $ORACLE_HOME/assistants/dbca/templates/General_Purpose.dbc -gdbname testdb -sid testdb -characterSet ZHS16GBK -redoLogFileSize 500 -nationalCharacterSet AL16UTF16
3)数据库参数设置和修改
比如在一个64G的环境中，我考虑的数据库参数变更如下，暂不考虑隐含参数的调整。
alter system set sga_max_size=40G scope=spfile;
alter system set sga_target=40G scope=spfile;
alter system set shared_pool_size=10G scope=spfile;
alter system set session_cached_cursors=200 scope=spfile;
alter system set deferred_segment_creation=false scope=spfile;
alter system set sec_case_sensitive_logon=false scope=spfile;
alter system set db_recovery_file_dest_size=200G scope=spfile;
alter system set open_cursors=1000 scope=spfile;
alter system set processes=3000 scope=spfile;
alter system set db_writer_processes=2 scope=spfile;
alter system set resource_limit=true scope=spfile;
4) 冷备，或者rman备份
然后做一个完整的冷备，尤其注意要备份控制文件。
5)部署变更后的数据结构信息
是否表空间，数据文件存在一些路径差异，需要初始化这些空间的设置。
6)机械硬盘使用datapump加载数据
使用datapump加载数据，得到基本的统计信息
7)冷备恢复
测试完毕，开始恢复数据库，把数据库都切换到SSD上去
8)部署变更后的数据结构信息，切换到SSD
重新部署数据结构的变化信息
9)SSD使用datapump加载数据
使用datapump来做完全一致的数据导入测试
10)迁移完毕，重启设置归档模式
11)完善检查脚本(dblink检查 )
当然这个过程中也着实准备了不少的脚本，方便工作，而且对于测试的步骤做了一些简单的总结。
当然测试的结果也是很有差距的，使用PCIE-SSD的速度可以比机械硬盘提高一倍，如果在非归档模式下，速度还能提高一倍。
