Oracle Databaseのアップグレードを開始する前に完了するデータベースの準備作業

Oracle Databaseのアップグレードを開始する前に、これらのデータベースの準備作業を完了していることを確認してください。

Oracle Databaseをアップグレードする場合のパッチ・セットの更新および要件
アップグレードを開始する前に、新しいリリースのOracle Databaseを最新のパッチ・セット更新(BPまたはPSU)に更新します。
オプティマイザ統計の収集によるOracle Databaseの停止時間の短縮
この手順を使用して、Oracle Databaseのアップグレードを実行する前に統計を収集することをお薦めします。
アップグレード前にマテリアライズド・ビューのリフレッシュが完了していることの確認
この手順を使用して、システムに問い合せて進行中のマテリアライズド・ビューのリフレッシュがあるかどうかを確認します。
アップグレード前にバックアップ・モードのファイルがないことの確認
この手順を使用して、システムに問い合せてバックアップ・モードのファイルのリストを取得します。
アップグレード前にメディア・リカバリを必要とするファイルがないことの確認
この手順を使用して、メディア・リカバリを必要とするファイルのリストを取得します。
アップグレード前の未処理の分散トランザクションの解決
この手順を使用して、アップグレードを開始する前に未処理の分散トランザクションを解決します。
アップグレード時のスタンバイ・データベースとプライマリ・データベースの同期化
スタンバイ・データベースが存在する場合、Oracle Databaseをアップグレードする前に、プライマリ・データベースと同期化する必要があるかどうか確認します。
アップグレード前のデータベースのごみ箱の消去
アップグレード前にPURGE文を使用して、項目とその関連オブジェクトを削除し、記憶領域を解放します。
Oracle Enterprise Manager Database Controlの構成およびデータの保存
アップグレード前にemdwgrdユーティリティを使用して、Oracle Enterprise Manager Database Control (DB Control)をダウングレードしてリストアできるように、DB Controlファイルを保存します。
emremove.sqlを使用したDB Controlの手動による削除
このSQLプロシージャを使用して、アップグレード処理中の停止時間を最小化します。
JSON対応コンテキスト検索索引の削除
Oracle Database 12cリリース1 (12.1)から12cリリース2 (12.2)にアップグレードする場合は、アップグレードする前にJSON対応コンテキスト索引を削除することをお薦めします。
透過的暗号化Oracleウォレットのコピー
透過的暗号化(TDE)でOracleウォレットを使用しており、Database Upgrade Assistant (DBUA)を使用してデータベースをアップグレードする場合は、sqlnet.oraおよびウォレット・ファイルを新しいOracleホームにコピーします。
Oracle Databaseのアップグレード時のOracle Net Servicesに関する推奨事項
アップグレード前にOracle Net Servicesに関するこれらの手順およびパラメータ変更を参照してください。
パスワードの大/小文字の区別とアップグレードについて
デフォルトで、Oracle Database 12cリリース2 (12.2)は排他モードにアップグレードされます。排他モードは大/小文字を区別しないパスワードを基にした認証をサポートしません。
大/小文字を区別しないパスワード・バージョンを使用しているアカウントがあるかどうかの確認
次の手順を使用して、アップグレードするOracle Databaseに大/小文字を区別しないパスワード・パージョンを使用しているアカウントや構成パラメータがないか、確認します。
読取り専用およびオフラインの表領域を使用したアップグレードの実行
アップグレード中にスキーマベースの表領域をオフラインに設定するには、Oracle Database 12cリリース2で使用できるパラレル・アップグレード・ユーティリティを、-Tオプションを指定して使用します。

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

Oracle Databaseをアップグレードする場合のパッチ・セットの更新および要件

アップグレードを開始する前に、新しいリリースのOracle Databaseを最新のパッチ・セット更新(BPまたはPSU)に更新します。

Oracle Database 12cのソフトウェアには、リリースの時点で最新のOracle Databaseのすべてのパッチおよび更新を含む完全なリリースが含まれます。

アップグレードまたはダウングレード・プロセスを開始する前に、以前のOracle Databaseリリースと新しいOracle Databaseリリースの両方を最新のパッチ・セット更新(BPまたはPSU)に更新することを強くお薦めします。

My Oracle Supportで、最新パッチの入手方法に加え、ライフサイクル管理と自動パッチ適用に使用するツールについて詳細に説明したノートが提供されています。次に例を示します。

My Oracle Supportノート854428.1には、パッチ・セットと更新に関する情報が記載されています。
My Oracle Supportノート730365には、使用可能なOracle Databaseのほとんどのリリースのアップグレードの参照リスト(ダウンロード情報、パッチ番号、他のノートへのリンクなど)が記載されています。
My Oracle Supportノート2180188.1にはアップグレード用、ダウングレード用、および以前のリリースとの共存用の単発のパッチが含まれています。

