ORACLE啟動過程淺析
資料庫啟動的三個過程：
一）：nomount
首先讀環境ORACLE_SID
到此目錄下$ORACLE_HOME/dbs按照以下順序查詢引數檔案。
spfileorcl.ora
spfile.ora
initorcl.ora
連線並啟動資料庫到nomount，這個過程啟動ORACLE例項，讀取相關引數，並分配相應的記憶體區域。
SQL> startup nomount
ORACLE instance started.
Total System Global Area 238530560 bytes
Fixed Size 1335724 bytes
Variable Size 163581524 bytes
Database Buffers 71303168 bytes
Redo Buffers 2310144 bytes
檢視alter日誌，瞭解詳細的啟動過程：
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 =51
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/product/11.1/dbs/spfileorcl.ora
System parameters with non-default values:
processes = 300
shared_pool_size = 100M
sga_target = 228M
control_files = "/u01/oracle/product/oradata/orcl/control01.ctl"
control_files = "/u01/oracle/product/flash_recovery_area/orcl/control02.ctl"
db_block_size = 8192
compatible = "11.2.0.0.0"
db_recovery_file_dest = "/u01/oracle/product/flash_recovery_area"
db_recovery_file_dest_size= 3852M
undo_tablespace = "UNDOTBS1"
remote_login_passwordfile= "EXCLUSIVE"
db_domain = ""
dispatchers = "(PROTOCOL=TCP) (SERVICE=orclXDB)"
shared_servers = 3
max_shared_servers = 10
max_dispatchers = 19
shared_server_sessions = 300
job_queue_processes = 5
audit_file_dest = "/u01/oracle/product/admin/orcl/adump"
audit_trail = "DB"
db_name = "orcl"
open_cursors = 300
pga_aggregate_target = 75M
diagnostic_dest = "/u01/oracle/product"
Fri May 16 11:09:32 2014
PMON started with pid=2, OS id=8994
Fri May 16 11:09:32 2014
VKTM started with pid=3, OS id=8996 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Fri May 16 11:09:32 2014
GEN0 started with pid=4, OS id=9000
Fri May 16 11:09:32 2014
DIAG started with pid=5, OS id=9002
Fri May 16 11:09:32 2014
DBRM started with pid=6, OS id=9004
Fri May 16 11:09:32 2014
PSP0 started with pid=7, OS id=9006
Fri May 16 11:09:32 2014
DIA0 started with pid=8, OS id=9008
Fri May 16 11:09:32 2014
MMAN started with pid=9, OS id=9010
Fri May 16 11:09:32 2014
DBW0 started with pid=10, OS id=9012
Fri May 16 11:09:32 2014
LGWR started with pid=11, OS id=9014
Fri May 16 11:09:32 2014
CKPT started with pid=12, OS id=9016
Fri May 16 11:09:32 2014
SMON started with pid=13, OS id=9018
Fri May 16 11:09:32 2014
RECO started with pid=14, OS id=9020
Fri May 16 11:09:32 2014
MMON started with pid=15, OS id=9022
Fri May 16 11:09:32 2014
MMNL started with pid=16, OS id=9024
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 3 shared server(s) ...
ORACLE_BASE from environment = /u01/oracle/product
不難看出，在啟動資料庫到nomount狀態時，引數檔案被呼叫，資料庫根據引數檔案中的相關設定確定控制檔案，閃回恢復區，dump跟蹤檔案的路徑，並啟動例項，分配相關的記憶體，從alter日誌中可以檢視到在此過程中相應的程式資訊，其中pid代表的是資料庫內的識別符號編號，OS id代表是的作業系統上的程式編號（oracle11g再羅列出程式資訊的同時，把程式啟動的時間也呈現出來，方便檢視程式啟動時間，幫助資料診斷）
利用v$process檢視檢視程式，其中spid指的是作業系統中的程式號：
SQL> select pid,spid,pname from v$process;
PID SPID PNAME
---------- ------------------------ -----
1
2 8994 PMON
3 8996 VKTM
4 9000 GEN0
5 9002 DIAG
6 9004 DBRM
7 9006 PSP0
8 9008 DIA0
9 9010 MMAN
10 9012 DBW0
11 9014 LGWR
PID SPID PNAME
---------- ------------------------ -----
12 9016 CKPT
13 9018 SMON
14 9020 RECO
15 9022 MMON
16 9024 MMNL
17 9026 D000
18 9028 S000
19 9030 S001
20 9032 S002
21 9033
與作業系統中的程式進行對比：
[oracle@orcl11g trace]$ ps aux | grep ora_
oracle 8994 0.0 3.3 389984 17256 ? Ss 11:09 0:00 ora_pmon_orcl
oracle 8996 0.0 2.5 389324 13272 ? Ss 11:09 0:00 ora_vktm_orcl
oracle 9000 0.0 2.5 389324 13336 ? Ss 11:09 0:00 ora_gen0_orcl
oracle 9002 0.0 2.5 389324 13212 ? Ss 11:09 0:00 ora_diag_orcl
oracle 9004 0.0 2.5 389324 13344 ? Ss 11:09 0:00 ora_dbrm_orcl
oracle 9006 0.0 2.5 389324 13356 ? Ss 11:09 0:00 ora_psp0_orcl
oracle 9008 0.0 3.8 390860 19904 ? Ss 11:09 0:00 ora_dia0_orcl
oracle 9010 0.0 3.0 389324 15692 ? Ss 11:09 0:00 ora_mman_orcl
oracle 9012 0.0 3.3 393224 17356 ? Ss 11:09 0:00 ora_dbw0_orcl
oracle 9014 0.0 2.5 389324 13380 ? Ss 11:09 0:00 ora_lgwr_orcl
oracle 9016 0.0 3.1 389324 16264 ? Ss 11:09 0:00 ora_ckpt_orcl
oracle 9018 0.0 2.7 389324 14108 ? Ss 11:09 0:00 ora_smon_orcl
oracle 9020 0.0 2.5 389324 13352 ? Ss 11:09 0:00 ora_reco_orcl
oracle 9022 0.0 2.8 389324 14584 ? Ss 11:09 0:00 ora_mmon_orcl
oracle 9024 0.0 3.3 389324 17160 ? Ss 11:09 0:00 ora_mmnl_orcl
oracle 9026 0.0 2.6 390108 13420 ? Ss 11:09 0:00 ora_d000_orcl
oracle 9028 0.0 2.4 389488 12712 ? Ss 11:09 0:00 ora_s000_orcl
oracle 9030 0.0 2.4 389488 12708 ? Ss 11:09 0:00 ora_s001_orcl
oracle 9032 0.0 2.4 389488 12712 ? Ss 11:09 0:00 ora_s002_orcl
oracle 9350 0.0 0.1 3920 664 pts/3 R+ 11:31 0:00 grep ora_
注意PID=1的程式在作業系統中及告警日誌中均沒有體現，該程式被認為是初始化資料庫的程式，啟動其他程式之前即被佔用。
二）：mount
根據引數檔案裡記錄的控制檔案的位置，找到控制檔案，校驗控制檔案的完整性和一致性，如果完整性和一致性都滿足，資料庫進入mount狀態。
mount的本質是例項和資料庫進行關聯。
SQL> alter database mount;
Database altered.
SQL> select name from v$controlfile;
NAME
-----------------------------------------------------------
/u01/oracle/product/oradata/orcl/control01.ctl
/u01/oracle/product/flash_recovery_area/orcl/control02.ctl
此時資料檔案的資訊已經載入
SQL> select name from v$datafile;
NAME
-----------------------------------------------------------
/u01/oracle/product/oradata/orcl/system01.dbf
/u01/oracle/product/oradata/orcl/sysaux01.dbf
/u01/oracle/product/oradata/orcl/undotbs01.dbf
/u01/oracle/product/oradata/orcl/users01.dbf
/u01/oracle/product/oradata/orcl/example01.dbf
/u01/oracle/product/oradata/orcl/test001.dbf
6 rows selected.
此時如果資料檔案丟失，可以在v$recover_file檢視檢視相關資訊：
SQL> select * from v$recover_file;
FILE# ONLINE ONLINE_ ERROR CHANGE# TIME
---------- ------- ------- -------------------- ---------- ---------
6 ONLINE ONLINE FILE NOT FOUND 0
在啟動資料到mount狀態時可以在告警日誌中看到如下資訊：
ALTER DATABASE MOUNT
Successful mount of redo thread 1, with mount id 1375768858
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE MOUNT
資料庫計算mount id並將其記錄在控制檔案中,並開始啟動心跳（heartbeat），沒三秒更新一次控制檔案。
HEARTBEAT可以透過X$KCCCP檢視查詢出：
SQL> select CPHBT from X$KCCCP;
CPHBT
----------
847995711
該心跳是透過等待時間實現：
SQL> select event#,name from v$event_name where name like '%heart%';
EVENT# NAME
---------- ----------------------------------------------------------------
75 heartbeat monitor sleep
380 ASM mount : wait for heartbeat
563 control file heartbeat
三）：open
根據控制檔案裡記錄的資料檔案和日誌檔案的位置，找到資料檔案和日誌檔案
校驗資料檔案，日誌檔案的完整性，並且校驗資料檔案，日誌檔案，控制檔案
的一致性，如果完整性和一致性都滿足，資料庫可以開啟。
在資料庫OPEN時，ORACLE會先檢查資料檔案頭中的檢查點計數（CNT）是否與控制檔案中的檢查點計數一致。
做個測試,看一下資料檔案6在不同狀態下CNT的變化情況：
SQL> alter tablespace test begin backup;
Tablespace altered.
SQL> alter session set events 'immediate trace name controlf level 8';
Session altered.
SQL> alter system checkpoint;
System altered.
SQL> alter session set events 'immediate trace name controlf level 8';
Session altered.
SQL> alter tablespace test end backup;
Tablespace altered.
SQL> alter session set events 'immediate trace name controlf level 8';
Session altered.
獲取dump路徑：
SQL> show parameter background_dump_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
background_dump_dest string /u01/oracle/product/diag/rdbms
/orcl/orcl/trace
檢視dump出的trace檔案，可以找到如下資訊：
[oracle@orcl11g orcl]$ cat orcl_ora_5786.trc
------------------------正常情況下------------------------
DATA FILE #6:
Checkpoint cnt:26 scn: 0x0000.001195e8 05/19/2014 18:05:43
------------------------begin backup cnt+1 scn+1------------------------
DATA FILE #6:
Checkpoint cnt:27 scn: 0x0000.001196c0 05/19/2014 18:10:13
注：對錶空間的begin backup會出發一次檢查點操作
------------------------執行檢查點 cnt+1 scn無變化------------------------
DATA FILE #6:
Checkpoint cnt:28 scn: 0x0000.001196c0 05/19/2014 18:10:13
注：表空間處於熱備模式，資料檔案檢查點被凍結
------------------------end backup cnt+1 scn+1------------------------
DATA FILE #6:
Checkpoint cnt:29 scn: 0x0000.001196dc 05/19/2014 18:10:48
注：結束備份狀態，資料檔案檢查點開始變化
在資料庫OPEN過程中如果資料檔案頭中的檢查點計數與控制檔案中的檢查點計數一直，則會檢查資料檔案的開始SCN是否與控制檔案中的結束SCN一直，若不一致則需對該資料檔案進行恢復。一旦資料庫處於OPEN狀態，控制檔案中記錄的資料檔案的stop scn將置為無窮大。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29320885/viewspace-1164630/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 淺析Spring Framework框架容器啟動過程SpringFramework框架
- Android啟動過程剖析-深入淺出Android
- Spring MVC實現過程淺析SpringMVC
- 淺析Java程式的執行過程Java
- MySQL伺服器連線過程淺析MySql伺服器
- Flutter Android 端啟動流程淺析FlutterAndroid
- MySQL 查詢語句執行過程淺析MySql
- 瀏覽器渲染過程與原理淺析（一）瀏覽器
- SpringBoot啟動過程Spring Boot
- Windows 啟動過程Windows
- Service啟動過程
- Oracle資料庫啟動過程及狀態詳解Oracle資料庫
- 淺析Spring Security 的認證過程及相關過濾器Spring過濾器
- 淺讀tomcat架構設計和tomcat啟動過程(1)Tomcat架構
- App 啟動過程（含 Activity 啟動過程） | 安卓 offer 收割基APP安卓
- oracle11g啟動過程中載入配置檔案Oracle
- iOS App啟動過程iOSAPP
- Android App啟動過程AndroidAPP
- SpringBoot 系列-啟動過程Spring Boot
- jmeter 啟動過程剖析JMeter
- Liferay 啟動過程分析
- main的啟動過程AI
- Spring Boot 啟動過程Spring Boot
- Angular的啟動過程Angular
- Spring啟動過程（一）Spring
- Linux 啟動過程分析Linux
- AMSI 淺析及繞過
- Spring原始碼淺析之bean例項的建立過程(二)Spring原始碼Bean
- Bytom側鏈Vapor原始碼淺析-節點出塊過程Vapor原始碼
- Spring原始碼淺析之bean例項的建立過程(一)Spring原始碼Bean
- Linux系統啟動過程Linux
- Linux核心Kernel啟動過程Linux
- Spring Security 啟動過程分析Spring
- HDFS啟動過程+安全模式模式
- Eureka Server啟動過程分析Server
- 計算機啟動過程計算機
- app的啟動過程（三）APP
- DUBBO服務啟動過程
- 從底層原始碼淺析Mybatis的SqlSessionFactory初始化過程原始碼MyBatisSQLSession