1. アップグレード・ガイド
  2. Oracle Databaseのアップグレード
  3. Oracle Databaseのアップグレードのトラブルシューティング

Oracle Databaseのアップグレードのトラブルシューティング

これらのトラブルシューティングのヒントを使用して、データベースのアップグレード中に発生する可能性のあるエラーまたは問題に対処します。

また、関連リンクも参照して、発生したエラーに関連する可能性のある、このリリースに影響する変更を理解し、エラーの解決後にアップグレードを再実行する方法について確認してください。

関連項目

親トピック: Oracle Databaseのアップグレード

Oracle Databaseのアップグレード・モードでの起動について

Oracle Databaseをアップグレード・モードで起動する場合、固定ビューに対する問合せのみを実行できます。他のビューまたはPL/SQLを実行しようとしても、ここに記載されているエラーが発生します。

データベースがアップグレード・モードで起動された場合、パラレル・アップグレード・ユーティリティ(直接catctl.plで、またはdbupgradeスクリプトを使用して)を実行するまでは、修正したビューでの問合せだけがエラーなしで実行されます。アップグレード・スクリプトを実行する前は、他のビューへの問合せやPL/SQLの実行で、エラーが戻されます。

この項に記載されているエラーは、新しいOracle Databaseリリースの起動を試みると発生する可能性があります。これらのエラーの一部はアラート・ログに記録され、セッションには表示されません。いずれかのエラーが表示された場合、 SHUTDOWN ABORTコマンドでデータベースを停止し、問題を修正します。

  • ORA-00401: パラメータcompatibleの値はこのリリースではサポートされません。

    COMPATIBLE初期化パラメータが11.2.0未満に設定されている場合。

  • ORA-39701: データベースをUPGRADEまたはDOWNGRADE用にEXCLUSIVEでマウントしてください

    CLUSTER_DATABASE初期化パラメータがFALSEではなく、TRUEに設定されている場合。

  • ORA-39700: データベースは、UPGRADEオプションを使用してオープンしてください

    UPGRADEキーワードを指定しないでSTARTUPコマンドを発行した場合。

  • Ora-00704: ブートストラップ障害

    パス変数が以前のリリースのOracleホームを指している可能性がある場合。

  • ORA-00336: ログ・ファイルのサイズxxxxが最小値8192より小さくなっています

    REDOログのサイズが4MB未満の場合。

サポートが終了した初期化パラメータを示すエラーが表示された場合は、そのサポートが終了した初期化パラメータをノートにとり、アップグレードを継続します。次回、データベースを停止したときに、そのサポートが終了した初期化パラメータを削除します。

関連項目

親トピック: Oracle Databaseのアップグレードのトラブルシューティング

異なるORACLE_HOME所有者でのDBUAの実行

Oracle Databaseホームが異なるオペレーティング・システム・ユーザー・アカウントによって所有されているか、「upgrade.xmlが見つかりません」エラーが発生した場合、このトピックを参照してください。

DBUAのアップグレードでは、デフォルトで、ソース(Oracle Database 12cより前のリリース)のOracleホームと宛先(新しい12c)のOracleホームが両方とも同じユーザーに所有されていると想定されます。各Oracleホームが同じユーザーに所有されていない場合、データベース・ファイルの権限を変更し、DBUAに追加のパラメータを渡す必要があります。これを行わない場合、アップグレード中にDBUAの「前提条件チェック」ページに「upgrade.xmlが見つかりません」エラーがレポートされます。このエラーが修正されるまで、アップグレードを継続することはできません。

  • すべてのOracle Databaseインストール所有者は、プライマリ・グループとして、OINSTALLグループ(またはOracleインベントリ・グループ)に指定したグループを保持している必要があります。すべてのデータベース・ファイル(データファイル、REDOファイル、制御ファイル、アーカイブ・ログの保存先、リカバリ領域、SPFILEおよびパスワード・ファイル)が新しい12cと12cより前の両方のバイナリ所有者によって読取りおよび書込み可能であることを確認します。これに該当しない場合、各インストール所有者がそのプライマリ・グループと同じグループを保持していることを確認し、OINSTALLグループのメンバーが以前のリリースと新しいリリースのすべてのOracle Databaseファイルおよびディレクトリに読取り/書込みアクセスできることを確認してください。

  • -logdirコマンドライン・オプションを指定してDBUAを実行し、新しいリリースと以前のリリースの両方のバイナリ所有者が書き込むことのできるディレクトリを指定します。たとえば、/tmpのように入力します。DBUAは、logdirパラメータで指定されたディレクトリを使用して、アップグレード前情報ツールからの出力を格納し、アップグレード中に生成されたDBUAログ・ファイルを格納します。以前のリリースのOracle Databaseインスタンスのアップグレード前情報ツールは、以前のリリースのOracle Databaseインストール所有者のユーザー・アカウントとして実行します。

    次に例を示します。

    dbua -logdir /tmp

親トピック: Oracle Databaseのアップグレードのトラブルシューティング

無効なオブジェクトの警告およびDBAレジストリ・エラー

アップグレードを開始する前に、アップグレード前情報ツール(preupgrd.jar)を実行することを強くお薦めします。

アップグレード前情報ツールでは、無効なSYSおよびSYSTEMオブジェクト、さらに他の無効なオブジェクトが識別されます。utlrp.sqlを使用して、無効なオブジェクトを再コンパイルします。アップグレード前にこれを行わないと、システム内で、アップグレード前に無効であったオブジェクトと、アップグレード後に無効になったオブジェクトを判別するのが難しくなります。

関連項目

親トピック: Oracle Databaseのアップグレードのトラブルシューティング

無効なオブジェクトおよび時期尚早なアップグレード後ツールの使用

アップグレードが完了するまで、新しいOracle Database リリース(utlu122s.sql)に対してアップグレード後の状態ツールを実行しないでください。

