Oracle小白笔记#1_Oracle数据库状态

前言说明：本文是自己学习Oracle过程中查询网站以及咨询其他人得到的信息，做的一个笔记，如和网络上已有文章相似，请见谅。

---

（以下说明摘取自网络文章）
Oracle的数据库的状态有如下几种状态：

状态 说明 查询命令 显示状态 SHUTDOWN 数据库属于停止状态 - - NOMOUNT 开始读取参数文件(pfile/spfile)、确保SGA、启动后台进程等 select status from v$instance; STARTED - - select open_mode from v$database; ORA-01507: database not mounted MOUNT 读取参数文件(pfile/spfile)中记载的控制文件 select status from v$instance; MOUNTED - - select open_mode from v$database; MOUNTED OPEN 读取控制文件中记载的数据文件 select status from v$instance; OPEN - - select open_mode from v$database; READ WRITE 或者 READ ONLY

以上各种状态之间的切换命令如下：

状态 →NOMOUNT命令 →MOUNT命令 →OPEN命令 SHUTDOWN startup nomount startup mount startup open NOMOUNT - alter database mount; alter database open; MOUNT - - alter database open; OPEN - - -

注意1：启动时可以按照HUTDOWN→NOMOUNT→MOUNT→OPEN的顺序进行，但是停止时只能直接 SHUTDOWN，没办法一步步回退。
注意2：一般正常启动时都是直接startup，那么该命令如果启动正常的话将在最后一个OPEN状态。如果启动不正常则应该是停在以上状态的某一步，这时即可使用以上的查询命令查看状态，然后进行相关的操作。

停止命令如下：
- 停止全部用户连接之后Shutdown
SQL> shutdown
或者SQL> shutdown normal
- 执行中的事务结束之后Shutdown
SQL> shutdown transactional
- 回滚执行中的事务之后Shutdown
SQL> shutdown immediate
- 立即强制停止，在下次启动数据库时需要进行相关恢复工作
SQL> shutdown abort

以上 是相关的知识点。

---

以下是一个实际使用的小事例，本人也是因为如下故障排查才知道有这么几个状态。
问题描述：
由于开发人员在开发中程序不当导致数据库数据文件所在磁盘容量满从而数据库奔溃。
首先我们扩展磁盘容量，之后发现该Instance无法连接，但是同一个服务器上的其他Instance可正常使用，连接时报错如下：

解决过程：
一开始着手按照以上的两个错误号码查询，那么【11g The SGA requires more space than was allocated for it】主要表示启动不正常，数据库未启动等意思，那么先看启动日志，然后在根据日志内容查询。

首先看Instance的Alert日志：
位置是：D:\app\Administrator\diag\rdbms\wingarc\wingarc\trace
（以上我的安装目录是在D:\app之下，wingarc是实例名字）

该目录下就是一些跟踪日志了，首先查看alert_wingarc.txt文件，一般会记载主要的错误，以及到哪里看更详细的信息，以下是本次错误的问题：

这个文件中看到的是乱码，那么可以到记载的几个trc文件中查看：
首先wingarc_ora_3296.trc中记载如下：

---

Trace file d:\app\administrator\diag\rdbms\wingarc\wingarc\trace\wingarc_ora_3296.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Windows NT Version V6.1 Service Pack 1
CPU : 4 - type 586, 4 Physical Cores
Process Affinity : 0x0x00000000
Memory (Avail/Total): Ph:6680M/10239M, Ph+PgF:15371M/20477M, VA:2773M/4095M
VM name : VMWare Version (6)
Instance name: wingarc
Redo thread mounted by this instance: 1
Oracle process number: 19
Windows thread id: 3296, image: ORACLE.EXE (SHAD)

* 2017-09-21 16:11:42.844
* SESSION ID:(191.7) 2017-09-21 16:11:42.844
* CLIENT ID:() 2017-09-21 16:11:42.844
* SERVICE NAME:() 2017-09-21 16:11:42.844
* MODULE NAME:(sqlplus.exe) 2017-09-21 16:11:42.844
* ACTION NAME:() 2017-09-21 16:11:42.844

DDE: Problem Key ‘ORA 312’ was flood controlled (0x1) (no incident)
ORA-00312: online log 1 thread 1: ‘E:\ORADATA\WINGARC\REDO01.LOG’
ORA-00322: log 1 of thread is not current copy
ORA-00312: online log 1 thread 1: ‘E:\ORADATA\WINGARC\REDO01.LOG’

* 2017-09-21 16:11:42.860
USER (ospid: 3296): terminating the instance due to error 322
Symbol file D:\app\Administrator\product\11.2.0\dbhome_1\BIN\orannzsbb11.SYM does not match binary.
Symbol TimeStamp=4b62bd94, Module TimeStamp=0 are different
EnumerateLoadedModules64 failed with error -1073741819
Symbol file orannzsbb11.SYM does not match binary.
Symbol TimeStamp=4b62bd94, Module TimeStamp=0 are different
Symbol file D:\app\Administrator\product\11.2.0\dbhome_1\BIN\orannzsbb11.SYM does not match binary.
Symbol TimeStamp=4b62bd94, Module TimeStamp=0 are different
EnumerateLoadedModules64 failed with error -1073741819
Symbol file orannzsbb11.SYM does not match binary.
Symbol TimeStamp=4b62bd94, Module TimeStamp=0 are different

---

可以看出问题如下：
DDE: Problem Key ‘ORA 312’ was flood controlled (0x1) (no incident)
ORA-00312: online log 1 thread 1: ‘E:\ORADATA\WINGARC\REDO01.LOG’
ORA-00322: log 1 of thread is not current copy
ORA-00312: online log 1 thread 1: ‘E:\ORADATA\WINGARC\REDO01.LOG’

按照这个错误号码查询处理。
处理过程如下图参考：

实际上我们还应该后续处理之前清除的日志问题，因为这个是开发数据库没有需要去做数据验证，也就不再做其他处理了。
实际上专门的日志清除之后如何处理的问题网上也有很多例子，可以参考试验。
本例子主要是本人小白，一开始查看到是日志错误时按照清除日志方法进行，但是一直报错 数据库不可用，完全不知道该如何着手处理。花了很多时间才发现 有 instance启动有不同的状态的这一知识点，特此记录下。