システム日付を設定すること
稼動中に システム日付 を変更するとデータベースの稼動に重大な影響を与えてしまうので、
インスタンスの稼動中、停止を問わず、システム日付は変更してはいけない。
但し、データベースのスタートアップ時刻がインスタンスの停止時刻より未来であれば、
通常のシャットダウンと同じことなので問題とならない。
特に時間を過去に大きく逆戻りすることは 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 の障害がでたという内容だったと思います。)
- 関連事項
NTP を考案した教授 ( Mills, David L ,PhD, Professor ) の
NTP に関するページ