日本語PDF

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

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

Oracle Databaseをアップグレードする場合のリリースの更新および要件

アップグレードを開始する前に、新しいリリースのOracleホームを最新のリリース更新(Update)に更新します。

新しいOracle Databaseリリースのソフトウェアには、リリースの時点で最新のOracle Databaseのすべての更新を含む完全なリリースが含まれます。

アップグレードを開始する前に、新しいリリースのOracleホームを最新の四半期リリース更新(Update)に更新することをお薦めします。

My Oracle Supportで、最新更新の入手方法に加え、ライフサイクル管理に使用するツールについて詳細に説明したノートが提供されています。たとえば:
  • 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外部キーストアに登録してキー管理を行うことで、ターゲット・データベースを自動的に起動できます。

  1. AutoUpgradeを実行する前に、TDEを使用するデータベースで使用する構成ファイルにグローバル・パラメータglobal.keystoreを追加し、アップグレードされたデータベース用に作成するキーストアの場所へのセキュアなパスを指定します。このパスは、キーストアがログ・ファイルの場所に存在しないように、AutoUpgradeで指定した他のファイル・パスと異なっている必要があります。
  2. デプロイ・モードでAutoUpgradeを実行する場合は、-configコマンドライン・パラメータおよび-load_passwordパラメータを使用して実行する必要があります。
  3. 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_CONFIGURATIONFILEに設定した場合は、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_PASSWORDFILESHAREDに設定されている場合、アップグレード前チェックの検証で警告が出ます。次のいずれかのオプションを選択して、この問題を修正します。

  • 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 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

追加の操作を実行せずに新しいOracle Databaseリリースにアップグレードした場合、そのアカウントにはアクセスできなくなります。アップグレード前に、(SQLNET.ORAパラメータSQLNET.ALLOWED_LOGON_VERSION_SERVERをより許容度の高い認証モードに設定すして、)システムが排他モードで構成されていないことを確認してください。

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

次の手順を実行します。

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

          select USERNAME
             from DBA_USERS
            where ( PASSWORD_VERSIONS = '10G '
                   or PASSWORD_VERSIONS = '10G HTTP ')
              and USERNAME <> 'ANONYMOUS';
    
  2. SQLNET.ORAパラメータSQLNET.ALLOWED_LOGON_VERSION_SERVERの設定を、該当するアカウントに適切なレベルに編集することにより、システムが排他モードで実行されるようにシステムを構成します。たとえば:

    SQLNET.ALLOWED_LOGON_VERSION_SERVER=11

    この変更を行った後で、アップグレードに進みます。

  3. アップグレードが終了したら、次のコマンド構文を使用してステップ1で検出したアカウントを期限切れにします。usernameは、ステップ1の問合せで返されたユーザーの名前です。

    ALTER USER username PASSWORD EXPIRE;

  4. パスワードを期限切れにしたユーザーに、ログインするよう依頼します。

  5. これらのユーザーがログインするときに、パスワードをリセットするよう、プロンプトが表示されます。システムは10Gパスワード・バージョンに加えて、欠落している11Gおよび12Cパスワード・バージョンを内部的に生成します。システムは許容モードで実行中のため、10Gパスワード・バージョンは引き続き存在します。

  6. ユーザーが接続しているクライアント・ソフトウェアに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の項に記載されています。

  7. すべてのクライアントにO5L_NP機能が導入されたら、次のプロシージャを使用してセキュリティを元の排他モードに上げます。

    1. インスタンス初期化ファイルからSEC_CASE_SENSITIVE_LOGON設定を削除するか、SEC_CASE_SENSITIVE_LOGONインスタンス初期化パラメータをTRUEに設定します。たとえば:

      SEC_CASE_SENSITIVE_LOGON = TRUE

    2. SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータをサーバーのSQLNET.ORAファイルから削除するか、サーバーのSQLNET.ORAファイルのSQLNET.ALLOWED_LOGON_VERSION_SERVERの値を12に戻して、排他モードに設定し直します。たとえば:

      SQLNET.ALLOWED_LOGON_VERSION_SERVER = 12

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

           select USERNAME
             from DBA_USERS
            where PASSWORD_VERSIONS like '%10G%'
              and USERNAME <> 'ANONYMOUS';
  9. ステップ8の問合せから戻されたアカウントのリストを使用して、まだ10Gパスワード・バージョンを持っているすべてのアカウントを期限切れにします。次の構文を使用して、アカウントを期限切れにします。usernameは問合せで返されたリストにある名前です。

    ALTER USER username PASSWORD EXPIRE;

  10. 期限切れにしたアカウントのユーザーに、アカウントにログインするよう依頼します。

    ユーザーはログインするときに、パスワードを再設定するようプロンプトが表示されます。システムは、アカウントの11Gおよび12Cパスワード・バージョンだけを内部的に生成します。システムは排他モードで実行されているため、10Gパスワード・バージョンはもう生成されません。

  11. ステップ1の問合せを実行して、システムがセキュア・モードで実行されていることを確認します。どのユーザーも検出されないことを確認します。この問合せでどのユーザーも検出されない場合、この結果は、10Gパスワード・バージョンがシステムにもう残っていないことを意味します。

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

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

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_PROFILELOCALプロファイルとして作成され、CONTAINER=CURRENT句が使用されます。ただし、Oracleが提供するプロファイルのセキュリティを強化するために、SYSユーザーのみがこれらのファイルを変更する権限を持っています。

ORA_STIG_PROFILEに関連付けられているユーザーがいる場合、これらのユーザーの次のパラメータはアップグレード後に厳密になります。

  • PASSWORD_LIFE_TIME35に変更されます。
  • PASSWORD_REUSE_TIME175に変更されます。
  • PASSWORD_GRACE_TIME0に変更されます。

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 (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 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 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スキーマ監査表に移動するには:

  1. AUDIT_ADMINロールを割り当てられているユーザーとして、CDBルートにログインします。
    現在のリリースまたはOracle Databaseにアップグレードする前に、アップグレード・プロセス中にオペレーティング・システムの過剰ファイルが失われないようにするために、CDBルートからDBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILESプロシージャを実行する必要があります。
    たとえば:
    CONNECT c##aud_admin
    Enter password: password
    Connected.
    
  2. データベースがオープンで、書込み可能であることを確認します。

    データベースがオープンされており書込み可能かどうかを確認するには、V$DATABASEビューを問い合せます。

    SELECT NAME, OPEN_MODE FROM V$DATABASE;
    
    NAME            OPEN_MODE  
    --------------- ---------- 
    HRPDB           READ WRITE 
    

    show pdbsコマンドを実行して、現在のインスタンスに関連付けられているPDBについて情報を見つけることができます。

  3. DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILESプロシージャを実行します。
    EXEC DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILES;
    
  4. 個々のPDB監査レコードをロードする場合は、各PDBにログインしてDBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILESプロシージャを再実行します。

監査レコードは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プロセスを停止して削除し、マルチテナント・アーキテクチャ用に変換およびアップグレードした後で再構成する必要があります。必要なプロセスの概要は次のとおりです。

  1. ソースOracle DatabaseでOracle GoldenGateユーザーを削除します。
  2. Oracle GoldenGateプロセスがOracle GoldenGate証跡内のすべての現行DMLデータおよびDDLデータの処理を終了し、プロセスがエンド・オブ・ファイル(EOF)になるまで待機します。
  3. ソース・データベースですべてのOracle GoldenGateプロセスを停止します。
  4. ソース非CDB Oracle Databaseからターゲット・リリースのCDB上のターゲットOracle Databaseへの変換およびアップグレードを完了します。
  5. データベースを再起動します。
  6. また、データベースを以前のリリースから新しいメジャー・リリース・ファミリ(たとえば、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バックアップを取得する前に、必要なすべての表のステータスを変更します。

このガイドラインの理由は、次のとおりです。

AutoUpgradeの操作中に、SYSTEMSYSAUXおよび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バックアップを作成する必要があります。

部分オフライン・バックアップに、アップグレード中に変更されたすべての表領域のバックアップが含まれていることを確認するには、次の手順を実行します。

  1. SYSTEMSYSUXおよびUNDO以外のすべての表領域と、READ WRITEに存在する必要があることがわかっている表領域をREAD ONLYモードにします。
  2. ピボット・ユーザーに対して次の問合せを実行します。
    (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#
        )'

    次に実行するステップは、問合せの結果によって異なります。

    • 問合せで行が戻されない場合は、SYSTEMSYSAUXおよびUNDOと、特にREAD WRITEに存在することがわかっている表のバックアップで、部分オフライン・バックアップを完了するのに十分であることを意味します。
    • 問合せで表領域の行が戻される場合、部分オフライン・バックアップを完了するには、これらの追加の表領域をREAD WRITEモードにする必要があります。
  3. 必要なすべての表領域の識別およびREAD WRITEモードへの設定が完了したら、それらの表領域の部分オフライン・バックアップを取得します。また、SYSTEMSYSAUXおよびUNDO.redoログ、制御ファイル、および必要に応じてリストア/リカバリ手順に関連するその他のファイルもバックアップします。
  4. ANALYZEモードでAutoUpgradeを実行します。出力を確認し、READ WRITEに配置する必要があるREAD ONLYとしてレポートされた追加の表領域がAutoUpgradeによって識別されないことを確認します。
(オプション)この手順の結果をここで入力します。