分类： Oracle
2008-08-02 21:19:20
一、自我调整检查点
在以前的文章中，笔者谈到过，Oracle数据库中有存储缓冲区，其包括三部分内容，一种叫做脏缓冲存储区。这个缓冲存储区中存储的是已经被修改的数据。一般情况下，这个数据不会马上被写入到数据文件中去。除非空闲缓冲快用完了，这个数据才会被写入数据文件。但是，如此的话，也会遇到一个问题，若空闲缓冲区刚用完的时候，其他用户也在频繁的对数据库进行读写操作，在这个繁忙的时刻，再往数据库文件中写入更改后的数据，那么，很明显，会极大的影响数据库的性能。
所以，作为数据库管理员，我们的设想是能否在I/Q操作比较空的时候，就把脏缓冲中的数据写入到数据库中去呢?这若是靠数据库管理员手工管理肯定不现实，我们数据库有这个自动判断的功能。甲骨文好像听到了我们众多数据库管理员的呼声，在10G版本的数据库中新增了这个功能，并在11G版本中进行了完善，这就是自我调整检查点的自我调整功能。
检查点是将内存中修改的数据与数据库中的数据文件同步的手段。Oracle数据库定期将检查点之间修改的数据写入数据文件，这种做法的要求之一是需要服务器有足够的可用内存，以提高为即将进行的操作寻找空闲内存的执行性能。
所以，这个检查点的设置，跟很多参数有关，如服务器的内存等等。虽然在以前的版本中，数据库管理员可以通过设置相关的初始化参数，来指定预期的崩溃恢复时间。但是，实际上，由于这个设置复杂，影响因素众多，所以，很少有数据库管理员会去调整这个参数，而都是采用其默认的设置。
笔者在使用Oracle11G数据库中，印象最深的是数据库可以自我调整检查点。虽然在10G中也已经提出了这个功能，但是用的总是不怎么顺心。在11G中作了一定的改善，从而使得这个新功能得到了大家的认同。使用数据库的自动检查点调整，数据库就会自动判断数据库的繁忙程度，具体的说是判断I/Q操作的繁忙程度，数据库会自动在其比较空闲的时候，把脏缓冲期中的内容写入到数据文件中，从而降低对数据库吞吐量所产生的影响，提高数据库的操作性能。
其实，这个检查点的自我调整功能就好像是一个交通****，当道路繁忙的时候，下班高峰期时，一些打扫卫生的清洁车就不能进入车道;只有到道路比较空闲的时候，清洁车才能进入车道打扫卫生。从而把清洁车对于车道的正常运行的影响降低到最低。
当然，这个改善可能用户一下子还察觉不出来。但是，我们通过数据库日志进行前后的对比，就会发现，两者的差异是很大的。利用了数据库检查点自我调整功能后，数据库的查询性能，特别是查询大量数据的性能，得到了比较显著的改善。
不过，话说回来，数据库的自我调整功能虽然是一个不错的“交通****”，但是当车真的很多的时候，最好的“交通****”，也是无能为力。此时，就需要对硬件上的改善，如增加服务器的内存等等。毕竟像数据检查点等自我调整功能只能够改善硬件的利用能力，而不能从本质上提升硬件的容量。
二、自我调整系统全局区
SGA是一个英文简称，中文的意思是系统全局区。它是一个存储区域，被所有用户所共享。系统全局区内就像是一个个格子，每个格子就是一个存储组件，用来存放为满足每类内存分配需求而使用的内存池。例如用户最近查询过的数据块就会被保存在其中的一个格子里;数据库的结构等变化需求等也会被存储在这些格子中。
现在就遇到一个问题，格子大小的问题。若格子太大，整个格子只装了不到三分之一的内容，那么明显是一种浪费，这些空间本来是可以被用作其他用途的;若格子太小，信息存放不下去了，就又会发生内存分配错误。
如果数据库管理员自己来调整这些格子的大小，那么难度也是可想而知的。因为这些空间的需求量是不确定的，随着业务的不同，其需要的容量也随之改变。所以，数据库管理员希望数据库能够对系统全局区进行动态分配，能够让数据库根据实际的需要量，划分这些格子的存储空间。当然有个前提，就是其不超出总的容量大小。
在Oracle10G与11G的数据库系统中，增加并完善了这方面的功能，实现了对于系统全局区的动态分配功能。也就是说，我们数据库管理员，只需要制定一个系统全局区的总大小，然后，里面的格子怎么分，就不需要我们关心了。Oracle数据库会自己根据里面居住的客人数量的多少，进行分配。Oracle数据库会担负起在整个系统全局区内部进行优化内存分配对一个重任。数据库有了这个改进之后，这些房间的大小就不是固定的，而是会随着业务量的不同而实现动态的梗概。如此的话，一方面，房间的空间不会被浪费，不会一个房间很挤而其他房间很空;另一方面，也不会因为存储信息的时候因为空间不够而发生内存存储错误。
通过这个自我调整系统全局区的功能，Oracle数据库会智能地对数据库服务器的内存进行合理的分配，提高内存的使用效率，提高数据库的性能。
不过，这两项功能，都提供了自定义的功能，如可以自己定义系统全局区的总大小以及检查点的恢复时间等等。虽然定义起来比较简单，但是，有个问题就是定义多大才使合理的呢?这个很难确定。因为这根据企业应用不同而有所区别，没有什么可以参考的标准。一般情况下，数据库管理员可能需要观测数据库性能达一年以上，才能够取得一个合理的值。所以，笔者的建议是，刚开始的时候，就采取默认的设置。让数据库自己根据服务器的硬件配置，去取得合理的参数。在以后若有必要的时候，再根据相关的信息，去设置一个合理的值。