アップグレード処理が完了し、utlrp.sqlを実行した後でのみ、アップグレード後の状態ツールを実行することをお薦めします。@utlrp.sqlを実行する前にアップグレード後の状態ツールが実行された場合、ツールの出力に正確な最終的コンポーネントの状態値が表示されないことがあります。utlrp.sqlを実行する前にツールが実行された場合、コンポーネントの状態値が最終的な状態を正確に反映しないことがあります。最終的なコンポーネント状態は、utlrp.sqlを実行した後でのみ特定できます。

親トピック: Oracle Databaseのアップグレードのトラブルシューティング

Oracle Databaseアップグレード・スクリプトの終了エラーの解決

ORA-00942、ORA-00904またはORA-01722エラーが発生した場合、この項を参照してください。

アップグレードの開始前にアップグレード前情報ツールを実行しないと、catctl.plおよびcatupgrd.sqlスクリプトが次のエラーで終了します。 

ORA-00942: table or view does not exist
ORA-00904: "TZ_VERSION": invalid identifier
ORA-01722: invalid number

これらのいずれかのエラーが発生した場合、次の手順を実行します。

  1. SHUTDOWN ABORTコマンドを入力し、コマンドが実行を完了するまで待機します。

  2. 元のOracleホーム・ディレクトリに戻ります

  3. アップグレード前情報ツールを実行します。

関連項目

親トピック: Oracle Databaseのアップグレードのトラブルシューティング

Oracle Databaseのアップグレード中におけるリソース制限エラーの原因のトラブルシューティング

リソース制限エラーを意味するORA-01650、ORA-01651、ORA-01652、ORA-01653、ORA-01654、ORA-01655、ORA-0431、ORA-01562、ORA-19815などのエラーが発生した場合、この項を参照してください。

アップグレード中にリソースが不足した場合は、リソースの割当てを増やします。リソースの割当てを増やした後、SHUTDOWN ABORTでインスタンスを停止し、UPGRADEモードでインスタンスを再起動してからcatupgrd.sqlスクリプトを再実行します。

通常、Oracle Databaseの新しいリリース用に増やす必要があるリソースは、次のとおりです。

  • SYSTEM表領域およびSYSAUX表領域

    SYSTEM表領域のサイズが不十分な場合、通常は次のエラー・メッセージが表示されます。 

    ORA-01650: unable to extend rollback segment string by string in tablespace string
ORA-01651: unable to extend save undo segment by string for tablespace string
ORA-01652: unable to extend temp segment by string in tablespace string
ORA-01653: unable to extend table string.string by string in tablespace string
ORA-01654: unable to extend index string.string by string in tablespace string
ORA-01655: unable to extend cluster string.string by string in tablespace string

    これらのエラーを回避するには、SYSTEMおよびSYSAUX表領域にAUTOEXTEND ON MAXSIZE UNLIMITEDを設定します。

  • 共有メモリー

    場合によっては、より大きな共有メモリー・プール・サイズが必要です。増やす必要がある共有メモリーの初期化パラメータが、次の形式でエラー・メッセージに示されます。

    ORA-04031: unable to allocate string bytes of shared memory ("string","string","string","string")

    参照:

    手動の共有メモリー管理の使用の詳細は、『Oracle Database管理者ガイド』を参照してください。

  • ロールバック・セグメント/UNDO表領域

    ロールバック・セグメントを使用している場合、アップグレード・スクリプトの実行中は、1つの大きい(100MBの)パブリック・ロールバック・セグメントをオンラインにする必要があります。小さいパブリック・ロールバック・セグメントは、アップグレード中はオフラインにする必要があります。ロールバック・セグメントのサイズが不十分な場合、通常は次のエラーが発生します。 

    ORA-01562: failed to extend rollback segment number string

    UNDO表領域を使用している場合は、400MB以上であることを確認してください。

  • 高速リカバリ領域

    高速リカバリ領域を使用していてアップグレード中にこの領域が一杯になった場合は、アラート・ログに次のエラーが表示され、その後に問題から復旧するためのアドバイスが表示されます。

    ORA-19815: WARNING: db_recovery_file_dest_size of string bytes is 98.99%
used, and has string remaining bytes available.

    問題の根本原因を特定し、アップグレードを続行するための適切な対処を行います。アップグレード中にこの問題が発生しないようにするには、アップグレードを開始する前に、高速リカバリ領域内の使用可能な領域を増やします。
    
                        
    • 
                     

                  

                  
               

               

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            
Oracle DatabaseでのSQL*Plusエディション・セッションの起動エラーの解決

               

                  
この項を使用して、SP2–1540: 「Oracle Databaseはエディション・セッションでは起動できません。」を理解および解決します。

                  
SQL*Plusでアップグレード・スクリプトまたはコマンドを実行してEDITIONパラメータを設定すると、それ以降Oracle Databaseを適切に起動できません。データベースを起動しようとすると、次のエラーが発生します。
                  
SP2-1540: "Oracle Database cannot startup in an Edition session"
この問題を回避するには、このパラメータが変更されるcatugrd.sqlまたはSQL*Plusセッションを実行した後に、そのSQL*Plusセッションを終了し、別のセッションでそのインスタンスを再起動します。
                  

               

               

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            

            
 エラーORA-00020 utlrp.sqlの実行中に処理の最大数が超過する

               

                  
