Server process : 獨立的 server, shared server.

以上結(jié)構(gòu)中:真正存放在磁盤上的物理文件是圖的下半部分，那么它們具體存放在哪里的，一般來講:

contrl file, redo log file, data file: 存放在 oraData 這個目錄下

oracle軟件一般單獨存放在 : $ORACLE_HOME/product 這個目錄下

在 $ORACLE_HOME 這個目錄里還有個很重要的文件夾, admin 顧名思義，這個文件夾是用來管理的

在 admin 里邊有以下內(nèi)容:

參數(shù) audit_file_dest = $ORACLE_BASE\admin\ADUMP

參數(shù) backgroup_dump_dest = $ORACLE_BASE\admin\BDUMP

參數(shù) user_dump_dest = $ORACLE_BASE\admin\UDUMP

參數(shù) core_dump_dest = $ORACLE_BASE\admin\CDUMP

其中：

adump : 審計

bdump : 后臺 trace 和 alert log

cdump : core trace,? 只有數(shù)據(jù)庫出問題時，這個目錄才有文件，一般不用看。

pfile ： 初始化參數(shù)文件 init， 這并不是真正的 初始化參數(shù)文件的地方.

udump: 用戶進(jìn)程跟蹤文件

---------------------------------------------------------------------------

dbs 目錄下， 其中:

真正初始化參數(shù)文件所在位置 : $ORACLE_HOME\dbs目錄

password file位置 : $ORACLE_HOME\dbs ( 密碼文件查找順序:? orapw<sid>-- orapw -- Failure(錯誤)

archivelog file: 你可以自己制定位置和格式

?

I/O server processes: dbwn 異步寫，有些操作系統(tǒng)不支持異步寫，這些進(jìn)程是為 dbwn 來服務(wù)的，模擬異步存儲

如果你不顯示指定 large pool(設(shè)置 large_pool_size 參數(shù)), large pool 會占用 SGA.(從shared pool 中分配)

?

large pool 用處, 當(dāng)執(zhí)行 RMAN 是可以使用 large pool 的內(nèi)存, 另外就是dbwn 異步寫的時候.

Large Pool Parameters

LARGE_POOL_SIZE: if this parameter is not set, then there is no large pool. The specified size of memory is allocated from the SGA.

select * from v$sgastat where pool = 'large pool';? -- 看到?jīng)], 是從 v$sgastat 中查看 large pool 的大小.

DBWR_IO_SLAVES: This parameter specifies the number of I/O slaves used by the DBWn process. The DBWn process and its slaves always write to disk. By default, the value is 0 and I/O slaves are not used.

BACKUP_TAPE_IO_SLAVES: It specifies whether I/O slaves are used by the Recovery Manager to backup, copy, or restore data to tape.

讀數(shù)據(jù)是由 server process 讀( server process 可以直接跟讀磁盤內(nèi)容 )， dbwn 的主要作用是寫數(shù)據(jù)

DBWn background process: writes the dirty buffers from the database buffer cache to the data files.

你可以指定多個 DBWn 來使操作的性能提高, 例如 DBW1, DBW2 …

當(dāng)然會有 uncommited data 存儲在datafile 中, 例如: 你創(chuàng)建一個新的 table, 并且數(shù)據(jù)庫的Buffer cache 是 100M, 現(xiàn)在你開始插入數(shù)據(jù), 一次性插入1000W條數(shù)據(jù), 那么此時由于 buffer cache 大小不夠(假如說), 那么就的把 數(shù)據(jù)存儲在 datafile中, 而此時的數(shù)據(jù)時 uncommited, 同樣, redo log file 也是一樣, 并不一定非的等待用戶的commit之后才將redo log buffern 中的內(nèi)容寫入磁盤, 記住, redo log 只是記錄對數(shù)據(jù)庫修改的每一條記錄, 它的作用只是用來恢復(fù)的, 跟實際數(shù)據(jù)寫入磁盤沒有多大關(guān)系, 以前理解錯誤了, 以為所有的數(shù)據(jù)都要通過commit以后才會被寫入磁盤, 另外, server process 修改數(shù)據(jù)的內(nèi)容都是在內(nèi)存的 buffer cache 中修改的, 如果 buffer cache 中沒有你想要的數(shù)據(jù), 那么server process 會去磁盤里讀, 但是放到哪里呢? 當(dāng)然是內(nèi)存, 計算機除了內(nèi)存, 還能在哪處理數(shù)據(jù)呢 ?

