ORACLE啟動過程淺析

靜以致遠√團團發表於2014-05-19

資料庫啟動的三個過程:

一):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/,如需轉載,請註明出處,否則將追究法律責任。

相關文章