Oracle Databaseのアップグレードを開始する前に完了するデータベースの準備作業
Oracle Databaseのアップグレードを開始する前に、これらのデータベースの準備作業を完了していることを確認してください。
- Oracle Databaseをアップグレードする場合のリリースの更新および要件
アップグレードを開始する前に、新しいリリースのOracleホームを最新のリリース更新(Update)に更新します。 - アップグレードおよび透過的データ暗号化
TDEを使用してデータベースをアップグレードするには、–load_password
コマンドライン・オプションを使用するか、外部パスワード・ストアを指定して、AutoUpgradeにTDEパスワードを指定します。 - Oracle Databaseのアップグレード時のOracle Net Servicesに関する推奨事項
リスナーが新しいリリースのOracleホームで実行されていることを確認する必要があります。 - ORAPWDを使用したパスワード・ファイルの作成または移行
REMOTE_LOGIN_PASSWORDFILEが設定されている場合に参照してください。 - パスワードの大/小文字の区別とアップグレードについて
デフォルトで、Oracle Database 12cリリース2 (12.2)以降のリリースでは、排他モード認証プロトコルが使用されます。排他モードは大/小文字を区別しないパスワードを基にした認証をサポートしません。 - 大/小文字を区別しないパスワード・バージョンを使用しているアカウントがあるかどうかの確認
次の手順を使用して、アップグレードするOracle Databaseに大/小文字を区別しないパスワード・パージョンを使用しているアカウントや構成パラメータがないか、確認します。 - STIGおよびCISプロファイルのリソースおよびパスワード・パラメータの更新
Oracle Database 21c以降、アップグレードでは、既存のSTIGプロファイルの更新、およびアップグレードの一環としてのCISプロファイルのインストールを含むOracle推奨プロファイルが構成されます。 - プロファイル・スクリプト(glogin.sqlおよびlogin.sql)の確認
すべてのアップグレード方法で、プロファイル・スクリプトを使用せずにアップグレードを実行することをお薦めします。 - 読取り専用表領域を使用したアップグレードの実行
アップグレード中にスキーマベースの表領域をオフラインに設定するには、-T
オプションを指定してパラレル・アップグレード・ユーティリティを使用します。 - Oracle Databaseの高可用性オプション
Standard Edition High Availability、Oracle Restart、Oracle Real Application Clusters (Oracle RAC)およびOracle RAC One Nodeを使用して、Oracle Databaseで使用可能な高可用性オプションを確認します。 - Oracle Database Standard Editionでの高可用性のオプション
Oracle Database 19c以降のリリースでOracle Database Standard Editionの高可用性を可能にするために、Standard Edition High Availabilityの使用方法について学習します。 - 統合監査証跡へのオペレーティング・システムの監査レコードの移動
スピルオーバー監査ファイルに書き込まれた監査レコードは、統合監査証跡データベース表に移動できます。 - 非CDBのアップグレードとOracle GoldenGate
Oracle GoldenGateがデプロイされている非CDB Oracle Databaseをアップグレードする場合は、Oracle GoldenGateを停止し、マルチテナント・アーキテクチャ用に変換およびアップグレードした後で再構成する必要があります。 - AutoUpgradeを使用する前の非常に大規模なデータベースのバックアップ
大規模なデータベースで部分オフライン・バックアップを使用する場合は、データベースをダウングレードする必要がある場合に停止時間を最小限に抑えるために、表領域をチェックし、リカバリに必要なすべての表領域がバックアップされていることを確認します。
親トピック: Oracle Databaseのアップグレードの準備
Oracle Databaseをアップグレードする場合のリリースの更新および要件
アップグレードを開始する前に、新しいリリースのOracleホームを最新のリリース更新(Update)に更新します。
新しいOracle Databaseリリースのソフトウェアには、リリースの時点で最新のOracle Databaseのすべての更新を含む完全なリリースが含まれます。
アップグレードを開始する前に、新しいリリースのOracleホームを最新の四半期リリース更新(Update)に更新することをお薦めします。
- My Oracle Supportノート555.1のOracle Database 19cの重要な推奨個別パッチには、Oracle Database 19cの特定の重要度のパッチのリストが含まれています。
- My Oracle Supportノート2118136.2には、環境に必要な更新、リビジョン、パッチ・セット更新(PSU)、SPU (CPU)、バンドル・パッチ、パッチ・セットおよびベース・リリースを選択する際に役立つダウンロード・アシスタントが含まれています。ここで開始することをお薦めします。
-
My Oracle Supportノート1227443.1には、Oracle DatabaseのPSU/BP/Update/Revisionに関する既知の問題のリストが含まれています。このノートでは、Oracle Database、Oracle Grid InfrastructureおよびOracle JavaVMコンポーネント(OJVM)のすべての既知の問題ノートに関する情報を提供します。
アップグレードおよび透過的データ暗号化
TDEを使用してデータベースをアップグレードするには、–load_password
コマンドライン・オプションを使用するか、外部パスワード・ストアを指定して、AutoUpgradeにTDEパスワードを指定します。
AutoUpgradeバージョン22.1以降では、アップグレード中にコマンドラインでTransparent Data Encryption (TDE)パスワードを指定して、ソース・キーストアにアクセスし、選択した場所のターゲット・システム上の新しい外部キーストアをAutoUpgradeで作成することも、TDEパスワードを含む既存のセキュアな外部パスワード・ストア(SEPS)にAutoUpgradeがアクセスするように指定することもできます。
パスワード初期化およびストレージを使用したコマンドラインでのTDEパスワードの指定
アップグレードするデータベースのTDEパスワードがある場合は、コマンドラインでこれらのパスワードをAutoUpgradeに指定できます。AutoUpgradeでは、AutoUpgradeによって生成および保守される外部キー・マネージャを作成します。この構成では、AutoUpgradeによって、TDE対応データベースの無人操作または自動操作がサポートされます。アップグレードが実行されると、AutoUpgradeは、キーストア・パスワードを要求せずに各ソース・データベース・キーストアをオープンし、ターゲット・データベースをTDE外部キーストアに登録してキー管理を行うことで、ターゲット・データベースを自動的に起動できます。
- AutoUpgradeを実行する前に、TDEを使用するデータベースで使用する構成ファイルにグローバル・パラメータ
global.keystore
を追加し、アップグレードされたデータベース用に作成するキーストアの場所へのセキュアなパスを指定します。このパスは、キーストアがログ・ファイルの場所に存在しないように、AutoUpgradeで指定した他のファイル・パスと異なっている必要があります。 - デプロイ・モードでAutoUpgradeを実行する場合は、
-config
コマンドライン・パラメータおよび-load_password
パラメータを使用して実行する必要があります。 - AutoUpgradeがデータベースのアップグレードを開始する前に、AutoUpgradeによって、TDEを使用する構成ファイルで指定された各データベースにTDEパスワードを指定するよう求められます。これらのパスワードは、ソース・リリースのTDEキーストアへのアクセス、および新しいターゲット外部キーストアへのTDEパスワードの書込みにのみ使用されます。パスワードは、アップグレード中にSQL*Plus実行計画に書き込まれません。AutoUpgradeでTDEパスワードが必要なくなった場合、これらのパスワードはメモリーから削除されます。パスワードのログ・レコードは保持されません。
- AutoUpgradeがデプロイを開始するときにTDEパスワードを指定します。これらは構成ファイルには含まれていません。
- AutoUpgradeでは、TDEキーストアを含む構成ファイルで指定された各ソース・データベースにTDEパスワードを指定するように求められます。
- AutoUpgradeでは、アップグレード中にAutoUpgradeによって書き込まれたファイルにパスワード・ロギングを実行しません。かわりに、AutoUpgradeは、デプロイ中に
load_password
コマンドライン・オプションが使用されたことを記録します。 - AutoUpgradeを実行すると、コマンドラインで入力されたTDEパスワードをセキュアなJava KeyStoreオブジェクトに配置します。
- Oracle DatabaseキーストアのTDEパスワードがアクセスに使用され、ターゲット・データベースがキー管理のためにTDE外部キーストアに登録されると、AutoUpgradeはパスワードを含むJava KeyStoreオブジェクトをクリアして、これらのパスワードがメモリーに存在しないようにします。
- AutoUpgradeでは、アップグレード中にAutoUpgradeによって生成されるzipファイルにキーストア・ファイルを含めません。
- アップグレードが非CDBまたは切断/接続PDBアップグレードの場合、AutoUpgradeで作成された、非CDBからPDBまたは切断/接続アップグレードを実行するデータベース用のXMLマニフェスト・ファイルには、TDE暗号化キーが含まれています。このファイルは、AutoUpgradeによって生成されたzipファイルでも除外されます。
AUTO LOGINキーストアを使用したTDEパスワードの指定
既存の外部キーストアを使用してTDEのパスワードをAutoUpgradeに指定する場合は、DBAの介入を必要とせずにデータベースを停止および再起動できるように、AUTO LOGIN
キーストアを1回かぎり設定する必要があります。
既存のものにOracle Wallet値が指定されていることを確認するには、次のコマンドを入力します。
SQL> show parameter WALLET_ROOT;
AutoUpgrade 22.1以降では、sqlnet.ora file
を新しいOracleリリースにコピーする必要がなくなりました。セキュアな外部パスワード・キーストアを使用する場合は、WALLET_ROOT
静的初期化パラメータおよびTDE_CONFIGURATION
動的初期化パラメータを使用することをお薦めします。
AutoUpgrade構成ファイルで、アップグレード中にキーストアの場所を変更するように指定できます。または、アップグレード後にこのタスクを手動で完了することもできます。いずれの場合も、アップグレードを開始する前に、キーストアから最新のバックアップが作成されていることを確認してください。
このタスクを手動で完了する場合は、アップグレード後、キーストアを構成しデータの暗号化を開始する前に、作成する予定のキーストアの場所とタイプを指定するために、WALLET_ROOT
パラメータとTDE_CONFIGURATION
パラメータを使用して1回かぎりの構成を実行する必要があります。
WALLET_ROOT
パラメータは、キーストア・ディレクトリの場所を指定します。WALLET_ROOT
を設定する前に、キーストアを格納するために使用できる既存のディレクトリがあることを確認してください。(通常、このディレクトリはwallet
と呼ばれます。)
TDE_CONFIGURATION
パラメータは、キーストアのタイプ(ソフトウェア・キーストア、ハードウェア・キーストアまたはOracle Key Vaultキーストア)を指定します。TDE_CONFIGURATION
パラメータを省略した場合、Oracle Databaseはsqlnet.ora
ファイル設定を使用します。TDE_CONFIGURATION
を使用してキーストアのタイプを設定した後で、キーストアを作成すると、Oracle Databaseはキーストア・タイプのWALLET_ROOT
の場所内にディレクトリを作成します。たとえば、透過的データ暗号化キーストアのためにTDE_CONFIGURATION
をFILE
に設定した場合は、Oracle Databaseによってウォレット・ディレクトリ内にtde
(小文字)というディレクトリが作成されます。キーストア・タイプ間で移行する場合は、最初にTDE_CONFIGURATION
パラメータに使用するキーストア・タイプを設定し、ADMINISTER KEY MANAGEMENT
文を使用して移行を実行する必要があります。たとえば、ハードウェア・セキュリティ・モジュール(HSM)キーストアからTDEキーストアに移行できます。
V$ENCRYPTION_WALLET
動的ビューのKEYSTORE_MODE
列は、統一モードまたは分離モードが構成されているかどうかを示します。
ノート:
以前のリリースでは、キーストア・ディレクトリの場所を定義するためにSQLNET.ENCRYPTION_WALLET_LOCATION
パラメータが使用されていました。このパラメータは現在非推奨になっています。かわりに、WALLET_ROOT
静的初期化パラメータおよびTDE_CONFIGURATION
動的初期化パラメータを使用することをお薦めします。AutoUpgradeユーティリティを使用して、アップグレード中にこの更新を自動的に実行できます。
Oracle Databaseのアップグレード時のOracle Net Servicesに関する推奨事項
リスナーが新しいリリースのOracleホームで実行されていることを確認する必要があります。
アップグレードするOracle Databaseでリスナーが構成されていない場合、アップグレードを開始する前に、Oracle Net Configuration Assistant (NETCA
)を実行して、listener.ora
ファイルを含むOracle Databaseの新しいリリースのリスニング・プロトコルのアドレスおよびサービス情報を構成する必要があります。現在のリスナーには、以前のOracle Databaseとの下位互換性があります。
Oracle Real Application Clusters Oracle DatabaseまたはOracle Database 12cより古いリリースをアップグレードする場合は、次の追加情報を確認してください。
DBUAを使用してOracle RACデータベースをアップグレードする場合、リスナーが古いOracleホームから新しいOracle Grid Infrastructureホームに自動的に移行されます。Oracle Grid Infrastructureホームでlsnrctl
コマンドを使用してリスナーを管理する必要があります。以前のリリースのOracleホームの場所からlsnrctl
コマンドを使用しないでください。
Oracle Databaseでは、新しい基礎となるネット・サービス・パラメータによってデータ圧縮が可能で、これにより、SQL TCP接続を介して転送されるセッション・データ・ユニットのサイズが縮小されます。
次のsqlnet.ora
ファイルの新しいパラメータで、圧縮、および優先圧縮方式を指定します。
-
SQLNET.COMPRESSION
-
SQLNET.COMPRESSION_LEVELS
-
SQLNET.COMPRESSION_THRESHOLD
これらのパラメータは、Oracle Database 12cで導入されたもので、以前のリリースではサポートされていません。
ORAPWDを使用したパスワード・ファイルの作成または移行
REMOTE_LOGIN_PASSWORDFILEが設定されている場合に参照してください。
REMOTE_LOGIN_PASSWORDFILE初期化パラメータがEXCLUSIVE
に設定されている場合、ORAPWD
を使用してパスワード・ファイルを作成または移行します。Oracle Database 12c以上のリリースでは、既存のデータベースからパスワード・ファイルを移行するために、ORAPWD
に新しいオプションが提供されています。
Oracle Database 12cリリース2 (12.2)以上では、REMOTE_LOGIN_PASSWORDFILEがSHARED
に設定されている場合、アップグレード前チェックの検証で警告が出ます。次のいずれかのオプションを選択して、この問題を修正します。
-
REMOTE_LOGIN_PASSWORDFILE = NONE
を設定して、パスワード・ファイル・ベースの認証を完全に無効にします -
REMOTE_LOGIN_PASSWORDFILE = EXCLUSIVE
を設定して、パスワード・ファイル・ベースの認証を制限します
参照:
パスワード・ファイルの作成および移行の詳細は、『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リリースへのアップグレード中に、大/小文字を区別する認証を一時的に無効にすることはできます。アップグレード後に、パスワード・バージョンを管理するための実装計画の一環として、大/小文字を区別するパスワード・ベースの認証を有効にするかどうかを決定できます。
アップグレード前に、デフォルトのパスワード・ベースの認証プロトコル構成に対するこの変更により影響を受けるかどうかを判定することをお薦めします。次のことを確認してください。
-
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 Database10G
で作成されましたが、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
追加の操作を実行せずに新しいOracle Databaseリリースにアップグレードした場合、そのアカウントにはアクセスできなくなります。アップグレード前に、(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.ALLOWED_LOGON_VERSION_SERVER
パラメータをサーバーのSQLNET.ORA
ファイルから削除するか、サーバーの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に設定しないでください。
STIGおよびCISプロファイルのリソースおよびパスワード・パラメータの更新
Oracle Database 21c以降、アップグレードでは、既存のSTIGプロファイルの更新、およびアップグレードの一環としてのCISプロファイルのインストールを含むOracle推奨プロファイルが構成されます。
プロファイルとは、ユーザーに適用される属性の集合です。それらの属性を共有する複数ユーザーの中の任意のユーザーに関する単一の参照になります。
Oracle Databaseのアップグレード中に、米国国防総省(DISA)セキュリティ技術導入ガイド(STIG)のベースラインで指定されている最新のシステム構成ベースラインに従って、Oracle提供プロファイルORA_STIG_PROFILE
ユーザー・プロファイルが更新されます。この更新により、ORA_STIG_PROFILE
ユーザー・プロファイルで以前に設定した可能性のあるパスワードおよびリソース制限が上書きされます。また、新しいプロファイルORA_CIS_PROFILE
が追加され、ソフトウェア・リリース時にOracleで使用可能な最新のCenter of Internet Security (CIS)ベースライン更新に準拠します。これら2つのプロファイルは、Oracle推奨プロファイルに指定されています。これらのプロファイルはSTIGおよびCISベースラインに基づいているため、標準のDEFAULT
プロファイルとは異なります。
プロファイルORA_STIG_PROFILE
およびORA_CIS_PROFILE
はLOCAL
プロファイルとして作成され、CONTAINER=CURRENT
句が使用されます。ただし、Oracleが提供するプロファイルのセキュリティを強化するために、SYS
ユーザーのみがこれらのファイルを変更する権限を持っています。
ORA_STIG_PROFILE
に関連付けられているユーザーがいる場合、これらのユーザーの次のパラメータはアップグレード後に厳密になります。
PASSWORD_LIFE_TIME
。35
に変更されます。PASSWORD_REUSE_TIME
。175
に変更されます。PASSWORD_GRACE_TIME
。0
に変更されます。
Oracle推奨プロファイルの使用の詳細は、Oracle Databaseセキュリティ・ガイドを参照してください。
プロファイル・スクリプト(glogin.sqlおよびlogin.sql)の確認
すべてのアップグレード方法で、プロファイル・スクリプトを使用せずにアップグレードを実行することをお薦めします。
プロファイル・スクリプト(glogin.sql
およびlogin.sql
)の内容によっては、これらのスクリプトがOracle Databaseのアップグレードを妨げるリスクがあり、「UPG-1400 アップグレードに失敗しました」
エラー、「catconで予期しないエラーが発生しました」
または「ORA-04023: オブジェクトSYS.STANDARDを検証または認可できませんでした」
が発生する可能性があります。アップグレードを開始する前に、ターゲットのOracleホームから(Oracleホームの/sqlplus/admin
にある)サイト・プロファイル・スクリプト(glogin.sql
)を削除することをお薦めします。また、現在のディレクトリまたは環境変数SQLPATH
を使用して指定されたディレクトリに、ユーザー・プロファイル・スクリプトが定義されていないことを確認します。
読取り専用の表領域を使用したアップグレードの実行
アップグレード中にスキーマベースの表領域をオフラインに設定するには、-T
オプションを指定してパラレル・アップグレード・ユーティリティを使用します。
Oracle Databaseでは以前のリリースで作成されたファイル・ヘッダーを読み取ることができるため、アップグレード時にそれらに対して処理を行う必要はありません。READ ONLY
表領域のファイル・ヘッダーは、それらがREAD WRITE
に変更されたときに更新されます。
アップグレードで致命的なエラーが発生し、その結果アップグレードで表領域をオンラインに戻すことができなくなった場合、アップグレード・ログ・ファイルを参照してください。ログ・ファイルには、表領域を使用可能にするために必要な実際のSQL文が含まれています。表領域をオンラインに戻すには、データベースにログ・ファイルのSQL文を実行するか、PDBごとにログ・ファイルを実行する必要があります。
アップグレード・ログ・ファイルの表領域コマンドの表示
致命的なアップグレードの失敗が発生した場合は、ログ・ディレクトリ(Oracle_base/cfgtoologs/dbua
)に移動し、ログ・ファイルのコマンドを手動で実行して表領域を表示させることができます。表領域コマンドは次のログ・ファイルで表示できます。
-
非CDBのアップグレード:
catupgrd0.log
-
PDBデータベース:
catupgrdpdbname0.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の高可用性オプション
Standard Edition High Availability、Oracle Restart、Oracle Real Application Clusters (Oracle RAC)およびOracle RAC One Nodeを使用して、Oracle Databaseで使用可能な高可用性オプションを確認します。
Oracle Databaseで使用可能な高可用性オプションの概要は次のとおりです。
Standard Edition High Availability
- クラスタベースのアクティブ/パッシブOracle Databaseフェイルオーバー・ソリューション
- シングル・インスタンスのStandard Edition Oracle Database用に設計されています
- Oracle Database 19cリリース更新(RU) 19.7以降で使用できます
- Oracle Grid Infrastructure 19c RU 19.7以降をスタンドアロン・クラスタとしてインストールする必要があります
Oracle Restart
- Oracle Databaseインスタンスの再起動のみの機能およびスタンドアロン・サーバー・デプロイメント用のOracle Automatic Storage Management (Oracle ASM)の基礎
- シングル・インスタンスのOracle Database用
- スタンドアロン・サーバー(クラスタなし)用のOracle Grid Infrastructureが必要です
Oracle Real Application Clusters (Oracle RAC) One Node
- クラスタベースのアクティブ/パッシブOracle Databaseフェイルオーバーおよびオンライン・データベース再配置ソリューションを提供します
- Oracle RAC対応のOracle Databaseで使用できます
- 通常の操作では、Oracle RAC対応のOracle Databaseの1つのインスタンスのみが実行されています
- オンライン方式で、クラスタ内の別のサーバーにアクティブなインスタンスを再配置できます。アクティブなインスタンスを再配置するために、宛先サーバー上の2番目のインスタンスを一時的に起動して、ワークロードを再配置できます
- ローリング・アップグレード(パッチ・セット、データベースおよびオペレーティング・システム)をサポートします
- アプリケーション・コンティニュイティをサポートします
- Oracle Grid Infrastructureをスタンドアロン・クラスタとしてインストールする必要があります
Oracle Real Application Clusters(Oracle RAC)
- アクティブ/アクティブOracle Database高可用性およびスケーラビリティのソリューションを提供します
- 複数のサーバーが同じOracle Databaseで同時トランザクションを実行できます
- 高可用性を実現します。他のインスタンスやサーバーが稼働したままであるため、データベース・インスタンスまたはサーバーの障害によってデータベース・サービス全体が中断されることはありません
- ローリング・アップグレード(パッチ・セット、データベースおよびオペレーティング・システム)をサポートします
- アプリケーション・コンティニュイティをサポートします
- Oracle Grid Infrastructureをスタンドアロン・クラスタとしてインストールする必要があります
- 監査表の事前アップグレードおよびアーカイブの要件
Oracle Label SecurityおよびOracle Database Vaultを使用している12.1より前のOracle Databaseリリースでは、アップグレードの前にOLS事前処理スクリプトを実行する必要があります。
監査表の事前アップグレードおよびアーカイブの要件
Oracle Label SecurityおよびOracle Database Vaultを使用している12.1より前のOracle Databaseリリースでは、アップグレードの前にOLS事前処理スクリプトを実行する必要があります。
Oracle Label Security (OLS)およびOracle Database Vaultを使用するOracle Databaseリリース12.1より前のデータベースをアップグレードする場合は、最初にOLS事前処理スクリプト(olspreupgrade.sql
)を実行してaud$
表のコンテンツを処理する必要があります。OLSアップグレードでは、aud$
表が、SYSTEM
スキーマからSYS
スキーマに移動されます。olspreupgrade.sql
スクリプトは、この移動に必要な事前処理スクリプトです。
注意:
Oracle Label SecurityおよびOracle Database Vaultを使用するOracle Databaseリリース12.1より前のデータベースをアップグレードする前には、olspreupgrade.sql
スクリプトを実行する必要があります。Oracle Databaseリリース12.1にアップグレード後に、データベースのパッチまたはアップグレードをするためのOLS事前処理の手順を実行する必要はありません。
olspreupgrade.sql
スクリプトでは、SYS
スキーマに一時表PREUPG_AUD$
が作成され、SYSTEM.aud$
レコードがSYS.PREUPG_AUD$
に移動されます。安全対策として、olspreupgrade.sql
スクリプトを実行する前に監査証跡をアーカイブすることをお薦めします。Oracle Label Securityがデータベースにインストールされていて、以前のリリースからアップグレードする場合は、アップグレードの前にOLS事前処理スクリプトを実行する必要があります。
参照:
監査証跡のアーカイブの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください
OLS事前処理スクリプトの詳細は、Oracle Label Security管理者ガイドを参照してください。
親トピック: Oracle Databaseの高可用性オプション
Oracle Database Standard Editionでの高可用性のオプション
Oracle Database 19c以降のリリースでOracle Database Standard Editionの高可用性を可能にするために、Standard Edition High Availabilityの使用方法について学習します。
- Standard Edition Oracle RACまたはOracle RAC One Nodeのアップグレードの準備
Standard Edition Oracle Real Application Clusters (Oracle RAC)からの移行後に高可用性を維持するために、Standard Edition High Availabilityを使用できます。 - Oracle DatabaseでStandard Edition High Availabilityを使用するための要件
Standard Edition High Availabilityを使用するには、次の構成要件に従ってOracle Database Standard Edition 2をデプロイします。
Standard Edition Oracle RACまたはOracle RAC One Nodeのアップグレードの準備
Standard Edition Oracle Real Application Clusters (Oracle RAC)からの移行後に高可用性を維持するために、Standard Edition High Availabilityを使用できます。
Oracle Database 19cのリリース以降、Oracle Database Standard Edition 2ではOracle RACはサポートされません。Oracle Database Standard Editionの高可用性のニーズを引き続き満たすために、Standard Edition High Availabilityが導入されています。
Oracle DatabaseでStandard Edition High Availabilityを使用するための要件
Standard Edition High Availabilityを使用するには、次の構成要件に従ってOracle Database Standard Edition 2をデプロイします。
- データベースは、スタンドアロン・クラスタ用のOracle Grid Infrastructureを実行するクラスタで作成され、そのデータベース・ファイルはOracle Automatic Storage Management (Oracle ASM)またはOracle Automatic Storage Management Cluster File System (Oracle ACFS)に配置されます。
- Database Configuration Assistantを使用する場合は、Standard Edition High Availability用に構成するOracle Database Standard Edition 2データベースの作成時にリスナーを作成しないでください。
- 単一クライアント・アクセス名(SCAN)リスナーに、データベースをリモート・リスナーとして、ノード・リスナーをローカル・リスナーとして登録します。
- データベース・サービスを作成します。アプリケーションまたはデータベース・クライアントをデータベースに接続する際は、デフォルトのデータベース・サービスではなくこのサービスを使用します。
- サーバー・パラメータ・ファイル(
spfile
)およびパスワード・ファイルがOracle ASMまたはOracle ACFSにあることを確認します。データベースの作成または構成時にspfile
およびパスワード・ファイルがローカル・ファイル・システムに配置された場合は、それらのファイルをOracle ASMまたはOracle ACFSに移動します。
満たす必要がある追加の要件は、データベースのインストールに関するドキュメントを参照してください。
統合監査証跡へのオペレーティング・システムの監査レコードの移動
スピルオーバー監査ファイルに書き込まれた監査レコードは、統合監査証跡データベース表に移動できます。
データベースが書込み可能でない場合(データベースのマウント中など)、データベースがクローズされている場合、または読取り専用の場合は、Oracle Databaseによって、監査レコードがこれらの外部ファイルに書き込まれます。これらの外部ファイルのデフォルトの場所は、$ORACLE_BASE/audit/$ORACLE_SID
ディレクトリです。
DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILES
プロシージャを実行して、データベースにファイルをロードできます。多くのオペレーティング・システム監査レコードを外部ファイルに移動している場合は、パフォーマンスが影響を受ける場合があるので注意してください。
データベースが書込み可能な場合に、これらのファイルの監査レコードをAUDSYS
スキーマ監査表に移動するには:
監査レコードはAUDSYS
スキーマ監査表に即座にロードされ、$ORACLE_BASE/audit/$ORACLE_SID
ディレクトリから削除されます。
非CDBのアップグレードとOracle GoldenGate
Oracle GoldenGateがデプロイされている非CDB Oracle Databaseをアップグレードする場合は、Oracle GoldenGateを停止し、マルチテナント・アーキテクチャ用に変換およびアップグレードした後で再構成する必要があります。
アップグレードする非CDB Oracle DatabaseでOracle GoldenGateを使用している場合、ソースの非CDB Oracle Databaseをマルチテナント・アーキテクチャに変換およびアップグレードする前に、Oracle GoldenGateプロセスを停止して削除し、マルチテナント・アーキテクチャ用に変換およびアップグレードした後で再構成する必要があります。必要なプロセスの概要は次のとおりです。
- ソースOracle DatabaseでOracle GoldenGateユーザーを削除します。
- Oracle GoldenGateプロセスがOracle GoldenGate証跡内のすべての現行DMLデータおよびDDLデータの処理を終了し、プロセスがエンド・オブ・ファイル(EOF)になるまで待機します。
- ソース・データベースですべてのOracle GoldenGateプロセスを停止します。
- ソース非CDB Oracle Databaseからターゲット・リリースのCDB上のターゲットOracle Databaseへの変換およびアップグレードを完了します。
- データベースを再起動します。
- また、データベースを以前のリリースから新しいメジャー・リリース・ファミリ(たとえば、Oracle Database 12.1からOracle Database 19c (Oracle Database 12.2ファミリのターミナル・パッチ・セット))にアップグレードする場合は、Oracle Database 19cでサポートされている新しいバージョンのOracle GoldenGateをインストールする必要があります。Oracle DatabaseとOracle GoldenGateの両方を同時にアップグレードする場合は、まずデータベースをアップグレードする必要があります。
データベースの変換およびアップグレードが完了した後に、Oracle GoldenGate Extractユーザー用の新しい資格証明を作成できます。新しい資格証明を使用して、ターゲットCDBのアップグレード済Oracle Database PDB用に新しいExtractプロセスとExtractポンプおよび配布サービスを作成し、新しく作成したプロセスを起動できます。アップグレード後にこれらの手順を完了する方法の詳細は、Oracle GoldenGateのドキュメントを参照してください。
AutoUpgradeを使用する前の大規模データベースのバックアップ
大規模なデータベースで部分オフライン・バックアップを使用する場合は、データベースをダウングレードする必要がある場合に停止時間を最小限に抑えるために、表領域をチェックし、リカバリに必要なすべての表領域がバックアップされていることを確認します。
バックアップ・オプションとして部分オフライン・バックアップを選択したデータベースのアップグレードにAutoUpgradeユーティリティを使用している場合は、アップグレードに必要なすべての表領域がREAD WRITE
モードであることを確認し、バックアップに必要なすべての表領域を特定した後にのみ、AutoUpgradeを実行する前に、リカバリに必要な表領域のOFFLINE
バックアップを取得する前に、必要なすべての表のステータスを変更します。
このガイドラインの理由は、次のとおりです。
SYSTEM
、SYSAUX
およびUNDO
以外の他の表領域をアップグレードのためにREAD WRITE
ステータスで保持する必要がある場合があります。アップグレード中にこの要件が発生する理由には、次のものがあります。
- ディクショナリ・オブジェクトを含む表領域
- Oracle管理ユーザーのデフォルト表領域である表領域
- データベースのデフォルト表領域である表領域
AutoUpgradeは、アップグレードに必要なすべての表領域がREAD WRITE
ステータスであるかどうかを検出します。
アップグレードのためにREAD WRITE
モードに変更する必要がある表領域がある場合は、次のようにします。
PRECHECKS
処理モードでは、AutoUpgradeはREAD ONLY
ステータスの表を問題として検出します。FIXUP
処理モードでは、AutoUpgradeは自動修正を実行して、READ WRITE
モードである必要があるREAD ONLY
モードで検出された表領域をREAD WRITE
モードに更新します。
AutoUpgradeがREAD ONLY
モードからREAD WRITE
モードに変更するアップグレードに必要な表領域があり、これらの表領域がAutoUpgradeの起動前にバックアップに含まれていなかった場合、リカバリ計画にリスクがあります。バックアップがリカバリに有効であることを確認するには、バックアップが必要な表領域を確認した後にのみ、OFFLINE
バックアップを作成する必要があります。
部分オフライン・バックアップに、アップグレード中に変更されたすべての表領域のバックアップが含まれていることを確認するには、次の手順を実行します。
SYSTEM
、SYSUX
およびUNDO
以外のすべての表領域と、READ WRITE
に存在する必要があることがわかっている表領域をREAD ONLY
モードにします。- ピボット・ユーザーに対して次の問合せを実行します。
(SELECT username FROM dba_users WHERE user_id in ( SELECT schema# FROM sys.registry$ WHERE namespace = 'SERVER' UNION SELECT schema# FROM sys.registry$schemas WHERE namespace = 'SERVER' UNION SELECT user# FROM sys.user$ WHERE type#=1 AND bitand(spare1,256)=256)) SELECT tablespace_name FROM dba_tablespaces WHERE status <>'ONLINE' and tablespace_name IN ( SELECT property_value FROM database_properties WHERE property_name = 'DEFAULT_PERMANENT_TABLESPACE' UNION SELECT default_tablespace FROM dba_users WHERE username IN (SELECT username FROM pivot_users) UNION SELECT tablespace_name FROM dba_segments WHERE owner IN (SELECT username FROM pivot_users) UNION SELECT t.name FROM modeltab$ m, ts$ t, sys_objects s WHERE m.obj#=s.object_id and s.ts_number=t.ts# )'
次に実行するステップは、問合せの結果によって異なります。
- 問合せで行が戻されない場合は、
SYSTEM
、SYSAUX
およびUNDO
と、特にREAD WRITE
に存在することがわかっている表のバックアップで、部分オフライン・バックアップを完了するのに十分であることを意味します。 - 問合せで表領域の行が戻される場合、部分オフライン・バックアップを完了するには、これらの追加の表領域を
READ WRITE
モードにする必要があります。
- 問合せで行が戻されない場合は、
- 必要なすべての表領域の識別および
READ WRITE
モードへの設定が完了したら、それらの表領域の部分オフライン・バックアップを取得します。また、SYSTEM
、SYSAUX
およびUNDO
.redoログ、制御ファイル、および必要に応じてリストア/リカバリ手順に関連するその他のファイルもバックアップします。 ANALYZE
モードでAutoUpgradeを実行します。出力を確認し、READ WRITE
に配置する必要があるREAD ONLY
としてレポートされた追加の表領域がAutoUpgradeによって識別されないことを確認します。