2012-10-17 11gR2 concepts page 293 - 326

今天，一开头，我想分享点想法。

如果我们能够把技术当作茶余饭后的乐趣，那我们在这条路就可以做得久。如果我们看书，看文档，不是为了学习而学习，而是觉得，它就是一种乐趣，那我们就会快乐。

 

 --  这又是一句会被现实主义者批判的话，因为他们永远不懂作为DBA，能够感受到的巨大的成就感与自豪感。

 

继续今天的CONCEPTS，今天很精彩，都想摘下来。

 

ADR Structure

 

Alert Log -- DBA每天都应该要看的东西
The alert log contents include the following:
 -- All internal errors (ORA-600), block corruption errors (ORA-1578), and deadlock
errors (ORA-60)
 -- Administrative operations such as DDL statements and the SQL*Plus commands
STARTUP, SHUTDOWN, ARCHIVE LOG, and RECOVER
 -- Several messages and errors relating to the functions of shared server and
dispatcher processes
 -- Errors during the automatic refresh of a materialized view

 

Locations of Trace Files
ADR stores trace files in the trace subdirectory, as shown in Figure 13–8. Trace file
names are platform-dependent and use the extension .trc.
Typically, database background process trace file names contain the Oracle SID, the
background process name, and the operating system process number. An example of a
trace file for the RECO process is mytest_reco_10355.trc.
Server process trace file names contain the Oracle SID, the string ora, and the
operating system process number. An example of a server process trace file name is
mytest_ora_10304.trc.
Sometimes trace files have corresponding trace map (.trm) files. These files contain
structural information about trace files and are used for searching and navigation. -- 我想讲下这个，经常能看到.trm后缀的文件，

其实它记录了TRACE FILE的结构信息。

Introduction to Oracle Database Memory Structures -- ORACLE的内存结构
The memory area stores information such as the following:
 -- Program code
 -- Information about each connected session, even if it is not currently active
 -- Information needed during program execution, for example, the current state of a
query from which rows are being fetched
 -- Information such as lock data that is shared and communicated among processes
 -- Cached data, such as data blocks and redo records, that also exists on disk

 

Contents of the PGA

 

Private SQL Area
A private SQL area holds information about a parsed SQL statement and other
session-specific information for processing. When a server process executes SQL or
PL/SQL code, the process uses the private SQL area to store bind variable values,
query execution state information, and query execution work areas.

A cursor is a name or handle to a specific private SQL area. As shown in Figure 14–5,
you can think of a cursor as a pointer on the client side and as a state on the server
side. Because cursors are closely associated with private SQL areas, the terms are
sometimes used interchangeably.

-- 游标，在PRIVATE SQL AREA里面类似一个指针。

 

A private SQL area is divided into the following areas:
 -- The run-time area
This area contains query execution state information. For example, the run-time
area tracks the number of rows retrieved so far in a full table scan.
Oracle Database creates the run-time area as the first step of an execute request.
For DML statements, the run-time area is freed when the SQL statement is closed.
 -- The persistent area
This area contains bind variable values. A bind variable value is supplied to a
SQL statement at run time when the statement is executed. The persistent area is
freed only when the cursor is closed.

The client process is responsible for managing private SQL areas. The allocation and
deallocation of private SQL areas depends largely on the application, although the
number of private SQL areas that a client process can allocate is limited by the
initialization parameter OPEN_CURSORS.

OPEN_CURSORS参数的作用。

 

SQL Work Areas
A work area is a private allocation of PGA memory used for memory-intensive
operations. For example, a sort operator uses the sort area to sort a set of rows.
Similarly, a hash join operator uses a hash area to build a hash table from its left
input, whereas a bitmap merge uses the bitmap merge area to merge data retrieves
from scans of multiple bitmap indexes.

 

If the amount of data to be processed by the operators does not fit into a work area,
then Oracle Database divides the input data into smaller pieces. In this way, the
database processes some data pieces in memory while writing the rest to temporary
disk storage for processing later. -- 如果内存不够，无法完全容纳排序的空间，它会IO一部分到临时表空间上。

 

