1. アップグレード・ガイド
  2. Oracle Databaseのアップグレード後の作業
  3. Oracle Databaseのアップグレード後に必要な作業

Oracle Databaseのアップグレード後に必要な作業

アップグレードの完了後、現在の環境に対して指定されたこれらの必要な作業を確認して完了します。

Oracle Databaseをアップグレードした後で、次のアップグレード後タスクを実行する必要があります。これらのタスクは手動でアップグレードを実行した場合も、Database Upgrade Assistant (DBUA)を使用してアップグレードした場合でも実行する必要があります。

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

手動アップグレード後のLinuxおよびUNIXシステム上での環境変数の設定

Oracle Databaseの手動アップグレードを実行した場合、必要とされるオペレーティング・システムの環境変数が、新しいOracle Databaseリリースのディレクトリを指していることを確認する必要があります。

クラスタ・データベースをアップグレードしている場合は、そのクラスタ・データベースのインスタンスが構成されているすべてのノードでこれらを確認してください。

次の環境変数が新しいOracleホームのディレクトリを指していることを確認します。

  • ORACLE_HOME

  • PATH

注意:

DBUAでは、自動的にOracle環境変数に対して必要な変更が行われます。

参照:

親トピック: Oracle Databaseのアップグレード後に必要な作業

すべての無効なオブジェクトの再コンパイル

データベースのインストール、パッチ適用またはアップグレードの後にutlrp.sqlスクリプトを実行し、無効なオブジェクトを特定して再コンパイルすることをお薦めします。

utlrp.sqlスクリプトは、すべての無効なオブジェクトを再コンパイルします。インストールの直後にスクリプトを実行して、ユーザーが無効なオブジェクトにアクセスしないようにしてください。
  1. SQL*Plusを起動します。
    sqlplus "/ AS SYSDBA"
  2. utlrp.sqlスクリプトを実行します。Oracle_homeはOracleホームのパスです。
    SQL> @Oracle_home/rdbms/admin/utlrp.sql

utlrp.sqlスクリプトは、無効なオブジェクトの数と使用可能なCPUの数の両方に基づいて、シリアル再コンパイルまたはパラレル再コンパイルで無効なオブジェクトを自動的に再コンパイルします。CPUは、CPUの数(cpu_count)にCPUごとのスレッドの数(parallel_threads_per_cpu)を乗じて計算されます。Oracle Real Application Clusters (Oracle RAC)では、すべてのOracle RACノード全体でこの数が追加されます。

親トピック: Oracle Databaseのアップグレード後に必要な作業

マルチテナント・アーキテクチャ・データベースでのすべての無効なオブジェクトの再コンパイル

マルチテナント・アーキテクチャOracle Databaseでは、アップグレード後にcatcon Perlスクリプトを使用して無効なオブジェクトを再コンパイルすることをお薦めしています。

catcon.plユーティリティを使用して、使用しているコンテナ・データベース(CDB)のすべてのコンテナでutlrp.sqlを実行します。

catcon.plスクリプトは、$ORACLE_HOME/rdbms/adminディレクトリからutlrp.sqlを実行します。このスクリプトは、残りのすべてのストアドPL/SQLおよびJavaコードを再コンパイルします。

例4-1 CATCONユーティリティを使用した、CDBのすべてのコンテナに対するutlrp.sqlスクリプトの実行

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlrp -d '''.''' utlrp.sql

この使用例では次の点に注意してください。

  • -nパラメータは1に設定されているため、各PDBの再コンパイルは順番に実行されます。

  • PDBのシリアル再コンパイルが完了するまでの時間の遅延を予期してください。アップグレードするPDBの数によっては、再コンパイルは、アップグレード・スクリプトの完了に要する時間を大幅に超えて延長される可能性があります。

親トピック: Oracle Databaseのアップグレード後に必要な作業

無効なオブジェクトの再コンパイルの進行状況の追跡

これらのSQL問合せを使用して、utlrp.sqlスクリプトによる無効なオブジェクトの再コンパイルの進行状況を追跡します。

アップグレード後にutlrp.sqlスクリプトを実行して無効なオブジェクトを再コンパイルすることをお薦めします。SQL問合せを実行してスクリプトを監視できます。

