改變系統時間對於oracle的影響

前不久，因為接到用戶投訴，說他們的應用中所產生的時間不一致，導致其產生的報表的產能達成上有一定問題。由於我們各大系統分布於不同的主機上，而各主機的系統時間各自又有一點差異，有的比標准時間稍有提前，有的又有滯後，於是我們因應用戶的需求做了ntp的主機同步的動作(ntp使多主機時鐘同步的相關問題請參見“NTP設定各台主機系統時鐘同步”)，因這幾台上均運行的是oracle的DB的應用，故而對於系統時鐘的改變對於oracle DB的影響，做了一些查證和學習。

相信很多朋友已经有這方面的經驗了，但是，沒有關係，如果你正在查這方面的資料，那我們從這開始吧!

本文描述了在OS的系統時鐘改變時對於其上的DB的影響相关知识.

問題的描述

當系統被改變時，比如系統時鐘向前調整，或是向後調整時，這些動作對於運行的DB有哪些潛在的危害及影響？

 

問題分析

當因為某些原因需要改變系統的時間時，如：時鐘改記夏令時，或是如我們這般因為需要多台主機時鐘與標准時鐘同步等等原因，有人會問這對於oracle DB 有很大的影響呢？其實，我們單從Oracle本身教，不涉及基於oracle上的應用的角度來分析這個問題，問題其實很簡單。由於oracle 數據庫中是使用SCN(System Commit Number)來記錄所有DB事務的軌跡，所以系統時鐘的改變，對於DB的操作是沒有任何影響的。

影響一：基於時間的恢愎(time-based recovery)

但,真的沒有影響嗎？當做基於時間的恢愎(time-based recovery)操作時，會受到影響。為什麼呢？很簡單，因為time-based recovery是依據log中的時間戳來恢愎事務的。

   Time based recovery需要檢查記錄中logfile中的事務發生的確切的時間。每個log記錄了事件發生時相關的時間戳。如果系統管理員因為某些原因改變了系統的時鐘的設定，Oracle技術支持建議你首先將數據當下來，然後做一份冷備份或是首選做熱備份.如果因為某些原因，DBA必須取得一份在改變系統時鐘之前的數據庫的備份話，除了基於時間的恢愎有問題外，其它的回滾恢愎工作是沒有任何問題的。

   請注意：當系統是向前移動的話，其於時間的恢愎是沒有問題的，唯一有問題的是，當系統時鐘向後移動時，可能存在有兩個logfile有相同的時間戳，這才是基於時間進行恢愎時，產生問題的所在。

在這種情形下，如果要做基於時間的恢愎的話，當使用冷備份(或是熱備份)進行基於時間的恢愎時，竟管oracle會應用在描述時間之前的所有relog entries,但是當它發現第一個記錄有描述時間的時間戳的log時，基於時間的恢愎會停下來，這時，可能形成做基於時間的恢愎時，丟失一部分的log,這部分的log不能被應用於基於時間的恢愎。

  下面這個圖示將是這種情況一個最好的例子說明：

3pm            4pm     4.15    4.30  5pm-->4pm   4.16pm  4.30   5pm 

|--------------|-------|-------|-------|---------|-------|------| 

cold/hot      T1      T2      T3     clock       T4     T5      T6 

backup                               change 

 

                                       |<----------R1---------->| 

 

     如圖所示：我們在3PM做了系統的一個冷備份(或是熱備份)。在4PM時運行了一個事務T1，redo log中記錄了一個4pm執行的事務的時間戳。在4.15PM運行的事務 T2，4.30PM運行的事務T3.而在5PM時我們進行了系統時鐘的後向調整，我們將時間向後調了整整一個小時。16分鐘後，也就是4.16PM時事務T4運行，接下來，硬盤壞了，我們丟失了一些數據文件。這時任何企圖恢愎DB到R1所示的區間的特定時間點的恢愎都是不可能的，這時只能恢愎到系統時鐘改變之前的的任意一時間點。

    也就是說，如果DBA想恢愎DB到T5事務所在的時間點4：30PM的話(注意T5在R1標示的范圍內)，首先DBA重存3PM的熱備或是冷務，最一個基於時間點的恢愎，想恢愎到T5事務所在的時間點4：30PM。實際上，這個恢愎只是到了T3事務所在的4：30PM，而不是T5事務所在的4：30PM，這種情況下T3事務之後發生的事務將被丟失。在這種情況下基於時間的恢愎最多可以恢愎到5PM這一時間點。

  

影響二：對於oracle上運行的業務邏輯的影響 (affect business logical)

    當您基於oracle上的應用使用了sysdate的話，而這時你又要將你的系統時鐘向後調整的話，那你要注意了!這可能意味著您基於oracle的應用可能產生業務邏輯上的不一致，這對於您的應用是致命的。一般來說，如果你要向後調整你的應用的話，最好的方式，就是將你的業務停下來，停過向後調整的時間差，這樣對於你的應用就是一致的，當然停業務，是會有損失的，您可以找一個維護的時間來做。但是很多時候，你的應用是7*24的，那麼這時，你就要注意了，在規劃您的應用和系統時，一定要考慮應用的所有主機的時鐘的同步問題。相關的如何同步的機制請參考XNTP或是NTP等協議。

 

注意事項：

    <1> 盡管基於時間點的恢愎可能存在問題，我們還是可以使用基於SCN號或是基於cancel的恢愎，使系統恢愎到當機前的狀態(RECOVER UNTIL CHANGE)。

    <2> 當基於oracle的應用用到sysdate時，您向後調整系統時鐘時，您在設計應用或是規劃時一定要考慮各應用的主機同步的問題。

結論&結語：

     <1> 當系統的時鐘向後調整時，oracle在這個調整的時間段內做的基於時間點的不完全恢愎將受到影響。可以使用基於SCN號的恢愎方式，恢復到這個時間區間，恢愎到SCN號所在的這個時間點不受任何影響。

<2> 當基於oracle的應用用到sysdate時，您向後調整系統時鐘時，可以通過停應用一段時間(向後調整的時間差)來使您的應用的業務邏輯保持一致。

本文来自优快云博客，转载请标明出处：http://blog.youkuaiyun.com/dodola/archive/2004/12/20/223235.aspx