参照先

オプティマイザ統計の収集によるOracle Databaseの停止時間の短縮

この手順を使用して、Oracle Databaseのアップグレードを実行する前に統計を収集することを強くお薦めします。

統計が不足しているか、Oracle Databaseのアップグレード中に大幅に変更された表に対して統計収集が発生します。

データベースに多数のディクショナリ表が含まれている場合は、アップグレードの開始前夜に統計を収集することをお薦めします。

ダウンタイムの時間を短縮するには、データベース構成に次の手順を使用します。

非CDBのOracle Databaseの場合: DBMS_STATS.GATHER_DICTIONARY_STATSプロシージャを使用して、統計を収集することをお薦めします。たとえば、次のSQL文を入力します。
```
SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
```
CDB (マルチテナント・アーキテクチャ) Oracle Databaseの場合: catconを使用して、マルチテナント・アーキテクチャ全体のデータ・ディクショナリ統計を収集することをお薦めします。

コンテナ・データベースのすべてのPDBのディクショナリ統計を収集するには、次の構文を使用します。

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -l /tmp -b gatherstats -- --x"exec dbms_stats.gather_dictionary_stats"

特定のPDBに関するディクショナリ統計を収集するには、次のような構文を使用します。
```
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -l /tmp -c
'SALES1' -b gatherstats -- --x"exec dbms_stats.gather_dictionary_stats"
```
前述の例では、SALES1というデータベースを指定することにより、実行するコマンドのPDB包含リストを-c SALES1オプションで指定しています。オプション-b gatherstatsでは、ログの基底名を指定します。オプション--xは、実行するSQLコマンドを指定します。SQLコマンドそのものは、引用符で囲みます。

参照:

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

オプティマイザ統計の収集の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

親トピック: Oracle Databaseのアップグレードを開始する前に完了するデータベースの準備作業

アップグレード前にマテリアライズド・ビューのリフレッシュが完了していることの確認

この手順を使用して、システムに問い合せて進行中のマテリアライズド・ビューのリフレッシュがあるかどうかを確認します。

Oracle Databaseをアップグレードする前に、すべてのマテリアライズド・ビューがリフレッシュを完了するまで待機する必要があります。

次のSQL問合せを実行します。

SQL> SELECT s.obj#,o.obj#,s.containerobj#,lastrefreshdate,pflags,xpflags,o.name,o.owner#,
bitand(s.mflags, 8) from obj$ o, sum$ s WHERE o.obj# = s.obj# AND o.type# =
42 AND bitand(s.mflags, 8) = 8;

参照:

マテリアライズド・ビューを管理するためのDBMS_MVIEWパッケージの使用の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
データベースから既存のマテリアライズド・ビューを永続的に削除するためのDROP MATERIALIZED VIEW文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

親トピック: Oracle Databaseのアップグレードを開始する前に完了するデータベースの準備作業

アップグレード前にバックアップ・モードのファイルがないことの確認

この手順を使用して、システムに問い合せてバックアップ・モードのファイルのリストを取得します。

Oracle Databaseをアップグレードするときには、バックアップ・モードのファイルがあってはなりません。次のv$backupプロシージャを実行して、バックアップのステータスを確認します。

SQL> SELECT * FROM v$backup WHERE status != 'NOT ACTIVE';

このSQL文でファイルがまだバックアップ中であることが示された場合は、バックアップが完了するのを待つか、または不要なバックアップを強制終了してからアップグレードを試行してください。

参照:

データのバックアップおよびアーカイブの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

親トピック: Oracle Databaseのアップグレードを開始する前に完了するデータベースの準備作業

アップグレード前にメディア・リカバリを必要とするファイルがないことの確認

この手順を使用して、メディア・リカバリを必要とするファイルのリストを取得します。

Oracle Databaseをアップグレードする前に、メディア・リカバリを必要とするファイルがないことを確認する必要があります。システムに問い合せてファイルのリストを取得し、必要に応じてこれらのファイルのリカバリを行うことができます。

次の文を実行します。
```
SQL> SELECT * FROM v$recover_file;
```

参照:

ブロック・メディア・リカバリの実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

親トピック: Oracle Databaseのアップグレードを開始する前に完了するデータベースの準備作業

アップグレード前の未処理の分散トランザクションの解決

この手順を使用して、アップグレードを開始する前に未処理の分散トランザクションを解決します。

Oracle Databaseをアップグレードする前に、未処理の分散トランザクションを解決する必要があります。これを行うには、最初に問合せによって保留中のトランザクションを確認してから、トランザクションをコミットします。保留中のすべての分散トランザクションがコミットされるまで待機する必要があります。

次の文を実行します。
```
SQL> SELECT * FROM dba_2pc_pending;
```