對數(shù)據(jù)庫的任何改變信息，都存儲在 redo log buffer(一會一存儲, 不比一定要等待commit, 比如再commit之前, redo log buffer 1/3滿了, 那么就將 redo log buffer 中的內(nèi)容寫入了數(shù)據(jù)庫, 另外, 這個操作是將所有的 redo log buffer 中的內(nèi)容都寫入了 online redo log file, 其中包括uncommit的)

commit 并不是真正的將數(shù)據(jù)寫到 datafile里，而是將 redo log buffer 的相應(yīng)數(shù)據(jù)寫到了 redo 磁盤中

undo , index, data 修改時，都會在 redo log buffer 中體現(xiàn)

以上是 commit

Before DBWn writes modified block 之前要把 redo log buffer 中的內(nèi)容寫入磁盤。

聯(lián)機重做日志要用最快的磁盤(頻繁的寫)

checkpoint : 就是把 database buffer 中的臟數(shù)據(jù)真正將的寫入數(shù)據(jù)文件中 (磁盤)

?

檢查點絕對恢復(fù)從哪個位置開始( checkpoint )

checkpoint position: 是存儲在連接重做日志中的一個點，在這個點之前的，redo log file 和 data file 都寫入完成了(貌似這時才實現(xiàn)一個同步, 確實)

Checkpoints synchronize the buffer cache by writing all buffers to disk whose corresponding redo entries were part of the log file being checkponted.

Checkpoint Process(CKPT) Features

• The CKPT process is always enabled.
• The CKPT process updates file headers at checkpoint completion.
• More frequent checkpoints reduce the time needed for recovering from instance failure at the possible expense of performance.

另外, 之前理解錯誤是, 檢查點是一個干凈的點, 就是恢復(fù)可以參考檢查點的, 但是, 實際上, 檢查點只是將所有的 data buffer cache 中的內(nèi)容寫入磁盤, 注意此時并非是干凈的, 因為還有很多 uncommited 數(shù)據(jù)被同時寫入磁盤, 不過此時應(yīng)該說是同步的, 因為檢查點之前會觸發(fā) redo log switch, 這樣, 貌似 DBWn 與 LGWR 同步了

因為檢查點是同步的, 所以檢查點以前的內(nèi)容肯定是同步的, 所以如果有檢查點的話, 恢復(fù)的時候, 從最后一個檢查點開始就可以了, 然后根據(jù) redo 和 archivelog 等或者根據(jù)backup文件來恢復(fù).

Synchronization 同步的

• At each checkpoint, the checkpoint number is updated in every database file header and in the control file.
• The checkpoint number acts as a synchronization marker for redo, control, and datafiles. if they have the same checkpoint number, the database is considered to be in a consistent state.
• Information in the control file is used to confirm that all files are at the same checkpoint number during database startup, Any incosistency between the checkpoint numbers in the various file headers results in a failure, and the database cannot be opened. Recovery is required.

Instance Recovery

Checkpints expedite instance recovery because at every checkpoint all changed data is written to a disk. After data? resides in datafiles. redo log entires before the last checkpoint need not be applied again during the roll forward phase of instance recovery.

checkpoint queue: 在內(nèi)存中的，一個隊列，臟數(shù)據(jù)，需要寫到數(shù)據(jù)磁盤，這里記錄的每條數(shù)據(jù)主要也是地址，例如 databuffer cache中的臟數(shù)據(jù)的地址， redo log file 等等 相應(yīng)的地址，另外這些條數(shù)據(jù)構(gòu)成了隊列，按照這個隊列的順序，來進(jìn)行對磁盤的修改。

檢查點類型

1 全類型 ：所有的臟數(shù)據(jù)都寫到數(shù)據(jù)文件中，一般發(fā)生在 shutdown 等等

2 增量類型 ：把很大的 checkpoint 分成很小的多個 checkpoint 頻繁的發(fā)生 check point.

3 partial : 對表空間操作時，與表空間相關(guān)的臟數(shù)據(jù)，都會寫入磁盤數(shù)據(jù)文件中

