Oracle Databaseのアップグレード後に必要な作業
アップグレードの完了後、現在の環境に対して指定されたこれらの必要な作業を確認して完了します。
Oracle Databaseをアップグレードした後で、次のアップグレード後タスクを実行する必要があります。これらのタスクは手動でアップグレードを実行した場合も、Database Upgrade Assistant (DBUA)を使用してアップグレードした場合でも実行する必要があります。
- 手動アップグレード後のLinuxおよびUnixシステム上での環境変数の設定
Oracle Databaseの手動アップグレードを実行した場合、必要とされるオペレーティング・システムの環境変数が、新しいOracle Databaseリリースのディレクトリを指していることを確認する必要があります。 - すべての無効なオブジェクトの再コンパイル
データベースのインストール、パッチ適用またはアップグレードの後にutlrp.sql
スクリプトを実行し、無効なオブジェクトを特定して再コンパイルすることをお薦めします。 - マルチテナント・アーキテクチャ・データベースのすべての無効なオブジェクトの再コンパイル
マルチテナント・アーキテクチャOracle Databaseでは、アップグレード後に、catcon
Perlスクリプトを使用して無効なオブジェクトを再コンパイルすることをお薦めしています。 - 無効なオブジェクトの再コンパイルの進行状況の追跡
これらのSQL問合せを使用して、utlrp.sql
スクリプトによる無効なオブジェクトの再コンパイルの進行状況を追跡します。 - Oracle Databaseのアップグレード後のOPatchコマンドの実行
Oracle Databaseをアップグレードした後で、新しいOracleホームからOPatchコマンドを実行する必要があります。 - Oracle Databaseのアップグレード後にoratabおよびスクリプトが新しいOracleの場所を指すようにするための設定
新しいOracleホームの場所を指すようにスクリプトを設定する必要があります。 - PL/SQLパッケージおよび依存プロシージャの確認
以前のリリースのOracle Databaseにインストールしたパッケージは新しいリリースでは使用できない可能性がありますが、これはアプリケーションに影響する場合があります。 - Oracle管理タイプに依存する表のアップグレード
Oracle Database 12cリリース2 (12.2)以降では、Oracle管理タイプに依存するユーザー表を手動でアップグレードする必要があります。 - 新しい拡張データ型機能の有効化
システムで新しい拡張データ型を利用できるようにするには、特定のアップグレード操作が必要です。 - パラレル実行サーバーの最大値および最小値の調整
環境に応じて、PARALLEL_MIN_SERVERSパラメータのデフォルト設定を減らすことができます。 - Oracle Databaseのアップグレード後のリカバリ・カタログ・アップグレードについて
RMANクライアントで要求されるバージョンより古いリカバリ・カタログ・スキーマを使用している場合、それをアップグレードする必要があります。 - Oracle Databaseのアップグレード後のタイムゾーン・ファイルのバージョンのアップグレード
データベースのアップグレードを完了した後、アップグレード前情報ツールによってタイムゾーン・ファイルをアップグレードするよう指示された場合は、DBMS_DST
PL/SQLパッケージを使用してタイムゾーン・ファイルをアップグレードします。 - Oracle Databaseのアップグレード後のDBMS_STATSパッケージで作成された統計表のアップグレード
DBMS_STATS.CREATE_STAT_TABLE
プロシージャを使用して統計表を作成した場合、DBMS_STATS.UPGRADE_STAT_TABLE
を実行してそれらの表をアップグレードします。 - Oracle Databaseのアップグレード後の外部認証されたSSLユーザーのアップグレード
Oracle9iリリース2 (9.2)またはOracle Database 10gリリース1 (10.1)からのアップグレード時に、外部認証されたSSLユーザーを使用している場合は、SSL外部ユーザー変換(extusrupgrade
)スクリプトを実行してそれらのユーザーをアップグレードする必要があります。 - Oracle XML DBに対するFTPとHTTPのポートおよびHTTP認証の構成
Oracle Database Configuration Assistant (DBCA)では、Oracle Database 12cのOracle XML DBのポートは構成されず、それ以降のリリースのアップグレードではダイジェスト認証が使用されます。 - Oracle Databaseのアップグレード後のOracle Textが提供するナレッジ・ベースのインストール
Oracle Textナレッジ・ベースに対してユーザーが拡張した項目は、Oracle Databaseアップグレード後に再生成する必要があります。 - AUTO_LEXERを使用したOracle Text索引の再構築
Oracle Database 12cより前のリリースからOracle Textをアップグレードする場合、このトピックを参照してください。 - Oracle Databaseのアップグレード後のOracle Application Express構成の更新
Oracle Application Expressのリリースとデータベースのインストール・タイプによっては、Oracle Application Expressがアップグレード手順に影響します。 - 外部ネットワーク・サービスへのアクセス制御リスト(ACL)の構成
Oracle Database 12c以降のリリースには、UTL_TCP
、UTL_SMTP
、UTL_MAIL
、UTL_HTTP
またはUTL_INADDR
パッケージに対するファイングレイン・アクセス制御が含まれています。 - Oracle Databaseのアップグレード後のOracle Database Vaultの有効化
ターゲットのデータベース・リリースによっては、Oracle Database Vaultを無効にしないとOracle Databaseのアップグレードを完了できない場合があります。 - SQLNET.ALLOWED_LOGON_VERSIONパラメータの動作の確認
10gより前のリリースのクライアントからのOracle Databaseに対する接続は、ORA-28040: 「一致する認証プロトコルがありません」
というエラーによって失敗します。
親トピック: Oracle Databaseのアップグレード後の作業
手動アップグレード後のLinuxおよびUnixシステム上での環境変数の設定
Oracle Databaseの手動アップグレードを実行した場合、必要とされるオペレーティング・システムの環境変数が、新しいOracle Databaseリリースのディレクトリを指していることを確認する必要があります。
次の環境変数が新しいOracleホームのディレクトリを指していることを確認します。
-
ORACLE_HOME
-
PATH
ノート:
DBUAでは、自動的にOracle環境変数に対して必要な変更が行われます。
すべての無効なオブジェクトの再コンパイル
データベースのインストール、パッチ適用またはアップグレードの後にutlrp.sql
スクリプトを実行し、無効なオブジェクトを特定して再コンパイルすることをお薦めします。
utlrp.sql
スクリプトは、すべての無効なオブジェクトを再コンパイルします。インストールの直後にスクリプトを実行して、ユーザーが無効なオブジェクトにアクセスしないようにしてください。
utlrp.sql
スクリプトは、無効なオブジェクトの数と使用可能なCPUの数の両方に基づいて、シリアル再コンパイルまたはパラレル再コンパイルで無効なオブジェクトを自動的に再コンパイルします。CPUは、CPUの数(cpu_count)にCPUごとのスレッドの数(parallel_threads_per_cpu)を乗じて計算されます。Oracle Real Application Clusters (Oracle RAC)では、すべてのOracle RACノード全体でこの数が追加されます。
マルチテナント・アーキテクチャ・データベースでのすべての無効なオブジェクトの再コンパイル
マルチテナント・アーキテクチャ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の数によっては、再コンパイルは、アップグレード・スクリプトの完了に要する時間を大幅に超えて延長される可能性があります。
無効なオブジェクトの再コンパイルの進行状況の追跡
これらの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のアップグレード後の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のノート756671.1を参照して、リリース更新(Update)およびリリース更新リビジョン(Revision)に関する最新の推奨事項を定期的に入手してください。
Oracle Databaseのアップグレード後にoratabおよびスクリプトが新しいOracleの場所を指すようにするための設定
新しいOracleホームの場所を指すようにスクリプトを設定する必要があります。
Oracle Databaseを新しいリリースにアップグレードした後に、oratab
ファイルおよびORACLE_HOME
値を設定するすべてのクライアント・スクリプトが、新しいOracle Databaseリリース用に作成された新しいOracleホームを指していることを確認する必要があります。DBUAでは、oratab
ファイルは自動的に新しいOracleホームを指します。ただし、クライアント・スクリプトは、アップグレードに使用する方法にかかわらず確認する必要があります。
データベースを手動でアップグレードする場合、新しいOracle DatabaseリリースのOracleインストール所有者としてログインし、oratab
ファイルを手動で更新する必要があります。oratab
ファイルの場所は、使用しているオペレーティング・システムによって異なります。
参照:
オペレーティング・システムの環境変数の設定の詳細は、『Oracle Database管理者ガイド』を参照してください
My Oracle Support: oratabファイルの検索または作成(ドキュメントID 394251.1)
PL/SQLパッケージおよび依存プロシージャの確認
以前のリリースのOracle Databaseにインストールしたパッケージは新しいリリースでは使用できない可能性がありますが、これはアプリケーションに影響する場合があります。
アップグレード後に、独自のスクリプトで使用していたパッケージまたは独自のスクリプトからコールしていたパッケージがすべて新しいリリースで使用できることを確認してください。パッケージに依存するプロシージャのテストは、アップグレード計画に含まれる必要があります。
データベース・アプリケーションのコードは、接続先データベースのオブジェクトを参照できます。たとえば、Oracle Call Interface(OCI)およびプリコンパイラ・アプリケーションは無名PL/SQLブロックを発行できます。Oracle Formsアプリケーションのトリガーは、スキーマ・オブジェクトを参照できます。これらのアプリケーションは、参照しているスキーマ・オブジェクトに依存しています。依存性管理の方法は開発環境によって異なります。Oracle Databaseでは、アプリケーションの依存性が自動的に追跡されることはありません。
Oracle管理タイプに依存する表のアップグレード
Oracle Database 12cリリース2 (12.2)以降では、Oracle管理タイプに依存するユーザー表を手動でアップグレードする必要があります。
Oracle管理タイプに依存するユーザー表(AQ
キュー表など)がデータベースに含まれる場合、アップグレード後にutluptabdata.sql
コマンドを実行して、Oracle管理タイプの変更の影響を受けるすべてのユーザー表に対してALTER TABLE UPGRADE
を実行します。この動作変更によって、ユーザー表は、アップグレード中にREAD ONLY
状態のままになります。ユーザーは、SYSDBA権限(AS SYSDBA
)を使用してアプリケーションにログインし、Oracle管理タイプに依存するアプリケーション表を変更できなくなります。
データベース・アップグレードの完了後にアップグレードする必要がある表を特定するには、データベースにAS 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管理タイプに依存するすべての表に対するALTER
権限を持つユーザー・アカウントか、またはAS SYSDBA
でログインしているSYSDBAシステム権限を付与されたユーザーを使用して実行する必要があります。
パラメータSERVEROUTPUTがON
に設定されている場合、utluptabdata.sql
スクリプトによって、アップグレードされたすべての表の名前が表示され、表のアップグレード中に発生したエラーがリストされます。サーバー出力をON
に設定するには、次のコマンドを実行します。
SET SERVEROUTPUT ON
@utluptabdata.sql
新しい拡張データ型機能の有効化
システムで新しい拡張データ型を利用できるようにするには、特定のアップグレード操作が必要です。
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
以上に設定する必要があります
また、データベースがアップグレード・モードで開いているときにutl32k.sql
スクリプトを実行することによって、データ型サイズの変更の影響を受けるオブジェクトを無効にして再コンパイルする必要があります。次に例を示します。
CONNNECT SYS / AS SYSDBA
SHUTDOWN IMMEDIATE;
STARTUP UPGRADE;
ALTER SYSTEM SET max_string_size=extended;
START $ORACLE_HOME/rdbms/admin/utl32k.sql
SHUTDOWN IMMEDIATE;
STARTUP;
注意:
MAX_STRING_SIZE
の値はSTANDARD
からEXTENDED
に変更できます。ただし、MAX_STRING_SIZE
の値をEXTENDED
からSTANDARD
には変更できません。MAX_STRING_SIZE = EXTENDED
を設定することは、データベースでアプリケーションの非互換性が発生する可能性がある設定を明示的に指定することになります。
参照:
MAX_STRING_SIZE
の推奨事項および手順などの詳細は、Oracle Databaseリファレンスを参照してください
パラレル実行サーバーの最大値および最小値の調整
環境に応じて、PARALLEL_MIN_SERVERSパラメータのデフォルト設定を減らすことができます。
Oracle Database 12cでは、PARALLEL_MIN_SERVERSのデフォルトは、0
からハードウェア・プラットフォームに基づいて提供された値に変更されました。パラレル実行に十分な最低限のサポートを提供するために、この変更が行われました。新しいデフォルト設定が高すぎる場合は、要件に応じて設定を調整します。PARALLEL_MAX_SERVERS
のデフォルトは変更されていません。以前の環境のデフォルトのまま変更されていない場合、追加の操作を実行する必要はありません。
参照:
PARALLEL_MIN_SERVERS
の詳細は、Oracle Databaseリファレンスを参照してください
Oracle Databaseのアップグレード後のリカバリ・カタログ・アップグレードについて
RMANクライアントで要求されるバージョンより古いリカバリ・カタログ・スキーマを使用している場合、そのカタログをアップグレードする必要があります。
参照:
-
RMANリカバリ・カタログの管理の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
-
リカバリ・カタログのアップグレードおよび
UPGRADE CATALOG
コマンドの詳細は、『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のアップグレード後の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のアップグレード後の外部認証された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 XML DBに対するFTPとHTTPのポートおよびHTTP認証の構成
Oracle Database Configuration 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ポートを手動で構成する必要があります。
-
DBMS_XDB_CONFIG.setHTTPPort(HTTP_port_number)
を使用して、Oracle XML DBのHTTPポートを設定します。SQL> exec DBMS_XDB_CONFIG.setHTTPPort(port_number);
-
Use
DBMS_XDB_CONFIG.setFTPPort(FTP_port_number)
を使用して、Oracle XML DBのFTPポートを設定します。SQL> exec DBMS_XDB_CONFIG.setFTPPort(FTP_port_number);
ノート:
手順内のFTPおよびHTTPで使用するポート番号は、
DBMS_XDB_CONFIG.getFTPPort
およびDBMS_XDB_CONFIG.getHTTPPort
をそれぞれ使用することによって問い合せることができます。 -
使用されているすべてのポート番号を確認するには、
DBMS_XDB_CONFIG.usedport
を問い合せます。
参照:
FTP、HTTP、HTTPSおよびWebDAVプロトコルを使用したOracle XML DB Repositoryのデータへのアクセスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。
Oracle Databaseのアップグレード後のOracle Textが提供するナレッジ・ベースのインストール
Oracle Textナレッジ・ベースに対してユーザーが拡張した項目は、Oracle Databaseアップグレード後に再生成する必要があります。
ユーザー拡張を再生成すると、指定したOracleホームにインストールされているすべてのデータベースに影響を与えます。
Oracle Textが提供するナレッジ・ベースは新しいOracle Databaseの付属製品の一部ですが、アップグレード後すぐに使用することはできません。アップグレード前には使用可能であったナレッジ・ベースに依存するOracle Textの機能は、アップグレード後には機能しなくなります。これらの機能を再度使用可能にするには、Oracle Textナレッジ・ベースを新しいOracle Databaseリリースのインストール・メディアからインストールする必要があります。
参照:
-
Oracle Textナレッジ・ベースの詳細は、Oracle Textアプリケーション開発者ガイドを参照してください
-
付属製品については、Oracle Databaseインストレーション・ガイドを参照してください
AUTO_LEXERを使用したOracle Text索引の再構築
Oracle Database 12cより前のリリースからOracle Textをアップグレードする場合、このトピックを参照してください。
新しいOracle Databaseリリースへのアップグレード完了後に、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 Application Express構成の更新
Oracle Application Expressのリリースとデータベースのインストール・タイプによっては、Oracle Application Expressがアップグレード手順に影響します。
アップグレードするOracle DatabaseリリースにOracle Application Expressリリース3.2以降が含まれる場合、新しいOracle Databaseリリースへのアップグレード後に追加構成を実行する必要はありません。ただし、Oracle Application Expressがレジストリに存在し、Oracle Application Expressがアップグレードに含まれる場合、open_cursorsパラメータを200以上に設定します。
アップグレードするOracle DatabaseがOracle Express Editionデータベースの場合、Oracle Express Edition環境に応じて調整されたOracle Application Expressの以前のリリースが含まれています。アップグレード時、最新のOracle Application Expressリリースが自動的にインストールされます。新しいOracle Databaseリリースと併用するには、インストール後の一連のステップを実行して、Oracle Application Expressを構成する必要があります。
参照:
-
Oracle Application Expressのインストール後の作業の詳細は、Oracle Application Expressインストレーション・ガイドを参照してください
-
http://www.oracle.com/technetwork/developer-tools/apex/overview/index.html
外部ネットワーク・サービスへのアクセス制御リスト(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 Vaultの有効化
ターゲットのデータベース・リリースによっては、Oracle Database Vaultを無効にしないとOracle Databaseのアップグレードを完了できない場合があります。
- Oracle Database Vaultの無効化なしでのOracle Databaseのアップグレード
ターゲットのOracle Databaseリリースが12.2以上である場合は、Oracle Database Vaultを無効にせずにアップグレードできます。 - Oracle Database Vaultが関連する一般的なアップグレード・シナリオ
アップグレード後にOracle Database Vaultを有効にする必要があるかどうかは、ソースのOracle Databaseリリースによって異なります。
Oracle Database Vaultの無効化なしでのOracle Databaseのアップグレード
ターゲットのOracle Databaseリリースが12.2以上である場合は、Oracle Database Vaultを無効にせずにアップグレードできます。
ソースのOracle DatabaseリリースでOracle Database Vaultを有効にしていた場合は、Oracle Database Vaultを事前に無効にしなくても、Oracle DatabaseをOracle Database 18cにアップグレードできます。ソースのOracle DatabaseリリースがOracle Database 12cリリース1 (12.1)以上である場合は、アップグレード後に、アップグレード前に用意したものと同じ強化設定を使用してOracle Database Vaultが有効になります。たとえば、ソース・データベースがOracle Databaseリリース12.1であり、そのリリースでOracle Database Vaultを無効にしていた場合は、アップグレード後も無効になります。アップグレード前にソースのOracle Databaseリリース12.1データベースで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
を付与されたユーザー・アカウントを使用して実行します。プロシージャを実行したら、そのプロシージャを有効にするためにデータベース・インスタンスを再起動します。
Oracle Database Vaultが関連する一般的なアップグレード・シナリオ
アップグレード後にOracle Database Vaultを有効にする必要があるかどうかは、ソースのOracle Databaseリリースによって異なります。
-
Oracle Database 11gリリース2 (11.2)以下からのアップグレード: アップグレード後、Oracle Database Vaultはデフォルトで無効になります。
-
Oracle Database 12cリリース1 (12.1)以上からのアップグレード: アップグレード後、Oracle Database Vaultはアップグレード前に用意したものと同じ強化ステータスになります。
表4-1 Oracle Database Vaultの一般的なアップグレード・シナリオおよびアップグレード準備作業
ソース・データベース・リリース | ターゲット・データベース・リリース | アップグレード前にDatabase Vaultを無効にする必要があるかどうか | アップグレード後のDatabase Vaultのステータス |
---|---|---|---|
11.2以下 | 12.1 | 可 | 無効。アップグレード後にDatabase Vaultを手動で有効にする必要があります。 |
11.2以下 | 12.2、18.1以上 | いいえ | 無効。アップグレード後にDatabase Vaultを手動で有効にする必要があります。 |
12.1、12.2、18.1以上 | 12.2、18.1以上 | いいえ | Database Vaultはアップグレード前に用意したものと同じ強化ステータスになります。 |
SQLNET.ALLOWED_LOGON_VERSIONパラメータの動作の確認
10gより前のリリースのクライアントからのOracle Databaseに対する接続は、ORA-28040: 「一致する認証プロトコルがありません」
というエラーによって失敗します。
Oracle Database 18c以上では、SQLNET.ALLOWED_LOGON_VERSIONパラメータのデフォルト値がOracle Database 12c (12.2)の11から12に変更されています。このパラメータの使用は非推奨になりました。
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パラメータを設定して正しいパスワード検証機能を使用するようにデータベースを構成します。
既存のデータベースにパスワードで保護されたロール(セキュア・ロール)があり、デフォルトのSQLNET.ALLOWED_LOGON_VERSION_SERVER
設定である12を使用してOracle Database 18cにアップグレードする場合、そのセキュア・ロールに含まれるのはリリース10gの検証機能のみであるため、アップグレード後もセキュア・ロールが使用可能な状態になるように、管理者は各セキュア・ロールのパスワードをリセットする必要があります。
参照:
-
パスワードのセキュリティの脅威から守る方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
-
ユーザーのパスワード・バージョンの設定の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。