Oracle資料庫啟動是分為三個不同的階段的，分別為nomount、mount和open。在不同的階段，Oracle進行不同的行為，執行不同的操作。在筆者《Oracle啟動三階段》（http://space.itpub.net/17203031/viewspace-684503）系列中，已經進行一定程度的說明。本篇打算從Alert_log，也就是資料庫自身的日誌中，分析啟動三階段的不同行為和操作。

Alert_log是Oracle資料庫執行階段的執行日誌。在Oracle工作時，會將所有會影響到整體效能的操作、變化和錯誤資訊記錄在一個日誌中，就是Alert_log。在Oracle11g中，提供了文字檔案和XML格式檔案兩種日誌格式。對我們來說，Alert_Log是進行資料庫故障診斷、監控和調整的重要研究物件。

環境準備

採用Oracle11g R2 For Linux版本進行研究，具體過程如下。

Last login: Sun Apr 3 10:51:03 2011

[root@oracle11g ~]# ps -ef | grep ora //當前後臺沒有與oracle相關的程式；

root 5514 5481 0 08:28 pts/0 00:00:00 grep ora

[root@oracle11g ~]#

[root@oracle11g ~]# su - oracle

[oracle@oracle11g ~]$ env | grep ORACLE //啟動所必需使用的環境變數；

ORACLE_SID=wilson

ORACLE_BASE=/u01

ORACLE_HOME=/u01/oracle

[oracle@oracle11g ~]$

啟動階段操作

分階段進行啟動操作，之後我們檢視效果。

1、 nomount階段

[oracle@oracle11g ~]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on Tue Apr 5 08:31:25 2011

SQL> conn / as sysdba;

Connected to an idle instance. //當前例項未啟動

SQL> startup nomount

ORACLE instance started. //例項啟動，共享內容空間分配！

Total System Global Area 414298112 bytes

Fixed Size 1336904 bytes

Variable Size 310380984 bytes

Database Buffers 96468992 bytes

Redo Buffers 6111232 bytes

此時，我們觀察後臺活動程式情況，可以看到。

[oracle@oracle11g ~]$ ps -ef | grep ora

oracle 5594 1 0 08:32 ? 00:00:00 ora_pmon_wilson

oracle 5596 1 0 08:32 ? 00:00:00 ora_vktm_wilson

oracle 5600 1 0 08:32 ? 00:00:00 ora_gen0_wilson

oracle 5602 1 0 08:32 ? 00:00:00 ora_diag_wilson

oracle 5604 1 0 08:32 ? 00:00:00 ora_dbrm_wilson

oracle 5606 1 0 08:32 ? 00:00:00 ora_psp0_wilson

oracle 5608 1 0 08:32 ? 00:00:00 ora_dia0_wilson

oracle 5610 1 2 08:32 ? 00:00:00 ora_mman_wilson

oracle 5612 1 0 08:32 ? 00:00:00 ora_dbw0_wilson

oracle 5614 1 0 08:32 ? 00:00:00 ora_lgwr_wilson

oracle 5616 1 0 08:32 ? 00:00:00 ora_ckpt_wilson

oracle 5618 1 0 08:32 ? 00:00:00 ora_smon_wilson

oracle 5620 1 0 08:32 ? 00:00:00 ora_reco_wilson

oracle 5622 1 0 08:32 ? 00:00:00 ora_mmon_wilson

oracle 5624 1 0 08:32 ? 00:00:00 ora_mmnl_wilson

oracle 5626 1 0 08:32 ? 00:00:00 ora_d000_wilson

oracle 5628 1 0 08:32 ? 00:00:00 ora_s000_wilson

oracle 5630 1 0 08:32 ? 00:00:00 ora_s001_wilson