?

redo log file : 是循環(huán)使用，media recovery 對原來的 redo log file 還是要使用的，所以如果被覆蓋了， 就很難再做 media recovery, 所以，會將該內(nèi)容寫在 Archived log files 中

redo log file 被覆蓋之前，必須被歸檔

data guard : 就是將 archive log file 寫到遠(yuǎn)端

An Oracle database cannot be opened unless all datafiles, redo logs, and control files are synchronized. In this case, recovery is required.

For the database to open, all datafiles must have the same checkpoint number, unless they are offline or part of a read-only tablespace.

Archived and online redo log files recover committed transactions and roll back uncommitted transactions to synchronize the database files.

Archived and online redo log files are automatically requested by the Oracle server during the recovery phase. Make sure logs exist in the requested location.

注意: undo 這部分內(nèi)容是在磁盤上的, 而非在內(nèi)存中.

例如: 斷電了

1. 發(fā)生了不同步現(xiàn)象, 例如突然斷電了

2. 先是向前滾, 即將所有的在 redo log files 從上一個最后的檢查點之后, 重做一遍. (這個操作同樣會產(chǎn)生 Undo 或 rollback 數(shù)據(jù) )

3. 現(xiàn)在 data file 中既包括 commit , 又包括 uncommit 的數(shù)據(jù), (因為是按照redo log file 全部操作了一遍, 所以肯定有uncommit數(shù)據(jù))

4. 回滾階段, 回滾那些沒有被commit的內(nèi)容

5. 現(xiàn)在 datafile 中只包括那些 commit 數(shù)據(jù)了.

前滾階段(Roll forward phase)

During the roll forward phase, Oracle replays transactions in the online redo log beginning with the checkpoint position. The checkpoint position in the place in the redo log where changes associated with previous redo entries had been saved to the datafiles before the failure(Each data file, in its header, has a checkpoint structure the contents gets incremented every time LGWR issures a checkpoint to the DBWR. The checkpoint structure has two structures checkpoint counter and SCN) At the coclusion of roll forward phase, the data files contain all committed changes, as well as new uncommitted changes(applied during roll forward) 也就是在重做日志文件的同時也會產(chǎn)生新的undo, 這個就是所謂的, 新的undo segment, 而同時, 由于系統(tǒng)沒有failure 以前, 也有很多 undo segment 內(nèi)容, 這部分內(nèi)容是舊的 segment 內(nèi)容,? 注意 undo 里的內(nèi)容.

回滾階段

During the rollback phase, Oracle searches out changes associated with dead transactions that bad not commited before the failure occurred.(注意: 這里只查找 failure 發(fā)生以前的內(nèi)容,(舊的undo segment) 而不是 undo segment 的全部內(nèi)容, 因為 undo segment 中還包含新的undo segment, 而這部分內(nèi)容是不需要回滾的).這步完成以后, oracle database 就同步了, 就可以被 open 了.

?

When the database is opened a start SCN is recorded in the control file for every data file associated in the database and a stop SCN is set to infinity.

During normal dtabase operation’s. The SCN and the checkopint counter, information in the data file header is incremented every time a checkpoint is done.

When the database is shutdown with the normal or immediate option, an end SCN is recorded in the data file header, This information is also recorded in the control files. for example : end SCN of the datafile is equal to the stop SCN of the control file.

When database is opened the next time, Oracle makes two checks:

• if end SCN in the data file? header matches its corresponding stop SCN in the control file.
• if checkpoint in the data file header matches its corresponding checkpoint in the control file.

Let us say you shutdown the database in ABORT mode:

• checkpoint is not performed and the stop SCN in the control file is left at infinity(the same state when you started or opened your data files)
• For example end SCN in the datafile header is “1000” and stop SCN in the control file is “infinity”

in this case Oracle performs crash recovery and as a part of crash, Oracle reads the on-line redo log files and applies the changes to the database as a part of the roll forward and reads the rollback segment’s transaction table to perform transaction recovery(rollbackward)

?

調(diào)優(yōu)恢復(fù)的過程

系統(tǒng)指標(biāo): 性能，可用性

看來, 如果檢查點頻繁的出現(xiàn)的話, 會改善 recovery , 因為操作是從上一個檢查點開始的.

