SGA--Redo Log Buffer & Shared Pool

Redo Log Buffer
The redo log buffer is a circular buffer in the SGA that stores redo entries describing changes made to the database. Redo entries contain the information necessary to reconstruct, or redo, changes made to the database by DML or DDL operations. Database recovery applies redo entries to data files to reconstruct lost changes.

Oracle Database processes copy redo entries from the user memory space to the redo log buffer in the SGA. The redo entries take up continuous, sequential space in the buffer. The background process log writer (LGWR) writes the redo log buffer to the active online redo log group on disk. 
--Oracle进程把用户内存区的redo条目复制到SGA中的redo log buffer里。Redo条目占用连续的，顺序的空间。

LGWR writes redo sequentially to disk while DBWn performs scattered writes of data blocks to disk. Scattered writes tend to be much slower than sequential writes. Because LGWR enable users to avoid waiting for DBWn to complete its slow writes, the database delivers better performance.
--LGWR避免用户等待DBWn完成它的slow writes，这样数据库性能表现更好。

The LOG_BUFFER initialization parameter specifies the amount of memory that Oracle Database uses when buffering redo entries. Unlike other SGA components, the redo log buffer and fixed SGA buffer do not divide memory into granules.
--与SGA其它组件不同，redo log buffer和fixed SGA buffer不把内存分成一个个的粒组。

Shared PoolThe shared pool caches various types of program data. For example, the shared pool stores parsed SQL, PL/SQL code, system parameters, and data dictionary information. The shared pool is involved in almost every operation that occurs in the database. For example, if a user executes a SQL statement, then Oracle Database accesses the shared pool.--共享池存各种程序数据，例如解析的SQL，PL/SQL代码，系统参数，数据字典信息。共享池几乎参与了数据库中的任何一个操作。

The shared pool is divided into several subcomponents, the most important of which are shown below.

--下面逐个讲解内部组件
Library Cache
Data Dictionary Cache
Server Result Cache
Reserved Pool
Library Cache
The library cache is a shared pool memory structure that stores executable SQL and PL/SQL code. This cache contains the shared SQL and PL/SQL areas and control structures such as locks and library cache handles. In a shared server architecture, the library cache also contains private SQL areas.
--简单来说，library cache就是存储SQL，PL/SQL。里面包含共享SQL，PL/SQL区，控制结构，比如锁和库缓存句柄。在共享服务器架构下，library cache也包含似有SQL区。

When a SQL statement is executed, the database attempts to reuse previously executed code. If a parsed representation of a SQL statement exists in the library cache and can be shared, then the database reuses the code, known as a soft parse or a library cache hit. Otherwise, the database must build a new executable version of the application code, known as a hard parse or a library cache miss.
--简单说了软硬解析。区别就是在library cache是否有之前解析过的SQL语句。
Shared SQL Areas
The database represents each SQL statement that it runs in the following SQL areas:

Shared SQL area
The database uses the shared SQL area to process the first occurrence of a SQL statement. This area is accessible to all users and contains the statement parse tree and execution plan. Only one shared SQL area exists for a unique statement.
数据库使用共享SQL区来执行第一次出现的SQL语句。所有的用户都可以访问这个区域，里面包含语句解析树和执行计划。对与每个唯一的语句只有一个共享SQL区。

Private SQL area
Each session issuing a SQL statement has a private SQL area in its PGA. Each user that submits the same statement has a private SQL area pointing to the same shared SQL area. Thus, many private SQL areas in separate PGAs can be associated with the same shared SQL area.
--每个发布SQL语句的会话在自己的PGA中都有一个私有SQL区。每个提交相同语句的用户都有一个指向相同的共享SQL区的私有SQL区。

The database automatically determines when applications submit similar SQL statements. The database considers both SQL statements issued directly by users and applications and recursive SQL statements issued internally by other statements.
--数据库会同时考虑用户和应用直接发布的SQL和其它语句在内部发布的递归SQL

The database performs the following steps:
1.Checks the shared pool to see if a shared SQL area exists for a syntactically and semantically identical statement:
a.If an identical statement exists, then the database uses the shared SQL area for the execution of the subsequent new instances of the statement, thereby reducing memory consumption.
b.If an identical statement does not exist, then the database allocates a new shared SQL area in the shared pool. A statement with the same syntax but different semantics uses a child cursor.
In either case, the private SQL area for the user points to the shared SQL area that contains the statement and execution plan.
--1.先看共享SQL区是否存在着语法，语义上相同的语句。然后再判断，如果存在相同的，就使用它的执行计划，减少内存消耗；如果不存在，就从共享池中分配一个新的共享SQL区。让那些语法相同，但是语义不同的语句使用子游标

2.Allocates a private SQL area on behalf of the session
The location of the private SQL area depends on the connection established for the session. If a session is connected through a shared server, then part of the private SQL area is kept in the SGA.
--私有SQL区的位置取决于会话所建立的连接。如果是共享服务器，则私有SQL区会放到SGA中。

The following figure shows a dedicated server architecture in which two sessions keep a copy of the same SQL statement in their own PGAs. In a shared server, this copy is in the UGA, which is in the large pool or in the shared pool when no large pool exists.

Program Units and the Library Cache

The library cache holds executable forms of PL/SQL programs and Java classes. These items are collectively referred to as program units.
--可执行的PL/SQL程序和Java类统称为程序单元，它们都存在与library cache中。

