Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2154399
  • 博文数量: 157
  • 博客积分: 10047
  • 博客等级: 上将
  • 技术积分: 6757
  • 用 户 组: 普通用户
  • 注册时间: 2005-05-19 11:38
文章分类

全部博文(157)

文章存档

2011年(16)

2010年(50)

2009年(42)

2008年(49)

我的朋友

分类: LINUX

2010-03-05 15:14:02

NFS Locking Problems Encountered During Database Startup [ID 236794.1]  
--------------------------------------------------------------------------------
 
  Modified 16-FEB-2005     Type BULLETIN     Status PUBLISHED  

PURPOSE
-------
This document aims to describe some possible issues with databases where 
the datafiles, redo logs, control files or any other file located on an
NFS mounted disk.
 
SCOPE & APPLICATION
-------------------
This article is intended for database administrators, who work with
databases with files on an NFS mounted disk. Note that Network Appliance
(NetApp) and EMC disk systems can employ NFS.
Oracle does not support and recommend using an NFS device unless the NFS
vendor is a member of the Oracle Storage Compatibility Program (OSCP)
(See ).
Members in the Oracle Storage Compatibility Program (OSCP) test and verify
their products compatibility with the Oracle Server product.
The main problem with NFS is that the protocol is not reliable the vendors
in the OSCP have gotten around the technical problems of NFS, which would
make NFS services reliable

NFS Locking Problems Encountered During Database Startup
--------------------------------------------------------
There are two types of locks involved:
  a. OS level locks
    Oracle places OS level locks when a database is started and releases
    these OS level locks when a database is stopped. Depending on the exact
    version of the database software, it also places small files. For Oracle
    7 and 8, this is the $ORACLE_HOME/dbs/sgadef.dbf file in . For
    later versions this is the $ORACLE_HOME/dbs/lk file.
  b. NFS locking daemons
 
    In order to be able to placed and release these OS locks on an NFS
    mounted file system you need the NFS locking daemons. These locking
    daemons are the rpc.lockd and the rpc.statd on most UNIXes.
With these locking schemes we may encounter some problems where the Oracle
or the OS errors are not much self explanatory (as in HP-UX case). The
following problems can be encountered:
Problem 1:
----------
Symptoms:
- Database startup fails
- Errors in alert.log:
    ALTER DATABASE   MOUNT
    scumnt: failed to lock .../dbs/lk exclusive
    ORA-09968: scumnt: unable to lock file
    ...
       Compaq Tru64 UNIX Error: 77: No locks available
       ...
       HP-UX Error: 13: Permission denied
       ...
    ORA-1102 signalled during: ALTER DATABASE   MOUNT.
Cause:
- One or both of the locking daemons crashed for any reason
- Instance was down when the locking daemon(s) crashed
- When starting the instance locks cannot be set
Solution:
- Restart locking daemons and retry startup.

Problem 2:
----------
Symptoms:
- (8i and before) Database startup fails with:
     ORA-00600: internal error code, arguments:[2806], [60]
OR
- (After 9i) Database startup hangs
Cause:
- One or both of the locking daemons crashed for any reason
- Instance was running when the locking daemon(s) crashed
- Locks could not be released on files when the database was being shutdown
  since at least one of the daemons were not running.
- When trying to startup the database you had encountered the "Problem 1"
  and fixed that but restarting the locking daemons.
- In this case we have locking daemons running but there are locks on the
  files remaining although the database is not up.
- Locks remained are generally on the:
    . sgadef.dbf
    . lck
    . controlfiles
    . redo logs
    . datafiles
Solution:
- Remove the sgadef.dbf or lck file. In this case you will get:
    ORA-27086: skgfglk: unable to lock file - already in use
  for controlfiles and datafiles etc.
- To workaround this:
    1. Copy all the files (data, control and log) to another location
    2. Delete the original files (data, control and log)
    3. Restore all the files to their original location
Actually, this is not easy to follow to get around the problem. The real
and clean solution may be to configure the NFS systems to forget about the
pending locks. The NetApp box has such possibilities (See Note:145194.1).

RELATED DOCUMENTS
-----------------
Note:145194.1  ORA-1157 ORA-1110 ORA-27086 Starting up Database
Note:102557.1  Open a Database In 8.1 On HP-UX Fails
                 With ORA-27086 And HP-UX Error: 46
Note:231442.1  ORA-1102 during startup
 
阅读(2496) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~