数据库自我调整介绍

　一、 自我调整检查点

　　在以前的文章中，笔者谈到过，Oracle数据库中有存储缓 冲区，其包括三部分内容，一种叫做脏缓冲存储区。这个缓冲存储区中存储的是已经被修改的数据。一般情况下，这个数据不会马上被写入到数据文件中去。除非空 闲缓冲快用完了，这个数据才会被写入数据文件。但是，如此的话，也会遇到一个问题，若空闲缓冲区刚用完的时候，其他用户也在频繁的对数据库进行读写操作， 在这个繁忙的时刻，再往数据库文件中写入更改后的数据，那么，很明显，会极大的影响数据库的性能。

　　所以，作为数据库管理员，我们的设想是能否在I/Q操作比较空的时候，就把脏缓冲中的数据写入到数据库中去呢?这若是靠数据库管理员手工管理肯 定不现实，我们数据库有这个自动判断的功能。甲骨文好像听到了我们众多数据库管理员的呼声，在10G版本的数据库中新增了这个功能，并在11G版本中进行 了完善，这就是自我调整检查点的自我调整功能。

　　检查点是将内存中修改的数据与数据库中的数据文件同步的手段。Oracle数据库定期将检查点之间修改的数据写入数据文件，这种做法的要求之一是需要服务器有足够的可用内存，以提高为即将进行的操作寻找空闲内存的执行性能。

　　所以，这个检查点的设置，跟很多参数有关，如服务器的内存等等。虽然在以前的版本中，数据库管理员可以通过设置相关的初始化参数，来指定预期的 崩溃恢复时间。但是，实际上，由于这个设置复杂，影响因素众多，所以，很少有数据库管理员会去调整这个参数，而都是采用其默认的设置。

　　笔者在使用Oracle 11G数据库中，印象最深的是数据库可以自我调整检查点。虽然在10G中也已经提出了这个功能，但是用的总是不怎么顺心。在11G中作了一定的改善，从而 使得这个新功能得到了大家的认同。使用数据库的自动检查点调整，数据库就会自动判断数据库的繁忙程度，具体的说是判断I/Q 操作的繁忙程度，数据库会自动在其比较空闲的时候，把脏缓冲期中的内容写入到数据文件中，从而降低对数据库吞吐量所产生的影响，提高数据库的操作性能。

　　其实，这个检查点的自我调整功能就好像是一个交通警察，当道路繁忙的时候，下班高峰期时，一些打扫卫生的清洁车就不能进入车道;只有到道路比较空闲的时候，清洁车才能进入车道打扫卫生。从而把清洁车对于车道的正常运行的影响降低到最低。

　　当然，这个改善可能用户一下子还察觉不出来。但是，我们通过数据库日志进行前后的对比，就会发现，两者的差异是很大的。利用了数据库检查点自我调整功能后，数据库的查询性能，特别是查询大量数据的性能，得到了比较显著的改善。

　　不过，话说回来，数据库的自我调整功能虽然是一个不错的“交通警察”，但是当车真的很多的时候，最好的“交通警察”，也是无能为力。此时，就需 要对硬件上的改善，如增加服务器的内存等等。毕竟像数据检查点等自我调整功能只能够改善硬件的利用能力，而不能从本质上提升硬件的容量。

　　二、 自我调整系统全局区

　　SGA是一个英文简称，中文的意思是系统全局区。它是一个存储区域，被所有用户所共享。系统全局区内就像是一个个格子，每个格子就是一个存储组 件，用来存放为满足每类内存分配需求而使用的内存池。例如用户最近查询过的数据块就会被保存在其中的一个格子里;数据库的结构等变化需求等也会被存储在这 些格子中。

　　现在就遇到一个问题，格子大小的问题。若格子太大，整个格子只装了不到三分之一的内容，那么明显是一种浪费，这些空间本来是可以被用作其他用途的;若格子太小，信息存放不下去了，就又会发生内存分配错误。

　　如果数据库管理员自己来调整这些格子的大小，那么难度也是可想而知的。因为这些空间的需求量是不确定的，随着业务的不同，其需要的容量也随之改 变。所以，数据库管理员希望数据库能够对系统全局区进行动态分配，能够让数据库根据实际的需要量，划分这些格子的存储空间。当然有个前提，就是其不超出总 的容量大小。

　　在Oracle 10G与11G的数据库系统中，增加并完善了这方面的功能，实现了对于系统全局区的动态分配功能。也就是说，我们数据库管理员，只需要制定一个系统全局区 的总大小，然后，里面的格子怎么分，就不需要我们关心了。Oracle数据库会自己根据里面居住的客人数量的多少，进行分配。Oracle数据库会担负起 在整个系统全局区内部进行优化内存分配对一个重任。数据库有了这个改进之后，这些房间的大小就不是固定的，而是会随着业务量的不同而实现动态的梗概。如此 的话，一方面，房间的空间不会被浪费，不会一个房间很挤而其他房间很空;另一方面，也不会因为存储信息的时候因为空间不够而发生内存存储错误。

　　通过这个自我调整系统全局区的功能，Oracle数据库会智能地对数据库服务器的内存进行合理的分配，提高内存的使用效率，提高数据库的性能。

　　不过，这两项功能，都提供了自定义的功能，如可以自己定义系统全局区的总大小以及检查点的恢复时间等等。虽然定义起来比较简单，但是，有个问题就是定义多大才使合理的呢?这个很难确定。因为这根据企业应用不同而有所区别，没有什么可以参考的标准。一般情况下，数据库管理员可能需要观测数据库性能达一年以上，才能够取得一个合理的值。所以，笔者的建议是，刚开始的时候，就采取默认的设置。让数据库自己根据服务器的硬件配置，去取得合理的参数。在以后若有必要的时候，再根据相关的信息，去设置一个合理的值。