【Oracle Database】2017年1月1日実施「うるう秒」の対応は大丈夫ですか？：データベースサポート最前線の現場から（3）（1/2 ページ）

データベース管理システムの運用でトラブルが発生したらどうするか。データベースサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は「2017年1月1日うるう秒の対応ポイント」を解説します。

[大野高志，株式会社アシスト]

※本連載は、アシストのデータベースサポートスペシャリストによる「Database Support Blog」より、提供社の許可の下、一部修正して転載するものです。

連載バックナンバー

　来たる2017年1月1日（日）に、通算27回目の「うるう秒」が適用されます。日本標準時（JST）では、2017年1月1日の午前8時59分59秒と午前9時0分0秒の間に「8時59分“60”秒」が挿入され、2017年1月1日が1秒長くなります。

（参考）2012年7月1日に実施されたうるう秒挿入の瞬間（出典：NICT）

　うるう秒（閏秒）とは、世界時 UT1（Universal Time 1）に対して協定世界時 UTC（Coordinated Universal Time）を±0.9秒以内に保つために、1秒単位で調整（追加／削除）される秒のことです。

（参考リンク）「うるう秒」挿入のお知らせ（総務省）

　アシストのサポートセンターへの過去の問合せ履歴を確認すると、うるう秒実施日の約2カ月前から直前に、どう対応すべきかについての問い合わせが増加します。ちなみに前回は、2015年7月1日に＋1秒の調整が行われましたが、皆さんはどう対応したでしょうか。今回はあらためて、2017年1月1日に向けたOracle Databaseにおける「うるう秒の対応手段」を紹介します。

Oracle Databaseにおけるうるう秒の対応

　Oracle Databaseでは、うるう秒（2017/01/01 08:59:60）の扱いをサポートしておりません。そのためOracle Databaseそのものに限っては、うるう秒に備えた特別な対応は発生しません。ただしシステムとしては、データベースサーバのシステムクロックが実際の時刻より1秒進みます。時刻の同期が行われるまで、システムクロックは1秒進んでいる状態となります。

　そのため、データベースサーバ側のOSがうるう秒をサポートしているシステムにおいて、アプリケーションが「SELECT SYSDATE」（OSのシステム日付／時刻を参照）を使用している場合には注意が必要です。具体的には、「2017/01/01 08:59:60」という通常では想定されていない値が戻ったときにどうなるか、などです。OSやデータベースなどの各種アプリケーションの情報収集や対応状況の確認をあらためて行ってください。

　例えば、Oracle Database上で「2017/01/01 08:59:60」を扱う処理を行うと、「ORA-01852」エラーが発生する可能性があります。「秒」は0から59の間で指定する必要があり、挿入値の範囲外となるためです。

 SQL> SELECT to_date('2017/01/01/08:59:60','YYYY-MM-DD/HH:MI:SS') FROM dual;
 　
 SELECT to_date('2017/01/01/08:59:60','YYYY-MM-DD/HH:MI:SS') FROM dual
                *
 行1でエラーが発生しました。:
 ORA-01852: 秒は0から59の間で指定する必要があります
 　
　
 SQL> INSERT INTO test values(to_date('2016/01/01/08:59:60','YYYY-MM-DD/HH:MI:SS'));
 INSERT INTO test values(to_date('2016/01/01/08:59:60','YYYY-MM-DD/HH:MI:SS'))
                                 *
 行1でエラーが発生しました。:
 ORA-01852: 秒は0から59の間で指定する必要があります

発生した「ORA-01852」エラーの例

　もし管理しているシステムが上記に該当する場合には、「"2017/01/01/08:59:60"のデータをOracle Databaseで扱わない」よう、事前にアプリケーションの調整をしておく必要があります。