Oracle instance启动

在nomount的时候需要去读取初始化控制文件pfile，spfile将实例启动到nomount阶段。

在mount状态下需要去读取控制文件，在mount阶段可以访问一些动态性能视图，也可以做备份。

从mount到open，控制文件记录了整个数据库的物理结构，在open的时候根据控制文件的记录去检查数据文件和redo日志的一些具体位置，必须保证每一个数据文件，每一组日志都能正常的去访问，之后还要去检查数据库的一致性，数据库的一致性怎么检查，去检查记录在数据文件，控制文件，redo日志上面的检查点来判断数据库是否处于一致性。

 

 

在数据库启动的时候可以通过alter日志来获取完整的启动，要查看告警日志的位置可以使用下面语句

SQL> set linesize 1200;

SQL> show parameter dump;  --告警日志放在bdump所指定的路径下面

 

NAME      TYPE     VALUE

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

background_core_dump      string     partial

background_dump_dest      string     /u01/app/oracle/diag/rdbms/ora

    db/oradb/trace

core_dump_dest      string     /u01/app/oracle/diag/rdbms/ora

    db/oradb/cdump

max_dump_file_size      string     unlimited

shadow_core_dump      string     partial

user_dump_dest      string     /u01/app/oracle/diag/rdbms/ora

    db/oradb/trace

[oracle@Database2 ~]$ cd /u01/app/oracle/diag/rdbms/oradb/oradb/trace

[oracle@Database2 trace]$ ls

alert_oradb.log  

 

Mon Jun 25 18:43:09 2018

Starting ORACLE instance (normal)   --通过下面信息可以看到在启动到nomount的时候，实例分配内存和启动后台进程

Specified value of sga_max_size is too small, bumping to 1312817152

...............................................................................................................

Using parameter settings in server-side spfile /u01/app/oracle/product/11.2.0/db_1/dbs/spfileoradb.ora

System parameters with non-default values:

  processes                = 2000

  sga_max_size             = 1252M

  sga_target               = 0

  memory_target            = 1384M

  memory_max_target        = 1420M

  control_files            = "/u01/app/oracle/oradata/oradb/control01.ctl"

Mon Jun 25 18:43:10 2018

PMON started with pid=2, OS id=6304

Mon Jun 25 18:43:10 2018

PSP0 started with pid=3, OS id=6306

Mon Jun 25 18:43:11 2018

VKTM started with pid=4, OS id=6308 at elevated priority

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

Mon Jun 25 18:43:11 2018

GEN0 started with pid=5, OS id=6312

Mon Jun 25 18:43:11 2018

 

 

ALTER DATABASE   MOUNT   --在mount状态下

Successful mount of redo thread 1, with mount id 2732988735

Database mounted in Exclusive Mode

Lost write protection disabled

Completed: ALTER DATABASE   MOUNT

Mon Jun 25 18:43:16 2018

 

ALTER DATABASE OPEN  --在open状态下

LGWR: STARTING ARCH PROCESSES

Mon Jun 25 18:43:16 2018

ARC0 started with pid=20, OS id=6346

ARC0: Archival started

LGWR: STARTING ARCH PROCESSES COMPLETE

............................................................................

Undo initialization finished serial:0 start:32829894 end:32829954 diff:60 (0 seconds)

Verifying file header compatibility for 11g tablespace encryption..

Verifying 11g file header compatibility for tablespace encryption completed

...............................................................................

 

 

SQL> alter database mount;  --下面无法启动到mount状态，因为一个控制文件比较老，一个控制文件比较新，解决办法就是将新的控制文件覆盖老的旧控制文件再重启

alter database mount

*

ERROR at line 1:

ORA-00214: control file '/u01/app/oracle/fast_recovery_area/oradb/control02.ctl' version 1954 inconsistent with file '/u01/app/oracle/oradata/oradb/control01.ctl' version 1942

 

[oracle@Database2 dbs]$ cp /u01/app/oracle/fast_recovery_area/oradb/control02.ctl /u01/app/oracle/oradata/oradb/control01.ctl

 

SQL> alter database mount;

 

Database altered.

 

上面可以看到控制文件还是要有多个，如果一个被破坏，可以从其他地方拷贝一份，如果所有控制文件都损坏了，只能重建控制文件或者使用备份来恢复了。

 

 

下面都是从控制文件读取到的信息，确保下面这些数据文件和redo文件是可以访问的，有一个文件是破话的就无法进入open。（v$datafile,v$logfile都是通过控制文件读取出来的信息）

SQL> select name from v$datafile;

 

NAME

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

/u01/app/oracle/oradata/oradb/

system01.dbf

.................................................................

 

 

SQL> col MEMBER for a30;

SQL> select member from v$logfile;

 

MEMBER

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

/u01/app/oracle/oradata/oradb/

redo03.log

 

在数据库open的时候还需要做一致性检查

SQL> col name for a80;

SQL> select name,checkpoint_change# from v$datafile;

 

NAME  CHECKPOINT_CHANGE#

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

/u01/app/oracle/oradata/oradb/system01.dbf    11087180

/u01/app/oracle/oradata/oradb/sysaux01.dbf    11087180

/u01/app/oracle/oradata/oradb/undotbs01.dbf    11087180

/u01/app/oracle/oradata/oradb/users01.dbf    11087180

/u01/app/oracle/oradata/oradb/example01.dbf    11087180

 

SQL> select name,checkpoint_change# from v$datafile_header;

 

NAME  CHECKPOINT_CHANGE#

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

/u01/app/oracle/oradata/oradb/system01.dbf    11087180

/u01/app/oracle/oradata/oradb/sysaux01.dbf    11087180

/u01/app/oracle/oradata/oradb/undotbs01.dbf    11087180

/u01/app/oracle/oradata/oradb/users01.dbf    11087180

/u01/app/oracle/oradata/oradb/example01.dbf    11087180

 

这里有两个视图，v$datafile和v$datafile_header，v$datafile是从控制文件读取的信息，v$datafile_header是从数据文件上读取的信息，读取的是数据文件头部的信息。

 

做一致性检查的时候必须保证：

1. 控制文件里记录的每个文件的checkpoint（数据库检查点）和数据文件上的checkpoint是一致的。
2. 在v$datafile_header视图里面数据文件和数据文件之间checkpoint必须保持一致。
3. 控制文件上的checkpoint和redo日志文件上面记录的checkpoint是一致的。

只有上面三项全部满足，数据库才可以open。

 

open的时候：第一保证控制文件里面记录的文件是可以正常访问的，其次满足一致性检查。

 

 

在数据库打不开的时候要监控告警日志，定位到什么原因导致数据库打不开。