Principle of GES/GCS of RAC (3)

Lock types
Every lock has a type, which is a two character alphabetic identifier (e. g, BL, Cu, Se, Nb). The number of lock types
Varies with each release. Some lock types are only used in RDBMS instances, others in ASM instances, and the reminder
Are used in both.
Each lock has a type, which is a two-letter identifier (E. g BL, Cu, Se, Nb ). the number of lock types varies with the database version. Some types of locks are only used in RDBMS instances, some are in ASM instances, and the rest are in both instances.

Each lock type has two parameters, which are called tags. Each tag value is a 32-bit number. The tag values differ
According to the lock type, but the name and the two tag values form a unique identifier for the lock. For example,
For a library cache object LB lock, the parameters represent a portion of the hash value for the object, which is
Derived from the object name. On the other hand, for a TM lock, the first parameter contains the object number, and
Second parameter describes whether the object is a table or a partition.

Each lock type has two parameters called tags. Each tag value is a 32-bit number. Tag values vary depending on the lock type. Their formats are generally as follows. The names and values of the two tags form a unique identifier of the lock type. For example, for a library cache object LB lock, this parameter represents part of the object hash value, which is derived from the object name. On the other hand, for a tmlock, the first parameter contains the object number, and the second parameter indicates whether the object is a table or a partition.

In Oracle 10.1 and above, the V $ lock_type dynamic performance view summarizes all implemented lock types.
In Oracle 10.1 and later versions, the V $ lock_type dynamic view summarizes all the current lock types.
Some lock types, for example, the Tx transaction lock and the Cu cursor lock, only affect the local instance;
Therefore, they can be managed locally. Other lock types, such as the TM table lock and the All library cache locks
And pins, must be observed by all instances in the database; therefore, they must be managed globally.

Some lock types, such as TX transaction locks and Cu cursor locks, only affect local instances. Therefore, they can be managed locally. Other lock types, such as TM table locks and all library cache locks and pins, must be observed by all instances in the database. Therefore, they must be managed globally.

The most common lock types seen in a RAC database are listed in table 22-1.
Common lock types
Type description
BL block (GCS)
Cu cursor lock
HW high water mark lock
L * library cache lock
N * library cache pin
Q * dictionary cache lock
Sq sequence Cache
TM table lock
TS temporary segment
TT tablespace lock (for DDL)
TX transaction lock

Library cache locks

Each RAC instance has its own library cache. The library cache contains all statemets ad packages currently in use
The instance. In addition, the library cache contains all objects that are referenced by these statements and packages.
Each instance under RAC has its own library cache. Library cache contains all packages and statements used by the current instance. In addition, the library cache contains all objects referenced by these statements and packages.

When a DML or DDL statement is parsed, all database objects that are referenced by that statement are locked using a library
Cache lock for the duration of the parse call. These objects include tables, indexes, views, packages, procedures, and functions.
Referenced objects are also locked in the library Cache during the compliation of all PL/SQL packages and Java classes.
When a DML or DDL operation is parsed, all referenced database objects are locked and the library cache lock is used to guide the analysis of this statement, this lock will be released. These objects include tables, indexes, views, packages, stored procedures, and functions. The referenced objects are also locked in the library cache when PL/SQL and Java classes are compiled.

When a statement is executed, all referenced objects are locked briefly to allow them to be pinned. objects are pinned
During statement execution to prevent modification of them by other processes, such as those executing DDL statements.
When a statement is executed, all objects involved in it will be quickly locked and allowed to be read by pin operations. During the execution of this statement, these objects are pinned,
Prevent access by other processes, such as execution of DDL statements.

Namespaces
Every objects in the library cache belongs to a namespace. The number of namespaces is release dependent; in Oracle 10.2
There can be a maximum of 64, although not all are used in that release.
Each object in the library cache belongs to a namespace. The number of namespaces is based on the version. in Oracle 10.2, there can be a maximum of 64 namespaces, although not all namespaces are used.
Within a namespace, each object name must be unique. For example, one of the namespaces is called tabl/prcd/type, which
Ensures that no table, procedure, or user-defined type can have the same name.
In a namespace, each object must be unique. For example, a namespace is named tabl/prcd/type, which ensures that the table, stored procedure, and user-defined type cannot have the same name.

The namespace for each object is externalized as a number in the kglhdnsp column of the x $ kglob family of views.
You can obtain limited statistics for objects in the library cache, such as the number of gets and pins from
V $ librarycache view. Note, however, that this view returns only a subset of namespaces from the x $ kglst base view.
The namespace corresponds to a number in the kglhdnsp column in the x $ kglob family view. You can obtain limited information about objects in the library cache, such
The number of gets and pins in the V $ librarycache view. Note that this view only returns the subset of the basic view of namespace x $ kglst.
Prior to Oracle10g, you cocould also identify the namespace for each object from a libary Cache dump as follows:
SQL> alter session set events 'immediate trace name library_cache level 8 ';

In this dump, each object in the library cache has a namespace attribute. unfortunantely in Oracle 10.1 and 10.2,
This attribute has become confused with the object type, which is externalized as kglobtyp in the x $ kglob
Family of views. Although the namespace attribute is incorrect in the dump. You can still determine the true
Namespace by inspecting the instance lock types for the library cache locks and pins as described later in
This section.
In this dump, each object in the library cache has a namespace attribute. Unfortunately, in Oracle 10.1 and 10.2, this attribute is confusing with the object type, which can be found in the kglobtyp column of the x $ kglst family view. Although the namespace attribute in the dump file is incorrect, you can still view the instance lock type to determine the real namespace, this section describes these instance locks (for library cache locks and pins ).

Hash values
Every object in the library cache has a hash value. This is derived from a combination of the namespace and
Name. In the case of stored objects, such as tables, the name is derived from the owner name, Object Name, and
Optionally, a remote link. In the case of transient objects, such as SQL statements, the name is derived from
The text of the SQL statement.
Each object in the library cache has a hash value. This value is obtained from the namespace and Object Name set. For a stored object, such as a table,
Its hash name is obtained from the object owner name, Object Name, and optional remote link name. For a temporary object, such as an SQL statement, its hash name is
SQL statement text.

Prior to Oracle 10.1, the hash value was represented by a 32-bit number, which is still calculated and
Externalized in the kglnahsh column of x $ kglob. This 32-bit hash value was sufficient for most purposes,
But cocould, on occasion, lead to collisions. Therefor, in Oracle 10.1 and above, a new hash value is calculated
Using a 128-bit value, which more or less guarantees uniqueness. This new value is externalized in
Kglnahsv column of x $ kglob.

Before Version 10.1, the hash value is a 32-bit number, which is expressed in the kglnahsh column in the x $ kglob view after calculation. In most cases, the 32-bit hash value is sufficient for most cases. However, in some cases, conflicts may occur. Therefore, in Oracle 10.1 and later versions, a 128-bit value is used, which guarantees more or less uniqueness. The new value can be obtained by viewing the kglnahsv column of x $ kglob.