数据库的启动过程

数据库的启动和关闭
参数文件：

spfile 文件：
   1.Linux可以通过 strings 查看；
   2.windows 可以用记事本查看。只可查看不可编辑！



简述数据库的启动步骤：


1.nomount 阶段，该阶段会完成的操作


    1.1.sqlplus 连接进入空闲实例，
sqlplus 连接至空闲实例主要包含以下几个过程

     
1.1.1.sqlplus 执行文件的合法性判断
 sqlplus 的执行文件主要位于$oracle_home/bin下，sqlplus 执行文件的合法性判断主要包含两部分内容

       
          1.sqlplus 执行文件的执行权限。
       
          2.sqlplus 执行文件的动态链接库，可以通过 ldd $oracle_home/bin/sqlplus 或者 ldd $oracle_home/bin/oracle 来确认sqlplus是否存在问题。实践表明，nomount阶段出现问题，总是和操作系统相关，通常情况下，一条简单的relink all 命令就能解决大部分问题。

    
     1.1.2.用户权限的判断


     在使用sqlplus命令连接数据库时，用户权限判断又分为操作系统认证和密码文件认证两种方式。
    对于拥有sysdba和sysoper 权限的用户，默认情况下，Oracle 优先使用操作系统认证方式。

         
          1.操作系统认证方式，Oracle默认开启，当用Oracle系统用户登录到操作系统之后，具有sysdba或者sysoper 权限的业务用户可以绕过密码文件验证，直接使用sqlplus来启动和关闭数据库。
         
          2.Oracle密码文件认证。密码文件验证和Oracle密码文件相关。
            当操作系统验证失败时，密码文件验证成功。oracle 密码文件存有sysdba 或 sysoper 权限的用户，当密码文件不存在时，若给用户赋予sysdba权限，则会报ORA-01994错误。
        
            oracle 选择密码文件的顺序和remote_login_passwordfile 参数有关，当将参数设置为exclusive 时，Oracle会优先使用orapw$oracle_sid 密码文件，如果不存在orapw$oracle_sid密码文件，则使用orapw密码文件。
     
     

1.1.3.相关空间资源分配
Oracle会强制审计sysdba 连接的客户端，客户端没发起一次sysdba连接，就会在审计目录下产生一个.aud为后缀的审计文件，审计文件的存放位置由audit_file_dest 参数决定，当不设置audit_file_dest 参数时，则保存在$Oracle_home/rdbms/audit目录下。
     
     
1.1.4.进程资源分配等操作
sqlplus 连接到一个空闲实例时，操作系统会派生出一个进程。这个进程需要消耗一定的操作系统资源，比如进程号、进程内存、信号量等，所以在操作系统资源比较紧张时，系统派生进程的速度将会大大减慢，甚至可能无法派生进程的现象，此时sqlplus 连接数据库往往表现为长时间处于hang状态。


    
   1.2.读取参数文件

如果不加连接串，用sysdba连接至空闲实例之后，Oracle会根据环境变量$Oracle_sid 去判断读取哪个参数文件。

    在启动实例之前，Oracle会先完成以下两步工作：
 
     1.2.1.定位数据库参数文件
   推荐使用spfile参数文件作为默认参数文件，Oracle定位参数文件的顺序依次为：spfile$Oracle_sid.ora、spfile.ora、init$oracle_sid.ora.
  
     1.2.2.读取并校验参数文件内容
   oracle的参数主要分为隐含参数和非隐含参数两类。隐含参数主要用于控制Oracle更加底层的行为，有些隐含参数甚至由较大的副作用。
     Oracle定位到参数文件之后，在打开实例之前，它会从参数文件中读取和校验数据库参数，主要校验参数有以下几个方面：
      
         1.2.2.1.检查参数名字的有效性
      
         1.2.2.2.检查参数设置是否符合操作系统命令的语法
      
         1.2.2.3.检查参数设置是否符合Oracle命名的语法
      
         1.2.2.4.检查参数设置是否存在非法值
      
         1.2.2.5.检查参数设置的目录是否存在
      
         1.2.2.6.检查参数文件中是否存在过期参数
      
         1.2.2.7.检查参数之间的关联性，比如参数parallerl_max_servers值超过参数process值时，在nomount阶段将会自动调整parallel_max_servers参数值。
      
         1.2.2.8.检查参数是否小于最低阀值
    


1.3.分配SGA内存

Oracle在nomount 阶段分配SGA的动作比较简单，只不过时根据SGA_MAX_SIZE参数开辟空闲的共享内存段。这期间主要涉及的使操作系统虚拟内存管理和SGA内存区域之间的完整性检查。Oracle分配SGA内存区域时一个典型的错误就是内存不足。
        ORA-27102
 内存不足的原因主要有以下4点：
    
         1.3.1.交换空间或者虚拟内存太小
    
         1.3.2.操作系统参数设置的太小，如Linux系统配置文件:/etc/sysctl.conf
    
         1.3.3.SGA参数设置的太大
    
         1.3.4.Oracle bug
  关注两个命令：ipcs -a , ipcs -mi
   数据库nomount阶段完成后，可以查询以下主要视图：
    ----另外分析----
    

1.4.派生后台进程
 SGA内存分配完之后，接下来就是派生后台进程了。当操作系统内存紧张或交换空间不足时，Oracle派生后台进程时可能会出现如下问题：ora-00443
