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

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

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

注意:

リプレイ・アップグレードについては、リプレイ・アップグレード・エラーに固有の個別のトラブルシューティングのステップを参照してください。

非CDB Oracle Databaseのアップグレード中のエラー

非CDB Oracle Databaseリリースをアップグレードしようとすると、エラーORA-O1722: invalid numberが発生します。

Oracle Database 20c以降では、Oracle Databaseのアップグレードにマルチテナント・アーキテクチャを使用する必要があります。非CDB Oracle DatabaseリリースをOracle Database 20cにアップグレードする際に、マルチテナント・アーキテクチャにアップグレードしない場合は、次のエラーが発生します。

SELECT TO_NUMBER('UPGRADE OF A NON-CDB TO TARGET RELEASE IS NOT SUPPORTED') * ERROR at line 1: ORA-01722: invalid number

この問題を解決するには、非CDBからCDBへのアップグレード方法のいずれかを使用して、マルチテナント・アーキテクチャにアップグレードします。

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_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

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

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

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

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

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

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

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のアップグレード中におけるリソース制限エラーの原因のトラブルシューティング

リソース制限エラーを意味するORA-01650ORA-01651ORA-01652ORA-01653ORA-01654ORA-01655ORA-0431ORA-01562ORA-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での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セッションを終了し、別のセッションでそのインスタンスを再起動します。

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

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

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

「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. 通常どおり、アップグレードを開始します。

ビュー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の他のコンテナで実行します。