PGA Usage in Dedicated and Shared Server Modes

 

Database Buffer Cache
Oracle Database uses the buffer cache to achieve the following goals:
 -- Optimize physical I/O
The database updates data blocks in the cache and stores metadata about the
changes in the redo log buffer. After a COMMIT, the database writes the redo
buffers to disk but does not immediately write data blocks to disk. Instead,
database writer (DBWn) performs lazy writes in the background.
 -- Keep frequently accessed blocks in the buffer cache and write infrequently
accessed blocks to disk
When Database Smart Flash Cache (flash cache) is enabled, part of the buffer
cache can reside in the flash cache. This buffer cache extension is stored on a flash
disk device, which is a solid state storage device that uses flash memory. The
database can improve performance by caching buffers in flash memory instead of
reading from magnetic disk.

 

Note: Database Smart Flash Cache is available only in Solaris and
Oracle Enterprise Linux.   --  FLASH CACHE

 

Buffer States  -- 在BUFFER池中几种块的状态
 -- Unused
The buffer is available for use because it has never been used or is currently
unused. This type of buffer is the easiest for the database to use.
 -- Clean
This buffer was used earlier and now contains a read-consistent version of a block
as of a point in time. The block contains data but is "clean" so it does not need to be
checkpointed. The database can pin the block and reuse it.
 -- Dirty
The buffer contain modified data that has not yet been written to disk. The
database must checkpoint the block before reusing it.

 

Every buffer has an access mode: pinned or free (unpinned). A buffer is "pinned" in
the cache so that it does not age out of memory while a user session accesses it.
Multiple sessions cannot modify a pinned buffer at the same time.
The database uses a sophisticated algorithm to make buffer access efficient. Pointers to
dirty and nondirty buffers exist on the same least recently used (LRU) list, which has
a hot end and cold end. A cold buffer is one that has not been recently used. A hot
buffer is frequently accessed and has been recently used.  --- LRU LIST “最近最少使用”的链表

Note: Conceptually, there is only one LRU, but for concurrency the
database actually uses several LRUs.

 

Buffer Modes -- 在一些性能报告上经常能看到以下两种块的读取状态
 -- Current mode -- db block get
A current mode get, also called a db block get, is a retrieval of a block as it
currently appears in the buffer cache. For example, if an uncommitted transaction
has updated two rows in a block, then a current mode get retrieves the block with
these uncommitted rows. The database uses db block gets most frequently during
modification statements, which must update only the current version of the block.
 -- Consistent mode -- consistent read get
A consistent read get is a retrieval of a read-consistent version of a block. This
retrieval may use undo data. For example, if an uncommitted transaction has
updated two rows in a block, and if a query in a separate session requests the
block, then the database uses undo data to create a read-consistent version of this
block (called a consistent read clone) that does not include the uncommitted
updates. Typically, a query retrieves blocks in consistent mode.

Buffer Writes -- BUFFER写
 -- A server process cannot find clean buffers for reading new blocks into the
database buffer cache.
As buffers are dirtied, the number of free buffers decreases. If the number drops
below an internal threshold, and if clean buffers are required, then server
processes signal DBWn to write.
The database uses the LRU to determine which dirty buffers to write. When dirty
buffers reach the cold end of the LRU, the database moves them off the LRU to a
write queue. DBWn writes buffers in the queue to disk, using multiblock writes if
possible. This mechanism prevents the end of the LRU from becoming clogged
with dirty buffers and allows clean buffers to be found for reuse.
 -- The database must advance the checkpoint, which is the position in the redo
thread from which instance recovery must begin.
 -- Tablespaces are changed to read-only status or taken offline.

 

Buffer Reads -- BUFFER读
 -- Flash cache disabled
The database re-uses each clean buffer as needed, overwriting it. If the overwritten
buffer is needed later, then the database must read it from magnetic disk.
 -- Flash cache enabled
