当前位置: 首页 > 图文教程 > 数据库 > Oracle > Oracle 9i数据库中动态重配置深入分析

Oracle
Oracle数据库系统紧急故障处理方法
Oracle SQL性能优化系列学习一
Oracle 数据库操作技巧集
Oracle组件实现动态Web数据库
ORACLE常见错误代码的分析与解决二
ORACLE常见错误代码的分析与解决三
在Oracle 8x实现自动断开后再连接
深刻理解Oracle数据库的启动和关闭
Oracle对两个数据表交集的查询
Oracle 8i字符集乱码问题析及其解决办法
Oracle 数据库管理脚本命名规范
Oracle不同数据库间对比分析脚本
Oracle数据库安全策略
Oracle数据库的空间管理技巧
Oracle数据库系统使用经验六则
ORACLE数据库应用开发常见问题及排除
Oracle系统表外键的更名
Oracle约束管理脚本
如何确定Oracle数据库表重复的记录
Oracle数据库索引的维护

Oracle 9i数据库中动态重配置深入分析


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-10-31   浏览: 69 ::
收藏到网摘: n/a

Oracle9i最重要的新特性就能动态修改几乎所有Oracle性能参数。这使Oracle专家能在Oracle实例运行期间动态地重新配置它——不管是因为要解决当前的一个性能问题,还是因为预测到一个紧迫的性能需求。由于能动态修改系统全局区域(System Global Area,SGA)中的所有东西(SGA是Oracle的一个实例使用的RAM),所以至关重要的一点就是知道如何监视Oracle数据库。归纳出系统访问趋势及访问模式后,可因为预测到常规的资源需求而提前重新配置好数据库。

牵涉到动态数据库调节操作时,Oracle专家通常关心的是两方面的问题:事先安排好的重配置,以支持常规处理需求的变化;以及基于趋势的动态重配置,以响应从STATSPACK中获取的信息。下面来看看Oracle如何对这两种活动提供支持。

安排好的重配置

假定一个Oracle数据库在白天以“联机事务处理”(OLTP)模式运行,夜间以“决策支持”模式运行。这两种服务为了获得最佳的性能,分别提出了完全不同的要求。针对这种类型的数据库,Oracle DBA可事先安排好一个任务,针对当前的处理类型,将Oracle实例重配置为最恰当的配置。

通常可选择两种工具之一来安排动态重配置。最常见的方式是使用一个UNIX cron作业,它启动一个shell脚本来安排定期重配置。还可使用Oracle dbms_job实用程序。这两种工具都允许你安排一次配置更改。

清单A如下:

Listing A: Script to change to DSS-mode    #!/bin/ksh # First, we must set the environment . . . . ORACLE_SID=$1 export ORACLE_SID ORACLE_HOME=`cat /etc/oratab|grep ^$ORACLE_SID:|cut -f2 -d':'#ORACLE_HOME=`cat /var/opt/oracle/oratab|grep ^$ORACLE_SID:|cut -f2 -d':'` export ORACLE_HOME PATH=$ORACLE_HOME/bin:$PATH export PATH $ORACLE_HOME/bin/sqlplus –s /nologin<  alter system set db_cache_size=1500m;alter system set shared_pool_size=500m;alter system set pga_aggregate_target=4000m;exit !
  

清单A提供了一个UNIX脚本,可用它针对决策支持处理而重配置Oracle。注意该脚本修改了shared_pool、db_cache_size以及pga_aggregate_target等参数,以满足数据仓库活动的需要。第二天早上可运行一个类似的脚本,将数据库配置变回OLTP模式。

基于趋势的动态重配置

执行基于趋势的动态重配置时,要收集有关Oracle数据库的历史数据,并用这种信息来提前重配置数据库,具体做法可能是使用dbms_job包进行临时性更改,或使用前面讨论的某种方法安排定期重配置。这类似于“准实时”生产——装配线上需要某些零件时,那些零件就刚好出现在生产车间。同样地,Oracle DBA可预测处理需求,并确保及时提供SGA资源,以满足处理任务之需要。

可用STATSPACK来跟踪重要度量指标,并揭示出访问模式,以预测Oracle服务器即将需要的资源。度量指标通常根据一天中的不同小时以及一周中的不同天来收集,以便发现其中的访问模式。以图A每天各个小时的数据缓冲命中率(BHR)为例。

  

图A

这幅BHR图表明缓冲区块反复出现短缺现象,注意重复出现的指标表明,数据缓冲区块在2:00到3:00 AM之间出现短缺,同样的情况在8:00到9:00 PM之间再次出现。了解这一点后,就可安排任务,在这些时段为数据缓冲重新分配RAM,以缓解问题。

还可以绘制一周中每一在的数据BHR图,如图B所示。从中可以看出,有问题的是周一和周五。所以,这两天需要增大db_cache_size来纠正问题。