sharepool_使用

共享池使用问题

SGA 中的另外一个重要结构是共享池。共享池存储了应用执行需要的PL/SQL块结构，SQL语句的文本、SQL编译后的可
执行代码、系统数据字典等。
    恰当的共享池尺寸设置将减少系统各种资源的使用。首先，对于SQL、PL/SQL 来说，共享池提供了运行状态下的临时
存储点，后续执行的SQL和PL/SQL将使用已被缓存的编译结果及执行计划，有效减少系统CPU的使用，减少用户调用事件。
第二，栓、锁资源的争用被环节。第三，数据字典信息将被缓存在共享池中，因此，有关系统的信息不必再去执行查询，
这就降低了资源的使用。

 

 

  在库缓存中区域中，存储着SQL、PL/SQL、Java类的源码、执行计划、伪编译后可执行代码等。当应用程序运行时，这些代码会被调用。如果这些代码在前面不久的应用运行中已经被调用执行过，则可能被后续执行的应用程序共享。默认地，Oracle将试图重复使用现有的代码，实现重用。也就是说，后续应用的执行能够引用前期应用执行中编译过的代码，这称为库缓存的“命中”。一次命中意味着一次
如软解析，SQL、PL/SQL的硬解析及编译过程的资源开销将被避免。

 

   假设后续应用在执行中不能通过库缓存实现“软解析”，Oracle 不得不为SQL、PL/SQL 进行语法解析、执行计划分析和编译，以及
应用代码可执行版本的创建。这个过程称为“硬解析”，硬解析需要整个系统付出额外的CPU时间片、库缓存栓资源等。

   从性能上看，我们当然希望能尽可能地实现软解析，减少硬解析。做到这一点需要进行两方面的准备工作：能够重用的SQL和PL/SQL、足够尺寸的共享池。

 

SQL与PL/SQL重用
   当用户想Oracle 发出SQL、PL/SQL请求时，Oracle将首先确定这些SQL语句、PL/SQL块是否可以在共享池中找到相同的
语句，过程如下:
   1>根据要执行的语句文本，和共享池中现有语句文本进行比较
   2>如果共享池中没有找到相同的语句，说明SQL语句在共享池中不存在，开始执行硬解析操作。
   3>如果找到匹配的语句，Oracle 继续把匹配语句的正文和缓存池中的SQL正文进行严格比较，包括空格、大小写、注释等。
例如下面两条语句就是不同的，虽然只是多了一个空格、大小写有些不一致。
   SELECT name FROM Mytable;
   SELECT  name FROM mytable;
Oracle在比较语句时，除了比较SQL、PL/SQL文本，也会比较其引用对象。假设两条语句的文本完全一致，但对象属主是另外
的模式，则Oracle也认为该语句是不同的。

 

1>实现游标共享
  在可能的情况下使用绑定变量来替换SQL中的常量。例如，下面两个SQL语句来自不同的两个用户：
  SELECT name FROM mytable WHERE id= 1;
  SELECT name FROM mytable WHERE id= 2;
 从Oracle的角度看，这两个SQL语句是不同的，因为文本不同。下面的语句解决了这个问题
  SELECT name FROM mytable WHERE  :v_id= 1;

在上面的语句中，变量v_id 替换了文本，在运行时进行变量赋值即可。要做到这一点，开发中必须遵守如下的共识：首先项目中的程序员应采用相同的编程规范，其次程序中尽量避免使用动态SQL。最后，尽量使用存储过程、函数或者包、包体。

2>避免执行DDL语句
避免在系统高峰时段执行表的DDL操作，因为这会导致依赖于表、索引的SQL必须做硬解析---他们所依赖的对象结构发生了改变。

3>将序列驻留在缓存中
对于系统中经常使用的序列对象，DBA 最好给他赋予足够的缓存，这会减少数据字典栓（资源锁）的使用频率。因此在CREATE
SEQUENCE 或 ALTER SEQUENCE 中加上Cache 关键词，可以使序列对象长驻缓存。示例如下:
SQL>CREATE SEQUENCE SCOTT.MY_SEQ1 CYCLE ORDER CACHE 20 MAXVALUE 20000 MINVALUE 1 INCREMENT BY 1 START WITH 1;

 

||||||||||||||

Shared Pool Concepts
共享池概念

The main components of the shared pool are the library cache and the dictionary
cache. The library cache stores the executable (parsed or compiled) form of recently
referenced SQL and PL/SQL code. The dictionary cache stores data referenced from
the data dictionary.

共享池的主要组件有library cache和dictionary cache。library cache 储存了最近的SQL
/PLSQL代码的可执行模式（解析或编译版本）。

 Many of the caches in the shared pool automatically increase or decrease in size,
 as needed, including the library cache and the dictionary cache. Old entries are aged
 out of these caches to accommodate new entries when the shared pool does not have
 free space.

share pool中的cache 将根据需要自动增长或减少，包括里面的library cache和dictionary cache。
老的条目信息从内存中过时并清除，如果没有空闲的空间，空出的空间将存储新的条目。

A cache miss on the data dictionary cache or library cache is more expensive than a
miss on the buffer cache. For this reason, the shared pool should be sized to ensure
that frequently used data is cached.

在data dictionary 或 library cache 中的丢失比buffer cache中的丢失造成的性能损坏更严重。
因为这个原因，共享池应该被调整大小，保证经常用的数据会被存入。

A number of features make large memory allocations in the shared pool: for example,
the shared server, parallel query, or Recovery Manager. Oracle recommends
segregating the SGA memory used by these features by configuring a distinct memory
area, called the large pool.