このエラーは、使用するOracle構成にリコンパイルに必要な数のプロセスがないことを示します。

                  
PROCESSESパラメータの設定の詳細は、Oracleのマニュアルを参照してください。
                  

               

               

                  

                     
参照:

                     
『Oracle Databaseリファレンス』

                  

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            
アップグレード後のDBMS_DSTパッケージによるORA-01822の修正

               

                  
この手順を使用して、タイムゾーン・ファイルの不一致に関連するORA-01822およびORA-16512エラーを修正します。
                  

                  
Oracle Database 12cへのアップグレード後にDBMS_DSTパッケージを実行すると、ORA-01882: 「タイムゾーンのリージョンが見つかりません」エラーが発生する場合があります。
                  

                  
このエラーは、タイムゾーン・ファイルのバージョンが正しく設定されていない場合に返されます。タイムゾーンの設定が正しくないと、いくつかのタイムゾーン・リージョンのリージョンIDがデータベースに正しく格納されないことがあります。次に例を示します。
ERROR at line 1:
@  ORA-01882: time zone region not found
@  ORA-06512: at "SYS.DBMS_DST", line 113
@  ORA-06512: at "SYS.DBMS_DST", line 1101
@  ORA-06512: at line 1

この問題を修正するには、タイムゾーン・バージョンを更新してアップグレードを再実行します。

               

               

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            

            
「ORA-28365: ウォレットがオープンしていません」エラーの修正

               

                  
透過的暗号化(TDE)によるOracleウォレットを使用しており、Database Upgrade Assistant (DBUA)を使用してデータベースをアップグレードする場合は、ORA-28365「ウォレットが開いていません」エラーが発生する可能性があります。 

                  
この問題を回避するには、アップグレード前に次の作業を行います。 

                  
                  
    
                     
  1. 許可ユーザーとしてログインします。
    2. 
                     
  2. sqlnet.oraファイル、そしてウォレット・ファイルewallet.p12を新しいリリースのOracleホームに手動でコピーします。
    3. 
                     
  3. マウントされているOracleウォレットをオープンします。
    
                           
    次に例を示します。
    SQL> STARTUP MOUNT;
SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN
    
                     
    4. 
                     
  4. 通常どおり、アップグレードを開始します。
    5. 
                  

               

               

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            

            
ビューCDB_JAVA_POLICYの問題の解決

               

                  
ビューCDB_JAVA_POLICYが無効になった場合は、この手順を使用します。 

                  

                     
Oracle Database 12cリリース2 (12.2)以降のリリースへのアップグレード後、またはリリース12.2以降のリリースから12.1へのダウングレード後に、CDB_JAVA_POLICYビューに関する問題が発生することがあります。通常は機能する方法でビューを使用しているときにCDB_JAVA_POLICYが無効になるか、またはエラーが発生することがあります。エラーが発生した場合はSYSとして接続し、次のコマンドを実行します。
                     

                  

                  
                  

                     
非CDB:
alter session set "_ORACLE_SCRIPT"=true;

exec CDBView.create_cdbview(false,'SYS','dba_java_policy','CDB_java_policy');

grant select on SYS.CDB_java_policy to select_catalog_role
/
create or replace public synonym CDB_java_policy for SYS.CDB_java_policy
/

マルチテナント・アーキテクチャ・システム:

                     
同じこれらのコマンドを実行しますが、まずCDB$ROOTで、次にCDBの他のコンテナで実行します。

                  

                  
               

               

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            
 サーバーの再起動後のアップグレードの継続(ADVM/ACFSドライバ・エラー)

               

                  
Windowsプラットフォームでは、アップグレード中にサーバーが再起動した場合に、ADVMドライバまたはACFSドライバ関連のエラーが発生する可能性があります。

                  
サーバーがアップグレード中に再起動した場合、次のいずれかのエラー・メッセージが表示されることがあります。
ACFS-9427: Failed to unload ADVM/ACFS drivers. A system reboot is recommended

ACFS-9428 Failed to load ADVM/ACFS drivers. A system reboot is recommended.
    
                     
  • 
                        
    原因
    
                        
    ADVMドライバとACFSドライバがまだ使用中です。システムを再起動して新しいドライバを起動する必要があります。
    
                     
    • 
                     
  • 
                        
    処置
    
                        
    次の手順に記載されているステップを完了します。
    
                     
    • 
                  

                  
最初のノード(アップグレードを開始したノード)以外のノードで、次の手順を実行します。

                  
    
                     
  1. 
                        
    エラーが発生したノードを再起動します。
    
                     
    2. 
                     
  2. 
                        
    そのノード上で、rootスクリプトを再度実行します。
    
                     
    3. 
                  

                  
最初のノード(アップグレードを開始したノード)で、次の手順を実行します。

                  
    
                     
  1. 
                        
    クラスタ内の他のすべてのノードでアップグレードを完了します。
    
                     
    2. 
                     
  2. 
                        
    最初のノードを再起動します。
    
                     
    3. 
                     
  3. 
                        
    最初のノード上で、rootスクリプトを再度実行します。
    
                     
    4. 
                     
  4. 
                        
    アップグレードを完了するには、rootでログインし、パスGrid_home/cfgtoollogs/configToolAllCommandsにあるスクリプトconfigToolAllCommandsを実行します。
                        
    
                     
    5. 
                  

                  

                  
               

               

                  

                     
参照:

                     
クラスタのアップグレードの問題のトラブルシューティングの詳細は、使用しているオペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。
                     

                  

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            

            
コンポーネント・ステータスおよびアップグレード

               

                  
コンポーネント・ステータス設定は、インストール済のコンポーネント、およびそれらのコンポーネントがアップグレード対象としてサポートされるかどうかの両方の要因に左右されます。

                  
トピック:

               

               

                  
                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