前述のステップの問合せによって行が戻された場合は、次の各文を実行します。

SQL> SELECT local_tran_id FROM dba_2pc_pending;
SQL> EXECUTE dbms_transaction.purge_lost_db_entry('');
SQL> COMMIT;

ヒント:

分散トランザクションの管理の詳細は、『Oracle Database管理者ガイド』を参照してください

親トピック: Oracle Databaseのアップグレードを開始する前に完了するデータベースの準備作業

アップグレード時のスタンバイ・データベースとプライマリ・データベースの同期化

スタンバイ・データベースが存在する場合、Oracle Databaseをアップグレードする前に、プライマリ・データベースと同期化する必要があるかどうか確認します。

次の問合せを実行します。

SQL> SELECT SUBSTR(value,INSTR(value,'=',INSTR(UPPER(value),'SERVICE'))+1)
FROM v$parameter
WHERE name LIKE 'log_archive_dest%' AND UPPER(value) LIKE 'SERVICE%';

前のステップの問合せによって行が戻された場合は、スタンバイ・データベースとプライマリ・データベースを同期化します。
- プライマリ・データベースでの最後のログ・スイッチの後のすべてのログがスタンバイ・サーバーに転送されていることを確認します。
- NODELAYオプションを使用して、スタンバイ・データベースのリカバリを開始します。

参照:

フィジカル・スタンバイ・データベースとプライマリ・データベースの同期の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください

親トピック: Oracle Databaseのアップグレードを開始する前に完了するデータベースの準備作業

アップグレード前のデータベースのごみ箱の消去

アップグレード前にPURGE文を使用して、項目とその関連オブジェクトを削除し、記憶領域を解放します。

Oracle Databaseのアップグレード処理を開始する前に、データベース内のすべてのユーザーのゴミ箱を空にしておく必要があります。SYSDBA権限がある場合は、RECYCLEBINのかわりに、DBA_RECYCLEBINを指定することによって、データベース全体のすべてのゴミ箱を消去できます。Oracle Database 12c以上では、SYSDBA権限を付与する必要なく、新しいPURGE DBA_RECYCLEBINシステム権限を使用して同じアクションを実行できます。

PURGE DBA_RECYCLEBIN文は、システム全体のごみ箱からすべてのオブジェクトを削除する特別なPURGEコマンドで、各ユーザーのごみ箱を空にすることと同じです。以前のリリースでは、この文にはSYSDBA管理者権限が必要であり、これは、義務の分離および最低限の権限の点で非常に望ましくないものです。義務の分離を順守するために、Oracle Database 12cでは新しいシステム権限であるPURGE DBA_RECYCLEBINが導入され、これによって、SYSDBA管理者権限を持たずにPURGE DBA_RECYCLEBINを実行することが可能です。

データベースのごみ箱を空にするには、次のコマンドを実行します。

SQL> PURGE DBA_RECYCLEBIN

注意:

アップグレード処理を行う際は、ORA-00600エラーの発生の回避とアップグレード時間の短縮のために、ごみ箱を空にしておく必要があります。

参照:

ゴミ箱内のオブジェクトの消去の詳細は、『Oracle Database管理者ガイド』を参照してください。
PURGE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
データベース管理に対する義務の分離の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

親トピック: Oracle Databaseのアップグレードを開始する前に完了するデータベースの準備作業

Oracle Enterprise Manager Database Controlの構成およびデータの保存

アップグレード前にemdwgrdユーティリティを使用して、Oracle Enterprise Manager Database Control (DB Control)をダウングレードしてリストアできるように、DB Controlファイルを保存します。

アップグレード前に既存のDB Control構成ファイルとデータを保存した場合は、データベースをアップグレードした後にOracle Enterprise Manager DB Controlをリストアするだけで済みます。ダウングレードのオプションを保存し、DB Controlのリストアが必要な場合は、これらのファイルを保存します。

Oracle Database 12cリリース1 (12.1)以上では、アップグレード処理の一部としてDB Controlは削除されます。データベースをアップグレードする前にDB Controlの制御ファイルとデータのコピーを保存するためのemdwgrdユーティリティが提供されています。ダウングレードして以前のリリースのOracle DatabaseからDB Control構成をリストアするには、DB Control構成およびデータのコピーを保持しておく必要があります。

emdwgrdユーティリティは、新しいOracle Database 12cリリースのORACLE_HOME/binディレクトリにあります。emdwgrdユーティリティは、LinuxとUNIX用のemdwgrdとemdwgrd.plおよびWindows用のemdwgrd.batとemdwgrd.plで構成されています。ユーティリティを実行する前に、Oracle Database 12cのソフトウェアをインストールして、新しいOracleホームからスクリプトを実行する必要があります。emdwgrdユーティリティでは、ORACLE_HOMEがアップグレード対象のリリースのOracleホームに設定されている必要があります。