oracle 5632 5547 1 08:32 ? 00:00:00 oraclewilson (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

在nomount狀態，雖然沒有涉及到資料檔案讀取、控制檔案讀取等內容。但是最重要的資料庫例項已經建立。核心後臺程式PMON、DBWn、LGWr、SMON和CKPT已經建立，共享記憶體SGA區已經分配。

2、 Mount狀態

進入mount狀態

SQL> alter database mount;

Database altered.

3、 Open

進入Open狀態

SQL> alter database open;

Database altered.

SQL> select count(*) from scott.emp;

COUNT(*)

----------

14

日誌分析

根據系統引數可以獲取到alert_log的路徑，檔名預設為alert_.log，其中sid為資料庫的唯一標誌。在實驗環境中，資料庫名稱為alert_wilson.log。

SQL> show parameter dump_dest;

NAME TYPE VALUE

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

background_dump_dest string /u01/diag/rdbms/wilson/wilson/

trace

core_dump_dest string /u01/diag/rdbms/wilson/wilson/

cdump

user_dump_dest string /u01/diag/rdbms/wilson/wilson/

trace

[oracle@oracle11g ~]$ date

Tue Apr 5 08:37:40 CST 2011

根據時間間隔進行整理日誌，我們看到三個階段資料庫操作情況。

1、 nomount階段

nomount階段進行的主要是Oracle例項的構建，共享記憶體的開啟，以及初始化引數的讀取定位。下面為日誌相關部分片段。

Tue Apr 05 08:32:27 2011

Starting ORACLE instance (normal)

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

Picked latch-free SCN scheme 2

Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST

Autotune of undo retention is turned on.

IMODE=BR

ILAT =27

LICENSE_MAX_USERS = 0

SYS auditing is disabled

Starting up:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options.

Using parameter settings in server-side spfile /u01/oracle/dbs/spfilewilson.ora

System parameters with non-default values:

processes = 150

memory_target = 396M

control_files = "/u01/oradata/WILSON/controlfile/o1_mf_6bcsqm50_.ctl"

control_files = "/u01/flash_recovery_area/WILSON/controlfile/o1_mf_6bcsqmd8_.ctl"

db_block_size = 8192

compatible = "11.2.0.0.0"

db_create_file_dest = "/u01/oradata"

db_recovery_file_dest = "/u01/flash_recovery_area"

db_recovery_file_dest_size= 3852M

undo_tablespace = "UNDOTBS1"

remote_login_passwordfile= "EXCLUSIVE"

db_domain = ""

dispatchers = "(PROTOCOL=TCP) (SERVICE=wilsonXDB)"

shared_servers = 2

audit_file_dest = "/u01/admin/wilson/adump"

audit_trail = "DB"

db_name = "wilson"

open_cursors = 300

diagnostic_dest = "/u01"

Tue Apr 05 08:32:30 2011

PMON started with pid=2, OS id=5594

Tue Apr 05 08:32:30 2011

VKTM started with pid=3, OS id=5596 at elevated priority

VKTM running at (10)millisec precision with DBRM quantum (100)ms

Tue Apr 05 08:32:30 2011

GEN0 started with pid=4, OS id=5600

Tue Apr 05 08:32:30 2011

DIAG started with pid=5, OS id=5602

Tue Apr 05 08:32:30 2011

DBRM started with pid=6, OS id=5604

Tue Apr 05 08:32:31 2011

PSP0 started with pid=7, OS id=5606

Tue Apr 05 08:32:31 2011

DIA0 started with pid=8, OS id=5608

Tue Apr 05 08:32:31 2011

MMAN started with pid=9, OS id=5610

Tue Apr 05 08:32:31 2011

DBW0 started with pid=10, OS id=5612

Tue Apr 05 08:32:31 2011

CKPT started with pid=12, OS id=5616

Tue Apr 05 08:32:31 2011

LGWR started with pid=11, OS id=5614

Tue Apr 05 08:32:31 2011

SMON started with pid=13, OS id=5618

Tue Apr 05 08:32:31 2011

RECO started with pid=14, OS id=5620

Tue Apr 05 08:32:31 2011

MMON started with pid=15, OS id=5622

starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...

Tue Apr 05 08:32:31 2011

MMNL started with pid=16, OS id=5624

starting up 2 shared server(s) ...

ORACLE_BASE from environment = /u01

總結：在本階段，Oracle忙於進行如下階段順序操作。

ü 根據環境變數，確定初始化引數檔案位置。根據環境變數中對ORACLE_SID、ORACLE_HOME等的設定，確定要啟動資料庫在物理磁碟上的位置。根據Oracle的OFS結構，來確定使用引數檔案可能的位置。根據spfile.ora、spfile.ora、init.ora和init.ora的順序來定位引數檔案。

ü 讀取引數檔案，確定基礎的引數內容。透過讀取引數檔案，Oracle啟動過程獲取到該資料庫的基本資訊，包括控制檔案位置、塊大小、各種型別目錄的具體位置、特殊表空間名稱等內容。其中，對控制檔案的定位，是進一步讀取更多資料庫資訊，定位資料庫檔案的重要前置步驟；

2、 mount階段

在mount階段，資料庫日誌的內容相對簡單些了。

Tue Apr 05 08:33:09 2011

alter database mount

Tue Apr 05 08:33:13 2011

Successful mount of redo thread 1, with mount id 3868018373

Database mounted in Exclusive Mode

Lost write protection disabled

Completed: alter database mount

總結：mount階段，Oracle主要進行的各型別檔案（資料檔案、日誌檔案）的定位尋找工作。透過在nomount階段載入的控制檔案資訊，確定了當前系統的檔案的具體位置已經SCN資訊。在此階段，可以進行資料恢復方面的一些工作。

3、 Open階段

Tue Apr 05 08:33:29 2011

alter database open

Beginning crash recovery of 1 threads

Started redo scan

Completed redo scan

read 18880 KB redo, 1853 data blocks need recovery

Started redo application at

Thread 1: logseq 87, block 4964

Recovery of Online Redo Log: Thread 1 Group 3 Seq 87 Reading mem 0

Mem# 0: /u01/oradata/WILSON/onlinelog/o1_mf_3_6bcsqtfj_.log

Mem# 1: /u01/flash_recovery_area/WILSON/onlinelog/o1_mf_3_6bcsqtwv_.log

Completed redo application of 15.28MB

Completed crash recovery at

Thread 1: logseq 87, block 42725, scn 2965918

1853 data blocks read, 1853 data blocks written, 18880 redo k-bytes read

Tue Apr 05 08:33:33 2011

Thread 1 advanced to log sequence 88 (thread open)

Thread 1 opened at log sequence 88

Current log# 1 seq# 88 mem# 0: /u01/oradata/WILSON/onlinelog/o1_mf_1_6bcsqpty_.log

Current log# 1 seq# 88 mem# 1: /u01/flash_recovery_area/WILSON/onlinelog/o1_mf_1_6bcsqqt0_.log

Successful open of redo thread 1

MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set

Tue Apr 05 08:33:34 2011

SMON: enabling cache recovery

Successfully onlined Undo Tablespace 2.

Verifying file header compatibility for 11g tablespace encryption..

Verifying 11g file header compatibility for tablespace encryption completed

SMON: enabling tx recovery

Database Characterset is AL32UTF8

No Resource Manager plan active

replication_dependency_tracking turned off (no async multimaster replication found)

Starting background process QMNC

Tue Apr 05 08:33:38 2011

QMNC started with pid=21, OS id=5721

Tue Apr 05 08:33:40 2011

Completed: alter database open

總結：在進入Open階段之後，Oracle進行了一系列的工作；

ü 由於上次關閉資料庫非正常關閉。Oracle會自動檢查是否需要進行前滾、後滾的回覆操作。此時，控制檔案、日誌檔案以及各個資料檔案上的檢查點和SCN記錄就是一個重要依據。在本段程式碼中，Oracle發現需要進行crash恢復，並且使用Group3、順序號為87的重做日誌進行恢復；

ü 確定當前的Oracle Redo Log。進行Seq87的恢復後，確定Seq88作為當前使用的Redo Log記錄；

ü 其他元件程式啟動；

應該說，Oracle的啟動是一個相當複雜精密、且層層相關的過程。深入的進行Alert_Log分析，可以幫助我們更好的理解Oracle內部機制和機理，進而提高我們使用資料庫、解決資料庫問題的能力。

從Alert_Log看Oracle資料庫啟動三階段

相關文章