例4-2 残っている無効なオブジェクトの数

次の問合せを入力すると、残っている無効なオブジェクトの数が返されます。この数は、utlrp.sqlスクリプトの実行につれて時間とともに減少します。 

SELECT COUNT(*) FROM obj$ WHERE status IN (4, 5, 6);

例4-3 再コンパイルされたオブジェクトの数

次の問合せを入力すると、utlrp.sqlによってコンパイルされたオブジェクトの数が返されます。この数は、スクリプトの実行につれて時間とともに増加します。

SELECT COUNT(*) FROM UTL_RECOMP_COMPILED;

例4-4 エラー付きで再コンパイルされたオブジェクトの数

次の問合せを入力すると、utlrp.sqlによってエラー付きでコンパイルされたオブジェクトの数が返されます。 

select COUNT(DISTINCT(obj#)) "OBJECTS WITH ERRORS" from utl_recomp_errors;

この数が予想より多い場合、各オブジェクトでレポートされたエラー・メッセージを確認してください。エラーの原因がシステムの間違った構成やリソース制約にある場合、それらのエラーの原因を修正してutlrp.sqlを再度実行します。

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle Databaseのアップグレード後のOPatchコマンドの実行

Oracle Databaseをアップグレードした後で、新しいOracleホームからOPatchコマンドを実行する必要があります。

OPatchは、Oracle Universal Installerを使用してインストールするJavaベースのユーティリティです。Opatchはプラットフォームに依存します。サポートされているすべてのオペレーティング・システム上で実行されます。スタンドアロンOPatchと呼ばれる別のバージョンのOPatchも使用できます。これは、Oracle Universal Installerを使用せずにOracleホームで実行されます。

パッチとは、既存のインストールにコピーされる小型のファイル・コレクションです。パッチはOracle製品の特定のバージョンに関連付けられています。インストール済の対応バージョンの製品にパッチを適用すると、製品のバージョンがアップグレードされます。

Oracle Databaseインベントリを確認するためのOPatchの実行

Oracleインストレーション所有者としてログインし、新しいOracleホームからlsinventoryコマンドを実行します。このコマンドは、使用しているシステムにインストールされているOracleソフトウェアの正確かつ完全なインベントリを生成します。 

opatch lsinventory –patch

個別パッチの取得

オラクル社では、不具合または一連の不具合を修正するために個別パッチを頻繁にリリースします。個別パッチはMy Oracle SupportでパッチIDを指定して取得できます。

関連項目

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle Databaseのアップグレード後にoratabおよびスクリプトが新しいOracleの場所を指すようにするための設定

新しいOracleホームの場所を指すようにスクリプトを設定する必要があります。

Oracle Databaseを新しいリリースにアップグレードした後に、oratabファイルおよびORACLE_HOME値を設定するすべてのクライアント・スクリプトが、新しいOracle Database 12cリリース用に作成された新しいOracleホームを指していることを確認する必要があります。DBUAでは、oratabファイルは自動的に新しいOracleホームを指します。ただし、クライアント・スクリプトは、アップグレードに使用する方法にかかわらず確認する必要があります。

参照:

オペレーティング・システムの環境変数の設定の詳細は、『Oracle Database管理者ガイド』を参照してください。

親トピック: Oracle Databaseのアップグレード後に必要な作業

PL/SQLパッケージおよび依存プロシージャの確認

以前のリリースのOracle Databaseにインストールしていたパッケージは、新しいリリースで自動的にアップグレードされない可能性があり、その場合アプリケーションに影響します。

アップグレード後に、独自のスクリプトで使用していたパッケージまたは独自のスクリプトからコールしていたパッケージがすべて新しいリリースで使用できることを確認してください。パッケージに依存するプロシージャのテストは、アップグレード計画に含まれる必要があります。

データベース・アプリケーションのコードは、接続先データベースのオブジェクトを参照できます。たとえば、Oracle Call Interface(OCI)およびプリコンパイラ・アプリケーションは無名PL/SQLブロックを発行できます。Oracle Formsアプリケーションのトリガーは、スキーマ・オブジェクトを参照できます。これらのアプリケーションは、参照しているスキーマ・オブジェクトに依存しています。依存性管理の方法は開発環境によって異なります。Oracle Databaseでは、アプリケーションの依存性が自動的に追跡されることはありません。

関連項目

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle管理タイプに依存する表のアップグレード

Oracle Database 12cリリース2 (12.2)以上では、Oracle管理タイプに依存するユーザー表を手動でアップグレードする必要があります。

Oracle管理タイプに依存するユーザー表(AQキュー表など)がデータベースに含まれる場合、アップグレード後にutluptabdata.sqlコマンドを実行して、Oracle管理タイプの変更の影響を受けるすべてのユーザー表に対してALTER TABLE UPGRADEを実行します。この動作変更によって、ユーザー表は、アップグレード中に読取り専用状態のままになります。ユーザーは、SYSDBAとしてアプリケーションにログインし、Oracle管理タイプに依存するアプリケーション表を変更することができなくなります。

データベース・アップグレードの後にアップグレードする必要がある表を特定するには、SYSDBAとして接続し、次の問合せを実行します。

COLUMN owner FORMAT A30
COLUMN table_name FORMAT A30
SELECT DISTINCT owner, table_name
FROM dba_tab_cols
WHERE data_upgraded = 'NO'
ORDER BY 1,2;

この問合せによって、UPGRADEDとしてリストされないすべての表が示されます。ただし、utluptabdata.sqlスクリプトは、Oracle管理タイプに依存する表のみをアップグレードします。問合せによって表がリストされた場合、utluptabdata.sqlスクリプトを実行して依存ユーザー表にALTER TABLE UPGRADEコマンドを実行し、これらのOracle管理タイプをそのタイプの最新バージョンにアップグレードします。

utluptabdata.sqlスクリプトは、Oracle管理タイプに依存するすべての表を変更できる権限を持つユーザー・アカウントか、またはSYSDBAとしてログインしているSYSDBAシステム権限を付与されたユーザーを使用して実行する必要があります。

パラメータSERVEROUTPUTがONに設定されている場合、utluptabdata.sqlスクリプトによって、アップグレードされたすべての表の名前が表示され、表のアップグレード中に発生したエラーがリストされます。次のコマンドを実行すると、サーバー出力がONに設定されます。 

SET SERVEROUTPUT ON
@utluptabdata.sql

親トピック: Oracle Databaseのアップグレード後に必要な作業

新しい拡張データ型機能の有効化

システムで新しい拡張データ型を利用できるようにするには、特定のアップグレード操作が必要です。

Oracle Database 12cでは、SQLのVARCHAR2、NVARCHAR2およびRAWデータ型の最大サイズを制御するMAX_STRING_SIZEが導入されました。MAX_STRING_SIZE = EXTENDEDを設定することで、Oracle Database 12cで導入された32767バイト制限が有効になります。

MAX_STRING_SIZE = EXTENDEDを設定できるようにするには、COMPATIBLE初期化パラメータを12.0.0.0以上に設定する必要があります。

注意:

MAX_STRING_SIZEの値はSTANDARDからEXTENDEDに変更できます。ただし、MAX_STRING_SIZEの値をEXTENDEDからSTANDARDには変更できません。MAX_STRING_SIZE = EXTENDEDを設定することは、データベースでアプリケーションの非互換性が発生する可能性がある設定を明示的に指定することになります。

参照:

MAX_STRING_SIZEの推奨事項および手順などの詳細は、『Oracle Databaseリファレンス』を参照してください。

親トピック: Oracle Databaseのアップグレード後に必要な作業

パラレル実行サーバーの最大値および最小値の調整

現在の環境に応じて、PARALLEL_MIN_SERVERSのデフォルト設定を調整する必要があります。

Oracle Database 12cでは、PARALLEL_MIN_SERVERSのデフォルトが0からご使用のハードウェア・プラットフォームに応じた値に変更されており、パラレル実行に必要な最低限のサポートが提供されます。新しいデフォルト設定が現在の環境に対して大きすぎる場合、要件に応じて設定を調整してください。PARALLEL_MAX_SERVERSのデフォルトは変更されていません。以前の環境のデフォルトのまま変更されていない場合、追加の操作を実行する必要はありません。

参照:

PARALLEL_MIN_SERVERSの詳細は、『Oracle Databaseリファレンス』を参照してください。

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle Databaseのアップグレード後のリカバリ・カタログ・アップグレードの概要

RMANクライアントで要求されるバージョンより古いリカバリ・カタログ・スキーマを使用している場合、そのカタログをアップグレードする必要があります。

参照:

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle Databaseのアップグレード後のタイムゾーン・ファイルのバージョンのアップグレード

データベースのアップグレードを完了した後、アップグレード前情報ツールによってタイムゾーン・ファイルをアップグレードするよう指示された場合は、DBMS_DST PL/SQLパッケージを使用してタイムゾーン・ファイルをアップグレードします。

Oracle Databaseでは、複数のバージョンのタイムゾーン・ファイルを提供しています。各タイムゾーン・ファイルに関連付けられた2つのタイプのファイルがあり、1つはデータベースに定義されたすべてのタイムゾーンを含む大きいファイルで、1つは最も一般的に使用されるタイムゾーンのみを含む小さいファイルです。大きいバージョンは、timezlrg_version_number.datという名前です。小さいバージョンは、timezone_version_number.datという名前です。ファイルは、Oracle Databaseホーム・ディレクトリ下のoracore/zoneinfoサブディレクトリにあります。

関連項目

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle Databaseのアップグレード後のDBMS_STATSパッケージで作成された統計表のアップグレード

DBMS_STATS.CREATE_STAT_TABLEプロシージャを使用して統計表を作成した場合、DBMS_STATS.UPGRADE_STAT_TABLEを実行してそれらの表をアップグレードします。

次の例で、greenは統計表の所有者で、STAT_TABLEは統計表の名前です。 

EXECUTE DBMS_STATS.UPGRADE_STAT_TABLE('green', 'stat_table');

各統計表にこのプロシージャを実行します。

参照:

DBMS_STATSパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle Databaseのアップグレード後の外部認証されたSSLユーザーのアップグレード

Oracle9iリリース2 (9.2)またはOracle Database 10gリリース1 (10.1)からのアップグレード時に、外部認証されたSSLユーザーを使用している場合は、SSL外部ユーザー変換(extusrupgrade)スクリプトを実行してそれらのユーザーをアップグレードする必要があります。

extusrupgradeスクリプトの構文は次のとおりで、ORACLE_HOMEはOracle Databaseホーム、hostnameはデータベースが実行されているホストの名前、port_noはリスナーのポート番号、sidはデータベース・インスタンスのシステム識別子、db_adminはユーザー・アカウントを変更する権限を持つデータベース管理ユーザーです。 

ORACLE_HOME/rdbms/bin/extusrupgrade --dbconnectstring 
hostname:port_no:sid --dbuser db_admin --dbuserpassword 
password -a

次に例を示します。

extusrupgrade --dbconnectstring dlsun88:1521:10gR2 --dbuser system --dbuserpassword manager -a

注意:

Oracle Database 10gリリース2 (10.2)以上のリリースからアップグレードしている場合は、extusrupgradeスクリプトを実行する必要はありません。

参照:

extusrupgradeスクリプトの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle XML DBに対するFTPとHTTPのポートおよびHTTP認証の構成

Database Creation Assistant (DBCA)では、Oracle Database 12cのOracle XML DBのポートは構成されません。

ポートを構成する場合、改善されたセキュリティ機能を利用するために、Oracle XML DB Repositoryへのアクセス用にHTTPの認証も構成することをお薦めします。

Oracle Database 12c以上では、ダイジェスト認証のサポートを提供することによって、データベースのセキュリティが向上しました。ダイジェスト認証は、HTTPプロトコルで一般に使用され、ほとんどのHTTPクライアントでサポートされている業界標準のプロトコルです。ほとんどのHTTPクライアントではこれがサポートされています。ダイジェスト認証により、暗号化(HTTPS)接続が使用されない場合でも、パスワードが常にセキュアな方法で送信されます。ダイジェスト認証をサポートすることによって、組織では、パスワードの漏えいを心配することなくOracle XML DB HTTPを使用するアプリケーションをデプロイできます。Oracle XML DBでのダイジェスト認証のサポートでは、Oracle XML DB HTTPサーバーとMicrosoft Web Folders WebDAVクライアントとの互換性も引き続き維持されます。

新しいリリースのインストールまたはアップグレード後に、次のようにOracle XML DBのFTPおよびHTTPポートを手動で構成する必要があります。

  1. DBMS_XDB_CONFIG.setHTTPPort(HTTPポート番号)を使用して、Oracle XML DBのHTTPポートを設定します。 

    SQL> exec DBMS_XDB_CONFIG.setHTTPPort(port_number);

  2. DBMS_XDB_CONFIG.setFTPPort(FTPポート番号)を使用して、Oracle XML DBのFTPポートを設定します。 

    SQL> exec DBMS_XDB_CONFIG.setFTPPort(
port_number);

    注意:

    手順内のFTPおよびHTTPで使用するポート番号は、DBMS_XDB_CONFIG.getFTPPortおよびDBMS_XDB_CONFIG.getHTTPPortをそれぞれ使用することによって問い合せることができます。

  3. 使用されているすべてのポート番号を確認するには、DBMS_XDB_CONFIG.usedportを問い合せます。

参照:

FTP、HTTP、HTTPSおよびWebDAVプロトコルを使用したOracle XML DB Repositoryのデータへのアクセスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle Databaseのアップグレード後のOracle Textが提供するナレッジ・ベースのインストール

Oracle Textに対するユーザー拡張をアップグレード後に再生成します。

Oracle Textナレッジ・ベースに対してユーザーが拡張した項目は、アップグレード後に再生成する必要があります。これらの変更は、指定されたOracleホームにインストールされているすべてのデータベースに影響します。

Oracle Textが提供するナレッジ・ベースはOracle Database 12cの付属製品の一部ですが、Oracle Database 12cへのアップグレード後すぐに使用できるようにはなっていません。アップグレード前には使用可能であったナレッジ・ベースに依存するOracle Textの機能は、アップグレード後には機能しなくなります。これらの機能を再度使用可能にするには、Oracle Textナレッジ・ベースをインストール・メディアからインストールする必要があります。

参照:

親トピック: Oracle Databaseのアップグレード後に必要な作業

AUTO_LEXERを使用したOracle Text索引の再構築

Oracle Database 12cより前のリリースからOracle Textをアップグレードする場合、このトピックを参照してください。

Oracle Database 12cリリース1へのアップグレード完了後に、AUTO_LEXERを使用して作成されたOracle Text索引を使用する場合、問合せを動作させるには、索引を再構築する必要があります。

また、BASIC_LEXERセットの次のINDEX_STEMSタイプを持つ索引を再構築する必要があります。

  • ARABIC

  • BOKMAL

  • CATALAN

  • CROATIAN

  • CZECH

  • DANISH

  • ERIVATIONAL_NEW

  • DUTCH_NEW

  • ENGLISH_NEW

  • FINNISH

  • FRENCH_NEW

  • GERMAN_NEW

  • GREEK

  • HEBREW

  • HUNGARIAN

  • ITALIAN_NEW

  • NYNORSK

  • POLISH

  • PORTUGUESE

  • ROMANIAN

  • RUSSIAN

  • SERBIAN

  • SLOVAK

  • SLOVENIAN

  • SPANISH_NEW

  • SWEDISH

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle Databaseのアップグレード後のOracle Application Express構成の更新

Oracle Application Expressのリリースとデータベースのインストール・タイプによっては、Oracle Application Expressがアップグレード手順に影響します。

アップグレードするOracle DatabaseリリースにOracle Application Expressリリース3.2以上が含まれる場合、Oracle Database 12cへのアップグレード後に追加構成を実行する必要はありません。ただし、Oracle Application Expressがレジストリに存在し、Oracle Application Expressがアップグレードに含まれる場合、open_cursorsパラメータを200以上に設定します。

アップグレードするOracle DatabaseがOracle Express Editionデータベースであり、以前のリリースのOracle Application Expressが含まれる場合、アップグレード中に自動的に最新リリースがインストールされます。新しいOracle Database 12cと併用するために、インストール後の一連のステップを実行して、Application Expressを構成する必要があります。

データベースがOracle Express Editionデータベースの場合、Oracle Express Edition環境に応じて調整されたOracle Application Expressの以前のリリースが含まれています。

参照:

親トピック: Oracle Databaseのアップグレード後に必要な作業

外部ネットワーク・サービスへのアクセス制御リスト(ACL)の構成

Oracle Database 12cには、UTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTPまたはUTL_INADDRパッケージに対するファイングレイン・アクセス制御が含まれています。

これらのパッケージを使用するアプリケーションがある場合、Oracle Databaseのアップグレード後に、データベースのネットワーク・アクセス制御リスト(ACL)を構成してから、これらのパッケージを前のリリースと同様に動作させる必要があります。ACLがない場合、エラー「ORA-24247: アクセス制御リスト(ACL)によりネットワーク・アクセスが拒否されました」でアプリケーションが失敗する可能性があります。

参照:

一部のユーザーはホストAに接続し、別のユーザーはホストBに接続するなど、より複雑な状況については、『Oracle Databaseセキュリティ・ガイド』を参照してください。

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle Databaseのアップグレード後のOracle Database Vaultの有効化

Oracle Database 12cリリース2 (12.2)以降、Oracle Database Vaultを無効にせずにデータベースをアップグレードできるようになりました。ただし、Oracle Database Vaultを無効にした場合はアップグレード後に手動で有効にする必要があります。

Oracle Database 12cリリース2 (12.2)以降、Oracle Database Vaultを有効にしてある場合は、Oracle Database Vaultを無効にせずにデータベースをアップグレードできるようになりました。アップグレード後に、アップグレード前に用意した強化設定を使用して、Oracle Database Vaultはデフォルトで有効化されます。

アップグレード前に手動でOracle Database Vaultを無効にした場合は、アップグレード後に手動でOracle Database Vaultを有効にする必要があります。

アップグレード前にOracle Database Vaultを有効にしていなかった場合は、アップグレード後に手動で有効にできます。

プロシージャdvsys.dbms_macadm.enable_dv()を使用して、アップグレードしたデータベースでOracle Database Vaultを有効にします。このプロシージャは、DV_OWNERまたはDV_ADMINのいずれかを付与されたユーザー・アカウントを使用して実行します。プロシージャを実行したら、そのプロシージャを有効にするためにデータベース・インスタンスを再起動します。

関連項目

親トピック: Oracle Databaseのアップグレード後に必要な作業

SQLNET.ALLOWED_LOGON_VERSIONパラメータの動作の確認

10gより前のリリースのクライアントからのOracle Databaseに対する接続は、ORA-28040: 「一致する認証プロトコルがありません」というエラーによって失敗します。

Oracle Database 12c以上では、SQLNET.ALLOWED_LOGON_VERSIONパラメータのデフォルト値は、8から11に変更されています。このパラメータの使用は非推奨になりました

SQLNET.ALLOWED_LOGON_VERSIONは、現在、SQLNET.ALLOWED_LOGON_VERSION_SERVERおよびSQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータに置き換えられています。アップグレードしたデータベースでSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを明示的に設定していない場合、10gより前のリリースのクライアントからの接続は、ORA-28040: 「一致する認証プロトコルがありません」というエラーによって失敗します。セキュリティ強化のため、データベース・ユーザーのパスワード検証機能を確認し、SQLNET.ALLOWED_LOGON_VERSION_SERVERおよびSQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータを設定して正しいパスワード検証機能を使用するようにデータベースを構成します。

既存のデータベースにパスワードで保護されたロール(セキュア・ロール)があり、11のデフォルトのSQLNET.ALLOWED_LOGON_VERSION_SERVER設定でOracle Database 12cにアップグレードする場合、そのセキュア・ロールに含まれるのはリリース10gの検証機能のみであるため、アップグレード後もセキュア・ロールが使用可能な状態になるように、管理者は各セキュア・ロールのパスワードをリセットする必要があります。

参照:

親トピック: Oracle Databaseのアップグレード後に必要な作業