求Oracle 9208不停机或尽量短时间停机升级到11.1.0.7的方案(续)

Question

小小的bs CSDN 一把，贴主都不能连续回复3次以上，逼迫我开新贴
各位大大在哪边回复都可以，一样给分，鞠躬
另，测试全库exp direct=y 需要2个半小时的时间，太慢了点，没柳荫凉大大说的那么快，或许服务器比较差劲吧，主要是有一张表非常非常的大，数据量上亿，大约数据的95%都在这张表里了[ora92@mddbstandby exp]$ cat exp_md9idb_20090702.log Start export file at  Thu Jul 2 14:58:31 CST 2009
End export file at Thu Jul 2 17:21:42 CST 2009开始RMAN（未使用传输表空间）的测试
明天来贴结果，前一段时间忙乎其他的去了

Answer 1

不会吧，你才30G的数据而已，怎么可能要2个小时。可以用schema这样的方式做么。我以前这样做的，将近一倍你的数据，导出在导进不到一个小时。

Answer 2

你可以先切换成partition,如果可能的话,比如range partition这样,就好办了.先把历史的partitition迁移过去,怎么样方法都可行,而且在线的.然后再最后的活跃分区在停机时处理(也可以不停机)

Answer 3

长期没来贴结果，忙着写Form的导入功能partition 表是hash复合分区，每个最小的分区里大概都是百万乃至千万的数据，实时性要求比较高，极其害怕出错
不能确定哪些是历史数据的分区，哪些不是，所以不能先把历史分区的弄过去机器长期load比较高，io等待60%左右，一开始rman备份，负载就嗖嗖嗖的上去了；下面测试的方案都是在32位的standby机器上测试完成的已经测试通过的方案:
1. 配置9208 64bit 作为9208 32bit的物理standby
2. 9208 32bit主库readonly提供服务，执行几次switch logfile，保证9208 64bit 上得到最新的logfile (该步骤未测试，从理论上说，一个switchlog的操作不会出现问题)
3. 激活9208 64bit的机器，然后执行 ?/rdbms/admin/utlirp.sql 重新编译一次无效对象
   说明：Oracle的官方文档没有明确说明支持还是不支持9i 32/64bit做物理standby ,10g就明确支持了；9i物理standby在应用归档方面没有问题，但是在连接数据库进行查询的时候，会提示 ORA-06553: PLS-801: internal error [56319]...错误，这个错误可以通过重新编译无效对象来解决
4. 9208不迁移数据文件调用dbua进行升级，这个步骤大约花费1个小时
说明：也许在步骤3可以不做重编译无效对象，dbua升级的过程肯定也会重新编译无效对象的，或者在dbua升级完成之后，做一次编译
5. 升级完毕后检查是否正确，然后通知应用切换继续找时间测试TTS
大家轻拍，偶做测试做的慢，灰溜溜的爬走

Answer 4

32bit to 64bit 至少是没有经过认证的.oracle9i下.

Answer 5

最后测试通过的升级方案：约需要停机5分钟左右，肯定不超过10分钟修改之前readonly提供服务的方式，仍然提供可读写的数据库，减小对服务的影响。1. 配置9208 64bit 作为9208 32bit的物理standby，升级前保证standby的log seq和主库一致 
2. 9208 32bit主库执行一次switch logfile，记录下归档日志号
3. 应用步骤2生成的归档日志，激活9208 64bit standby的机器，然后执行 ?/rdbms/admin/utlirp.sql 重新编译一次无效对象 
4. 9208不迁移数据文件调用dbua进行升级（提前安装好数据库软件11g，只升级数据库），这个步骤大约花费不到26分钟
5. 升级完毕后，在原32位服务器上做switch logfile，把升级过程中(大约30分钟时间，不超过40分钟)生成的logfile拷贝到64位机器上，使用logminer挖出SQL语句，在64位新机器上执行SQL语句（提前写好通过归档文件生成SQL和执行SQL的脚本）
6. 关闭原服务器，把最后生成的小归档日志拷贝至新64位机器上解析并执行，成功后检查数据库无问题，通知应用切换。期间正常情况，只需要停止服务不到5分钟。嘿嘿，下班前结这两个相关的帖子

Answer 6

参考一下如下做法，看能否行？1.在primary机中导出（exp）所有的库；
2.在stand by机中装好Oracle 10g，创建表空间和用户后，实施数据库导入（imp）;
3.编译无效数据库对象；
4.经测试无误后，将此IP网络数据库服务器接入。时间可按排在夜间，如凌晨3点，全部在停机后实施导入和导出。如经充分测试后，应该不会太长时间。