就我看，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/oratabgrep ^$ORACLE_SID:cut -f2 -d':'` #ORACLE_HOME=`cat /var/opt/oracle/oratabgrep ^$ORACLE_SID:cut -f2 -d':'` export ORACLE_HOME PATH=$ORACLE_HOME/bin:$PATH export PATH $ORACLE_HOME/bin/sqlplus –s /nologin
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来纠正问题。
图B
日BHR图揭示出较长周期内产生的问题
基于趋势的信息对于Oracle DBA来说是一个大有潜力可挖的金矿，因为可用它揭示出Oracle数据库中以前看不见的性能趋势。我的下一篇文章将更研究聪明的Oracle专家喜欢使用的一些重要指标，可根据它们确定如何动态调节Oracle9i数据库。