新しいOracle Database 12cリリースのソフトウェアをインストールします。
ORACLE_HOMEを古いOracleホームに設定します。
ORACLE_SIDを、アップグレードするデータベースのSIDに設定します。
PATH、LD_LIBRARY_PATHおよびSHLIB_PATHが、アップグレードしたOracle DatabaseのOracleホームを指すように設定します。
ディレクトリを新しいOracle DatabaseリリースのOracleホームに変更します。
次のガイドラインに従って、データベース・デプロイメントの手順を使用してemdwgrdを実行します。
- Oracleホームが共有デバイス上にある場合、-sharedオプションをemdwgrdコマンドラインに追加します。
- ここでの例では、old_SIDは、アップグレードするデータベースのシステム識別子(SID)で、save_directoryは、既存のDB Controlファイルおよびデータを保存するために選択した格納場所へのパスです。
- 単一インスタンス・データベース:
  
  emdwgrd -save -sid old_SID -path save_directory
  
  LinuxおよびUNIXシステムの場合、このスクリプトはemdwgrd.shにあります。
  
  Windowsの場合、このスクリプトはemdwgrd.batにあります。
- Oracle Real Application Clusters(Oracle RAC)データベース:
  1. すべてのクラスタ・メンバー・ノードでリモート・コピーを有効にする必要があります。どのリモート・コピーを構成するかを指定するには、環境変数を定義します。次に例を示します。
    
    setenv EM_REMCP /usr/bin/scp
  2. 次の構文を使用して、emdwgrdを実行します。
    
    emdwgrd -save -cluster -sid old_SID -path save_directory
アップグレードするデータベースのSYSパスワードを入力します。

注意:

データベースをアップグレードした後に、DBUAバックアップおよびリストア処理を使用して、以前のOracle Enterprise Manager Database Control環境に戻すことも可能です。ただし、アップグレードしてからリストアするまでの間に蓄積されたユーザー・データは、すべて失われます。データベースの制御ファイルおよびデータを保存しておくことで、データベースとDB Controlの両方をダウングレードできます。アップグレードしてからダウングレードするまでの間に蓄積されたDB Controlのデータはすべて失われますが、すべてのユーザー・データが保持されます。

親トピック: Oracle Databaseのアップグレードを開始する前に完了するデータベースの準備作業

emremove.sqlを使用したDB Controlの手動による削除

このSQLプロシージャを使用して、アップグレード処理中の停止時間を最小化します。

アップグレード前の準備の一環としてemremove.sqlスクリプトを実行できます。

emremove.sqlスクリプトは、Oracle Enterprise Manager関連のスキーマおよびオブジェクトを削除します。このスクリプトは、6つのステージで処理を実行するため、完了までに数分かかることがあります。このスクリプトは、SYSMANがあり、関連するセッションがSQL*Plus、Oracle Enterprise Managerまたはその他のクライアントからアクティブの場合に、完了するまでさらに時間がかかる場合があります。

注意:

ダウングレード後にDB Controlをリストアするには、前もってDB Control構成およびデータをバックアップしておく必要があります。この手順を開始する前にバックアップを完了してください。

DB Controlアプリケーションを構成したら、停止します。以下のコマンドを使用します。
```
$ emctl stop dbconsole
```
SQL*Plusを起動し、SYSDBAとしてSYSアカウントを使用してデータベースに接続します。
サイレント・モードと冗長モードでemremove.sqlを構成できます。実行中にスクリプトを監視する場合、次の変数を設定します。
```
SET ECHO ON;
SET SERVEROUTPUT ON;
```
emremove.sqlを実行します。このスクリプトは、パスORACLE_HOME/rdbms/admin/の新しいOracle Database 12cホームにあります。
次に例を示します。
```
SQL> @emremove.sql
```
emremove.sqlの完了後、ファイル・システムからORACLE_HOME/HOSTNAME_SIDディレクトリおよびORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_HOSTNAME_SIDディレクトリを手動で削除する必要があります。

注意:

前にDB Controlをリリース10.2.0.3から10.2.0.4にアップグレードした場合、ファイル・システムから次のディレクトリも削除する必要があります。

ORACLE_HOME/HOSTNAME_SID.upgrade

ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_HOSTNAME_SID.upgrade
Windowsプラットフォームでは、通常、OracleDBConsoleSIDという名前のDBコンソール・サービスも削除します。

親トピック: Oracle Databaseのアップグレードを開始する前に完了するデータベースの準備作業

JSON対応コンテキスト検索索引の削除

Oracle Database 12cリリース1 (12.1)から12cリリース2 (12.2)にアップグレードする場合は、アップグレードする前にJSON対応コンテキスト索引を削除することをお薦めします。

既存のJSON対応索引を削除することをお薦めします。

関連項目

Oracle Database JSON開発者ガイド

親トピック: Oracle Databaseのアップグレードを開始する前に完了するデータベースの準備作業

透過的暗号化Oracleウォレットのコピー

透過的暗号化(TDE)でOracleウォレットを使用しており、Database Upgrade Assistant (DBUA)を使用してデータベースをアップグレードする場合は、sqlnet.oraおよびウォレット・ファイルを新しいOracleホームにコピーします。

アップグレードを開始する前に、sqlnet.oraおよびウォレット・ファイルをコピーする必要があります。

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

親トピック: Oracle Databaseのアップグレードを開始する前に完了するデータベースの準備作業

Oracle Databaseのアップグレード時のOracle Net Servicesに関する推奨事項

アップグレード前にOracle Net Servicesに関するこれらの手順およびパラメータ変更を参照してください。

Oracle Database 12cでは、新しい基礎となるネット・サービス・パラメータによってデータ圧縮が可能で、これにより、SQL TCP接続を介して転送されるセッション・データ・ユニットのサイズが縮小されます。

次のsqlnet.oraファイルの新しいパラメータで、圧縮、および優先圧縮方式を指定します。

SQLNET.COMPRESSION
SQLNET.COMPRESSION_LEVELS
SQLNET.COMPRESSION_THRESHOLD

これらの新しいパラメータは以前のリリースではサポートされておらず、Oracle Database 12cでのみ使用可能です。

アップグレードするOracle Databaseでリスナーが構成されていない場合、DBUAを実行する前に、Oracle Net Configuration Assistant (NETCA)を実行して、listener.oraファイルを含むOracle Databaseの新しいリリースのリスニング・プロトコルのアドレスおよびサービス情報を構成する必要があります。リリース11.2より前のリリースのOracle Databaseには、新しいバージョンのリスナーを作成する必要があります。新しいリスナーには、以前のOracle Databaseとの下位互換性があります。

DBUAを使用してOracle RACデータベースをアップグレードする場合、リスナーが古いOracleホームから新しいOracle Grid Infrastructureホームに自動的に移行されます。Oracle Grid Infrastructureホームでlsnrctlコマンドを使用してリスナーを管理する必要があります。以前のリリースのOracleホームの場所からlsnrctlコマンドを使用しないでください。

注意:

ソース・ホームにリスナーが構成されており、ソース・ホームのOracle DatabaseがターゲットのOracle Databaseホームよりも古い場合、アップグレード処理中にDBUAはデフォルトで、移行用にソース・ホームのリスナーを選択します。

参照:

新しいsqlnet.ora圧縮パラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

Oracle Net Configuration Assistantの使用方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

親トピック: Oracle Databaseのアップグレードを開始する前に完了するデータベースの準備作業

パスワードの大/小文字の区別とアップグレードについて

デフォルトで、Oracle Database 12cリリース2 (12.2)は排他モードにアップグレードされます。排他モードは大/小文字を区別しないパスワードを基にした認証をサポートしません。

サーバーが排他モードで実行されている場合、10Gパスワード・バージョンだけを持つアカウントにはアクセスできなくなります。

以前のリリースのOracle Databaseでは、SEC_CASE_SENSITIVE_LOGON=FALSEを設定することにより、大/小文字を区別しないパスワード・ベースの認証プロトコルを許可するように構成できました。Oracle Database 12cリリース2 (12.2)以降は、デフォルトのパスワード・ベースの認証プロトコル構成で大/小文字を区別しない10Gパスワードの使用が排除されています。これは、デフォルトで、SQLNET.ORAパラメータSQLNET.ALLOWED_LOGON_VERSION_SERVERが12 (排他モード)に設定されるためです。データベースが排他モードで設定されている場合、パスワード・ベースの認証プロトコルでは大/小文字を区別するいずれかのパスワード・バージョン(11Gまたは12C)が、認証されるアカウントに存在する必要があります。このモードは、以前のリリースで使用されていた10Gパスワード・バージョンの使用を排除します。Oracle Database 12cリリース2にアップグレードした後は、大/小文字を区別しない10Gパスワード・バージョンだけを持つアカウントにはアクセスできなくなります。これが発生するのは、サーバーはデフォルトで排他モードで実行されるためです。Oracle Databaseが排他モードで構成されていると、古い10Gパスワード・バージョンを使用してクライアントを認証できません。クライアントを認証するパスワード・バージョンなしで、サーバーはそのまま構成されます。

セキュリティを高めるためには、大/小文字を区別するパスワード・ベースの認証を有効にしておくことをお薦めします。これはデフォルトです。ただし、Oracle Database 12cリリース2 (12.2)へのアップグレード中に、大/小文字を区別する認証を一時的に無効にすることはできます。アップグレード後に、パスワード・バージョンを管理するための実装計画の一環として、大/小文字を区別するパスワード・ベースの認証を有効にするかどうかを決定できます。

アップグレード前に、デフォルトのパスワード・ベースの認証プロトコル構成により影響を受けるかどうかを判定するために、次のチェックを実行することをお薦めしています。

10Gの大/小文字を区別しないパスワード認証バージョンだけを持つアカウントがあるかどうかを確認します。
重要なパッチ更新CPUOct2012またはそれ以降のパッチ更新を適用していないOracle Database 11gリリース2 (11.2.0.3)データベースがあるかどうか、かつ、大/小文字を区別しない10Gパスワード・バージョンを持たないアカウントがあるかどうかを確認します。
FALSEに設定した非推奨のパラメータSEC_CASE_SENSITIVE_LOGONがないことを確認します。このパラメータをFALSEに設定すると、大/小文字を区別するパスワード・バージョン(11Gおよび12Cパスワード・バージョン)を認証に使用できません。

大/小文字を区別しないバージョンを使用するアカウントのオプション

大/小文字を区別しない10Gパスワード・バージョンのみを持つユーザー・アカウントがある場合は、次の代替方式のいずれかを選択する必要があります。

アップグレード前に、10Gパスワード・バージョンだけを持つそれぞれのアカウントのパスワード・バージョンを更新します。これを行うには、10Gパスワードを使用するユーザー・パスワードを期限切れにして、そうしたユーザーにアカウントにログインするように要求します。ユーザーがログインを試行すると、サーバーはこれらのユーザーのパスワード・バージョンのリストを自動的に更新しますが、これには大/小文字を区別するパスワード・バージョンが含まれます。
SQLNET.ORAパラメータSQLNET.ALLOWED_LOGON_VERSION_SERVERの設定を、排他モード以外の設定に変更します。例: SQLNET.ALLOWED_LOGON_VERSION_SERVER=11

大/小文字を区別しないパスワード・バージョンを使用しているアカウントがあるかどうかの確認

次の手順を使用して、アップグレードするOracle Databaseに大/小文字を区別しないパスワード・パージョンを使用しているアカウントや構成パラメータがないか、確認します。

デフォルトで、Oracle Database 12cリリース2 (12.2)では、10Gパスワード・バージョンは生成されることも許可されることもありません。

SQLNET.ALLOWED_LOGON_VERSION_SERVERを、大/小文字を区別しないバージョンを使用できる許容度の高い認証プロトコルに設定しておらず、かつ、大/小文字を区別しないパスワード・バージョンで認証されるユーザー・アカウントがデータベースでロックされないようにする場合は、該当するアカウントを確認して、それらが大/小文字を区別するパスワード・バージョンを使用していることを確認します。

例2-1 大/小文字を区別しない(10G)バージョンを使用するユーザー・アカウントの検索

管理ユーザーとしてSQL*Plusにログインし、次のSQL問合せを入力します。

SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;

次の結果は、アカウントのパスワード・バージョンを示しています。

USERNAME                       PASSWORD_VERSIONS
------------------------------ -----------------
JONES                          10G 11G 12C
ADAMS                          10G 11G
CLARK                          10G 11G
PRESTON                        11G
BLAKE                          10G

この例では、各ユーザー・アカウント・パスワードの使用中のバックグラウンド検証バージョンは異なります。

JONESはOracle Database 10Gで作成されましたが、JONESのパスワードは、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの設定が8に設定されたときにOracle Database 12Cにリセットされました。その結果、このパスワードのリセットによって3つのバージョンがすべて作成されました。11Gおよび12Cは大/小文字を区別するパスワードを使用します。
ADAMSおよびCLARKは最初に10Gバージョンで作成され、次に、以前のリリースからインポートされた後に11Gバージョンで作成されました。これらのアカウント・パスワードはその後、非推奨のパラメータSEC_CASE_SENSITIVE_LOGONをTRUEに設定した場合、11Gでリセットされました。
BLAKEのパスワードは10Gバージョンで作成され、パスワードはリセットされませんでした。その結果、ユーザーBLAKEは引き続き10Gパスワード・バージョンを使用し、これは大/小文字を区別しないパスワードを使用します。

ユーザーBLAKEはアップグレード前には10Gパスワード・バージョンだけを持っています。

SQL> SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;

USERNAME PASSWORD_VERSIONS
------------------------------ -----------------
BLAKE 10G

パスワードに対する措置をせずにただ、12cリリース2 (12.2)にアップグレードした場合、そのアカウントにはアクセスできなくなります。アップグレード前に、(SQLNET.ORAパラメータSQLNET.ALLOWED_LOGON_VERSION_SERVERを、より許容度の高い認証モードに設定して、)システムが排他モードで構成されていないことを確認する必要があります。

例2-2 大/小文字を区別しないパスワードを持つアカウントの修正

次の手順を実行します。

次のSQL問合せを使用して、10Gパスワード・バージョンだけを持つアカウントを検索します。

      select USERNAME
         from DBA_USERS
        where ( PASSWORD_VERSIONS = '10G '
               or PASSWORD_VERSIONS = '10G HTTP ')
          and USERNAME <> 'ANONYMOUS';

SQLNET.ORAパラメータSQLNET.ALLOWED_LOGON_VERSION_SERVERの設定を、該当するアカウントに適切なレベルに編集することにより、システムが排他モードで実行されるようにシステムを構成します。次に例を示します。
```
SQLNET.ALLOWED_LOGON_VERSION_SERVER=11
```
その後で、アップグレードに進みます。
アップグレードが終了したら、次のコマンド構文を使用してステップ1で検出したアカウントを期限切れにします。usernameは、ステップ1の問合せで返されたユーザーの名前です。

ALTER USER username PASSWORD EXPIRE;
パスワードを期限切れにしたユーザーに、ログインするよう依頼します。
これらのユーザーがログインするときに、パスワードをリセットするよう、プロンプトが表示されます。システムは10Gパスワード・バージョンに加えて、欠落している11Gおよび12Cパスワード・バージョンを内部的に生成します。システムは許容モードで実行中のため、10Gパスワード・バージョンは引き続き存在します。
ユーザーが接続しているクライアント・ソフトウェアにO5L_NP機能フラグがあることを確認します。

注意:

Oracle Databaseリリース11.2.0.4以降のすべてのクライアント、およびOracle Databaseリリース12.1以降のすべてのクライアントにはO5L_NP機能があります。他のクライアントではCPUOct2012パッチを適用してO5L_NP機能を取得する必要があります。

O5L_NP機能フラグは、『Oracle Database Net Servicesリファレンス』のパラメータSQLNET.ALLOWED_LOGON_VERSION_SERVERの項に記載されています。
すべてのクライアントにO5L_NP機能が導入されたら、次のプロシージャを使用してセキュリティを元の排他モードに上げます。
1. インスタンス初期化ファイルからSEC_CASE_SENSITIVE_LOGON設定を削除するか、SEC_CASE_SENSITIVE_LOGONインスタンス初期化パラメータをTRUEに設定します。次に例を示します。
  
  SEC_CASE_SENSITIVE_LOGON = TRUE
2. サーバーのSQLNET.ORAファイルからSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを削除するか、サーバーのSQLNET.ORAファイルのSQLNET.ALLOWED_LOGON_VERSION_SERVERの値を12に戻して排他モードに設定します。次に例を示します。
  
  SQLNET.ALLOWED_LOGON_VERSION_SERVER = 12

次のSQL問合せを使用して、まだ10Gパスワード・バージョンを持っているアカウントを検索します。

       select USERNAME
         from DBA_USERS
        where PASSWORD_VERSIONS like '%10G%'
          and USERNAME <> 'ANONYMOUS';

ステップ8の問合せから戻されたアカウントのリストを使用して、まだ10Gパスワード・バージョンを持っているすべてのアカウントを期限切れにします。次の構文を使用して、アカウントを期限切れにします。usernameは問合せで返されたリストにある名前です。

ALTER USER username PASSWORD EXPIRE;
期限切れにしたアカウントのユーザーに、アカウントにログインするよう依頼します。

ユーザーはログインするときに、パスワードを再設定するようプロンプトが表示されます。システムは、アカウントの11Gおよび12Cパスワード・バージョンだけを内部的に生成します。システムは排他モードで実行されているため、10Gパスワード・バージョンはもう生成されません。
ステップ1の問合せを実行して、システムがセキュア・モードで実行されていることを確認します。どのユーザーも検出されないことを確認します。この問合せでどのユーザーも検出されない場合、それは、10Gパスワード・バージョンがシステムにもう残っていないことを意味します。

例2-3 SEC_CASE_SENSITIVE_LOGON SetがFALSEになっているものがないことの確認

SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータが12または12aに設定されている場合、Oracle DatabaseはSEC_CASE_SENSITIVE_LOGONのFALSE設定の使用を妨げません。これにより、アップグレードされたデータベースのすべてのアカウントがアクセス不能になる可能性があります。

SQL> SHOW PARAMETER SEC_CASE_SENSITIVE_LOGON

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
sec_case_sensitive_logon             boolean     FALSE

次のコマンドを使用して、このパラメータを変更できます。

SQL> ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = TRUE;

System altered.

注意:

