|Oracle9i Real Application Clusters Concepts
Release 2 (9.2)
Part Number A96597-01
This appendix describes configuring locks to cover multiple blocks. Refer to this appendix only for a limited set of rare circumstances to override Oracle Real Application Clusters' default resource control scheme as performed by the Global Cache Service (GCS) and the Global Enqueue Service (GES). Overriding Cache Fusion to use locks is only desirable in rare cases. Topics in this appendix include:
The methodology described in this appendix has been superseded by Cache Fusion in Real Application Clusters. Overriding Cache Fusion to perform lock setting is only desirable in Real Application Clusters installations that have a large number of read-mostly blocks.
Locks can manage one or more blocks of any class: data blocks, undo blocks, segment headers, and so on. The amount of cross-instance activity, such as read/write or write/write operations, and the corresponding performance of Real Application Clusters, is evaluated in terms of forced writes. If you override Cache Fusion, then a forced write can occur when one instance requests a block that is held by another instance: Oracle writes the block to disk so the requesting instance can read it in its most current state.
Oracle9i Real Application Clusters Deployment and Performance for detailed information about allocating locks
There are two levels of lock granularity: 1:1 locks, which is the default, and 1:n locks. 1:n locks implies that a lock manages two or more data blocks as defined by the value for n. With 1:n locks, a few locks can manage many blocks and thus reduce lock operations. For read-only data, 1:n locks can perform faster than 1:1 locks during certain operations such as parallel execution. The
GC_FILES_TO_LOCKS parameter is only useful to get 1:n lock granularity.
The number of locks assigned to datafiles and the number of data blocks in those datafiles determines the number of data blocks managed by a single lock.
When you set the
GC_FILES_TO_LOCKS parameter for a file, then the number of blocks for each lock can be expressed as shown in Figure B-1 for each file level. This example assumes values of
If the size of each file, in blocks, is a multiple of the number of locks assigned to it, then each 1:n lock manages exactly the number of data blocks given by the equation.
If the file size is not a multiple of the number of locks, then the number of data blocks for each 1:n lock can vary by one for that datafile. For example, if you assign 400 locks to a datafile that contains 2,500 data blocks, then 100 locks manage 7 data blocks each and 300 locks manage 6 blocks. Any datafiles not specified in the
GC_FILES_TO_LOCKS initialization parameter use the remaining locks.
If n files share the same 1:n locks, then the number of blocks for each lock can vary by as much as n. If you assign locks to individual files, either with separate clauses of
GC_FILES_TO_LOCKS or by using the keyword
EACH, then the number of blocks for each lock does not vary by more than one.
If you assign 1:n locks to a set of datafiles collectively, then each lock usually manages one or more blocks in each file. Exceptions can occur when you specify contiguous blocks (by using the
!blocks option) or when a file contains fewer blocks than the number of locks assigned to the set of files.
Oracle9i Real Application Clusters Deployment and Performance for details on how to use the