科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道自动调整 Oracle9i Database :Oracle SGA

自动调整 Oracle9i Database :Oracle SGA

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

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

作者:中国IT实验室 来源:中国IT实验室 2007年10月7日

关键字: 优化 数据库 ORACLE

  • 评论
  • 分享微博
  • 分享邮件

在本页阅读全文(共2页)


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

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

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

  
图 2:RAM 的动态重分配

  您可以在很多种 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 10 g 中,如何轻易地改变 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 10 g 使 DBA 能够预见处理需求并定期地安排适当的干预操作,从而确保为处理需求的变化即时地提供 SGA 资源。
  
  自调整 Oracle 的内存区域涉及到改变几个 Oracle 参数的值。虽然存在 250 多个 Oracle Database 10 g 参数来管理数据库的各方面配置,但只有少数几个参数对自动的 Oracle SGA 调整很重要:
  
  db_cache_size ― db_cache_size 确定 Oracle SGA 中的数据库块缓冲的数量,并且代表着 Oracle 内存最重要的一个参数。
  db_keep_cache_size ― 这个数据缓冲池是 Oracle8 i 中 db_block_buffers 的一个子缓冲池,但从 Oracle9 i Database 开始成为一个单独的 RAM 区域。
  db_nn_cache_size ― Oracle Database 10 g 有单独的数据缓冲池,您可以使用这些数据缓冲池来分离数据并分离具有不同 I/O 特性的对象。
  shared_pool_size ― shared_pool_size 定义系统中由所有用户共享的池,包括 SQL 区域和数据字典缓存。
  pga_aggregate_target ― pga_aggregate_target 定义为系统范围的排序和散列连接保留的 RAM 区域。
  您可以看到,甚至不需要对您的 Oracle 数据库状况的最重要的量度进行归零校正。让我们从检查库缓存中的趋势开始,并确定如何自动调整 shared_pool_size 。
  
  使用 Oracle Database 10 g 顾问实用程序
  Oracle Database 10 g 拥有完整的顾问实用程序,它们将准确地预测改变任意的 RAM 区域大小将带来的变化。 Oracle Database 10 g 中的顾问实用程序包括:
  
  共享池建议 ― v$shared_pool_advice
  PGA 目标建议 ― v$pga_target_advice
  数据缓存建议 ― v$db_cache_advice
  Java 池建议 ― v$java_pool_advice
  这些实用程序是确保自调整变化正确合理的一种极好的方式。以下内容将显示如何调用和解释这些顾问实用程序;当您能够轻松地解释它们的输出时,您就可以编写自动化的脚本来生成建议、解释输出,并自动改变 RAM 区域的大小。
  
  共享池建议实用程序
  这一顾问功能在 Oracle9 i Database Release 2 中得到了扩展,包含了一个称为 v$shared_pool_advice 的新的建议实用程序,在将来的版本中它可能最终将被扩展至所有的 SGA RAM 。
  
  从 Oracle9 i Database Release 2 开始,当共享池的大小从当前值的 10% 变为当前值的 200% 时, v$shared_pool_advice 视图将显示 SQL 分析的边际差异。
  
  共享池建议实用程序非常易于配置:安装后,您可以运行一个简单的脚本来查询 v$shared_pool_advice 视图,并查看不同 shared_pool 大小的 SQL 分析的边际变化。以下脚本的输出将告诉您动态增加或减少 shared_pool_size 参数带来

查看本文来源

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章