Oracle数据库维护中的前瞻性。

   数据库管理员必须自始自终都密切关注可能会对他们所管理的各个系统的可用性或者性能有负面影响的潜在数据库问题。通常情况下，可以把数据库管理员监视、维护系统的方式分为两种，分别为反应性监视与前瞻性监视。

    如上图所示，反应性监视是指在已经出现一个性能或者管理问题后再对数据库进行监视。例如有员工向数据库管理员反应应用系统的速度比较慢。数据库管员跟其他技术人员共同会诊后发现是由于数据库的原因所造成的。此时数据库管理员就需要使用相关的工具来收集数据库的运行数据，以查明问题发生的原因。虽然这最终也可以顺利把问题解决，但是这毕竟与优秀数据库管理员心中的期望还有一点距离。因此反应性监视有点像放马后炮的感觉。问题已经出现，即使数据库管理员能够在最短时间内查明原因、解决问题，但是毕竟对于用户产生了一些不利的影响。故数据库管理员希望能够在故障发生之前就能够了解导致这个故障发生的原因，并及时采取有效措施预防这种故障的最终发生。这就使数据库管理员所期待的前瞻性监视。

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

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

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

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

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

    如果数据库管理员需要启用这个自动工作负荷存储库功能，则需要手工对此启动。默认情况下数据库是不会启动这项功能的。笔者的意见是，在数据库设计或者测试的时候，不用启动这项功能。毕竟其本身需要耗用服务器一定的资源。但是在生产服务器(即企业已经在使用的Oracle数据库)系统中，最好启用这项功能。以帮助数据库管理员自动收集数据库的运行性能信息，以实现前瞻性监视的目标。

    如果想要启用自动工作负荷存储库功能，则需要配置数据库中的Statistics_level这个参数。这个参数主要有三个值，用来决定内存监视器进程收集统计数据的深度与频率等等。如数据库的规模比较小或者应用时间不长的话，可以把这个参数设置为Basic。在这个参数下，数据库虽然已经启用了自动工作负荷存储库，但是会禁用这项功能的大多数争端监视以及顾问活动。也就是说，此时数据库管理员启动数据库实例时，系统只会收集少量的数据库运行时的统计数据。当数据库规模比较大时这些数据往往不能够帮助数据库管理员排查故障发生的原因。如果数据库设计比较复杂或者企业对于数据库的性能要求比较高，则此时数据库管理员可以把这个参数设置为ALL，这是自动工作负荷存储库收集统计数据的最高级别。在这个级别下，内存监视器将会捕获大部分的统计数据，同时还会收集来自操作系统的执行计划和定时信息。如Oracle数据库的自动备份有时候需要操作系统的任务计划的帮助下才能够完成。那么此时数据库管理员就需要考虑数据库性能下降的原因是否跟这个操作系统的任务计划有关。此时内存监视器收集起来的跟操作系统相关的计划与定时信息就会非常的有用。不过有时候数据库管理员可能只需要收集数据库自深的运行信息，而不需要操作系统的相关信息。此时就可以把这个参数设置为Typical。这个参数是自动工作负荷存储库的标准级别，他会收集跟数据库自深相关的统计信息。

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

    三、配置合适的时间参数。

    在启用自动工作负荷存储库之后，数据库管理员还需要考虑一些时间上的分配问题。如这个自动负荷存储库表中的数据需要保存多久。由于数据库运行统计信息的数量，随着其级别的不同，数据量有多少。但是只要采用了Typical或者All这两个级别后，其信息量还是很可观的。故如果不定时清除这些数据的话，则这个表没有多少时间就会占用很大的空间了。为此这个表必须循环利用，以减少存储空间。默认情况下，自动负荷存储表中的内容只会被保存七天，也就是说这个表中存储的是最近七天的数据库运行信息。但是如果数据库环境设计比较复杂可能会产生大量的统计信息，则此时数据库管理员就需要缩短这个时间。而有时候某些异常数据可能会周期性的出现，故数据库管理员需要了解几个周期之内的数据，此时就需要延长这个循坏周期。为此数据库管理员要能够更改这个周期，以方便其工作。如果数据库管理员需要跟该这个周期的话，那么就需要执行Dbms_Workload_Reposttory程序，设置其中的retention参数。注意这里是用分钟为单位。如果数据库管理员想要把这个时间设置为10天的话，则就需要把这个参数设置为60*24*10=14400分钟。注意这里是以分钟为单位。如果数据库管理员不知道这个内容或者误以为这里是以天为单位的，而把这个参数设置为10的话，那么这个工作负荷存储库表中就不会记录有价值的信息。

    另外，默认情况下工作负荷存储库的内存监视器是每60分钟收集一下信息。不过有时候数据库管理员可能需要根据实际情况来缩短这个统计的周期或者严惩周期。如为了测试的需要要把这个周期缩短为10分钟以判断是否正常启用了自动工作负荷存储库时，就需要把这个周期缩短。此时也是采用如上那个程序，不过参数是interval了。如果要把这个时间调整为30分钟，则只需要把这个参数设置为30即可。注意此时这里是以分钟为单位。如果此时数据库管理员要让这个工作负荷存储库表保留10天的纪录，同时每隔30分钟统计数据库运行的信息，就可以执行以下的命令来完成：Execute Dbms_Workload_Reposttory.modify_snapshot_settings(interval=30,retention=14400)。即可以完成如上的需求。笔者再次强调一下，这个命令中都是以分钟为单位的。另外，如果同时缩短统计周期并延长工作负荷存储库表的存储周期，那么在这两个因素的共同作用下，这个表的容量会很快的膨胀起来。数据库管理员需要注意这个问题。通常情况下，笔者建议可以缩短这个统计周期，但是不建议延长表的存储周期。如果数据库管理员确实需要一段时期内的性能数据的话，则可以先把这个表导出来进行备份。这可以避免工作负荷存储表对数据库表空间的侵蚀。再者，缩短内存监视器收集系统统计数据周期会增加数据库的额外开销，这也是数据库管理员在调整这两个参数时需要注意到的内容。