从9i升级到10g两个方案可供选择.doc

从9i升级到10g两个方案可供选择: 1、利用oracle提供的一个升级实用程序dbua(database upgrade assistant)直接将9i的数据库升级到10g. 2、新建一个10g的数据库,利用oracle的导入/导出(imp/exp)实用程序迁移数据 1.首先来讲第一种方案(用升级程序:dbua): 适合: 这种方案适宜于数据量比较大,用导入导出工具来迁移可能要花费很长时间的数据库. 方法: 用这种方案的话我们要在原来的数据库的机器上安装10g的软件,不安装10g的数据库.安装完10g的软件后,运行10g的数据库升级助手实用程序dbua,然后通过此升级向导完成9ig到10g的升级过程.升级过程中, dbua会自动的将一些数据库的配置更改成适合10g的环境,如数据库参数设置,内存配置,sql,pl/sql引擎等和数据库管理,操作相关的软件的版本也会自动升级到10g. 优点: (1)对于数据规模比较大的数据库而言,用这种方法升级是最快速的. (2)保留原有数据库的物理结构(如数据文件,重做日志文件)和逻辑结构(表空间,用户,系统权限设置等),无需重新规划数据库. 风险: 这种方案存在一定的风险.虽然,10g的数据库升级助手实用程序dbua总体而言比较稳定,但是万一升级失败的话,原来的数据库就有可能使用不了,某些功能丢失,或运行不正常.所以在正式升级之前一定要先在测试库上先演练一下升级的所有过程,确认无误后才能在生产库上执行升级 IT成本:此种方案不需追加新的硬件投资. dbua支持直接升级的数据库版本: 1、 oracle 8版本8.0.6 2、oracle 8i版本8.1.7 3、 oracle 9i版本9.0.1 4、oracle 9i版本9.2.0 2.第二种方案(用导入/导出工具:imp/exp): 适合: 这种方案适合数据量不是很大,中小规模的数据库升级 方法: 用这种方案的话我们必须先把旧的数据库的数据导出来,然后新安装和新建一个10g的数据库,然后将旧库的dump文件导入至新库. 优点: (1)用这种方法最大的优点是安全. 我们新建一个10g的数据库并导入旧库的数据以后可能保留原来的数据库,直到应用系统在新的数据库运行无误后才删去原有的数据库.如果有问题,还可以切换回原来的数据库,升级的风险非常小. (2)可以优化数据库结构.如果原来的数据库结构不好,如很多用户的数据存储在system表空间,或者是表空间碎片比较多,通过导出再导入到一个数库后,这些数据库的结构能够得到优化. 缺点: (1)升级的时间可能相对会长一些,因为导入导出的速度并不是很快 (2)因为得新建一个数据库,所以得重新规划数据库的结构,如数据文件,表空间等. IT成本: 可能会增加一些硬件投资.因为要建新库嘛. Gryps(3913725) 13:39:51 imp/exp是不带用户角色的，按照旧数据库用户角色，表空间结构，一点一点扣出来拷贝出来，重新在心11G数据库构建，然后在imp 愿烟缠绕致失(280815672) 13:40:30 对，这样，很麻烦吧 愿烟缠绕致失(280815672) 13:40:49 技术总监，就是 怎么做的； 愿烟缠绕致失(280815672) 13:41:12 不过我是不会，我想用DBCA测试一下 Gryps(3913725) 13:41:16 是吗？我也是这么做的！ 愿烟缠绕致失(280815672) 13:41:32 我不会， 我们技术总监 是一点一点拷贝的 Gryps(3913725) 13:42:56 但是一些触发器，存储过程失效了，还有导入时一些表字段的长度提示太长导入失败行。 愿烟缠绕致失(280815672) 13:44:42 用dbua，不行吗？ Gryps(3913725) 13:45:32 我不需要数据库升级，我只是重建，移植 愿烟缠绕致失(280815672) 13:47:09 我们现在的库是9i的， 以后我们要用 11g了， 愿烟缠绕致失(280815672) 13:47:38 重建 移植 ，是个什么过程，，就是你说 的 一点点拷贝吗？ Gryps(3913725) 13:50:14 类似吧，table/trigger/procedure/function/package/job/user linux问题解决 13:58:34 11G的支持好像少一些