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

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

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

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

関連項目

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

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

データベースがアップグレード・モードで起動すると、固定ビューの問合せのみがエラーなしで実行されます。この制限は、パラレル・アップグレード・ユーティリティ(catctl.pl)を直接実行するか、dbupgradeスクリプトを使用して間接的に実行するまで適用されます。アップグレード・スクリプトを実行する前に、他のビューでPL/SQLを使用するか、他のビューに対して問合せを実行するとエラーが戻されます。この項で説明するエラーを受け取った場合は、SHUTDOWN ABORTコマンドを発行してデータベースを停止し、問題を修正します。

新しいOracle Databaseリリースを起動しようとすると、次のエラー・リストが発生する場合があります。これらのエラーの一部はアラート・ログに記録され、セッションには表示されません。

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

  • すべてのOracle Databaseインストール所有者は、プライマリ・グループとしてOINSTALLグループ(またはOracleインベントリ・グループ)に指定したグループを保持している必要があります。すべてのデータベース・ファイル(データファイル、REDOファイル、制御ファイル、アーカイブ・ログの保存先、リカバリ領域、SPFILEおよびパスワード・ファイル)が新しいターゲット・リリースとソース(以前の)リリースの両方のバイナリ所有者によって読取りおよび書込み可能であることを確認します。そうでない場合は、各インストール所有者がそのプライマリ・グループと同じグループを持っていることを確認し、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リリースに対してアップグレード後の状態ツール(utlusts.sql)を実行しないでください。

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

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

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

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

アップグレードの開始前にpreupgradeパラメータを使用してAutoUpgradeを実行しなかった場合、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. preupgradeパラメータを使用してAutoUpgradeユーティリティを実行し、upgrade.xmlファイルで報告された問題を修正します。

関連項目

親トピック: 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スクリプトを再実行します。パラレル・アップグレード・ユーティリティ(catctl.pl)を使用してアップグレードを実行する場合、失敗した時点から自動的にアップグレードを再開するには、-Rオプションを指定してユーティリティを実行します。問題を修正すると、AutoUpgradeが自動的にアップグレードを再開します。

通常、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のアップグレードのトラブルシューティング

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

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

この問題を回避するには、アップグレード前に次の作業を行います。
  1. 許可ユーザーとしてログインします。
  2. sqlnet.oraファイル、そしてウォレット・ファイルewallet.p12を新しいリリースのOracleホームに手動でコピーします。
  3. マウントされているOracleウォレットをオープンします。

    たとえば:

    SQL> STARTUP MOUNT;
SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN
  4. 通常どおり、アップグレードを開始します。

親トピック: 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. そのノード上で、rootスクリプトを再度実行します。

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

  1. クラスタ内の他のすべてのノードでアップグレードを完了します。

  2. 最初のノードを再起動します。

  3. 最初のノード上で、rootスクリプトを再度実行します。

  4. アップグレードを完了するには、rootでログインし、パスGrid_home/cfgtoollogs/configToolAllCommandsにあるスクリプトconfigToolAllCommandsを実行します。

参照:

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

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

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

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

トピック:

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

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

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

アップグレード後の状態ツール(utlusts.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に見つかりませんでした。インストール・ログを確認し、コンポーネント・ソフトウェアをインストールしてから、パラレル・アップグレード・ユーティリティを再実行します。

ノート:

パラレル・アップグレード・ユーティリティ(catctl.pl)を、コマンドライン・スクリプトdbupgradeを使用して、サポートされているすべてのプラットフォームで実行できます。

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

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

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

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

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

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

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

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

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

必須オプションを持つコンポーネントは、すべてアップグレードする必要があります。該当するコンポーネントは次のとおりです。

  • RAC

  • SDO

  • APS

  • XOQ

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

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

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

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

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

  1. ORACLE_BASE/cfgtoollogs/db_unique_name/upgradeYYMMDDHHMMSC/upg_summary.rpt

  2. $ORACLE_HOME/rdbms/log/upg_summary.rpt

  3. LinuxおよびUNIX:

    /tmp/upg_summary.rpt

    Windowsの場合:

     \TEMP\upg_summary.rpt

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

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


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. ターゲットPDBでPL/SQLパッケージSET SERVEROUTPUT ONおよびexec xdb.DBMS_XMLSTORAGE_MANAGE.GetTypeDDLを実行し、ユーザー指定のSQLスクリプト(script1.sqlなど)を生成します。
  3. 12.1のソースCDBで、ステップ2で作成したスクリプト(script1.sqlなど)を実行し、エラーが発生した共通タイプごとにタイプ作成スクリプトを取得します
  4. これらの作成スクリプトを含む別のユーザー指定のSQLスクリプト(script2.sqlなど)を生成します。
  5. 12.1のソースCDBで作成したスクリプト(script2.sqlなど)をターゲットPDBで実行します。
リリース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のアップグレードのトラブルシューティング

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

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

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

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

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

    LinuxおよびUNIXの場合:

    ./datapatch -verbose

    Microsoft Windowsの場合: 

    datapatch -verbose

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