カテゴリー: 技術情報

新発表！Oracleバージョン選定に朗報？

こんにちは。イトウです。
今年のOracle OpenWorldがオンライン開催となることが発表されました。これまでのサンフランシスコからラスベガスに会場を変更しての初回となるはずだっただけに、残念に思っている方も多いかもしれません。

ただ、先月アメリカで開催されたOracle Cloud Day 2020もオンラインで参加しましたが、時間や場所を問わず、自宅でコーヒーを飲みながらセッションを見られるのは良かったので、悪いことばかりではないと思います。無料で参加できるのも嬉しいですね。

さて、今月はOracle Databaseに関わるその他のニュースとして、製品ライフサイクルに関する発表がありました。それは “Innovation Release” と “Long Term Release” の2種類のリリースです。

Oracle Database 12cまでは約2～4年で大型のリリースが行われていましたが、18c以降は年1回リリースへ変更されていました。

Premier Supportのライフサイクルとしては18cと19cは12.2ファミリーに位置づけられ（18c＝12.2.0.2、19c＝12.2.0.3という扱い）、19cが12.2のTerminal Releaseとされていました。

11gから19cまでのリリースおよびサポートのスケジュール。Terminal Releaseを連続して選択できず、途中2～3年でアップグレードが前提のライフサイクルとなっている。

今回発表された “Innovation Release” と “Long Term Release” は従来の “Base Release” ＋ “Patch Set Release” 方式に変わるものです。要点をかいつまむと次の通り。

“Innovation Release”
多くの機能強化や新機能を含むリリースとなり、新しいアプリケーションの開発や既存システムの拡張に有用なリリース。2年間のPremier Supportを提供し、Extended Supportはありません。

“Long Term Release”
5年間のPremier Supportと3年間のExtended Supportを提供することで、次のアップグレードまでのインターバルを長く取ることができる為、より高い安定性を求めるシステムに適しています。

狙いとしては、新機能追加やエンハンスメントをより頻繁にリリースすることだと思います。Innovation Releaseの間隔や回数は公表されていないものの、「Long Term Release から次の Long Term Release へのアップグレードは約4年になる」という説明もあったので、年次リリースが継続されるなら、Innovation Release 3回 ＋ Long Term Release ということになるのかもしれません。従来の Base Release 1回 ＋ Patch Set Release 1～3回 に比べると、その差は明らかです。

仮にInnovation Release3回で従来方式と比べると、より積極的な新機能追加が可能

一方、ユーザー目線では Long Term Release で Premier Support 5年、Extended Support 3年があらかじめ保証されているのは大きなメリットと言えるのではないでしょうか。これまでのライフサイクルでは、Terminal ReleaseからTerminal Releaseへと移行することが難しく(※)、途中のPatch Set Releaseを挟む為、2～3年に1回のアップグレードを前提にしたリリース計画でした。その為、アップグレードが難しい現場では Premier Support が切れた状態で利用を続けているケースも少なくなかったと思います。
（※）上記のサポート期間の表を見ると十分な Premier や 無償Extended 期間があるように見えるリリースも、途中で延長されたケースが多く、運用開始時点に保障されていた期間ではありません

新しいライフサイクルでのリリース予測とサポート期間。Innovation Releaseの回数や間隔は果たして…

Oracle のライフサイクルやサポートポリシーに関する変更はよくあることなので、ユーザー側で将来を予測しながら、自社システムのライフサイクルを考えるということは非常に難しいと思います。また、データベースをアップグレードする背景としては、新機能を利用したいと言ったポジティブな理由よりも、法令対応や老朽化対策、社内の他システムとの互換性維持といった「仕方なく」というケースが大半のように感じます。そして、そういうケースではタイミングを選べないことが多いだけに、バージョン選定において「安定リリース」（となるはず！）として用意された “Long Term Release” は一つの基準になるかもしれません。そんな期待を込めて、今回の発表は前向きなものと考えている次第です。

※製品のライフサイクル、リリーススケジュールに関する最新の情報は、オラクル社発表のこちらをご参照ください。
Release Schedule of Current Database Releases (Doc ID 742060.1)

サマータイムとOracleのTIMESTAMP WITH TIME ZONE型

イトウです。本日（3/8）からトロントはサマータイムになりました。
「3月なのにサマーなんてだいぶ気が早いな」と思っていたら、なんと今日の気温は10℃、明日は12℃と暖かい日が続いています。カナダに住む人たちの夏に対する強い思いが春の陽気を呼び寄せたのかも。日本でも以前に東京オリンピックでサマータイム導入の話がありちょっと話題になりましたが、実際にサマータイムのある地域に暮らしてみて気づいたこともあります。

そもそもサマータイムの方が長い

カナダでは3月の第2日曜日3:00にサマータイムが始まり、11月の第1日曜日2:00に終わります。約8か月、実に1年の2/3はサマータイムということになります。トロントのタイムゾーンは東部標準時（Eastern Standard Time, EST）と東部夏時間（Eastern Daylight Time, EDT）の2つですが、「標準」のほうが遥かに短いというのが不思議。

すべての地域でサマータイムを導入しているのではない