user-specified bounds: 用戶指定指標(biāo)

最新版本的 oracle, 提供了一個新的參數(shù)用來配置該內(nèi)容，就是第1個參數(shù) FAST_START_MTTR_TARGET

我們系統(tǒng)設(shè)置的是 FAST_START_MTTR_TARGET= 300

所以，只要這個參數(shù)就可以了。這個值設(shè)置的不恰當(dāng)，比如1秒，那么oracle會根據(jù)自己系統(tǒng)的限制來計算出來合適的值

做完了 重做日志 重做后， oracle 數(shù)據(jù)庫就 open了。還有 undo 沒有回滾呢

增加進(jìn)程，來處理，SMON指揮一些別的進(jìn)程幫助處理

---

轉(zhuǎn)載

在ITPUB 論壇上看到一個有關(guān)實例恢復(fù)時 前滾（roll forword）和回滾（roll back）的討論。在這里小整理一下，也理理自己的一個思路。

?

一. 什么時候需要實例恢復(fù)

?????? 在shutdown normal or shutdown immediate下，也就是所謂的clean shutdown，checkpoint也會自動觸發(fā)，并且把SCN紀(jì)錄寫回。 當(dāng)發(fā)生checkpoint時，會把SCN寫到四個地方：

?

三個地方于control file內(nèi)：

（1）SYSTEM CHECKPOINT SCN

（2）Datafile checkpoint SCN

（3）Stop SCN

?

一個在datafile header內(nèi)：

Start SCN

?

1.1 Clean shutdown 時

?????? 當(dāng)clean shutdown 時，checkpoint會進(jìn)行，并且此時datafile的stop scn和控制文件里的start scn會相同。 等到open數(shù)據(jù)庫時，Oracle檢查datafile header中的start scn和存于control file中的datafile的scn是否相同， 如果相同，接著檢查start scn和stop scn是否相同，如果仍然相同，數(shù)據(jù)庫就會正常開啟，否則就需要recovery。

?????? 等到數(shù)據(jù)庫開啟后，儲存在control file中的stop scn就會恢復(fù)為NULL值，此時表示datafile是open在正常模式下了。

?

1.2 非正常shutdown

?????? 如果不正常SHUTDOWN (shutdown abort)，則mount數(shù)據(jù)庫后，會發(fā)現(xiàn)stop scn并不是等于其它位置的scn， 而是等于NULL，這表示Oracle在shutdown時沒有進(jìn)行checkpoint，下次開機必須進(jìn)行crash recovery（實例恢復(fù)）。

?

注意一點：

?????? （1）啟動數(shù)據(jù)庫時，如果發(fā)現(xiàn)STOP SCN = NULL，表示需要進(jìn)行crash recovery；

?????? （2）啟動數(shù)據(jù)庫時，如果發(fā)現(xiàn)有datafile header的START SCN 不等于儲存于CONTROLFILE的DATAFILE SCN，表示需要進(jìn)行Media recovery

?

1.3 crash recovery 順序問題

?????? 必須先進(jìn)行roll forward(從redo log file中從目前的start SCN開始，重做后面的已提交之交易)。 再從roll back segment 做rollback未完成(dead transaction)交易。檢驗controlfile中的SCN會等于datafile header的SCN

?

二. Crash Recovery 過程

?????? 當(dāng)數(shù)據(jù)庫突然崩潰，而還沒有來得及將buffer cache里的臟數(shù)據(jù)塊刷新到數(shù)據(jù)文件里，同時在實例崩潰時正在運行著的事務(wù)被突然中斷，則事務(wù)為中間狀態(tài)，也就是既沒有提交也沒有回滾。這時數(shù)據(jù)文件里的內(nèi)容不能體現(xiàn)實例崩潰時的狀態(tài)。這樣關(guān)閉的數(shù)據(jù)庫是不一致的。

?

?????? 下次啟動實例時，Oracle會由SMON進(jìn)程自動進(jìn)行實例恢復(fù)。實例啟動時，SMON進(jìn)程會去檢查控制文件中所記錄的、每個在線的、可讀寫的數(shù)據(jù)文件的END SCN號。

