B
Using Multi-Block Lock Assignments (Optional)

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:

• When to Use Locks
• How to Use Locks
• Lock Granularity
• Understanding Lock Management

  Note: You never have to set GC_FILES_TO_LOCKS. Real Application Clusters and its resource control mechanism from Cache Fusion provide optimal performance without using locks.

When to Use Locks

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.

How to Use Locks

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.

Lock Granularity

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.

Understanding Lock Management

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 GC_FILES_TO_LOCKS=1:300,2:200,3-5:100.

Figure B-1 Lock-to-Block Assignment Examples for GC_FILES_TO_LOCKS Settings

Text description of the illustration sps81108.gif

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.