「iThome 第七屆鐵人賽 29」系統備份與還原(I)

熱門文章 (Popular Post)

Posted by : Duran Hsieh 2015-01-07



前情提要:

寫到今天,才發現oracle database很多內容可以描述,原本打算後面沒有東西可以講的時候,來說明接上ASP.net MVC 5來開發專案,但講到今天為止,才講到了備份與還原的基本觀念。到鐵人賽30天後,我會補充前面的內容,讓內容更完整。

另外,還有很多像是oracle的架構說明、校能調教與資料移動的時候如何處理等議題還沒有說明,後續我會在自己的部落格上接續後面的內容。

--

這篇內容雖然是說備份與還原,但實際的內容是資料庫系統相關資料的灰複方法。

我將簡單說明資料庫運作中,可能發生某些錯誤,而如何去解決或處理這些問題;或者是資料庫組態檔案移失,該怎麼去復原,維持資料庫正常運作。

一個DBA的職務,就是要維持資料庫正常運作,提供使用者操作使用。DBA職務如下:

1.避免資料庫發生常見的失敗或錯誤

2.增加平均故障的間隔時間(mean-time-between-failure),確保硬體可用性。 oracle提供兩種方式增加MTBF,如real application cluster與stearms

3.降低平均恢復時間(mean time to recover),提前練習恢復操作流程與備份。

4.資料損失達到最低,oracle提供了三種方式,如Archive、standby database與guard。



錯誤大致上分類可以分成:

1.使用者程序錯誤:通常oracle在背景程式(Process Monitor,PMON)會執行,每隔一段時間檢查使用者程序是否可以連線,若使用者程序當掉後會自動rollback未commit的改變與踢掉該使用者程序的所有locks。所以管理者並不需要去手動恢復使用者程序,而是去觀察甚麼原因造成這些使用者程序中斷,進而判斷原因。

2.敘述錯誤:SQL語法錯誤,如select、insert等錯誤。這個部份的錯誤,DBA通常需要處理的內容為使用者是否有權限,或者資料庫空間是否足夠。

3.網路錯誤:連線到資料庫失敗,持續刪除多餘的連線是最好處理的方法。

4.使用者錯誤:使用者操作上的錯誤,如輸入錯誤資料。若使用者尚未commit資料,DBA可以rollbak使用者的操作;若使用者已經commit,DBA則必須flashback queries檢查前一個資料數值是否存在。若flashback因為redo log已經執行而無法使用,DBA仍可以透過oracle LogMiner恢復資料。

DBA可以透過SQL interface查詢online redo logs 與 archive redo logs。這些進階方法,我們後續在說明。

5.Instance 錯誤: 資料庫無預警的被關閉

CheckPoint(CKPT):

oracle database每三秒左右,CKPT會紀錄某些資訊在Control file中。這些資訊為:把被修改的資料區塊從SGA寫入到disk進行儲存,而每一個區塊稱為一個checkpoint。

CKPT主要目的是要辨識online redo log file中,可以從哪一個位置進行還原,這個位置我們稱為checkpoint position。

CKPT原先存在的目的:

一、確保每個在記憶體中被修改資料區能正常的寫入disk,而不會因為系統諱資料庫錯誤導致資料移失。

二、降低instance恢復的時間。redo log 會追蹤最後一個checkpoint,進而降低恢復的時間。

三、確保每個Commit的資料有被寫入。



Redo log file and LogWriter:

Redo log file會紀錄資料庫一個transaction的結果與oracle四福氣多個行為。redo log file目的在於保戶資料庫的完整性,當電源中斷或磁碟損毀,Redo log file能確保這些資料不會因為這些事件而導致資料移失。

redo log 由一組redo log file所組成,且包含多個複本。

每一個可辨識的複本為一個group中的成員,而每一個group藉由一個number進行辨識。

LogWriter(LGWR) process會寫入redo 紀錄給一個group中的所有成員,直到這個file滿了或者被要求更換group,才換下一個group。



Archiver:

是一個選擇性的背景程序。當磁碟移失的時候,Archiver是很重要恢復資料庫關鍵。剛剛有說明redo log group的轉換方式:每一個group滿了後,就換下一個group。在group轉換的同時,此程序就會初始化,並把前一個online redo group的資料儲存下來。因此,資料庫會完全保留變更的內容,我們可以成功將資料庫狀態回復到磁碟損壞之前。

我們可以設定ARCHIVE 模式:

一、在NOARCHIVELOG模式:redo log會被複寫,當轉換發生時。

二、在ARCHIVELOG模式:在被複寫之前,將滿的redo log group的內容保存下來。



Instance Recovery:

Instance crash發生在開啟資料庫的時候,上一次關閉資料庫未同步相關組態檔案導致所導致,系統將利用redo log group自動進行Instance Recovery。

有兩種不同的操作選項

Rolling forward:將data file恢復到instance faile之前的狀態。

Rolling back:改變資料內容,但未commit的資料恢復到原始狀態。

還原的步驟:

一、同步data files

二、Roll forward(redo)

三、commited 與 noncommited data in files

四、Roll back(undo)

五、commited data in files


MTTR Advisor:

下一篇,我們會提到media 錯誤與相關內容:


Leave a Reply

Subscribe to Posts | Subscribe to Comments

- Copyright © Duran Hsieh @ Duran 的技術冶煉廠 - Date A Live - Powered by Blogger - Designed by Johanes Djogan -