Oracle のタイムゾーンファイルの自動アップグレード
TIMEZONE_FILE_AUTOUPGRADE
オプションを使用すると、現在のタイムゾーンファイルを RDS for Oracle DB インスタンスの最新バージョンにアップグレードできます。
トピック
Oracle のタイムゾーンファイルの概要
Oracle Database のタイムゾーンファイルには、次の情報が格納されます。
-
協定世界時 (UTC) との時差
-
サマータイム (DST) の移行時期
-
標準時と DST の略語
Oracle Database には、複数のバージョンのタイムゾーンファイルが用意されています。オンプレミス環境で Oracle Database を作成するときには、タイムゾーンファイルのバージョンを選択します。詳細については、「Oracle Database グローバリゼーションサポートガイド」の「タイムゾーンファイルの選択
DST のルールが変更された場合、Oracle は新しいタイムゾーンファイルを公開します。Oracle は、四半期ごとの Release Updates (RU) および Release Update Revisions (RUR) のスケジュールとは関係なく、これらの新しいタイムゾーンファイルをリリースします。タイムゾーンファイルは、データベースホストのディレクトリ $ORACLE_HOME/oracore/zoneinfo/
にあります。タイムゾーンファイル名は、DSTv35 のような形式 DSTv バージョン
を使用します。
タイムゾーンファイルがデータ転送に与える影響
Oracle Database では、TIMESTAMP WITH TIME ZONE
データ型は、タイムスタンプとタイムゾーンのデータを保存します。TIMESTAMP WITH TIME ZONE
データ型のデータは、関連付けられたタイムゾーンファイルバージョンのルールを使用します。そのため、タイムゾーンファイルを更新すると、既存の TIMESTAMP WITH TIME ZONE
データが影響を受けます。
異なるバージョンのタイムゾーンファイルを使用するデータベース間でデータを転送すると、問題が発生する可能性があります。例えば、ターゲットデータベースよりも高いバージョンのタイムゾーンファイルを持つソースデータベースからデータをインポートすると、データベースは ORA-39405
エラーを発行します。以前は、次のいずれかのテクニックを使用して、このエラーを回避する必要がありました。
-
必要なタイムゾーンファイルを使用して RDS for Oracle DB インスタンスを作成し、ソースデータベースからデータをエクスポートしてから、新しいデータベースにインポートします。
-
AWS DMS または論理的なレプリケーションを使用して、データを移行します。
TIMEZONE_FILE_AUTOUPGRADE オプションを使用した自動アップデート
RDS for Oracle DB インスタンスにアタッチされたオプショングループに TIMEZONE_FILE_AUTOUPGRADE
オプションが含まれている場合、RDS はタイムゾーンファイルを自動的に更新します。Oracle データベースが同じバージョンのタイムゾーンファイルを使用するようにすることで、異なる環境間でデータを移動する際に時間のかかる手動操作を回避できます。TIMEZONE_FILE_AUTOUPGRADE
オプションは、コンテナデータベース (CDB) と非 CDB の両方に対してサポートされています。
TIMEZONE_FILE_AUTOUPGRADE
オプションをオプショングループに追加するときには、オプションをすぐに追加するか、メンテナンスウィンドウで追加するかを選択できます。DB インスタンスが新しいオプションを適用すると、RDS は新しい DSTv バージョン
ファイルをインストールできるかどうか確認します。対象の DST バージョン
は以下の内容によって異なります。
-
DB インスタンスが現在実行中のマイナーエンジンバージョン
-
DB インスタンスのアップグレード先のマイナーエンジンバージョン
例えば、現在のタイムゾーンファイルのバージョンは DSTv33 である可能性があります。RDS がオプショングループに更新を適用すると、DSTv34 が DB インスタンスファイルシステムで現在利用可能であると判断される場合があります。その後、RDS はタイムゾーンファイルを自動的に DSTv34 に更新します。
サポートされる RDS リリース更新で利用可能な DST バージョンを確認するには、「Release notes for Amazon Relational Database Service (Amazon RDS) for Oracle」(Amazon Relational Database Service (Amazon RDS) for Oracle リリースノート) のパッチを参照してください。例えば、version 19.0.0.0.ru-2022-10.rur-2022-10.r1 には、パッチ 34533061: RDBMS - DSTV39 UPDATE - TZDATA2022C がリストされています。
タイムゾーンファイルを更新する戦略
DB エンジンをアップグレードし、オプショングループに TIMEZONE_FILE_AUTOUPGRADE
オプションを追加するオペレーションは個別に行います。TIMEZONE_FILE_AUTOUPGRADE
オプションを追加すると、最新のタイムゾーンファイルがある場合は、タイムゾーンファイルの更新が開始されます。すぐに、または次のメンテナンスウィンドウで、次のコマンドを実行します (関連するオプションのみが表示されます)。
-
次の RDS CLI コマンドを使用してのみ DB エンジンをアップグレードします。
modify-db-instance --engine-version
name
... -
次の CLI コマンドを使用してのみ
TIMEZONE_FILE_AUTOUPGRADE
オプションを追加します。add-option-to-option-group --option-group-name
name
--options OptionName=TIMEZONE_FILE_AUTOUPGRADE ... -
次の CLI コマンドを使用して、DB エンジンをアップグレードし、インスタンスに新しいオプショングループを追加します。
modify-db-instance --engine-version
name
--option-group-namename
...
更新戦略は、データベースとタイムゾーンファイルを一緒にアップグレードするか、これらのオペレーションのいずれかのみを実行するかによって異なります。オプショングループを更新し、別の API オペレーションで DB エンジンをアップグレードすると、DB エンジンをアップグレードするときにタイムゾーンファイルの更新が現在進行中になる可能性があることに注意してください。
このセクションの例では、以下を前提とします。
-
DB インスタンスに現在関連付けられているオプショングループに、まだ
TIMEZONE_FILE_AUTOUPGRADE
が追加されていません。 -
ご使用の DB インスタンスはデータベースバージョン 19.0.0.0.ru-2019-07.rur-2019-07.r1 およびタイムゾーンファイル DSTv33 を使用しています。
-
DB インスタンスファイルシステムには、ファイル DSTv34 が含まれています。
-
リリース更新プログラム 19.0.0.0.ru-2022-10.rur-2022-10.r1 には DSTv35 が含まれています。
タイムゾーンファイルを更新するには、以下の戦略を使用できます。
トピック
エンジンをアップグレードせずにタイムゾーンファイルを更新する
このシナリオでは、データベースに DSTv33 を使用していますが、ご使用の DB インスタンスファイルシステムでは DSTv34 が使用できます。DB インスタンスで使用されるタイムゾーンファイルを DSTv33 から DSTv34 に更新しても、エンジンは DSTv35 を含む新しいマイナーバージョンにアップグレードしたくありません。
add-option-to-option-group
コマンドで、DB インスタンスで使用されるオプショングループに TIMEZONE_FILE_AUTOUPGRADE
を追加します。オプションをすぐに追加するか、メンテナンスウィンドウまで遅延するかを指定します。TIMEZONE_FILE_AUTOUPGRADE
オプションを適用すると、RDS は次の処理を行います。
-
新しい DST バージョンをチェックする。
-
DSTv34 がファイルシステムで使用可能であることを決定する。
-
タイムゾーンファイルをすぐに更新する。
タイムゾーンファイルと DB エンジンバージョンをアップグレードする
このシナリオでは、データベースに DSTv33 を使用していますが、ご使用の DB インスタンスファイルシステムでは DSTv34 が使用できます。DB エンジンを DSTv35 を含むマイナーバージョン 19.0.0.0.ru-2022-10.rur-2022-10.r1 にアップグレードし、エンジンのアップグレード中にタイムゾーンファイルを DSTv35 に更新します。したがって、目標は DSTv34 をスキップして、タイムゾーンファイルを DSTv35 に直接更新することです。
エンジンとタイムゾーンファイルを一緒にアップグレードするには、--option-group-name
および --engine-version
オプションを使用して modify-db-instance
を実行します。コマンドはすぐに実行することも、メンテナンスウィンドウ に延期することもできます。In --option-group-name
は、TIMEZONE_FILE_AUTOUPGRADE
オプションを含むオプショングループを指定します。例:
aws rds modify-db-instance --db-instance-identifier
my-instance
\ --engine-versionnew-version
\ ----option-group-nameog-with-timezone-file-autoupgrade
\ --apply-immediately
RDS は、エンジンの 19.0.0.0.ru-2022-10.rur-2022-10.r1 へのアップグレードを開始します。TIMEZONE_FILE_AUTOUPGRADE
オプションが適用されると、RDS は新しい DST バージョンを確認して、DSTv35 が 19.0.0.0.ru-2022-10.rur-2022-10.r1 で使用可能であることがわかると、すぐに DSTv35 に更新を開始します。
エンジンをすぐにアップグレードし、タイムゾーンファイルをアップグレードするには、オペレーションを順番に実行します。
-
次の CLI コマンドを使用してのみ DB エンジンをアップグレードします。
aws rds modify-db-instance \ --db-instance-identifier
my-instance
\ --engine-versionnew-version
\ --apply-immediately -
次の CLI コマンドを使用して、インスタンスにアタッチされたオプショングループに
TIMEZONE_FILE_AUTOUPGRADE
オプションを追加します。aws rds add-option-to-option-group \ --option-group-name
og-in-use-by-your-instance
\ --options OptionName=TIMEZONE_FILE_AUTOUPGRADE \ --apply-immediately
タイムゾーンファイルを更新せずに、DB エンジンのバージョンをアップグレードする
このシナリオでは、データベースに DSTv33 を使用していますが、ご使用の DB インスタンスファイルシステムでは DSTv34 が使用できます。DB エンジンを DSTv35 を含むバージョン 19.0.0.0.ru-2022-10.rur-2022-10.r1 にアップグレードしても、タイムゾーンファイル DSTv33 を保持します。次の理由から、この戦略が必要になる場合があります。
-
データが
TIMESTAMP WITH TIME ZONE
データ型を使用しない。 -
データは
TIMESTAMP WITH TIME ZONE
データ型を使用できますが、データがタイムゾーン変更の影響を受けません。 -
追加のダウンタイムを許容できないため、タイムゾーンファイルの更新を延期する必要があります。
戦略は、次のいずれが該当するによって異なります。
-
DB インスタンスは
TIMEZONE_FILE_AUTOUPGRADE
を含むオプショングループに関連付けられていません。modify-db-instance
コマンドでは、RDS がタイムゾーンファイルを更新しないように、新しいオプショングループを指定しないでください。 -
DB インスタンスは現在、
TIMEZONE_FILE_AUTOUPGRADE
を含むオプショングループに関連付けられています。単一のmodify-db-instance
コマンド内で、TIMEZONE_FILE_AUTOUPGRADE
を含まないオプショングループに DB インスタンスを関連付けてから、DB エンジンを 19.0.0.0.ru-2022-10.rur-2022-10.r1 にアップグレードします。
タイムゾーンファイル更新時のダウンタイム
RDS がタイムゾーンファイルを更新すると、TIMESTAMP WITH
TIME ZONE
を使用する既存のデータが変更される可能性があります。この場合、主な考慮事項は、ダウンタイムです。
警告
TIMEZONE_FILE_AUTOUPGRADE
オプションを追加すると、エンジンのアップグレードのためにダウンタイムが長くなる可能性があります。ラージデータベースのタイムゾーンデータの更新には、数時間または数日かかることがあります。
タイムゾーンファイルの更新の長さは、次のような要因によって異なります。
-
データベース内の
TIMESTAMP WITH TIME ZONE
データの量 -
DB インスタンスの設定
-
DB インスタンスクラス
-
ストレージ設定
-
データベース設定
-
データベースパラメータ設定
次の操作を行うと、追加のダウンタイムが発生する可能性があります。
-
DB インスタンスが古いタイムゾーンファイルを使用しているときには、オプションをオプショングループに追加します。
-
新しいエンジンバージョンにタイムゾーンファイルの新しいバージョンが含まれている場合は、Oracle データベースエンジンをアップグレードします。
注記
タイムゾーンファイルの更新中に、RDS for Oracle は PURGE
DBA_RECYCLEBIN
を呼び出します。
タイムゾーンファイル更新の準備
タイムゾーンファイルのアップグレードには、準備とアップグレードの 2 つの段階があります。必須ではありませんが、準備ステップを実行することを強く推奨します。このステップでは、PL/SQL ステップ DBMS_DST.FIND_AFFECTED_TABLES
を実行することによって影響を受けるデータを調べます。準備ウィンドウの詳細については、Oracle Database ドキュメントの Upgrading the Time Zone File and Timestamp with Time Zone Data
タイムゾーンファイル更新の準備を行うには
-
SQL クライアントを使用して、Oracle Database に接続します。
-
現在使用されているタイムゾーンファイルのバージョンを確認します。
SELECT * FROM V$TIMEZONE_FILE;
-
DB インスタンスで使用可能な最新のタイムゾーンファイルのバージョンを決定します。
SELECT DBMS_DST.GET_LATEST_TIMEZONE_VERSION FROM DUAL;
-
TIMESTAMP WITH LOCAL TIME ZONE
またはTIMESTAMP WITH TIME ZONE
型の列を持つテーブルの合計サイズを決定します。SELECT SUM(BYTES)/1024/1024/1024 "Total_size_w_TSTZ_columns_GB" FROM DBA_SEGMENTS WHERE SEGMENT_TYPE LIKE 'TABLE%' AND (OWNER, SEGMENT_NAME) IN (SELECT OWNER, TABLE_NAME FROM DBA_TAB_COLUMNS WHERE DATA_TYPE LIKE 'TIMESTAMP%TIME ZONE');
-
TIMESTAMP WITH LOCAL TIME ZONE
またはTIMESTAMP WITH TIME ZONE
型の列を持つセグメントの名前とサイズを決定します。SELECT OWNER, SEGMENT_NAME, SUM(BYTES)/1024/1024/1024 "SEGMENT_SIZE_W_TSTZ_COLUMNS_GB" FROM DBA_SEGMENTS WHERE SEGMENT_TYPE LIKE 'TABLE%' AND (OWNER, SEGMENT_NAME) IN (SELECT OWNER, TABLE_NAME FROM DBA_TAB_COLUMNS WHERE DATA_TYPE LIKE 'TIMESTAMP%TIME ZONE') GROUP BY OWNER, SEGMENT_NAME;
-
準備ステップを実行します。
-
手順
DBMS_DST.CREATE_AFFECTED_TABLE
で、影響を受けるデータを保存するためのテーブルを作成します。このテーブル名をDBMS_DST.FIND_AFFECTED_TABLES
手順に渡します。詳細については、Oracle Database ドキュメントの CREATE_AFFECTED_TABLE Procedureを参照してください。 -
このプロシージャ
CREATE_ERROR_TABLE
は、エラーを記録するテーブルを作成します。詳細については、Oracle Database ドキュメントの CREATE_ERROR_TABLE Procedureを参照してください。
次の例では、影響を受けるデータとエラーテーブルを作成し、影響を受けるすべてのテーブルを検索します。
EXEC DBMS_DST.CREATE_ERROR_TABLE('
my_error_table
') EXEC DBMS_DST.CREATE_AFFECTED_TABLE('my_affected_table
') EXEC DBMS_DST.BEGIN_PREPARE(new_version
); EXEC DBMS_DST.FIND_AFFECTED_TABLES('my_affected_table
', TRUE, 'my_error_table
'); EXEC DBMS_DST.END_PREPARE; SELECT * FROMmy_affected_table
; SELECT * FROMmy_error_table
; -
-
影響を受けるテーブルとエラーテーブルをクエリします。
SELECT * FROM
my_affected_table
; SELECT * FROMmy_error_table
;
タイムゾーンファイル自動アップグレードオプションの追加
オプションをオプショングループに追加すると、オプショングループは次のいずれかの状態になります。
-
既存のオプショングループは、現在、少なくとも 1 つの DB インスタンスにアタッチされています。オプションを追加すると、このオプショングループを使用するすべての DB インスタンスが自動的に再起動します。これにより、短時間の停止が発生します。
-
既存のオプショングループは、DB インスタンスにアタッチされていません。オプションを追加してから、既存のオプショングループを既存の DB インスタンスまたは新しい DB インスタンスに関連付ける予定です。
-
新しいオプショングループを作成し、オプションを追加します。新しいオプショングループを既存の DB インスタンスまたは新しい DB インスタンスに関連付ける予定です。
コンソール
タイムゾーンファイル自動アップグレードオプションを DB インスタンスに追加するには
AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 -
ナビゲーションペインで、[オプショングループ] を選択します。
-
使用するオプショングループを決定します。新しいオプショングループを作成することも、既存のオプショングループを使用することもできます。既存のオプショングループを使用する場合は、次のステップは飛ばしてください。または、次の設定でカスタム DB オプショングループを作成します。
-
[Engine] (エンジン) として、DB インスタンスの Oracle Database エディションを選択します。
-
[メジャーエンジンのバージョン] で、DB インスタンスのバージョンを選択します。
詳細については、「オプショングループを作成する」を参照してください。
-
-
変更するオプショングループを選択し、[オプションの追加] を選択します。
-
[Add option(オプションの追加)] ウィンドウで、以下の操作を行います。
-
[TIMEZONE_FILE_AUTOUPGRADE] を選択します。
-
オプションを追加後すぐに、関連付けられているすべての DB インスタンスに対して有効にするには、[Apply Immediately] で [Yes] を選択します。[No] を選択した場合 (デフォルト)、オプションは次のメンテナンス時間中に、関連付けられている各 DB インスタンスに対して有効になります。
-
-
設定が希望どおりになったら、[オプションの追加] を選択します。
AWS CLI
次の例では、AWS CLI の add-option-to-option-group コマンドを使用して、TIMEZONE_FILE_AUTOUPGRADE
オプションを myoptiongroup
オプショングループに追加しています。
Linux、macOS、Unix の場合:
aws rds add-option-to-option-group \ --option-group-name "
myoptiongroup
" \ --options "OptionName=TIMEZONE_FILE_AUTOUPGRADE
" \ --apply-immediately
Windows の場合:
aws rds add-option-to-option-group ^ --option-group-name "
myoptiongroup
" ^ --options "OptionName=TIMEZONE_FILE_AUTOUPGRADE
" ^ --apply-immediately
タイムゾーンファイル更新後のデータのチェック
タイムゾーンファイルの更新後に、データをチェックすることをお勧めします。準備ステップでは、RDS for Oracle によって次のテーブルが自動的に作成されます。
-
rdsadmin.rds_dst_affected_tables
- 更新の影響を受けるデータを含むテーブルを一覧表示します -
rdsadmin.rds_dst_error_table
- 更新中に生成されたエラーを一覧表示します
これらのテーブルは、準備ウィンドウで作成するテーブルから独立しています。更新の結果を表示するには、次のようにテーブルをクエリします。
SELECT * FROM rdsadmin.rds_dst_affected_tables; SELECT * FROM rdsadmin.rds_dst_error_table;
影響を受けるデータおよびエラーテーブルのスキーマの詳細については、Oracle ドキュメントの FIND_AFFECTED_TABLES Procedure