Oracle数据库升级向来是一门纷繁复杂的工程，DBA需要为产品数据库的升级耗费大量时间精力在准备工作上；因为其升级复杂度高，所以即便做了较为充分的准备仍可能在升级过程中遇到意想不到的问题，为了更高效地完成升级任务和减少停机时间，我们有必要为升级工作营造一种”舒适的”防御式的数据库”氛围”:
1.为了保障升级后的数据库性能，我们有必要在升级前有效地收集数据库的性能统计信息，以便升级后若发生性能问题可以做出对比:
为了保证性能统计信息真实有效，有必要在数据库升级前的一个月即开展收集工作 收集的性能统计信息应当尽可能的精确真实 在Oracle 8i/9i中使用Statspack性能报表，将快照级别设置为6或更高，设置快照间隔为30分钟，在具体升级前将perfstat用户使用exp工具导出，参考Metalink文档Note:466350.1介绍了若何对比升级前后的Statspack快照 在Oracle 10g/11g中使用AWR自动负载仓库性能报告，保证采集30天左右的快照，快照间隔最好为30-60分钟;之后可以使用dbms_swrf_internal.awr_extract存储过程将AWR导出到dumpfile文件，在升级完成后载入这部分AWR信息，并可以使用DBMS_WORKLOAD_REPOSITORY.AWR_DIFF_REPORT_HTML函数对比升级前后的性能
2.正式升级前的防御性措施:
过多的审计信息可能会导致升级速度下降，可以在升级前将审计数据导出，并清理审计字典基表: 截断SYS.AUD$基表: SQL>TRUNCATE TABLE SYS.AUD$; 同样的有必要清理10g后出现的回收站： 清理DBA回收站: SQL>purge DBA_RECYCLEBIN; 移除一些”过期”的参数，设置这些参数的原因很有可能是为了修正原版本上的一些问题，例如我们都会做的设置event参数；但在新版本中这些参数是否仍有必要设置是一个值得讨论的问题，当然你完全可以就此事去提交一个SR： 这些”过期”参数可能包括:过老的如optimizer_features_enable=8.1.7.4,_always_semi_join=off,_unnest_subquery=false 或者event = “10061 trace name context forever, level 10″，如此之类等等。 为数据库中的数据字典收集统计信息: 在Oracle 9i中可以执行以下过程收集数据字典统计信息, SQL> exec DBMS_STATS.GATHER_SCHEMA_STATS (‘SYS’, options => ‘GATHER’,estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => ‘FOR ALL COLUMNS SIZE AUTO’, cascade => TRUE); 在Oracle10g/11g中收集字典统计信息可以由GATHER_DICTIONARY_STATS存储过程来完成: SQL> exec DBMS_STATS.GATHER_DICTIONARY_STATS; . . . → Read More: Oracle数据库升级前必要的准备工作
最新评论