Oracle ORA-1157を解決する

ORACLEデータベース によくあるエラ の解決策

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：[email protected]

 

 

すべてのエンタプライズバーションデータベースにも適用できる
すべてのプラットフォームにも適用できる。

目標

ORA-1157エラについて、よくある原因とその解決策を検討する。

範囲

Oracle技術サポート及びOracleデータベース管理員。

詳しい情報

Oracle Error: ORA-1157

あるORA-01157エラが現れた。Oracleがファイルをアクセスしてみると、ファイルがなくなったあるいはロックされた。
エラディスクライブ:

01157, 00000, “cannot identify/lock data file %s – see DBWR trace file”

Cause: The background process was either unable to find one of the data files or failed to lock it because the file was already in use. The database will prohibit access to this file but other files will be unaffected. However the first instance to open the database will need to access all online data files. Accompanying error from the operating system describes why the file could not be identified.

Action: Have operating system make file available to database. Then either open the database or do ALTER SYSTEM CHECK DATAFILES.

一般的に、ORA-01157が起こったら、ORA-01110とOracleオペレーションシステムレベルエラも付き添う。例えばORA-07360。あるDBWRトレースファイルがBACKGROUND_DUMP_DESTディレクトリに作成される。

例えば、Solarisプラットフォームで、以下のようなエラが現れる：

ORA-01157: cannot identify/lock data file 19 – see DBWR trace file
ORA-01110: data file 19: ‘/app/Oracle/oradata/users02.dbf’

From the DBWR trace file:

ORA-01157: cannot identify/lock data file 19 – see DBWR trace file
ORA-01110: data file 19: ‘/app/Oracle/oradata/users02.dbf’
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3

ORA-1157によくある原因とその解決策

注：ここで検討しているのは「バックアップ」で、有効な物理バックアップがあれば、そのバックアップからデータベースをリカバリすることもできる。

1、データベースが存在しているが、Oracleが気づいていない。

このデータファイルがオペレーションシステムレベルにリネームされたかもしれない。別のディレクトリあるいはディスクに移す。
2、データファイルが存在していない。あるいはOracleに使われられない。データファイル既に削除され、識別できなくなった。

例えば、そのデータファイルが上書きされた。こういう場合に、ORA-27046だけじゃなく、ORA-1157も起こる。

例えば:

ORA-27046: ファイルの大きさはロジックブロックの何倍になった
こういう場合に、以下のような二つの選択肢がある    :

A   データファイルを含むテーブルスペースを再構造する.

このオプションはuser,index,temporaryテーブルスペースに対して最適である。

そして、undoテーブルスペースにも適用できる。もしデータベースが完全クロスした場合に、アクチブなトランザクションがそのテーブルスペースのロールバックセグメントに存在しなくなった。
もし、テーブルスペースはSYSTEMテーブルスペースなら、データベースを再構造することに意味している。
この方法は一時的なテーブルスペースに最適である（重要なデータを含まないから）、useテーブルスペース及びindexテーブルスペースにも適用できる。
この方法は有効なエクスポートオブジェクトテーブルスペースに対しても利用できる。

ステップは以下の通り：
1. データベースがクロスされたら、データベースをmountしてください

STARTUP MOUNT;

2. データファイルをOffline dropに設定してください.

ALTER DATABASE DATAFILE ‘full_path_file_name’ OFFLINE DROP;

3.もしデータベースが mountなら、起動してください.

ALTER DATABASE OPEN;

4. テーブルスペースを削除する.

DROP TABLESPACE tablespace_name INCLUDING CONTENTS;

注：ここに進めたらいい。もし、データベースがそのテーブルスペースを必要しなくなったら、

5. テーブルスペースを再構造する.

CREATE TABLESPACE tablespace_name DATAFILE ‘datafile_full_path_name’ SIZE required_size;

6.そのテーブルスペースにあらゆるオブジェクトを再構造する。

ここで、スクリプトで、そのテーブルスペースのオブジェクトを再構造できる。あるいはそのテーブルスペースオブジェクトがエクスポートした有効なダンプデータを利用する。

B. データファイルをリカバリしてまともなリカバリプログラムを利用する

これはread onlyテーブルスペースと再構造できなくなったusers，indexテーブルスペースに適用できる

もし、テーブルスペースはundoテーブルスペースなら、データベースが完全にクロスされていない場合に適用できる（つまりデータベースがシャットダウンされた場合）
もしテーブルスペースはSYSTEMなら、この方法を利用できるが、バックアップもアーカイブログも使えて、データベースがNOARCHIVELOGモードの場合に、オンラインで必要な変更をリカバリするしかない。

