前言：

早晨上班，开发告知数据库连接不上，说是报内存溢出，查看内存空余空间确实不足，遂将高内存进程结束，但结束后还是连接不上，重启数据库，悲剧发生了，数据库居然启不来了，因前一天改了下dastart文件，已为是文件改动的问题，但使用sqlpuls /as nolog登陆后 conn /as sysdba连接数据再startup也是启不来。

之前没有接触过oracle数据库，想先找找错误日志吧，看看有没有报错，结果一顿找，也没找到错误日志在哪，不过后来找到一个启动日志/oracle/app/oracle/diag/rdbms/orcl/orcl/alert/log.xml，一个终端监视这个日志问题，另一个终端再次startup，日志这边有滚动了，滚了好多，关键在最后几行，报错了一条错误，以及错误记录文件/oracle/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_6319.trc，内容如下*** MODULE NAME:(sqlplus@test (TNS V1-V3)) 2015-09-17 11:17:30.014

*** ACTION NAME:() 2015-09-17 11:17:30.014

DDE: Problem Key 'ORA 312' was flood controlled (0x1) (no incident)

ORA-00312: online log 2 thread 1: '/oracle/app/oracle/oradata/orcl/redo02.log'

ORA-16014: log 2 sequence# 419 not archived, no available destinations

ORA-00312: online log 2 thread 1: '/oracle/app/oracle/oradata/orcl/redo02.log'

*** 2015-09-17 11:17:30.014

USER (ospid: 6319): terminating the instance due to error 16014

确认错误就是terminating the instance due to error 16014

根据这个错误百度出几条解决办法，有一条和我情况类似，看到这标题吓我一跳，以为没救了呢，不过还好，这是台测试机器

在此还意外发现了oracle错误日志的路径sqlplus /nolog

SQL*Plus: Release 11.2.0.3.0 Production on Fri Apr 20 10:35:15 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

SQL> conn /as sysdba

Connected to an idle instance.

SQL> startup

ORACLE instance started.

Total System Global Area  417546240 bytes

Fixed Size                  2228944 bytes

Variable Size             339742000 bytes

Database Buffers           67108864 bytes

Redo Buffers                8466432 bytes

Database mounted.

ORA-03113: end-of-file on communication channel

Process ID: 2558

Session ID: 125 Serial number: 5

[oracle@dg1 ~]$ tail -f /u01/app/oracle/diag/rdbms/dg1/dg/trace/alert_dg.log

Errors in file /u01/app/oracle/diag/rdbms/dg1/dg/trace/dg_ora_2743.trc:

ORA-16014: log 1 sequence# 63 not archived, no available destinations

ORA-00312: online log 1 thread 1: '/u01/app/oracle/oradata/dg/redo01.log'

USER (ospid: 2743): terminating the instance due to error 16014

Fri Apr 20 10:45:37 2012

System state dump requested by (instance=1, osid=2743), summary=[abnormal instance termination].

System State dumped to trace file /u01/app/oracle/diag/rdbms/dg1/dg/trace/dg_diag_2699.trc

Dumping diagnostic data in directory=[cdmp_20120420104537], requested by

(instance=1, osid=2743), summary=[abnormal instance termination].

Instance terminated by USER, pid = 2743

我也是在前一天尝试做数据备份导出时开启了oracle归档模式，当时是没问题的，但数据导出一直报错 TNS:could not resolve the connect identifier s，百度都说是环境变量问题，但我的环境变量都有，搞了一天也不知为何

看到问题和原因描述，觉得应该就是归档的问题，遂按照操作关闭归档模式sqlplus /nolog

SQL*Plus: Release 11.2.0.3.0 Production on Fri Apr 20 10:49:26 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

SQL> conn /as sysdba

Connected to an idle instance.

SQL> startup mount

ORACLE instance started.

Total System Global Area  417546240 bytes

Fixed Size                  2228944 bytes

Variable Size             339742000 bytes

Database Buffers           67108864 bytes

Redo Buffers                8466432 bytes

Database mounted.

SQL> alter database noarchivelog;

Database altered.

SQL> alter database open;

Database altered.

SQL> archive log list;

Database log mode              No Archive Mode

Automatic archival             Disabled

Archive destination            /u01/app/oracle/standbylog

Oldest online log sequence     64

Current log sequence           66

再次开启归档模式(此步尚未操作，记录在此方便后期操作查找)shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

Total System Global Area  417546240 bytes

Fixed Size                  2228944 bytes

Variable Size             339742000 bytes

Database Buffers           67108864 bytes

Redo Buffers                8466432 bytes

Database mounted.

SQL> alter database archivelog;

Database altered.

SQL> alter database open;

Database altered.

SQL> archive log list;

Database log mode              Archive Mode

Automatic archival             Enabled

Archive destination            /u01/app/oracle/standbylog

Oldest online log sequence     64

Next log sequence to archive   66

Current log sequence           66

一样ok，没有出现之前的63日志无法归档的问题，不过这个在生产库上肯定意味着丢数据的！

继续查询备库，发现日志只到62，之后的日志再也传不过来了，郁闷，数据丢失先不论，因为是测试库，但至少dg是要重建了，悲剧！

SQL> select open_mode,database_role,db_unique_name from v$database;

OPEN_MODE            DATABASE_ROLE    DB_UNIQUE_NAME

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

READ ONLY            PHYSICAL STANDBY dg2

SQL> select dest_id,applied,sequence# from v$archived_log where sequence# > 58 and dest_id=2;

DEST_ID APPLIED    SEQUENCE#

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

2 YES               59

2 YES               60

2 NO                61

2 NO                62

这事给我的总结是，还是别用broker切换了，就算用，也别切的那么快，慢慢来！今天真衰！