重做日誌是對用戶的DML和DDL操作所做的記錄，它是保證資料庫安全的一種重要手段。當用戶執行DML或DDL命令時，資料庫伺服器將生成重做日誌，並將其記錄在重做日誌文件中。為了保證重做日誌文件的安全，需要對它們進行歸檔。 如果資料庫出現故障，可以利用重做日誌文件和歸檔日誌文件進行實例恢復或者介質恢復。 ...
重做日誌是對用戶的DML和DDL操作所做的記錄，它是保證資料庫安全的一種重要手段。
當用戶執行DML或DDL命令時，資料庫伺服器將生成重做日誌，並將其記錄在重做日誌文件中。
為了保證重做日誌文件的安全，需要對它們進行歸檔。
如果資料庫出現故障，可以利用重做日誌文件和歸檔日誌文件進行實例恢復或者介質恢復。
無論是重做日誌文件還是歸檔日誌文件，都是以二進位的形式記錄重做日誌的。
用戶如果需要瞭解這些文件的內容，就需要對它們進行分析，將日誌信息轉化為文本形式。
下麵主要內容包括重做日誌文件的管理、歸檔日誌文件的管理以及日誌分析等內容。
與重做日誌有關的內容較多，接下來首先對這些內容做一次綜合介紹，以使對重做日誌有個全面、深刻的認識。
當用戶執行SQL語句時，在用戶進程和伺服器進程之間需要建立一條連接。
用戶進程向伺服器進程發送SQL語句，伺服器進程對這些SQL語句進行解析，並生成執行計劃，然後將解析代碼和執行計劃存儲在SGA 的庫緩衝區中，然後按照執行計劃執行SQL語句。
在執行階段，伺服器進程首先檢查用戶訪問的數據是否已經位於資料庫高速緩存中。
如果是，則直接在資料庫高速緩存的緩衝區中訪問數據，否則，需要從數據文件中將對應的數據塊讀到資料庫高速緩存中。
如果用戶的SQL命令是DML或DDL ，那麼在訪問數據之前首先生成重做日誌，並將重做日誌記錄在重做日誌緩衝區中，然後修改資料庫高速緩存中的緩衝區。
被修改的緩衝區叫做臟緩衝區。
重做日誌緩衝區是SGA的一部分，它的作用是記錄資料庫中的重做日誌。
重做日誌是對用戶執行的DML或DDL操作的記錄，其中包括被修改的數據塊、修改的位置以及修改後的數據等信息。
重做日誌緩衝區的大小由初始化參數LOG_BUFFER指定。
當實例啟動時，在記憶體中按照這個參數的值為重做日誌緩衝區分配記憶體空間。
從上面的描述可以看到，當用戶在修改數據時，伺服器進程首先生成重做日誌，然後才修改緩衝區中的數據。
無論是重做日誌還是被修改後的數據，都是位於記憶體中的。
由於記憶體中的數據是易消失的， Oracle提供了兩個後臺進程，用於將這些數據寫入磁碟上的文件中。
其中DBWR 的作用是在一定的時機下將資料庫高速緩存中的臟緩衝區寫入數據文件， LGWR進程的作用是在一定的時機下將重做日誌緩衝區中的內容寫入重做日誌文件。
DBWR和LGWR 進程的執行時機並不是同步的，但是在DBWR 工作之前， LGWR一定將重做日誌寫入了重做日誌文件中。
用戶在進行一次數據訪問時，儘管被修改的數據可能已經寫入了數據文件，重做日誌也可能寫入了重做日誌文件，但這次訪問並不一定是一個有效的事務，因為對資料庫所做的任何修改都必須同時記錄在數據文件、控制文件和重做日誌文件中。
Oracle是通過SCN來維護這個一致狀態的。
資料庫伺服器每執行一個事務，都將產生一個新的、遞增的SCN 。
如果用戶沒有提交事務，新的SCN是不被寫入任何一個文件的。
這時如果系統突然斷電，那麼資料庫伺服器在重新啟動時， SMON後臺進程將檢查數據文件、控制文件和重做日誌文件中的SCN ，並回滾所有的未提交事務，然後打開資料庫。
如果用戶在訪問數據之後提交了事務，那麼重做日誌緩衝區的重做日誌連同最新的SCN一起被寫入重做日誌文件。
既然SCN和重做日誌一起被寫入了重做日誌文件，實例恢復和介質恢復就成為可能。
如果發生了系統斷電或者數據文件損壞等情況，可以根據重做日誌文件的內容對資料庫中的數據進行恢復。
用戶提交事務後，最新的SCN僅僅寫入了重做日誌文件，而數據文件和控制文件中SCN的寫入則依賴於檢查點。
檢查點是一種資料庫事件，當資料庫伺服器發生檢查點時， DBWR進程將資料庫高速緩存中的所有臟緩衝區寫入數據文件，並且使數據文件、控制文件和重做日誌文
件中的SCN達到一致狀態。
檢查點是由後臺進程CKPT發出的， CKPT進程在一定的時機發生檢查點，同步數據文件、控制文件和重做日誌文件的狀態。
假設在用戶提交事務後CKPT進程恰好發出一個檢查點，這時三種文件的狀態完全一致，如果這時系統突然斷電，那麼資料庫伺服器在重新啟動時，可以直接打開資料庫，不需要進行實例恢復，所以這次啟動會很快。
如果在用戶提交事務後CKPT還沒有來得及發出檢查點時系統突然斷電，那麼資料庫伺服器在重新啟動時就需要進行實例恢復。
在這種情況下，數據文件和控制文件中的SCN應該是一致的，並且小於重做日誌文件中的SCN 。
SMON後臺進程將檢測到三個文件中的SCN 不一致，於是將兩個SCN之間的所有已經提交的事務重新執行一遍，並回滾所有未提交的事務，然後再打開資料庫。
Oracle利用這種方法來保證用戶已經提交的事務不受系統故障的影響。
當用戶執行DML操作時，伺服器進程將修改前的數據首先寫入回滾段，然後在資料庫高速緩存中對數據進行修改。
如果用戶提交了事務，回滾段中的數據成為無效數據。
如果用戶回滾了該事務，那麼回滾段中的數據將被寫回原來位置，用戶對這些數據所做的修改便宣告無效。
因為重做日誌緩衝區的大小是有限的，而且它不能永久存儲數據，因此重做日誌需要被寫入重做日誌文件。
在資料庫中一般有若幹個重做日誌組，每個日誌組中有若幹個日誌成員，資料庫伺服器以迴圈的方式將重做日誌寫入這些重做日誌組。
當一組重做日誌文件被寫滿後，資料庫伺服器自動切換到下一個日誌組。
當最後一組重做日誌文件被寫滿後，資料庫伺服器又自動切換到第－組。
在資料庫伺服器切換日誌時，新的重做日誌被寫入重做日誌文件，文件中原來的內容將被覆蓋。
為了保留以前的重做日誌，需要對重做日誌文件進行歸檔。
重做日誌文件的歸檔是由後臺進程ARCH完成的。
重做日誌的規劃
在創建資料庫之前，對重做日誌進行詳細的規劃是很有必要的。
重做日誌的規劃包括重做日誌緩衝區規劃、重做日誌組規劃以及重做日誌文件的規劃。
通過對重做日誌進行規劃，不僅可以提高資料庫系統的性能，而且能夠保證重做日誌的安全。
重做日誌緩衝區的規劃
當用戶執行一個事務時，伺服器進程首先生成重做日誌，並記錄在重做日誌緩衝區中，而不是將其直接寫入重做日誌文件中，這樣做的好處當然是因為記憶體的讀寫速度比硬碟快得多。
在重做日誌緩衝區中可以存儲多條重做日誌， LGWR後臺進程在一定的時機下一次將多條重做日誌全部寫入重做日誌文件，這樣可以減少寫磁碟的次數，從而提高資料庫的性能。
重做日誌緩衝區是一段迴圈使用的存儲區，重做日誌將從緩衝區的頭部開始，依次寫入緩衝區的各個部分。
當最後一部分緩衝區被寫滿時，重做日誌又重新被寫入緩衝區的開始部分。
在一定的時機下， LGWR進程將緩衝區中的重做日誌寫入重做日誌文件，並清空這一部分重做日誌所占用的存儲區。
例如，當重做日誌緩衝區1/3 的存儲空間被寫滿時， LGWR進程便開始工作。
重做日誌緩衝區的大小由初始化參數LOG_BUFFER指定，這個參數的值越大， LGWR進程寫入磁碟文件的次數就越少。
因此，只要電腦的記憶體足夠大，儘可能為重做日誌緩衝區分配更大的存儲區，這樣可以減少磁碟寫操作的次數，從而提高系統的性能。
重做日誌文件組的規劃
資料庫中的重做日誌文件是分組的，在一個資料庫中至少需要兩個日誌組，日誌組的最大數目由永久性參數MAXLOGFILES 限定，這個數目在創建資料庫時就已經確定。
在資料庫中創建多個重做日誌組的主要目的是為了對重做日誌文件進行歸檔，因為當資料庫正在使用一個重做日誌文件時，是不能對它進行歸檔的，只有當切換到下一個日誌組時，才能對它進行歸檔。
其次，使用多個日誌組可以節約磁碟空間，如果只有一個日誌組，那麼所有的重做日誌都將被寫入這組重做日誌文件，文件的大小將無限制地增加，從而消耗大量的磁碟空間。
重做日誌是以迴圈的方式被寫入各個重做日誌組的。
如圖所示，當資料庫伺服器剛開始運行時，重做日誌被寫入第一個日誌組，當第一個日誌組中的重做日誌文件被寫滿時，資料庫伺服器將自動切換到第二個日誌組，重做日誌將接著被寫入第二個日誌組，依此類推。
當最後一個日誌組被寫滿後，資料庫伺服器將自動切換到第一個日誌組，這樣重做日誌便被寫入第一個日誌組。
當資料庫伺服器再次使用一個日誌組時，這組重做日誌文件中以前的內容將被新的重做日誌覆蓋。
在對重做日誌文件進行規劃時，應該選擇合適的日誌組數目。
如果日誌組太多，可能會消耗太多的磁碟空間。
如果日誌組太少，可能會影響資料庫的性能。
如果資料庫處於歸檔日誌模式下，當資料庫伺服器切換到下一個日誌組時， ARCH進程要對剛剛使用過的日誌組進行歸檔。
如果歸檔的速度較慢，或者資料庫伺服器寫日誌的速度較快，那麼可能在日誌歸檔還沒有結束時，資料庫伺服器又切換到了這個日誌組。
當資料庫伺服器試圖使用一個尚未歸檔或者歸檔未結束的日誌組時， LGWR進程將被阻塞，用戶事務將無法執行，直到歸檔結束。
如果在資料庫中有上述情況發生，在資料庫的警告文件中將產生這樣的警告信息：
“ checkpoint incomplete ”。
雖然這種情況持續的時間並不長，但是對資料庫性能的影響是比較大的。
解決這種問題的最直接的辦法是在資料庫中增加日誌組，或者將目前的重做日誌文件替換為更大的文件。
重做日誌組數目的選擇需要一定的經驗，資料庫管理員可以在資料庫的運行過程中不斷觀察，在不影響LGWR進程工作的前提下，將日誌組的數目設置為最小的可能值。
如果發生了LGWR進程被阻塞的情況，在警告文件和LGWR進程的跟蹤文件中將產生相應的信息。
資料庫管理員在設置重做日誌組時，可以不斷觀察這個文件的內容，以判斷是否有這種情況發生。
現在以一個實際的例子來說明重做日誌組太少，或者重做日誌文件太小對資料庫系統所造成的不利影響。
在某個實際的生產系統中，資料庫管理員經常接到用戶的抱怨。
在業務最繁忙的時段內，用戶進程向資料庫中寫入一行數據需要等待50秒左右。
通過對資料庫進行診斷後發現，在該資料庫中每天大約產生3GB 的重做日誌，而資料庫中當時只有三個重做日誌組，每個組中的成員只有50MB 。
通過進一步對重做日誌文件的歸檔情況進行觀察發現，在業務最繁忙的時段內，一個重做日誌組被寫滿所用的時間大約為2分鐘，而對一個重做日誌組進行歸檔所
用的時間大約為4分鐘，而且在警告文件中有大量的警告信息：“checkpoint incomplete ”。
在找到問題發生的原因後，解決這個問題就很簡單了。
在該資料庫中另外增加了6個重做日誌組，每個日誌組的日誌成員大小為200MB ，然後刪除了以前的三個重做日誌組，這個問題基本上就解決了。
如何對重做日誌文件進行規劃
在每一個重做日誌組中，至少有一個重做日誌文件，日誌組中的重做日誌文件叫做日誌成員。
重做日誌組中的日誌成員在資料庫創建時已經確定，在資料庫的運行過程中也可以添加新的日誌成員。
重做日誌對於資料庫的恢復起著重要的作用。
如果重做日誌文件丟失或者損壞，那麼在資料庫發生故障時，可能無法對數據進行完全恢復。
對於重做日誌文件，應該採取特殊的措施來保證它的可用性。
一般要求一個重做日誌組中至少有兩個日誌成員，這些重做日誌文件的內容、大小完全相同，它們互為鏡像。
LGWR後臺進程將把重做日誌同時寫入日誌組的所有日誌成員。
當其中一個日誌成員丟失或損壞時， LGWR進程將被阻塞。
資料庫管理員可以利用其他完好的日誌成員複製一個新的日誌成員，資料庫伺服器則可繼續正常運行。
為了防止磁碟發生故障，一般要求同一個日誌組中的各個日誌成員分別存儲在不同的磁碟上，這樣即使其中一個磁碟發生故障，其他磁碟上的日誌成員的內容仍然是完好的。
下圖表示日誌成員的鏡像情況。
在圖中有三個日誌組，每個日誌組有兩個日誌成員，它們分別存儲在兩個磁碟上。
需要註意的是，同一個日誌組的日誌成員大小完全相同，但不同日誌組的日誌成員可以有不同的大小，而且不同日誌組的成員數目也可以不同。
在資料庫伺服器運行的過程中， LGWR迸程可能會遇到以下異常情況：
·某個重做日誌組中的一個日誌成員不可用。LGWR進程將忽略不可用的日誌成員，把重做日誌寫入其他可用的日誌成員。
·某個重做日誌組正在被歸檔或者尚未歸檔。LGWR進程將等待該重做日誌組被歸檔完成。
·某個重做日誌組中的所有日誌成員都不可用。在資料庫伺服器進行日誌切換時，該日誌組對LGWR進程不可用，資料庫實例將自動關閉。
·當前重做日誌組中的所有日誌成員突然都不可用。因為LGWR進程無法寫重做日誌，資料庫實例將自動關閉。
重做日誌文件的管理
在創建資料庫時，重做日誌組與日誌成員的數目已經確定。
在資料庫的運行過程中，可以根據需要增加重做日誌組和日誌成員的數目。
重傲日誌組的最大允許數目由永久參數MAXLOGFILES 限定，每個日誌組最大允許的日誌成員數目由永久參數MAXLOGMEMBERS限定。
如果重做日誌組或日誌成員的數目已經達到規定的極限，就需要重新創建控制文件，增加永久參數的值。
在Oracle 11g的資料庫中，這兩個永久性參數是可以突破的。
重做日誌組和日誌成員的數目也可以根據需要適當地減少。
如果日誌成員的存儲位置不合適，還可以改變它們的存儲位置和名稱。
增加重做日誌組
在一個小型應用系統中，由於用戶的事務較少，兩個重做日誌組就可能足夠使用。
對於大型的應用系統，用戶的事務非常繁忙，需要更多的重做日誌組來記錄重做日誌。
如果日誌組太少，可能會發生這樣的情況： LGWR進程在向一個重做日誌組中寫入重做日誌時，發現這個重做日誌組尚未歸檔，或者歸檔尚未結束，於是LGWR進程不得不等待歸檔的結束，整個資料庫伺服器的運行也將暫時停止。
出現上述情況的原因是重做日誌組太少，資料庫管理員應該增加重做日誌組的數目，以免因為重做做日誌組太少而影響資料庫的性能。
增加重做日誌組的命令是ALTER DATABASE ，在這條命令中使用ADD LOGFILE子句指定重做日誌組的組號以及該日誌組中每個日誌成員的名稱及大小。
例如：
ALTER DATABASE ADD LOGFILE GROUP 4
('D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO41.LOG',
'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO42.LOG') SIZE 200M;
重做日誌組的組號應該為現有的最大組號加1 。
當然，也可以不指定組號，這時資料庫伺服器將按照這個原則自動分配組號。
例如：
ALTER DATABASE ADD LOGFILE 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO51.LOG' SIZE 200M;
增加日誌成員
如果一個重做日誌組中只有一個日誌成員，那麼資料庫管理員可能需要向這個日誌組中添加新的日誌成員。
當日誌組中的一個日誌成員損壞時，資料庫管理員需要刪除這個日誌成員，然後再添加一個。
添加日誌成員的命令是ALTER DATABASE ，在這條命令中通過ADD LOGFILE MEMBER子句指定新的日誌成員，並通過TO子句指定目標重做日誌組。
例如：
ALTER DATABASE ADD LOGFILE MEMBER 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO022.LOG' TO GROUP 2;
修改重做日誌文件的位置和名稱
在資料庫的運行過程中，有時可能會根據需要修改重做日誌文件的存儲位置或名稱。
假如一個日誌組的所有成員存儲在同一個磁碟上，為了防止磁碟故障，有必要將這些成員存儲在不同的磁碟上。
重做日誌文件的信息是記錄在控制文件中的，修改重做日誌文件的名稱或存儲位置就意味著修改控制文件中的信息。
在資料庫中無法真正實現重做日誌文件的移動或重命名，這一點需要在操作系統下完成。
因此，要實現重做日誌文件的移動或重命名，需要將資料庫伺服器切換到MOUNT狀態，這時控制文件已經打開，而重做日誌文件尚未打開。
首先，關閉資料庫。
註意應該以NORMAL方式關閉資料庫，確保所有的用戶事務正常結束。
接下來需要在操作系統下將重做日誌文件移動到新的存儲位置，或者修改它的名稱。
然後將資料庫伺服器啟動到MOUNT 狀態。修改重做日誌文件的位置或名稱的命令是ALTER DATABASE ，在這條命令中通過RENAME FILES子句修改重做日誌文件的位置或名稱。
實際上，通過這種方法也可以修改數據文件的位置和名稱。
例如，以下語句將重做日誌文件REDO51.LOG 的位置改為“\oracle\product\10.2.0\oradata\ ”，並將名稱修改為REDO52.LOG。
ALTER DATABASE RENAME FILE 'D:\oracle\product\10.2.0\oradata\orcl\REDO51.LOG' TO'D:\oracle\product\10.2.0\oradata\REDO52.LOG';
多個重做日誌文件的位置和名稱可以通過同一條語句來修改。
例如，下麵的語句同時將重做日誌文件redo41.log和redo42.log修改為新的名稱。
ALTER DATABASE REAME FILE
'D:\oracle\product\10.2.0\oradata\orcl\REDO41.LOG', 'D:\oracle\product\10.2.0\oradata\orcl\REDO42.LOG'
TO
'D:\oracle\product\10.2.0\oradata\orcl\REDO410.LOG', 'D:\oracle\product\10.2.0\oradata\orcl\REDO420.LOG';
刪除重做日誌文件
在一些情況下，需要將某個重做日誌組或日誌成員刪除。
例如，由於某個日誌成員損壞而導致整個重做日誌組不可用，這時需要將損壞的日誌成員刪除。
刪除日誌組時，日誌組中的所有日誌成員都將被刪除。
為了保證資料庫伺服器的運行，應該保證至少有兩個日誌組可用。
另外，如果日誌組的狀態為“CURRENT”，那麼該日誌組是不能刪除的，這時必須進行日誌組的切換。
“CURRENT”狀態表明資料庫伺服器當前正在使用該日誌組。
在刪除日誌組之前，應該先查詢日誌組的狀態。
例如：
SELECT group#, status FROM v$log;
下麵是有關動態性能視圖v$log的相關信息：
V$LOG displays log file information from the control file.
| Column | Datatype | Description |
|---|---|---|
|
|
|
Log group number |
|
|
|
Log thread（線程） number |
|
|
|
Log sequence number |
|
|
|
Size of the log (in bytes) |
|
|
|
Block size of the logfile (512 or 4096) |
|
|
|
Number of members in the log group |
|
|
|
Archive status ( |
|
|
|
Log status:
|
|
|
|
Lowest（最低） system change number (SCN) in the log |
|
|
|
Time of the first SCN in the log |
|
|
|
Highest change number (SCN) in the log. When |
|
|
|
Time of the highest SCN in the log. When |
|
|
|
The ID of the container to which the data pertains. Possible values include:
|
刪除日誌組的命令是ALTER DATABASE ，通過DROP LOGFILE子句指定要刪除的日誌組。
例如，以下語句用於刪除日誌組5:
ALTER DATABASE DROP LOGFILE GROUP 5;
為了保證重做日誌的連續性，在歸檔模式下刪除一個重做日誌組時，應先對其進行歸檔。
重做日誌組的歸檔狀態也可以通過查詢動態性能視圖v$log獲得。
當重做日誌組被刪除後，所有的日誌成員都將被刪除。
在有些情況下，僅需要刪除日誌組的某些日誌成員，其餘成員仍然保留。
比如當某個重做日誌文件損壞時，應該將該日誌成員刪除，以保證資料庫伺服器的正常運行。
刪除日誌成員時，不能刪除重做日誌組中唯一的成員。
為了保證重做日誌文件的安全，應該保證日誌組中至少有兩個成員。
當某個日誌組中僅剩一個日誌成員時，應該及時添加其他的日誌成員。
如果某個日誌組處於“CURRENT”狀態，不能刪除該重做日誌組中的任何成員，
這時必須手工切換日誌，使重做日誌組的狀態切換為“INACTIVE”狀態。
刪除日誌成員的命令仍然是ALTER DATABASE ，在命令中通過DROP LOGFILE MEMBER子句指定要刪除的日誌成員。
因為重做日誌文件的位置和名稱是唯一的，因此，不需要指定該日誌成員所屬的重做日誌組。
例如，下麵的語句用於刪除重做日誌組5的日誌成員REDO52.LOG:
ALTER DATABASE DROP LOGFILE MEMBER 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO52.LOG';
當一個重做日誌組或一個日誌成員被刪除後，對應的重做日誌文件並沒有被真正刪除。為
了徹底刪除重做日誌文件，還需要在操作系統中手工執行刪除操作。
下麵是有關動態性能視圖v$logfile相關信息：
V$LOGFILE contains information about redo log files.
| Column | Datatype | Description |
|---|---|---|
GROUP# |
NUMBER |
Redo log group identifier number |
STATUS |
VARCHAR2(7) |
Status of the log member:
|
TYPE |
VARCHAR2(7) |
Type of the logfile:
|
MEMBER |
VARCHAR2(513) |
Redo log member name |
IS_RECOVERY_DEST_FILE |
VARCHAR2(3) |
Indicates whether the file was created in the fast recovery area (YES) or not (NO) |
重做日誌文件的清空
不僅可以刪除重做日誌組和日誌成員，還可以請空重做日誌文件的內容。
在資料庫的運行過程中，如果由於重做日誌文件的損壞而導致歸檔操作無法進行，資料庫伺服器的運行最終將停止，在這種情況下，可以將重做日誌文件的內容全部清空。
清空重做日誌文件的操作可以在不關閉資料庫的情況下進行，即使資料庫中只有兩個日誌組，或者該重做日誌所屬日誌組的狀態為“CURRENT ”。
清空重做日誌文件的命令是ALTER DATABASE ，在這條命令中通過CLEAR LOGFILE子句指定要清空的日誌組，執行清空操作時一個重做日誌組中的所有日誌成員都將被清空。
例如，
下麵的語句用於清空重做日誌組5中的所有日誌成員：
ALTER DATABASE CLEAR LOGFILE GROUP 5;
如果要清空的重做日誌組尚未歸檔，則需要使用UNARCHIEVED關鍵字。
例如：
ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 5;
以上語句在清空尚未歸檔的重做日誌文件時，避免對其進行歸檔。
儘管沒有歸檔，但被清空的重做日誌文件可再次使用了。
需要註意的是，如果清空了尚未歸檔的重做日誌文件，應該對資料庫進行一次備份。
如果－個重做日誌組被清空，而在進行資料庫恢復時恰好需要這個組的重做日誌文件，那麼恢復操作將無法進行。
資料庫伺服器將把這種無法進行的恢復情況寫入警告文件。
重做日誌的切換
資料庫伺服器在運行過程中， LGWR後臺進程將重做日誌寫入重做日誌文件。
當第一個日誌組寫滿後， LGWR將自動切換到第二個日誌組，並將重做日誌寫入第二個日誌組。
依此類推，當最後一個日誌組被寫滿後， LGWR將自動切換到第一個日誌組，這個迴圈的過程是自動進行的。
在有些特殊的情況下，需要手工切換日誌，在當前重做日誌組尚未寫滿的時候，強制LGWR進程將重做日誌寫入下一個日誌組。
比如，要刪除當前日誌組時，需要先強制切換日誌。
手工切換重做日誌的命令是ALTER SYSTEM ，執行手工切換重做日誌任務的用戶需要有ALTER SYSTEM系統許可權。
命令的完整格式為：
ALTER SYSTEM SWITCH LOGFILE
無論是自動切換還是手工切換，當發生重做日誌的切換時，日誌序列號將自動加一，日誌序列號和當前的SCN被寫入控制文件。
隨後CKPT後臺進程將發出檢查點，將SCN寫入控制文件和數據文件，然後撤活DBWR後臺進程，將資料庫高速緩存中的臟緩衝區寫入數據文件。
儘管重做日誌組是迴圈使用的，但是日誌序列號卻是無限遞增的。
每次發生重做日誌的切換時，資料庫伺服器為當前重做日誌組指定一個日誌序列號，這個序列號是在前一個序列號的基礎上加一而得的。
在對重做日誌文件進行歸檔時，這個序列號被一起寫入了歸檔日誌文件。
重做日誌文件和歸檔日誌文件就是通過重做日誌序列號來唯一地標識的。
在進行資料庫的恢復時，將按照序列號遞增的順序依次查找所需的重做日誌文件和歸檔日誌文件。
註：在切換日誌時，是根據SEQUENCE#列的值，而不是GROUP#組號。
重做日誌信息的查詢
與重做日誌文件有關的動態性能視圖有以下三個：
• v$log ：記錄重做日誌文件組的信息。
• v$logfile ：記錄重做日誌文件的信息。
• v$log_history ：記錄重做日誌組的切換信息。
其中從動態性能視圖v$log可以查詢重做日誌文件組的組號、序列號、大小、是否歸檔、狀態等信息。
例如，以下語句將獲得每個重做日誌組的成員數目、序列號和大小等信息：
SELECT group#,sequence#,bytes/1024/1024 AS MB FROM v$1og;
下麵的查詢語句將獲得每個重做日誌組是否歸檔、狀態以及最小的SCN等信息：
SELECT archived,status,first_change# FROM v$log;
從動態性能視圖v$1ogfile中可以獲得每個重做日誌組中的日誌成員及其狀態等信息。
例如：
SELECT group#,member,status FROM v$logfile;
下麵是有關動態性能視圖v$log_history的相關信息：
V$LOG_HISTORY displays log history information from the control file.
| Column | Datatype | Description |
|---|---|---|
RECID |
NUMBER |
Control file record ID |
STAMP |
NUMBER |
Control file record stamp |
THREAD# |
NUMBER |
Thread number of the archived log |
SEQUENCE# |
NUMBER |
Sequence number of the archived log |
FIRST_CHANGE# |
NUMBER |
Lowest system change number (SCN) in the log |
FIRST_TIME |
DATE |
Time of the first entry (lowest SCN) in the log |
NEXT_CHANGE# |
NUMBER |
Highest SCN in the log |
RESETLOGS_CHANGE# |
NUMBER |
Resetlogs change number of the database when the log was written |
RESETLOGS_TIME |
DATE |
Resetlogs time of the database when the log was written |
歸檔日誌管理
對於實際的生產系統來說，重做日誌文件的歸檔是非常重要的。
歸檔日誌管理主要包括修改資料庫的日誌模式、指定歸檔文件的位置和名稱、手工對重做日誌文件進行歸檔等內容。
資料庫的日誌模式
資料庫伺服器有兩種日誌模式：歸檔模式和非歸檔模式。
在非歸檔模式下，當一個重做日誌組被寫滿時， LGWR進程將自動切換到下一個重做日誌組，這個重做日誌組中以前的重做日誌將被覆蓋。
而在歸檔模式下，每個重做日誌組在被覆蓋之前都要進行歸檔，生成一個歸檔日誌文件。
重做日誌文件的歸檔對於資料庫的安全有著重要的意義：如果資料庫被破壞，利用重做日誌和歸檔日誌可以進行完全恢復。
如果沒有對重做日誌文件進行歸擋，那麼只能進行不完全恢復。
現在舉個例子來說明歸檔日誌的作用。
假設某資料庫有三個重做日誌組，在周一的時候資料庫管理員對資料庫做了一次完全備份，以後每天都做一次增量備份，到周四的時候資料庫被破壞。
資料庫管理員首先可以利用最近的一次完全備份將資料庫恢復到周一時的狀態，然後依次利用後面的增量備份把資料庫一直恢復到周三時的狀態。
如果資料庫處於非歸檔模式下，那麼周三到周四的數據將無法恢復。
如果資料庫處於歸檔模式下，在這段時間只要發生過日誌切換，就會產生歸檔日誌文件，資料庫管理員可以利用歸檔日誌和聯機重做日誌將資料庫恢復到發生故障之前的狀態。
由此可見，在進行數據的恢復時，最後一段時間沒有被備份的數據完全是依靠重做日誌來恢復的。
在預設情況下，資料庫初始處於非歸檔模式下，資料庫管理員可以將資料庫在兩種日誌模式之間進行切換。
如果要確定資料庫當前所處的日誌模式，可以執行命令ARCHIVE LOG LIST 。
資料庫的日誌模式還可以通過以下SELECT語句獲得：
SELECT log_mode FROM v$database;
以下是動態性能視圖v$database的相關信息：
V$DATABASE displays information about the database from the control file.
| Column | Datatype | Description |
|---|---|---|
|
|
|
Database identifier calculated when the database is created and stored in all file headers |
|
|
|
Name of the database |
|
|
|
Creation date of the database. If the control file was re-created using the |
|
|
|
System change number (SCN) at open resetlogs |
|
|
|
Timestamp of open resetlogs |
|
|
|
SCN at prior resetlogs |
|
|
|
Timestamp of prior resetlogs |
|
|
|
Archive log mode:
|
|
|
|
Last SCN checkpointed |
|
|
|
Database force archiving SCN. Any redo log with a start SCN below this will be forced to archive out. |
|
|
|
Type of control file:
|
|
|
|
Creation date of the control file |
|
|
|
Control file sequence number incremented by control file transactions |
|
|
|
Last SCN in backup control file; null if the control file is not a backup |
|
|
|
Last timestamp in backup control file; null if the control file is not a backup |
|
|
|
( |
|
|
|
Version time |
|
|
|
Open mode information:
|
|
|
|
Protection mode currently in effect for the database:
|
|
|
|
Aggregated protection mode currently in effect for the database:
Note: This column is an aggregation of the |
|
|
|
Value of the |
|
|
|
Number assigned to the database instantiation |
|
|
|
Number assigned to the database switchover |
|
|
|
Current role of the database:
|
|
|
|
Highest |
|
|
|
Status of the archive log compression ( |
|
|
|
Indicates whether switchover is allowed:
|
|
|
|
Data Guard broker information:
|
|
|
|
Protects data from being changed:
|
|
|
  更多相關文章
一周排行
 所有分類
|