Oracle資料庫報錯 ORA-01102 ORA-1102 signalled during....

昨天剛裝完的一個資料庫在啟動的時候，報錯ORA-01102，而且安裝的時候也沒有看到哪裡有報錯資訊，一路都比較順利，而且這也是第一次我碰到這個問題，當時我首先就檢查了alert記錄檔，並把相關的錯誤資訊在metalink上查看過了，經過分析後判斷是由於處理序間通訊被爭用導致，以下是我處理該問題的一個思路，並在最後附上了metalink原文以及朋友對該問題的一個理解和處理辦法。

為什麼會發生如下錯誤，原因是多個使用者同時去訪問同一個資源就會發生獨佔模式，因為在Linux裡面預設一個進程只被一個使用者訪問，要避免這個問題，在建立使用者的時候指定預設去指定不同於其它使用者的優先順序就可以避免此類問題的發生。

sculkget: failed to lock /orasoft/product/10.2.0/db_1/dbs/lkWWL exclusive   同一個進程被多個使用者訪問發生了獨佔模式
sculkget: lock held by PID: 26312                                           發生獨佔模式的進程號為pid:26312
ORA-09968: Message 9968 not found; No message file for product=RDBMS, facility=ORA  並且沒有找到9968的資料訊號，同時了我們該訊號的類型
Linux Error: 11: Resource temporarily unavailable                           導致資源無法被正常利用
Additional information: 26312
Thu Nov 17 15:51:16 2011
ORA-1102 signalled during: ALTER DATABASE   MOUNT...

解決如上錯誤過程如下:

1、我們可以通過如下命令查看到發生獨佔的進程名稱為ora_dbw0_wwl
[Oracle@ora10g dbs]$ ps -ef|grep 26312
oracle   26312     1  0 15:43 ?        00:00:02 ora_dbw0_wwl
oracle   26663 26574  0 17:39 pts/1    00:00:00 grep 26312

2、進入資料庫，先關閉執行個體
[oracle@ora10g ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Thu Nov 17 17:45:56 2011

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options

SQL> shutdown immediate
ORA-01507: database not mounted

ORACLE instance shut down.
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options

進入到 $ORACLE_HOME/dbs，查看到一個名為lkWWL的檔案，正常情況下是沒有這個檔案的
[oracle@ora10g ~]$ cd $ORACLE_HOME/dbs
[oracle@ora10g dbs]$ ls
hc_wwl.dat  initdw.ora  init.ora  lkWWL  orapwwwl  spfilewwl.ora

[oracle@ora10g dbs]$ su - root
口令：

通過fuser -u lkWWL 命令一看，果然果然進程沒有被釋放
[root@ora10g ~]# cd /orasoft/product/10.2.0/db_1/dbs
[root@ora10g dbs]# fuser -u lkWWL
lkWWL:               26306 26308 26310 26312 26314 26316 26318 26320 26322 26324 26326 26334 26336 26340 26354 26356

[root@ora10g dbs]# fuser -k lkWWL
lkWWL:               26306 26308 26310 26312 26314 26316 26318 26320 26322 26324 26326 26334 26336 26340 26354 26356

[root@ora10g dbs]# fuser -u lkWWL

重新啟動資料庫看看，這個時候資料庫沒有報錯了，能正常起來。
[root@ora10g dbs]# su - oracle
[oracle@ora10g ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Thu Nov 17 17:47:50 2011

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area  285212672 bytes
Fixed Size                  1218992 bytes
Variable Size              92276304 bytes
Database Buffers          188743680 bytes
Redo Buffers                2973696 bytes
Database mounted.
Database opened.

SQL> col host_name format a20
SQL> select host_name,instance_name,status from v$instance

HOST_NAME            INSTANCE_NAME    STATUS
-------------------- ---------------- ------------
ora10g.localdomain   wwl              OPEN

SQL>

Metalink 原文如下：
analysis：
Problem Description:
==================== 
You are trying to startup the database and you receive the following error:
     ORA-01102:  cannot mount database in EXCLUSIVE mode
       Cause:  Some other instance has the database mounted exclusive
               or shared.
      Action: Shutdown other instance or mount in a compatible mode.
    Problem Explanation:
==================== 
A database is started in EXCLUSIVE mode by default.  Therefore, the
ORA-01102 error is misleading and may have occurred due to one of the
following reasons: 
  - there is still an "sgadef<sid>.dbf" file in the "ORACLE_HOME/dbs"
    directory
  - the processes for Oracle (pmon, smon, lgwr and dbwr) still exist
  - shared memory segments and semaphores still exist even though the
    database has been shutdown
  - there is a "ORACLE_HOME/dbs/lk<sid>" file
   Search Words:
============= 
ORA-1102, crash, immediate, abort, fail, fails, migration
Solution Description:
===================== 
Verify that the database was shutdown cleanly by doing the following:
  1. Verify that there is not a "sgadef<sid>.dbf" file in the directory
   "ORACLE_HOME/dbs".   
        % ls $ORACLE_HOME/dbs/sgadef<sid>.dbf
     If this file does exist, remove it. 
        % rm $ORACLE_HOME/dbs/sgadef<sid>.dbf 
2. Verify that there are no background processes owned by "oracle"
          % ps -ef | grep ora_ | grep $ORACLE_SID
     If background processes exist, remove them by using the Unix
   command "kill".  For example:
          % kill -9 <rocess_ID_Number>
  3. Verify that no shared memory segments and semaphores that are owned
   by "oracle" still exist
          % ipcs -b
     If there are shared memory segments and semaphores owned by "oracle",
   remove the shared memory segments
          % ipcrm -m <Shared_Memory_ID_Number>
     and remove the semaphores
          % ipcrm -s <Semaphore_ID_Number>
     NOTE:  The example shown above assumes that you only have one
          database on this machine.  If you have more than one
          database, you will need to shutdown all other databases
          before proceeding with Step 4.
  4. Verify that the "$ORACLE_HOME/dbs/lk<sid>" file does not exist
  5. Startup the instance
    Solution Explanation:
===================== 
The "lk<sid>" and "sgadef<sid>.dbf" files are used for locking shared memory.  It seems that even though no memory is allocated, Oracle thinks memory is  still locked.  By removing the "sgadef" and "lk" files you remove any knowledge oracle has of shared memory that is in use. Now the database can start.

1 2 3 下一頁