サーバーの再起動後のアップグレードの継続(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インストレーション・ガイド』を参照してください。

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

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

トピック:

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

アップグレード後の状態ツール(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の標準のサポート対象コンポーネントの場合と同じ手順に従ってアップグレードされます

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

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

アップグレードが完了した後、アップグレード・ユーティリティ・スクリプトutlusts.sqlはアップグレード・レポートを表示します。

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

Oracle Database Release 20 Post-Upgrade Status Tool    12-04-2019 08:18:1
Container Database: AIME1
[CON_ID: 1 => CDB$ROOT]

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

Oracle Server                          UPGRADED      20.1.0.0.0  00:22:08
JServer JAVA Virtual Machine           UPGRADED      20.1.0.0.0  00:09:35
Oracle XDK                             UPGRADED      20.1.0.0.0  00:01:36
Oracle Database Java Packages          UPGRADED      20.1.0.0.0  00:00:14
OLAP Analytic Workspace                UPGRADED      20.1.0.0.0  00:00:44
Oracle Label Security                  UPGRADED      20.1.0.0.0  00:00:17
Oracle Database Vault                  UPGRADED      20.1.0.0.0  00:01:20
Oracle Text                            UPGRADED      20.1.0.0.0  00:01:21
Oracle Workspace Manager               UPGRADED      20.1.0.0.0  00:01:20
Oracle Real Application Clusters       UPGRADED      20.1.0.0.0  00:00:06
Oracle XML Database                    UPGRADED      20.1.0.0.0  00:03:08
Oracle Multimedia                      UPGRADED      20.1.0.0.0  00:01:33
Spatial                                UPGRADED      20.1.0.0.0  00:07:51
Oracle OLAP API                        UPGRADED      20.1.0.0.0  00:00:12
Oracle Locator                         UPGRADED      20.1.0.0.0  00:00:00
Datapatch                                                        00:00:23
Final Actions                                                    00:00:43
Post Upgrade                                                     00:00:17

Total Upgrade Time: 00:48:56 [CON_ID: 1 => CDB$ROOT]

Database time zone version is 31. It is older than current release time
zone version 34. Time zone upgrade is needed using the DBMS_DST package.


Oracle Database Release 20 Post-Upgrade Status Tool    12-04-2019 09:12:4
Container Database: AIME1
[CON_ID: 3 => CDB1_PDB1]

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

Oracle Server                          UPGRADED      20.1.0.0.0  00:31:00
JServer JAVA Virtual Machine           UPGRADED      20.1.0.0.0  00:04:25
Oracle XDK                             UPGRADED      20.1.0.0.0  00:01:38
Oracle Database Java Packages          UPGRADED      20.1.0.0.0  00:00:13
OLAP Analytic Workspace                UPGRADED      20.1.0.0.0  00:01:03
Oracle Label Security                  UPGRADED      20.1.0.0.0  00:00:11
Oracle Database Vault                  UPGRADED      20.1.0.0.0  00:01:38
Oracle Text                            UPGRADED      20.1.0.0.0  00:00:34
Oracle Workspace Manager               UPGRADED      20.1.0.0.0  00:00:53
Oracle Real Application Clusters       UPGRADED      20.1.0.0.0  00:00:00
Oracle XML Database                    UPGRADED      20.1.0.0.0  00:03:04
Oracle Multimedia                      UPGRADED      20.1.0.0.0  00:01:15
Spatial                                UPGRADED      20.1.0.0.0  00:06:48
Oracle OLAP API                        UPGRADED      20.1.0.0.0  00:00:18
Oracle Locator                         UPGRADED      20.1.0.0.0  00:00:00
Datapatch                                                        00:00:23
Final Actions                                                    00:00:44
Post Upgrade                                                     00:00:20

Total Upgrade Time: 00:51:12 [CON_ID: 3 => CDB1_PDB1]

Database time zone version is 31. It is older than current release time
zone version 34. Time zone upgrade is needed using the DBMS_DST package.


Oracle Database Release 20 Post-Upgrade Status Tool    12-04-2019 09:20:0
Container Database: AIME1
[CON_ID: 2 => PDB$SEED]

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

Oracle Server                             VALID      20.1.0.0.0  00:30:56
JServer JAVA Virtual Machine              VALID      20.1.0.0.0  00:04:29
Oracle XDK                                VALID      20.1.0.0.0  00:01:38
Oracle Database Java Packages             VALID      20.1.0.0.0  00:00:12
OLAP Analytic Workspace                   VALID      20.1.0.0.0  00:00:55
Oracle Label Security                     VALID      20.1.0.0.0  00:00:14
Oracle Database Vault                     VALID      20.1.0.0.0  00:01:41
Oracle Text                               VALID      20.1.0.0.0  00:00:40
Oracle Workspace Manager                  VALID      20.1.0.0.0  00:00:53
Oracle Real Application Clusters     OPTION OFF      20.1.0.0.0  00:00:00
Oracle XML Database                       VALID      20.1.0.0.0  00:03:04
Oracle Multimedia                         VALID      20.1.0.0.0  00:01:15
Spatial                                   VALID      20.1.0.0.0  00:06:49
Oracle OLAP API                           VALID      20.1.0.0.0  00:00:19
Oracle Locator                            VALID      20.1.0.0.0  00:00:00
Datapatch                                                        00:00:25
Final Actions                                                    00:00:45
Post Upgrade                                                     00:00:21
Post Compile                                                     00:07:11

Total Upgrade Time: 00:58:24 [CON_ID: 2 => PDB$SEED * ]
Asterisks denotes compilation time has been included during the upgrade process.

Database time zone version is 31. It is older than current release time
zone version 34. Time zone upgrade is needed using the DBMS_DST package.


Upgrade Times Sorted In Descending Order

Total Upgrade Time: 00:58:24 [CON_ID: 2 => PDB$SEED * ]
Total Upgrade Time: 00:51:12 [CON_ID: 3 => CDB1_PDB1]
Total Upgrade Time: 00:48:56 [CON_ID: 1 => CDB$ROOT]
Grand Total Upgrade Time:    [0d:1h:53m:17s]

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 ASMパスワード・ファイルの場所の調整

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

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

参照:

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

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

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

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

オブジェクト・リレーショナルXMLスキーマにシステム生成の名前を登録することで、共通オブジェクト(dba_objectssharing='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エラーは解消します。

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%';

「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エンタープライズ・ユーザー・セキュリティ、OLS-OIDおよびプロビジョニング・プロファイルのエラーの修正

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

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

参照:

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

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

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

初期化パラメータMAX_STRING_SIZEEXTENDEDに設定されているが、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_SIZESTANDARDにリセットします。

  2. UPGRADEモードでデータベースを再起動します。

  3. 手動による手順を使用してアップグレードを再実行します。

  4. データベースのアップグレード後、初期化パラメータMAX_STRING_SIZEEXTENDEDに設定します。

  5. UPGRADEモードでデータベースを再起動します。

  6. SQLスクリプト../rdbms/admin/utl32k.sqlを実行します。

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

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. 12.1.0.2ノードを起動する前に、node3またはnode4でOracle ASMインスタンスに次のSQLコマンドを実行します。

    ALTER SYSTEM START ROLLING MIGRATION TO '12.1.0.2'
  3. 障害の時点から、記載されているアップグレード手順を継続します。

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

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

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

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

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の場合)に対して再リンクします。

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に戻してください。

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

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

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

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

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

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

アップグレード元のデータベースの夏時間(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ホーム間のタイムゾーン・バージョン・エラーを報告する有効なエラー・チェックを無視すると、アップグレードが失敗します。

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

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

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

  1. Net Configuration Assistant (NetCA)またはNet Managerを使用して、以前のリリースのOracleホームにリスナーを作成しました。

  2. 新しいOracle Databaseリリースを新しいOracleホームにインストールし、リスナーに対して登録しました。

  3. リスナーをOracle Internet Directory (OID)に登録してデータベースをアップグレードするか、新しいOracleホームのOIDにリスナーを登録する必要があります。

注意:

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

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

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

  1. OIDからリスナーを登録解除します。

  2. データベースのアップグレードを実行します。

  3. 新しいリリースのOracle Database Oracleホームで、移行されたリスナーをOIDレジストリに再度登録します。