アップグレード後の状態ツールを使用したコンポーネント・ステータスの理解

                  

                     
アップグレード後の状態ツール(utlu122s.sql)は、アップグレードの完了後にデータベース・コンポーネント・ステータスをレポートします。 
                     

                     
アップグレード後の状態ツール(utlu122s.sql)は、アップグレード後に、またはutlrp.sqlで無効なオブジェクトを再コンパイルした後にいつでも実行できます。 
                     

                     
次のリストでは、アップグレード後の状態ツールによってレポートされるステータス値を簡単に説明します。

                     
    
                        
  • 
                           
    INVALID
    
                           
    アップグレードが完了したときに、コンポーネントの一部のオブジェクトが無効な状態のまま残されました。コンポーネント・アップグレードのログ・ファイルにエラーが見つからない場合、スクリプトutlrp.sqlを実行します。このスクリプトを実行することで、アップグレード全体を再実行せずに無効なコンポーネントのステータスをVALIDに変更できる可能性があります。utlrp.sqlを実行した後に、DBA_REGISTRYビューを確認します。 
                           
    
                        
    • 
                        
  • 
                           
    VALID
    
                           
    コンポーネントは有効で、エラーがありません。
    
                        
    • 
                        
  • 
                           
    LOADING
    
                           
    コンポーネントはロード中です。
    
                        
    • 
                        
  • 
                           
    LOADED
    
                           
    コンポーネントは正常にロードが終了しました。
    
                        
    • 
                        
  • 
                           
    UPGRADING
    
                           
    コンポーネントはアップグレードの処理中です。
    
                        
    • 
                        
  • 
                           
    UPGRADED
    
                           
    コンポーネントはアップグレードが完了し、エラーがありません。 
    
                        
    • 
                        
  • 
                           
    DOWNGRADING
    
                           
    コンポーネントはダウングレードの処理中です。
    
                        
    • 
                        
  • 
                           
    DOWNGRADED
    
                           
    コンポーネントはダウングレードが完了し、エラーがありません。
    
                        
    • 
                        
  • 
                           
    REMOVING
    
                           
    コンポーネントは削除の処理中です。
    
                        
    • 
                        
  • 
                           
    REMOVED
    
                           
    データベースから削除されたため、コンポーネントはアップグレードされませんでした。
    
                        
    • 
                        
  • 
                           
    OPTION OFF
    
                           
    コンポーネントに必要なサーバー・オプションがインストールされていないか、またはサーバーとリンクされていません。V$OPTIONビューおよびインストール・ログを確認します。コンポーネントをインストールするか、サーバーを必要なオプションと再リンクしてから、パラレル・アップグレード・ユーティリティを再実行します。 
                           
    
                        
    • 
                        
  • 
                           
    NO SCRIPT
    
                           
    コンポーネント・アップグレード・スクリプトが$ORACLE_HOMEに見つかりませんでした。インストール・ログを確認し、コンポーネント・ソフトウェアをインストールしてから、パラレル・アップグレード・ユーティリティを再実行します。
    
                        
    • 
                     

                     

                        
ノート: 

                        
パラレル・アップグレード・ユーティリティを実行できます(LinuxおよびUNIXではコマンドライン・スクリプトdbupgradeを、Windowsではdbupgrade.cmdを使用してcatctl.plを実行)。
                        

                     

                  

                  

                     

                        
関連項目

                        
                     

                     

                        

                           
親トピック: コンポーネント・ステータスおよびアップグレード

                        

                     

                  

               

               
OPTION OFFコンポーネントのステータスおよびアップグレード

                  

                     
OPTION OFFコンポーネントのアップグレード・ステータスは、ターゲット・リリースでコンポーネントがサポートされるかどうか、およびコンポーネントをアップグレードの一環としてアップグレードする必要があるかどうかの両方の要因に左右されます。
                     

                     
OPTION OFFコンポーネントがアップグレードされるかどうかは3つのケースに分かれます。

                     

                        
ステータスがOPTION OFFのサポート対象外コンポーネント

                        
データベースにステータスがOPTION OFFのコンポーネントが存在し、そのコンポーネントがターゲット・リリースへのデータベース・アップグレードの対象としてサポートされない場合、該当するコンポーネントはアップグレードされません。アップグレード後、そのバージョンおよびステータスは変更されません。

                     

                     
                     

                        
ステータスがOPTION OFFのサポート対象コンポーネント

                        
データベースにステータスがOPTION OFFのコンポーネントが存在し、そのコンポーネントがターゲット・リリースへのデータベース・アップグレードの対象としてサポートされる場合、該当するコンポーネントはアップグレードされます。アップグレード後、コンポーネントのバージョンはターゲット・リリースのバージョンと一致します。このコンポーネントのステータスは、UPGRADED (正常なアップグレード)またはINVALID (エラー)のいずれかになります。アップグレード対象のすべてのコンポーネントのステータスがUPGRADEDになるまで、必要に応じてアップグレードを再実行してください。次に、utlrp.sqlを実行します。アップグレード前のコンポーネントのステータスがOPTION OFFであった場合、アップグレード後、コンパイルと検証が正常に終了したら、ステータスがOPTION OFFに戻ります。
                        

                     

                     
                     

                        
アップグレードを求める必須オプションが設定されたサポート対象コンポーネント

                        
Oracle Database 18.1以上では、必須オプションが設定されたコンポーネントはすべてアップグレードする必要があります。該当するコンポーネントは次のとおりです。

                        
    
                           
  • 
                              
    RAC
    
                           
    • 
                           
  • 
                              
    SDO
    
                           
    • 
                           
  • 
                              
    APS
    
                           
    • 
                           
  • 
                              
    XOQ
    
                           
    • 
                        

                        
アップグレードが必要なコンポーネントは、ステータスがOPTION OFFの標準のサポート対象コンポーネントの場合と同じ手順に従ってアップグレードされます

                     

                     
                  

                  

                     

                        

                           
親トピック: コンポーネント・ステータスおよびアップグレード

                        

                     

                  

                  
               

               
アップグレード・サマリー・レポートの例 

                  

                     
アップグレード・サマリー・レポートでは、コンポーネントのアップグレード・ステータスに関する情報が提供されます。

                     
アップグレードが完了すると、Oracle Database 12cリリース2以上では、アップグレード・ユーティリティ・スクリプト(たとえば、12.2および18cの場合はutlu1212.sql)によって、次の書込み順序を使用してレポートのコピーが書き込まれます。
                     

                     
    
                        
  1. 
                           
    ORACLE_BASE/cfgtoollogs/db_unique_name/upgradeYYMMDDHHMMSC/upg_summary.rpt
    
                        
    2. 
                        
  2. 
                           
    $ORACLE_HOME/rdbms/log/upg_summary.rpt
    
                        
    3. 
                        
  3. 
                           
    LinuxおよびUNIX:
    /tmp/upg_summary.rpt
    Windowsの場合:
     \TEMP\upg_summary.rpt
    4. 
                     

                     
