Oracle9i Database 自调整:Oracle SGA(上)

发表于:2007-06-22来源:作者:点击数: 标签:
随着 数据库 管理员在自调整工作方面变得更加成熟,许多 Oracle 规格可能变为自调整。在 Oracle Database 10g 中,我们将看到比以前更多的自调整功能。 例如,Oracle Database 10g 的动态内存分配特性使得创建一个自调整的 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)。
  
  
 Oracle9i Database 自调整:Oracle SGA(上)(图一)

  使用 alter system 命令,我们可以在数据缓冲区之间调整 RAM,以将 RAM 重新分配给最需要的地方(参见图 2)。
  
Oracle9i Database 自调整:Oracle SGA(上)(图二)

  您可以在很多种 Oracle 脚本(包括动态 SQL、dbms_job 和 shell 脚本)中使用 alter system 命令。列表 2 是调整 RAM 缓存大小的一个简单的 SQL*Plus 脚本;这个脚本向您提示缓存的名称和大小,并发出适当的 alter system 命令来调整 RAM 区域的大小。下面是输出的内容:
  
  SQL> @dyn_sga
  
  Enter cache to decrease:shared_pool_size
  Enter cache to increase:db_cache_size
  Enter amount to change: 1048576
  
  alter system set shared_pool_size = 49283072;
  System altered.
  
  alter system set db_cache_size = 17825792;
  
  System altered.
  
  现在我们看到了在 Oracle Database 10g 中,如何轻易地改变 RAM 区域,下面让我们研究一下调用 RAM 区域自动调整的一些规则。
  
  何时触发动态重配置
  无论何时当监控脚本的例程指示有一个负担过重的 RAM 区域时,您必须选择从哪一个区域中“窃取”内存。表 1 显示了阈值条件的一个简单的示例,该阈值条件触发 SGA 的三个主要区域的动态内存修改。当然,每个系统都各不相同,您将要根据您的需求来调整这些阈值。例如,许多商店实施了多个 blocksize,并分离了 db_32k_cache_size (用于索引表空间)、db_keep_cache_size(用于小型、引用频繁的对象)等的 RAM 区域。
  
  记住数据库的需求将根据正在执行的 SQL 不断变化是很重要的;在 9:00am 最优的一个 SGA 可能在 3:00pm 就不是最优了。为了了解处理特性的变化,您可以运行 Statspack 报表来查明 Oracle 改变 RAM 存储需求的那些时间。您还可以运行 v$db_cache_advice、v$pga_target_advice、v$java_pool_advice 和 v$db_shared_pool_advice 实用程序来查看 RAM 区域大小的变化带来的边际效益。
  
  一种使动态 SGA 重新配置自动化的流行的方法是识别趋势。您可以使用 Statspack 来预测那些处理特性变化的时间,并使用 dbms_job 程序包或动态 SQL 来执行特定的 SGA 修改。让我们详细了解一下基于趋势的方法。
  
  显示系统信号图
  基于趋势的重新配置的一种常见的方法是使用 Statspack 历史数据来显示可预测的趋势,并根据信号图用这些趋势来修改数据库。
  
  这种方法与零库存生产很相似,其中零部件正好在需要组装时才出现在工厂车间里。Oracle Database 10g 使 DBA 能够预见处理需求并定期地安排适当的干预操作,从而确保为处理需求的变化即时地提供 SGA 资源。
  
  自调整 Oracle 的内存区域涉及到改变几个 Oracle 参数的值。虽然存在 250 多个 Oracle Database 10g 参数来管理数据库的各方面配置,但只有少数几个参数对自动的 Oracle SGA 调整很重要:
  
  db_cache_size — db_cache_size 确定 Oracle SGA 中的数据库块缓冲的数量,并且代表着 Oracle 内存最重要的一个参数。
  
  db_keep_cache_size — 这个数据缓冲池是 Oracle8i 中 db_block_buffers 的一个子缓冲池,但从 Oracle9i Database 开始成为一个单独的 RAM 区域。
  
  db_nn_cache_size — Oracle Database 10g 有单独的数据缓冲池,您可以使用这些数据缓冲池来分离数据并分离具有不同 I/O 特性的对象。
  
  shared_pool_size — shared_pool_size 定义系统中由所有用户共享的池,包括 SQL 区域和数据字典缓存。
  
  pga_aggregate_target — pga_aggregate_target 定义为系统范围的排序和散列连接保留的 RAM 区域。
  
  您可以看到,甚至不需要对您的 Oracle 数据库状况的最重要的量度进行归零校正。让我们从检查库缓存中的趋势开始,并确定如何自动调整 shared_pool_size。
  
  使用 Oracle Database 10g 顾问实用程序
  Oracle Database 10g 拥有完整的顾问实用程序,它们将准确地预测改变任意的 RAM 区域大小将带来的变化。Oracle Database 10g 中的顾问实用程序包括:
  
  共享池建议 — v$shared_pool_advice
  PGA 目标建议 — v$pga_target_advice
  数据缓存建议 — v$db_cache_advice
  Java 池建议 — v$java_pool_advice
  
  这些实用程序是确保自调整变化正确合理的一种极好的方式。以下内容将显示如何调用和解释这些顾问实用程序;当您能够轻松地解释它们的输出时,您就可以编写自动化的脚本来生成建议、解释输出,并自动改变 RAM 区域的大小。
  
  共享池建议实用程序
  这一顾问功能在 Oracle9i Database Release 2 中得到了扩展,包含了一个称为 v$shared_pool_advice 的新的建议实用程序,在将来的版本中它可能最终将被扩展至所有的 SGA RAM。
  
  从 Oracle9i Database Release 2 开始,当共享池的大小从当前值的 10% 变为当前值的 200% 时,v$shared_pool_advice 视图将显示 SQL 分析的边际差异。
  
  共享池建议实用程序非常易于配置:安装后,您可以运行一个简单的脚本来查询 v$shared_pool_advice 视图,并查看不同 shared_pool 大小的 SQL 分析的边际变化。以下脚本的输出将告诉您动态增加或减少 shared_pool_size 参数带来的变化。
  
  -- ************************************************
  -- Display shared pool advice
  -- ************************************************

原文转自:http://www.ltesting.net