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ノート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をアップグレードする前に、すべてのマテリアライズド・ビューがリフレッシュを完了するまで待機する必要があります。
-
次の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をアップグレードするときには、バックアップ・モードのファイルがあってはなりません。次のv$backup
プロシージャを実行して、バックアップのステータスを確認します。
SQL> SELECT * FROM v$backup WHERE status != 'NOT ACTIVE';
このSQL文でファイルがまだバックアップ中であることが示された場合は、バックアップが完了するのを待つか、または不要なバックアップを強制終了してからアップグレードを試行してください。
参照:
データのバックアップおよびアーカイブの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
アップグレード前にメディア・リカバリを必要とするファイルがないことの確認
この手順を使用して、メディア・リカバリを必要とするファイルのリストを取得します。
Oracle Databaseをアップグレードする前に、メディア・リカバリを必要とするファイルがないことを確認する必要があります。システムに問い合せてファイルのリストを取得し、必要に応じてこれらのファイルのリカバリを行うことができます。
-
次の文を実行します。
SQL> SELECT * FROM v$recover_file;
参照:
ブロック・メディア・リカバリの実行方法の詳細は、『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をアップグレードする前に、プライマリ・データベースと同期化する必要があるかどうか確認します。
-
次の問合せを実行します。
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バックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください
アップグレード前のデータベースのごみ箱の消去
アップグレード前に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 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)データベース:
-
すべてのクラスタ・メンバー・ノードでリモート・コピーを有効にする必要があります。どのリモート・コピーを構成するかを指定するには、環境変数を定義します。次に例を示します。
setenv EM_REMCP /usr/bin/scp
-
次の構文を使用して、
emdwgrd
を実行します。emdwgrd -save -cluster -sid old_SID -path save_directory
-
-
-
アップグレードするデータベースの
SYS
パスワードを入力します。
注意:
データベースをアップグレードした後に、DBUAバックアップおよびリストア処理を使用して、以前のOracle Enterprise Manager Database Control環境に戻すことも可能です。ただし、アップグレードしてからリストアするまでの間に蓄積されたユーザー・データは、すべて失われます。データベースの制御ファイルおよびデータを保存しておくことで、データベースとDB Controlの両方をダウングレードできます。アップグレードしてからダウングレードするまでの間に蓄積されたDB Controlのデータはすべて失われますが、すべてのユーザー・データが保持されます。
emremove.sqlを使用したDB Controlの手動による削除
このSQLプロシージャを使用して、アップグレード処理中の停止時間を最小化します。
アップグレード前の準備の一環としてemremove.sql
スクリプトを実行できます。
emremove.sql
スクリプトは、Oracle Enterprise Manager関連のスキーマおよびオブジェクトを削除します。このスクリプトは、6つのステージで処理を実行するため、完了までに数分かかることがあります。このスクリプトは、SYSMANがあり、関連するセッションがSQL*Plus、Oracle Enterprise Managerまたはその他のクライアントからアクティブの場合に、完了するまでさらに時間がかかる場合があります。
注意:
ダウングレード後にDB Controlをリストアするには、前もってDB Control構成およびデータをバックアップしておく必要があります。この手順を開始する前にバックアップを完了してください。
JSON対応コンテキスト検索索引の削除
Oracle Database 12cリリース1 (12.1)から12cリリース2 (12.2)にアップグレードする場合は、アップグレードする前にJSON対応コンテキスト索引を削除することをお薦めします。
透過的暗号化Oracleウォレットのコピー
透過的暗号化(TDE)でOracleウォレットを使用しており、Database Upgrade Assistant (DBUA)を使用してデータベースをアップグレードする場合は、sqlnet.ora
およびウォレット・ファイルを新しいOracleホームにコピーします。
アップグレードを開始する前に、sqlnet.ora
およびウォレット・ファイルをコピーする必要があります。
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 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 Database12C
にリセットされました。その結果、このパスワードのリセットによって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
機能が導入されたら、次のプロシージャを使用してセキュリティを元の排他モードに上げます。-
インスタンス初期化ファイルからSEC_CASE_SENSITIVE_LOGON設定を削除するか、SEC_CASE_SENSITIVE_LOGONインスタンス初期化パラメータをTRUEに設定します。次に例を示します。
SEC_CASE_SENSITIVE_LOGON = TRUE
-
サーバーの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管理者ガイドを参照してください。