システム日付を設定すること

稼動中に システム日付 を変更するとデータベースの稼動に重大な影響を与えてしまうので、 インスタンスの稼動中、停止を問わず、システム日付は変更してはいけない。 但し、データベースのスタートアップ時刻がインスタンスの停止時刻より未来であれば、 通常のシャットダウンと同じことなので問題とならない。

特に時間を過去に大きく逆戻りすることは Oracle だけでなくアプリケーションレベルでも危険な行為なので注意が必要。 正常に起動してもユーティリティ使用時などにエラー(ORA-01466: データを読み込めません - 表定義が変更されました)となる事が知られている。しばらく後で忘れた頃に判明するのでやっかい。

Oracle 上で仮想的にシステム日付を変更する

データベースの SYSDATE(※) を任意の時間に設定するには、FIXED_DATE 初期化パラメータを使用する。

(※) SYSDATE 以外、たとえば SYSTIMESTAMP にも FIXED_DATE の設定は反映されない。

見せかけのシステム日付の変更方法

ALTER SYSTEM SET FIXED_DATE = 'YYYY-MM-DD HH24:MI:SS' SCOPE=MEMORY;

SCOPE=MEMORY 句を使用することを強く薦めます。

元に戻す方法(1)

以下の方法で FIXED_DATE の初期化パラメータを削除する

 ALTER SYSTEM RESET FIXED_DATE SCOPE=SPFILE SID='*';

SCOPE={MEMORY|SPFILE|BOTH} SID='SID' 句は省略不可。
RESET コマンドは RAC 環境が前提らしくシングルインスタンスでも SID='*' の指定が必要になる。(いつからかは未確認だが 11gR2 現在では SID='*' がデフォルトになっている模様)

元に戻す方法(2)…危険:次回の起動ができなくなる場合がある。Oracle 10g のマニュアルにクリアに関する記載はない
ORA-00065: FIXED_DATEの初期化に失敗しました。

ALTER SYSTEM SET FIXED_DATE = none SCOPE=MEMORY;

none は列挙タイプの初期化パラメータで使用するパラメータのひとつ。
注意 SCOPE=MEMORY を併用しないとバージョンにより次回の起動ができなくなります。
上の日付の設定で SCOPE=MEMORY を使用していない場合、SPFILE へのエントリを RESETコマンドにより削除する。

関連事項

どうしてもシステム日付を変更したい

人的ミスなどで日付を間違って運用していたなどの場合。
変更前には必ずフルバックアップを行う。日付の変更後にはジョブキューの確認を行う。
しばらくの間(数日)は慎重にシステムを監視する。

どんな不具合が発生するか

オラクル時間? (SCN)

Oracleにおける トランザクションにおける時間進行は SCN(システム変更番号)で管理されている。 そのため、システム日付を過去にしてもデータの整合性が破綻することはない。*1 しかし、すべてが SCN で管理できるようなものではないために不具合が発生する。

どんな不具合が発生するか

  • 開発アプリケーションで、日付項目に SYSDATE を設定していることによるデータの不整合
  • オブジェクトの作成日付が管理されていることによる Oracle ユーティリティでの不具合
  • ジョブ(スケジューラ)に依存する機能の不調
    ジョブ スケジューラの次回実行予定時刻は、計算式の値が データ・ディクショナリに保存されている。
    (マテリアライズドビューのリフレッシュグループなども、スケジューラを使用している)

(例) ジョブの処理時間が管理されているデータディクショナリ

SELECT
   LAST_DATE, NEXT_DATE, WHAT, INTERVAL
FROM DBA_JOBS ;
 
SELECT
   OWNER, JOB_NAME, LAST_START_DATE,LAST_RUN_DURATION
FROM DBA_SCHEDULER_JOBS ;

タイムサーバー(NTP)運用によるシステム日付の変更

タイムサーバーとクライアントの設定により異なる。(クライアントのOS,NTPプログラムの種類によっても異なるらしい)

  • slew time correction モード(-x オプション)の場合

    1 秒を微小に長くしたり短くしたりすることで、時間経過スピードを緩やかに進めて(遅らせて)調整する。
    (カーネルレベルでサポートされているものもあるらしい)
    しかし、調整単位が1秒あたりミリ秒(0.5 ミリ秒)のレベルのため調整できる限度がある。
    そして slew 〜 モードの場合 1秒補正するのに 2000秒(約 33分) かかり、1日換算しても1分にも満たない約 43 秒しか補正できない。( これは基本仕様であり ntpd の提供ベンダやカーネルによっても異なると思われる。)
    また、その間は分散型アプリケーションは使用できないと書かれているので RAC を使用している ntp クライアントが slew 〜 モード(-x オプション)で動作している場合には、問題があるかもしれない。
    ( ntp による障害の経験から極小の時間差の場合には RAC 側に何かしらの回避策が組み込まれている可能性もある )

  • step time correction モードの場合(デフォルト)

    時間は即座に正確な時間に設定される。(ネットワークの遅延や誤差の収集が行なわれている安定した状態の場合)
    この場合は、複数の ntp クライアントで時間に差(通常誤差は 128 ms 以内)が発生することはない、 そしてサーバーとの誤差が 128 msを超えるとダイレクトに時間が変更される。(NTP+RAC構成において、かなり重度の不具合が発生したという話があるようですが、これは非常に低い確率で、かつ、タイミングが悪いときに時間が戻って RAC の障害がでたという内容だったと思います。)



日本オラクル
■ 日本オラクル 株式会社
■ オラクルマスター資格 (オラクルマスターとは
■ 会員制(無料)の公式技術サイト

*1 旧バージョンでの NTP+RAC構成において、かなり重度の不具合が発生したというドキュメントを見たことがある、ソースは失念しました。