?????? 數(shù)據(jù)庫正常運行過程中，該END SCN號始終為NULL，而當(dāng)數(shù)據(jù)庫正常關(guān)閉時，會進(jìn)行完全檢查點，并將檢查點SCN號更新該字段。

?????? 而崩潰時，Oracle還來不及更新該字段，則該字段仍然為NULL。當(dāng)SMON進(jìn)程發(fā)現(xiàn)該字段為空時，就知道實例在上次沒有正常關(guān)閉，于是由SMON進(jìn)程就開始進(jìn)行實例恢復(fù)了。

?

?????? SMON進(jìn)程進(jìn)行實例恢復(fù)時，會從控制文件中獲得檢查點位置。于是，SMON進(jìn)程到聯(lián)機日志文件中，找到該檢查點位置，然后從該檢查點位置開始往下，應(yīng)用所有的重做條目，從而在buffer cache里又恢復(fù)了實例崩潰那個時間點的狀態(tài)。這個過程叫做前滾，前滾完畢以后，buffer cache里既有崩潰時已經(jīng)提交還沒有寫入數(shù)據(jù)文件的臟數(shù)據(jù)塊，也還有事務(wù)被突然終止，而導(dǎo)致的既沒有提交又沒有回滾的事務(wù)所弄臟的數(shù)據(jù)塊。

?

?????? 前滾一旦完畢，SMON進(jìn)程立即打開數(shù)據(jù)庫。但是，這時的數(shù)據(jù)庫中還含有那些中間狀態(tài)的、既沒有提交又沒有回滾的臟塊，這種臟塊是不能存在于數(shù)據(jù)庫中的，因為它們并沒有被提交，必須被回滾。打開數(shù)據(jù)庫以后，SMON進(jìn)程會在后臺進(jìn)行回滾。

?

?????? 有時，數(shù)據(jù)庫打開以后，SMON進(jìn)程還沒來得及回滾這些中間狀態(tài)的數(shù)據(jù)塊時，就有用戶進(jìn)程發(fā)出讀取這些數(shù)據(jù)塊的請求。這時，服務(wù)器進(jìn)程在將這些塊返回給用戶之前，由服務(wù)器進(jìn)程負(fù)責(zé)進(jìn)行回滾，回滾完畢后，將數(shù)據(jù)塊的內(nèi)容返回給用戶。

?

?

三. 為什么數(shù)據(jù)庫的實例恢復(fù)是先前滾再回滾

?

?????? 回滾段實際上也是以回滾表空間的形式存在的，既然是表空間，那么肯定就有對應(yīng)的數(shù)據(jù)文件，同時在buffer cache 中就會存在映像塊，這一點和其他表空間的數(shù)據(jù)文件相同。

?????

?????? 當(dāng)發(fā)生DML操作時，既要生成REDO（針對DML操作本身的REDO Entry）也要生成UNDO（用于回滾該DML操作，記錄在UNDO表空間中），但是既然UNDO信息也是使用回滾表空間來存放的，那么該DML操作對應(yīng)的UNDO信息（在BUFFER CACHE生成對應(yīng)中的UNDO BLOCK）就會首先生成其對應(yīng)的REDO信息（UNDO BLOCK's REDO Entry）并寫入Log Buffer中。

?

?????? 這樣做的原因是因為Buffer Cache中的有關(guān)UNDO表空間的塊也可能因為數(shù)據(jù)庫故障而丟失，為了保障在下一次啟動時能夠順利進(jìn)行回滾，首先就必須使用REDO日志來恢復(fù)UNDO段（實際上是先回復(fù)Buffer Cache中的臟數(shù)據(jù)塊，然后由Checkpoint寫入UNDO段中），在數(shù)據(jù)庫OPEN以后再使用UNDO信息來進(jìn)行回滾，達(dá)到一致性的目的。

?????? 生成完UNDO BLOCK's REDO Entry后才輪到該DML語句對應(yīng)的REDO Entry，最后再修改Buffer Cache中的Block，該Block同時變?yōu)榕K數(shù)據(jù)塊。

?

?????? 實際上，簡單點說REDO的作用就是記錄所有的數(shù)據(jù)庫更改，包括UNDO表空間在內(nèi)

總結(jié)

以上是生活随笔為你收集整理的Instance and Media Recovery Structures的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。