Oracleクラスターでは、sysdateは常に一貫した答えを返しますか？

Question

Oracleクラスタ（複数のマシンが連携して1つのデータベースを提供する）では、「sysdate」が関数は常に一貫した答えを返しますか？サーバーのオペレーティングシステムクロックが一貫性のない値を報告している場合でも

Answer 1

SYSDATEもOSにリンクされていると強く疑います。使用する必要がある理由に注意してください。イベントのインクリメンタルトラッキングを実装するロジックがある場合（インクリメンタルエクスポートを実行している場合など）、アイテムの欠落や重複がないことを確認する必要がある場合は、SYSDATEではなくシーケンシャルIDに基づいてトラッキングを行います。

実際、SYSDATEは時々変更される可能性があるため（時間の節約、sysadminエラーなど）、非クラスターシステムでもこれは当てはまります。

Answer 2

SYSDATEはノードOS関連です。クラスタ全体で正しいことが保証されている場合、SYSDATEを呼び出すたびにノードを同期する必要があります。 クラスター環境では、順序付けされたシーケンスは高価です。可能な限り避けてください。 順序付けられたシーケンスは、一意性と順序を保証しますが、シーケンスから選択した後、トランザクションをコミットする前に処理が失敗した場合でも、ギャップが生じる可能性があります。

いくつかの回避策を使用します：

1. 通常、シーケンスは キャッシュサイズが大きい順不同 （25,000）クラスター間の削減 コミュニケーション。
2. NTPを使用して時刻同期を行う ノード（それらはまだ 不正確、+ /-ナノ秒なので、 これに頼ることはできません）
3. 監査スタイルのログには、systimestampを使用します （timestamp（6））として 識別子-そして事実と共に生きる それが可能であること（ただし 非常に低い）ログ 順不同で表示される可能性があります（これは 通常でも可能 処理、いつに応じて コミットが発生します）

4. 注文した場所 シーケンスが必要です。 ギャップがある-順序付けられたシーケンスを使用する （クラスター化された環境では避けるようにしてください 「キャッシュ」としての環境役に立たない）

5. 順序付けられたシーケンスは 必須-ただし、ギャップはありません-独自のシーケンステーブルがあり、レコードをロックし、番号を取得し、 その後、レコードをロックするまで ユーザーがコミットします。これにより 同じことをしようとする他のみんな ユーザーの トランザクションは完全にコミットされています- できる限りこれを行わないでください。

Answer 3

NTPを使用して、すべてのサーバー（Oracleなど）で時刻を同期し、それが発生しないようにします。一貫性のないシステムクロックは災害のレシピです。

sysdateは、説明したシナリオで一貫性のない結果を返すと推測します。

Answer 4

これに対する答えを探すのに（少し）時間を費やしましたが、それを見つけることができませんでしたが、sysdateがオペレーティングシステムから日付/時刻を返すだけなので、dmitriyが正しいと思います。