多くの場合に、テーブルスペースを再構造する可能性が高くない。該当する解決策はバックアップからなくしたデータファイルをリカバリするあるいはメディアリカバリする。

もしデータベースはNOARCHIVELOGモードなら、オンラインログの範囲にリカバリしかできない。

これはREAD ONLYテーブルスペースに対して最適な方法である。もし、テーブルスペースがバックアップしたあと読み書きに切り替えされていなければ、データをリカバリするときにテーブルスペースのバックアップからリカバリすればいい。

ステップは以下の通り：
1.バックアップからなくしたファイルをリカバリする
2.データベースがクロスされたら、mountしてください.

STARTUP MOUNT;

3. 以下のようなクエリを実行してください:

SELECT V1.GROUP#, MEMBER, SEQUENCE#,
FIRST_CHANGE#
FROM V$LOG V1, V$LOGFILE V2
WHERE V1.GROUP# = V2.GROUP# ;
これで、すべてのオンラインログファイルとそのシーケンスをリストする。

4.もしデータベースはひアーカイブモードで、以下のようなクエリを実行してください:

SELECT FILE#, CHANGE# FROM V$RECOVER_FILE;

もしCHANGE#がFIRST_CHANGE#の最小値より大きいな場合にそのデータファイルがリカバリできると意味している。すべてのログもオンラインログとして、ステップ５に進めてください。
もしCHANGE#がFIRST_CHANGE#の最小値より小さい場合に、そのデータファイルがリカバリできないと意味している。
これで、最近のバックアップにしかリカバリできない。あるいはオプションAによって、テーブルスペースを再構造する。

5. データファイルをリカバリする:

RECOVER DATAFILE ‘full_path_file_name’ ;

6. 「メディアリカバリ完了」というメッセージを受信したまで、各システムが報告したログを確認する。もし、システムが存在していないアーカイブログを報告したら、データベースが一つあるいは複数のオンラインログリカバリが必要としている。オンラインシーケンスとORA-280メッセージに使ったシーケンスを使って、シーケンスとマッチするredo組みのパスを指定する。
7. データベースはmount状態なら、起動する.

オペレーションシステムの一時ファイルがなくした：

一時テーブルスペースの一時ファイルを使うと、その一時ファイルがなくなる。それにORA-1157エラが起こる。

Oracleが一時ファイルに対してチェックポイントオペレーションを出来ないから、データベースが一時ファイルを欠かす場合に起動できる。この場合の解決策はロジック一時ファイルを削除して、新たに追加する。
例えば:

select * from dba_objects order by object_name;
select * from dba_objects order by object_name;
*
ERROR at line 1:

ORA-01157: cannot identify/lock data file 1026 – see DBWR trace file
ORA-01110: data file 1026: ‘/Oracle/oradata/temp2_01.tmp’

解決策:

alter database tempfile ‘/Oracle/oradata/temp2_01.tmp’ drop;

select tablespace_name, file_name from dba_temp_files;

alter tablespace temp2 add tempfile ‘/Oracle/oradata/temp2_01.tmp’ size 5m;

オペレーションシステムトラブルあるいはサードパーティーソフトウェアによるORA-1157

1. When trying to access Quick I/O files with vxfddstat, or other applications, getting an error message similar to “Cannot open file”.
   I/ O、vxfsstat、ほかのアプリケーションをアクセスしてみると、「ファイルをオープン出来ない」と報告する。
   Oracleに以下のようなエラが返される：

ORA-01157: cannot identify data file 1 – file not found
ORA-01110: data file 1: ‘/u01/Oracle/oradata/system01.dbf’

この場合に、ユーザーはVeritasに連絡して、サポートを求める必要がある。
http://support.veritas.com/

Click on: ‘Product Listing’
Click on: ‘File System for UNIX’
Enter ‘Oracle’ and click ‘Search’ to view relevant information from their Knowledge Base.

2. Hewlett-Packardのマシンで、カーネルバラメタnflockが高く設定されていなければ、エラになる。これで、Oracleが必要なデータファイルをロックすることをとめてやる。制御ファイルを再構造することも失敗するかもしれない。ORA-27041とORA-1157の原因も同じである。:

これで、より多くのエラが以下のようなダンプディレクトリのトレースファイルに現れる：

ORA-27086: skgfglk: unable to lock file – already in use

OR

