作为一名合格的Oracle数据库管理员密切关注有可能会对他们所管理的每个系统可用性或是性能具有不良影响的Oracle数据库的一些相关问题。在一般的情况下，我们就可以把数据库管理员监视、维护系统的方式分为两种，分别为反应性监视与前瞻性监视。

如上图所示，反应性监视是指在已经出现一个性能或者管理问题后再对数据库进行监视。例如有员工向Oracle数据库管理员反应应用系统的速度比较慢。数据库管员跟其他技术人员共同会诊后发现是由于数据库的原因所造成的。

此时数据库管理员就需要使用相关的工具来收集数据库的运行数据，以查明问题发生的原因。虽然这最终也可以顺利把问题解决，但是这毕竟与优秀数据库管理员心中的期望还有一点距离。因此反应性监视有点像放马后炮的感觉。问题已经出现，即使数据库管理员能够在最短时间内查明原因、解决问题，但是毕竟对于用户产生了一些不利的影响。

故数据库管理员希望能够在故障发生之前就能够了解导致这个故障发生的原因，并及时采取有效措施预防这种故障的最终发生。这就使数据库管理员所期待的前瞻性监视。

前瞻性监视可以让数据库管理员在问题出现之前、期间或者之后查处并响应Oracle数据库常见的性能与管理问题。简单的说，在某一个数据库故障发生之前，都会有一些征兆。这就好像一些自然灾害发生时，像蚂蚁、燕子等等都会有一些异常的反应。数据库管理员有必要了解这些征兆。如此的话，我们才能够把这些问题消除来萌芽状态，防止问题的扩大。

Oracle数据库设计者们也一直在往这个方向努力。如在10G以后的数据库版本中，就有了一个自动工作负荷储存库的功能，来帮助数据库管理员收集在数据库运行中的异常数据。通过这些数据的帮助，数据库管理员可以抢在Oracle数据库故障发生之前把问题解决了。

自动工作负荷存储库的特点

自动工作负荷存储库主要是通过两个回退进程实现的，分别为内存监视器与内存监视灯。这两个进程是一对双胞胎数据，他们可以给数据库管理员带来很大的帮助。如这两个进程会相互合作，从数据库系统全局区中直接收集性能统计数据。如数据库服务器CPU内存的使用率等等。其中内存监视器在其中担任主要角色。默认情况下，内存监视器每个小时会启动一次，并从数据动态性能视图、数据库目录视图和数据库优化器中收集性能等相关的统计信息，然后会把这些信息存储在Oracle数据库的表中。这个表就叫做自动工作负荷存储库表。通常情况下，这个表被Sysman用户所拥有，并被存储在Sysaux表空间中。

启用自动工作负荷存储库并进行相关的配置

如果数据库管理员需要启用这个自动工作负荷存储库功能，则需要手工对此启动。默认情况下数据库是不会启动这项功能的。笔者的意见是，在数据库设计或者测试的时候，不用启动这项功能。毕竟其本身需要耗用服务器一定的资源。但是在生产服务器(即企业已经在使用的Oracle数据库)系统中，***启用这项功能。

以帮助数据库管理员自动收集数据库的运行性能信息，以实现前瞻性监视的目标。

如果想要启用自动工作负荷存储库功能，则需要配置数据库中的Statistics_level这个参数。这个参数主要有三个值，用来决定内存监视器进程收集统计数据的深度与频率等等。如数据库的规模比较小或者应用时间不长的话，可以把这个参数设置为Basic。

在这个参数下，数据库虽然已经启用了自动工作负荷存储库，但是会禁用这项功能的大多数争端监视以及顾问活动。也就是说，此时数据库管理员启动数据库实例时，系统只会收集少量的数据库运行时的统计数据。当数据库规模比较大时这些数据往往不能够帮助Oracle数据库管理员排查故障发生的原因。

如果数据库设计比较复杂或者企业对于数据库的性能要求比较高，则此时数据库管理员可以把这个参数设置为ALL，这是自动工作负荷存储库收集统计数据的***级别。在这个级别下，内存监视器将会捕获大部分的统计数据，同时还会收集来自操作系统的执行计划和定时信息。

如Oracle数据库的自动备份有时候需要操作系统的任务计划的帮助下才能够完成。那么此时数据库管理员就需要考虑数据库性能下降的原因是否跟这个操作系统的任务计划有关。此时内存监视器收集起来的跟操作系统相关的计划与定时信息就会非常的有用。不过有时候数据库管理员可能只需要收集数据库自深的运行信息，而不需要操作系统的相关信息。

此时就可以把这个参数设置为Typical。这个参数是自动工作负荷存储库的标准级别，他会收集跟数据库自深相关的统计信息。

数据库管理员可以根据企业对数据库性能的要求、可以允许数据库当机的时间、服务器的配置等因素来考虑要选择的级别。通常情况下，如果在同一个服务器中，除了Oracle数据库外还部署了其他应用服务的话，那么笔者建议***采用All级别。此时Oracle数据库管理员可以知道尽可能多的信息，帮助管理员及早把问题消除掉。