Server process : 獨(dú)立的 server, shared server.

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

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

oracle軟件一般單獨(dú)存放在 : $ORACLE_HOME/product 這個(gè)目錄下

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

在 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 : 審計(jì)

bdump : 后臺(tái) trace 和 alert log

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

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

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

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

dbs 目錄下， 其中:

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

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

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

?

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

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

?

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

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 可以直接跟讀磁盤(pán)內(nèi)容 )， dbwn 的主要作用是寫(xiě)數(shù)據(jù)

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

你可以指定多個(gè) DBWn 來(lái)使操作的性能提高, 例如 DBW1, DBW2 …

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

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

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

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

以上是 commit

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

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

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

?

檢查點(diǎn)絕對(duì)恢復(fù)從哪個(gè)位置開(kāi)始( checkpoint )

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

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.

另外, 之前理解錯(cuò)誤是, 檢查點(diǎn)是一個(gè)干凈的點(diǎn), 就是恢復(fù)可以參考檢查點(diǎn)的, 但是, 實(shí)際上, 檢查點(diǎn)只是將所有的 data buffer cache 中的內(nèi)容寫(xiě)入磁盤(pán), 注意此時(shí)并非是干凈的, 因?yàn)檫€有很多 uncommited 數(shù)據(jù)被同時(shí)寫(xiě)入磁盤(pán), 不過(guò)此時(shí)應(yīng)該說(shuō)是同步的, 因?yàn)闄z查點(diǎn)之前會(huì)觸發(fā) redo log switch, 這樣, 貌似 DBWn 與 LGWR 同步了

因?yàn)闄z查點(diǎn)是同步的, 所以檢查點(diǎn)以前的內(nèi)容肯定是同步的, 所以如果有檢查點(diǎn)的話, 恢復(fù)的時(shí)候, 從最后一個(gè)檢查點(diǎn)開(kāi)始就可以了, 然后根據(jù) redo 和 archivelog 等或者根據(jù)backup文件來(lái)恢復(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)存中的，一個(gè)隊(duì)列，臟數(shù)據(jù)，需要寫(xiě)到數(shù)據(jù)磁盤(pán)，這里記錄的每條數(shù)據(jù)主要也是地址，例如 databuffer cache中的臟數(shù)據(jù)的地址， redo log file 等等 相應(yīng)的地址，另外這些條數(shù)據(jù)構(gòu)成了隊(duì)列，按照這個(gè)隊(duì)列的順序，來(lái)進(jìn)行對(duì)磁盤(pán)的修改。

檢查點(diǎn)類(lèi)型

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

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

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

?

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

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

data guard : 就是將 archive log file 寫(xiě)到遠(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)容是在磁盤(pán)上的, 而非在內(nèi)存中.

例如: 斷電了

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

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

3. 現(xiàn)在 data file 中既包括 commit , 又包括 uncommit 的數(shù)據(jù), (因?yàn)槭前凑誶edo log file 全部操作了一遍, 所以肯定有uncommit數(shù)據(jù))

4. 回滾階段, 回滾那些沒(méi)有被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) 也就是在重做日志文件的同時(shí)也會(huì)產(chǎn)生新的undo, 這個(gè)就是所謂的, 新的undo segment, 而同時(shí), 由于系統(tǒng)沒(méi)有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 的全部?jī)?nèi)容, 因?yàn)?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ù)的過(guò)程

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

看來(lái), 如果檢查點(diǎn)頻繁的出現(xiàn)的話, 會(huì)改善 recovery , 因?yàn)椴僮魇菑纳弦粋€(gè)檢查點(diǎn)開(kāi)始的.

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

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

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

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

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

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

---

轉(zhuǎn)載

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

?

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

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

?

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

（1）SYSTEM CHECKPOINT SCN

（2）Datafile checkpoint SCN

（3）Stop SCN

?

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

Start SCN

?

1.1 Clean shutdown 時(shí)

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

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

?

1.2 非正常shutdown

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

?

注意一點(diǎn)：

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

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

?

1.3 crash recovery 順序問(wèn)題

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

?

二. Crash Recovery 過(guò)程

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

?

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

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

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

?

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

?

?????? 前滾一旦完畢，SMON進(jìn)程立即打開(kāi)數(shù)據(jù)庫(kù)。但是，這時(shí)的數(shù)據(jù)庫(kù)中還含有那些中間狀態(tài)的、既沒(méi)有提交又沒(méi)有回滾的臟塊，這種臟塊是不能存在于數(shù)據(jù)庫(kù)中的，因?yàn)樗鼈儾](méi)有被提交，必須被回滾。打開(kāi)數(shù)據(jù)庫(kù)以后，SMON進(jìn)程會(huì)在后臺(tái)進(jìn)行回滾。

?

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

?

?

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

?

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

?????

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

?

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

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

?

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

總結(jié)

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

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