| Oracle® Databaseグローバリゼーション・サポート・ガイド 11gリリース2 (11.2) B56307-04 |
|
 前 |
 次 |
この章の内容は、次のとおりです。
企業は様々なタイム・ゾーンにまたがってトランザクションを実行しています。Oracle Databaseの日時データ型、期間データ型およびタイム・ゾーン・サポートにより、イベントとトランザクションの時間に関して一貫性のある情報を格納できます。
|
注意: この章では、Oracle Databaseの日時データ型と期間データ型について説明します。特に明記している場合を除き、ANSIデータ型や他の種類のデータ型については説明しません。 |
日時データ型は、DATE、TIMESTAMP、TIMESTAMP WITH TIME ZONEおよびTIMESTAMP WITH LOCAL TIME ZONEです。日時データ型の値をDatetimesと呼ぶこともあります。
期間データ型は、INTERVAL YEAR TO MONTHおよびINTERVAL DAY TO SECONDです。期間データ型の値をIntervalsと呼ぶこともあります。
DatatimesとIntervalsは、どちらも複数のフィールドで構成されます。これらのフィールドの値により、データ型の値が決定されます。Oracle Databaseのすべての日時および期間データ型に適用されるフィールドは、次のとおりです。
YEAR
MONTH
DAY
HOUR
MINUTE
SECOND
TIMESTAMP WITH TIME ZONEには、次のフィールドも含まれます。
TIMEZONE_HOUR
TIMEZONE_MINUTE
TIMEZONE_REGION
TIMEZONE_ABBR
TIMESTAMP WITH LOCAL TIME ZONEはタイム・ゾーン情報の内部格納には使用されませんが、TZH:TZMまたはTZR TZD書式要素が指定されている場合は、SQL出力にローカルのタイム・ゾーン情報を表示できます。
次の項では、日時データ型と期間データ型の詳細を説明します。
|
関連項目:
|
この項の内容は、次のとおりです。
DATEデータ型を使用して、日付および時刻情報が格納されます。日付および時刻情報はCHARACTERおよびNUMBERデータ型の両方で表現できますが、DATEデータ型は特別に関連付けられているプロパティがあります。DATE値ごとに、次の世紀、年、月、日、時間、分および秒の情報が格納されます。
日付値は次の方法で指定できます。
日付値をリテラルとして指定
TO_DATE関数を使用して文字値または数値を日付値に変換
日付は、ANSI日付リテラルまたはOracle Databaseの日付値として指定できます。
ANSI日付リテラルには時間部分がなく、次の書式で正確に指定する必要があります。
DATE 'YYYY-MM-DD'
次にANSI日付リテラルの例を示します。
DATE '1998-12-25'
または、次の例に示すようにOracle Databaseの日付値を指定することもできます。
TO_DATE('1998-DEC-25 17:30','YYYY-MON-DD HH24:MI','NLS_DATE_LANGUAGE=AMERICAN')
Oracleデータベースの日付値のデフォルト書式は、NLS_DATE_FORMATおよびNLS_DATE_LANGUAGE初期化パラメータから導出されます。この例の日付書式には、日を表す2桁の数値、月名の略称、年の最後の2桁および24時間指定が含まれています。NLS_DATE_LANGUAGEの指定が含まれていますが、これはどのロケールでも'DEC'はMONに有効な値ではないためです。
デフォルト日付書式の文字値が日付式に使用されている場合は、自動的に日付値に変換されます。
時刻要素を含めずに日付値を指定した場合、デフォルトの時刻として午前0時に設定されます。日付を含めずに日付値を指定した場合、デフォルトの日付として現在の月の第1日に設定されます。
Oracle DatabaseのDATE列には、常に日付と時刻の両方のフィールドが含まれます。時刻部分を指定せずに問合せに日付書式を使用する場合は、DATE列の時刻フィールドを午前0時に設定する必要があります。TRUNC(date)SQL関数を使用すると、時刻フィールドを確実に午前0時に設定できます。また、問合せを使用して等価性または非等価性(=または!=)のかわりに大小の関係(<、<=、>=または>)のテストもできます。そうでない場合、Oracle Databaseは、正しい結果を戻さない場合があります。
|
関連項目:
|
TIMESTAMPデータ型は、DATEデータ型の拡張です。年、月、日、時間、分および秒の値が格納されます。DATEデータ型では格納されない小数秒も格納されます。
TIMESTAMPデータ型は次のように指定します。
TIMESTAMP [(fractional_seconds_precision)]
fractional_seconds_precisionはオプションで、SECOND日時フィールドの小数部の桁数を指定します。範囲0から9の数値を指定できます。デフォルトは6です。
たとえば、'26-JUN-02 09:39:16.78'は16.78秒を示します。78は2桁のため、小数秒の精度は2です。
TIMESTAMPリテラルは、次のような書式で指定できます。
TIMESTAMP 'YYYY-MM-DD HH24:MI:SS.FF'
この例に示す書式を使用して、次のようにTIMESTAMPをリテラルとして指定します。
TIMESTAMP '1997-01-31 09:26:50.12'
NLS_TIMESTAMP_FORMAT初期化パラメータの値により、文字列からTIMESTAMPデータ型への変換時のタイムスタンプ書式が決定されます。NLS_DATE_LANGUAGEにより、MONなど、文字データの使用言語が決定されます。
|
関連項目:
|
TIMESTAMP WITH TIME ZONEはTIMESTAMPのバリアントで、値にはタイム・ゾーン・リージョン名またはタイム・ゾーン・オフセットが含まれます。タイム・ゾーン・オフセットは、ローカル時間とUTC(協定世界時、以前のグリニッジ標準時)との時差(時間および分単位)です。TIMESTAMP WITH TIME ZONEデータ型は次のように指定します。
TIMESTAMP [(fractional_seconds_precision)] WITH TIME ZONE
fractional_seconds_precisionはオプションで、SECOND日時フィールドの小数部の桁数を指定します。
TIMESTAMP WITH TIME ZONEは、次のようにリテラルとして指定できます。
TIMESTAMP '1997-01-31 09:26:56.66 +02:00'
2つのTIMESTAMP WITH TIME ZONE値がUTCで同じ時刻を表している場合は、データに格納されているTIME ZONEのオフセットに関係なく同一とみなされます。たとえば、次の2つの式の値は同じです。
TIMESTAMP '1999-01-15 8:00:00 -8:00' TIMESTAMP '1999-01-15 11:00:00 -5:00'
UTCオフセットはTZR(タイム・ゾーン・リージョン)書式要素で置き換えることができます。次の式は、タイム・ゾーン・リージョンにAmerica/Los_Angelesを指定しています。
TIMESTAMP '1999-01-15 8:00:00 America/Los_Angeles'
標準時間から夏時間への切替時に境界を明確にするには、TZR書式要素および対応するTZD書式要素の両方を使用します。TZD書式要素は、夏時間情報を含むタイム・ゾーン・リージョンの略称です。たとえば、米国太平洋標準時間の場合はPST、米国太平洋夏時間の場合はPDTです。次のように指定すると、確実に夏時間の値が戻されます。
TIMESTAMP '1999-10-29 01:30:00 America/Los_Angeles PDT'
ERROR_ON_OVERLAP_TIMEセッション・パラメータをTRUEに設定していて、TZD書式要素を追加しない場合、日時の値が不明確な場合はエラーが戻されます。ERROR_ON_OVERLAP_TIMEがFALSE(デフォルト値)に設定されている場合、あいまいな日時は標準時間として解析されます。
TIMESTAMP WITH TIME ZONEデータ型のデフォルトの日付書式は、NLS_TIMESTAMP_TZ_FORMAT初期化パラメータの値により決定されます。
|
関連項目:
|
TIMESTAMP WITH LOCAL TIME ZONEはTIMESTAMPのもう1つのバリアントです。TIMESTAMP WITH TIME ZONEとは異なり、データベースに格納されるデータはデータベース・タイムゾーンに対して正規化され、タイムゾーン・オフセッは列データの一部として格納されません。ユーザーがデータを検索すると、そのユーザーのローカル・セッションのタイム・ゾーンで戻されます。タイム・ゾーン・オフセットは、ローカル時間とUTC(協定世界時、以前のグリニッジ標準時)との時差(時間および分単位)です。
TIMESTAMP WITH LOCAL TIME ZONEデータ型は次のように指定します。
TIMESTAMP [(fractional_seconds_precision)] WITH LOCAL TIME ZONE
fractional_seconds_precisionはオプションで、SECOND日時フィールドの小数部の桁数を指定します。
TIMESTAMP WITH LOCAL TIME ZONEのリテラルはありませんが、TIMESTAMP WITH LOCAL TIME ZONE列にTIMESTAMPリテラルとTIMESTAMP WITH TIME ZONEリテラルを挿入できます。
TIMESTAMP WITH LOCAL TIME ZONEデータ型のデフォルトの日付書式は、NLS_TIMESTAMP_FORMAT初期化パラメータの値により決定されます。
|
関連項目:
|
適切なNLS書式値に基づく書式を使用した文字列の挿入
リテラルの挿入
暗黙的な変換の実行対象となるリテラルの挿入
TO_TIMESTAMP、TO_TIMESTAMP_TZまたはTO_DATE SQL関数の使用
次の例に、日時データ型にデータを挿入する方法を示します。
例4-1 DATE列へのデータの挿入
日付書式を設定します。
SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS';
c_id列とc_dt列を含むtable_dt表を作成します。c_id列はNUMBERデータ型で、データの入力方法を識別できます。c_dt列はDATEデータ型です。
SQL> CREATE TABLE table_dt (c_id NUMBER, c_dt DATE);
日付を文字列として挿入します。
SQL> INSERT INTO table_dt VALUES(1, '01-JAN-2003');
同じ日付をDATEリテラルとして挿入します。
SQL> INSERT INTO table_dt VALUES(2, DATE '2003-01-01');
同じ日付をTIMESTAMPリテラルとして挿入します。タイム・ゾーン情報は削除されます。
SQL> INSERT INTO table_dt VALUES(3, TIMESTAMP '2003-01-01 00:00:00 America/Los_Angeles');
TO_DATE関数を使用して同じ日付を挿入します。
SQL> INSERT INTO table_dt VALUES(4, TO_DATE('01-JAN-2003', 'DD-MON-YYYY'));
データを表示します。
SQL> SELECT * FROM table_dt; C_ID C_DT ---------- -------------------- 1 01-JAN-2003 00:00:00 2 01-JAN-2003 00:00:00 3 01-JAN-2003 00:00:00 4 01-JAN-2003 00:00:00
例4-2 TIMESTAMP列へのデータの挿入
タイムスタンプ書式を設定します。
SQL> ALTER SESSION SET NLS_TIMESTAMP_FORMAT='DD-MON-YY HH:MI:SSXFF';
c_id列とc_ts列を含むtable_ts表を作成します。c_id列はNUMBERデータ型で、データの入力方法を識別できます。c_ts列はTIMESTAMPデータ型です。
SQL> CREATE TABLE table_ts(c_id NUMBER, c_ts TIMESTAMP);
日付と時刻を文字列として挿入します。
SQL> INSERT INTO table_ts VALUES(1, '01-JAN-2003 2:00:00');
同じ日付および時刻をTIMESTAMPリテラルとして挿入します。
SQL> INSERT INTO table_ts VALUES(2, TIMESTAMP '2003-01-01 2:00:00');
同じ日付および時刻をTIMESTAMP WITH TIME ZONEリテラルとして挿入します。値はTIMESTAMP値に変換されます。つまり、タイム・ゾーン情報が削除されます。
SQL> INSERT INTO table_ts VALUES(3, TIMESTAMP '2003-01-01 2:00:00 -08:00');
データを表示します。
SQL> SELECT * FROM table_ts; C_ID C_TS ---------- ----------------------------- 1 01-JAN-03 02:00:00.000000 AM 2 01-JAN-03 02:00:00.000000 AM 3 01-JAN-03 02:00:00.000000 AM
この3つの方法では、いずれも同じ値が格納されることに注意してください。
例4-3 TIMESTAMP WITH TIME ZONEデータ型へのデータの挿入
タイムスタンプ書式を設定します。
SQL> ALTER SESSION SET NLS_TIMESTAMP_TZ_FORMAT='DD-MON-RR HH:MI:SSXFF AM TZR';
タイム・ゾーンを'-07:00'に設定します。
SQL> ALTER SESSION SET TIME_ZONE='-7:00';
c_id列とc_tstz列を含むtable_tstz表を作成します。c_id列はNUMBERデータ型で、データの入力方法を識別できます。c_tstz列はTIMESTAMP WITH TIME ZONEデータ型です。
SQL> CREATE TABLE table_tstz (c_id NUMBER, c_tstz TIMESTAMP WITH TIME ZONE);
日付と時刻を文字列として挿入します。
SQL> INSERT INTO table_tstz VALUES(1, '01-JAN-2003 2:00:00 AM -07:00');
同じ日付および時刻をTIMESTAMPリテラルとして挿入します。値はTIMESTAMP WITH TIME ZONEリテラルに変換されます。つまり、TIMESTAMP値にセッションのタイム・ゾーンが追加されます。
SQL> INSERT INTO table_tstz VALUES(2, TIMESTAMP '2003-01-01 2:00:00');
同じ日付および時刻をTIMESTAMP WITH TIME ZONEリテラルとして挿入します。
SQL> INSERT INTO table_tstz VALUES(3, TIMESTAMP '2003-01-01 2:00:00 -8:00');
データを表示します。
SQL> SELECT * FROM table_tstz; C_ID C_TSTZ ---------- ------------------------------------ 1 01-JAN-03 02:00.00:000000 AM -07:00 2 01-JAN-03 02:00:00.000000 AM -07:00 3 01-JAN-03 02:00:00.000000 AM -08:00
方法3の場合はタイム・ゾーンが異なることに注意してください。これは、TIMESTAMP WITH TIME ZONEリテラルの一部としてタイム・ゾーン情報が指定されているためです。
例4-4 TIMESTAMP WITH LOCAL TIME ZONEデータ型へのデータの挿入
タイム・ゾーンがUTC-7である米国コロラド州デンバーで入力されるデータを考えます。
SQL> ALTER SESSION SET TIME_ZONE='-07:00';
c_id列とc_tsltz列を含むtable_tsltz表を作成します。c_id列はNUMBERデータ型で、データの入力方法を識別できます。c_tsltz列はTIMESTAMP WITH LOCAL TIME ZONEデータ型です。
SQL> CREATE TABLE table_tsltz (c_id NUMBER, c_tsltz TIMESTAMP WITH LOCAL TIME ZONE);
日付と時刻を文字列として挿入します。
SQL> INSERT INTO table_tsltz VALUES(1, '01-JAN-2003 2:00:00');
同じデータをTIMESTAMP WITH LOCAL TIME ZONEリテラルとして挿入します。
SQL> INSERT INTO table_tsltz VALUES(2, TIMESTAMP '2003-01-01 2:00:00');
同じデータをTIMESTAMP WITH TIME ZONEリテラルとして挿入します。データはTIMESTAMP WITH LOCAL TIME ZONE値に変換されます。つまり、入力したタイム・ゾーン(-08:00)はセッションのタイム・ゾーン値(-07:00)に変換されます。
SQL> INSERT INTO table_tsltz VALUES(3, TIMESTAMP '2003-01-01 2:00:00 -08:00');
データを表示します。
SQL> SELECT * FROM table_tsltz; C_ID C_TSLTZ ---------- ------------------------------------ 1 01-JAN-03 02.00.00.000000 AM 2 01-JAN-03 02.00.00.000000 AM 3 01-JAN-03 03.00.00.000000 AM
時間が2から3に変更され、UTC-8として入力した情報がローカル・タイム・ゾーンに変更されていることに注意してください。
TIMESTAMPデータ型は、イベントの時間を記録する日時値(タイム・ゾーンなし)が必要な場合に使用します。たとえば、組立ラインの作業場にいる従業員がタイムカードに出社と退社を記録した時刻情報を格納できます。これは常にローカル時刻であるため、タイムゾーンの部分を保存する必要がありません。TIMESTAMPデータ型では、格納に7バイトまたは11バイトが使用されます。
TIMESTAMP WITH LOCAL TIME ZONEデータ型を使用するのは、日時値が指定されたローカル時刻を表す場合、またはタイム・ゾーン情報を値で記録する必要がある場合です。ローカル時間で設定された予定を考えます。夏時間ルールなどのタイム・ゾーン定義が変更された場合、指定ローカル日時を調整する必要があります。調整しないと、値が不正確になります。このデータ型は、そのような影響をほとんど受けません。
TIMESTAMP WITH TIME ZONEデータ型では、タイム・ゾーン情報が格納されるため、データの格納にTIMESTAMPおよびTIMESTAMP WITH LOCAL TIME ZONEデータ型よりも2バイト多い13バイトが必要です。タイム・ゾーンは、タイム・ゾーン・リージョン名またはUTCからのオフセットとして格納されます。データはそのまま表示または計算に使用でき、追加の処理は必要ありません。TIMESTAMP WITH TIME ZONE列は主キーとして使用できません。TIMESTAMP WITH TIME ZONE列で索引が作成されると、ファンクション索引となります。
TIMESTAMP WITH LOCAL TIME ZONEデータ型は、タイム・ゾーン情報のないタイムスタンプの格納に使用されます。データは、クライアントとの間でやり取りされるたびにデータベースのタイム・ゾーンに対して正規化されます。格納には11バイトが必要です。
TIMESTAMP WITH LOCAL TIME ZONEデータ型は、元のタイム・ゾーンは重要ではないが、イベントの相対時刻が重要で、夏時間を正確に調製する必要がない場合に適しています。データベースのタイム・ゾーン間でこのデータ型が実行するタイム・ゾーン変換は、夏時間調整により非対称です。このデータ型はタイム・ゾーン情報を維持しないため、夏時間と標準時間のいずれであるか、秋の調整で近接する値を区別しません。個別のインスタンス間の混合により、ユーザーの通常の作業時間内に調整が発生する場合は特に、アプリケーションが予期しない動作をします。
夏時間への移行日が頻繁に更新され期間も変則的なブラジルやイスラエルなどは、特にタイム・ゾーン調整の問題の影響を受けやすいリージョンです。これらの地域からの時間情報がキーとなるアプリケーションの場合は、別の日時データ型の利用を考慮できます。
期間データ型は、期間の格納に使用されます。主な用途は分析関数です。たとえば、株価の移動平均の計算に使用できます。特定のパーセンタイルに対応する値を判別するには、期間データ型を使用する必要があります。また、期間データ型は履歴表の更新にも使用できます。
この項の内容は、次のとおりです。
|
関連項目: 移動平均や逆パーセンタイルなどの分析関数の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。 |
INTERVAL YEAR TO MONTHでは、YEARおよびMONTH日時フィールドを使用して期間が格納されます。INTERVAL YEAR TO MONTHは次のように指定します。
INTERVAL YEAR [(year_precision)] TO MONTH
year_precisionは、YEAR日時フィールドの桁数です。有効範囲は0から9です。year_precisionのデフォルト値は2です。
時間隔値は、リテラルとして指定できます。時間隔リテラルを指定するには様々な方法があります。次に、123年と2か月という時間隔を指定する例を示します。年の精度は3です。
INTERVAL '123-2' YEAR(3) TO MONTH
|
関連項目: INTERVAL YEAR TO MONTHデータ型を使用して時間隔リテラルを指定する方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
INTERVAL DAY TO SECONDでは、期間が日、時間、分および秒単位で格納されます。このデータ型は次のように指定します。
INTERVAL DAY [(day_precision)] TO SECOND [(fractional_seconds_precision)]
day_precisionは、DAY日時フィールドの桁数です。有効範囲は0から9です。デフォルト値は2です。
fractional_seconds_precisionは、SECOND日時フィールドの小数部の桁数です。有効範囲は0から9です。デフォルトは6です。
次に、4日、5時間、12分、10秒および0.222秒の時間隔を指定する一例を示します。小数秒の精度は3です。
INTERVAL '4 5:12:10.222' DAY TO SECOND(3)
時間隔値は、リテラルとして指定できます。時間隔リテラルを指定するには様々な方法があります。
|
関連項目: INTERVAL DAY TO SECONDデータ型を使用して時間隔リテラルを指定する方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
時間隔をリテラルとして挿入します。次に例を示します。
INSERT INTO table1 VALUES (INTERVAL '4-2' YEAR TO MONTH);
この文では、4年と2か月という期間が挿入されます。
Oracle Databaseでは、他のANSI期間型のリテラルが認識され、Oracle Databaseの時間隔値に変換されます。
NUMTODSINTERVAL、NUMTOYMINTERVAL, TO_DSINTERVALおよびTO_YMINTERVAL SQL関数を使用します。
この項の内容は、次のとおりです。
日付(DATE)、タイムスタンプ(TIMESTAMP、TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONE)および時間隔(INTERVAL DAY TO SECOND、INTERVAL YEAR TO MONTH)の各データに対する演算操作を実行できます。タイムスタンプ・データ型を期間データ型と併用すると、演算操作で最大精度を維持できます。
日付値とタイムスタンプ値に対する演算操作には、NUMBER定数を使用できます。タイムスタンプ値はOracleで内部的に日付値に変換されてから、NUMBER定数を使用して演算操作が実行されます。これは、日付値とタイムスタンプ値の両方を含む操作中には、小数秒に関する情報が失われることを意味します。日時式および時間隔式では、NUMBER定数が日数として解析されます。
各DATE値には、時間要素が含まれます。多くの日付操作の結果には、小数部があります。この小数部は、1日の一部分を表します。たとえば、1.5日は36時間です。DATEデータに対する一般的な操作では、これらの小数部もOracle Databaseの組込みSQL関数により戻されます。たとえば、組込みMONTHS_BETWEEN SQL関数は、2つの日付間の月数を戻します。結果の小数部は、大の月である1か月のうちの該当部分を表します。
Oracleデータベースでは、すべてのタイムスタンプ演算がUTC時間で実行されます。TIMESTAMP WITH LOCAL TIME ZONEデータの場合は、日時値がデータベースのタイム・ゾーンからUTCに変換され、演算の実行後にデータベースのタイム・ゾーンに逆変換されます。TIMESTAMP WITH TIME ZONEデータの場合、日時値には常にUTCが使用されるため、変換は必要ありません。
|
関連項目:
|
日付値とタイムスタンプ値を比較する場合、Oracleデータベースではデータが高精度のデータ型に変換されてから比較されます。たとえば、TIMESTAMP WITH TIME ZONEデータ型のデータをTIMESTAMPデータ型のデータと比較する場合は、セッションのタイム・ゾーンを使用してTIMESTAMPデータがTIMESTAMP WITH TIME ZONEに変換されます。
日付およびタイムスタンプ・データの変換の優先順位は次のとおりです。
DATE
TIMESTAMP
TIMESTAMPWITHLOCALTIMEZONE
TIMESTAMPWITHTIMEZONE
どのデータ型のペアの場合も、優先順位リストで小さい番号を持つデータ型が、大きい番号を持つデータ型に変換されます。
日時データ型を明示的に変換する場合は、CAST SQL関数を使用します。DATE、TIMESTAMP、TIMESTAMP WITH TIME ZONEおよびTIMESTAMP WITH LOCAL TIME ZONEを、前述のリストに示した他のデータ型に明示的に変換できます。
|
関連項目: 『Oracle Database SQL言語リファレンス』 |
日時関数は、日付(DATE)、タイムスタンプ(TIMESTAMP、TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONE)および時間隔(INTERVAL DAY TO SECOND、INTERVAL YEAR TO MONTH)の値を処理します。
日時関数の一部は、Oracle DatabaseのDATEデータ型用に設計されています。引数としてタイムスタンプ値を指定すると、Oracle Databaseでは内部的に入力の型がDATE値に変換されます。ROUNDおよびTRUNC関数の場合、内部変換は実行されません。
表4-1に、OracleのDATEデータ型用に設計されている日時関数を示します。この表には、各関数の詳細へのクロス・リファレンスが含まれます。
表4-1 DATEデータ型用に設計された日時関数
表4-2に、その他の日時関数と詳細説明へのクロス・リファレンスを示します。
表4-2 その他の日時関数
表4-3に、夏時間(DST)アップグレード・プロセスで使用する関数を示します。これらの関数は、準備ウィンドウまたは更新ウィンドウでのみ使用できます。詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
|
関連項目: 『Oracle Database SQL言語リファレンス』 |
この項の内容は、次のとおりです。
表4-4に、日時書式パラメータの名前と説明を示します。
表4-4 日時書式パラメータ
| パラメータ | 説明 |
|---|---|
|
|
|
|
|
|
|
|
|
デフォルト値はNLS_TERRITORYから導出されます。
値は、初期化パラメータ・ファイル内で設定することで指定できます。初期化パラメータ・ファイル内の値を変更する場合、インスタンスを再起動して変更を有効にする必要があります。クライアントの場合は、値をクライアント環境変数として指定することもできます。Javaクライアントの場合、NLS_TERRITORYの値はJREのデフォルト・ロケールから導出されます。初期化パラメータ・ファイルに指定されている値は、JDBCセッションで使用されません。
セッション中に値を変更するには、ALTER SESSION文を使用します。
ORA_TZFILE。クライアントおよびOracle Databaseサーバー上でタイム・ゾーンを指定できます。Oracle DatabaseサーバーでORA_TZFILEを指定した場合、この環境変数が有効になるのはデータベースの作成時のみです。
ORA_SDTZ。デフォルトのセッション・タイム・ゾーンを指定します。
ERROR_ON_OVERLAP_TIMEは、Oracle Databaseによる不明確な日時境界値の処理方法を決定するセッション・パラメータです。不明確な日時値は、夏時間と標準時間の間の切替時に発生することがあります。
可能な値はTRUEとFALSEです。ERROR_ON_OVERLAP_TIMEがTRUEの場合は、不明確な日時値が検出されるとエラーが戻されます。ERROR_ON_OVERLAP_TIMEがFALSEの場合、不明確な日時値は標準時間とみなされます。デフォルト値はFALSEです。
DST_UPGRADE_INSERT_CONVは、夏時間(DST)アップグレード・プロセスのアップグレード・ウィンドウでのみ使用する初期化パラメータです。これは、DSTのアップグレードで変更されるTIMESTAMP WITH TIME ZONE列のある表にのみ適用されます。
(DBMS_DSTパッケージで説明されている)DSTパッチ適用プロセスのアップグレード・ウィンドウでは、TIMESTAMP WITH TIMEZONEデータを含む表に対する新規タイム・ゾーン・バージョンへの変換が行われます。まだ変換されていない表の列には、前のタイム・ゾーン・バージョンを反映するTIMESTAMP WITH TIMEZONEが残っています。SELECT文の発行時に、これらの列のデータを新規タイム・ゾーン・バージョンに変換済であるかのように表すために、新規バージョンに変換するための変換演算子がこれらの列にデフォルトで追加されます。ただし、変換演算子を追加すると、問合せ速度が低下してTIMESTAMP WITH TIMEZONE列で索引が使用できなくなることがあります。そのため、OracleにはパラメータDST_UPGRADE_INSERT_CONVが用意されています。このパラメータは、まだアップグレードされていない表のTIMESTAMP WITH TIMEZONE列の上に内部演算子を割り当てるかどうかを指定します。デフォルト値はTRUEです。この変換プロセスがTIMESTAMP WITH TIMEZONE列に影響しないことが明らかな場合は、このパラメータをFALSEに設定してかまいません。
DSTパッチ適用プロセス全体で、このパラメータをTRUEに設定することをお薦めします。デフォルトではTRUEに設定されています。ただし、TRUEに設定すると、未変換の表に対する問合せのパフォーマンスが低下する可能性があります。これは、アップグレード・ウィンドウについてのみ該当することに注意してください。
|
関連項目:
|
Oracle Databaseタイム・ゾーン・ファイルには、有効なタイム・ゾーン名が含まれています。タイム・ゾーンごとに次の情報も含まれています。
協定世界時(UTC)からのオフセット。
夏時間への移行時間。
標準時間と夏時間の略称。
Oracle Databaseでは複数のバージョンのタイム・ゾーン・ファイルが提供されており、互いに関連付けられている2種類のファイルがあります。1つはデータベースで定義されているすべてのタイム・ゾーンを含む大きなファイルで、もう1つは最も一般的に使用されるタイム・ゾーンのみを含む小さいファイルです。大きいバージョンはtimezlrg_<version_number>.dat、小さいバージョンはtimezone_<version_number>.datと指定されます。ファイルはOracle Databaseホーム・ディレクトリのoracore/zoneinfoサブディレクトリにあるため、たとえば、デフォルトのタイム・ゾーン・ファイルはこのサブディレクトリの最上位バージョンのタイム・ゾーンになります。たとえば、Oracle Database 11gリリース2では、デフォルト・ファイルは$ORACLE_HOME/oracore/zoneinfo/timezlrg_14.datで、このファイルにデータベースで定義されているすべてのタイム・ゾーンが含まれます。
タイム・ゾーン・ファイルの例を次に示します。
$ORACLE_HOME/oracore/zoneinfo/timezlrg_4.dat -- large version 4 $ORACLE_HOME/oracore/zoneinfo/timezone_4.dat -- small version 4 $ORACLE_HOME/oracore/zoneinfo/timezlrg_5.dat -- large version 5 $ORACLE_HOME/oracore/zoneinfo/timezone_5.dat -- small version 5
データベース作成プロセスでは、サーバーのタイム・ゾーン・バージョンを選択します。このバージョンは固定ですが、アップグレード・プロセスを実行してより新しいバージョンにすることは可能です。異なるバージョンのタイム・ゾーン・ファイルをクライアントとサーバーで使用できますが、これは行わないことをお薦めします。あるバージョンのクライアントと別のバージョンのサーバー間の通信には、パフォーマンス・ペナルティがあるためです。TIMESTAMP WITH TIME ZONE(TSTZ)データがUTCではなくローカル・タイムスタンプを使用して転送されるため、パフォーマンス・ペナルティが発生します。
サーバー側では、Oracle Databaseには常に大きいファイルが使用されます。クライアント側では、大きいファイルまたは小さいファイルのいずれかを使用できます。クライアントで大きいタイム・ゾーン・ファイルを使用している場合は、小さいファイルに切り替えたときに情報が失われないことが確実である場合を除き、引き続き大きいファイルを使用する必要があります。小さいファイルを使用する場合、クライアントで小さいタイム・ゾーン・ファイルに存在しないデータを問い合せることがないことを確認してください。問い合せた場合、エラーが発生します。
クライアントまたはサーバーの特定のタイム・ゾーン・ファイルを有効にして使用できます。2つの状況で、サーバーのタイム・ゾーン・ファイルを有効にする場合があります。1つは、ターゲット・バージョンへのタイム・ゾーンのアップグレードを実行する場合です。詳細は、「タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード」を参照してください。もう1つは、新しいデータベースを作成する際に、選択したタイム・ゾーン・ファイルを指すようにORA_TZFILE環境変数を設定する場合です。
クライアント上の特定のタイム・ゾーン・ファイルを有効にするには、ORA_TZFILEを、必要なタイム・ゾーン・ファイルに設定します。ORA_TZFILEを設定しない場合、Oracle Databaseでは、最新バージョンのタイム・ゾーン・ファイルが自動的に選択されて使用されます。クライアントで夏時間をアップグレードする方法の詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。
Oracleデータベースのタイム・ゾーン・データは、ftp://elsie.nci.nih.gov/pub/で使用可能な公開情報から導出されます。Oracleデータベースのタイム・ゾーン・データには、このサイトから入手可能な最新データが反映されていない場合があります。
次の文を入力すると、データベースとともにインストールされるタイム・ゾーン・ファイルからタイム・ゾーンの名前と略称のリストを取得できます。
SELECT TZNAME, TZABBREV FROM V$TIMEZONE_NAMES ORDER BY TZNAME, TZABBREV;
デフォルトのタイム・ゾーン・ファイルの場合、この文の出力は次のようになります。
TZNAME TZABBREV -------------------- ---------- Africa/Abidjan GMT Africa/Abidjan LMT ... Africa/Algiers CEST Africa/Algiers CET Africa/Algiers LMT Africa/Algiers PMT Africa/Algiers WET Africa/Algiers WEST ... WET LMT WET WEST WET WET 2137 rows selected.
上の出力では、Africa/Abidjanタイム・ゾーンには2つのタイム・ゾーン略称が、またAfrica/Algiersタイム・ゾーンには6つの略称が関連付けられています。次の表に、タイム・ゾーン略称の一部とその意味を示します。
| タイム・ゾーン略称 | 意味 |
|---|---|
| LMT | ローカル標準時間 |
| PMT | パリ標準時間 |
| WET | 西ヨーロッパ時間 |
| WEST | 西ヨーロッパ夏時間 |
| CET | 中央ヨーロッパ時間 |
| CEST | 中央ヨーロッパ夏時間 |
| EET | 東ヨーロッパ時間 |
| EEST | 東ヨーロッパ夏時間 |
1つの略称が複数のタイム・ゾーンに関連付けられている場合があるため注意してください。たとえば、CETは、ヨーロッパのタイム・ゾーンに加えてAfrica/AlgiersとAfrica/Casablancaの両方に関連付けられています。
略称ごとにタイム・ゾーン名が繰り返されないタイム・ゾーン・リストが必要な場合は、次の問合せを使用します。
SELECT UNIQUE TZNAME FROM V$TIMEZONE_NAMES;
たとえば、バージョン11には次のような出力が含まれます。
TZNAME -------------------- Africa/Addis_Ababa Africa/Bissau Africa/Ceuta ... Turkey US/East-Indiana US/Samoa
デフォルトのタイム・ゾーン・ファイルには、350を超える一意のタイム・ゾーン名が含まれています。小さいタイム・ゾーン・ファイルには、180を超える一意のタイム・ゾーン名が含まれています。
|
関連項目:
|
Oracle Databaseによって提供されるタイム・ゾーン・ファイルを定期的に更新して、様々なタイム・ゾーン・リージョンに対する変更を反映します。データベースで現在使用しているタイム・ゾーン・ファイルを特定するには、V$TIMEZONE_FILEを問い合せます。
|
注意: Oracle Database 9iには、タイム・ゾーン・ファイルのバージョン1が、Oracle Database 10gにはバージョン2が含まれています。Oracle Database 11gリリース2には、バージョン1から14のすべてのタイム・ゾーン・ファイルが含まれています。これらのリリースでそれぞれ提供されている各種のパッチおよびパッチ・セットにより、タイム・ゾーン・ファイルのバージョンも更新できます。 |
夏時間の実施の時期や方法に関する規則の変更は、政府が行います。政府による変更が行われると、Oracleでは、タイム・ゾーン・データ付きタイムスタンプを処理するための、一連の新規移行ルールを提供します。
夏時間が開始または終了する移行期には、タイム・ゾーン・データ付きタイムスタンプを処理する際に、問題(データ消失など)が発生する可能性があります。そのため、移行の処理には一定のルールがあり、このリリースではこれらの移行ルールが変更されています。さらに、DBMS_DSTという新しいパッケージを提供することで、この移行の処理方法が大幅に改善されました。
Oracle DatabaseはTIMESTAMP WITH TIME ZONEデータ型のデータを内部的に格納するため、DST移行ルールに対する変更は、このデータ型の既存データに影響を与える可能性があります。ユーザーがタイム・ゾーン付きのタイムスタンプを入力すると、Oracle Databaseは、そのタイム・ゾーンの移行ルールに基づいて、そのデータをUTCに変換し、元のタイム・ゾーンIDとともに、そのデータをディスクに格納します。データを取り出すときは、UTCからの逆変換が起こります。たとえば、バージョン2の移行ルールを適用した場合、TIMESTAMP '2007-11-02 12:00:00 America/Los_Angeles'は、UTCの値'2007-11-02 20:00:00'と'America/Los_Angeles'のタイム・ゾーンIDとして格納されます。ロサンゼルス時間は、UTC-8時間(PST)です。バージョン3の移行ルールの場合、同じ日のオフセットは-7時間(PDT)です。2007年から、DSTの有効期間は今までよりも長くなりました(11月の第1日曜日、つまり2007年は11月4日まで)。先ほどのタイムスタンプをユーザーが取り出すと、格納されていたUTC時間に新しいオフセットが適応され、TIMESTAMP '2007-11-02 13:00:00 America/Los_Angeles'になります。以前のデータとバージョン3が適用されたデータの間には1時間の差があります。
DBMS_DSTパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
|
注意: 移行ルールが更新されているタイム・ゾーン・リージョンの場合、この「タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード」全体で説明したアップグレード・プロセスは、該当するDSTルール変更の有効日よりも未来を示すタイムスタンプに対してのみ影響します。たとえば、2007年よりも前のタイムスタンプには、'America/Los_Angeles'タイム・ゾーン・リージョンのバージョン3による影響はありません。 |
データを実際にアップグレードする前に、アップグレードの影響がどの程度であるか確認する必要があります。一般に、アップグレード・プロセスでは、2つの個別のサブプロセスを考慮できます。1つ目は準備ウィンドウの作成、2つ目はアップグレード・ウィンドウの作成です。準備ウィンドウはデータベースで更新が必要なデータの量を確認する時間、アップグレード・ウィンドウは実際にアップグレードが発生する時間です。
必須でなければ、準備ウィンドウ・ステップを実行することをお薦めします。アップグレードの際に変更するデータ量の確認に加えて、アップグレードに必要な時間を見積ることができ、発生する可能性のあるセマンティック・エラーも発見できます。「タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード時のエラー処理」を参照してください。
準備ウィンドウを作成し、次のステップを実行して影響を受けるデータを確認できます。
後で$ORACLE_HOME/oracore/zoneinfoへ移行する必要な(最新の)タイム・ゾーン・ファイルをインストールします。必要な(最新の)バージョンのtimezlrg_<version_number>.datは必須であり、timezone_<version_number>.datも必要に応じて追加できます。これらのファイルは、My Oracle Supportで入手できます。
オプションで、DBMS_DST.CREATE_ERROR_TABLEおよびDBMS_DST.CREATE_AFFECTED_TABLEをそれぞれ使用して、エラー表、および影響を受けるタイムスタンプとタイム・ゾーン情報の表を作成できます。作成しない場合、Oracle Databaseでは事前作成済のsys.dst$affected_tablesおよびsys.dst$error_tableが使用されます。これらの表は、ステップ4で使用します。
EXEC DBMS_DST.CREATE_AFFECTED_TABLE('my_affected_tables');
EXEC DBMS_DST.CREATE_ERROR_TABLE('my_error_table');
DBMS_DST.BEGIN_PREPARE(<new_version)を起動します。これは、ステップ1で選択したバージョンです。DBMS_DST権限情報の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
DBMS_DST.FIND_AFFECTED_TABLESを起動して影響を受けるデータをチェックし、sys.dst$affected_tablesを問い合せて影響を受ける列を検証します。また、sys.dst$affected_tables.error_countで可能性のあるエラーをチェックすることが特に重要です。エラー件数が1以上の場合、sys.dst$error_tableをチェックして、アップグレードで発生する可能性のあるエラーの種類を確認できます。「タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード時のエラー処理」を参照してください。
DBMS_DST.END_PREPAREを起動して、準備ウィンドウを終了します。
|
注意: 準備ウィンドウで一度に実行できるDBAは、1つのみです。また、アップグレードを実行する前に、すべてのエラーを修正する必要があります。 |
|
注意: タイム・ゾーン・ファイルを更新するために使用可能なパッチのマトリクスは、My Oracle Support(http://support.oracle.com)のDocument ID 412160.1を参照してください。 |
タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプをアップグレードする手順は、次のとおりです。
timezlrg_<version_number>.datの必要な(最新の)バージョンをダウンロードしていない場合はダウンロードし、$ORACLE_HOME/oracore/zoneinfoにインストールします。また、オプションで、timezone_<version_number>.datをMy Oracle Supportからダウンロードし、同じ場所に置きます。
データベースを停止します。Oracle RACでは、すべてのインスタンスを停止します。
UPGRADEモードで、データベースを起動します。Oracle RACでは、1つのインスタンスのみを起動してください。UPGRADEモードの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。
DBMS_DST.BEGIN_UPGRADE(<new_version>)を実行します。タイム・ゾーン・データ付きタイムスタンプを含むディクショナリ表のアップグレードで、セマンティック・エラーが無視されないようにする場合は、TRUEに指定できる他の2つのパラメータをオプションで使用できます。パラメータのいずれか、または両方にTRUEを指定すると、デフォルトで、エラーはsys.dst$error_tableに移入されます。この場合、BEGIN_UPGRADEプロシージャを開始する前に、エラー表を切り捨てることがあります。詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
BEGIN_UPGRADEの実行が失敗すると、ORA-56927エラー(アップグレード・ウィンドウの起動に失敗しました)が発生します。
BEGIN_UPGRADEの実行がエラーで終了した後、sys.dst$error_tableをチェックして、ディクショナリ変換が成功しているかどうかを判別します。成功した場合、表内に行はありません。エラーが発生した場合、手動でエラーを修正し、DBMS_DST.BEGIN_UPGRADE(<new_version>)を再実行します。「タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード時のエラー処理」を参照してください。
データベースを通常のモードで再起動します。
エラーおよびトリガー表(デフォルトでは、sys.dst$error_tableおよびsys.dst$trigger_table)を切り捨てます。
トリガー表では、アップグレード・プロセス中に無効化されたTSTZ表トリガーが記録されます。これは、DBMS_DST.UPGRADE_*プロシージャのパラメータとして渡されます。DBMS_DST.CREATE_TRIGGER_TABLEをコールして、オプションで独自のトリガー表を作成できます。DBMS_DST.UPGRADE_*の際、Oracle Databaseでは、影響を受けるTSTZデータのアップグレードを実行する前に、まずTSTZ表上のトリガーが無効になります。Oracle Databaseでは、sys.dst$trigger_table内の無効にされたトリガーの情報も保存されます。表内の影響を受けるTSTZデータのアップグレードの終了後、これらの無効化されたトリガーは、sys.dst$trigger_tableから読み込まれて有効になり、sys.dst$trigger_tableから削除されます。アップグレード・プロセス中にインスタンスが予期せず停止するなどの致命的エラーが発生した場合、sys.dst$trigger_tableをチェックして、アップグレードする前のアクティブな以前の状態に戻っていないトリガーがないかを確認します。
DBMS_DST.UPGRADE_DATABASEを起動して、すべての表内のTSTZデータをアップグレードします。
「夏時間動作の更新の例」で示されるDBA_TSTZ_TABLESビューを問い合せ、すべての表でアップグレードが終了しているかどうか確認します。次に、dst$error_tableでエラーがないかどうか確認します。エラーが発生した場合、エラーを修正し、関係する表でDBMS_DST.UPGRADE_TABLEを再実行します。発生したエラーが重要でない場合は、エラーが無視されるようにパラメータを設定して、再実行します。
DBMS_DST.END_UPGRADEを起動して、アップグレード・ウィンドウを終了します。
|
注意: タイム・ゾーン列付きのタイムスタンプを含む表は、更新可能な状態であることが必要です。たとえば、列に検証済および無効なCHECK制約があると更新の妨げになるため、このようなCHECK制約を列に含めることはできません。表のサイズが2GBを超える場合は、パラレル・オプションを使用することをお薦めします。また、発生するすべてのセマンティック・エラーをOracleで処理することをお薦めします。 エラー表、トリガー表または影響を受ける表の |
この例では、Oracle Database 11gリリース2へのDST動作の更新を示します。まず、現在のデータベースでタイム・ゾーンのバージョン3が使用され、タイム・ゾーン・データ付きタイムスタンプを含む既存の表tがあるとします。
CONNECT scott/tiger
DROP TABLE t;
CREATE TABLE t (c NUMBER, mark VARCHAR(25), ts TIMESTAMP WITH TIME ZONE);
INSERT INTO t VALUES(1, 'not_affected',
to_timestamp_tz('22-sep-2006 13:00:00 america/los_angeles',
'dd-mon-yyyy hh24:mi:ss tzr tzd'));
INSERT INTO t VALUES(4, 'affected_err_exist',
to_timestamp_tz('11-mar-2007 00:30:00 america/st_johns',
'dd-mon-yyyy hh24:mi:ss tzr tzd'));
INSERT INTO t VALUES(6, 'affected_no_err',
to_timestamp_tz('11-mar-2007 01:30:00 america/st_johns',
'dd-mon-yyyy hh24:mi:ss tzr tzd'));
INSERT INTO t VALUES(14, 'affected_err_dup',
to_timestamp_tz('21-sep-2006 23:30:00 egypt',
'dd-mon-yyyy hh24:mi:ss tzr tzd'));
COMMIT;
次に、オプションで、準備ウィンドウを起動して、影響を受けるデータおよびオーバーラップや存在しない時間などの潜在的なセマンティック・エラーをチェックできます。それには、バージョン4に移行する準備のためのウィンドウを起動する必要があります。必要な権限は付与されていることを前提とします。これらの権限は、DBMS_DSTパッケージで制御されます。詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
例として、最初にウィンドウを準備します。
conn / AS SYSDBA set serveroutput on EXEC DBMS_DST.BEGIN_PREPARE(4); A prepare window has been successfully started. PL/SQL procedure successfully completed.
引数4を使用すると、この文でバージョン4が使用されます。このウィンドウが正常に起動された後、次のようにしてDATABASE_PROPERTIES内のDSTのステータスをチェックできます。
SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value FROM DATABASE_PROPERTIES WHERE NAME LIKE 'DST_%' ORDER BY PROPERTY_NAME;
次のような出力が表示されます。
PROPERTY_NAME VALUE --------------------------- --------- DST_PRIMARY_TT_VERSION 3 DST_SECONDARY_TT_VERSION 4 DST_UPGRADE_STATE PREPARE
次に、DBMS_DST.FIND_AFFECTED_TABLESを起動して、バージョン3からバージョン4へのアップグレードにより影響を受けるデータベース内のすべての表を検索できます。この表には、表所有者、表名、列名、行数およびエラー件数が含まれます。ここで、デフォルトのエラー表(sys.dst$error_table)および影響を受ける表(sys.dst$affected_table)を使用するか、独自の表を作成するかを選択できます。この例では、DBMS_DST.CREATE_ERROR_TABLEおよびDBMS_DST.CREATE_AFFECTED_TABLEを使用して独自の表を作成し、次のようにして、FIND_AFFECTED_TABLESに渡します。
EXEC DBMS_DST.CREATE_AFFECTED_TABLE('scott.my_affected_tables');
EXEC DBMS_DST.CREATE_ERROR_TABLE('scott.my_error_table');
これらの表内に行がないことを確認してください。これを行うには、次のようにして表を切り捨てます。
TRUNCATE TABLE scott.my_affected_tables; TRUNCATE TABLE scott.my_error_table;
次に、FIND_AFFECTED_TABLESを起動して、アップグレードで影響を受ける表を確認します。
EXEC DBMS_DST.FIND_AFFECTED_TABLES(affected_tables => 'scott.my_affected_tables',
log_errors => TRUE,
log_errors_table => 'scott.my_error_table');
次に、影響を受ける表をチェックします。
SELECT * FROM scott.my_affected_tables; TABLE_OWNER TABLE_NAME COLUMN_NAM ROW_COUNT ERROR_COUNT ----------- ---------- ---------- --------- ----------- SCOTT T TS 3 2
次に、エラー表をチェックします。
SELECT * FROM scott.my_error_table; TABLE_OWNER TABLE_NAME COLUMN_NAME ROWID ERROR_NUMBER ----------- ---------- ----------- ------------------ ------------ SCOTT T TS AAAPW3AABAAANzoAAB 1878 SCOTT T TS AAAPW3AABAAANzoAAE 1883
これらのエラーを修正する方法は、「タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード時のエラー処理」を参照してください。その後、次の文に示すように準備ウィンドウを終了します。
EXEC DBMS_DST.END_PREPARE; A prepare window has been successfully ended. PL/SQL procedure successfully completed.
これが終了したら、DATABASE_PROPERTIES内のDSTステータスをチェックできます。
SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME LIKE 'DST_%' ORDER BY PROPERTY_NAME; PROPERTY_NAME VALUE ------------------------ -------- DST_PRIMARY_TT_VERSION 3 DST_SECONDARY_TT_VERSION 0 DST_UPGRADE_STATE NONE
次に、アップグレード・ウィンドウを使用して、影響を受けるデータをアップグレードできます。これを行うには、最初にアップグレード・ウィンドウを起動します。DBMS_DST.BEGIN_UPGRADEを実行する前に、データベースをUPGRADEモードでオープンする必要があります。Oracle RACでは、1つのインスタンスのみを起動できます。BEGIN_UPGRADEにより、すべてのディクショナリ表が1つのトランザクションでアップグレードされるため、起動は全体として成功または失敗します。プロシージャの実行中、TSTZデータのあるすべてのユーザー表は、アップグレード進行中としてマークされます。詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。
また、アップグレード・ウィンドウを起動できるのは、SYSDBAのみです。データベースをUPGRADEモードでオープンせずにBEGIN_UPGRADEを起動すると、次のエラーが発生します。
EXEC DBMS_DST.BEGIN_UPGRADE(4); BEGIN DBMS_DST.BEGIN_UPGRADE(4); END; * ERROR at line 1: ORA-56926: database must be in UPGRADE mode in order to start an upgrade window ORA-06512: at "SYS.DBMS_SYS_ERROR", line 79 ORA-06512: at "SYS.DBMS_DST", line 1021 ORA-06512: at line 1
したがって、BEGIN_UPGRADEでは、TSTZデータを含むシステム表がアップグレードされ、(TSTZデータを含む)ユーザー表がUPGRADE_IN_PROGRESSプロパティでマーク付けされます。これは、この例で後述するALL_TSTZ_TABLESでチェックできます。
BEGIN_UPGRADEには、セマンティック・エラーを処理する2つのパラメータがあります。1つはerror_on_overlap_time(エラー番号ORA-1883)で、もう1つはerror_on_nonexisting_time(エラー番号ORA-1878)です。パラメータでデフォルト設定のFALSEが使用されると、Oracleではデフォルトの変換を使用してデータが変換され、エラーは表示されません。これらの意味およびエラー処理の方法の詳細は、「タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード時のエラー処理」を参照してください。
ディクショナリ表のアップグレードの際、次のコールにより、いくつかのデフォルト値に基づいてセマンティック・エラーが自動的に修正されます。セマンティック・エラーを無視せず、ディクショナリ表でこのようなエラーが発生する場合、BEGIN_UPGRADEは失敗します。これらのセマンティック・エラーは、sys.dst$error_tableに移入されます。
EXEC DBMS_DST.BEGIN_UPGRADE(4); An upgrade window has been successfully started. PL/SQL procedure successfully completed.
これが終了した後、次のようにしてDATABASE_PROPERTIES内のDSTステータスをチェックできます。
SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME LIKE 'DST_%' ORDER BY PROPERTY_NAME; PROPERTY_NAME VALUE ------------------------ -------- DST_PRIMARY_TT_VERSION 4 DST_SECONDARY_TT_VERSION 3 DST_UPGRADE_STATE UPGRADE
次に、どのユーザー表にUPGRADE_IN_PROGRESSのマークが付いているかチェックします。
SELECT OWNER, TABLE_NAME, UPGRADE_IN_PROGRESS FROM ALL_TSTZ_TABLES; OWNER TABLE_NAME UPGRADE_IN_PROGRESS ----- ------------------------- ------------------- SYS WRI$_OPTSTAT_AUX_HISTORY NO SYS WRI$_OPTSTAT_OPR NO SYS OPTSTAT_HIST_CONTROL$ NO SYS SCHEDULER$_JOB NO SYS KET$_AUTOTASK_STATUS NO SYS AQ$_ALERT_QT_S NO SYS AQ$_KUPC$DATAPUMP_QUETAB_S NO DBSNMP MGMT_DB_FEATURE_LOG NO WMSYS WM$VERSIONED_TABLES NO SYS WRI$_OPTSTAT_IND_HISTORY NO SYS OPTSTAT_USER_PREFS$ NO SYS FGR$_FILE_GROUP_FILES NO SYS SCHEDULER$_WINDOW NO SYS WRR$_REPLAY_DIVERGENCE NO SCOTT T YES IX AQ$_ORDERS_QUEUETABLE_S YES ...
この出力では、ディクショナリ表(SYSスキーマ内)はBEGIN_UPGRADEでアップグレードされています。SCOTT.Tなどのユーザー表はアップグレードされていず、進行中です。
ここで、DBMS_DST.UPGRADE_DATABASEを使用してユーザー表のアップグレードを実行できます。すべての表をアップグレードする必要があります。そうしないと、END_UPGRADEプロシージャを使用してアップグレード・ウィンドウを終了できません。この手順を行う前に、データベースをnormalモードで再起動する必要があります。次に構文の例を示します。
VAR numfail number
BEGIN
DBMS_DST.UPGRADE_DATABASE(:numfail,
parallel => TRUE,
log_errors => TRUE,
log_errors_table => 'SYS.DST$ERROR_TABLE',
log_triggers_table => 'SYS.DST$TRIGGER_TABLE',
error_on_overlap_time => TRUE,
error_on_nonexisting_time => TRUE);
DBMS_OUTPUT.PUT_LINE('Failures:'|| :numfail);
END;
/
エラーが発生した場合、エラーを修正し、個々の表でUPGRADE_TABLEを使用します。その場合、マテリアライズド・ビュー・ベース表、マテリアライズド・ビュー・ログ表およびマテリアライズド・ビュー・コンテナ表などのマテリアライズド・ビューに関連する表の処理が必要になることがあります。これらの表のアップグレードの際に、考慮が必要ないくつかの事項があります。まず、ベース表およびそのマテリアライズド・ビュー・ログ表を、アトミックにアップグレードする必要があります。次に、すべてのベース表およびマテリアライズド・ビュー・ログ表のアップグレードが終了してから、マテリアライズド・ビュー・コンテナ表をアップグレードする必要があります。一般に、Oracle Databaseでデフォルト処理を実行して、セマンティック・エラーを処理することをお薦めします。
この例では、UPGRADE_DATABASEを実行後、SCOTT.Tでエラーがいくつか発生したとします。この場合、次を発行してこれらのエラーをチェックできます。
SELECT * FROM scott.error_table; TABLE_OWNER TABLE_NAME COLUMN_NAME ROWID ERROR_NUMBER ----------- ---------- ----------- ------------------ ------------ SCOTT T TS AAAO2XAABAAANrgAAD 1878 SCOTT T TS AAAO2XAABAAANrgAAE 1878
この出力では、エラー番号1878が発生しているのがわかります。このエラーは、存在しない時間に対してエラーがスローされたことを示します。
SCOTT.Tにマテリアライズド・ビュー・ログscott.mlog$_tがあり、SCOTT.Tに単一のマテリアライズド・ビューがあると想定して、この例を続けます。ここで、この1878エラーが修正されているとします。
最後に、表、マテリアライズド・ビュー・ログおよびマテリアライズド・ビューを次のようにしてアップグレードできます。
BEGIN
DBMS_DST.UPGRADE_TABLE(:numfail,
table_list => 'SCOTT.t, SCOTT.mlog$_T',
parallel => TRUE,
continue_after_errors => FALSE,
log_errors => TRUE,
log_errors_table => 'SYS.DST$ERROR_TABLE',
error_on_overlap_time => FALSE,
error_on_nonexisting_time => TRUE,
log_triggers_table => 'SYS.DST$TRIGGER_TABLE',
atomic_upgrade => TRUE);
DBMS_OUTPUT.PUT_LINE('Failures:'|| :numfail);
END;
/
BEGIN
DBMS_DST.UPGRADE_TABLE(:numfail,
table_list => 'SCOTT.MYMV_T',
parallel => TRUE,
continue_after_errors => FALSE,
log_errors => TRUE,
log_errors_table => 'SYS.DST$ERROR_TABLE',
error_on_overlap_time => FALSE,
error_on_nonexisting_time => TRUE,
log_triggers_table => 'SYS.DST$TRIGGER_TABLE',
atomic_upgrade => TRUE);
DBMS_OUTPUT.PUT_LINE('Failures:'|| :numfail);
END;
/
atomic_upgradeパラメータを使用すると、表とそのマテリアライズド・ビュー・ログのアップグレードを組み合せることができます。詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
すべての表のアップグレード後、次のようにしてEND_UPGRADEを起動して、次に示すようにアップグレード・ウィンドウを終了します。
BEGIN DBMS_DST.END_UPGRADE(:numfail OUT BINARY_INTEGER); END; /
他の表が正しくアップグレードされていない場合、END_UPGRADE文は失敗します。
DBMS_DSTパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
アップグレードの際、発生する可能性があるセマンティック・エラーは主に3つあります。1つ目は存在する時間が存在しない時間になる場合、2つ目は時間が重複する場合、3つ目は重複する時間が重複しない時間になる場合です。
1つ目のエラーの例として、2007年に太平洋標準時間(PST)が太平洋夏時間(PDT)に変更される場合を考えます。この変更は、バージョン4に基づいて2007年3月11日午前2時に行われ、時計が午前3時まで1時間進められると、午前2時と午前3時の間にギャップが発生します。バージョン2では、この時間の変更は、2007年4月1日に発生します。タイム・ゾーン・ファイルをバージョン2からバージョン4にアップグレードすると、2007年3月11日の午前2時と午前3時の間の時間は無効であり、ERROR_ON_NONEXISTING_TIMEがTRUEに設定されている場合、エラー(ORA-1878)が発生します。したがって、存在しない時間の問題が起こります。ERROR_ON_NONEXISTING_TIMEが、このパラメータのデフォルトであるFALSEに設定されている場合、このエラーはレポートされず、OracleではUTC時間が保持されます。バージョン2とバージョン4のどちらも同じUTCタイムスタンプに変換されるため、たとえば、バージョン2の"Mar-11-2007 02:30 PST"は、バージョン4では"Mar-11-2007 03:30 PDT"になります。
2つ目のエラーでは、PDTからPSTに変更する場合を例に考えます。たとえば、2007年のバージョン4では、2007年11月4日の午前2時から午前1時に時間が戻る際に、変更が発生します。これは、2007年11月4日の<午前1時、午前2時>内の時間が、PSTとPDTで1回ずつ、2回存在することを意味します。バージョン2では、この移行は、2007年10月28日午前2時に発生します。したがって、バージョン2では一意に識別される2007年11月4日の<午前1時、午前2時>内のタイムスタンプは、ERROR_ON_OVERLAP_TIMEがTRUEに設定されている場合、バージョン4ではエラー(ORA-1883)になります。このパラメータをデフォルト設定のFALSEのままにすると、UTCタイムスタンプ値が保持され、エラーは発生しません。この状況では、バージョン2からバージョン4に変更すると、バージョン2の"Nov-04-2007 01:30 PST"は、バージョン4では"Nov-04-2007 01:30 PST"になります。
3つ目のエラーは、重複する時間が重複しない時間になる場合に発生します。2007年のPDTからPSTへの移行を例にすると、バージョン2の2007年10月28日の<午前1時、午前2時>は重なっている期間です。したがって、バージョン2では"Oct-28-2007 01:30 PDT"と"Oct-28-2007 01:30 PST"はどちらも有効なタイムスタンプです。ERROR_ON_OVERLAP_TIMEがTRUEに設定されている場合、バージョン2からバージョン4へのアップグレード時にORA-1883エラーが発生します。ただし、ERROR_ON_OVERLAP_TIMEがFALSE(このパラメータのデフォルト値)に設定されている場合は、ローカル時間が保持されるため、エラーはレポートされません。この場合、バージョン2の"Oct-28-2007 01:30 PDT"と"Oct-28-2007 01:30 PST"は、いずれもバージョン4では同じ"Oct-28-2007 01:30 PDT"に変換されます。ERROR_ON_OVERLAP_TIMEをFALSEに設定した場合は、一部の時間の順序が逆になる可能性があることに注意してください。たとえば、バージョン2で"Oct-28-2007 01:45 PDT"にスケジュールされているジョブ(ジョブA)は、"Oct-28-2007 01:30 PST"にスケジュールされているジョブ(ジョブB)より先に実行されると考えられます。バージョン4へのアップグレード後、ジョブAは"Oct-28-2007 01:45 PDT"にスケジュールされ、ジョブBはそのまま"Oct-28-2007 01:30 PDT"にスケジュールされるため、ジョブBがジョブAより先に実行されます。連鎖していないスケジュール済ジョブは特定の順序で実行されるよう保証されていませんが、スケジュール済ジョブを設定する際には、この問題を考慮する必要があります。
これらのパラメータの使用方法の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
Oracle Database 11gリリース11.2以上では、クライアントとサーバーで異なるバージョンのタイム・ゾーン・ファイルを使用できます。この動作モードは11.2より前のリリースではサポートされていませんでした。このような混在モードで作業するには、クライアントとサーバーの両方が11.2以上であることが必要です。このようなモードでの作業で発生する問題は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。
OCI、JDBC、Pro*CおよびSQL*Plusの各クライアントは、クライアント側タイム・ゾーン・ファイルを更新しなくてもデータベース・サーバーとの通信を続行できるようになりました。その他の製品では、製品固有のドキュメントに明記されていないかぎり、このようなクライアントは、クライアントと異なるタイム・ゾーン・ファイルを使用するデータベース・サーバーでは運用できないと考える必要があります。そうでない場合、クライアントでのリージョンIDベースのTIMESTAMP WITH TIMEZONE値の計算結果に一貫性がなくなる可能性があります。これは、クライアントとサーバーの異なるバージョンのタイム・ゾーン・ファイル間で影響を受けるタイム・ゾーン・リージョンに対して、異なる夏時間(DST)ルールが有効であるためです。
アプリケーションが異なるデータベースに直接またはデータベース・リンクを介して接続する場合は、すべてのデータベースに同じバージョンのタイム・ゾーン・ファイルを使用することをお薦めします。そうでない場合、これらのデータベースのTIMESTAMP WITH TIMEZONE値の計算結果に一貫性がなくなる可能性があります。これは、様々なデータベース・サーバーの異なるバージョンのタイム・ゾーン・ファイル間で影響を受けるタイム・ゾーン・リージョンに対して、異なるDSTルールが有効であるためです。
データベースのタイム・ゾーンは、データベースの作成時に、CREATE DATABASE文のSET TIME_ZONE句を使用して設定します。データベースのタイム・ゾーンを設定しなければ、デフォルトでサーバーのオペレーティング・システムのタイム・ゾーンに設定されます。
タイム・ゾーンは、指定のリージョンまたはUTCからの絶対オフセットに設定できます。タイム・ゾーンを指定のリージョンに設定するには、次のような文を使用します。
CREATE DATABASE db01 ... SET TIME_ZONE='Europe/London';
たとえば、タイム・ゾーンをUTCからのオフセットに設定するには、次のような文を使用します。
CREATE DATABASE db01 ... SET TIME_ZONE='-05:00';
有効なオフセットの範囲は-12:00から+14:00です。
|
注意: データベースのタイム・ゾーンが関連するのは、TIMESTAMP WITH LOCAL TIME ZONE列のみです。データベース間でのデータ転送時にデータ変換を回避してパフォーマンスを改善するために、データベースのタイム・ゾーンはUTC(0:00)に設定することをお薦めします。これは、分散データベース、レプリケーションおよびエクスポートとインポートには特に重要です。 |
データベースのタイム・ゾーンは、ALTER DATABASE文のSET TIME_ZONE句を使用して変更できます。次に例を示します。
ALTER DATABASE SET TIME_ZONE='Europe/London'; ALTER DATABASE SET TIME_ZONE='-05:00';
データベースにTIMESTAMP WITH LOCAL TIME ZONE列を含む表があり、その列にデータがあると、ALTER DATABASE SET TIME_ZONE文はエラーを返します。
変更は、データベースを停止して再起動するまで有効になりません。
次の問合せを入力すると、データベースのタイム・ゾーンを確認できます。
SELECT dbtimezone FROM DUAL;
デフォルトのセッション・タイム・ゾーンは、ORA_SDTZ環境変数を使用して設定できます。ユーザーがTIMESTAMP WITH LOCAL TIME ZONEデータを検索すると、そのユーザー・セッションのタイム・ゾーンで戻されます。セッションのタイム・ゾーンは、TIMESTAMP値がTIMESTAMP WITH TIME ZONEまたはTIMESTAMP WITH LOCAL TIME ZONEデータ型に変換される場合にも有効です。
ORA_SDTZ環境変数は次の値に設定できます。
UTCからの絶対オフセット('-05:00'など)
タイム・ゾーン・リージョン名('Europe/London'など)
UNIX環境(Cシェル)でORA_SDTZを設定するには、次のような文を使用します。
% setenv ORA_SDTZ 'OS_TZ' % setenv ORA_SDTZ 'DB_TZ' % setenv ORA_SDTZ 'Europe/London' % setenv ORA_SDTZ '-05:00'
ALTER SESSION文のSET TIME_ZONE句を使用して、特定のSQLセッションに対するタイム・ゾーンを変更できます。
TIME_ZONEは次の値に設定できます。
セッション開始時のデフォルトのローカル・タイム・ゾーン(local)
データベースのタイム・ゾーン(dbtimezone)
UTCからの絶対オフセット('+10:00'など)
タイム・ゾーン・リージョン名('Asia/Hong_Kong'など)
次のようなALTER SESSION文を使用します。
ALTER SESSION SET TIME_ZONE=local; ALTER SESSION SET TIME_ZONE=dbtimezone; ALTER SESSION SET TIME_ZONE='Asia/Hong_Kong'; ALTER SESSION SET TIME_ZONE='+10:00';
次の問合せを入力すると、現行のセッションのタイム・ゾーンを確認できます。
SELECT sessiontimezone FROM DUAL;
日時SQL式には、次のいずれかを使用できます。
日時列
日時値となる複合式
日時式には、AT LOCAL句またはAT TIME ZONE句を含めることができます。AT LOCAL句を含めると、結果は現在のセッションのタイム・ゾーンで戻されます。AT TIME ZONE句を含める場合は、その句で次のいずれかの設定を使用します。
タイム・ゾーン・オフセット: 文字列'(+|-)HH:MM'で、タイム・ゾーンをUTCからのオフセットとして指定します。たとえば、'-07:00'はUTCから7時間遅れのタイム・ゾーンを指定します。UTC時間が午前11時の場合、'-07:00'タイム・ゾーンの時間は午前4時です。
DBTIMEZONE: Oracle Databaseでは、データベース作成時に(明示的またはデフォルトで)設定されたデータベースのタイム・ゾーンを使用します。
SESSIONTIMEZONE: Oracleでは、デフォルトまたは最新のALTER SESSION文で設定されたセッションのタイム・ゾーンが使用されます。
タイム・ゾーン・リージョン名: Oracle Databaseでは、タイム・ゾーン・リージョン名が示すタイム・ゾーンの値を返します。たとえば、Asia/Hong_Kongを指定できます。
式: 式で有効なタイム・ゾーン書式の文字列が戻されると、Oracle Databaseはそのタイム・ゾーンの入力を返します。それ以外の場合、Oracle Databaseはエラーを返します。
次の例では、America/New_Yorkタイム・ゾーンの日時値をAmerica/Los_Angelesタイム・ゾーンの日時値に変換しています。
例4-5 他のタイム・ゾーンへの日時値の変換
SELECT FROM_TZ(CAST(TO_DATE('1999-12-01 11:00:00',
'YYYY-MM-DD HH:MI:SS') AS TIMESTAMP), 'America/New_York')
AT TIME ZONE 'America/Los_Angeles' "West Coast Time"
FROM DUAL;
West Coast Time
----------------------------------------------------------
01-DEC-99 08.00.00.000000 AM AMERICA/LOS_ANGELES
|
関連項目: 『Oracle Database SQL言語リファレンス』 |
Oracle Databaseは、指定のタイム・ゾーンで夏時間が有効かどうかを自動的に判別し、対応するローカル時間を返します。Oracle Databaseで夏時間が特定のタイム・ゾーンで有効かどうかを判別するには、通常、日時値で十分です。夏時間の開始期間または終了期間は境界事例です。たとえば、米国東部では、夏時間が有効になる時点で、時刻が午前1時59分59秒から午前3時0分0秒に変わります。午前2時0分0秒～午前2時59分59秒の時間隔は存在しません。その時間隔に該当する値は無効です。夏時間の終了時には、時刻が午前2時0分0秒から午前1時0分1秒に変わります。午前1時0分1秒～午前2時0分0秒の時間隔が繰り返されます。この時間隔に含まれる値は、2回発生するため不明確となります。
このような境界事例を解決するために、Oracle DatabaseではTZRおよびTZD書式要素を使用します。TZRは、日時入力文字列でのタイム・ゾーン・リージョンを表します。たとえば、'Australia/North'、'UTC'および'Singapore'などです。TZDは、夏時間情報を含むタイム・ゾーン・リージョンの略称を表します。たとえば、米国太平洋標準時間の場合は'PST'、米国太平洋夏時間の場合は'PDT'です。TZRおよびTZD書式要素に対して有効な値のリストを表示するには、V$TIMEZONE_NAMES動的パフォーマンス・ビューのTZNAME列とTZABBREV列を問い合せます。
|
関連項目:
|
TIMESTAMPデータ型はタイム・ゾーン値を受け入れず、夏時間は計算されません。
TIMESTAMP WITH TIME ZONEおよびTIMESTAMP WITH LOCAL TIME ZONEデータ型は、次のように動作します。
タイム・ゾーン・リージョンが日時値に関連付けられている場合、データベース・サーバーではリージョンの夏時間規則が認識され、その規則が計算に使用されます。
夏時間を使用しないリージョンについては、夏時間は計算されません。
これ以降は、日時データ型を使用する例について説明します。例ではglobal_orders表を使用します。この表には、TIMESTAMPデータ型のorderdate1列とTIMESTAMP WITH TIME ZONEデータ型のorderdate2列が含まれます。global_orders表は次のように作成されます。
CREATE TABLE global_orders ( orderdate1 TIMESTAMP(0),
orderdate2 TIMESTAMP(0) WITH TIME ZONE);
INSERT INTO global_orders VALUES ( '28-OCT-00 11:24:54 PM',
'28-OCT-00 11:24:54 PM America/New_York');
例4-6 TIMESTAMP WITH TIME ZONEおよびTIMESTAMPを使用した夏時間計算の比較
SELECT orderdate1 + INTERVAL '8' HOUR, orderdate2 + INTERVAL '8' HOUR
FROM global_orders;
出力は次のようになります。
ORDERDATE1+INTERVAL'8'HOUR ORDERDATE2+INTERVAL'8'HOUR -------------------------- -------------------------- 29-OCT-00 07.24.54.000000 AM 29-OCT-00 06.24.54.000000 AM AMERICA/NEW_YORK
この例は、各列に8時間追加した場合の影響を示しています。この期間には、夏時間の境界(夏時間から標準時間への切替え)が含まれています。orderdate1列はTIMESTAMPデータ型で、夏時間情報は使用されないため、8時間内に発生する切替えにあわせた調整は実行されません。TIMESTAMP WITH TIME ZONEデータ型では切替えにあわせて調整されるため、orderdate2列はorderdate1列より1時間早い時刻を示します。
例4-7 TIMESTAMP WITH LOCAL TIME ZONEおよびTIMESTAMPを使用した夏時間計算の比較
TIMESTAMP WITH LOCAL TIME ZONEデータ型では、セッション環境にあわせて設定されたTIME_ZONEの値が使用されます。次の文は、TIME_ZONEセッション・パラメータの値を設定してglobal_orders表を作成します。global_orders表には、TIMESTAMPデータ型の1列とTIMESTAMP WITH LOCAL TIME ZONEデータ型の1列があります。
ALTER SESSION SET TIME_ZONE='America/New_York';
CREATE TABLE global_orders ( orderdate1 TIMESTAMP(0),
orderdate2 TIMESTAMP(0) WITH LOCAL TIME ZONE );
INSERT INTO global_orders VALUES ( '28-OCT-00 11:24:54 PM',
'28-OCT-00 11:24:54 PM' );
両方の列に8時間を追加します。
SELECT orderdate1 + INTERVAL '8' HOUR, orderdate2 + INTERVAL '8' HOUR FROM global_orders;
orderdate2の日時値にはタイム・ゾーン・リージョンが関連付けられているため、Oracle Databaseサーバーではそのリージョンに夏時間規則が使用されます。そのため、出力は例4-6と同じになります。TIMESTAMPデータ型の場合は夏時間が計算されないため、2つの計算には1時間の時差があり、計算は夏時間境界にまたがっています。
例4-8 夏時間を使用しないリージョンについては計算されない夏時間
タイム・ゾーン・リージョンをUTCに設定します。UTCでは、夏時間は使用されません。
ALTER SESSION SET TIME_ZONE='UTC';
global_orders表を切り捨てます。
TRUNCATE TABLE global_orders;
global_orders表に値を挿入します。
INSERT INTO global_orders VALUES ( '28-OCT-00 11:24:54 PM',
TIMESTAMP '2000-10-28 23:24:54 ' );
各列に8時間を追加します。
SELECT orderdate1 + INTERVAL '8' HOUR, orderdate2 + INTERVAL '8' HOUR FROM global_orders;
出力は次のようになります。
ORDERDATE1+INTERVAL'8'HOUR ORDERDATE2+INTERVAL'8'HOUR -------------------------- --------------------------- 29-OCT-00 07.24.54.000000000 AM 29-OCT-00 07.24.54.000000000 AM UTC
UTCタイム・ゾーン・リージョンの場合は夏時間が計算されないため、時刻は同じです。
