Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles
New Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

Oracle Technology Network

动调整 Oracle9i DatabaseOracle SGA

作者:Donald K. Burleson
2001 年以来的 OTN

与以往相比,Oracle Database 10g 使得数据库管理员更多的日常任务变得自动化。这里说明的 Oracle9i Database 自管理技巧仿效了新版本的一些功能。

本文附带的示例代码(列表 1-7

随着数据库管理员在自调整工作方面变得更加成熟,许多 Oracle 规格可能变为自调整。在 Oracle Database 10g 中,我们将看到比以前更多的自调整功能。

例如,Oracle Database 10g 动态内存分配特性使得创建一个自调整的 Oracle SGA 为可能。通过演示,在本文中我将说明如何检查 Oracle 9i Database 中的 Oracle 例程,以及根据服务器上和数据库内的处理需求来调整 sort_area_size pga_aggregate_targetlarge_pool_sizesga_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_pooldb_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)。

分配过度和分配不足的 RAM 区域

1:分配过度和分配不足的 RAM 区域

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

Oracle10g 中动态重分配 RAM

2RAM 动态重分配

您可以在很多 Oracle 脚本(包括动态 SQLdbms_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_advicev$pga_target_advicev$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
-- ************************************************
 
set lines  100
set pages  999
 
column  c1      heading 'Pool |Size(M)'
column  c2      heading 'Size|Factor'
column  c3      heading 'Est|LC(M)  '
column  c4      heading 'Est LC|Mem. Obj.'
 
column  c5      heading 'Est|Time|Saved|(sec)'
column  c6      heading 'Est|Parse|Saved|Factor'
column  c7      heading 'Est|Object Hits'   format 999,999,999
 
 
SELECT
   shared_pool_size_for_estimate      c1,
   shared_pool_size_factor            c2,
   estd_lc_size                c3,
   estd_lc_memory_objects             c4,
   estd_lc_time_saved          c5,
   estd_lc_time_saved_factor   c6,
   estd_lc_memory_object_hits  c7
FROM 
   v$shared_pool_advice;
 
                                                   Est        Est
                                                  Time      Parse
     Pool        Size        Est     Est LC      Saved      Saved          Est
   Size(M)     Factor    LC(M)    Mem. Obj.      (sec)     Factor  Object Hits
---------- ---------- ---------- ---------- ---------- ---------- ------------
        48         .5         48      20839    1459645          1  135,756,032
 
        64      .6667         63      28140    1459645          1  135,756,101
        80      .8333         78      35447    1459645          1  135,756,149
        96          1         93      43028    1459645          1  135,756,253
       112     1.1667        100      46755    1459646          1  135,756,842
       128     1.3333        100      46755    1459646          1  135,756,842
       144        1.5        100      46755    1459646          1  135,756,842
       160     1.6667        100      46755    1459646          1  135,756,842
       176     1.8333        100      46755    1459646          1  135,756,842
       192          2        100      46755    1459646          1  135,756,842

下面我们看一下共享池在当前大小的 50% 到当前大小的 200% 变化范围内的统计数字。这些统计数字可以使您很好地了解 shared_pool_size 的真正大小。如果您使用自动化的 alter system 命令来自动调整 SGA 区域的大小,那么创建这种输出并编写一个程序来解释结果是确保共享池和库缓存始终有足够的 RAM 的一种极好的方式。接下来,让我们看看我们如何能够随时跟踪共享池的使用并显示"信号",从而允许我们预测那些需要共享池调整的时间。

们可以使用 Statspack 创建一个列表来显示那些库缓存丢失率低于指定水平的时间,如列表 3 中所示。以下输出显示,在每天上午 9:00 10:00 间共享池重复出现 RAM 不足。

 
 
                        Cache   Misses    Library Cache
Yr. Mo Dy  Hr.  execs   While Executing   Miss Ratio
 
--------------- ------- --------------- -------------
2001-12-11 10    10,338          6,443        .64
2001-12-12 10   182,477         88,136        .43
2001-12-14 10   190,707        101,832        .56
2001-12-16 10    72,803         45,932        .62
 

这个例子中,DBA 需要在内存不足的时间段内为 shared_pool_size 安排额外的 RAM

显示 pga_aggregate_target 的信号

Oracle Database 10g 中的 PGA 区域非常重要,因为它控制排序操作和 SQL 散列连接的速度。当以下条件的任何一个为真时,您可能需要动态地修改 pga_aggregate_target 参数:

  • 论何时当 v$sysstat 统计的"用于一次通过的估计 PGA 内存"值超过 pga_aggregate_target 时,您需要增加 pga_aggregate_target
  • 论何时当 v$sysstat 统计的"工作区执行 多次通"值大于百分之一时,数据库就可以从额外的 RAM 内存中获益。
  • 有可能 PGA 内存分配过度,无论何时当 v$sysstat "工作区执行 "值始终测量为百分之百时,您可以考虑减少 pga_aggregate_target 值。

v$pgastat 视图提供了例程级的 PGA 使用率汇总统计和自动的内存管理器。要获得一个快速的概览,一次简单的查询可以为所有 Oracle Database 10g 连接提供一个极好的总体 PGA 使用统计表:

check_pga.sql

-- *************************************************************
-- Display detailed PGA statistics
--
-- *************************************************************
column name  format a30
column value format 999,999,999
 
 
select
   name, 
   value 
from
   v$pgastat
;

该查询的输出可能如下所示:

 
NAME                                                   VALUE     
------------------------------------------------------ ----------
aggregate PGA auto target                             736,052,224
global memory bound                                        21,200
total expected memory                                     141,144
total PGA inuse                                        22,234,736
total PGA allocated                                    55,327,872
maximum PGA allocated                                  23,970,624
total PGA used for auto workareas                         262,144
maximum PGA used for auto workareas                     7,333,032
total PGA used for manual workareas                             0
maximum PGA used for manual workareas                           0
 
estimated PGA memory for optimal                          141,395
maximum PGA memory for optimal                        500,123,520
estimated PGA memory for one-pass                         534,144
maximum PGA memory for one-pass                        52,123,520

在之前 v$pgastat 显示中,我们看到了下面这些重要的统计量:

  • 用于自动工作区的全部 PGA 这个统计量监控运行在自动内存模式下的所有连接的 RAM 使用。记住,不是所有的内部过程都被 Oracle 许使用自动内存特性。例如,Java PL/SQL 将分配 RAM 内存,而它不会计入总体的 PGA 统计。因此,您应当从分配的总体 PGA 中减去这个值,以查看连接使用的内存和 Java PL/SQL 使用的 RAM 内存。
  • 用于最/一次通过的估计 PGA 内存 这个统计量估计在最优模式下执行所有的任务连接 RAM 需求需要多少内存。记住,当 Oracle Database 10g 遇到内存不足时,DBA 调用多次通过操作来试图找到当前释放的 RAM 内存。这个统计量对于监控 Oracle Database 10g 中的 RAM 费至关重要,大多数 Oracle DBA 将把 pga_aggregate_target 增加到这个值。

Oracle Database 10g 中,您可以使用名称 v$pga_target_advice 的新的顾问实用程序。这个实用程序将显示不同大小的 pga_aggregate_target (范围从当前值的 10% 200%)在最优、一次通过和多次通过 PGA 执行中的边际变化。

列表 4 显示了使用这个新的实用程序的一个示例查询,下面是一个输出示例。这里我们看到对于当前的处理,我们已经为 pga_aggregate_target 分配了过多的内存,从这个区域取出内存并将其分配到其它地方是安全的:

 
             Estimated   Estimated
 Target(M) Cache Hit % Over-Alloc.
---------- ----------- -----------
       113          73           0
       225          81           0
       450          92           0
       675         100           0
       900         100           0
      1080         100           0
      1260         100           0 <= current size
      1440         100           0
      1620         100           0
      1800         100           0
      2700         100           0
      3600         100           0
      5400         100           0
      7200         100           0

您可以看到,您可以容易地创建自动化的方法来检测 PGA 内存不足(利用 Statspack)并编写作业来动态改变 pga_aggregate_target,以便为排序和散列连接确保最优的 RAM 使用率。

pga_aggregate_target 开发特征码

Oracle 数据库中的 PGA 区域非常重要,因为它控制排序操作以及 SQL 散列联接的速度。在以下的某一种情况出现时,您可能希望动态更改 pga_aggregate_target 参数:

  • 只要 v$sysstat 统计量 "estimated PGA memory for one-pass" 值超过 pga_aggregate_target您就希望增加 pga_aggregate_target
  • 只要 v$sysstat 统计量 "workarea executions � multipass" 值大于百分之一,数据库就可能得益于额外增加的 RAM 内存。
  • 有可能出现过量分配 PGA 内存的情况,而只要 v$sysstat "workarea executions�optimal" 值持续显示百分之百时,您可能会考虑减少 pga_aggregate_target 值。

v$pgastat 视图提供对 PGA 使用情况以及自动内存管理程序的实例级汇总统计信息。为快速获得概要信息,有个简单的查询提供了关于所有 Oracle Database 10g 连接的总体 PGA 使用情况的极佳统计信息:

check_pga.sql

-- *************************************************************
-- Display detailed PGA statistics
--
-- *************************************************************
column name  format a30
 
column value format 999,999,999
 
select
   name, 
   value 
from
   v$pgastat
;

该查询的输出可能类似于以下信息:

 
NAME                                                   VALUE     
------------------------------------------------------ ----------
aggregate PGA auto target                             736,052,224
global memory bound                                        21,200
total expected memory                                     141,144
 
total PGA inuse                                        22,234,736
total PGA allocated                                    55,327,872
maximum PGA allocated                                  23,970,624
total PGA used for auto workareas                         262,144
maximum PGA used for auto workareas                     7,333,032
total PGA used for manual workareas                             0
maximum PGA used for manual workareas                           0
estimated PGA memory for optimal                          141,395
maximum PGA memory for optimal                        500,123,520
estimated PGA memory for one-pass                         534,144
maximum PGA memory for one-pass                        52,123,520

在上面来自于 v$pgastat 显示内容中,我们看到以下重要的统计信息:

  • Total PGA used for auto workareas 该统计量监视所有以自动内存模式运行的连接的 RAM 使用情况。记住,Oracle 没有允许所有内部进程使用自动内存特性。例如,Java PL/SQL 将会分配 RAM 内存,而这将不会计算在总的 PGA 统计量中。因此,您应该从分配的总 PGA 中减去该值,以便了解由连接所使用的内存量和由 Java PL/SQL 所使用的 RAM 内存量。
  • Estimated PGA memory for optimal/one-pass 该统计量估计出以最优化模式执行所有任务连接 RAM 请求时需要多少内存。记住,当 Oracle Database 10g 遇到内存短缺情况时,DBA 调用多步操作,试图找到最近释放的 RAM 内存。在 Oracle Database 10g 中,该统计量对于监视 RAM 使用情况非常重要,大部分 Oracle DBA 会将 pga_aggregate_target 增加到此值。

Oracle Database 10g 中可以使用称为新顾问实用程序的 v$pga_target_advice该实用程序显示从当前值的 10% 200% 的不同大小的 pga_aggregate_target 的最优化、一步和多步 PGA 执行的临界差别。

列表 4 显示使用这一新的实用程序的示例查询,以下是输出的示例。在这里我们看到,已经为当前的处理超量分配了 pga_aggregate_target,可以安全地从这一区域提取 RAM 并将它分配到其他地方:

 
             Estimated   Estimated
 Target(M) Cache Hit % Over-Alloc.
 
---------- ----------- -----------
       113          73           0
       225          81           0
       450          92           0
       675         100           0
       900         100           0
      1080         100           0
      1260         100           0 <= current size
      1440         100           0
      1620         100           0
      1800         100           0
      2700         100           0
      3600         100           0
      5400         100           0
      7200         100           0
 

可以看到,您能够方便地创建自动方法来检测 PGA 内存短缺情况(使用 Statspack)并编写作业来动态更改 pga_aggregate_target,以确保为排序和散列联接进行最优化的 RAM 使用。

为数据缓冲区开发特征码

DBA 将会注意到,在实际情况中,数据缓冲区命中率 (DBHR) 变化会随着测量间隔的频率增加而增加。例如,Statspack 可能在以小时为单位的间隔时报告 DBHR 为百分之九十二,但在采样率以两分钟为间隔时,将显示很大的变化,如 3 所示。

Statspack 报告,以两分钟为间隔

为一般性原则,应该调整主机上的所有可用内存,并且应该为 db_cache_size 分配达到增益递减点的 RAM 资源。(参见 4)。在该点处增加缓冲区块不会显著提高缓冲区命中率。

分配的 Ram 资源达到增益递减点

新的 v$db_cache_advice 视图类似于 Oracle7 中推出的一个用于跟踪缓冲区命中情况的旧实用程序 x$kcbrbh;同样,x$kcbcbh 视图用于跟踪缓冲区遗漏情况。数据缓冲区命中率可以提供与 v$db_cache_advice 所提供内容相类似的数据,因此多数 Oracle 调整的专业人员可以使用这两种工具来监视其数据缓冲区的有效性。

v$db_cache_advice 实用程序已经启用,并且数据库已经运行了足够长的时间来提供有代表性的结果时,可以使用列表 5 中的脚本来执行高速缓存建议功能。使用这一脚本,您可以获得对您所有缓冲区池的高速缓存建议,包括 2k4k8k16k 32k 数据缓冲区。

该脚本的输出如下所示。注意,数值的范围从 db_cache_size 当前大小的百分之十直到当前大小的两倍。

                                Estd Phys    Estd Phys
 Cache Size (MB)      Buffers Read Factor        Reads
---------------- ------------ ----------- ------------
              30        3,802       18.70  192,317,943 <- 10% size
 
              60        7,604       12.83  131,949,536
              91       11,406        7.38   75,865,861
             121       15,208        4.97   51,111,658
             152       19,010        3.64   37,460,786
             182       22,812        2.50   25,668,196
             212       26,614        1.74   17,850,847
             243       30,416        1.33   13,720,149
             273       34,218        1.13   11,583,180
             304       38,020        1.00   10,282,475 Current Size
             334       41,822         .93    9,515,878
             364       45,624         .87    8,909,026
             395       49,426         .83    8,495,039
             424       53,228         .79    8,116,496
             456       57,030         .76    7,824,764
             486       60,832         .74    7,563,180
             517       64,634         .71    7,311,729
             547       68,436         .69    7,104,280
             577       72,238         .67    6,895,122
             608       76,040         .66    6,739,731 <- 2x size
 

4 中所标注,数据缓冲区最优化设置的位置就是附加缓冲区的临界效益开始减少的位置。当然,该优化点将在一段时间后改变,这就是为什么我们需要预先重新配置 SGA 的原因,以便于我们能够根据当前的处理需要来更改数据缓冲区的大小。

对于趋势分析,DBHR 中的变化并不重要,可以沿两个方向生成平均数据缓冲区命中率:一周中每天的平均 DBHR 和一天中每小时的平均 DBHR

记住,在数据缓冲区中变化快速地发生,有时长期的分析将会提供线索,指出数据库中的处理故障问题。几乎每个 Oracle 数据库都提供链接到常规处理计划的模式,称为特征码。

以下显示一个 Statspack DBHR 每小时平均值脚本的输出。报告基于六个月的数据收集,显示每天的平均命中率。如果在电子表格中绘制该数据,则该数据库的 DBHR 特征码变得显而易见。

 
 
hr   BHR
-- -----
00   .94
01   .96
02   .91
03   .82
04   .80
05   .90
06   .94
07   .93
08   .96
09   .95
10   .84
12   .91
13   .96
14   .95
17   .97
18   .97
19   .95
20   .95
21   .99
 
22   .93
23   .94

该数据的绘图如 5 所示,我们看到一些有趣的重复趋势。

数据的绘图

图中清楚地看到,每天上午 3:004:00 10:00DBHR 降到百分之九十以下。为解决此问题,DBA 可以安排动态的调整,每天为 db_cache_size 添加更多的 RAM

一个类似的脚本可以提供一周中每天的平均 DBHR,如列表 6 所示;脚本的输出如下。

DOW         BHR
--------- -----
sunday      .91
monday      .98
tuesday     .93
wednesday   .91
thursday    .96
friday      .89
saturday    .92
 

然后我们可以将该数据粘贴到一个电子表格中并绘制成图表,如 6 所示。

数据的图表

该报告在确定周期性或常规的缓冲区特征码时很有用,而图形清楚地显示,需要在周一和周五增加 db_cache_size。要了解原因,您可以使用 Statspack 调查一周中这几天与其他天的区别。

然后,让我们来检查另一种自调整方法,们利用这种方法自动识别对象并将其分配到 KEEP 池中,用于完全的 RAM 高速缓存。

动进行 KEEP 池分配

根据 Oracle 文档,"适合放入 KEEP 池中的段小于 DEFAULT 缓冲区池大小的 10%,并至少引发系统中总 I/O 量的 1%"很容易找到小于其数据缓冲区大小 10% 的段,但 Oracle 没有在段级跟踪 I/O 的直接机制。一种解决方案是将每个段都放置到一个单独的表空间中,在此情况下 Statspack 显示总的 I/O,但对于具有数百个段的复杂模式而言,这不是切实可行的解决方案。

由于 KEEP 的核心构思是完全高速缓存,我们希望找到那些小型并且具有不成比例的活动量的对象。利用这一原则,您可以考虑对以下情况的对象进行高速缓存:

  • 该对象消耗了数据缓冲区总大小的 10% 以上
  • 该对象的 50% 以上已经处于数据缓冲区中(根据 x$bh 查询)。

为识别这些对象,我们首先解释数据库中所有查找小型表、全表扫描的 SQL。接着,我们重复地检查数据缓冲区高速缓存,查看任何其数据块的 80% 以上位于 RAM 中的对象。

KEEP 识别表和索引的最佳方法会检查数据缓冲区中的当前块。对于此查询,其规则很简单:任何其数据块的 80% 以上处于数据缓冲区中的对象应该进行完全高速缓存。

不合适的表或索引不大可能满足这一标准。当然,您可能在一天之中需要多次运行这一脚本,因为缓冲区内容变化非常快。

可以每小时通过 dbms_job 运行列表 7 中的脚本,并自动监视 KEEP 池的候选对象。每当找到一个候选对象时,DBA 执行该语句并调整总的 KEEP 池大小,以适应于新的对象。以下是该脚本的输出:

 
 
alter TABLE LIS.BOM_DELETE_SUB_ENTITIES storage (buffer_pool keep);
alter TABLE LIS.BOM_OPERATIONAL_ROUTINGS storage (buffer_pool keep);
alter INDEX LIS.CST_ITEM_COSTS_U1 storage (buffer_pool keep);
alter TABLE ISM3.FND_CONCT_PROGRAMS storage (buffer_pool keep);
alter TABLE ISM3.FND_CONCT_REQUESTS storage (buffer_pool keep);
alter TABLE IS.GL_JE_BATCHES storage (buffer_pool keep);
alter INDEX IS.GL_JE_BATCHES_U2 storage (buffer_pool keep);
alter TABLE IS.GL_JE_HEADERS storage (buffer_pool keep);

当您已经识别出要分配到 KEEP 池的段时,需要调整 db_keep_cache_size 参数,以确保具有足够的块将所有分配到池中的段进行完全高速缓存。

当然,自动化方法有很多例外情况。例如,这些脚本不处理表分区和其他对象类型。它们只应该用作 KEEP 池高速缓存策略的框架,而不应该就这样运行。

数据库自调整的前景

尽管有许多新的 Oracle Database 10g 特性使自动调整变得更容易,但最直接相关的特性是新的 dbms_advisor PL/SQL 包和 Java pool advisory 实用程序:

  • Java Pool Advisory 该实用程序帮助预测 java_pool_size 内存区域添加或删除 RAM 帧的益处。
  • SQLAccess Advisor 这是新的 dbms_advisor 程序包的一个新的令人激动的 Oracle Database 10g 特性,它使您能获得关于创建、维护和使用索引及物化视图的建议。
  • tune_mview advisor 实用程序 这是 Oracle Database 10g dbms_advisor 程序包的另一个新组件,使您能获得关于何种物化视图可用于超级管理 SQL 查询的专家建议。

记住,只要 Oracle 提供了功能强大的工具,如 alter system 语句,您就应该利用它们来自动执行常规的 DBA 务。这样将为您节省更多时间来钻研 Oracle 数据库管理中更复杂的领域。

Donald K. Burleson  是世界上最优秀的 Oracle 数据库专家之一。他已经撰写了 19 书籍,在全国性杂志上发表了 100 多篇文章,并担任 Oracle Internals(一本领先的 Oracle 数据库期刊)的主编。Burleson 最新的一本书是创建自调整的数据库,由 Rampant TechPress 出版。Don 的网站是 http://www.dba-oracle.com http://www.remote-dba.net/

1

RAM 区域

压力过大的情况

过量分配的情况

共享池

库高速缓存遗漏

遗漏

数据缓冲区高速缓存

命中率 < 90%

命中率 > 95%

PGA 集合

高度的多执行

100% 优化执行

 


 

 

 

��  
 
 
Oracle Training at Sea
 
 
 
 
oracle dba poster
 

 
Follow us on Twitter 
 
Oracle performance tuning software 
 
Oracle Linux poster
 
 
 

 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational