トップ > Amazon RDS > RDS for Oracle を 11.2.0.4 から 19c へアップグレードするためのベストプラクティス

RDS for Oracle を 11.2.0.4 から 19c へアップグレードするためのベストプラクティス

Amazon RDS Oracle
記事タイトルとURLをコピーする

SRE部 佐竹です。
期限が差し迫った RDS for Oracle 11g の EOS (End of support) に関連して記載します。

はじめに

本ブログは、以下のブログに関連した記事となります。

blog.serverworks.co.jp

以下のタイムラインの通り、RDS for Oracle 11g の LI(License Included) は2020年10月末で期限を迎えます。BYOLは12月末となっているためもう少し余裕がありますが、LI モデルをご利用のお客様には期限がもう目の前という状況です。

f:id:swx-satake:20200913213447p:plain

本状況ですので、AWS公式のデータベースブログにおいて、以下の記事が2020年7月22日に投稿されています。

aws.amazon.com

残念ながら、待てど暮らせど本ブログの日本語版が出ませんため、このブログ記事にて上記ブログを翻訳してご紹介します。翻訳の誤りが含まれる可能性がございますので、確実な情報は原文をご覧ください。

なお、「※補足」と記載している箇所は全て私による補足部分であり、原文には存在しません。

RDS for Oracle を 11.2.0.4 から 19c へアップグレードするためのベストプラクティス

  • ※補足
    導入ではバージョンアップの差について記載されています。つまりメジャーバージョンアップと、マイナーバージョンアップの差についてです。ここについては既に多くの方がご理解されていると思われますが、バージョン 11g から 19c へのアップグレードは、メジャーバージョンアップになります。なお、先にご紹介しましたブログでも記載していますが、18c, 19c は 12.2 系のファミリーです。このナンバリングは、18c と 19c がリリースされた西暦の後ろ2つを取ったものとなっているためです。つまり、Oracle Database 12.2 の2018年に出たパッチセットが18cであり、2019年に出たパッチセットが19cです。この部分の翻訳は省略しました。

この記事では、Amazon RDS for Oracleの11.2.0.4サポート終了タイムラインを確認し、利用可能なバージョンアップグレードの選択肢を調査し、アップグレードプロセス中に実行するベストプラクティスについて詳しく説明します。

本記事は、Amazon RDS for OracleでDBインスタンスを実行・保守するデータベース管理者（DBA）に関連する記事です。本記事における「アップグレード前」と「アップグレード後」の多くのステップは、Oracleサポートからの一般的なガイドラインとAmazon RDS for Oracleに関連するアップグレードドキュメントになります。バージョン 11.2.0.4 のアップグレードによって影響を受ける可能性がある Amazon RDS for Oracle の様々なワークロードを考慮して記載されています。ただし、記載されているすべてのガイドラインがすべてのお客様に当てはまるわけではありません。使用するオプションとパラメーターに基づいて、利用されているRDS for Oracleに適したものはどれなのか、判断されることを強くお勧めします。アップグレードを実行するには、Oracleデータベースの管理と利用環境に関する事前の知識が必要になります。

Amazon RDS for Oracle: 11.2.0.4 version End of Support timeline

オラクルは、2020年12月31日にOracleデータベースバージョン11.2.0.4のサポートを終了すると発表しました。その日以降、Oracleサポートはこのデータベースバージョン(11.2.0.4)の重要なパッチアップデートをリリースしません。 Amazon RDS for Oracleは、2020年10月31日にライセンス込み（LI）モデルのOracleデータベースバージョン11.2.0.4 Standard Edition 1（SE1）のサポートを終了します。Bring Your Own License（BYOL）モデルの場合、Amazon RDS for Oracleは、2020年12月31日にすべてのエディションのOracleデータベースバージョン11.2.0.4のサポートを終了します。

すべての11.2.0.4 SE1 LI RDS DBインスタンスは、2020年11月1日から自動的に19cにアップグレードされます。同様に、11.2.0.4 BYOL RDS DBインスタンスは、2021年1月1日から自動的に19cにアップグレードされます。自動アップグレードが開始される前に、既存のAmazon RDS for Oracle 11.2.0.4 DBインスタンスをアップグレードし、アプリケーションの動作検証を前もって実行することを強く推奨します。

次の表は、LI SE1を使用したOracle 11.2.0.4のタイムラインをまとめたものです。

Dates Activity
2020年10月31日まで 11.2.0.4 DB instances の特定のバージョンへの手動アップグレードが可能
2020年9月1日から 同 Snapshot の特定のバージョンへの手動アップグレードが可能
2020年9月1日から RDS for Oracle 11.2.0.4 ライセンス込みモデルの新規構築が終了
2020年11月1日から 11.2.0.4 DB instances の 19c への自動バージョンアップを開始
2020年11月1日から 同 Snapshot からのリストア時に 19c への自動バージョンアップを開始

次の表は、SE、SE1、およびEEとBYOLを併用したOracle 11.2.0.4のタイムラインをまとめたものです。

Dates Activity
2020年12月31日まで 11.2.0.4 DB instances の特定のバージョンへの手動アップグレードが可能
2020年11月1日から 同 Snapshot の特定のバージョンへの手動アップグレードが可能
2020年11月1日から RDS for Oracle 11.2.0.4 BYOLモデルの新規構築が終了
2021年1月1日から 11.2.0.4 DB instances の 19c への自動バージョンアップを開始
2021年1月1日から 同 Snapshot からのリストア時に 19c への自動バージョンアップを開始

Amazon RDS for Oracleによる11.2.0.4バージョンのEOSの詳細については、「Announcement: Amazon RDS for Oracle – End of Support Timeline for 12.2.0.1 and 11.2.0.4 Major Versions.」を参照してください。

Version upgrade choices in Amazon RDS for Oracle

Amazon RDS for Oracleは、次のメジャーバージョンアップグレードパスをサポートしています（ドキュメント執筆時点）。

Current Version Supported Upgrade Path
18.0.0.0 19.0.0.0
12.2.0.1 19.0.0.0, 18.0.0.0
12.1.0.2 19.0.0.0, 18.0.0.0, 12.2.0.1
11.2.0.4 19.0.0.0, 18.0.0.0, 12.2.0.1, 12.1.0.2.v5 and higher 12.1 versions

アップグレードするバージョンを決定するための一助として、次の選択肢があります。

  • 12.1.0.2 – Oracle Database 12.1.0.2（ターミナルパッチセット）の Extended Support は2022年7月31日に終了します。Amazon RDS for Oracleは、2022年7月31日までOracle Database 12.1.0.2をサポートする予定です。
  • 12.2.0.1 – Oracle Database 12.2.0.1の Limited Error Correction サポートは2022年3月31日に終了します。Amazon RDS for Oracleは、2022年3月31日までOracle Database 12.2.0.1をサポートする予定です。
  • 18c – Oracle Database 18cのサポートは2021年6月8日に終了します。Amazon RDS for Oracleは2021年6月8日までOracle Database 18cをサポートする予定です（Oracle Database 18cの Extended Support は提供されていません）。

  • 19c – Oracle Database 19cの Premier Support は2024年4月30日に終了し、Extended Support は2027年4月30日に終了します。Amazon RDS for Oracleは、2027年4月30日までOracle Database 19cをサポートする予定です。

  • ※補足
    文章だとわかりにくいと思いますので、合わせて以下の表を参考にしてください。18c のみ月末に終了ではなく、2021年6月8日と月の途中になる点に注意してください f:id:swx-satake:20200804200041p:plain

11.2.0.4 DBインスタンスは 19c にアップグレードすることを推奨します。これは長期のサポートを提供するためです。

ソフトウェアをアップグレードする時は、新しいバージョンとその機能の互換性を事前に確認することが、アップグレード全体の成功に重要な役割を果たします。 Oracle Databaseのバージョンとリリースでは、それらがどのように動作し、アプリケーションと相互作用するかに違いがあるため、互換性の問題が発生する可能性があります。 Amazon RDS for Oracleの操作方法は、メジャーバージョンのアップグレードの観点からは同じですが、メジャーバージョン間でのOracleデータベース固有の機能は変更されたり、廃止されたりする場合があります。メジャーバージョンのアップグレードの詳細については、Oracleデータベースエンジンのリリースノートを参照してください。

次の点に注意してください。

  • メジャーバージョンアップ後のダウングレードはサポートされていません。
  • 11gから12cへのメジャーバージョンアップグレードは、同月以降にリリースされたOracle Patch Set Update（PSU）にアップグレードする必要があります。

例えば、Oracleバージョン11.2.0.4.v14 から Oracleバージョン12.1.0.2.v11 へのメジャーバージョンアップグレードはサポートされています。ただし、Oracleバージョン11.2.0.4.v14 から Oracleバージョン12.1.0.2.v9 へのメジャーバージョンアップグレードはサポートされていません。これは、Oracleバージョン11.2.0.4.v14 が2017年10月にリリースされ、Oracleバージョン12.1.0.2.v9 が2017年7月にリリースされたためです。各Oracle PSUのリリース日については、Oracleデータベースエンジンのリリースノートを参照してください。

Downtime considerations for a major version upgrade

Amazon RDSでは、AWSマネジメントコンソール、AWSコマンドラインインターフェイス（AWS CLI）、またはAmazon RDS APIを介してDBインスタンスを変更（Modify）することにより、メジャーバージョンアップグレードを手動で開始できます。これはインプレースアップグレードであり、アップグレードプロセス中にアプリケーションのダウンタイムが必要です。アップグレードフェーズで問題が発生した場合は、最新のバックアップを利用することで復元可能です。停止の期間は、エンジンのバージョンとDBインスタンスクラスによって異なります。Productionデータベースのスナップショットリストアを使用してPre-Production環境を作成し、アップグレードを前もってテスト実行することで正確なダウンタイムを予め測定可能です。

DBインスタンスのModify機能を使用してメジャーバージョンのアップグレードを実行することがアプリケーションにとって望ましくない場合（※補足：例えばこれはダウンタイムが長期に及ぶことが許容できないような場合です）、他のアプローチとして、AWS Database Migration Service（AWS DMS）または Oracle GoldenGate のいずれかで論理的な双方向レプリケーションを使用することが考えられます。この方法では、アップグレードのダウンタイムを最小限に抑えることができます。この方法では、ソースとターゲットのDBインスタンス（両方が同じバージョンで実行されている必要があります）間の論理レプリケーションを設定します。次に、ソースを11.2.0.4で実行したまま、ターゲットDBインスタンスを19cにアップグレードします。ターゲットDBインスタンスのアップグレードが完了したら、アップグレードしたターゲットDBインスタンスをアプリケーションにポイントできます。ソースとターゲットのDBインスタンス間で双方向レプリケーションを使用するこの方法は、互換性がないためにアップグレードが中断した場合のフォールバック計画としても使用できます。

  • ※補足
    最後の文章にある「incompatibility」＝「非互換性」という言葉を日本語にするのが難しいと感じたのですが、これは何らかの要因によってアップグレードが途中で失敗したり、アプリケーションの動作が正常動作しなかったりしたような場合に、切り戻しを行うというシーンのについて記載されていると推測します。

この記事では、DBインスタンスの変更方法を使用したアップグレードプロセスについて説明します。アップグレードの論理的な複製方法は、この記事の範囲外です。

How Amazon RDS for Oracle performs a major version upgrade

メジャーバージョンアップグレードの実行がコンソール、AWS CLI、またはAmazon RDS APIで呼び出されると、自動的に次の手順が実行され完了します。

  1. アップグレード前のスナップショットを作成します（※補足：オプションで自動バックアップ機能が有効にされている場合）。このスナップショットを使用して、必要に応じてロールバックが可能です。
  2. インスタンスをシャットダウンし、アップグレードの準備をします。
  3. Oracleアップグレードスクリプトを実行します。
  4. アップグレード後のスナップショットを取得します。

Amazon RDSがステップ1を開始すると、インスタンスのステータスが Available から Upgrading に変わります。ステップ4の後、Available に戻ります。次の図は、modify-db-instance AWS CLI呼び出しが呼び出されたときの大まかな進行順を示しています。

f:id:swx-satake:20200912184352p:plain

Best practices for major version upgrades

このセクションでは、アップグレードプロセスのさまざまなフェーズ（アップグレード前、アップグレード、アップグレード後）における推奨されるベストプラクティスについて詳しく説明します。

次のセクションで説明するのは、ほとんどのOracleデータベースのアップグレードで通常完了する一般的な手順です。完全なリストについては、 『Oracle Database Upgrade Guide』を参照してください。

Pre-upgrade phase

Oracleは、上位リリースへのアップグレード（またはAmazon RDS用語ではメジャーバージョンのアップグレード）時に次の用語を使用します。

  • 非推奨機能 – 機能は拡張されていませんが、このリリースのOracleデータベースの存続期間中は引き続きサポートされます。
  • サポートされなくなった機能 – その機能に関連するバグを修正することでサポートされなくなった機能。 Oracleは、機能の使用に必要なコードを削除することを選択できます。

明記がされている場合、非推奨の機能は、将来のメジャーリリースでサポートが中止される可能性があります。アップグレードプロセス中に複数のメジャーリリース間を移動する場合は、中間リリースの非推奨およびサポートが終了した機能、オプション、およびパラメータについても、Oracleのドキュメントを参照することを強くお勧めします。詳細については、「Behavior Changes, Deprecated and Desupported Features for Oracle Database」を参照してください。

アップグレード前のフェーズでは、次の要素を考慮する必要があります。

Downtime considerations

オプショングループのすべての可能なオプションを使用した一般的なアップグレードには、1〜2時間かかる場合があります。ダウンタイムを削減するには、次のことを考慮してください。

  • アップグレードフェーズを開始する前に、create-db-snapshot AWS CLIを使用して手動スナップショットを作成します。これにより、アップグレード前のスナップショット（アップグレードフェーズ中に自動的に呼び出される）にかかる時間が短縮されます。（※補足：これはSnapshotが差分バックアップのためです。差分が少ないほどSnapshotの取得にかかる時間は短縮されます）
  • 19cにアップグレードする場合は、アップグレードの前にすべての DBMS_JOB を DBMS_SCHEDULER に変換することを推奨します。アップグレード中に、Oracleは DBMS_JOB を DBMS_SCHEDULER に変換しようとします。多数の DBMS_JOB エントリがある場合、アップグレードに時間がかかります。
  • 監査証跡があまり大きくないことを確認してください。大きな監査証跡を使用すると、アップグレード前のチェックとアップグレードに時間がかかる場合があります。
  • DBMS_STATS.gather_dictionary_stats を使用して、アップグレード前にオプティマイザ統計を収集します。また、固定および辞書の統計を収集します。（※補足：この表記についての詳細は「Oracle Databaseをアップグレードする場合のオプティマイザ統計の収集」を確認してください）
  • 使用されていないオプションを削除します。未使用のオプションを削除してアップグレードを高速化し、1つのメジャーバージョンから別のメジャーバージョンに移行する際の問題や競合を減らすことを推奨します。（※補足：オプショングループの設定です）
  • 上記と同じ理由で使用されていないパラメーターを削除またはリセットします。（※補足：パラメータグループの設定です）
  • 必要に応じて、ターゲットインスタンスの選択に基づいてインスタンスクラスをアップグレードする必要がある場合もあります。詳細については、「DB Instance Class Support for Oracle」を参照してください。（※補足：DB.Instance Class が低スペックすぎる場合に、バージョンアップに失敗するもしくはダウンタイムが長期に及んでしまう可能性が示唆されています。またダウンタイムの短縮のためにも、バージョンアップ前には必要があればスケールアップを実行されると良いでしょう）
Multi-AZ considerations

DBインスタンスがマルチAZオプションを利用している場合、Amazon RDS for OracleはプライマリとマルチAZスタンバイインスタンスの両方を同時にアップグレードします。

※補足：この記述は「先にマルチAZスタンバイインスタンスをアップグレードしてから、プライマリをアップグレードするように、アップグレード時間が短縮可能か？」という問いに対して、そうではないということを示しています。

Option groups considerations

オプショングループについては、以下を考慮してください。

  • デフォルトでは、1つのエンジンが次に高いメジャーバージョンにアップグレードされるときに、ターゲットバージョンに対応する新しいカスタムオプショングループが選択されていない場合、Amazon RDS for Oracleはデフォルトのオプショングループを選択します。たとえば、11.2.0.4から19cにアップグレードする場合、新しいバージョン19cと互換性があり、11.2.0.4オプションに最も近いオプショングループを作成し、アップグレードプロセス中に使用する必要があります。アップグレードを高速化するために、APEXアップグレードなどの要素も考慮する必要があります。これは、別個の準備プロセスとして処理することを推奨します。これはOEMエージェントにも当てはまります。あるバージョンから別のバージョンに移動すると、オプションがアンインストールされて再インストールされる場合があります。たとえば、SQLTが新しくインストールされ、オプションによって保存された古いメタデータが削除されます。（※補足：SQLT のアップグレードの注意点は、公式ドキュメントの SQLT をアップグレードするには、SQLT の旧バージョンをアンインストールしてから、新しいバージョンをインストールする必要があります。そのため、すべての SQLT メタデータが SQLT をアップグレードすると失われる可能性があります。データベースのメジャーバージョンのアップグレードでも、SQLT がアンインストールされ、再インストールされます。 を参考ください）
  • OEMエージェントのバージョンを選択するときは、OMSとの互換性を考慮してください。
  • オプショングループとVPCに注意してください。 DBインスタンスがVPCにある場合、インスタンスに関連付けられているオプショングループはそのVPCにリンクされます。つまり、インスタンスを別のVPCまたは別のプラットフォームに復元しようとすると（たとえば、OEMオプションを使用する場合）、DBインスタンスに割り当てられたオプショングループを使用できません。
  • メジャーバージョンをアップグレードする時は、Oracleがその変更のオプションに加える変更を理解してください。たとえば、Oracleは19cでマルチメディアオプションをサポートしていません（※補足：Oracle Multimediaの非推奨）。ただし、MDSYS機能をLocatorと呼ばれる別のオプションに分離しました。また、アップグレードの前に、LocatorからSpatial and Graphに移行することを推奨します。 MDSYSのすべての機能は、SpatialおよびGraphで使用できます。したがって、19cにアップグレードしてSpatialとGraphをインストールすると、すべてのストアドプロシージャが正常に動作します。詳細については、「My Oracle support」の記事2347372.1を参照してください。
  • PL / SQLパッケージ DBMS_XMLQUERY は、Oracle Database 18cでは非推奨です。代わりに、DBMS_XMLGEN を使用することを推奨します。