ユーティリティ・スクリプトは、最初のディレクトリ・スキームにレポートを作成できない場合、引き続き2番目の場所、3番目の場所の順に書込みを試みます。これらのどのパスにも書き込むことができない場合、アップグレード・サマリー・レポートは書き込まれません。Oracle Database 18cの例を示します。

                     

                        
例3-40 アップグレード後の状態ツールのアップグレード・サマリー・レポート

Oracle Database Release 18 Post-Upgrade Status Tool    05-27-2018 23:41:0

Component                               Current         Full     Elapsed Time
Name                                    Status          Version  HH:MM:SS

Oracle Server                          UPGRADED      18.3.0.0.0  00:18:21
JServer JAVA Virtual Machine           UPGRADED      18.3.0.0.0  00:04:31
Oracle XDK                             UPGRADED      18.3.0.0.0  00:00:51
Oracle Database Java Packages          UPGRADED      18.3.0.0.0  00:00:22
OLAP Analytic Workspace                UPGRADED      18.3.0.0.0  00:00:51
Oracle Label Security                  UPGRADED      18.3.0.0.0  00:00:20
Oracle Database Vault                  UPGRADED      18.3.0.0.0  00:00:40
Oracle Text                            UPGRADED      18.3.0.0.0  00:01:37
Oracle Workspace Manager               UPGRADED      18.3.0.0.0  00:01:10
Oracle Real Application Clusters       UPGRADED      18.3.0.0.0  00:00:00
Oracle XML Database                    UPGRADED      18.3.0.0.0  00:02:17
Oracle Multimedia                      UPGRADED      18.3.0.0.0  00:03:01
Spatial                                UPGRADED      18.3.0.0.0  00:06:23
Oracle OLAP API                        UPGRADED      18.3.0.0.0  00:00:22
Upgrade Datapatch                                                00:00:10
Final Actions                                                    00:00:20
Post Upgrade                                                     00:00:05
Post Upgrade Datapatch                                           00:00:04

Total Upgrade Time: 00:41:45

                     
                  

                  

                     

                        

                           
親トピック: コンポーネント・ステータスおよびアップグレード

                        

                     

                  

                  
               

            

            
Standard Editionの初期データベースおよびステータスがOPTION OFFのコンポーネント

               

                  
Oracle Database 18c (18.1)以降、すべてのOPTION OFFコンポーネントは新しいリリースにアップグレードされますが、Oracle Database Standard Edition (SE)では、これらのオプションはOPTION OFFのまま無効化されます。
                  

                  
Oracle Database Standard Edition (SE)初期データベースをアップグレードする場合、初期データベースに含まれないコンポーネントはオンになり、アップグレードされます。utlrp.sqlを実行すると、サーバーでオンになっておらず、SEに含まれていないオプションは、DBA_REGISTRYビューでOPTION OFFにリセットされます。
                  

               

               

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            
 アップグレード後のOracle ASMパスワード・ファイルの場所の調整

               

                  
Oracle Grid Infrastructureのアップグレード後にOracle ASMの新しいパスワード・ファイルを作成する必要があります。 

                  

                     
Grid Infrastructureのアップグレード後、srvctl config asmを実行すると、コマンド出力にはOracle ASMパスワード・ファイルの場所は表示されません。パスワード・ファイルの場所は、新しいOracle ASMディスク・グループに自動的には渡されません。SRVCTLがアップグレード後のパスワード・ファイルの場所を特定できるようにするには、ディスク・グループの互換性の設定を拡張し、ディスク・グループにPWFILEを作成する必要があります。SRVCTLは、共有PWFILEの構成済の場所を報告します。
                     

                  

                  
               

               

                  

                     
参照:

                     
ディスク・グループでの共有パスワード・ファイルの管理の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください
                     

                  

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            

            
プラガブル・データベースのアップグレードでの「警告: XDBは現在無効です」エラーの修正

               

                  
プラガブル・データベース(PDB)のアップグレード時に「警告: XDBは現在無効です、無効なオブジェクトが見つかりました」というエラーが発生した場合、このトピックを参照してください。 

                  

                     
Oracle Database 12cリリース1 (12.1)のプラガブル・データベース(PDB)をOracle Database 12cリリース2 (12.2)以上のマルチテナント・コンテナ・データベース(CDB)に接続する場合に、XMLオブジェクト・エラーが発生する可能性があります。 
                     

                     
 オブジェクト・リレーショナルXMLスキーマにシステム生成の名前を登録することで、共通オブジェクト(dba_objectsにsharing='METADATA LINK'を含むオブジェクト)が作成されます。これらの共通タイプは、オブジェクト・リレーショナル記憶域に複数のORDSYSスキーマを登録することで作成されます。 
                     

                     