The database processes program units similarly to SQL statements. For example, the database allocates a shared area to hold the parsed, compiled form of a PL/SQL program. The database allocates a private area to hold values specific to the session that runs the program, including local, global, and package variables, and buffers for executing SQL. If multiple users run the same program, then each user maintains a separate copy of his or her private SQL area, which holds session-specific values, and accesses a single shared SQL area.
--数据库处理程序单元的方式与SQL语句类似。比方数据库会分配共享区来存储解析的，编译的PL/SQL，分配私有区来存储变量。如果多个用户运行相同的程序，那么每个用户都会维护一个自己的私有SQL区的独立的副本，用来存储会话变量，访问单独的共享SQL区。

The database processes individual SQL statements within a PL/SQL program unit as previously described. Despite their origins within a PL/SQL program unit, these SQL statements use a shared area to hold their parsed representations and a private area for each session that runs the statement.
--这段话不知所谓。但是，可以这样说，在PL/SQL程序单元里的SQL也使用共享区存解析的内容，运行语句的每个会话使用私有区。
Allocation and Reuse of Memory in the Shared Pool
当解析一条新的SQL语句时，数据库从共享池中分配一块儿内存，大小由SQL的复杂程度决定。一般来说，除非数据库根据LRU算法把把SQL移出共享池，否则它就一直待在那里。只要这些条目有用，即使生成它们的进程结束了，它们仍然待在内存中供别的会话使用。这种机制使得处理SQL的耗费最小化。
如果新条目要求使用空间，数据库就会释放不常用的条目所占用的内存。如果共享SQL区corresponds to an open cursor，但是这个游标有段时间没被使用了，那么数据库也会把这个共享SQL区移出共享池。若这个游标接下来要被使用，那么数据库就会重新解析SQL，分配共享区。

The database also removes a shared SQL area from the shared pool in the following circumstances:
If statistics are gathered for a table, table cluster, or index, then by default the database gradually removes all shared SQL areas that contain statements referencing the analyzed object after a period of time. The next time a removed statement is run, the database parses it in a new shared SQL area to reflect the new statistics for the schema object.
If a schema object is referenced in a SQL statement, and if this object is later modified by a DDL statement, then the database invalidates the shared SQL area. The optimizer must reparse the statement the next time it is run.
--如果一个SQL用到了一个schema对象，但是后来这个对象被DDL语句修改，那么分配的shared SQL area就会失效，下次运行时候就必须reparse the statement。

If you change the global database name, then the database removes all information from the shared pool.
--这个有意思，一旦你把数据库的global name改了，那么数据库就会把shard pool中所有信息移出。

You can use the ALTER SYSTEM FLUSH SHARED_POOL statement to manually remove all information in the shared pool to assess the performance that can be expected after an instance restart.
Data Dictionary Cache
The data dictionary is a collection of database tables and views containing reference information about the database, its structures, and its users. Oracle Database accesses the data dictionary frequently during SQL statement parsing.

The data dictionary is accessed so often by Oracle Database that the following special memory locations are designated to hold dictionary data:
Data dictionary cache

This cache holds information about database objects. The cache is also known as the row cache because it holds data as rows instead of buffers.
--data dictionary cache也叫row cache，因为它以rows的形式存储数据而不是buffers
Library cache

All server processes share these caches for access to data dictionary information.
Server Result Cache
Unlike the buffer pools, the server result cache holds result sets and not data blocks. The server result cache contains the SQL query result cache and PL/SQL function result cache, which share the same infrastructure.

A client result cache differs from the server result cache. A client cache is configured at the application level and is located in client memory, not in database memory.

SQL Query Result Cache
The database can store the results of queries and query fragments in the SQL query result cache, using the cached results for future queries and query fragments. Most applications benefit from this performance improvement.

For example, suppose an application runs the same SELECT statement repeatedly. If the results are cached, then the database returns them immediately. In this way, the database avoids the expensive operation of rereading blocks and recomputing results. 

The database automatically invalidates a cached result whenever a transaction modifies the data or metadata of database objects used to construct that cached result.
Users can annotate a query or query fragment with a RESULT_CACHE hint to indicate that the database should store results in the SQL query result cache. TheRESULT_CACHE_MODE initialization parameter determines whether the SQL query result cache is used for all queries (when possible) or only for annotated queries.
PL/SQL Function Result Cache

The PL/SQL function result cache stores function result sets. Without caching, 1000 calls of a function at 1 second per call would take 1000 seconds. With caching, 1000 function calls with the same inputs could take 1 second total. Good candidates for result caching are frequently invoked functions that depend on relatively static data.

PL/SQL function code can include a request to cache its results. Upon invocation of this function, the system checks the cache. If the cache contains the result from a previous function call with the same parameter values, then the system returns the cached result to the invoker and does not reexecute the function body. If the cache does not contain the result, then the system executes the function body and adds the result (for these parameter values) to the cache before returning control to the invoker.

You can specify the database objects that are used to compute a cached result so that if any of them are updated, the cached result becomes invalid and must be recomputed.

The cache can accumulate many results—one result for every unique combination of parameter values with which each result-cached function was invoked. If the database needs more memory, then it ages out one or more cached results.

--上面写了很多东西，整理一下

--这个功能很强大，有很多好处，上面的那几段都有说明，此处不再赘述