Parameter groups considerations

新しいパラメーターグループをDBインスタンスに関連付ける場合は、アップグレードの完了後にデータベースを再起動します。パラメータグループの変更を適用するためにインスタンスを再起動する必要がある場合、インスタンスのパラメータグループのステータスは pending-reboot を示します。インスタンスのパラメータグループのステータスは、コンソールで、または describe-db-instances などの describe コマンドを使用して表示できます。

LogMiner パッケージ DBMS_LOGMNR.START_LOGMNR の Continuous_mine 機能は廃止されました。 Oracle Database 12cリリース2（12.2）では非推奨です。代替機能はありません。オラクルはこれに代わるものを提供しませんでした。これを使用する場合は、AWS DMS やO racle GoldenGate などの別の方法でアドレス指定する必要があります。

※補足：REDOログ・ファイル分析のためのLogMinerの使用

Security considerations

以下は、セキュリティに関する重要な考慮事項です。

  • デフォルトでは、アップグレード前にパスワードがリセットされていない（ EXPIRED ステータスに設定されている）Oracleアカウントは、 LOCKED ステータスにも設定されており、アップグレードの完了後に NO AUTHENTICATION に設定されます。したがって、アップグレード後に、パスワードがデフォルトに設定され、ロックされ、期限切れになったアカウントは、認証方法を失います。元に戻すこともできますが、アップグレード前にパスワードの強度を検証してロックすることをお勧めします。（※補足：スキーマ専用アカウントおよびEXPIREDパスワード・アカウントのアップグレード を合わせて確認ください）
  • 大文字と小文字を区別しないパスワードバージョンを使用するアカウントを確認します。 SQL * Plus に管理ユーザーとしてログインし、次のSQLクエリを入力します。 10gバージョンがある場合は、Oracleのドキュメントを参照して、10gバージョンを修正するか、アップグレードの完了後に LOCKED のユーザーアカウントを修正する必要があります。（※補足：パスワードの大/小文字の区別とアップグレードについて を合わせて確認ください）
SELECT USERNAME, PASSWORD_VERSIONS FROM DBA_USERS;
  • 廃止されたパラメータ SEC_CASE_SENSITIVE_LOGON が FALSE に設定されていないことを確認してください。（※補足：大/小文字を区別しないパスワード・バージョンを使用しているアカウントがあるかどうかの確認 を合わせて確認ください）
  • Oracle 12c 以降、OracleはOracle Real Application Security（ORAS）を使用してOracleセキュリティポリシーを格納します。 11gデータベースをOracle Database 19c にアップグレードする前に、11gで定義されているデータセキュリティロールを削除する必要があります。アップグレード後、データセキュリティロールを再度定義する必要がある場合があります。このアクションを実行せずにアップグレードした場合、データセキュリティロールを含むデータセキュリティポリシーは、新しい19cデータベースでは無効 (Invalid) になります。（※補足： Oracle Databaseのアップグレードの準備 の リリース11gのOracle Databaseインスタンスで定義されたデータ・セキュリティ・ロールは、自動的にORASに変換されません。11gデータベースをOracle Database 12cにアップグレードする前に、11gデータベースで定義されたすべてのデータ・セキュリティ・ロールを削除する必要があります。 を参照ください）
General considerations