これらの共通オブジェクトの名前はシステムによって生成されますが、リリース12.1で生成される名前は、リリース12.2以上でそれらのオブジェクトに使用される名前と異なる場合があります。これらの名前変更の可能性により、リリース12.1のオブジェクト・タイプは、リリース12.2以上のCDBルートの共通タイプと一致しないことがあります。

                  

                  
                  

                     
この問題を解決するには、次の手順を使用します。 

                  

                  
                  
    
                     
  1. ターゲットCDBルートのPDB_PLUG_IN_VIOLATIONSビューを問い合せ、'GetTypeDDL'を含むアクションが存在するかどうかを確認します
    'GetTypeDDL'アクションが見つかった場合、アップグレードしたPDBに共通オブジェクトの問題があります。 
                        
    
                     
    2. 
                     
  2. ターゲットPDBでPL/SQLパッケージSET SERVEROUTPUT ONおよびexec xdb.DBMS_XMLSTORAGE_MANAGE.GetTypeDDLを実行し、ユーザー指定のSQLスクリプト(script1.sqlなど)を生成します。
    3. 
                     
  3. 12.1のソースCDBで、ステップ2で作成したスクリプト(script1.sqlなど)を実行し、エラーが発生した共通タイプごとにタイプ作成スクリプトを取得します
    4. 
                     
  4. これらの作成スクリプトを含む別のユーザー指定のSQLスクリプト(script2.sqlなど)を生成します。
    5. 
                     
  5. 12.1のソースCDBで作成したスクリプト(script2.sqlなど)をターゲットPDBで実行します。
    
                     
    6. 
                  

                  
リリース12.1のソースCDBのタイプ作成スクリプトから生成されたスクリプトによって、ターゲットPDBにこれらすべてのオブジェクトが生成されます。通常、ターゲットPDBでこれらの共通オブジェクトを使用できるようにすることで、無効なXDBエラーは解消します。

                  
               

               

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            
ORA-27248: 「sys.dra_reevaluate_open_failuresが実行されています」の修正

               

                  
この手順を使用して、アップグレードをブロックしているDRA_REEVALUATE_OPEN_FAILURESジョブを特定します。
                  

                  
アップグレード時に、DBUAがエラーORA-27248: 「sys.dra_reevaluate_open_failuresが実行されています」で失敗した場合、アップグレードの障害の原因となるジョブDRA_REEVALUATE_OPEN_FAILURESが実行されています。アップグレードを継続する前に、このジョブが停止していることを確認してください。 
                  

                  
ジョブ定義で、ALLOW_RUNS_IN_RESTRICTED_MODEがTRUEに設定され、ジョブ所有者が制限モード中にログインできる場合、データベースが制限モードやアップグレード・モードでもそのジョブを実行できます。このパラメータのデフォルトの設定はFALSEです。 
                  

                  
次の問合せを使用して、実行中のジョブの状態を確認してください。
SQL> select OBJECT_NAME, Owner, OBJECT_TYPE from dba_objects whereobject_name like '%DRA_REEVA%';


               

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            

            
「ORA-22288: ファイルまたはLOB操作FILEOPENがパスのソフト・リンクで失敗」の修正

               

                  
ORA-22288は、BFILESをオープンするときにシンボリック・リンクがディレクトリ・オブジェクトのパスまたはファイル名にある場合に発生します。

                  

                     
ディレクトリ・オブジェクトまたはBFILEオブジェクトを作成するときには、次の条件を満たす必要があります。

                     
    
                        
  • 
                           
    オペレーティング・システム・ファイルが、シンボリック・リンクまたはハード・リンクではないこと。
    
                        
    • 
                        
  • 
                           
    Oracleディレクトリ・オブジェクトに指定されているオペレーティング・システム・ディレクトリ・パスが、既存のオペレーティング・システム・ディレクトリ・パスであること。
    
                        
    • 
                        
  • 
                           
    Oracleディレクトリ・オブジェクトに指定されているオペレーティング・システム・ディレクトリ・パスのコンポーネントに、シンボリック・リンクが含まれていないこと。
    
                        
    • 
                     

                  

                  
                  

                     
BFILEを開くときに、ディレクトリ・パスとファイル名全体がチェックされます。シンボリック・リンクが検出されると、次のエラーが表示されます。
 ORA-22288: file or LOB operation FILEOPEN failed soft link in path

                  
                  

                     
このエラーを解決するには、シンボリック・リンクを削除し、さらに、BFILEを作成するための他の要件に従います。 

                  

                  
               

               

                  

                     
関連項目

                     
                  

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

            

            
Oracle Databaseエンタープライズ・ユーザー・セキュリティ、OLS-OIDおよびプロビジョニング・プロファイルのエラーの修正

               

                  
参照してORA-16000: 「データベースは読取り専用アクセスでオープンされています。」エラーを理解してください。
                  

                  

                     
OLSを使用するデータベースおよびスタンバイ・データベースをアップグレードすると、ORA-16000 (データベースは読取り専用アクセスでオープンされています。)が表示される場合があります。スイッチオーバー後、プロビジョニング・プロファイルを新しいプライマリの接続情報で更新してください。プロビジョニング・プロファイルを更新しないと、新しいスタンバイ(前のプライマリ)にポリシーが伝播し続け、データベースのORA-16000エラーの障害は解消しません。

                  

                  
               

               

                  

                     
参照:

                     
Oracle Databaseをリリース10g (10.1)以上からOracle Database 12cにアップグレードする際に必要な追加のステップの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください

                  

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            

            
utl32k.sqlおよびMAX_STRING_SIZEによる32K移行エラーの修正

               

                  
この手順を使用して、ORA-01722: 「数値が無効です。」というアップグレード・エラーを修正します。
                  

                  
初期化パラメータMAX_STRING_SIZEがEXTENDEDに設定されているが、utl32k.sqlスクリプトによって実行される32K移行が完了していない場合、データベース・アップグレードは次のエラーで失敗します。
                  
SELECT TO_NUMBER('32K_MIGRATION_NOT_COMPLETED')
                    *
      ERROR at line 1:
      ORA-01722: invalid number

