3,491
社区成员
发帖
与我相关
我的任务
分享求Oracle 9208不停机或尽量短时间停机升级到11.1.0.7的方案(续)
小小的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（未使用传输表空间）的测试。。。
明天来贴结果，前一段时间忙乎其他的去了
各位大大在哪边回复都可以，一样给分，鞠躬
另，测试全库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（未使用传输表空间）的测试。。。
明天来贴结果，前一段时间忙乎其他的去了
...全文
请发表友善的回复…
发表回复
xiaoxiao1984 2009-07-23
- 打赏
- 举报
呵呵，之前测试过了，花费2个小时导出
BlueskyWide 2009-07-23
- 打赏
- 举报
参考一下如下做法，看能否行？
1.在primary机中导出（exp）所有的库；
2.在stand by机中装好Oracle 10g，创建表空间和用户后，实施数据库导入（imp）;
3.编译无效数据库对象；
4.经测试无误后，将此IP网络数据库服务器接入。
时间可按排在夜间，如凌晨3点，全部在停机后实施导入和导出。如经充分测试后，应该不会太长时间。
1.在primary机中导出（exp）所有的库；
2.在stand by机中装好Oracle 10g，创建表空间和用户后，实施数据库导入（imp）;
3.编译无效数据库对象；
4.经测试无误后，将此IP网络数据库服务器接入。
时间可按排在夜间，如凌晨3点，全部在停机后实施导入和导出。如经充分测试后，应该不会太长时间。
Andy__Huang 2009-07-23
- 打赏
- 举报
学习！
yhuib 2009-07-23
- 打赏
- 举报
学习了
csuxp2008 2009-07-23
- 打赏
- 举报
看高手解决问题
xiaoxiao1984 2009-07-23
- 打赏
- 举报
最后测试通过的升级方案：约需要停机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分钟。
嘿嘿，下班前结这两个相关的帖子
修改之前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分钟。
嘿嘿，下班前结这两个相关的帖子
liuyi8903 2009-07-15
- 打赏
- 举报
32bit to 64bit 至少是没有经过认证的.oracle9i下.
超维电脑科技 2009-07-15
- 打赏
- 举报
UP蹭分了
xiaoxiao1984 2009-07-15
- 打赏
- 举报
长期没来贴结果，忙着写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
大家轻拍，偶做测试做的慢，灰溜溜的爬走
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
大家轻拍，偶做测试做的慢，灰溜溜的爬走
zl3450341 2009-07-09
- 打赏
- 举报
关注
liuyi8903 2009-07-09
- 打赏
- 举报
其实我认为只需要一个应用的切换时间就可以了.
liuyi8903 2009-07-09
- 打赏
- 举报
你可以先切换成partition,
如果可能的话,比如range partition
这样,就好办了.先把历史的partitition迁移过去,怎么样方法都可行,而且在线的.
然后再最后的活跃分区在停机时处理(也可以不停机)
又是违规昵称 2009-07-09
- 打赏
- 举报
导的时候不要统计信息，能快点
moqingcn 2009-07-09
- 打赏
- 举报
这么慢..
jdsnhan 2009-07-03
- 打赏
- 举报
猫儿用的啥机器啊。
30g的数据两个小时都没搞定
30g的数据两个小时都没搞定
liuyi8903 2009-07-02
- 打赏
- 举报
TTS完全可以的,不用担心.
子陌红尘 2009-07-02
- 打赏
- 举报
继续关注...
inthirties 2009-07-02
- 打赏
- 举报
不会吧，你才30G的数据而已，怎么可能要2个小时。可以用schema这样的方式做么。
我以前这样做的，将近一倍你的数据，导出在导进不到一个小时。
我以前这样做的，将近一倍你的数据，导出在导进不到一个小时。
