前不久,因為接到用戶投訴,說他們的應用中所產生的時間不一致,導致其產生的報表的產能達成上有一定問題。由於我們各大系統分布於不同的主機上,而各主機的系統時間各自又有一點差異,有的比標准時間稍有提前,有的又有滯後,於是我們因應用戶的需求做了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