データベース・アップグレードではutl32k.sqlスクリプトを自動的に実行せず、32K移行を実行しません。 
                  

                  
この手動の手順を使用して、アップグレードと32Kマイグレーションを完了します。

                  
    
                     
  1. 
                        
    初期化パラメータMAX_STRING_SIZEをSTANDARDにリセットします。 
                        
    
                     
    2. 
                     
  2. 
                        
    UPGRADEモードでデータベースを再起動します。
                        
    
                     
    3. 
                     
  3. 
                        
    手動による手順を使用してアップグレードを再実行します。
    
                     
    4. 
                     
  4. 
                        
    データベースのアップグレード後、初期化パラメータMAX_STRING_SIZEをEXTENDEDに設定します。
                        
    
                     
    5. 
                     
  5. 
                        
    UPGRADEモードでデータベースを再起動します。
                        
    
                     
    6. 
                     
  6. 
                        
    SQLスクリプト../rdbms/admin/utl32k.sqlを実行します。
                        
    
                     
    7. 
                  

                  
utl32k.sqlスクリプトを実行すると、アップグレードしたデータベースで32K移行が完了し、EXTENDEDパラメータがサポートされます。
                  

               

               

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            

            
CRSの停止およびローリング移行を失ったOracle ASMからのリカバリ

               

                  
Cluster Ready Services (CRS)がすべてのクラスタ・メンバーで停止すると、クラスタが異種状態になる可能性があります。この手順を使用して、この問題から回復します。

                  
CRSがすべてのノードで停止した場合、Oracle Automatic Storage Management (Oracle ASM)ではローリング移行状態が失われます。このCRSの停止によって、異種状態が発生し、すべてのクラスタ・メンバー・ノードを再起動できなくなる可能性があります。クラスタで異なるバージョンの2つのノードを起動することはできません。異なるバージョンのOracle ASMが実行されているノードを起動しようとすると、Oracle ASMノードが実行されている異種ノードのセットのいずれかに障害が発生し、ORA-15153またはORA-15163エラー・メッセージが生成されます。

                  
 Oracle Databaseリリース11.2.0.2で、リリース12.1.0.2にアップグレードされる4つのノード(node1、node2、node3およびnode4)の次のシナリオを考えてみます。

                  
    
                     
  • 
                        
    node1およびnode2は12.1.0.2にアップグレードされ、実行中です。
    
                     
    • 
                     
  • 
                        
    node3およびnode4は11.2.0.2のままで、実行中です。
    
                     
    • 
                     
  • 
                        
    すべてのCRSスタックがダウンしている停止があると考えます。クラスタは異機種状態のままです(つまり、11.2.0.2に2ノード、12.1.0.2に2ノード)。
    
                     
    • 
                  

                  
