自动调整 Oracle9i Database ：Oracle SGA(2)

为 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 executionsoptimal 的值持续显示百分之百时 您可能会考虑减少 pga_aggregate_target 的值 v$pgastat 视图提供对 PGA 使用情况以及自动内存管理程序的实例级汇总统计信息 为快速获得概要信息 有个简单的查询提供了关于所有 Oracle Database g 连接的总体 PGA 使用情况的极佳统计信息 check_pga sql Display detailed PGA statistics column name format a column value format selectname valuefromv$pgastat;该查询的输出可能类似于以下信息 NAME VALUE aggregate PGA auto target global memory bound total expected memory total PGA inuse total PGA allocated maximum PGA allocated total PGA used for auto workareas maximum PGA used for auto workareas total PGA used for manual workareas maximum PGA used for manual workareas estimated PGA memory for optimal maximum PGA memory for optimal estimated PGA memory for one pass maximum PGA memory for one pass 在上面来自于 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 g 遇到内存短缺情况时 DBA 将调用多步 *** 作 试图找到最近释放的 RAM 内存 在 Oracle Database g 中 该统计量对于监视 RAM 使用情况非常重要 大部分 Oracle DBA 会将 pga_aggregate_target 增加到此值 在 Oracle Database g 中可以使用称为新顾问实用程序的 v$pga_target_advice 该实用程序显示从当前值的 % 到 % 的不同大小的 pga_aggregate_target 的最优化 一步和多步 PGA 执行的临界差别 列表显示使用这一新的实用程序的示例查询 以下是输出的示例 在这里我们看到 已经为当前的处理超量分配了 pga_aggregate_target 可以安全地从这一区域提取 RAM 并将它分配到其他地方 Estimated EstimatedTarget(M) Cache Hit % Over Alloc <= current size 可以看到 您能够方便地创建自动方法来检测 PGA 内存短缺情况（使用 Statspack ）并编写作业来动态更改 pga_aggregate_target 以确保为排序和散列联接进行最优化的 RAM 使用 为数据缓冲区开发特征码 DBA 将会注意到 在实际情况中 数据缓冲区命中率 (DBHR) 的变化会随着测量间隔的频率增加而增加 例如 Statspack 可能在以小时为单位的间隔时报告 DBHR 为百分之九十二 但在采样率以两分钟为间隔时 将显示很大的变化 如图 所示 图 作为一般性原则 应该调整主机上的所有可用内存 并且应该为 db_cache_size 分配达到增益递减点的 RAM 资源 （参见图 ） 在该点处增加缓冲区块不会显著提高缓冲区命中率 图 新的 v$db_cache_advice 视图 类似于 Oracle 中推出的一个用于跟踪缓冲区命中情况的旧实用程序 x$kcbrbh 同样 x$kcbcbh 视图用于跟踪缓冲区遗漏情况 数据缓冲区命中率可以提供与 v$db_cache_advice 所提供内容相类似的数据 因此多数 Oracle 调整的专业人员可以使用这两种工具来监视其数据缓冲区的有效性 当 v$db_cache_advice 实用程序已经启用 并且数据库已经运行了足够长的时间来提供有代表性的结果时 可以使用 列表 中的脚本来执行高速缓存建议功能 使用这一脚本 您可以获得对您所有缓冲区池的高速缓存建议 包括 k k k k 和 k 数据缓冲区 该脚本的输出如下所示 注意 数值的范围从 db_cache_size 当前大小的百分之十直到当前大小的两倍 Estd Phys Estd PhysCache Size (MB) BuffersRead　Factor　Reads < % size Current Size < x size如图 中所标注 数据缓冲区最优化设置的位置就是附加缓冲区的临界效益开始减少的位置 当然 该优化点将在一段时间后改变 这就是为什么我们需要预先重新配置 SGA 的原因 以便于我们能够根据当前的处理需要来更改数据缓冲区的大小 对于趋势分析 DBHR 中的变化并不重要 可以沿两个方向生成平均数据缓冲区命中率 一周中每天的平均 DBHR 和一天中每小时的平均 DBHR 记住 在数据缓冲区中变化快速地发生 有时长期的分析将会提供线索 指出数据库中的处理故障问题 几乎每个 Oracle 数据库都提供链接到常规处理计划的模式 称为特征码 以下显示一个 Statspack DBHR 每小时平均值脚本的输出 报告基于六个月的数据收集 显示每天的平均命中率 如果在电子表格中绘制该数据 则该数据库的 DBHR 特征码变得显而易见 hr BHR 该数据的绘图如图 所示 我们看到一些有趣的重复趋势 lishixinzhi/Article/program/Oracle/201311/18159

