内存配置使用

下面的池是手工调整的，不受asmm影响

log buffer

other buffer cache(像是keep,recycle和非默认块）

固定sga和其他内部分配

对共享池，大池，java池，和buffer cache是以grunules为单位来分配的。如果sga的大小小于1GB，那么granule的大小是4MB。如果SGA大于1GB,那么granule的大小就是16MB,这个的大小在启动时候就计算出来了，并且是不可以改变的。大小可以查看v$sga_dynamic_components视图来查看。

查看动态调整操作的信息，下面的视图可以查看

• V$SGA_CURRENT_RESIZE_OPS: Information about SGA resize operations that are currently in progress. An operation can be a grow or a shrink of a dynamic SGA component.

• V$SGA_RESIZE_OPS: Information about the last 800 completed SGA resize operations. This does not include any operations currently in progress.

• V$SGA_DYNAMIC_COMPONENTS: Information about the dynamic components in SGA. This view summarizes information based on all completed SGA resize operations since startup.

• V$SGA_DYNAMIC_FREE_MEMORY: Information about the amount of SGA memory available for future dynamic SGA resize operations.

配置buffer cache,可以通过下面2个方面来配置buffer cache

1v$db_cache_advice

2buffer cache hit ratio

使用下面的语句

COLUMN size_for_estimate          FORMAT 999,999,999,999 heading 'Cache Size (MB)'
COLUMN buffers_for_estimate       FORMAT 999,999,999 heading 'Buffers'
COLUMN estd_physical_read_factor  FORMAT 999.90 heading 'Estd Phys|Read Factor'
COLUMN estd_physical_reads        FORMAT 999,999,999 heading 'Estd Phys| Reads'

SELECT size_for_estimate, buffers_for_estimate, estd_physical_read_factor, estd_physical_reads
   FROM V$DB_CACHE_ADVICE
   WHERE name          = 'DEFAULT'
     AND block_size    = (SELECT value FROM V$PARAMETER WHERE name = 'db_block_size')
     AND advice_status = 'ON';

如下的输出

Estd Phys    Estd Phys
 Cache Size (MB)      Buffers Read Factor        Reads
---------------- ------------ ----------- ------------
              30        3,802       18.70  192,317,943      10% of Current 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      200% of Current Size 

这个输出指出如果buffer cache是212MB，而不是当前的304MB那么物理读将会增加1.74或是74%。如果是增加到334MB，那么这个物理读会降7%

计算buffercache 命中率

Table 7-1 Statistics for Calculating the Hit Ratio

Statistic	Description
consistent gets from cache	Number of times a consistent read was requested for a block from the buffer cache.
db block gets from cache	Number of times a CURRENT block was requested from the buffer cache.
physical reads cache	Total number of data blocks read from disk into buffer cache.

SELECT NAME, VALUE
  FROM V$SYSSTAT
WHERE NAME IN ('db block gets from cache', 'consistent gets from cache', 'physical reads cache');

Using the values in the output of the query, calculate the hit ratio for the buffer cache with the following formula:

1 - (('physical reads cache') / ('consistent gets from cache' + 'db block gets from cache')

buffer pool命中率

The ratio can be calculated with the following query:
SELECT NAME, PHYSICAL_READS, DB_BLOCK_GETS, CONSISTENT_GETS,
      1 - (PHYSICAL_READS / (DB_BLOCK_GETS + CONSISTENT_GETS)) "Hit Ratio"
  FROM V$BUFFER_POOL_STATISTICS;

多buffer cache

对那些非典型的访问模式，存储这些段到2个不同的池，keep池与recycle池。可以使用keep buffer来放经常访问的段，recycle池来阻止对象消耗不必要的空间。当一个对象关联到一个cache中，该对象的所有的块都在这个cache中，oracle维护一个defaultbuffer pool来存放没有分配具体buffer pool的对象。默认的buffer pool使用db_cache_size来指定大小。keep池，recycel池与default bufferpool,是相互独立的。

随机访问大段

当一个大段使用一个大的或是没有边界的索引范围扫描时，lru算法可能会有问题，这里的非常大指的是相对cache size来说的。超过cache的10%就认为是很大了。随机的访问一个大段可能会把别的段挤出去，大段最终消耗了大量的空间，但是没有从cache中获取好处。经常访问的段不受大段的影响 ，因为他们的buffer是热的，不会被交换出去。解决这个问题有下面的几个方法：

1找到索引，看索引是否是选择性高的，如果不是，调优索引

2如果索引没有问题，你可以吧大对象移动到单独的recyclecache中，这样就不影响别的段。recycle 应该小于default buffer cache。

3你也可以将经常访问的对象放到keep中。

查看一个对象有多少buffer

方法一，查看所有段的块数，依赖与buffer cache size这个可能需要很多的排序空间

COLUMN OBJECT_NAME FORMAT A40
COLUMN NUMBER_OF_BLOCKS FORMAT 999,999,999,999

SELECT o.OBJECT_NAME, COUNT(*) NUMBER_OF_BLOCKS
     FROM DBA_OBJECTS o, V$BH bh
    WHERE o.DATA_OBJECT_ID = bh.OBJD
      AND o.OWNER         != 'SYS'
    GROUP BY o.OBJECT_NAME
    ORDER BY COUNT(*);

方法二，使用下面的方法来看一个对象使用的cache百分比

1. the Oracle internal object number of the segment by entering the following query:

   SELECT DATA_OBJECT_ID, OBJECT_TYPE
     FROM DBA_OBJECTS 
    WHERE OBJECT_NAME = UPPER('segment_name'); 
   
   

   Because two objects can have the same name (if they are different types of objects), use theOBJECT_TYPE column to identify the object of interest.

2. Find the number of buffers in the buffer cache for SEGMENT_NAME:

   SELECT COUNT(*) BUFFERS 
     FROM V$BH
    WHERE OBJD = data_object_id_value; 
   
   

   where data_object_id_value is from step 1.

3. Find the number of buffers in the instance:

   SELECT NAME, BLOCK_SIZE, SUM(BUFFERS)
     FROM V$BUFFER_POOL
    GROUP BY NAME, BLOCK_SIZE
    HAVING SUM(BUFFERS) > 0;
   
   

4. Calculate the ratio of buffers to total buffers to obtain the percentage of the cache currently used by SEGMENT_NAME:

   % cache used by segment_name = [buffers(Step2)/total buffers(Step3)] 
   

keep池

nocache 语句对于在keep池中的对象来说没有影响。keep池的大小依赖与keep池中的对象，你可以通过算下keep池中对象的块数来计算。通过dba_table.blocks与dba_tables.empty_blocks来决定使用的块数。

命中率是100%,也不见得好，这种情况下，通常降低buffer的大小并维持命中率很高，把多余的空间分配给别的部分使用。

recycle池

可以配置recyclebuffer来放你不想放在内存中的段的块，recycle池对于那些很少扫描或很少访问的段很有好处，如果应用程序以随机方式访问一个大对象，那么在它被交换出去之前就很少有机会被重复使用，因此这个对象的块不需要缓存，这些cache buffer可以分配给别的对象。

配置共享池

在数据字典缓存或库缓存中的缓存丢失的代价要比buffer cache中的代价要高。

在共享池中的几个分配大内存的特色功能有：共享server,并行查询，或recovery manager.oracle建议这些特色使用的内存在sga中分开，配置一个大池供他们使用。

共享池中的内存分配是以chunks来分的。这个允许超过5k的大对象加载到缓存中，而不需要一个单独的连续空间，减少了由于碎片导致的没有足够的连续空间问题。java,pl/sql,或sql游标可能超过5k,为了让这样的分配快些，oracle在共享池中分配一小部分空间，当共享池没有足够的空间的时候就使用这部分内存，这部分内存叫reserved pool

在oltp系统中，有几个方法可以有效的使用共享内存和相关资源：

• Shared Cursors

• Single-User Logon and Qualified Table Reference

• Use of PL/SQL

• Avoid Performing DDL

• Cache Sequence Numbers

• Cursor Access and Management

1共享游标，这个就是使用绑定变量来解决，对于没有共享游标的语句，可以查看v$sql_shared_cursor视图来查找没有共享的原因。

设置共享池：库缓存信息

v$librarycache视图中的reloads和invalidation列都应该是0，

SELECT NAMESPACE, PINS, PINHITS, RELOADS, INVALIDATIONS
  FROM V$LIBRARYCACHE
 ORDER BY NAMESPACE;

计算库缓存的命中率，使用下面的公式
Library Cache Hit Ratio = sum(pinhits) / sum(pins)

查看sga中共享池空闲的大小

SELECT * FROM V$SGASTAT 
 WHERE NAME = 'free memory'
   AND POOL = 'shared pool';

共享池：数据字典信息

v$rowcache反映了数据字典的信息

Table 7-2 V$ROWCACHE Columns

Column	Description
PARAMETER	Identifies a particular data dictionary item. For each row, the value in this column is the item prefixed bydc_. For example, in the row that contains statistics for file descriptions, this column has the valuedc_files.
GETS	Shows the total number of requests for information on the corresponding item. For example, in the row that contains statistics for file descriptions, this column has the total number of requests for file description data.
GETMISSES	Shows the number of data requests which were not satisfied by the cache, requiring an I/O.
MODIFICATIONS	Shows the number of times data in the dictionary cache was updated.

column parameter format a21
column pct_succ_gets format 999.9
column updates format 999,999,999

SELECT parameter
     , sum(gets)
     , sum(getmisses)
     , 100*sum(gets - getmisses) / sum(gets)  pct_succ_gets
     , sum(modifications)                     updates
  FROM V$ROWCACHE
 WHERE gets > 0
 GROUP BY parameter;

使用下面公式计算数据字典缓存命中率

SELECT (SUM(GETS - GETMISSES - FIXED)) / SUM(GETS) "ROW CACHE" FROM V$ROWCACHE;

使用大池

大池不会使用lru列表，oracle不会把对象交换出大池，如果你的实例中有下面的东西，你需要设置大池：

1并行查询，并行查询使用共享内存来缓存并行执行信息。

2recovery manager

3共享server

为共享server配置大池

oracle建议使用大池来分配uga，而不是使用共享池，使用大池减少了共享池的碎片。为了在大池中存放uga，要设置large_pool_size，大池默认不配置，最小值是300k，如果不使用大池，oracle使用共享池来放置用户会话。配置大池是基于并发的活动会话。例如假设每个共享server要求200k到300k来存放用户活动会话，要是有100个会话，那么配置大池要到30M.

查看v$sesstat，根据下面的查询为共享server设置共享池

SELECT SUM(VALUE) || ' BYTES' "TOTAL MEMORY FOR ALL SESSIONS"
    FROM V$SESSTAT, V$STATNAME
    WHERE NAME = 'session uga memory' 
    AND V$SESSTAT.STATISTIC# = V$STATNAME.STATISTIC#;

SELECT SUM(VALUE) || ' BYTES' "TOTAL MAX MEM FOR ALL SESSIONS"
    FROM V$SESSTAT, V$STATNAME
    WHERE NAME = 'session uga memory max'
    AND V$SESSTAT.STATISTIC# = V$STATNAME.STATISTIC#;

使用cursor_space_for_time

如果没有library cache misses，你可以设置cursor_space_for_tiime成true来加速执行调用，这个参数指定了游标是否可以再library cache中删除来为别的sql提供空间，cursor_space_for_time有下面的信息：

1false是默认的，那么这个游标是可以再库缓存中删除的不管应用sql关联的游标是打开的。

2true，这个游标在关闭的时候才能丢弃。

如果发现库缓存中在执行调用的时候有misses，那么不要设置成true，这种miss意味着共享池的内存不够大来存放所有的共享打开游标，如果设置成true，那么共享池就没有空闲空间供新sql使用，那么sql就不能解析，oracle就会返回一个错误，提示没有更多的内存。如果设置false,如果没有空闲空间，那么oracle丢弃存在的游标。

如果对每个用户的可用私有sql区很匮乏，也不要设置成true,这个同样是对打开的游标不会丢弃，新来的sql没有空间，也是报错。

缓存会话游标

如果应用程序总是重复的执行相同sql语句，那么重复打开会话游标会影响系统性能，为了最小化这个影响，会话游标可以存放在游标缓存中，可以被重复使用。oracle检查库缓存来决定一个sql是否解析超过3次，如果超过3次，那么oracle就会缓存这个游标，后续相同的会话就在会话游标缓存中找到这个游标。为了使用会话游标缓存，要设置初始化参数session_cached_cursors，这个值是个正整数，用lru算法来移除游标为新的游标腾出空间。

查看v$sysstat的session cursor cache hits,看这个值在解析调用中占的比例是否过低，要是低的话，加大session_cached_cursors的值。

配置reserved pool

默认最小reserved pool的值是4400字节，尽管oracle把大的内存请求转化为小的chunks，但是一些系统中仍然会请求连续的chunk，如果没有空闲空间，oracle必须搜寻空闲空间，这个操作会持有latch，影响别的内存分配的请求。

改变shared_pool_reserved_size参数来设置该池，这个参数设置的空间用来不经常出现的大的空间分配。

对大的分配，oracle按下面的顺序尝试分配空间：

1在共享池unreserved 部分

2在reserved部分。

3如果上面2个都没有足够的空间，那么oracle会释放足够的内存，然后再次尝试1,2两步。

默认的shared_pool_reserved_size是shared_pool_size的5%，意味着默认的reserved list是配置了的。视图v$shared_pool_reserved提供了对该池配置的帮助。目标是使request_misses等于0.request_failures不至于增长。要是request_failures大于0,就是这个值太小了。

保持大对象不被交换出去

对象加载到共享池，然后交换出去，可能会让共享池变的破碎，dbms_shared_pool包保持对象在共享池中，这个包在下面的情况下有用：

1当加载PL/SQL对象，比如standard和diutil包，用户的相应时间也许会受影响，比如没有足够空间的时候。

2频繁执行触发器，你也许想要在共享池中频繁使用表上执行编译好的触发器。

3dbms_shared_pool支持sequences。当sequence被交换出共享池后，这个号就丢失了。

 配置使用redo log buffer

在一个有快cpu和相对慢的磁盘的机器上，处理器在写buffer到磁盘的时候，可能已经填满了剩余的buffer，一个大的log buffer能临时的解决这个问题。你也可以做下面的操作：

1提高检查点和归档进程

2提高log writer的性能

设置log buffer的大小

A reasonable first estimate for such systems is to the default value, which is:

MAX(0.5M, (128K * number of cpus))

log buffer等待事件

redo buffer allocation retries反映了用户进程等待redo log buffer的时间，这个值在v$sysstat视图中查看，该值应该接近0，要是非0，可能是buffer太小或是检查点问题。

PGA内存管理

pga是一个私有内存区，包含server进程的数据和控制信息。比如游标运行区，每次游标运行，一个新的运行区在pga中被创建来执行那个游标。

对复杂的查询，要求有大的运行区；

1sort排序 如order by group by rollup,还有窗口函数

2hash-join

3bitmap merge

4bitmap create

5批量加载操作使用的buffer

设置pga大小

You must then divide the resulting memory between the SGA and the PGA.

• For OLTP systems, the PGA memory typically accounts for a small fraction of the total memory available (for example, 20%), leaving 80% for the SGA.

• For DSS systems running large, memory-intensive queries, PGA memory can typically use up to 70% of that total (up to 2.2 GB in this example).

Good initial values for the parameter PGA_AGGREGATE_TARGET might be:

• For OLTP: PGA_AGGREGATE_TARGET = (total_mem * 80%) * 20%

• For DSS: PGA_AGGREGATE_TARGET = (total_mem * 80%) * 50%

  where total_mem is the total amount of physical memory available on the system.

In this example, with a value of total_mem equal to 4 GB, you can initially setPGA_AGGREGATE_TARGET to 1600 MB for a DSS system and to 655 MB for an OLTP system.

监控pga使用情况

• V$PGASTAT

• V$PROCESS

• V$PROCESS_MEMORY

• V$SQL_WORKAREA_HISTOGRAM

• V$SQL_WORKAREA_ACTIVE

• V$SQL_WORKAREA

• aggregate PGA target parameter: This is the current value of the initialization parameterPGA_AGGREGATE_TARGET. The default value is 20% of the SGA size. If you set this parameter to 0, automatic management of the PGA memory is disabled.

• aggregate PGA auto target: This gives the amount of PGA memory Oracle can use for work areas running in automatic mode. This amount is dynamically derived from the value of the parameterPGA_AGGREGATE_TARGET and the current work area workload. Hence, it is continuously adjusted by Oracle. If this value is small compared to the value ofPGA_AGGREGATE_TARGET, then a lot of PGA memory is used by other components of the system (for example, PL/SQL or Java memory) and little is left for sort work areas. You must ensure that enough PGA memory is left for work areas running in automatic mode.

• global memory bound: This gives the maximum size of a work area executed inAUTO mode. This value is continuously adjusted by Oracle to reflect the current state of the work area workload. The global memory bound generally decreases when the number of active work areas is increasing in the system. As a rule of thumb, the value of the global bound should not decrease to less than one megabyte. If it does, then the value ofPGA_AGGREGATE_TARGET should probably be increased.

• total PGA allocated: This gives the current amount of PGA memory allocated by the instance. Oracle tries to keep this number less than the value ofPGA_AGGREGATE_TARGET. However, it is possible for the PGA allocated to exceed that value by a small percentage and for a short period of time, when the work area workload is increasing very rapidly or when the initialization parameterPGA_AGGREGATE_TARGET is set to a too small value.

• total freeable PGA memory: This indicates how much allocated PGA memory which can be freed.

• total PGA used for auto workareas: This indicates how much PGA memory is currently consumed by work areas running under automatic memory management mode. This number can be used to determine how much memory is consumed by other consumers of the PGA memory (for example, PL/SQL or Java):

  PGA other = total PGA allocated - total PGA used for auto workareas
  
  

• over allocation count: This statistic is cumulative from instance start-up. Over-allocating PGA memory can happen if the value ofPGA_AGGREGATE_TARGET is too small to accommodate thePGA other component in the previous equation plus the minimum memory required to execute the work area workload. When this happens, Oracle cannot honor the initialization parameterPGA_AGGREGATE_TARGET, and extra PGA memory needs to be allocated. If over-allocation occurs, you should increase the value ofPGA_AGGREGATE_TARGET using the information provided by the advice viewV$PGA_TARGET_ADVICE.

• total bytes processed: This is the number of bytes processed by memory-intensive SQL operators since instance start-up. For example, the number of byte processed is the input size for a sort operation. This number is used to compute thecachehit percentage metric.

• extra bytes read/written: When a work area cannot run optimally, one or more extra passes is performed over the input data.extrabytes read/written represents the number of bytes processed during these extra passes since instance start-up. This number is also used to compute thecachehit percentage. Ideally, it should be small compared tototal bytes processed.

• cache hit percentage: This metric is computed by Oracle to reflect the performance of the PGA memory component. It is cumulative from instance start-up. A value of 100% means that all work areas executed by the system since instance start-up have used an optimal amount of PGA memory. This is, of course, ideal but rarely happens except maybe for pure OLTP systems. In reality, some work areas run one-pass or even multi-pass, depending on the overall size of the PGA memory. When a work area cannot run optimally, one or more extra passes is performed over the input data. This reduces thecachehit percentage in proportion to the size of the input data and the number of extra passes performed.Example 7-3 shows how cache hit percentage is affected by extra passes.

cache hit percentage这个反应了pga的性能，这个值是累计值，100%意味着所有的工作区使用了最优的大小，这个是个理想值，现实中，大部分工作区是运行一次通过或是多次通过，当工作区不能运行最优时，一个或更多额外的通过会被使用。

Example 7-3 Calculating Cache Hit Percentage

Consider a simple example: Four sort operations have been executed, three were small (1 MB of input data) and one was bigger (100 MB of input data). The total number of bytes processed (BP) by the four operations is 103 MB. If one of the small sorts runs one-pass, an extra pass over 1 MB of input data is performed. This 1 MB value is the number ofextrabytes read/written, or EBP. Thecachehit percentage is calculated by the following formula:

BP x 100 / (BP + EBP)

The cache hit percentage in this case is 99.03%, almost 100%. This value reflects the fact that only one of the small sorts had to perform an extra pass while all other sorts were able to run optimally. Hence, thecachehit percentage is almost 100%, because this extra pass over 1 MB represents a tiny overhead. On the other hand, if the big sort is the one to run one-pass, then EBP is 100 MB instead of 1 MB, and thecachehit percentage falls to 50.73%, because the extra pass has a much bigger impact.

V$PROCESS

This view has one row for each Oracle process connected to the instance. The columnsPGA_USED_MEM,PGA_ALLOC_MEM, PGA_FREEABLE_MEM andPGA_MAX_MEM can be used to monitor the PGA memory usage of these processes. For example:

SELECT PROGRAM, PGA_USED_MEM, PGA_ALLOC_MEM, PGA_FREEABLE_MEM, PGA_MAX_MEM 
  FROM V$PROCESS;

V$PROCESS_MEMORY

This view displays dynamic PGA memory usage by named component categories for each Oracle process. This view will contain up to six rows for each Oracle process, one row for:

• Each named component category:

  • Java

  • PL/SQL

  • OLAP

  • SQL

• Freeable - memory that has been allocated to the process by the operating system, but not to a specific category.

• Other - memory that has been allocated to a category, but not to one of the named categories.

The columns CATEGORY, ALLOCATED, USED, andMAX_ALLOCATED can be used to dynamically monitor the PGA memory usage of Oracle processes for each of the six categories.

v$sql_workarea_histogram

这个视图显示了用最优内存大小，one- pass，和multi-pass工作区的个数 视图中的数据按最优内存大小分配到桶中 每个桶被low_optimao_size和high-optimal-size指定范围。

Example 7-4 Querying V$SQL_WORKAREA_HISTOGRAM: Non-empty Buckets

Consider a sort operation that requires 3 MB of memory to run optimally (cached). Statistics about the work area used by this sort are placed in the bucket defined byLOW_OPTIMAL_SIZE = 2097152 (2 MB) and HIGH_OPTIMAL_SIZE = 4194303 (4 MB minus 1 byte), because 3 MB falls within that range of optimal sizes. Statistics are segmented by work area size, because the performance impact of running a work area in optimal, one-pass or multi-pass mode depends mainly on the size of that work area.

The following query shows statistics for all non-empty buckets. Empty buckets are removed with the predicatewhere total_execution != 0.

SELECT LOW_OPTIMAL_SIZE/1024 low_kb,
       (HIGH_OPTIMAL_SIZE+1)/1024 high_kb,
       OPTIMAL_EXECUTIONS, ONEPASS_EXECUTIONS, MULTIPASSES_EXECUTIONS
  FROM V$SQL_WORKAREA_HISTOGRAM
 WHERE TOTAL_EXECUTIONS != 0;

The result of the query might look like the following:

LOW_KB HIGH_KB OPTIMAL_EXECUTIONS ONEPASS_EXECUTIONS MULTIPASSES_EXECUTIONS
------ ------- ------------------ ------------------ ----------------------
     8      16             156255                  0                      0
    16      32                150                  0                      0
    32      64                 89                  0                      0
    64     128                 13                  0                      0
   128     256                 60                  0                      0
   256     512                  8                  0                      0
   512    1024                657                  0                      0
  1024    2048                551                 16                      0
  2048    4096                538                 26                      0
  4096    8192                243                 28                      0
  8192   16384                137                 35                      0
 16384   32768                 45                107                      0
 32768   65536                  0                153                      0
 65536  131072                  0                 73                      0
131072  262144                  0                 44                      0
262144  524288                  0                 22                      0

The query result shows that, in the 1024 KB to 2048 KB bucket, 551 work areas used an optimal amount of memory, while 16 ran in one-pass mode and none ran in multi-pass mode. It also shows that all work areas under 1 MB were able to run in optimal mode.

Example 7-5 Querying V$SQL_WORKAREA_HISTOGRAM: Percent Optimal

You can also use V$SQL_WORKAREA_HISTOGRAM to find the percentage of times work areas were executed in optimal, one-pass, or multi-pass mode since start-up. This query only considers work areas of a certain size, with an optimal memory requirement of at least 64 KB.

SELECT optimal_count, round(optimal_count*100/total, 2) optimal_perc, 
       onepass_count, round(onepass_count*100/total, 2) onepass_perc,
       multipass_count, round(multipass_count*100/total, 2) multipass_perc
FROM
 (SELECT decode(sum(total_executions), 0, 1, sum(total_executions)) total,
         sum(OPTIMAL_EXECUTIONS) optimal_count,
         sum(ONEPASS_EXECUTIONS) onepass_count,
         sum(MULTIPASSES_EXECUTIONS) multipass_count
    FROM v$sql_workarea_histogram
   WHERE low_optimal_size > 64*1024);

The output of this query might look like the following:

OPTIMAL_COUNT OPTIMAL_PERC ONEPASS_COUNT ONEPASS_PERC MULTIPASS_COUNT MULTIPASS_PERC
------------- ------------ ------------- ------------ --------------- --------------
         2239        81.63           504        18.37               0              0

This result shows that 81.63% of these work areas have been able to run using an optimal amount of memory. The rest (18.37%) ran one-pass. None of them ran multi-pass. Such behavior is preferable, for the following reasons:

• Multi-pass mode can severely degrade performance. A high number of multi-pass work areas has an exponentially adverse effect on the response time of its associated SQL operator.

• Running one-pass does not require a large amount of memory; only 22 MB is required to sort 1 GB of data in one-pass mode.

V$SQL_WORKAREA_ACTIVE

This view can be used to display the work areas that are active (or executing) in the instance. Small active sorts (under 64 KB) are excluded from the view. Use this view to precisely monitor the size of all active work areas and to determine if these active work areas spill to a temporary segment. Example 7-6 shows a typical query of this view:

Example 7-6 Querying V$SQL_WORKAREA_ACTIVE

SELECT to_number(decode(SID, 65535, NULL, SID)) sid,
       operation_type OPERATION,
       trunc(EXPECTED_SIZE/1024) ESIZE,
       trunc(ACTUAL_MEM_USED/1024) MEM,
       trunc(MAX_MEM_USED/1024) "MAX MEM",
       NUMBER_PASSES PASS,
       trunc(TEMPSEG_SIZE/1024) TSIZE
  FROM V$SQL_WORKAREA_ACTIVE
 ORDER BY 1,2;

The output of this query might look like the following:
SID         OPERATION     ESIZE       MEM   MAX MEM  PASS   TSIZE
--- ----------------- --------- --------- --------- ----- -------
  8   GROUP BY (SORT)       315       280       904     0
  8         HASH-JOIN      2995      2377      2430     1   20000
  9   GROUP BY (SORT)     34300     22688     22688     0
 11         HASH-JOIN     18044     54482     54482     0
 12         HASH-JOIN     18044     11406     21406     1  120000

This output shows that session 12 (column SID) is running a hash-join having its work area running in one-pass mode (PASS column). This work area is currently using 11406 KB of memory (MEM column) and has used, in the past, up to 21406 KB of PGA memory (MAX MEM column). It has also spilled to a temporary segment of size 120000 KB. Finally, the columnESIZE indicates the maximum amount of memory that the PGA memory manager expects this hash-join to use. This maximum is dynamically computed by the PGA memory manager according to workload.

When a work area is deallocated—that is, when the execution of its associated SQL operator is complete—the work area is automatically removed from theV$SQL_WORKAREA_ACTIVE view.

 

V$SQL_WORKAREA

Oracle maintains cumulative work area statistics for each loaded cursor whose execution plan uses one or more work areas. Every time a work area is deallocated, theV$SQL_WORKAREA table is updated with execution statistics for that work area.

V$SQL_WORKAREA can be joined with V$SQL to relate a work area to a cursor. It can even be joined toV$SQL_PLAN to precisely determine which operator in the plan uses a work area.

Example 7-7 shows three typical queries on theV$SQL_WORKAREA dynamic view:

Example 7-7 Querying V$SQL_WORKAREA

The following query finds the top 10 work areas requiring most cache memory:

SELECT *
  FROM
     ( SELECT workarea_address, operation_type, policy, estimated_optimal_size
         FROM V$SQL_WORKAREA
        ORDER BY estimated_optimal_size )
 WHERE ROWNUM <= 10;

The following query finds the cursors with one or more work areas that have been executed in one or even multiple passes:

col sql_text format A80 wrap 
SELECT sql_text, sum(ONEPASS_EXECUTIONS) onepass_cnt,
       sum(MULTIPASSES_EXECUTIONS) mpass_cnt 
FROM V$SQL s, V$SQL_WORKAREA wa 
WHERE s.address = wa.address 
GROUP BY sql_text 
HAVING sum(ONEPASS_EXECUTIONS+MULTIPASSES_EXECUTIONS)>0;

Using the hash value and address of a particular cursor, the following query displays the cursor execution plan, including information about the associated work areas.

col "O/1/M" format a10
col name format a20
SELECT operation, options, object_name name,
       trunc(bytes/1024/1024) "input(MB)",
       trunc(last_memory_used/1024) last_mem,
       trunc(estimated_optimal_size/1024) optimal_mem, 
       trunc(estimated_onepass_size/1024) onepass_mem, 
       decode(optimal_executions, null, null, 
              optimal_executions||'/'||onepass_executions||'/'||
              multipasses_executions) "O/1/M"
  FROM V$SQL_PLAN p, V$SQL_WORKAREA w 
 WHERE p.address=w.address(+) 
   AND p.hash_value=w.hash_value(+) 
   AND p.id=w.operation_id(+) 
   AND p.address='88BB460C'
   AND p.hash_value=3738161960; 

OPERATION    OPTIONS  NAME     input(MB) LAST_MEM OPTIMAL_ME ONEPASS_ME O/1/M 
------------ -------- -------- --------- -------- ---------- ---------- ------
SELECT STATE                                                                  
HASH         GROUP BY               4582        8         16         16 16/0/0
HASH JOIN    SEMI                   4582     5976       5194       2187 16/0/0
TABLE ACCESS FULL     ORDERS          51                                      
TABLE ACCESS FUL      LINEITEM      1000                                      

You can get the address and hash value from the V$SQL view by specifying a pattern in the query. For example:

SELECT address, hash_value 
  FROM V$SQL 
WHERE sql_text LIKE '%my_pattern%';

 

调优pga_aggregate_targtet

oracle提供了两个视图来帮助调优pga_aggreate_target，v$pga_target_advice v$pga_target_advice_histogram 有了这两个视图你就不用凭经验区调优了.通过这2个视图 在你调整完该参数后就可以看到pga的关键指标是怎么被影响的了。

 

V$PGA_TARGET_ADVICE

This view predicts how the statistics cache hit percentage and over allocation count inV$PGASTAT will be impacted if you change the value of the initialization parameterPGA_AGGREGATE_TARGET. Example 7-8 shows a typical query of this view:

Example 7-8 Querying V$PGA_TARGET_ADVICE

SELECT round(PGA_TARGET_FOR_ESTIMATE/1024/1024) target_mb,
       ESTD_PGA_CACHE_HIT_PERCENTAGE cache_hit_perc,
       ESTD_OVERALLOC_COUNT
  FROM V$PGA_TARGET_ADVICE;

The output of this query might look like the following:

TARGET_MB CACHE_HIT_PERC ESTD_OVERALLOC_COUNT---------- -------------- -------------------- 63 23 367 125 24 30 250 30 3 375 39 0 500 58 0 600 59 0 700 59 0 800 60 0 900 60 0 1000 61 0 1500 67 0 2000 76 0 3000 83 0 4000 85 0

V$PGA_TARGET_ADVICE_HISTOGRAM

This view predicts how the statistics displayed by the performance view V$SQL_WORKAREA_HISTOGRAM will be impacted if you change the value of the initialization parameterPGA_AGGREGATE_TARGET. You can use the dynamic view V$PGA_TARGET_ADVICE_HISTOGRAM to view detailed information on the predicted number of optimal, one-pass and multi-pass work area executions for the set ofPGA_AGGREGATE_TARGET values you use for the prediction.

The V$PGA_TARGET_ADVICE_HISTOGRAM view is identical to the V$SQL_WORKAREA_HISTOGRAM view, with two additional columns to represent thePGA_AGGREGATE_TARGET values used for the prediction. Therefore, any query executed against theV$SQL_WORKAREA_HISTOGRAM view can be used on this view, with an additional predicate to select the desired value ofPGA_AGGREGATE_TARGET.

Example 7-9 Querying V$PGA_TARGET_ADVICE_HISTOGRAM

The following query displays the predicted content of V$SQL_WORKAREA_HISTOGRAM for a value of the initialization parameterPGA_AGGREGATE_TARGET set to twice its current value.

SELECT LOW_OPTIMAL_SIZE/1024 low_kb, (HIGH_OPTIMAL_SIZE+1)/1024 high_kb, 
       estd_optimal_executions estd_opt_cnt, 
       estd_onepass_executions estd_onepass_cnt, 
       estd_multipasses_executions estd_mpass_cnt 
  FROM v$pga_target_advice_histogram 
 WHERE pga_target_factor = 2 
   AND estd_total_executions != 0 
 ORDER BY 1; 

The output of this query might look like the following.

LOW_KB   HIGH_KB   ESTD_OPTIMAL_CNT   ESTD_ONEPASS_CNT   ESTD_MPASS_CNT
------   -------   ----------------   ----------------   --------------
     8        16             156107                  0                0
    16        32                148                  0                0
    32        64                 89                  0                0
    64       128                 13                  0                0
   128       256                 58                  0                0
   256       512                 10                  0                0
   512      1024                653                  0                0
  1024      2048                530                  0                0
  2048      4096                509                  0                0
  4096      8192                227                  0                0
  8192     16384                176                  0                0
 16384     32768                133                 16                0
 32768     65536                 66                103                0
 65536    131072                 15                 47                0
131072    262144                  0                 48                0
262144    524288                  0                 23                0

The output shows that increasing PGA_AGGREGATE_TARGET by a factor of 2 will allow all work areas under 16 MB to execute in optimal mode.

 

V$SYSSTAT and V$SESSTAT

The following query gives the total number and the percentage of times work areas were executed in these three modes since the instance was started:

SELECT name profile, cnt, decode(total, 0, 0, round(cnt*100/total)) percentage
    FROM (SELECT name, value cnt, (sum(value) over ()) total
    FROM V$SYSSTAT 
    WHERE name like 'workarea exec%');

The output of this query might look like the following:

PROFILE                                    CNT PERCENTAGE
----------------------------------- ---------- ----------
workarea executions - optimal             5395         95
workarea executions - onepass              284          5
workarea executions - multipass              0          0

关于one-pass multi-pass optimal-pass

A sort operator uses a work area (the sort area) to perform the in-memory sort of a set of rows. Similarly, a hash-join operator uses a work area (the hash area) to build a hash table from its left input.

The size of a work area can be controlled and tuned. Generally, bigger work areas can significantly improve the performance of a particular operator at the cost of higher memory consumption. Ideally, the size of a work area is big enough that it can accommodate the input data and auxiliary memory structures allocated by its associated SQL operator. This is known as the optimal size of a work area. When the size of the work area is smaller than optimal, the response time increases, because an extra pass is performed over part of the input data. This is known as the one-pass size of the work area. Under the one-pass threshold, when the size of a work area is far too small compared to the input data size, multiple passes over the input data are needed. This could dramatically increase the response time of the operator. This is known as the multi-pass size of the work area. For example, a serial sort operation that needs to sort 10GB of data needs a little more than 10GB to run optimal and at least 40MB to run one-pass. If this sort gets less that 40MB, then it must perform several passes over the input data.

The goal is to have most work areas running with an optimal size (for example, more than 90% or even 100% for pure OLTP systems), while a smaller fraction of them are running with a one-pass size (for example, less than 10%). Multi-pass execution should be avoided. Even for DSS systems running large sorts and hash-joins, the memory requirement for the one-pass executions is relatively small. A system configured with a reasonable amount of PGA memory should not need to perform multiple passes over the input data.