このシナリオを例として使用し、次の手順を実行します。

                  
    
                     
  1. 
                        
    以前のリリースのノードのみを再起動します。このシナリオでは、リリース11.2.0.2 (node3またはnode4、あるいはその両方)のノードを起動します。
    
                     
    2. 
                     
  2. 
                        
    12.1.0.2ノードを起動する前に、node3またはnode4でOracle ASMインスタンスに次のSQLコマンドを実行します。 
    ALTER SYSTEM START ROLLING MIGRATION TO '12.1.0.2'
    3. 
                     
  3. 
                        
    障害の時点から、記載されているアップグレード手順を継続します。 
    
                     
    4. 
                  

               

               

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            

            
データ型のバージョニングによるバージョン間のレプリケーション(ORA-26656)

               

                  
バージョニングによって影響を受けるユーザー定義のオブジェクト・タイプを確認してください。

                  
リリース12.1.0.2では、Oracleオブジェクト・タイプの属性に使用できるデータ型のバージョニングが導入されています(Oracle Bug#18897657を参照)。この機能により、リリース12.1.0.1データベースとリリース12.1.0.2データベースのバージョン間のレプリケーションは影響を受ける可能性があり、ORA-26656エラーが発生します。 

                  
ユーザー定義のオブジェクト・タイプにDATE、TIMESTAMP、TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONE、BINARY_FLOAT、BINARY_DOUBLE、NCHAR、NVARCHAR2、NCLOB、ANYDATAなどのオブジェクトの属性が含まれる場合、リリース12.1.0.1のすべてのインスタンスに必須のパッチ・セット更新18038108を適用する必要があります。
                  

               

               

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            

            
libclntsh.so.11.1での「参照シンボル・カウントが未定義です」エラー

               

                  
「参照シンボル・カウントが未定義です」、「共有オブジェクト・ファイルを開くことができません」などのエラーによってlibclntsh.so.11.1を参照するエラーが発生した場合、このトピックを参照してください。
                  

                  
Oracle Database 12cまたは18cへのアップグレード中に、libclntsh.so.11.1ファイルに対してリンクされているクライアント・アプリケーションが、Oracle Solaris、HP-UX ItaniumまたはIBM AIXプラットフォームで実行できない場合があります。その場合、次のようなエラー・メッセージが表示されます。
                  
referenced symbol count is undefined

                     
回避策

                     
影響を受けるクライアント・アプリケーションを新しいlibclntsh.so.12.2ファイル(Oracle Database 12cの場合)またはlibclntssh.so.18.1ファイル(Oracle Database 18cの場合)に対して再リンクします。
                     

                  

                  
               

               

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            

            
ISO 8601タイムスタンプを原因とするタイムスタンプ・エラーの解決

               

                  
Oracle Database 12c、18cまたはそれ以上のリリースへのアップグレード後にアプリケーションでタイムスタンプ・エラーが発生した場合、このトピックを参照してください。
                  

                  
ISO 8601は、国際標準化機構(ISO)および国際電気標準会議(IEC)によって策定された、日付と時刻関連のデータを交換するための国際標準です。この標準の目的は、数値で日付と時刻を記述する場合に異なる表記規則を使用するそれぞれの国の間で使用されるデータについて、日付と時刻の間違った解釈を避けるため、日付と時刻を表現するための共通の国際標準を提供することです。次に例を示します。
2015-09-23T19:25:25.123456+00:00
この標準を使用することをお薦めします。 

                  
デフォルトでは、初期化パラメータUNIFORM_LOG_TIMESTAMP_FORMATはTRUEに設定されます。ISO 8601標準を使用することでスクリプトが中断する場合、UNIFORM_LOG_TIMESTAMP_FORMATをFALSEに設定し、Oracle Database 12.2以上のリリースを、Oracle Database 12.1で使用していたタイムスタンプ形式に戻すことができます。初期化パラメータの変更後、ISO 8601タイムスタンプを使用できるようにスクリプトを修正してください。スクリプトでISO 8601標準を使用できるようになったら、パラメータをデフォルト値のTRUEに戻してください。 

               

               

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            

            
Datapatchのみが失敗した場合の失敗したアップグレードの修正

               

                  
アップグレード中にdatapatchが失敗した場合にのみ、datapatchを直接再実行します。 

                  

                     
 Datapatchスクリプトdatapatch.plは、PERLスクリプトです。一部のパッチ適用操作では、ORA-20001などのエラーのため、最終的なアップグレード後のパッチ適用は実行されないことがあります。Datapatchスクリプトのみが失敗した場合は、この問題を修正するためにアップグレードを再実行する必要はありません。かわりに、datapatch.plを直接実行します。 
                     

                  

                  
                  

                     
失敗したdatapatchを修正するには、Oracleユーザーとしてログインし、この手順を完了します。

                  

                  
                  
    
                     
  1. アップグレードされたOracleホームの中にあるOpatchディレクトリに変更します。
    $ cd $ORACLE_HOME/OPatch
    
                        
    
                     
    2. 
                     
  2. datapatchコマンドを実行します。
    $ ./datapatch -verbose
    
                     
    3. 
                  

               

               

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            

            
エラー「タイムゾーン・データファイルを下位バージョンにダウングレードすることはできません」

               

                  
アップグレード元のデータベースの夏時間(DST)バージョンがアップグレード先のデータベース・リリースのDSTより新しい場合、アップグレードを禁止するタイムゾーン・エラーが発生します。 

                  

                     
シナリオ: Database Upgrade Assistant (DBUA)を実行して、以前のリリースのOracle Databaseから新しいリリースのOracle Databaseにアップグレードするときに、次のエラーが発生します。
SEVERE: Timezone datafiles may not be downgraded to a lower version as a
result of an Oracle Database upgrade.
このエラーは、以前のリリースのOracle Databaseから新しいリリースのOracle Databaseにアップグレードし、以前のリリースのOracle Database Oracleホームに新しいアップグレードのOracle Database Oracleホームより新しいDSTパッチが含まれている場合に発生します。ログ・ファイルpreupgrade.logの中で、新しいOracle Database Oracleホームに古いOracleホーム内の更新版DSTパッチを適用するよう指示されます。次に例を示します。
                     
 
                  

                  
                  
+ Patch the new 12.2.0.1.0 $ORACLE_HOME/oracore/zoneinfo/ with the version 
29 time zone data file from the 12.1.0.2.0 
$ORACLE_HOME/oracore/zoneinfo/.   

The database is using a time zone file version that is newer than the
version shipped with the 12.2.0.1.0 release. 

Timezone datafiles may not be downgraded to a lower version as a result
of an Oracle Database upgrade.
ただし、このエラーは、新しいOracle Database Oracleホームにパッチを適用し、以前のリリースのOracleホームと同じバージョンにしても引き続き発生することがあります。

                  

                  
                  

                     
回避策:

                     
新しいOracleホームに最新のタイムゾーン・ファイルを適用してもこのエラーが引き続き発生する場合は、-ignorePreReqs trueフラグを指定してOracle Database Upgrade Assistantを実行します。アシスタントを次のように実行します 
                     
$ dbua -sid mydb -oracleHome /u02/product/12.2.0/dbhome_1/ -ignorePreReqs - true

                  
                  

                     

                        
注意:

                        
前提条件チェックをオフにするというこの回避策は、この特定のシナリオに対してのみ使用してください。Oracleホーム間のタイムゾーン・バージョン・エラーを報告する有効なエラー・チェックを無視すると、アップグレードが失敗します。

                     

                  

                  
               

               

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング

                     

                  

               

               
            

            
DBUAでのリスナー登録を完了するための障害の修正

               

                  
Database Upgrade Assistantの「進行状況」ステップでは、ウィンドウが表示され、「ディレクトリ・サービスにデータベース・エントリを作成できません。リスナーが構成されていません」という警告が示されます。

                  

                     
このシナリオでは、次のステップを完了しました。

                     
    
                        
  1. 
                           
    Net Configuration Assistant (NetCA)またはNet Managerを使用して、以前のリリースのOracleホームにリスナーを作成しました。 
    
                        
    2. 
                        
  2. 
                           
    新しいOracle Databaseリリースを新しいOracleホームにインストールし、リスナーに対して登録しました。
    
                        
    3. 
                        
  3. 
                           
    リスナーをOracle Internet Directory (OID)に登録してデータベースをアップグレードするか、新しいOracleホームのOIDにリスナーを登録する必要があります。
    
                        
    4. 
                     

                     

                        
ノート: 

                        
リスナーがサーバー上の別のOracleホームから実行されている場合、またはリスナーが現在のOracleホームから実行されていてもLISTENER.ORAファイルで構成されていない(つまり、自動的に生成されたデフォルト構成を使用する)場合、DBCAはリスナーを検出できません。 
                        

                     

                  

                  
                  

                     
DBUAでは、アップグレードと同時にアップグレードしたデータベースがOIDに直接登録されなくなりました。 

                     
この問題を解決するには、次のタスクを実行します。

                     
    
                        
  1. 
                           
    OIDからリスナーを登録解除します。
    
                        
    2. 
                        
  2. 
                           
    データベースのアップグレードを実行します。
    
                        
    3. 
                        
  3. 
                           
    新しいリリースのOracle Database Oracleホームで、移行されたリスナーをOIDレジストリに再度登録します。
    
                        
    4. 
                     

                  

                  
               

               

                  

                     

                        
親トピック: Oracle Databaseのアップグレードのトラブルシューティング