Oracle9iDatabase自调整.doc

Oracle9i Database 自调整:Oracle SGA（上） 随着数据库治理员在自调整工作方面变得更加成熟，许多 Oracle 规格可能变为自调整。在 Oracle Database 10g 中，我们将看到比以前更多的自调整功能。　　　　例如，Oracle Database 10g 的动态内存分配特性使得创建一个自调整的 Oracle SGA 成为可能。通过演示，在本文中我将说明如何检查 Oracle 9i Database 中的 Oracle 例程，以及根据服务器上和数据库内的处理需求来调整 sort_area_size 或 pga_aggregate_target、large_pool_size、sga_max_size 和 db_cache_size 的内存区域。这里讨论的技巧的基础是使用 Statspack 来随时监控内存区域并显示系统资源利用率的信号图。 软件开发网 　　　　我还将讨论如何创建一种智能机制，以根据当前的处理需求来自动地重新配置 Oracle9i Database，并提供了示例代码，这些示例代码将使您能够开始编写自己的能够有效地仿效 Oracle Database 10g 功能的自动化脚本；例如，我将提供一个脚本，它将自动识别小型、常用的程序段，并将它们分配给 KEEP 池，以全部进行缓存。（重要注重事项：这种仿效仅考虑外部的行为，但不反映新版本的内部实施。）因为每个数据库都各不相同，所以为了清楚起见，这些脚本特意进行了省略和简化。因此，您将需要扩展这些示例并编写适合您的环境的自定义的自动化脚本。　　　　具有以下特性的商店将从自动化的自调整中最大程度的获益：　　　　双模式系统 — 在在线事务处理 (OLTP) 和数据仓库处理模式之间转换的系统尤其将从自调整 RAM 区域中获益。　　　　32 位的商店 — 运行 32 位服务器的商店受其 RAM 区域大小（最大约为 1.7GB）的限制。对于这些商店，最有效地使用 RAM 资源尤为重要。　　 　　记住拥有一个非常大的 db_cache_size 的趋势正在下降也很重要。虽然对数据的直接访问是利用散列法来完成的，但有时数据库必须检查 RAM 缓存中的所有内存块：　　　　高失效率的系统 — 无论何时当程序产生一个截断表、使用临时表或运行一次大型的数据清除时，Oracle 必须清除 db_cache_size 中的所有内存块，以除去已被使用的内存块。对于拥有大于 10gB 的 db_cache_size 的系统，这种方法可能造成过多的开销。　　　　更新率高的系统 — 当执行一次异步写操作时，数据库写入器 (DBWR) 过程必须清除 db_cache_size 中的所有内存块。拥有一个巨大的 db_cache_size 可能给数据库写入器造成过重的负担。　　　　首先，让我们回顾一下创建自调整数据库背后的准则。　　　　自调整背后的准则　　重新配置一个 Oracle 例程的最常用的技巧是使用一个脚本，并通过 dbms_job 或一个外部调度程序（如 UNIX cron）来调用这个脚本。为了说明一个简单的例子，考虑一个白天在 OLTP 模式下运行，而晚上在数据仓库模式下运行的数据库。对于这种类型的数据库，您可以安排一项作业来将例程 SGA 内存重新配置成最适合于在该 Oracle 例程中执行的处理类型的配置。 　　　　列表 1 包含一个 UNIX 脚本，该脚本用来重新配置 Oracle，以便进行决策支持处理。注重为了适应数据仓库行为，对 shared_pool、db_cache_size 和 pga_aggregate_target 中的配置作了重要的修改。该脚本被安排在每晚 6:00pm 通过 dbms_job 来调用。　　　　在列表 1 中，我们看到了建立了自调整 Oracle Database 10g 的基础的 alter system 命令。记住 RAM 是一种昂贵的 Oracle 服务器资源，DBA 有责任在服务器上充分地分配 RAM 资源。未得到利用的 RAM 将浪费昂贵的硬件资源。 即使得到了充分的分配，分配过度的 RAM 也是一种浪费。例如，当您只需要 200m 时，分配一个 shared_pool_size=400m 是效率低下的，因为 RAM 可以被 SGA 的另一个区域（如 db_cache_size）使用。　　　　为了说明 RAM 重新配置的概念，考虑下面这个例子，一个分配不足且数据缓冲命中率很低的 16K 数据缓冲区，和一个分配过度且数据缓冲命中率很高的 32K 数据缓冲区（参见图 1）。　　　　 　 　　使用 alter system 命令，我们可以在数据缓冲区