ORA-01157: cannot identify/lock data file 263 – see DBWR trace file
ORA-0110: data file 263: ‘/u01/Oracle/mndata4/veax01.dbf’
ORA-27041: unable to open file
HP-UX Error: 23: File table overflow
Additional information: 2

OR

ORA-07445: exception encountered: core dump [%s] [%s] [%s] [%s] [%s] [%s]
ORA-01110: data file %s: ‘%s’
ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode
ORA-01115: IO error reading block from file %s (block # %s)
ORA-27041: unable to open file
HP-UX Error: 23: File table overflow
Additional information: 3

トラブルを解決するために、カーネルバラメタを増やす。設定は以下の通り：
nproc 4096 Max Number of Processes
nfile 63488 Max Number of Open Files
nflocks 4096 Max Number of File Locks

これらのバラメタのメッセージはガイドブックに参考してください。
ORA-27041エラを解決できたら、Solarisに’File table overflow’する。次はシステム設定の解決策である：
/etc/system parameters
set vxfs:vxfs_ninode=692416
set ncsize=519312

Oracleはこれらのバラメタを調整することを支持していない。詳しい情報はsunsolve.sun.comに使用可能なSunファイル（76671）を参考してください。これもncsize調整を説明した。それに、調整したVxFS：vxfs_ninodeはVERITASにしかどこにもないものから、トラブルがあれば、Veritasに連絡してください。

3. もしOracleが必要としたデータファイルがほかのプロセスによってロックされたら、例えば、バックアップソフトウェアがファイルをロックして、バックアップするかもしれない、ORA-1157になる。

Windowsシステムで、ユーザーが以下のようなエラを受信した：

ORA-01157: signalled during alter database open
ORA-01157: can not identify datafile
ORA-01110: data file 10: ‘u01/Oracle/oradata/index01.dbf’
ORA-27047: Unable to read header of file
OSD-04006: Read file failure
Error 33: process can not access file

The operating system error 33 is an error_lock_violation indicating that a portion of the data file is locked by another NT process.
オペレーションシステムエラ33はあるERROR_LOCK_VIOLATIONでそのデータファイルの一部がほかのNTプロセスにロックされる。
あるいは

ORA-1157 – cannot identify datafile – file not found
ORA-1110 – datafile 11 ‘u01/Oracle/oradata/index02.dbf’
ORA-9202 – sfifi: error identifying file
OSD-4006(OS 203) – The System could not find the environment option that was entered

ほかのエラはアラームログに現れる:

ORA-1115 – IO error reading block from file %s (block # %s)
ORA-1110 – datafile 11 ‘u01/Oracle/oradata/index02.dbf’
ORA-9206 – sfrfb: error reading from file
OSD-4006(OS 203) – The System Could not find the environment option that was entered

あるいは

ORA-1242 – data file suffered media failure: database in NOARCHIVELOG mode
ORA-1114 – IO error writing block to file <name> block #
ORA-9205 – sfqio: error reading or writing to disk
OSD-4016(OS 33) – The process cannot access the file because another process has locked a portion of the file.

それに、以下のようなエラも現れるかもしれない：

KCF: write/open error dba=0x703473d block=0x3473d online=1
file=7 E:\Oracle\data\grec\crecind2.dbf
error=9211 txt: ‘OSD-4008 : WriteFile error (OS 203) – The System Could not find the environment option that was entered

一部の場合に、alterログに以下のようなエラが現れるかもしれない：
1110エラによってインスタンスを中止した。
バックグラウンドプロセスPID-XXXがインスタンスを中止した。

あるいは

background process TERMINATING INSTANCE DUE TO ERROR 472

ORA 472 – PMON process terminated with error

以下のようなエラもWindowsの時間確認マシンに報告される：
23 Error ReadFile() failure.
25 Error WriteFile() failure.

もしこれはコールドバックアップなら、バックアップできたら、データベースを起動するあるいはバックアップすることをやめてデータベースを起動する。
代わる解決策はバックアップソフトウェアを設置して、ファイルがロックされないようにする。

BACKUP ソフトウェアファイルを参考して、ソフトウェアファイル情報はどうやって設定するか確認する必要がある
例えば、Seagate Backup Exec Softwareで、’Read and Not lock’オプションを設定して、オンラインバックアップを実現する。

一部のlinuxプラットフォームで実現できる。

この場合に対して、解決策は人工的にデータファイルのロックを削除する。
i. Run $ ps -ef | grep <SID> – look for an existing process on a datafile

1. Do $ kill -9 on the process id
2. windowsシステムで、ファイル管理器で、Oracleデータファイルをほかのディレクトリにコピする。もし、そのデータファイルの名は8.3フォーマットに超えたら、ORA-1157 エラになる。つまり、ファイル名が8に超えたら３文字も延びる。

このトラブルを避けるために、windows95/98でファイルをコピすると、ファイル管理器を使わないでください。ファイルの名が長くなると（名が決まった8.3を超えたネームルール）。長いファイル名を保持するために、ファイル管理器は8.3ファイル名でそのファイルをリネームする。
長いファイル名を保持するために、ブラウザでファイルをコピしてください。もし、ファイルは使用された、それにファイルに「～」を含むから、そのファイルを元の名にリネームする。

5.ネットアプリで、一部のオペレーションは該当するデータファイルにロックする必要がある。その場合にも、ORA-1157になる。
インスタンスあるホストのシャットダウンの時に、ネットアプリは該当するロックを格納する。こういう場合にシステム管理者によってロックを解放する必要がある。

コマンドは以下の通り:

As root on the netapp, from the prompt:

rc_toggle_basic

sm_mon -l <hostname>

以上のコマンドで、ホスト名は実行しているインスタンスのホスト名である。

6.異なるユーザーが同時にリカバリすれば、ORA-1157になる。

データファイルをrestoreしてから、リカバリするときに、ORA-1157エラになって、リストアしたデータファイルが識別できない：

– The datafile exists at the OS.
– select * from v$datafile shows the correct path for the datafile.
– “alter system check datafiles” is successful.
– backup control file to trace shows full path to datafile is correct.

こういう場合に、オペレーションシステムレベルの権限に引き起こしたものである。データファイルの権限をチェックして、リカバリオペレーションがほかのユーザーに完成されたことをチェックして、Oracleユーザーじゃなくで、rootユーザーに確保してください。

この場合に、ファイルがOracleユーザーに見られるが、Oracleに属していないから、書き読めない。

ファイルの所有権を変更して、Oracleユーザーがデータファイルをリストアことを許し、コマンドが成功できるようになる。

ORA-1157 –別の可能性

1. エラの制御ファイルはORA-1157を引き起こすかもしれない

ORA-1157になって、制御ファイルを壊すかもしれない。その可能な原因の一つは制御ファイルのファイル名とブランクである。これは制御ファイルのテキストバーションを確認して、 “ALTER DATABASE BACKUP CONTROLFILE TO TRACE’コマンドでテキストバーションを作成する。（トレースファイルはUSER_DUMP_DEST初始化バラメタが指定した位置に放置する）。

Example:
——–

‘/home/d/Oracle/oradata/ecn/rdx01.dbf ‘ — corrupt
‘/home/d/Oracle/oradata/ecn/rdx02.dbf’ — non-corrupt

こういう場合に、制御ファイルのコピ（壊れていなければ）で解決する。バラメタファイルinit.oraのCONTROCL_FILESバラメタを変更して、壊れた制御ファイルを削除する。すべての制御ファイルも壊れた場合に、制御ファイルを再構造する必要がある。これも制御ファイルの制御文字を埋め込むかもしれない。

例えば:

“^J” がデータファイルの名前に現れるかもしれない.

以上の解決策はこの場合にも解決できる。

2. データベースを構造できたら、メインデータベースにテーブルスペースあるいはデータファイルを追加する。

もし、データファイルがコピデータベースに自動的に作成されていなければ、人工的に作成してください。そのファイルが存在すれば、リカバリを続ける。
例えば:

Redoがデータファイルを作成していなければ、mount状態でデータファイルを作成する:

alter database create datafile ‘datafile_full_path_name’;

3. RMANはalert.logで偽ORA-1157エラをリカバリできる

RMANリカバリオペレーションは以下のようなエラを引き起こす：

ORA-01157: cannot identify/lock data file N – see DBWR trace file
ORA-01110: data file N: ‘filename’
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory

もしRMANリカバリオペレーションを実行していなければ、ディスクから、削除したデータファイルも同じようなエラになる。

これらすべても予想内で、心配する必要はない（必要なときにアーカイブする必要がある）。

4. 種データベースをインストールするときに、ORA-1157になった。
   種データベースを利用するときに、OracleはCDからデータファイルをディスクにコピして、データベースを起動してみる。けど、データファイルはＣＤに壊れた場合に、ORA-1157エラになる。

このようなエラの解決策は新たなＣＤを利用することあるいは人工的にスクリプトを作成して、データベースを作成する。