ITPub博客

首页 > 数据库 > Oracle > ORACLE启动过程浅析

ORACLE启动过程浅析

原创 Oracle 作者:静以致远√团团 时间:2014-05-19 21:31:06 0 删除 编辑

数据库启动的三个过程:

一):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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
每个人都有梦想,去实现吧!

注册时间:2013-11-14

  • 博文量
    164
  • 访问量
    2103604