Description of the internal mechanism of Oracle Library cache

1. Library Cache description

LibraryCache is a component of the Shared pool in Oracle SGA. For details about Shared Pool, refer to this article:

Oracle Shared pool details

Here we will focus on a management mechanism of Library Cache. I have reviewed the following two articles:

Librarycache internal mechanism details

Storage location of the Execution Plan in Oracle

1. Description of Library Cache in DSI:

(1) An area in the shared pool thatmanages information about:

-- Sharedcursors (SQL and PL/SQL objects)

-- Databaseobjects (tables, indexes, and so on)

(2) Initially created to manage PL/SQLprograms and library units, therefore called library cache

(3) Scope was extended to includeshared cursors and information about other RDBMS objects.

 

2. Library Cache Objects

(1) The units of information that arestored in the library cache are called objects.

(2) There are two classes of objects:

1) Stored objects

-- Created and dropped withexplicit SQL or PL/SQL commands

Examples: Tables, views, packages, functions

2) Transient objects

-- Created at execution time and liveonly for the duration of the instance (or aged out)

Example: Shared and nonsharedcursors

 

3. Shared Cursors

(1) In-memory representation of anexecutable object:

SQLstatements

AnonymousPL/SQL block

PL/SQLstored procedures or functions

Javastored procedures

ObjectMethods

(2) Represented by two or more objects:

Aparent cursor that has a name

Oneor more child cursors containing the execution plan

 

4. Library Cache Architecture

(1) The library cache is a hash tablethat is accessible through an array of hash buckets.

(2) The library cache manager (KGL) controls the access and usage of library cache objects.

(3) Memory for the library cache isallocated from the shared pool.

5. Library cache needs to solve three problems:

(1). Fast locating: There are many objects in the Library cache. How can Oracle manage these objects so that service processes can quickly find the information they need. For example, a service process needs to quickly locate whether an SQL statement exists in Librarycache.

(2) relational dependency: objects in the Library cache have complex dependencies. When an objec becomes invalid, the dependent objects can be quickly invalidated. For example, if the structure of a table changes, the SQL statements that depend on the table need to be parsed again.

(3 ). concurrency Control: the Library cache must have a concurrency control mechanism, such as the lock mechanism, to manage concurrent access and modification of a large number of shared objects, for example, when a SQL statement is re-compiled, its dependent objects cannot be modified.

Oracle uses the hash table structure to solve the problem of fast locating in library cache. hash table is an array composed of many hash buckets. First, check several related images in DSI 405:

 

 

LibraryCache saves explicitSQL, PL/SQLcommands, shared, and nonshared cursors. These objects are stored in the Hash table, which is composed of Hash buckets. The Hash Bucket is composed of some Object Handle lists. Therefore, to search for an Object in the Hash Bucket, you can search for the Handle List.

6. Object Handle

We can see the information saved by the Object handle. Library cache handle points to library cache object (LCO, heap 0), which contains the library object Name, namespace, timestamp, reference list, lock Object and pin object list information.

For more information about Namespace, see Oracle Namespace description.

Therefore, access to all objects in the Library cache is implemented by using the library cache handle. That is to say, to access the library cache object, we must first find the library cache handle.

Because the Object handle stores the lock and pin information, that is, to record which user has the lock on the handle, or which user is waiting to get the lock. So here we also know that library cache lock occurs on handle.

When a process requests the library cache object, librarycache manager applies a hash algorithm to obtain a hash value, which is searched in the corresponding hash bucket based on the corresponding hash value.

If the library cache object is in the memory, the library cache handle will be found. Sometimes, when the shared pool is not large enough, the library cache handle will be stored in the memory. However, the library cache heap is out due to insufficient memory. In this case, the requested object heap will be overloaded. In the worst case, the library cache handle is not found in the memory. In this case, a new library cachehandle must be allocated and the object heap will be loaded into the memory.

7. Library Cache Object (LCO: Heap 0)

Its structure information is as follows. This figure must be carefully understood.

 

 

DSI description:

(1) Internally, most of the objectidentity is represented by structures of type kglob.

(2) These are thestructures stored in heap 0.

(3) Object structures have thefollowing components:

Type

Name

Flags

Tables

Datablocks

LibraryCache stores SQL or shared cursors. This information is saved through the LCO Heap 0.

1 2 3 Next Page