Oracle已经不再对9i进行支持,HP对RISC平台支持将到2013年截止,因此陆续将有相关的升级项目出现,以下是对涉及到的数据库升级步骤和方法进行阐述。
一、版本要求
建议9i数据库版本至少9.2.0.7,10g的版本至少10.2.0.2
二、测试环境
源 : HP-UX RISC/ RP8420/B.11.11/oracle9.2.0.8
目标: HP-UX Itanium/RX3600/B.11.31/10.2.0.4
三、源数据库迁移准备步骤
1、源数据库生成控制文件脚本
SQL>alter database backup controlfile to trace
$ strings spfile.ora >init.ora
2、从10.2.0.4拷贝utlu102i.sql和utltzuv2.sql,并运行
utlu102i.sql -- 生成数据库升级检查信息报告
utltzuv2.sql -- 检查时间区域
3、收集数据库用户权限信息
4、检查数据库是否存在dblink设置
5、检查是否存在N-type的列,如果存在,需要先前转化
6、进行统计分析,并备份统计信息
7、检查数据库是否存在无效对象,损坏字典
8、确认物化视图和快照是否完成,是否存在复制设置
9、检查v$recover_file,是否存在数据文件正进行media recovery
10、确保没有文件处于备份状态
11、检查是否存在正运行的交易,如果有,对该交易进行终止
12、检查是否存在批量导入导出,或定时执行作业
13、检查系统用户是否正常指向对应表空间
14、检查AUD$是否存在系统表空间
15、检查是否存在XDB.MIGR9202STATUS表,如果存在,删除它
16、正常关闭数据库,进行备份,备份方法:
--使用RMAN进行冷备份
--通过存储设备卷快照功能进行复制
--数据文件是文件类型,采用ftp传送到目标系统
四、目标数据库升级步骤
完成10.2.0.4数据库软件安装后,执行以下步骤
1、检查修改参数文件init.ora,修改参数
-- compatible=9.2.0.0.0
-- shared_pool_size , pga_aggregate_target,
large_pool_size, java_pool_size
streams_pool_size根据3.1检查报告建议值设置
-- 如果设置NLS_LENGTH_SEMANTICS=CHAR需要改成bytes
-- db_domain
-- AQ_TM_PROCESSES=0 和JOB_QUEUE_PROCESSES=0
-- UNDO_MANAGEMENT=AUTO
-- fixed_date没有设置
2、启动数据库为nomount状态,修改并运行控制文件脚本
3、启动数据库为升级模式
SQL>startup upgrade
4、根据3.1检查报告,有可能增加表空间大小
SQL> alter database datafile 'xxxxx' size xxxm;
5、创建SYSAUX表空间,至少500M
6、升级数据库字典
SQL> @catupgrd.sql
7、检查数据库组件状态
SQL>@utlu102s.sql TEXT
SQL>select comp_name, status, version from dba_registry;
8、正常关闭数据库,并重新启动
SQL>shutdown immediate
SQL>startup restrict pfile='/xxxx/init.ora'
9、重建Oracle Label Security 表中DML触发器
SQL>@olstrig.sql
10、检查是否存在无效对象,必要时候进行编译
11、重启,统计分析字典
SQL>EXEC DBMS_STATS.GATHER_DICTIONARY_STATS ;
五、通过SQL性能分析器测试新旧数据库SQL性能
在11g引入了一个Real Application Testing Option,通过一台配置降低机器,安装11g数据库。通过源和目标数据库SQL跟踪对比,生成升级前后性能分析报告,具体步骤:
1、在源数据库创建SQL trace文件
2、生成映射表
3、将跟踪文件拷贝到11g主机目录下,生成SQL数据集
4、创建数据库性能分析任务,在源和目标数据库运行测试脚本
5、比对两者之间的性能数据,生成差异性SQL性能报告
6、应用开发人员根据该报告进行修改调整
因为从9i到10gCBO发生了变化,还有一个省事的办法,设置OPTIMIZER_FEATURES_ENABLE=9.2.0。
六、其他建议
因为CBO发生变化,对以下几个环节需要注意
1、统计分析使用dbms_stats,不建议使用analyze
2、在参数文件中不要在设置db_file_muitlblock_read_count
3、要注意捆绑变量窥探(bind variable peeking),因为其可能造成执行计划变化
4、执行计划中采用Index skip scans,需要检查
5、In-List成本计算公式有可能发生变化
6、Transitive Closure成本计算公式发生变化(可参看前面博客)
7、sysdate算法变化
8、Indexing Null
9、pga_aggregate_target,在10.2.0.4有一个PLSQL中forall loop的bug
10、_complex_view_merging,(参看前面博客)
11、子查询语句中执行计划变化最大,性能问题也最多,通常需要加hint来解决
12、并行查询发生变化
13、动态采样发生变化,9i是1,10g是2
14、数据字典统计,10g缺省每天自动进行统计分析,有可能造成统计数据变化,导致执行计划发生突变。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/354732/viewspace-661737/
,如需转载,请注明出处,否则将追究法律责任。