修改SGA参数时你用的是什么启动是用spfile启动的吗

alter system set sga_max_size=2000m scope=spfile;

你查看下sga_max_size的status

select from v$parameter where name ='sga_max_size' ;

看看 ISSYS_MODIFIABLE 和 ISSES_MODIFIABLE 等字段是否为false , 如是,好像只能修改pfile 然后用

create spfile from pfile ， 然后再重新启动oracle试试

1、1、调整数据结构的设计。这一部分在开发信息系统之前完成，程序员需要考虑是否使用ORACLE数据库的分区功能，对于经常访问的数据库表是否需要建立索引等。 \x0d\\x0d\2、2、调整应用程序结构设计。这一部分也是在开发信息系统之前完成，程序员在这一步需要考虑应用程序使用什么样的体系结构，是使用传统的Client/Server两层体系结构，还是使用Browser/Web/Database的三层体系结构。不同的应用程序体系结构要求的数据库资源是不同的。 \x0d\\x0d\3、3、调整数据库SQL语句。应用程序的执行最终将归结为数据库中的SQL语句执行，因此SQL语句的执行效率最终决定了ORACLE数据库的性能。ORACLE公司推荐使用ORACLE语句优化器（Oracle Optimizer）和行锁管理器（row-level manager）来调整优化SQL语句。 \x0d\\x0d\4、4、调整服务器内存分配。内存分配是在信息系统运行过程中优化配置的，数据库管理员可以根据数据库运行状况调整数据库系统全局区（SGA区）的数据缓冲区、日志缓冲区和共享池的大小；还可以调整程序全局区（PGA区）的大小。需要注意的是，SGA区不是越大越好，SGA区过大会占用 *** 作系统使用的内存而引起虚拟内存的页面交换，这样反而会降低系统。 \x0d\\x0d\5、5、调整硬盘I/O，这一步是在信息系统开发之前完成的。数据库管理员可以将组成同一个表空间的数据文件放在不同的硬盘上，做到硬盘之间I/O负载均衡。 \x0d\\x0d\6、6、调整 *** 作系统参数，例如：运行在UNIX *** 作系统上的ORACLE数据库，可以调整UNIX数据缓冲池的大小，每个进程所能使用的内存大小等参数。 \x0d\\x0d\实际上，上述数据库优化措施之间是相互联系的。ORACLE数据库性能恶化表现基本上都是用户响应时间比较长，需要用户长时间的等待。但性能恶化的原因却是多种多样的，有时是多个因素共同造成了性能恶化的结果，这就需要数据库管理员有比较全面的计算机知识，能够敏感地察觉到影响数据库性能的主要原因所在。另外，良好的数据库管理工具对于优化数据库性能也是很重要的。 \x0d\\x0d\ORACLE数据库性能优化工具 \x0d\\x0d\常用的数据库性能优化工具有： \x0d\\x0d\1、1、ORACLE数据库在线数据字典，ORACLE在线数据字典能够反映出ORACLE动态运行情况，对于调整数据库性能是很有帮助的。 \x0d\\x0d\2、2、 *** 作系统工具，例如UNIX *** 作系统的vmstat，iostat等命令可以查看到系统系统级内存和硬盘I/O的使用情况，这些工具对于管理员弄清出系统瓶颈出现在什么地方有时候很有用。 \x0d\\x0d\3、3、SQL语言跟踪工具（SQL TRACE FACILITY），SQL语言跟踪工具可以记录SQL语句的执行情况，管理员可以使用虚拟表来调整实例，使用SQL语句跟踪文件调整应用程序性能。SQL语言跟踪工具将结果输出成一个 *** 作系统的文件，管理员可以使用TKPROF工具查看这些文件。 \x0d\\x0d\4、4、ORACLE Enterprise Manager（OEM），这是一个图形的用户管理界面，用户可以使用它方便地进行数据库管理而不必记住复杂的ORACLE数据库管理的命令。 \x0d\\x0d\5、5、EXPLAIN PLAN——SQL语言优化命令，使用这个命令可以帮助程序员写出高效的SQL语言。 \x0d\\x0d\ORACLE数据库的系统性能评估 \x0d\\x0d\信息系统的类型不同，需要关注的数据库参数也是不同的。数据库管理员需要根据自己的信息系统的类型着重考虑不同的数据库参数。 \x0d\\x0d\1、1、在线事务处理信息系统（OLTP），这种类型的信息系统一般需要有大量的Insert、Update *** 作，典型的系统包括民航机票发售系统、银行储蓄系统等。OLTP系统需要保证数据库的并发性、可靠性和最终用户的速度，这类系统使用的ORACLE数据库需要主要考虑下述参数： \x0d\\x0d\l l 数据库回滚段是否足够？ \x0d\\x0d\l l 是否需要建立ORACLE数据库索引、聚集、散列？ \x0d\\x0d\l l 系统全局区（SGA）大小是否足够？ \x0d\\x0d\l l SQL语句是否高效？ \x0d\\x0d\2、2、数据仓库系统（Data Warehousing），这种信息系统的主要任务是从ORACLE的海量数据中进行查询，得到数据之间的某些规律。数据库管理员需要为这种类型的ORACLE数据库着重考虑下述参数： \x0d\\x0d\l l 是否采用B-索引或者bitmap索引？ \x0d\\x0d\l l 是否采用并行SQL查询以提高查询效率？ \x0d\\x0d\l l 是否采用PL/SQL函数编写存储过程？ \x0d\\x0d\l l 有必要的话，需要建立并行数据库提高数据库的查询效率 \x0d\\x0d\SQL语句的调整原则 \x0d\\x0d\SQL语言是一种灵活的语言，相同的功能可以使用不同的语句来实现，但是语句的执行效率是很不相同的。程序员可以使用EXPLAIN PLAN语句来比较各种实现方案，并选出最优的实现方案。总得来讲，程序员写SQL语句需要满足考虑如下规则： \x0d\\x0d\1、1、尽量使用索引。试比较下面两条SQL语句： \x0d\\x0d\语句A：SELECT dname, deptno FROM dept WHERE deptno NOT IN \x0d\\x0d\(SELECT deptno FROM emp); \x0d\\x0d\语句B：SELECT dname, deptno FROM dept WHERE NOT EXISTS \x0d\\x0d\(SELECT deptno FROM emp WHERE deptdeptno = empdeptno); \x0d\\x0d\这两条查询语句实现的结果是相同的，但是执行语句A的时候，ORACLE会对整个emp表进行扫描，没有使用建立在emp表上的deptno索引，执行语句B的时候，由于在子查询中使用了联合查询，ORACLE只是对emp表进行的部分数据扫描，并利用了deptno列的索引，所以语句B的效率要比语句A的效率高一些。 \x0d\\x0d\2、2、选择联合查询的联合次序。考虑下面的例子： \x0d\\x0d\SELECT stuff FROM taba a, tabb b, tabc c \x0d\\x0d\WHERE aacol between :alow and :ahigh \x0d\\x0d\AND bbcol between :blow and :bhigh \x0d\\x0d\AND cccol between :clow and :chigh \x0d\\x0d\AND akey1 = bkey1 \x0d\\x0d\AMD akey2 = ckey2; \x0d\\x0d\这个SQL例子中，程序员首先需要选择要查询的主表，因为主表要进行整个表数据的扫描，所以主表应该数据量最小，所以例子中表A的acol列的范围应该比表B和表C相应列的范围小。 \x0d\\x0d\3、3、在子查询中慎重使用IN或者NOT IN语句，使用where (NOT) exists的效果要好的多。 \x0d\\x0d\4、4、慎重使用视图的联合查询，尤其是比较复杂的视图之间的联合查询。一般对视图的查询最好都分解为对数据表的直接查询效果要好一些。 \x0d\\x0d\5、5、可以在参数文件中设置SHARED_POOL_RESERVED_SIZE参数，这个参数在SGA共享池中保留一个连续的内存空间，连续的内存空间有益于存放大的SQL程序包。 \x0d\\x0d\6、6、ORACLE公司提供的DBMS_SHARED_POOL程序可以帮助程序员将某些经常使用的存储过程“钉”在SQL区中而不被换出内存，程序员对于经常使用并且占用内存很多的存储过程“钉”到内存中有利于提高最终用户的响应时间。 \x0d\\x0d\CPU参数的调整 \x0d\\x0d\CPU是服务器的一项重要资源，服务器良好的工作状态是在工作高峰时CPU的使用率在90％以上。如果空闲时间CPU使用率就在90％以上，说明服务器缺乏CPU资源，如果工作高峰时CPU使用率仍然很低，说明服务器CPU资源还比较富余。 \x0d\\x0d\使用 *** 作相同命令可以看到CPU的使用情况，一般UNIX *** 作系统的服务器，可以使用sar _u命令查看CPU的使用率，NT *** 作系统的服务器，可以使用NT的性能管理器来查看CPU的使用率。 \x0d\\x0d\数据库管理员可以通过查看v$sysstat数据字典中“CPU used by this session”统计项得知ORACLE数据库使用的CPU时间，查看“OS User level CPU time”统计项得知 *** 作系统用户态下的CPU时间，查看“OS System call CPU time”统计项得知 *** 作系统系统态下的CPU时间， *** 作系统总的CPU时间就是用户态和系统态时间之和，如果ORACLE数据库使用的CPU时间占 *** 作系统总的CPU时间90％以上，说明服务器CPU基本上被ORACLE数据库使用着，这是合理，反之，说明服务器CPU被其它程序占用过多，ORACLE数据库无法得到更多的CPU时间。 \x0d\\x0d\数据库管理员还可以通过查看v$sesstat数据字典来获得当前连接ORACLE数据库各个会话占用的CPU时间，从而得知什么会话耗用服务器CPU比较多。 \x0d\\x0d\出现CPU资源不足的情况是很多的：SQL语句的重解析、低效率的SQL语句、锁冲突都会引起CPU资源不足。 \x0d\\x0d\1、数据库管理员可以执行下述语句来查看SQL语句的解析情况： \x0d\\x0d\SELECT FROM V$SYSSTAT \x0d\\x0d\WHERE NAME IN \x0d\\x0d\('parse time cpu', 'parse time elapsed', 'parse count (hard)'); \x0d\\x0d\这里parse time cpu是系统服务时间，parse time elapsed是响应时间，用户等待时间 \x0d\\x0d\waite time = parse time elapsed _ parse time cpu \x0d\\x0d\由此可以得到用户SQL语句平均解析等待时间＝waite time / parse count。这个平均等待时间应该接近于0，如果平均解析等待时间过长，数据库管理员可以通过下述语句 \x0d\\x0d\SELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS FROM V$SQLAREA \x0d\\x0d\ORDER BY PARSE_CALLS; \x0d\\x0d\来发现是什么SQL语句解析效率比较低。程序员可以优化这些语句，或者增加ORACLE参数SESSION_CACHED_CURSORS的值。 \x0d\\x0d\2、数据库管理员还可以通过下述语句： \x0d\\x0d\SELECT BUFFER_GETS, EXECUTIONS, SQL_TEXT FROM V$SQLAREA; \x0d\\x0d\查看低效率的SQL语句，优化这些语句也有助于提高CPU的利用率。 \x0d\\x0d\3、3、数据库管理员可以通过v$system_event数据字典中的“latch free”统计项查看ORACLE数据库的冲突情况，如果没有冲突的话，latch free查询出来没有结果。如果冲突太大的话，数据库管理员可以降低spin_count参数值，来消除高的CPU使用率。 \x0d\\x0d\内存参数的调整 \x0d\\x0d\内存参数的调整主要是指ORACLE数据库的系统全局区（SGA）的调整。SGA主要由三部分构成：共享池、数据缓冲区、日志缓冲区。 \x0d\\x0d\1、 1、 共享池由两部分构成：共享SQL区和数据字典缓冲区，共享SQL区是存放用户SQL命令的区域，数据字典缓冲区存放数据库运行的动态信息。数据库管理员通过执行下述语句： \x0d\\x0d\select (sum(pins - reloads)) / sum(pins) "Lib Cache" from v$librarycache; \x0d\\x0d\来查看共享SQL区的使用率。这个使用率应该在90％以上，否则需要增加共享池的大小。数据库管理员还可以执行下述语句： \x0d\\x0d\select (sum(gets - getmisses - usage - fixed)) / sum(gets) "Row Cache" from v$rowcache; \x0d\\x0d\查看数据字典缓冲区的使用率，这个使用率也应该在90％以上，否则需要增加共享池的大小。 \x0d\\x0d\2、 2、 数据缓冲区。数据库管理员可以通过下述语句： \x0d\\x0d\SELECT name, value FROM v$sysstat WHERE name IN ('db block gets', 'consistent gets','physical reads'); \x0d\\x0d\来查看数据库数据缓冲区的使用情况。查询出来的结果可以计算出来数据缓冲区的使用命中率＝1 - ( physical reads / (db block gets + consistent gets) )。 \x0d\\x0d\这个命中率应该在90％以上，否则需要增加数据缓冲区的大小。 \x0d\\x0d\3、 3、 日志缓冲区。数据库管理员可以通过执行下述语句： \x0d\\x0d\select name,value from v$sysstat where name in ('redo entries','redo log space requests');查看日志缓冲区的使用情况。查询出的结果可以计算出日志缓冲区的申请失败率： \x0d\\x0d\申请失败率＝requests/entries，申请失败率应该接近于0，否则说明日志缓冲区开设太小，需要增加ORACLE数据库的日志缓冲区。