DBWn can write the body of a clean buffer to the flash cache, enabling reuse of its
in-memory buffer. The database keeps the buffer header in an LRU list in main
memory to track the state and location of the buffer body in the flash cache. If this
buffer is needed later, then the database can read it from the flash cache instead of
from magnetic disk.

 

When a client process requests a buffer, the server process searches the buffer cache for
the buffer. A cache hit occurs if the database finds the buffer in memory. The search
order is as follows:
1. The server process searches for the whole buffer in the buffer cache.
If the process finds the whole buffer, then the database performs a logical read of
this buffer.
2. The server process searches for the buffer header in the flash cache LRU list.
If the process finds the buffer header, then the database performs an optimized
physical read of the buffer body from the flash cache into the in-memory cache.
3. If the process does not find the buffer in memory (a cache miss), then the server
process performs the following steps:
a. Copies the block from a data file into memory (a physical read)
b. Performs a logical read of the buffer that was read into memory

 

Buffer Touch Counts The database measures the frequency of access of buffers on the
LRU list using a touch count. This mechanism enables the database to increment a
counter when a buffer is pinned instead of constantly shuffling buffers on the LRU list.

 

When a buffer is pinned, the database determines when its touch count was last
incremented. If the count was incremented over three seconds ago, then the count is
incremented; otherwise, the count stays the same. The three-second rule prevents a
burst of pins on a buffer counting as many touches. For example, a session may insert
several rows in a data block, but the database considers these inserts as one touch.

 -- ORACLE也不傻，TOUCH COUNTS 它会去探测，要3S以上才会继续加一。

 

Buffers and Full Table Scans When buffers must be read from disk, the database inserts
the buffers into the middle of the LRU list. In this way, hot blocks can remain in the
cache so that they do not need to be read from disk again.

 

A problem is posed by a full table scan, which sequentially reads all rows under the
table high water mark (see "Segment Space and the High Water Mark" on page 12-27).
Suppose that the total size of the blocks in a table segment is greater than the size of
the buffer cache. A full scan of this table could clean out the buffer cache, preventing
the database from maintaining a cache of frequently accessed blocks.
Blocks read into the database cache as the result of a full scan of a large table are
treated differently from other types of reads. The blocks are immediately available for
reuse to prevent the scan from effectively cleaning out the buffer cache.

 

In the rare case where the default behavior is not desired, you can change the CACHE
attribute of the table. In this case, the database does not force or pin the blocks in the
buffer cache, but ages them out of the cache in the same way as any other block. Use
care when exercising this option because a full scan of a large table may clean most of
the other blocks out of the cache.

 

Shared 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.
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.

 

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.
 -- Private SQL area
Each session issuing a SQL statement has a private SQL area in its PGA (see
"Private SQL Area" on page 14-5). 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.

 

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.
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.
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.

 

Allocation and Reuse of Memory in the Shared Pool -- 共享池中的分配
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.
 -- If you change the global database name, then the database removes all information
from the shared pool.

Data Dictionary Cache -- 数据字典缓存
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.
 -- 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.

 

Large Pool -- 大池
The large pool is different from reserved space in the shared pool, which uses the same
LRU list as other memory allocated from the shared pool. The large pool does not have
an LRU list. Pieces of memory are allocated and cannot be freed until they are done
being used. As soon as a chunk of memory is freed, other processes can use it. -- important

Streams Pool -- 流池
The Streams pool stores buffered queue messages and provides memory for Oracle
Streams capture processes and apply processes. The Streams pool is used exclusively
by Oracle Streams.

 

Fixed SGA -- SGA区中固定的区域
The fixed SGA is an internal housekeeping area. For example, the fixed SGA contains:
 -- General information about the state of the database and the instance, which the
background processes need to access
 -- Information communicated between processes, such as information about locks
(see "Overview of Automatic Locks" on page 9-17)
The size of the fixed SGA is set by Oracle Database and cannot be altered manually.
The fixed SGA size can change from release to release.