一系列的现象将导致share pool中的大的内存分配：比如说，共享服务进程，
并行查询，recovery manager.Oracle 建议隔离被这些选项使用的SGA内存，
这个可以通过建立一个独立的内存区域来实现，这个内存区域叫做large pool.

Allocation of memory from the shared pool is performed in chunks. This allows large
objects (over 5k) to be loaded into the cache without requiring a single contiguous
area, hence reducing the possibility of running out of enough contiguous memory due
to fragmentation.
从共享池中分配的内存是以块状来分配的。这种方式可以允许大的对象（超过5K)的
对象被加入cache 而无需要求一个单独的连续空间，这样可以减少因为内存碎片
找不到足够的连续内存的几率。

 

Infrequently, Java, PL/SQL, or SQL cursors may make allocations out of the shared
pool that are larger than 5k. To allow these allocations to occur most efficiently, Oracle
segregates a small amount of the shared pool. This memory is used if the shared pool
does not have enough space. The segregated area of the shared pool is called the
reserved pool.

不是很频繁的，JAVA,PL/SQL或者SQL 游标可能会从共享池中分配大于5K的空间。
让这些分配尽量的发生，Oracle 从share pool中分配出一小部分。
如果共享池没有足够的空间，这块内存将被使用。这块内存将被使用，如果共享
池中没有足够的空间。这块单独分配出来的共享池叫做保留池。

Dictionary Cache Concepts
Information stored in the data dictionary cache includes usernames, segment
information, profile data, tablespace information, and sequence numbers. The
dictionary cache also stores descriptive information, or metadata, about schema
objects. Oracle uses this metadata when parsing SQL cursors or during the
compilation of PL/SQL programs

dictionary cache 概念
储存在数据字典cache中的信息包括用户名，段信息，数据信息，表空间信息以及序列号。
dictionary cache也储存有描述性信息，或者关于方案对象的源信息。
在对PL/SQL程序编译SQL游标的时候，ORACLE将使用这个原信息。

Library Cache Concepts
The library cache holds executable forms of SQL cursors, PL/SQL programs, and Java
classes. This section focuses on tuning as it relates to cursors, PL/SQL programs, and
Java classes. These are collectively referred to as application code.
When application code is run, Oracle attempts to reuse existing code if it has been
executed previously and can be shared. If the parsed representation of the statement
does exist in the library cache and it can be shared, then Oracle reuses the existing
code. This is known as a soft parse, or a library cache hit. If Oracle is unable to use
existing code, then a new executable version of the application code must be built.

library cache 概念
Library cache 包含有SQL游标的可执行模式，PL/SQL 程序，以及JAVA类。
这个部分将关注 libarary cache 中游标，PL/SQL程序以及JAVA类调优的概念。
这些脚本都被称为应用脚本。当运行应用程序脚本的时候，如果这个脚本曾经
被执行过并可以被共享，oracle将尝试重用此代码。 这就叫做软解析，或者library cache hit.
如果Oracle 不能够使用已存在的代码，那么应用程序的新的可执行版本必须被构建。

This is known as a hard parse, or a library cache miss. See "SQL Sharing Criteria" on
page 7-17 for details on when a SQL and PL/SQL statements can be shared.

这个就叫做硬解析，或者library cache miss。 查看 7-17页的“sql 共享准则”，了解
SQL 和PL/SQL语句可以被共享的原则。

Library cache misses can occur on either the parse step or the execute step when
processing a SQL statement. When an application makes a parse call for a SQL
statement, if the parsed representation of the statement does not already exist in the
library cache, then Oracle parses the statement and stores the parsed form in the
shared pool.

library cache misses 可以在处理SQL语句时，在parse 或者 execute 这个步骤发生.
当应用程序对SQL语句做一个解析要求，如果被解析的语句不再library cache中，
那么oracle将解析这个语句，并把它储存在共享池中。

This is a hard parse. You might be able to reduce library cache misses on
parse calls by ensuring that all shareable SQL statements are in the shared pool
whenever possible。

这个就叫做硬解析。你可以用这种方法来减少 library cache miss ，劲量让可共享的
SQL语句存储在shared pool中。

If an application makes an execute call for a SQL statement, and if the executable
portion of the previously built SQL statement has been aged out (that is, deallocated)
from the library cache to make room for another statement, then Oracle implicitly
reparses the statement, creating a new shared SQL area for it, and executes it. This also
results in a hard parse. Usually, you can reduce library cache misses on execution calls
by allocating more memory to the library cache.

如果一个应用程序对一个SQL语句做执行的请求，如果之前sql语句的可执行部分以及
过期了（即已经被重新分配了），oracle将隐式的重新分析这个语句，执行一个新的
SQL 共享区，并重新执行这个语句。这也导致一个硬解析。一般来说，你可以通过
分配更多的内存给libarary cache来减少 library cache misses.

 

In order to perform a hard parse, Oracle uses more resources than during a soft parse.
Resources used for a soft parse include CPU and library cache latch gets. Resources
required for a hard parse include additional CPU, library cache latch gets, and shared
pool latch gets. See "SQL Execution Efficiency" on page 2-13 for a discussion of hard
and soft parsing.

为了执行一个硬解析，oracle比使用软解析使用更多的资源。针对软解析的资源包括
CPU和library cache闩锁。而硬解析需要的资源包括额外的CPU，library cache 闩锁获取，
share pool 闩锁。查看2-13页的“SQL 执行效率”来讨论硬解析和软解析。