今回も発表のメインはクラウド関連だと思いますが、やはりDBエンジニアとしては昨年の Oracle Database 21c に続く 22c の発表があるのかが気になります。現在の Long Term Release は 19c であり、Long Term Release 間の移行は約4年と言われているので、「（恐らく次の Long Term Release になる）23c に注力するから 22c はスキップ」なんてことがあるんじゃないかと心配しています。
もう一つは Exadata X9M の後継機も注目ですね。Exadata は枯れているようで、リリース毎に最新のHWとSW技術を盛り込んでいます。節目の10代目（V時代を入れると11代目）で大きな変更があるのかどうか。名称も「X10M」ではなくて「Exadata XXM」なんてことになったりして（もはや X が多過ぎてよく分からない）。
“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 期間があるように見えるリリースも、途中で延長されたケースが多く、運用開始時点に保障されていた期間ではありません
カナダでは3月の第2日曜日3:00にサマータイムが始まり、11月の第1日曜日2:00に終わります。約8か月、実に1年の2/3はサマータイムということになります。トロントのタイムゾーンは東部標準時（Eastern Standard Time, EST）と東部夏時間（Eastern Daylight Time, EDT）の2つですが、「標準」のほうが遥かに短いというのが不思議。
大分前置きが長くなりました。日本で仕事をしている時にはサマータイムを意識した運用を経験することはほとんどありませんでしたが、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を使ったタイムゾーンの指定をしています。
TIMESTAMP WITH TIMEZONE型を使うことでOracleがサマータイムの切替えに対応できることが分かりました。日本でも海外とのシステム連携が必要な場合には利用しているケースもあると思います。一方で、テーブルのデータ型だけではない考慮も必要になります。例えば、SYSDATEのようにサーバ時刻を返す動作もある為、サーバ側でもサマータイム対応するのかどうか気になります。また、DATE型に比べてTIMESTAMP WITH TIMEZONE型のほうがバイト数が大きくなる（7バイト→13バイト）為、元あるシステムからデータ移行が必要な際にはテーブル設計等で注意が必要になりそうです。アプリケーションや他システムとの連携を考えると話は更に複雑になります。「本当に日本でサマータイム導入が見送られてよかった」というのが今回の結論です。