最後に、次の一般的なポイントを考慮する必要があります。

  • 19cにアップグレードするときは、プロビジョニングされた容量を確認し、それが満たされるかどうかを確認することを推奨します。 11gデータベースが実行されているインスタンスクラスによっては、新しい世代のインスタンスクラスにコンピューティングをスケーリングする必要がある場合があります。詳細については、「Amazon RDS での Oracle - Amazon Relational Database Service」を参照してください。これは、Amazon RDSリザーブドインスタンスを評価する機会にもなる可能性があり、アップグレードを実行する前に、バージョンの新しいリースを購入することができます。（※補足：アップグレードによってRDSのインスタンスクラスを変更し、そのインスタンスクラスを恒常的に利用する場合は、リザーブドインスタンスのオプションもそれに合わせて変更する必要があります）
  • アップグレードする前に、無効 (invalid) なオブジェクトがないことを確認してください。すべてのオブジェクトのリストを、それぞれの数、タイプ、アップグレード前のステータスとともに保持し、アップグレード後に比較することを推奨します。
  • DBMS_STATS パッケージを使用して、すべてのアプリケーションスキーマのオプティマイザ統計のバックアップを取ります。
  • アップグレード前に、AWR または Statspack スナップショットを収集します。これらを利用し、アップグレード後のパフォーマンス検証が可能です。Pre-Production環境でこれを行っていたとしても、Production環境でもこの比較を行うことを推奨します。
  • パーティションの追加のようなDBメンテナンスタスクもある場合は、アップグレードする前にそれらを実行することを推奨します。
  • スケジュールされたデータベースのカスタムジョブまたはcronジョブを無効にします。
  • アップグレード前にカスタムDDLトリガーを無効にし、アップグレード後に再度有効にすることを推奨します。
  • マテリアライズドビュー（MV）を使用している場合は、アップグレード前にすべてのMVのステータスを確認してください。 MVログのサイズを確認します。ログサイズが0ではない場合は、アドレス指定してすべてが同期していることを確認します。すべてのMVの更新が完了するまで待つことを推奨します。ネットワークタイムアウトに費やす時間を削減するために、データベースリンクを介してリモートデータベースを参照するオブジェクトにアクセスできることを確認してください。詳細については、「My Oracle support」ドキュメントID 1406586.1を参照してください。ライセンス込みのお客様の場合は、このドキュメントのサポートケースを作成してください。
  • 使用するクライアントとそのドライバーのリストをバージョンナンバーとともに保管します。 19cで動作する対応バージョンを特定します。
  • すべての非表示のパラメーターを確認し、それらがターゲットバージョンに合わせて変更または削除されていることを確認します。これらのパラメーターの影響を受けるすべての機能をPre-Production環境での機能およびパフォーマンステストの一部として含めます。

Upgrade phase

アップグレード前のチェックが正常に完了した後に、アップグレードフェーズに進むことができます。インスタンスがカスタムされたオプショングループまたはパラメーターグループの構成を使用している場合、他の追加属性とともにアップグレードを実行するには、新しいオプショングループとパラメーターグループを指定する必要があります。

11.2.0.4 SE1 DBインスタンスを19cにアップグレードすると、デフォルトでは19cのSE2に移動します。（※補足：SE1 と SE2 とでは Reserved DB.Instance の種類が異なるため、同じ DB.Instance Class でもRIに互換性はありませんので注意してください。つまりバージョンアップして 19c にすると SE1 の Reserved Instance が適用対象外になります）

このセクションでは、コンソールまたはAWS CLIを使用してアップグレードを実行する方法について説明します。

コンソールでDBインスタンスのエンジンバージョンをアップグレードするには、次の手順を実行します。

  1. Amazon RDSコンソールで、[データベース]を選択します。
  2. アップグレードするDBインスタンスを選択します。
  3. 変更を選択します。[DBインスタンスの変更]ページが表示されます。
  4. ライセンスモデルでは、目的のライセンスタイプを選択します。 DBエンジンのバージョンについては、新しいバージョンを選択します。
  5. 続行を選択し、変更の概要を確認します。
  6. 変更をすぐに適用するには、[Apply immediately] を選択します。このオプションを選択すると、場合によっては停止が発生する可能性があります。詳細については、「即時適用設定の使用」を参照してください。それ以外の場合は、次の毎週のメンテナンスウィンドウでアップグレードを行うことができます。
  7. 確認ページで変更を確認し、[Modify DB Instance]を選択して変更を保存します。

AWS CLIの modify-db-instance コマンドを使用して次のメンテナンスウィンドウでメジャーバージョンのアップグレードを実行するには、次のコードを入力します。

aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --engine-version new_version \
    --allow-major-version-upgrade \
    --no-apply-immediately

有効なエンジンバージョンについては、AWS CLIの describe-db-engine-versions コマンドを使用してください。

複数のインスタンスがある場合は、AWS CLIをシェルスクリプトと組み合わせて使用​​して、複数のインスタンスをアップグレードできます。 Amazon RDS for Oracleのデータベースエンジンのアップグレードの詳細については、「Oracle DBエンジンのアップグレード」を参照してください。

Post-upgrade phase

アップグレードフェーズの後、次のチェックとアップグレード後の手順を実行できます。

  1. アップグレード前のフェーズのセクションで説明したように INVALID の再コンパイルが必要です、 INVALID ステータスのオブジェクトをチェックして修正することは、さらにテストする前に必要です。これは、アップグレード前のフェーズで収集された（オブジェクトカウントとステータスの）レポート/リストを比較するのにもよいタイミングです。（※補足：無効なスキーマ・オブジェクトおよびデータベース・アップグレードの概要 を合わせて確認ください）
  2. Amazon RDS for OracleがRMANカタログとして使用されている場合は、RMANリカバリカタログをアップグレードしてください。 UPGRADE CATALOG コマンドを使用して、RMANリカバリカタログスキーマを古いバージョンからRMANクライアントに必要なバージョンにアップグレードします。
  3. 次のクライアント接続手順を実行します。
    • A）クライアントのホームで、ORACLE_HOME , PATH , LD_LIBRARY_PATH , LIBPATH などを必ず 19.x に設定してください。
    • B) 本番環境から復元された新しいRDSインスタンスでテストする場合は、クライアント側の tnsnames.ora と sqlnet.ora に適切な変更を加え、19cまたは新しいエンドポイントに関連する設定を変更します。
    • C) クライアント接続をテストします。識別されたドライバーのターゲットバージョンに基づいて、リグレッションテストを実行します。 JDBCバージョンの選択がパフォーマンスに影響を与え、プロセスオプティマイザーの計画を変更する場合があることに注意してください。
  4. アップグレード前のタスクで説明したように DBMS_STATS パッケージを使用してオプティマイザ統計をエクスポートした場合は、アップグレードの前にオプティマイザ統計がバックアップされている統計テーブルを（ DBMS_STATS.UPGRADE_STAT_TABLE を使用して）アップグレードします。次に、統計を復元し、パフォーマンステストを実行します。
  5. 他のAmazon RDS for Oracle DBインスタンスまたはAmazon Elastic Compute Cloud（Amazon EC2）上の他のOracleインスタンスへのデータベースリンクがある場合は、アップグレード後に機能とパフォーマンスの両方の観点からそれらをテストすることを推奨します。
  6. Amazon CloudWatchまたはcronでスケジュールされた外部スケジューラジョブがある場合は、それらが有効になっていて、アップグレード後もデータベースに接続して問題なく実行できることを確認してください。
  7. また、アップグレード前のチェックの一環として、DDLまたはシステムトリガーが無効になっていることを確認してください。
  8. SYSTEM および SYSAUX の表領域に十分な空きスペースがあることを確認してください。（不足が想定される場合は）各テーブルスペースに1〜2 GBのスペースを追加することを推奨します。
  9. アップグレードしたデータベースに対してアプリケーションを検証します。上位のSQLステートメントを（AWRまたはStatspackを介して）確認し、それらが目的のPLAN(※補足：実行計画)を使用していることを確認することが重要です。
  10. バックアップと復元、災害復旧（DR）、または本番から非本番への更新手順の自動化プロセスがある場合は、それらをテストすることを強く推奨します。同じレベルにあるかどうかに関係なく、他のデータベースと対話するプロセスをテストする必要があります。

Common issues

AWSバックアップまたはサードパーティのパートナー製品を使用して取得したスナップショットを含め、長期間保持する予定の手動スナップショットをアップグレードすることを強く推奨します。たとえば、AWSバックアップを使用し、バックアップがAWSバックアップで定義されたライフサイクルに基づいてAmazon EFSファイルシステムに移行された場合、そこからバックアップが復元されると、RDSが最初に行うことは、サポートされるバージョンのいずれかに強制的にアップグレードし、次に、復元を完了します。古いバージョンのコピーとして保持する場合（たとえば、データベースが古いバージョンのサードパーティアプリケーションをサポートしている場合）、エクスポートデータポンプやRMANなどのネイティブOracleツールを使用してバックアップを作成することを計画する必要があります。また、バージョンの非互換性にも注意してください。

※補足：前半は Oracle DB スナップショットのアップグレード - Amazon Relational Database Service を参照ください。後半については、RDS for Oracle 11g の Snapshot は今後、リストア時に強制的にアップグレードされようになるため、Expdpなどを利用して Snapshot ではない形式でバックアップを作成して置くほうが良いということです。

データベースをアップグレードした後、 "ORA-28040: No matching authentication protocol" などの接続の問題が発生した場合は、クライアントのバージョンまたはJDBCドライバーをアップグレードする必要がある場合があります。一般に、クライアントとサーバーのバージョンを一致させることが最善です。データベースバージョン19cに最適なクライアントバージョンは、クライアント19cです。ただし、11.2.0.4クライアントも19cでサポートされています。この組み合わせをテストすることを強く推奨します。 「My Oracle support」ドキュメント207303.1を参照してください。

※補足：これについては以下のブログを合わせて参照ください。

blog.serverworks.co.jp

Testing the upgrade of your Amazon RDS for Oracle DB instance

Production データベースを新しいメジャーバージョンにアップグレードする前に、Pre-Production 環境で新しいバージョンに対してアプリケーションを検証する必要があります。このアップグレードプロセスのリハーサルでは、メジャーバージョンアップグレードの実行時間を測定することも可能です。

次の図は、アップグレードをテストする手順を示しています。

f:id:swx-satake:20200913152947p:plain

プロセスには次のステップが含まれます。

  1. create-db-snapshot AWS CLI呼び出しを使用して、既存のDBインスタンスのスナップショットを作成します。
  2. 同じバージョンでテストDBインスタンスを作成するために、restore-db-instance-from-db-snapshot AWS CLI呼び出しを使用してDBスナップショットを復元します。
  3. テストDBインスタンスで modify-db-instance AWS CLI呼び出しを実行して、新しいメジャーバージョンにアップグレードします。
  4. アップグレードが完了したら、テストDBインスタンスに対してアプリケーションを検証できます。
  5. テストが完了した後に、Productionデータベースのアップグレードをスケジュールして実行します。

Additional considerations

Amazon RDS for Oracleは、バージョン12.1.0.2以降のリードレプリカ機能をサポートしています。データベースを11.2.0.4をアップグレードするにおいて、リードレプリカ機能を評価し、アプリケーションにCross-Region disaster recoveryとread scalabilityが必要かどうかを判断する必要があります。詳細については、Managed disaster recovery and managed reader farm with Amazon RDS for Oracle using Oracle Active Data Guard. を参照してください。

19cへのアップグレードの一環として、OLAPやOracle Label Securityなどのオプションを使用することもできます。

Conclusion

この投稿では、Amazon RDS for Oracleの11.2.0.4サポート終了タイムラインを確認し、利用可能なバージョンアップグレードの選択肢を調査し、アップグレードプロセスのフェーズにおけるベストプラクティスをカバーしました。

11.2.0.4で実行されているAmazon RDS for Oracle DBインスタンスの計画とアップグレードについて追加の支援が必要な場合は、次のリソースに問い合わせることができます。

アップグレードの詳細については、以下も合わせて参照してください。

まとめ

f:id:swx-satake:20200912172007p:plain

以上が翻訳になります。

これは私の経験からくる個人的な意見はありますが、大規模なアプリケーション開発においては、アプリケーションの仕様とOracleデータベース機能の活用状況を完全に把握できる DBA や開発者は存在しえないと考えています（※完全な管理資料が存在する場合は別ですが）。そのため、Pre-Production環境（つまり本番環境の複製環境）を作成し、その本番複製環境でアップグレード作業のテストと、アップグレード後の機能検証を実行されるのがベターと考えます。その場合におけるOraceデータベースバージョンアップ後の機能検証（機能テスト）は、普段のテストシナリオがどの程度までアプリケーションの機能全体を網羅できているかによって精度は変わりますが、予め複製環境を作成してテストすることが重要なことには変わりないでしょう。

何が伝えたいかと言いますと、早期に本番環境を複製し、その環境においてアップグレードの影響を確かめるテストシナリオを実行されることによって予め影響範囲を特定し、事前の対策を検討されることを推奨いたします。

本記事が、何かの参考になれば幸いです。

ではまた、ブログでお会いしましょう。

佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ

マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。

【お知らせ】

【AWS re:Invent 2024 をエンジニアブログで振り返ろう】

2024年12月2日 - 12月6日 | ラスベガス（米国）
世界最大の AWS カンファレンス・AWS re:Invent 2024の感動をエンジニアブログで振り返りましょう！

AWS re:Invent 2024のブログ記事を読む