国土の広いカナダでは元々6つのタイムゾーンがあります。そして一部の州や地域ではサマータイムを導入していません。例えば、サスカチュワン州は州全体で中部標準時（CST）を通年採用していたり、オンタリオ州やケベック州では州内でサマータイムを導入していない地域がある等、対応に違いがあります。国内で複数の標準時と更にサマータイムが入り混じっている状況は、日本人からすると訳が分かりませんね。。バンクーバーのあるブリティッシュ・コロンビア州では1年中サマータイムのタイムゾーンとする法案が州議会に提出されたというニュースも見かけました。もう「サマータイム」って何だろう。

一般の人は夜が長くなる

サマータイムにより時計の針が1時間早まります。夏のトロントでは日没が夜の8〜9時頃になるので、仕事が終わってからも外でゆっくりと過ごすことができます。多くのレストランでパティオが開き、街中がとても賑やかに。寒く長い冬を過ごすカナダでは、みんな大好きサマータイム。

日本と仕事をしている人は辛い？

しかし、喜んでばかりいられない事情もあります。トロントはサマータイムになっても日本のタイムゾーンは変わりません。弊社の場合、24時間のシステム運用保守を日本と分割していますが、交代のタイミングは変わらない為、トロント側は業務開始と終了が1時間ずつ遅くなります。仕事の後に買い物や飲みに行きたいと思っても、標準時と比べて1時間短くなる逆転現象が生まれてしまうのです。また、日本とのWEB会議でも、日本時間で朝9時開始の場合、トロント側は夜7時開始だったのが夜8時開始になります。1日の終わりが遅くなるのは辛いなというのが個人的な感想です。ただ、仕事のない日は1日が長くて嬉しいのは皆と一緒。

ところでOracleではどうなの？

大分前置きが長くなりました。日本で仕事をしている時にはサマータイムを意識した運用を経験することはほとんどありませんでしたが、Oracle Databaseではタイムゾーンを意識した時刻を格納する為にTIMESTAMP WITH TIMEZONE型があり、指定のタイムゾーンでサマータイムかどうかを自動で判別して時間を返してくれます。ちょっと気になったので、どういう動きになるのか遊んでみました。

サマータイムへ切り替わる時刻を表示してみる

今回はOracle Live SQLを使って、ブラウザから19cのデータベースで動作を確認しました。手元に環境がなくてもSQLを実行できるので便利です。

TO_TIMESTAMP_TZファンクションを使うと、指定した文字列をTIMESTAMP WITH TIME ZONEデータ型の値に変換できるので、今日の標準時からサマータイムへの切替わりの例で確認してみます。TIMESTAMP WITH TIMEZONE型ではUTCに対するオフセットかタイムゾーンリージョンを示すTZR書式、TZD書式を指定することで、その地域に合わせた時刻を扱うことができます。ここでは標準時とサマータイムの違いが分かりやすいTZRとTZDを使ったタイムゾーンの指定をしています。

実際の時刻では2020年3月8日午前1:59の次は一気に3:00になります（2:00〜2:59が飛ばされる）。EST（東部標準時）とEDT（東部夏時間）のそれぞれで、1:00、2:00、3:00を表示させようとしてみたところ、存在しない時刻はエラーになり表示できませんでした（当たり前ですが）。1パターンだけエラー番号が異なるのが不思議ですね。

 

サマータイムを意識した計算を試してみる

次にサマータイムを意識した計算ができるのかを確認してみようと思います。3/8 0:00から1時間ずつ時刻を足していき、標準時からサマータイムに切替わるのかを試してみます。

1時間足した時はEST 1:00でしたが、2時間足したらEDT 3:00という結果になり、期待通りの動作になりました。

まとめ

TIMESTAMP WITH TIMEZONE型を使うことでOracleがサマータイムの切替えに対応できることが分かりました。日本でも海外とのシステム連携が必要な場合には利用しているケースもあると思います。一方で、テーブルのデータ型だけではない考慮も必要になります。例えば、SYSDATEのようにサーバ時刻を返す動作もある為、サーバ側でもサマータイム対応するのかどうか気になります。また、DATE型に比べてTIMESTAMP WITH TIMEZONE型のほうがバイト数が大きくなる（7バイト→13バイト）為、元あるシステムからデータ移行が必要な際にはテーブル設計等で注意が必要になりそうです。アプリケーションや他システムとの連携を考えると話は更に複雑になります。「本当に日本でサマータイム導入が見送られてよかった」というのが今回の結論です。

【参考】
SQL言語リファレンス
TO_TIMESTAMP_TZ
https://docs.oracle.com/cd/F19136_01/sqlrf/TO_TIMESTAMP_TZ.html#GUID-3999303B-89CA-4AA3-9817-458F36ADC9DC

Databaseグローバリゼーション・サポート・ガイド
4.2.1.3 TIMESTAMP WITH TIME ZONEデータ型
https://docs.oracle.com/cd/F19136_01/nlspg/datetime-data-types-and-time-zone-support.html#GUID-5BC5D2C1-6506-49BE-8177-F743A46FDC09
4.12 夏時間のサポート
https://docs.oracle.com/cd/F19136_01/nlspg/datetime-data-types-and-time-zone-support.html#GUID-E5171DEF-74D7-482A-B4E9-1EE3403E18BC