# Oracle のタイムゾーンファイルの自動アップグレード
`TIMEZONE_FILE_AUTOUPGRADE` オプションを使用すると、現在のタイムゾーンファイルを RDS for Oracle DB インスタンスの最新バージョンにアップグレードできます。
**Topics**
+ [Oracle のタイムゾーンファイルの概要](Appendix.Oracle.Options.Timezone-file-autoupgrade.tz-overview.md)
+ [タイムゾーンファイルを更新する戦略](Appendix.Oracle.Options.Timezone-file-autoupgrade.strategies.md)
+ [タイムゾーンファイル更新時のダウンタイム](Appendix.Oracle.Options.Timezone-file-autoupgrade.considerations.md)
+ [タイムゾーンファイル更新の準備](Appendix.Oracle.Options.Timezone-file-autoupgrade.preparing.md)
+ [タイムゾーンファイル自動アップグレードオプションの追加](Appendix.Oracle.Options.Timezone-file-autoupgrade.adding.md)
+ [タイムゾーンファイル更新後のデータのチェック](Appendix.Oracle.Options.Timezone-file-autoupgrade.checking.md)
# Oracle のタイムゾーンファイルの概要
Oracle Database の*タイムゾーンファイル*には、次の情報が格納されます。
+ 協定世界時 (UTC) との時差
+ サマータイム (DST) の移行時期
+ 標準時と DST の略語
Oracle Database には、複数のバージョンのタイムゾーンファイルが用意されています。オンプレミス環境で Oracle Database を作成するときには、タイムゾーンファイルのバージョンを選択します。詳細については、*「Oracle Database グローバリゼーションサポートガイド*」の「[タイムゾーンファイルの選択](https://docs.oracle.com/en/database/oracle/oracle-database/19/nlspg/datetime-data-types-and-time-zone-support.html#GUID-805AB986-DE12-4FEA-AF56-5AABCD2132DF)」を参照してください。
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\$1FILE\$1AUTOUPGRADE オプションを使用した自動アップデート
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](https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/Welcome.html)」(Amazon Relational Database Service (Amazon RDS) for Oracle リリースノート) のパッチを参照してください。例えば、[version 19.0.0.0.ru-2022-10.rur-2022-10.r1](https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/oracle-version-19-0.html#oracle-version-RU-RUR.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-name name ...
```
更新戦略は、データベースとタイムゾーンファイルを一緒にアップグレードするか、これらのオペレーションのいずれかのみを実行するかによって異なります。オプショングループを更新し、別の 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 が含まれています。
タイムゾーンファイルを更新するには、以下の戦略を使用できます。
**Topics**
+ [エンジンをアップグレードせずにタイムゾーンファイルを更新する](#Appendix.Oracle.Options.Timezone-file-autoupgrade.strategies.no-upgrade)
+ [タイムゾーンファイルと DB エンジンバージョンをアップグレードする](#Appendix.Oracle.Options.Timezone-file-autoupgrade.strategies.upgrade)
+ [タイムゾーンファイルを更新せずに、DB エンジンのバージョンをアップグレードする](#Appendix.Oracle.Options.Timezone-file-autoupgrade.strategies.upgrade-only)
## エンジンをアップグレードせずにタイムゾーンファイルを更新する
このシナリオでは、データベースに DSTv33 を使用していますが、ご使用の DB インスタンスファイルシステムでは DSTv34 が使用できます。DB インスタンスで使用されるタイムゾーンファイルを DSTv33 から DSTv34 に更新しても、エンジンは DSTv35 を含む新しいマイナーバージョンにアップグレードしたくありません。
`add-option-to-option-group` コマンドで、DB インスタンスで使用されるオプショングループに `TIMEZONE_FILE_AUTOUPGRADE` を追加します。オプションをすぐに追加するか、メンテナンスウィンドウまで遅延するかを指定します。`TIMEZONE_FILE_AUTOUPGRADE` オプションを適用すると、RDS は次の処理を行います。
1. 新しい DST バージョンをチェックする。
1. DSTv34 がファイルシステムで使用可能であることを決定する。
1. タイムゾーンファイルをすぐに更新する。
## タイムゾーンファイルと 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-version new-version \
----option-group-name og-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 に更新を開始します。
エンジンをすぐにアップグレードし、タイムゾーンファイルをアップグレードするには、オペレーションを順番に実行します。
1. 次の CLI コマンドを使用してのみ DB エンジンをアップグレードします。
```
aws rds modify-db-instance \
--db-instance-identifier my-instance \
--engine-version new-version \
--apply-immediately
```
1. 次の 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](https://docs.oracle.com/en/database/oracle/oracle-database/19/nlspg/datetime-data-types-and-time-zone-support.html#GUID-B0ACDB2E-4B49-4EB4-B4CC-9260DAE1567A) を参照してください。
**タイムゾーンファイル更新の準備を行うには**
1. SQL クライアントを使用して、Oracle Database に接続します。
1. 現在使用されているタイムゾーンファイルのバージョンを確認します。
```
SELECT * FROM V$TIMEZONE_FILE;
```
1. DB インスタンスで使用可能な最新のタイムゾーンファイルのバージョンを決定します。
```
SELECT DBMS_DST.GET_LATEST_TIMEZONE_VERSION FROM DUAL;
```
1. `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');
```
1. `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;
```
1. 準備ステップを実行します。
+ 手順 `DBMS_DST.CREATE_AFFECTED_TABLE` で、影響を受けるデータを保存するためのテーブルを作成します。このテーブル名を `DBMS_DST.FIND_AFFECTED_TABLES` 手順に渡します。詳細については、Oracle Database ドキュメントの [CREATE\$1AFFECTED\$1TABLE Procedure](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_DST.html#GUID-C53BAABA-914A-404C-9CD5-823257BE0B00) を参照してください。
+ このプロシージャ `CREATE_ERROR_TABLE` は、エラーを記録するテーブルを作成します。詳細については、Oracle Database ドキュメントの [CREATE\$1ERROR\$1TABLE Procedure](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_DST.html#GUID-6A7EA024-B02D-4486-B1D6-EF6ABF5DE507) を参照してください。
次の例では、影響を受けるデータとエラーテーブルを作成し、影響を受けるすべてのテーブルを検索します。
```
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 * FROM my_affected_table;
SELECT * FROM my_error_table;
```
1. 影響を受けるテーブルとエラーテーブルをクエリします。
```
SELECT * FROM my_affected_table;
SELECT * FROM my_error_table;
```
# タイムゾーンファイル自動アップグレードオプションの追加
オプションをオプショングループに追加すると、オプショングループは次のいずれかの状態になります。
+ 既存のオプショングループは、現在、少なくとも 1 つの DB インスタンスにアタッチされています。オプションを追加すると、このオプショングループを使用するすべての DB インスタンスが自動的に再起動します。これにより、短時間の停止が発生します。
+ 既存のオプショングループは、DB インスタンスにアタッチされていません。オプションを追加してから、既存のオプショングループを既存の DB インスタンスまたは新しい DB インスタンスに関連付ける予定です。
+ 新しいオプショングループを作成し、オプションを追加します。新しいオプショングループを既存の DB インスタンスまたは新しい DB インスタンスに関連付ける予定です。
## コンソール
**タイムゾーンファイル自動アップグレードオプションを DB インスタンスに追加するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. 使用するオプショングループを決定します。新しいオプショングループを作成することも、既存のオプショングループを使用することもできます。既存のオプショングループを使用する場合は、次のステップは飛ばしてください。または、次の設定でカスタム DB オプショングループを作成します。
1. **[Engine]** (エンジン) として、DB インスタンスの Oracle Database エディションを選択します。
1. [**メジャーエンジンのバージョン**] で、DB インスタンスのバージョンを選択します。
詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. 変更するオプショングループを選択し、[**オプションの追加**] を選択します。
1. [**Add option**(オプションの追加)] ウィンドウで、以下の操作を行います。
1. **[TIMEZONE\$1FILE\$1AUTOUPGRADE]** を選択します。
1. オプションを追加後すぐに、関連付けられているすべての DB インスタンスに対して有効にするには、[**Apply Immediately**] で [**Yes**] を選択します。[**No**] を選択した場合 (デフォルト)、オプションは次のメンテナンス時間中に、関連付けられている各 DB インスタンスに対して有効になります。
1. 設定が希望どおりになったら、[**オプションの追加**] を選択します。
## AWS CLI
次の例では、AWS CLI の [add-option-to-option-group](https://docs.aws.amazon.com/cli/latest/reference/rds/add-option-to-option-group.html) コマンドを使用して、`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\$1AFFECTED\$1TABLES Procedure](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_DST.html#GUID-1F977505-671C-4D5B-8570-86956F136199) を参照してください。