Oracle的重做日志基本概念及原理
重做日志文件 redo log file 通常也稱為日志文件，它是保證數據庫安全和數據庫備份與恢復的文件，是數據庫安全和恢復的最基本的保障。管理員可以根據日志文集和數據庫備份文件，將崩潰的數據庫恢復到最近一次記錄日志時的狀態。所以在日常工作當中，管理員維護重做日志文件也是十分必要的。
1、概述
重做日志文件用於記錄事務操作所引起的數據的變化，包括回滾段事務表、回滾塊、數據塊上的事務槽、數據行的變化等，當執行DDL、DML操作時，有LGWR進程將日志緩沖區中與事務相關的重做記錄寫入到重做日志文件中。當丟失或損壞數據庫中的數據時，Oracle會根據redo文件中的記錄 恢復丟失的數據。
1.1史記講解法來理解日志記錄的原理
buffercache里面有一堆的buffer，假設在buffercache上站着一個人，它能夠看到buffercache里面所有的buffer，而且這個人眼睛特別快，對buffercache來講大量的sql語句執行，在一個時間其中的某個buffercache中的塊被改了，下一個時間另外一個buffercache中的塊被改了，時間差了幾毫秒，就是說在短時間內，大量的buffer被修改了，然后這個人就拿着一個本在記錄，嚴格按照時間來記錄buffer的一個改變過程，機上在這個時間點哪個buffer發生什么樣的改變。也就是說這個人，以極快的速度嚴格的按照時間順序來記錄buffer的一個改變過程，這些日志會記錄到logbuffer里面去，最后logbuffer會通過LGWR這個進程寫到磁盤上的redolog里面去。
也就是說，我們的日志記錄的是BUFFER的改變，並且按照時間順序記錄的，所以說日志里面記錄的就是buffer里嚴格的按照時間順序記錄的buffer的整個改變過程。日志記錄的是buffer的改變，日志是以buffer為單位來記錄的，一個塊的改變至少記錄一條日志，安裝改變的時間順序來記錄的。
1.2、日志記錄方式
Oracle要記錄這個buffer的改變：
一記錄buffer地址也就是磁盤中數據塊的地址
二時間點哪個時間改變的
三對這個數據塊做了什么改變。
比如我們執行了一個delete的語句，刪除了一萬行，這一萬行在一千個塊里，這時我們大體粗略的認為產生了一千條日志，因為針對每一個塊都產生一條日志。
1.3、時間日志產生的過程
oracle實例連接很多客戶端會話，每一個會話都分到一個小塊內存pga，客戶會話Oracle用server process處理，每個serverprocess都會產生一個pga，都有可能修改buffercache中的一個buffer，server process會將磁盤block塊讀到buffer里面去，會從內存buffer里面讀到CPU里面去，也會修改buffer數據，所有的這些訪問都是server process來做的，當然臟數據塊寫會的時候是使用的DBWR進程。server process每修改一次buffer的時候它會自己產生日志，先寫到自己的PGA里面去，當寫到一定程度的時候，它再從PGA寫到logbuffer里面去，第二個serverprocess也一樣。當修改某個buffer的時候它也會產生日志，也會從PGA寫到logbuffer里面去。
實際的日志產生的過程：
serverprocess修改buffer產生日志寫到自己的PGA里面去，在某些觸發的條件下，會把日志寫到logbuffer里面去，最終又通過進程LGWR寫到磁盤的redolog里面去。
2.1、 Oracle中的事務
Oracle有一個原則，所有已提交事務Oracle保證不會丟失，一個事務是由一條和多條增刪改數據組成一個事務，就是一條或多條DML語句。關系型數據庫的標准語言為結構化查詢語言（STRUCTURED QUERY LANGUAGE），最多可分為六個類型：
數據查詢語言（DQL:data query language）:如select語句
數據操作語言（DML:data manipulation language）:如Insert update delete 等
數據定義語言（DDL:data definition language）:如create dop alter等
數據控制語言（DCL:data control language）:如grant revoke deny等語句
事務處理語言（TPL:transaction process language）:如begin transaction commit rollback savepoint等語句
指針控制語言（CCL:cursor control language）:如declare sursor、fetch into、update where current等語句
事務和Oracle的一致性關系非常緊密，很多人就是因為在事務這個概念上沒有注意。最后導致數據庫的數據被損壞。在實際中事務很簡單，事務就是由一條或多條增刪改語句組成，比如，登陸數據庫以后，開始一條delete語句，一個事務開始了，然后commit一個事務就結束了，commit以后再輸入一條增傷語句的時候，一個事務又開始了，我們可以這么認為一個事務的開始和結束是在兩個commit之間。
2.2、事務提交方法
2.2.1、假設提交是將修改的數據寫到磁盤上
一個事務提交，將該事務所修改的塊寫到磁盤上，然后才是提交成功，就如客戶端上我們操作很多dml語句后，執行COMMIT后，要過很久光標才返回。在提交一個事務的時候，如果這個事務修改了大量的塊，commit的話，如果需要把臟數據塊寫到磁盤上，DBWR需要將這些大量的臟數據寫到磁盤，需要消耗大量的IO，很耗時，用戶等待commit完成需要很長時間，這樣的話會感覺數據塊很慢，所以說commit后，Oracle將該事務涉及的所有臟數據都寫到磁盤上是不現實的。
2.2.2、事務的提交實際方法
一條事務開始以后，進行了DML操作以后，在修改的過程會產生很多的日志，這些日志在這個會話的PGA里面產生，產生以后會批量的快速的寫到logbuffer里面去，logbuffer因為有空間限制、時間限制等，LGWR會相對較快的把日志寫到redolog里面去。
會話serverprocess修改塊的過程中產生很多日志，日志寫到logbuffer，logbuffer由后台進程LGWR寫到磁盤上，整個過程產生的日志都在logbuffer里面，logbuffer也會往redolog里寫。Oracle在commit的時候，一提交Oracle就會觸發LGWR把logbuffer的日志寫到磁盤。
日志寫的好處：
1、logbuffer寫到redolog，在一個時間點只往一個redolog文件寫入，每一個redoLog在磁盤上都是一塊連續的空間，所以日志寫的時候，尋道的次數會很少，而且是順序寫，臟數據寫的時候磁盤位置很多時候是離散的。
2、當事務提交，Oracle只需觸發LGWR把剩余的日志寫到磁盤上就可以了。。
3、日志記錄了數據塊的所有的改變，一個數據快改變了，和磁盤上就不一樣了，提交的時候沒有把buffercache里的臟數據寫到DBF，但是把臟塊的修改記錄以日志的形式記錄下來，如果以后數據庫崩潰了，之前已提交未寫到磁盤上的臟數據可以通過日志前滾再次寫到磁盤上。
2.2.3、快速提交
以上兩點已經闡述了為什么會快速的把日志寫到redolog中了，當會話進行COMMIT時，Oracle知識把logbuffer中的日志快速的寫到redolog中，並沒有實際把buffer寫會磁盤，所以說對用戶來講，commit速度快，就認為Oracle很快，一旦光標返回就可以做下一件事。
3、日志和計算機緩存
緩存在很多軟件上進行應用，對於計算機而言，有讀緩存有寫緩存。計算機中，讀緩存是吧數據塊調到內存中，讀的時候可以到緩存里面去找，CPU去讀這個塊，只能讀這個塊，如果CPU要修改這個塊，不能直接在內存修改，要修改需要直接修改磁盤上的，修改磁盤會產生IO，讀緩存支隊讀有意義對寫性能很低下，它知識能提高讀的性能對寫沒有性能提高。Oracle因為實現了日志機制，修改了一個buffer塊產生logbuffer日志馬上寫會磁盤redolog，commit以后一直保證寫，commit就成功了。
在Oracle里面，Oracle的各種buffercache實現了寫緩存，對寫的塊和對產生的日志寫會磁盤進行緩存，所以對Oracle來講實現了寫緩存，日志寫緩存的實現是通過日志的buffercache也就是logbuffer，它不僅僅對讀有意義，對寫也有意義。Oracle的buffercache不僅能提高讀性能，還能提高性能。在整個計算機里面，Oracle數據庫里面能夠提高寫緩存的只有兩個地方，還有一個就是存儲上的BUFFER，Oracle數據庫很多都是建在各類型的存儲上，存儲上有buffer，buffer上有電池，也就是存儲的buffer支持寫緩存，存儲中的單個硬盤本身也有緩存，只支持讀緩存。
在整個Oracle的運行環境中，buffercache提供寫緩存，文件系統也有緩存，只支持讀緩存，不能寫緩存。一般內存和磁盤的數據交換都要經過文件系統，內存的數據在從磁盤讀取時要經過文件系統的讀緩存，內存的數據在向磁盤寫入時也要經過文件系統但此時文件系統不提供緩存，當然Oracle的存儲體系實際工作中很少建在文件系統上，這樣讀寫也不經過操作系統的文件系統了，Oracle讀數據，先從磁盤到存儲的buffer然后到文件系統的buffer再到buffercache。Oracle寫數據時，redolog在存儲上，LGWR寫的時候會繞過文件系統的緩存，即繞過文件系統中的cache，這個cache只能緩存讀，直接將日志寫到存儲的緩存里面，然后存儲會控制在適當的時候寫到磁盤里面去，存儲的寫緩存通過電池來實現的，為了保證數據不丟失要使用電池，當commit時，實際上數據庫使用LGWR只是把數據從logbuffer寫到存儲的cache里，到底有沒有寫到磁盤上，數據庫並不知道。如果存儲出問題，電池沒電了，這時數據就會丟失了，這時候redolog也可能損壞，這個需要注意。
commit提交以后，保證我這個事務所修改的所有的數據塊對應的日志都已經寫到redolog里面去了，數據庫突然崩潰了，就是buffer里面的臟塊沒有了，數據庫下次啟動以后，就可以使用這些redolog把那些丟失的臟塊再重新構造出來，就是能夠將數據庫恢復到崩潰前的那個時刻，也就是不會出現數據丟失。Oracle數據庫數據恢復有實例恢復INSTANCE RECOVERY和介質恢復MEDIA RECOVERY，上面就是說的實例恢復。
實例恢復是Oracle實例出現失敗后，Oracle自動進行的恢復，數據庫出現實例故障，如斷電、后台進程故障、或使用abort命令終止實例，在啟動數據庫時就會發現實例故障，此時就需要實例恢復，實例恢復是數據庫自動進行的，可以將數據庫恢復到故障之前的事務一致性狀態。它可以確保buffer cache中的數據不會丟失，只用到redolog，不使用歸檔。
介質恢復主要用於介質故障引起數據庫文件的破壞時使用，當存檔數據庫的介質出現故障時所做的恢復，介質故障時當一個文件、文件的一部分或磁盤不能讀寫時出現的故障，文件錯誤一般指意外的錯誤導致文件被刪除或意外事務導致文件的不一致，這些狀態下的數據庫都是不一致的，需要DBA手工進行數據庫的恢復。介質恢復用在丟失或損壞數據文件或控制文件的情形，將還原的數據文件恢復成當前數據文件，還能恢復數據文件異常脫機時沒有來得及做檢查點操作丟失的變更，介質恢復使用歸檔日志和聯機日志，但必須由命令顯示調用，即手工進行。
Oracle是通過日志保證已經提交的數據不會丟失，同時實現快速提交。
4、LGWR的觸發條件
a、用戶提交
b、有1/3重做日志緩沖區未寫入磁盤
c、有大於1M的重做日志緩沖區未被寫入磁盤
d、每隔3秒
e、DBWR需要寫入的數據的SCN大於LGWR記錄的SCN，DBWR觸發LGWR寫入
Oracle有這么一個機制，一個buffer臟了，Oracle保證這個buffer在寫到磁盤以前，這個buffer變臟所做的操作對應的日志一定是寫到磁盤了，就是DBWR被觸發了，它要將40個臟塊寫到磁盤上，這個時候Oracle保證40個臟塊所對應的日志已經寫到磁盤上了，如果沒有就寫到磁盤就先觸發LGWR寫到磁盤，然后DBWR再往磁盤上寫。對於Oracle來講日志總是先於buffer寫到磁盤上，日志寫入優先機制。
5、log優化建議
數據庫按進行的大多數數據處理情況可分為兩種應用類型：
OLTP，聯機事務處理（online transaction processing）系統是傳統的關系型數據庫的主要應用，表示事務性非常高的系統，並行事務處理多，但是一般都很短，使用一般用途活事務處理模板。
OLAP，聯機分析處理（online analytical process）系統是數據倉庫系統的主要應用，支持復雜的分析操作，側重決策支持，並且提供直觀易懂的查詢結果，數據量大，DML少，使用數據倉庫模板。正常的數據庫一般都是OLTP。
在OLTP系統上，redo log文件的寫操作主要是小型的，比較頻繁，一般的寫大小在幾K，而每秒鍾產生的寫IO次數會達到幾十次，數百次神指上千次。因為redo log文件適合存在於IOPS較高的轉速較快的磁盤上。另外由於redo log文件的寫入是串行的，因為對於redo log文件所做的底層條帶化處理，對於redo log寫性能的提升是十分有限的。
redolog放到存儲上，對硬盤來講有一個參數較IOPS(input/output operations per sccond)，每秒進行讀寫IO操作的次數，多用於OLTP數據庫、小文件存儲等場合，衡量磁盤隨機訪問的性能。整體來講硬盤有stat盤，sas盤，fc盤，還有固態盤，對IOPS來講從stat到sas到fs到ssd一次增加，ssd硬盤它的iops會達到幾十萬，當然不同的固態硬盤的IOPS性能差距是非常大的，它跟硬盤不一樣，富士通的硬盤和希捷的硬盤都是sas盤他們的性能差不多，但是固態盤性能差距較大。
LGWR的特點是在寫日志時：第一非常頻繁，寫的次數很多，每秒的IO次數很高，要求磁盤的IOPS必須很高；二每次寫的量比較小；三它是順序寫，一個磁盤文件LGWR從logbuffer中順序望redolog磁盤文件里寫。
raid5raid6甚至包括raid10、raid01都是條帶化，一塊數據被條帶的分布到多個硬盤上，可以並發，條帶在這里沒有意義，redolog不要放在raid5raid6上，因為他們的寫性能很差，當然可以放到raid10和raid01上，最好放到固態盤上，現在狠多存儲里面可以有一部分固態盤，同時還有一部分硬盤。如果redolog確實是因為IOPS非常高導致LGWR工作負擔很大、寫的很慢，產生一堆問題，這個問題很難解決的話，非常簡答但涉及到硬件投資，采購固態硬盤，把你的redolog寫進去，固態盤不需要很大，一個G就夠了。
6、logbuffer設置多大
9i以前一般是3M，在10G以后Oracle會自動調整他的大小，它遵循這樣一個原則，fixed sga size + redo buffers 是granule size的整數倍。
6.1、粒度
Oracle把它的sga和pga內存給它分成一個叫granule（粒度）的東西，這個粒度大小是Oracle自動去調整的，大小由一個隱含參數_ksmg_granule_size決定，最終分配的內存量都是這個參數的整數倍，sga組件buffer cache shared pool等都是按granule的整數倍來分配和釋放的。
在Oracle9i中，sga<128M時，粒度值是4M，否則粒度依平台不同值可能為8M或16M，
在10G中這個參數的大小一般遵循如下原則：
sga_max_size <=1024m then _ksmg_granule_size=4m
sga_max_size >=1024m then _ksmg_granule_size=16m
另外在32位windows平台sga大於1G時參數默認值為8M
這個參數調整並不是任意的，還收到sga總量的限制，如果sga不夠，即使調整參數也不會生效，只能調整到系統能夠認到的最大值，可以使用alter system set "_ksmg_granule_size"=16777216 scope =spfile;調整它的值，重啟數據庫生效，在手動調整后還是要再由Oracle決定大小，最終又可能的值有4M 8M 16M。
執行一個sql語句看下粒度多大：
select * from v$sgainfo where name in ( 'Fixed SGA Size','Redo Buffers','Granule Size');
NAME BYTES RES
-------------------------------- ---------- ---
Fixed SGA Size 1219016 No
Redo Buffers 7168000 No
Granule Size 4194304 No
如granule size是4M，想給sga分配空間，比如我們給他分配161m，但是Oracle不會給它分配161的，它會用4對161取整，要不就是160要不就是164。粒度起始就是為了防止內存被分成小塊，Oracle內存分配最好4M，防止小碎片的產生。
6.2、redo buffer的大小
原則：fixed sga size + redo buffers 是granule size的整數倍
在上面語句的查詢結果中fixed sga size 1219016 no,fixed sga size的大小就是1m，redo buffer要不就是3M要不就是7M,一般fixed sga size和redo buffers的和是granule size的最小的整數倍。
7、redo log的組成
Oracle初始安裝時redolog一般有三組，
select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARCHIVED STATUS FIRST_CHANGE# FIRST_TIME
1 1 35 52428800 1 NO INACTIVE 1174677 20-10月-16
2 1 36 52428800 1 NO CURRENT 1185401 21-10月-16
3 1 34 52428800 1 NO INACTIVE 1161958 19-10月-16
group有3個就是有三個日志組，membets都是1表示每個日志組有一個成員。
select * from v$logfile;
GROUP# STATUS TYPE MEMBER IS_RECOVERY_DEST_FILE
3 (null) ONLINE /u01/app/oracle/oradata/jiagulun/redo03.log NO
2 (null) ONLINE /u01/app/oracle/oradata/jiagulun/redo02.log NO
1 (null) ONLINE /u01/app/oracle/oradata/jiagulun/redo01.log NO
GROUP#為組號，MEMBER為組的成員，如/u01/app/oracle/oradata/jiagulun/redo03.log，可以每個組兩個成員，這兩個成員完全相等，就是互相備份的關系。redolog重要性比dbf都要重要，dbf可以丟，但是redolog千萬不能丟失。比如我有四個組，每個組兩個成員，一個組其中的一個成員放到一個磁盤上另外一個成員放到另外一個磁盤上，一個磁盤壞了還有另外一個成員，這叫冗余。
我們經常需要對日志進行一些改變，這和數據庫備份恢復有關，備份恢復就是涉及一個體系性的方案，來解決Oracle的數據丟失的問題，將我們數據丟失的損失減少到最少。關於日志如何添加刪除如下：
添加日志組：
alter database add logfile group 5 '/opt/oracle/oradata/dbtest/redo05_1.log' size 10M;
給日志組添加成員：
alter database add logfile member ''/opt/oracle/oradata/dbtest/redo04_3.log' to group 4;
刪除日志組：
alter database drop logfile group 5;
刪除組成員：
alter database drop logfile (''/opt/oracle/oradata/dbtest/redo05_1.log',''/opt/oracle/oradata/dbtest/redo05_2.log');
8、控制日志切換時間
有次一個學生找老師，說用戶給我們提出一個需求，維護數據庫可以丟數據，因為丟數據是沒有辦法的，但丟的額數據不能超過十分鍾，怎么才能保證丟的數據不能超過十分鍾。
其實這是很簡單的一個問題，也是在備份恢復里面重點講的一個東西，你只要知道Oracle的體系結構原理很容易設計出來，我們可以把數據庫控制在用戶提出的需求范圍之內。
redolog切換的時間應該盡可能的不低於10-20分鍾，建議是10-20分鍾之間，這個地方是他控制數據丟失的問題。logbuffer對應redolog，寫的時候先寫第一個redolog，寫滿以后再寫第二個，第一個寫滿了寫第二個的時候叫切換，我們盡量控制寫一個日志文件，從開始寫到寫滿的時間在10-20分鍾之內。根據當前日志的產生的速度我們可以調整它的大小，來控制這個時間。
8.1、調整日志大小
Oracle中redolog日志的大小是不能直接改變的，只能先刪除原日志文件，然后建立新大小的文件。
例如現在蒸菜使用第二組，可把第三組改成20M，當切換寫第三組的時候，再把第二組改成20M；
可以依次新建立三個日志組分配新的大小，然后刪除原來的日志組；
也可以在原三組操作，刪除當前未使用的組，再建立組名想的新組分配新的大小，然后切換當前日志，刪除剩下的那個組，創建新的同名組成員及大小。
8.2、調整日志大小的實際例子
a)進入歸檔模式
因為控制日志切換時間是為了保存住日志，所以讓redolog日志歸檔才有意義，在非歸檔模式雖然也有日志切換，但是切換后都扔掉了，再控制切換時間就沒有意義了。
SQL> select GROUP# ,BYTES/1024/1024 size_M,STATUS,ARCHIVED from v$log;
GROUP# SIZE_M STATUS ARC
---------- ---------- ---------------- ---
1 50 INACTIVE NO
2 50 INACTIVE NO
3 50 CURRENT NO
arc列都為no說明日志處於非歸檔模式，用命令看下當前歸檔模式，
archive log list;
Database log mode No Archive Mode --數據庫日志模式目前非歸檔
Automatic archival Disabled --自動存檔 未啟用
Archive destination USE_DB_RECOVERY_FILE_DEST --歸檔終點
Oldest online log sequence 35 --最早的聯機日志序列
Current log sequence 37 --當前的日志序列
也可以使用select log_mode from v$database;修改歸檔模式，需要重啟數據庫。
先關閉數據庫，shutdown immediate;
再啟動到mount狀態，startup mount再切換至歸檔模式，
alter database archivelog --切換到自動歸檔模式
alter database archivelog manual --切換到手動歸檔模式
alter database noarchivelog --切換到非歸檔模式
最后再打開數據庫，alter database open;
b)修改日志組成員大小
--1、查看當前日志組成員
SQL> select GROUP# ,BYTES/1024/1024 size_M,STATUS,ARCHIVED from v$log;
GROUP# SIZE_M STATUS ARC
---------- ---------- ---------------- ---
1 50 INACTIVE YES
2 50 INACTIVE YES
3 50 CURRENT NO
SQL> select member from v$logfile;
MEMBER
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/jiagulun/redo03.log
/u01/app/oracle/oradata/jiagulun/redo02.log
/u01/app/oracle/oradata/jiagulun/redo01.log
從結果分析當前正在使用第三組，並且第一第二組處於非活動狀態，所以下面刪除第一第二組並重新建第一第二組並建立新大小的成員，因為Oracle每個實例的日志組最少不能少於兩個，所以一二組不能同時刪除，系統不讓都刪了只剩下第三組，需要一次的刪除並且重建。
--2、刪除重建日志組成員
刪除並重建第一組日志
alter database drop logfile group 1;
SQL> select GROUP# ,BYTES/1024/1024 size_M,STATUS,ARCHIVED from v$log;
GROUP# SIZE_M STATUS ARC
---------- ---------- ---------------- ---
2 50 INACTIVE YES
3 50 CURRENT NO
SQL> select member from v$logfile;
MEMBER
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/jiagulun/redo03.log
/u01/app/oracle/oradata/jiagulun/redo02.log
這時在操作系統中，/u01/app/oracle/oradata/jiagulun/redo01.log文件還存在，所以需要手動刪除，mv /u01/app/oracle/oradata/jiagulun/redo01.log /tmp
建新組和成員
alter database add logfile group 1 ('/u01/app/oracle/oradata/jiagulun/redo01.log') size 100M;
用語句再次查看情況
select GROUP# ,BYTES/1024/1024 size_M,STATUS,ARCHIVED from v$log;
select member from v$logfile;
注意只有當日志組為unused（或Inactive）時才能刪除，如果不是該狀態的，需要切換日志組，alter system switch logfile;同樣的操作刪除並重建第二組日志。
重建第三組日志，需要先切換日志組，將其狀態變成Inactive，再進行上述操作刪除添加。
大小都是100M的日志組修改成功，修改系統檢查點不能改變組的unused狀態，需要切換日志后才會進入使用狀態，數據庫重啟不會切換日志，但是active狀態會變成Inactive狀態，這里的status狀態跟是否歸檔沒有關系，active是指活動的非當前日志，在實例恢復時會被用到。active狀態意味着，checkpoint尚未完成，因此該日志文件不能被覆蓋，Inactive是非活動日志，在實例恢復時不再需要但在介質恢復時可能需要。
如果此redolog文件在Oracle進行實例恢復時有用它就是active，在需要進行實例恢復時沒有用了，就是變成Inactive狀態，一般可理解為如果此日志記錄的信息所對應的buffer臟還沒有寫入磁盤它的狀態就是active，如果此日志所記錄的所有改變對應的所有buffer塊已經沒有了臟塊，此日志就轉換為Inactive狀態。
--3、查看切換時間
select to_char(FIRST_TIME,'yyyy-mm-dd hh24:mi:ss') f_time,SEQUENCE# from v$log_history;
--4、archive_lag_target參數
上面的方法控制日志的切換，如不手工切換，最終都是在日志寫滿后自動的切換，想做到20分鍾切換一次，需要根據實例的負載情況計算出日志在要求時間內產生多少，然后把redolog設置成相應的大小，在日志寫滿后進行切換，如果實例出現一次往往日志產生的數據量會發生變化，這樣會造成日志切換並歸檔時間長短的變動，就很難保證在20分鍾就會歸檔保存日志。
但是一個參數可以強制進行日志切換，ARCHIVE_LAG_TRAGET參數可以設置一個時間，通過時間限制，指定數據庫強制進行日志切換，進行歸檔。日志切換后再自動歸檔模式下馬上就會自動進行歸檔，若自動歸檔沒打開，日志切換后就不歸檔當前重做日志。
SQL> show parameter archive_lag_target;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target integer 0
值為0表示禁用基於時間的日志切換功能，修改參數如下：
alter system set archive_lag_target=1200;設置日志切換時間為20分鍾
查看當前數據庫記錄的歸檔日志信息：
sleect name ,completion_time from v$archived_log where name is not null;
非歸檔模式、手動歸檔模式和自動歸檔模式此參數都會使redolog自動切換，但手動模式切換后並不自動歸檔，歸檔需要手動完成，在手動歸檔模式下自動切換日志后若沒有進行及時手動歸檔，當已歸檔日志用完后，Oracle實例就會停止自動切換而被掛起，等待可使用的redolog，並且手動切換日志也會無法執行等待可用日志文件，這是只能感覺給數據庫日志進行手動歸檔，否則數據庫只能讀而不能寫。
非歸檔模式下參數也有效會自動切換日志也可手動切換，但這種模式不要求日志必須歸檔，所以即使所有的日志都沒有歸檔它仍然會不停的切換，不要求有已經歸檔的可用redolog文件，不會造成阻塞，自動模式在切換后會自動進行歸檔。
小結：盡量設置redo log 切換時間在10-20分鍾之內。