パラメータSQLNET.ALLOWED_LOGON_VERSION_SERVERの値が12よりも許容度の高いバージョン(11など)に変更されないかぎり、SEC_CASE_SENSITIVE_LOGONパラメータをFALSEに設定しないでください。

読取り専用およびオフラインの表領域を使用したアップグレードの実行

アップグレード中にスキーマベースの表領域をオフラインに設定するには、Oracle Database 12cリリース2で使用できるパラレル・アップグレード・ユーティリティを、-Tオプションを指定して使用します。

Oracle Databaseでは以前のリリースで作成されたファイル・ヘッダーを読み取ることができるため、アップグレード時にそれらに対して処理を行う必要はありません。オフライン・データ・ファイルのファイル・ヘッダーは、後でそれらのファイルがオンラインになったときに更新されます。READ ONLY表領域のファイル・ヘッダーは、それらがREAD WRITEに変更されたときに更新されます。表スペースをオフラインに設定すると、アップグレード中に表領域が変更されないことが保証されます。アップグレードが完了すると、アップグレード中にオフラインに設定されたユーザー表領域は、すべてオンラインに戻ります。

アップグレードで致命的なエラーが発生し、その結果アップグレードで表領域をオンラインに戻すことができなくなった場合、アップグレード・ログ・ファイルを参照してください。ログ・ファイルには、表領域を使用可能にするために必要な実際のSQL文が含まれています。表領域をオンラインに戻すには、データベースにログ・ファイルのSQL文を実行するか、PDBごとにログ・ファイルを実行する必要があります。

Oracle Database 12cリリース2 (12.2)での表領域アップグレードの変更

Oracle Database 12cリリース2以上では、-Tオプションを指定してパラレル・アップグレード・ユーティリティを実行し、アップグレード中にスキーマベースの表領域(ユーザー表領域)をオフラインに設定できます。これらの表領域をオフラインにすると、アップグレード前のバックアップの必要性を下げられます。パラレル・アップグレード・ユーティリティ(catctl.pl)は表領域を分析し、表領域の正しい設定を自動的に選択してこれを読取り専用に設定します。ユーティリティはOracleが維持するオブジェクトが含まれる表領域をREAD ONLYに設定しません。

この変更により、ユーザーはアップグレードの一環としてより多くの表領域を自動的にREAD ONLYモードに設定できます。以前のリリースでは、表領域を手動でREAD ONLYまたはOFFLINEモードに設定できました。ただし、一部のケースではアップグレードの失敗を防ぐためにREAD WRITEに戻す必要がありました。

また、Oracle Database 12cリリース2 (12.2)ではALTER TYPE文の動作が変更されています。アクセス可能な表領域に従属表がある場合は、アップグレード中に、それが自動的に新しいバージョン・タイプにアップグレードされます。従属表がREAD ONLY表領域にある場合は、自動的にアップグレードされません。その場合は、アップグレードが完了した後にutluptabdata.sqlスクリプトを実行して、アップグレード中にREAD ONLY表領域にあったそれらの表をアップグレードします。

スキーマベースの表領域をオフラインにするには、コマンド・ラインからパラレル・アップグレード・ユーティリティ(catctl.pl)を、-Tオプションを指定して実行します。dbupgradeスクリプトを使用してcatctl.plを実行できます。

たとえば、LinuxおよびUNIXプラットフォームでは次のようにします。

$ dbupgrade -T

アップグレードが完了した後にutluptabdata.sqlスクリプトを実行して、アップグレード中にREAD ONLY表領域に設定されていたそれらの表をアップグレードします。

アップグレード・ログ・ファイルの表領域コマンドの表示

致命的なアップグレードの失敗が発生した場合は、ログ・ファイルのコマンドを手動で実行して表領域を表示させることができます。表領域コマンドは次のログ・ファイルで表示できます。

非CDBのアップグレード: catupgrd0.log
PDBデータベース: catupdrdpdbname0.log (pdbnameはアップグレードするPDBの名前です)。

各ログ・ファイルの先頭で、次のようなSQL文が見つかります。これは、表をREAD ONLYに設定する文です。

SQL> ALTER TABLESPACE ARGROTBLSPA6 READ ONLY;

Tablespace altered.

SQL> ALTER TABLESPACE ARGROTBLSPB6 READ ONLY;

Tablespace altered.

各ログ・ファイルの末尾近くには、表をREAD WRITEに再設定するSQL文が見つかります。

SQL> ALTER TABLESPACE ARGROTBLSPA6 READ WRITE;

Tablespace altered.

SQL> ALTER TABLESPACE ARGROTBLSPB6 READ WRITE;

Tablespace altered.

参照:

データベース間での表領域の転送の詳細は、Oracle Database管理者ガイドを参照してください。

親トピック: Oracle Databaseのアップグレードを開始する前に完了するデータベースの準備作業