Chinaunix

标题: 7000万的图片表添加一个新字段和update一个字段类型，那种方案风险更小 [打印本页]

作者: linuxaid 时间: 2009-07-23 16:09
标题: 7000万的图片表添加一个新字段和update一个字段类型，那种方案风险更小
大家好：
最近碰到了一个非常棘手的问题，原来的一个遗留系统，其中有一张图片表，约7000万的图片数据，目前业务扩展，发现了一个严重的问题，某个重要的业务字段为char(20)类型，而char类型在不足20未数据的时候，会自动补齐空格，导致新的业务扩展开发无法正常进行，目前就有两种方案。
方案一：1、新增加一个字段，在新的业务扩展中启用该字段。

方案二：2、将原有字段char类型修改为varchar2类型。

风险所在：
1、数据量过大，做备份时间和空间都不允许。
2、生产系统，最多停机2天（周六、周日）。比如我如果采用更改字段类型的办法，如果一句update语句执行个3，5天。。。。那就废了。

大家给分析一下，那种方案风险最小，或者有更好的解决办法（增加中间关联表的方案就不必了，那新的开发商会跳楼去）
或者有什么办法，可以预估执行所需时间？
                                    谢谢
                                    祝工作顺利，多进米米

作者: anton 时间: 2009-07-24 09:24
两天时间足够啦，最好采用第二思路，直接修改表结构，成本最小也是最快的，你只是在原来字段去空而已，数据层面不会存在丢失风险，如果版本实在10G以下只是会影响到与该表相关view,funciton等对象失效，重新编译就可以，实现技术方法最好可以采用平行的sql的nologging、rename、temporary table过渡等多种方式中的一种,如果机器配置有限最好不要用update；
因为是生产环境，在实施之前最好做一个评估，如和该表相关对象、该字段数据质量分析、函数选取用trim或replace等做一个全面综合的评估，曾经处理过一个2亿多条的照片表，整个过程差不多8个小时。

[ 本帖最后由 anton 于 2009-7-24 09:27 编辑 ]

作者: ga0feng 时间: 2009-07-26 17:58
楼主真的很幸福，两天的down机时间还不够你自豪的阿。
你得数据库到底有多大？用RMAN备份可以节省空间，做hot backup不需要停机的（不过要开archivelog mode）。

作者: dingning239 时间: 2009-07-31 16:47
建议楼主直接修改，方便，对于应用程序来说也不需要进行别的修改

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)