您好，很高兴为您解答。

在Oracle11g数据库中，使用自动内存管理特性不再需要设定参数PGA_AGGREGATE_TARGET和SGA_TARGET，因为这两个参数都已经被修改成自动调优的，除非想指定PGA和SGA的最小值才需要设定这两个参数。在Oracle11g数据库中，则需要设置一个叫做MEMORY_TARGET的初始化参数，这个参数是指整个Oracle实例所能使用的内存大小，包括PGA和SGA的整体大小，在MEMORY_TARGET的内存大小之内，PGA和SGA所用的内存可以根据当前负载情况自动相互转换。如果当初始设定的MEMORY_TARGET的内存不够当前数据库使用的时候，Oracle11g还提供了另外一个初始化参数MEMORY_MAX_TARGET，当原始设定的内存不够使用的时候，可以手工来动态

调节MEMORY_TARGET的大小，但是不允许超过MEMORY_MAX_TARGET的值。

如若满意，请点击右侧~~答案，如若还有问题，请点击追问

希望我的回答对您有所帮助，望~~！

fixed size就是SGA中固定组件（它在编译oracle 数据库本身时就固定于其中）的大小。它是固定大小的内存，用来指向SGA的其它部分。SGA这一部分的大小是不能改变的。

variable size指分配的内存块大小可变。SGA的可变块，分为共享池、大池、JAVA池、游标区和其他结构。

以上就是关于自动调整 Oracle9i Database ：Oracle SGA(2)全部的内容，包括:自动调整 Oracle9i Database ：Oracle SGA(2)、oracle sga 参数无法修改是什么原因、影响数据库性能的主要因素有哪些等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！