该阶段会检测软件运行环境，主要消耗操作系统内存资源




2.mount阶段
该阶段会完成的操作：
在该阶段会读取control_files参数指定的控制文件，获得数据文件和日志文件等数据库文件的相关信息（如数据库文件的位置信息）。
数据库成功完成mount阶段后，可以进行数据文件重命名、开启关闭归档、开启关闭闪回、增加删除重命名在线日志文件等操作。

mount 阶段具体步骤：
     

2.1.读取控制文件
 
             Oracle首先会根据control_files 参数读取控制文件，当所有控制文件或其中一个控制文件不存在时，会报：ora-00205，同时警告日志会明确指出缺失的控制文件。
     
2.2.校验控制文件
         
2.2.1.校验控制文件头是否损坏
    
              在mount阶段，数据库在读取控制文件时，首先会校验控制文件头，如果控制文件头损坏。则报：ora-00227,且警告日志会明确指出控制文件具体损坏位置。
         
2.2.2.校验控制文件之间的一致性
    
              如果数据库有多个控制文件，那么所有的控制文件的内容将会彼此镜像。当其中一个控制文件的内容和其他控制文件不一样时，那么在mount阶段会报错。
         
2.2.3.校验控制文件的核心内容是否损坏
     
              校验控制文件的核心数据块是否损坏，控制文件的核心数据块指的是数据库在mount 阶段必须要读取的控制文件数据块，可以在nomount阶段开启10046事件来观察控制文件核心数据块。当存有核心内容的控制文件数据块发生损坏时，在数据库mount阶段将会报错。当保存非核心内容的控制文件数据块发生损坏时，由于在mount阶段Oracle并不读取这些内容，所以数据库能成功完成mount阶段。但是在读取这些内容时，数据库会由于这些损坏块而产生异常错误。比如当控制文件第30号块损坏时，数据库虽然能成功完成mount，但是读取v$darafile（v$datafile视图内容来自控制文件）时，实例会由于控制文件坏块而异常关机。警告日志文件会显示控制文件30号块损坏。所以，数据库能成功mount，并不意味着控制文件没有损坏块。


         2.2.4.检查DB_NAME参数和控制文件的数据库名字是否一致
     
              当数据库参数DB_NAME的值和存储在控制文件的数据库名字不一致时，Oracle在mount阶段会报ora-01103错误。     
         
2.2.5.检查compatible 参数和控制文件版本是否一致
    
              当compatible数据库参数和保存在控制文件里的数据库版本不一致时，则会报错。
        


控制文件损坏的处理：
控制文件保存着数据库的很多核心信息，在数据库启动过程中，需要从控制文件中读取这些核心信息进一步打开其他文件。
        如果控制文件损坏，也就意味着数据库无法打开。
常见的处理思路如下：
 
              1.如果数据库有多份控制文件，当其中一份控制文件损坏时，由于控制文件之间的内容完全镜像，因此只要用完好的控制文件覆盖损坏的控制文件即可。
 
              2.如果所有的控制文件损坏，那么首先观察操作系统是否能完整的读取控制文件。如果能读取，则可以用操作系统命令打开控制文件来获取控制文件中online redolog 和数据文件的位置和名字。Linux中可以使用strings查看。
   
                获取到数据文件和日志文件的位置及文件名之后，只要按照重建控制文件的固定格式来重建控制文件即可。
 
              3. 如果操作系统不能读取控制文件，那么只能人为的将所有数据文件和在线日志文件找出来，按照重建控制文件的格式对其进行重建，需要注意的是，必须以noresetlogs选项重建控制文件，否则数据库打开之后可能会丢失业务数据。
注意：重建控制文件后，记录在控制文件中的相关数据库特性将会丢失，如数据库级别的force loggging








3.open阶段
在该阶段Oracle会校验数据文件和控制文件之间的一致性，完成初始化，打开数据库。
数据库完成mount之后，就进入了open阶段。在open阶段，服务器进程就会打开数据文件和日志文件等文件。数据库的open阶段是一个非常复杂的过程。
以下为经典的数据库启动步骤：
 
      1.根据控制文件的数据文件和日志文件信息尝试打开并锁定数据文件和日志文件，如果文件不存在，则警告日志会报错。
     
 2.crash recovery 如果数据库正常关机，那么启动的过程中不需要crash recovery 如果数据库异常关机，为了不丢失数据，Oracle服务进程在数据库open阶段需要扫描 online redolog 进程进行数据恢复。
      3.如果数据库处于归档模式，则派生归档进程。
 
      4.切换在线日志。Oracle 在open过程中会触发切换在线日志操作
 
      5.smon 进程启动cache recovery.该步骤主要是读取1号数据文件的bootsrtap 对象，并在row cache中创建数据字典基表
 
      6.onle undo segment 该步骤主要为接下来的tx recovery 做准备。
 
      7.smon 进程启动tx recovery,smon 在该阶段提交或回滚未完成的事务。
 
      8.成功open 数据库

实践表明，在启动过程中数据库容易在步骤 2,5,6中出现问题

如果将数据库采用resetlogs 方式打开，Oracle会重新格式化online redolog,并将online redolog 的sequence 重置为1，此打开方式常用于数据库不完全恢复之后。