clicksor ad

Monday, July 10, 2006

Table locking in Oracle RAC

The other day there was some problem in a particular module .People were not able to save recors and also not able to query record related to a particular table.When I analysed with OEM I found that the table had more than one "exclusive lock" held on it.I was puzzled and I tried removing them by killing sessions related to those locks ,but again after a few minutes it was back.

I am not an advanced level DBA so I was searching for a solution on google.I got this link
http://www.utexas.edu/its/unix/reference/oracledocs/v92/B10501_01/rac.920/a96598/freelist.htm

Deciding Whether to Create Database Objects with Free List Groups

Free lists and free list groups are usually needed when random inserts to a table from multiple instances occur frequently. Processes looking for space in data blocks can contend for the same blocks and table headers. The degree of concurrency and the overhead of shipping data and header blocks from one instance to another can adversely affect performance. In these cases, use free list groups.

Identifying Critical Tables

You can identify tables that are subject to high insert rates by querying the V$SQL view and searching for INSERT commands as shown in the following example:

SELECT SUBSTR(SQL_TEXT,80), DECODE(COMMAND_TYPE,2,'INSERT'),EXECUTIONS
FROM V$SQL
WHERE COMMAND_TYPE = 2
ORDER BY EXECUTIONS;

Search for the table name in the string for the statements with the highest number of executions. These statements and the indexes that are built on them are candidates for free list groups.

Determining FREELIST GROUPS Reorganization Needs

You can monitor free list group performance by examining the rate of cache transfers and forced disk writes by using the V$CLASS_CACHE_TRANSFER view. V$CLASS_CACHE_TRANSFER view contains information about the number of cache transfers that occurred since instance startup for each class of block. If your output from the following select statement example shows a relatively high amount for segment header and free list forced disk writes, for example, more than 5% of the total, then consider changing the FREELIST GROUPS parameter for some tables to improve performance.

SELECT CLASS, (X_2_NULL_FORCED_STALE + X_2_S_FORCED_STALE) CACHE_TRANSFER
FROM V$CLASS_CACHE_TRANSFER;

Because the V$CLASS_CACHE_TRANSFER view does not identify cache transfers by object name, use other views to identify the objects that significantly contribute to the number of cache transfers. For example, the V$CACHE_TRANSFER view has information about each block in the buffer cache that is transferred. Block class 4 identifies segment headers and block class 6 identifies free list blocks. The output from the following select statement can show objects that could benefit from increased free list groups values:

SELECT NAME, CLASS#, SUM(XNC) CACHE_TRANSFER
FROM V$CACHE_TRANSFER
WHERE CLASS# IN (4,6)
GROUP BY NAME, CLASS#
ORDER BY CACHE_TRANSFER DESC;

Note:

If you did not create your database with the Database Configuration Assistant, then certain Real Application Clusters-specific views such as V$CLASS_CACHE_TRANSFER are only available after you execute the CATCLUST.SQL script.


Then I found that these queries pointed to the same table.Then I found that the tablespace had Automatic segment space management enabled.So it should all be working fine for RAC.That is what the page told me.But then I rebuilt the indexes with increased initrans ,freelists and freelist groups .And the problem was solved.

No comments: