Oracle バックアップおよびリカバリにおけるORA-1157エラーの一般的な原因と解決法

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

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

本文書利用上のご注意：本文書は英語で提供されている文書Document 184327.1を翻訳した
    ものです。ご利用に際しては、併せて英語の原文をご参照頂くことをお勧めいたします。 

目的
=====

この文書では、ORA-1157エラー、およびそのさまざまな原因と解決法について
記述しています。

 
適用範囲とアプリケーション
===========================

ORA-1157エラーに遭遇しているユーザー、およびORA-1157エラーに関する
既知の問題の情報を必要としているアナリストを対象としています。



ORA-1157
========

ORA-01157は、Oracleでファイルへのアクセスを試行し、そのファイルが
見つからなかった場合に返されます。
 

エラーの説明
------------

01157, 00000, "cannot identify/lock data file %s - see DBWR trace file"

   原因:    バックグラウンド・プロセスで、いずれかのデータ・ファイルを
            見つけることができなかったか、あるいはそのファイルが
            既に使用されているためロックできなかったかのいずれかが原因です。
            データベースでは、このファイルへのアクセスを禁止しますが、
            他のファイルには影響しません。
            しかし、データベースをオープンするための最初のインスタンスは、
            すべてのオンライン・データ・ファイルへアクセスする必要があります。
            オペレーティング・システムから返される、このエラーに付随する
            エラーには、そのファイルを特定できなかった理由が記述されます。
  
   処置:    オペレーティング・システムで、データベースに対して
            ファイルが利用可能となるようにします。
            その後データベースをオープンするか、または
            ALTER SYSTEM CHECK DATAFILESを実行するかのいずれかを行います。      
  
   ORA-01157エラーでは、通常ORA-01110も共に返され、また時にはORA-07360などの
   Oracleオペレーティング・システム・レイヤーのエラーも共に返される
   ことがあります。background_dump_destディレクトリ内に、
   DBWRトレース・ファイルが生成されます。

  たとえば、Solarisプラットフォームでは、次のエラーが表示されることが
  あります。

   ORA-01157: cannot identify/lock data file 19 - see DBWR trace file
   ORA-01110: data file 19: '/h04/usupport/app/Oracle/oradata/v817/users02.dbf' 

  DBWRトレース・ファイルには、次のように記述されます。

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



考えられる原因と解決法の概要
=============================

   A. ORA-1157の一般的な原因と解決法
   B. OSの問題または(入出力(IO)やバックアップなどに使用される)
        サード・パーティのソフトウェアが原因で、ORA-1157が返されるケース
   C. 移行/アップグレードの際にORA-1157が返されるケース
   D. ORA-1157エラーの他の考えられる原因
   E. ORA-1157エラーに関連する他のNote


A. ORA-1157の一般的な原因と解決法
**********************************

  注意: 
   Oracle9iを使用している場合は、記載されているコマンドの実行に、
   Server ManagerではなくSQL*Plusを使用してください。
   これは、Oracle9iではServer Managerはすでに廃止されているためです。

1. データファイルが存在するのに、Oracleで検出できないケース:

     意図的に、あるいは意図的ではない理由により、
     オペレーティング・システム・レベルでデータファイルがリネームされたか、
     ファイルが異なるディレクトリやディスク・ドライブなどへ
     移動された可能性があります。

     この場合は単純に、そのデータファイルを元の名前やロケーションへ戻すか、
     あるいはデータファイルを新しいロケーション/ディレクトリへ
     リネームすることにより、この問題は解決されます。
 
     ファイルをリネームする方法については、Document 115424.1を
     参照してください。


2. データファイルが存在しないか、またはOracleで使用可能でないケース:

     データファイルが物理的に削除されたか、またはOracleで認識できないほど
     破損している可能性があります。

     たとえば、データファイルで切り捨てや上書きが行われた場合などです。
     この場合は、ORA-1157エラーとともにORA-27046も返されます。

     例:

     ORA-27046: file size is not a multiple of logical block size

     この場合、ユーザーがとり得るオプションには、次の2つがあります。

     a. そのデータファイルが属する表領域を再作成する方法
        -----------------------------------------------------------

       このオプションは、USERS、INDEX、TEMPORARYテーブルスペースに
       適した方法です。

       また、データベースがSHUTDOWN NORMALやSHUTDOWN IMMEDIATEされており、
       この表領域のロールバック・セグメント内に
       アクティブなトランザクションがまったく無い場合には、
       ROLLBACKテーブルスペースに対しても、このオプションは利用できます。

       表領域がSYSTEMテーブルスペースである場合は、
       データベースを再作成することになります。
       
       このメソッドは、テンポラリ・表領域に最も適していますが
       (テンポラリ・表領域には重要なデータは含まれないため)、
       USERSテーブルスペースおよびINDEXESテーブルスペースにも
       使用することができます。

       このメソッドは、表領域内のオブジェクトの適度に最近の
       エクスポートが使用可能である場合や、あるいはスクリプトや
       プログラムの実行、SQL*Loaderを介したデータのロードなどにより、
       表領域内のテーブルに再度データを移植することが
       可能である場合に、有用です。

       ステップは次のとおりです。
  
       注意: Oracle9iを使用している場合は、記載されているコマンドの実行に、
             Server ManagerではなくSQL*Plusを使用してください。
             これは、Oracle9iではServer Managerは既に廃止されているためです。
             

        1. データベースがダウンしている場合は、マウントを行います。
  		
            SVRMGR> STARTUP MOUNT PFILE='<location_of_pfile>'; 
                  
        2. データファイルのoffline dropを行います。
   		
            SVRMGR> ALTER DATABASE DATAFILE '<full_path_file_name>' OFFLINE DROP; 
	   		
        3. データベースがマウント・ポイントにある場合は、オープンします。
   
            SVRMGR> ALTER DATABASE OPEN;

        4. ユーザー・表領域をドロップ(drop)します。

            SVRMGR> DROP TABLESPACE <tablespace_name> INCLUDING CONTENTS;   

        注意: データベース内でこの表領域を以後必要としない場合は、
              このステップまでで終わりにすることができます。
   
        5. 表領域を再作成します。
   	
            SVRMGR> CREATE TABLESPACE <tablespace_name> DATAFILE  
                    '<datafile_full_path_name'> SIZE <required_size>;

 	6. 表領域内に以前存在していたすべてのオブジェクトを
       再作成します。
   
        これは、その表領域内のオブジェクトに対して
        作成スクリプトを使用して、あるいはその表領域の
        オブジェクトについて使用可能な最近のエクスポート・ダンプを使用して、
        行うことができます。


    b. 通常のリカバリ手順を使用してデータファイルのリカバリを行う方法
       -----------------------------------------------------------------

     このオプションは、READ ONLY表領域、
     および再作成が実行できない場合のUSERS、INDEX表領域に
     適した方法です。
     
     表領域がROLLBACKタイプである場合は、
     データベースがSHUTDOWN CLEANLYされていない
     (つまり、shutdown abortが使用されたか、またはデータベースが
      クラッシュした)場合に、このメソッドを使用します。
     このための詳細なステップは、Note:1013221.6を参照してください。
	
     表領域がSYSTEMである場合は、バックアップおよび
     アーカイブ・ログが使用可能である場合に、これが推奨されるメソッド
     となります。
     データベースがNOARCHIVELOGモードにある場合は、ONLINE redolog内に
     必要な変更事項がある場合にのみ、リカバリが可能です。

     多くの状況では、ユーザー・表領域を再作成することは、
     不可能、または非常に困難です。そこで、この解決法として、
     バックアップから失われたデータファイルをリストアし、
     メディア・リカバリを行う方法があります。
     データベースがNOARCHIVELOGモードにある場合は、
     データファイルのリカバリに成功するのは、データファイルへ適用される
     redoがオンライン・ログの範囲内にある場合のみです。

     このメソッドは、READ ONLYテーブルスペースには理想的です。
     バックアップが行われた後に表領域がREAD-WRITEへ
     切り替えられておらず、かつバックアップ時にこの表領域が
     READ ONLYであった場合は、リカバリはこの表領域の
     バックアップのリストアのみになります。

     ステップは次のとおりです。
  
     1. バックアップから失われたファイルをリストアします。

     2. データベースがダウンしている場合は、マウントを行います。

	SVRMGR> STARTUP MOUNT PFILE=<location_of_pfile>;

     3. 次のクエリーを発行します。
   	
        SVRMGR> SELECT V1.GROUP#, MEMBER, SEQUENCE#, 
                FIRST_CHANGE#   
                FROM V$LOG V1, V$LOGFILE V2   
                WHERE V1.GROUP# = V2.GROUP# ;   
   
        これにより、ユーザーのすべてのオンラインredologファイル、
        およびそれらのシーケンス番号と最初の変更番号がすべてリストされます。
   
    4. データベースがNOARCHIVELOGモードにある場合は、次のクエリーを
       発行します。

       	SVRMGR> SELECT FILE#, CHANGE# FROM V$RECOVER_FILE;   
   
        CHANGE#がユーザーのログのFIRST_CHANGE#の最小の値よりも大きい場合は、
        データファイルはリカバリ可能です。適用されるすべてのログは、
        オンライン・ログであることに留意してください。
        ステップ5へ進んでください。   
    
        CHANGE#がユーザーのログのFIRST_CHANGE#の最小の値より小さい場合は、
        ファイルはリカバリできません。この時点でとり得るオプションは、
        最も最近のフル・バックアップをリストアする(そして、バックアップ時点
        以降に加えられたデータベースへのすべての変更が失われる)か、
        またはシナリオa.で説明したように表領域を再作成するかです。   
  
		
    5. データファイルのリカバリを行います。
   
       SVRMGR> RECOVER DATAFILE '<full_path_file_name>'   
   
    6.「メディア・リカバリが完了しました」というメッセージが返されるまで、
       プロンプトで表示される各ログを確認します。
       存在しないアーカイブ・ログがプロンプト表示された場合は、
       Oracleでリカバリを進めるために、おそらく1つまたは複数の
       オンライン・ログが必要とされています。
       ORA-280メッセージで参照されているシーケンス番号を、ユーザーの
       オンライン・ログのシーケンス番号と比較してください。
       そして、要求されているものと一致するシーケンス番号を持つ
       redoグループのメンバーのフルパス名を入力します。
      「メディア・リカバリが完了しました」というメッセージが返されるまで、
       要求に従ってオンライン ・ログの入力を続けてください。
  
    7. データベースがマウント・ポイントにある場合は、オープンします。


3. オペレーティング・システム(OS)のテンポラリ・ファイルが見つからないケース:


      TEMPORARYテーブルスペースをテンポラリ・ファイル(tempfile)とともに
      使用している場合は、テンポラリ・ファイルがOSレベルで
      見つからないことが、ORA-1157の原因となることがあります。

      Oracleではテンポラリ・ファイルのチェックポイントを指定しないため、
      テンポラリ・ファイルが見つからなくてもデータベースのオープンは
      可能です。

      ※ 起動時に一時表領域を利用したソート処理が行われる場合にはテンポラリ・
         ファイルが存在しないことを検知するためエラーが発生します。

      この場合の解決法は、論理テンポラリ・ファイルをドロップし、
      新規のテンポラリ・ファイルを追加することです。

例:
	
     SQL>  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/V901/temp2_01.tmp'


     SQL> alter database tempfile '/Oracle/oradata/V901/temp2_01.tmp' drop;
 
     SQL> select tablespace_name, file_name from dba_temp_files;
		     
     SQL> alter tablespace temp2 
          add tempfile '/Oracle/oradata/V901/temp2_01.tmp' size 5m;
		     


B. OSの問題または(IO/バックアップなどに使用される)サード・パーティの
   ソフトウェアが原因で、ORA-1157が返されるケース
************************************************************************


1. vxfddstatまたは他のアプリケーションを使用して
   Quick I/Oファイルにアクセスしようとし、「ファイルをオープンできません」
   というようなエラー･メッセージが返されるケース:

   Oracleで、次のようなエラー・メッセージが返されることがあります。
          
     ORA-01157: cannot identify data file 1 - file not found
     ORA-01110: data file 1: '<filename>'
 
   この場合、ユーザーはVeritas社のサポートに問い合わせる必要があります。

   Veritas社のサポート・サイトにアクセスするには、次のURLを参照してください。

   http://support.veritas.com/
  
         「Product Listing」をクリック 
         「File System for UNIX」をクリック
         「Oracle」へ入り、Knowledge Baseから関連情報を参照するために
         「Search」をクリックしてください。

2. HPでカーネル・パラメータnflockが十分高く設定されていない場合に、
   このエラーが返されるケース:

   これは、Oracleが必要なデータファイルをロックするのを妨げます。
   同じ理由で、制御ファイルの再作成がORA-27041およびORA-1157エラーで
   失敗することがあります。
	
   dumpディレクトリ内のトレース・ファイルには、たとえば次のように
   さらに多くのエラーがリストされることがあります。

     ORA-27086: skgfglk: unable to lock file - already in use 
	
     または

     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

     または

     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

     これらの問題を解決するには、HP上の関連するカーネル・パラメータの
     設定を増加させます。     
     推奨される設定は、次のようになります。
 		  
     nproc     4096    	Max Number of Processes
     nfile     63488    Max Number of Open Files    
     nflocks   4096    	Max Number of File Locks 

     これらのパラメータに関する詳細情報については、
     OSのインストレーション・ガイドを参照してください。


3.  Oracleで必要としているデータファイルが他のプロセスによって
    ロックされている場合に、ORA-1157が返されるケース:

    たとえば、バックアップ・ソフトウェアがバックアップのために
    ファイルをロックしている場合などがあります。

    NTでは、次のエラーのいずれかが返されることがあります。

     ORA-01157: signalled during alter database open
     ORA-01157: can not identify datafile <datafile id>
     ORA-01110: datafile <datafile id> path and filename of datafile
     ORA-27047: Unable to read header of file <datafile id>
     OSD-04006: Read file failure
     Error 33: process can not access file

    オペレーティング・システム・エラー33は、error_lock_violationであり、
    データファイルの一部が他のNTプロセスによってロックされていることを
    示します。

    または

     ORA-1157 - cannot identify datafile <name> - file not found
     ORA-1110 - datafile <name>: <str>
     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 <name>: <str>
     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 # <num>
     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

   場合によっては、アラート・ログに次のようなエラーが表示されることも
   あります。

     Instance terminating due to error 1110.  
     Instance terminated by <background process> PID=XXX

  または

    <background process> TERMINATING INSTANCE DUE TO ERROR 472

    ORA 472 - PMON process terminated with error

    Windows NTのイベント ビューアに次のイベントが報告される場合もあります。
	
    23      Error          ReadFile() failure. 
    25      Error          WriteFile() failure. 

 これがコールド・バックアップである場合は、バックアップが終了するまで
 待ってからデータベースをスタートアップするか、
 または、バックアップを終了させてデータベースをスタートアップ
 する必要があります。
	
 あるいは、バックアップ・ソフトウェアを構成して、オープン・ファイルを
 ロックしないようにするという解決法もあります。

 これを行う方法については、バックアップ・ソフトウェアの
 ドキュメントを参照してください。

 たとえば、Seagate Backup Exec Softwareでは、オンライン・バックアップに
「Read and Not lock」オプションを適用するように構成する必要があります。

 また、これは一部のUnixプラットフォームにも当てはまります。
 たとえば、IBM AIX ADSMバックアップ・ユーティリティでは、
 正常な実行が行われる前にフォールオーバーする可能性があり、
 このためOracleデータファイルのロックを保持することがあります。

この場合の解決法は、データファイルのロックを手動でクリアすることです。

i.  データファイルの既存のプロセスに対して、
    $ ps -ef | grep <SID> - look
    を実行します。

ii. $ kill -9 on the process id
    を実行します。



4. Windows上でファイル マネージャを使用してOracleデータファイルを
   ディレクトリへコピーし、ORA-1157が返されるケース:

   これは、ファイル名が通常の8.3フォーマットより長い場合に該当します。
   つまり、ファイルが8文字より長いロング・ネームであるか、
   または拡張子が3文字より長い場合です。

   この問題を回避するには、Windows 95/98でファイルをコピーする際に、
   ファイル マネージャを使用しないことです。
   ファイルにロング・ネームが付いている場合(つまり、標準の8.3の
   ファイル命名規則より長い場合)、ファイル マネージャは、
   それらのファイルを8.3のファイル名になるようにリネームします。

   ロング・ファイル名を保持するには、ファイルのコピーにエクスプローラを
   使用する必要があります。
   すでにファイル マネージャを使用済みで、ファイル名にチルダ(~)が
   含まれている場合は、それらのファイルを元のファイル名へ
   リネームする必要があります。



5. ネットワーク・アプライアンスを使用している場合に
   ORA-1157が返されるケース:
   
   ネットワーク・アプライアンスは、特定のオペレーションにおいて、
   データファイルのロックを取得します。
   これらのロックは、インスタンスまたはホスト・マシンの障害が原因で、
   ネットワーク・アプライアンスによって保持される場合があります。
   これらの場合は、システム管理者が、ネットワーク・アプライアンスから
   ロックを手動で解放する必要があります。

   これを行うためのコマンドは次のようになります。

   netappでのrootとして、プロンプトから次のように実行します。

      rc_toggle_basic

      sm_mon -l <hostname> 

   上記のコマンドで参照されるホスト名は、Oracleインスタンスの実行元
   であるマシン名にする必要があります。



6. Oracleファイルが異なるユーザーとしてリストアされ、
   ORA-1157が返されるケース:

   データファイルのリストア後、およびrecover datafileの発行後に、
   エラーORA-1157(cannot identify datafile - file not found) 
   が発生する場合があります。 
   次のような状況にもかかわらず、リストアされたデータファイルが
   認識されていないようです。
   
       - データファイルはOSに存在します。

       - select * from v$datafileでは、データファイルへの正しいパスが
         示されます。

       - alter system check datafilesは成功します。

       - トレースのためのバックアップ制御ファイルでは、
         データファイルへのフルパスが正しいことが示されています。

   この場合は、OSレベルでのアクセス権限の問題である可能性があります。

   データファイルのアクセス権限をチェックします。
   データファイルがリストアされた際、rootなどのOracleユーザーとは
   異なるユーザーによって行われた可能性があります。
   この場合、Oracleではこのファイルは見えますが、アクセスすることは
   できません。
   Oracleは、そのデータファイルのオーナーではないため、
   ファイルへの読み取りおよび書き込みを行うことはできません。
   アクセス権限のオーナーシップをOracleユーザーへ変更すると、
   restore datafileコマンドが成功するようになります。



7. ulimitの設定値が低いためにORA-1157が返されるケース:
	
     dbwrトレース・ファイルでORA-1157とORA-27092がともに返される
     ことがあります。

     DBWRトレース・ファイルで次のように表示されます。
 
     ORA-01157: cannot identify/lock data file N - see DBWR trace file
     ORA-01110: data file 1: '<filename>'
     ORA-27092: skgfofi: size of file exceeds file size limit of the process
     Additional information: xxxxx
     Additional information: yyyyy


     Oracle 8.1.7では、データベースをオープンする際に、OSでのリミット
     におけるより厳密なチェックを行います。
     8.1.6までは、Server Managerクライアントのプロセスのファイルサイズ
     における(ソフト)リミットが、データベースの最大のデータファイルより
     小さい値に設定された状態で、データベースをオープンすることが可能でした。
     しかし、8.1.7からは、ファイルサイズのリミットの方が小さい場合、
     データベースはオープンされず、上記のエラーで失敗します。

     これを回避するには、Oracleプロセスのulimitの値を増加させます。

     これを行うには、次のコマンドを使用できます(Unixのプロンプトから)。
	 
     $ ulimit -f   <require_size_of_file_in_os_blocks>;

     これについての詳細は、ulimitのman pageを参照してください。



C.  移行の際にORA-1157が返されるケース
***************************************


1. 移行ユーティリティ(MIG.EXE)を使用してOracle7データベースをOracle8iへ
   移行しようとして、alter database convertを実行すると、
   次のエラー・スタックが発生します。

    ORA-1157  cannot identify datafile <name> - file not found
    ORA-1110  datafile <name>: <str>

   これは、データファイルへのフルパスを指定せずに、
   新しい表領域または新しいデータファイルのいずれか
   (またはその両方)をデータベースへ追加した場合に起こります。
   その後、ファイル名は指定され、パスは指定されていない状態で
   制御ファイルが更新されます。
   データファイルは現行のデフォルトのロケーション内に正常に
   作成されるため、この時点では、パスが含まれていないことは
   明白ではありません。

   移行ユーティリティはconvert.oraファイルの情報の構築に
   Oracle7制御ファイルを使用し、これが制御ファイルから欠落しているため、
   convert.ora内で正しく指定できません。

   これを解決するには、まず%Oracle_home%\rdbmsxx\convert.oraファイルを
   チェックして、フルパスを含んでいないデータファイルを特定します。
   エラー・スタック内にリストされている、フルパスが指定されていない
   データファイルを探し、そのファイルをそのロケーションへコピーして、
   alter database convertを再度実行します。

   解決法のもうひとつのオプションとして、Oracle7データベースをリストアし、
   alter database datafile rename fileコマンドを使用して、
   制御ファイル内のデータファイルのパス情報を変更する方法があります
   (手順についてはDocument 115424.1を参照してください)。
   その後、移行プロセスを初めから再度行ってください。
 

2. 移行ユーティリティを使用してOracle 7.3.xから8.1.xへ移行中、
   alter database convertを実行すると、次のエラーが発生することがあります。

   ORA-01157: cannot identify/lock data file 2 - see DBWR tracefile
   ORA-01110: data file 2: '/u01/datafiles/V734/users01.dbf' 
   ORA-27046: file size is not a multiple of logical block size         
   Additional information:1    

   このエラーが発生する理由は、Oracle 8.1.xではOracle 7.3.xよりも
   厳密なファイル・チェックが行われるため、
   Oracle V7よりも検出されるエラーが増えることがあるためです。
	
   このケースでは、ファイル・サイズがORACLEブロック・サイズの厳密な
   倍数ではありません。
   これは通常、RAW DEVICE上のデータファイルが非ロー・ファイルシステムへ
　　"dd"(コピー)が行われることで起こります。


   実際のデータファイル・サイズをコピーする代わりに、
   通常はデータファイル・サイズより大きいトータルのボリューム・サイズが、
   大きいか切り捨てられているかの正しくないデータファイル・サイズで、
   非ロー・ファイルシステムへ"dd"(コピー)されます。
	
   例:

     file size =  839911424 bytes
     Oracle block size = 8092 bytes

   この場合の問題を修正するには、Oracle7環境をスタートアップし、
   関連するデータファイルをリサイズして、データファイルのサイズが
   厳密にOracleブロック・サイズの倍数になるようにします。

   SQL>  ALTER DATABASE DATAFILE '<filename>' RESIZE <VALUE IN KB OR MB>;   
          - この例では、整数は8の倍数である必要があります。

   あるいは、次のメソッドを使用することもできます。

    (1) 失敗するデータファイルに対してdbfsizeコマンドを使用して、
        データベースのサイズを取得します。
 
         $dbfsize <file_name>
 	
    (2)  OSのファイル・サイズを調べます。

	 $ls -lt <file_name>

    (3) mod()ファンクションを使用してデータベースのサイズとOSのサイズを
        比較し、剰余を求めます。

    (4) 問題を修正するために、データベースがシャットダウンされていることを
        確認し、ddコマンドを使用します。

	例:

	OSのファイル・サイズが2097203200バイトであり、dbfsizeの出力が
    511744 4096バイト・ブロックである場合、Unixのコマンド・プロンプトから
    次のように実行します。
	
	    $dd if=<some_name>bs=4096 count=511745
	
  	    NB: count= 511744 + 1 (この問題を修正するために1を指定します)

	    $mv <some_file> to <file_name>

    (5)	 SVRMGR> startup nomount
	     SVRMGR> alter database convert;

         データファイルをリサイズすることにより、
         OracleとOSとのファイル・サイズが再びマッチするようになるため、
         移行ユーティリティを再度実行してalter database convertを
         再試行することができます。
        

D. ORA-1157エラーの他の考えられる原因
**************************************


1. 破損した制御ファイルによりORA-1157が返されるケース:

   制御ファイルが破損しているなどの極端なケースで、ORA-1157が返される
   ことがあります。

   このエラーの原因となり得る破損のタイプのひとつに、
   制御ファイル内のファイル名の後に空白が含まれている場合があります。
   これは、ALTER DATABASE BACKUP CONTROLFILE TO TRACEコマンドを使用して
   生成される制御ファイルのテキスト・バージョンを調べると、
   見つけることができます(トレース・ファイルは、user_dump_dest
   初期設定パラメータで指定されるロケーションに置かれます)。
 
   例: 
   --- 
 
   '/home/d/Oracle/oradata/ecn/rdx02.dbf '  <-- 破損
   '/home/d/Oracle/oradata/ecn/rdx02.dbf'   <-- 破損していない
 
   この場合の解決法は、破損制御ファイルを除外するために、
   init.ora内のCONTROL_FILESパラメータを変更して、
   他の制御ファイルのコピーを使用する(それらが破損していない場合)ことです。

   制御ファイルがすべて破損している場合は、制御ファイルを再作成します。

   制御ファイルの再作成に関する情報については、Note:1012929.6を
   参照してください。

   また、制御ファイル内に他の「予期せぬ」制御文字が埋め込まれている
   ことが原因となるケースもあります。

   たとえば、データファイル名に"^J"が存在する場合などです。

   このケースにも上記の解決法を適用できます。


2. スタンバイ・データベースがセットアップされた後で
   プライマリ・データベースに追加された表領域や
   データファイルがないかどうかをチェックします。

   追加されている場合は、スタンバイ・データベース上にそのデータファイルを
   手動で作成します。ファイルが存在すると、リカバリは続行できます。
 
   データファイルは、スタンバイ・サイト上に自動的には作成されません。

   例:
   
   redoは、ユーザーに代わって新しいデータファイルを作成することはしません。
 
   startup mountからのcreate datafileコマンドは次のようになります。
 	
   alter database create datafile '<datafile_full_path_name>';


3. RMANのリストアで、alert.log内にORA-1157エラーが誤って表示されるケース:

   RMANのリストアのオペレーション中に、alert.log内に次のエラーが
   表示されることがあります。

   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でリストアしている場合に起こります。
 
   これらのエラー(このエラーは、影響のある各データファイルについて
   複数回発生します)は、データベース管理者にとって混乱のもとになる
   可能性があります。しかし、これらはまったく予期どおりのものであり、
   alert.logのサイズのモニタ(および、必要な場合はアーカイブ)を別にすれば、
   何も心配する必要はありません。



4. 新しくインストールされたシード・データベースでORA-1157が返されるケース:
	
   シード・データベースが使用された場合、OracleはCDからディスクへ
   データファイルをコピーして、データベースを起動しようとします。
   しかし、そのデータファイルがCD内で破損している場合、
   つまりCDに損傷がある場合は、ORA-1157エラーの原因となることがあります。

   これに対する解決法は、新しいCDのセットを使用するか、
   あるいは手動の作成スクリプトを使用してデータベースを作成することです。

 注意: 

   Oracle9iを使用している場合は、上記のコマンドの実行に、
   Sever ManagerではなくSQL*Plusを使用してください。
   これは、Server ManagerはOracle9i内では使用可能ではないためです。