ORACLE startup报错之ORA-01154&&ORA-01155&&ORA-01033&&ORA-03113

本文涉及的产品
云原生数据仓库AnalyticDB MySQL版,基础版 8ACU 100GB 1个月
日志服务 SLS,月写入数据量 50GB 1个月
简介:     今天,一实施同事求助,说一地市oracle数据库无法通过远程连接,连接报错如图: 操作系统:windows server2008 R2  数据库版本:oracle 11.2.0.1 初看报错貌似数据库正处在打开或关闭的过程中。
    今天,一实施同事求助,说一地市oracle数据库无法通过远程连接,连接报错如图:
操作系统:windows server 2008 R2 
数据库版本:oracle 11.2.0.1

初看报错貌似数据库正处在打开或关闭的过程中。查看告警日志,最近的一次数据库启动发生在上午10:50,部分告警日志如下:
Wed Aug 02 10:51:48 2017
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Wed Aug 02 10:52:01 2017
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =86
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
然后,实施同事说,他中午那会startup了一下数据库,但是数据库停在了:“ 数据库装载完毕。”好长一段时间,如图:

然后,启动就报了ORA-03113,如果所示:

然后,他又说,数据库启动失败后,他接着重启了数据库服务器主机,然后但是问题依旧。
接下来是我的处理过程:
登录数据库服务器,
查看主机状态,CPU、磁盘IO、内存等资源很空闲
查看数据库服务和监听服务均已启动
登录数据库sqlplus查看数据库实例当前状态是mounted
Microsoft Windows [版本 6.1.7601]
版权所有 (c) 2009 Microsoft Corporation。保留所有权利。
C:\Users\Administrator>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on 星期三 8月 2 13:48:40 2017
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
连接到:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select status from v$instance;
STATUS
------------
MOUNTED
--尝试open数据库报ORA-01154,日志如下:
SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01154: 数据库忙。现在不允许打开, 关闭, 装载和卸装
接下来,重启了操作系统的Oracle实例服务,然后重新启动,启动依然停留在“ 数据库装载完毕”,日志如下:
从 Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options(情况复杂) 断开
C:\Users\Administrator>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on 星期三 8月 2 13:58:58 2017
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
已连接到空闲例程。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area 2.0577E+10 bytes
Fixed Size                  2184672 bytes
Variable Size            8589937184 bytes
Database Buffers         1.1945E+10 bytes
Redo Buffers               39743488 bytes
数据库装载完毕。
--观察数据库告警日志,12:59分数据库有ORA-00949,有实例进程超时等待
Wed Aug 02 12:59:29 2017
Errors in file d:\oraclehome\oracle\diag\rdbms\bmi\bmi\trace\bmi_arc1_3604.trc  (incident=164377):
ORA-00494: 持有入队 [CF] 的时间过长 (超过 900 秒) (由 'inst 1, osid 3084')
Incident details in: d:\oraclehome\oracle\diag\rdbms\bmi\bmi\incident\incdir_164377\bmi_arc1_3604_i164377.trc
Killing enqueue blocker (pid=3084) on resource CF-00000000-00000000 by (pid=3604)
 by killing session 638.1
Killing enqueue blocker (pid=3084) on resource CF-00000000-00000000 by (pid=3604)
 by terminating the process
ARC1 (ospid: 3604): terminating the instance due to error 2103
--13:20数据库被重启,日志如下(猜想是主机重启后的自动重启)
Wed Aug 02 13:19:29 2017
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =86
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
--观察到TNS连接报错: ORA-01155
Wed Aug 02 13:34:35 2017
Errors in file d:\oraclehome\oracle\diag\rdbms\bmi\bmi\trace\bmi_m000_4620.trc:
ORA-01155: 正在打开, 关闭, 装载或卸装数据库
Wed Aug 02 13:48:39 2017
TNS-12535: TNS: 操作超时
    ns secondary err code: 12606
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0
  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=fe80::94b2:4372:a24c:4b6e%11)(PORT=49179))
WARNING: inbound connection timed out (ORA-3136)
Wed Aug 02 13:49:38 2017
Errors in file d:\oraclehome\oracle\diag\rdbms\bmi\bmi\trace\bmi_m000_5596.trc:
ORA-01155: 正在打开, 关闭, 装载或卸装数据库
再看自己重启后的告警日志
Wed Aug 02 13:59:07 2017
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =86
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
......
Wed Aug 02 13:59:12 2017
ALTER DATABASE   MOUNT
Wed Aug 02 13:59:12 2017
MMNL started with pid=17, OS id=2012 
Successful mount of redo thread 1, with mount id 271372528
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE   MOUNT
Wed Aug 02 13:59:17 2017
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
  parallel recovery started with 15 processes
Wed Aug 02 13:59:41 2017
Started redo scan
Wed Aug 02 14:01:55 2017
Completed redo scan
 read 8951211 KB redo, 764700 data blocks need recovery
Wed Aug 02 14:03:22 2017
Started redo application at
 Thread 1: logseq 364892, block 508132
Recovery of Online Redo Log: Thread 1 Group 7 Seq 364892 Reading mem 0
  Mem# 0: D:\ORACLEHOME\ORACLE\ORADATA\BMI\REDO07_01.LOG
  Mem# 1: D:\ORACLEHOME\ORACLE\ORADATA\BMI\REDO07_02.LOG
Recovery of Online Redo Log: Thread 1 Group 21 Seq 364893 Reading mem 0
  Mem# 0: D:\ORACLEHOME\ORACLE\ORADATA\BMI\REDO21_01.LOG
  Mem# 1: D:\ORACLEHOME\ORACLE\ORADATA\BMI\REDO21_02.LOG
从启动告警日志可以看到,数据库肯定被异常终止过,当前数据库增在从redo日志恢复,此时需要耐心等待;再次询问实施同事并让其关闭远程的所有oracle客户端程序。
然后等待20分钟,数据库完成了open操作
Wed Aug 02 14:19:19 2017
Completed crash recovery at
 Thread 1: logseq 364905, block 820661, scn 14976863197959
 764700 data blocks read, 474332 data blocks written, 8951211 redo k-bytes read
Wed Aug 02 14:19:37 2017
LGWR: STARTING ARCH PROCESSES
Wed Aug 02 14:19:37 2017
ARC0 started with pid=37, OS id=1072 
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Wed Aug 02 14:19:38 2017
ARC1 started with pid=38, OS id=5408 
Wed Aug 02 14:19:38 2017
ARC2 started with pid=39, OS id=4412 
ARC1: Archival started
ARC2: Archival started
ARC2: Becoming the 'no FAL' ARCH
ARC2: Becoming the 'no SRL' ARCH
ARC1: Becoming the heartbeat ARCH
Wed Aug 02 14:19:38 2017
ARC3 started with pid=40, OS id=5536 
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Thread 1 advanced to log sequence 364906 (thread open)
Thread 1 opened at log sequence 364906
  Current log# 6 seq# 364906 mem# 0: D:\ORACLEHOME\ORACLE\ORADATA\BMI\REDO06_01.LOG
  Current log# 6 seq# 364906 mem# 1: D:\ORACLEHOME\ORACLE\ORADATA\BMI\REDO06_02.LOG
Successful open of redo thread 1
Wed Aug 02 14:19:45 2017
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Wed Aug 02 14:19:45 2017
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Wed Aug 02 14:20:02 2017
Starting background process QMNC
Wed Aug 02 14:20:02 2017
QMNC started with pid=58, OS id=5700 
Completed: ALTER DATABASE OPEN
--在数据库open的过程中,本地登录sqlplus查看会话信息,数据库确实开启了并行进程恢复:
SQL>  select sid,process,program from  v$session
  2  where
  3   type = 'USER'
  4  and
  5  SID not in (select DISTINCT SID from v$mystat);


       SID PROCESS                  PROGRAM
---------- ------------------------ ----------------------------------------------------------------
         3 3668                     ORACLE.EXE (P011)
         4 828                      ORACLE.EXE (P022)
        51 6024                     ORACLE.EXE (P012)
        52 5824                     ORACLE.EXE (P023)
       100 5880                     ORACLE.EXE (P013)
       101 4624                     ORACLE.EXE (P024)
       148 6048                     ORACLE.EXE (P014)
       150 2452                     ORACLE.EXE (P025)
       198 6028                     ORACLE.EXE (P000)
       200 3060                     ORACLE.EXE (P026)
       251 4844                     ORACLE.EXE (P027)
       298 4556                     ORACLE.EXE (P001)
       299 4356                     ORACLE.EXE (P028)
       347 4828                     ORACLE.EXE (P002)
       348 5956                     ORACLE.EXE (P029)
       396 5716                     ORACLE.EXE (P003)
       397 4288                     ORACLE.EXE (P030)
       443 5992                     ORACLE.EXE (P004)
       444 2828                     ORACLE.EXE (P015)
       445 4140                     ORACLE.EXE (P031)
       492 4704                     ORACLE.EXE (P005)
       493 5840                     ORACLE.EXE (P016)
       541 6004                     ORACLE.EXE (P006)
       542 2216                     ORACLE.EXE (P017)
       590 5048                     ORACLE.EXE (P018)
       591 1808                     ORACLE.EXE (P007)
       639 5632                     ORACLE.EXE (P019)
       640 4936                     ORACLE.EXE (P008)
       641 4436                     ORACLE.EXE (J000)
       689 5576                     ORACLE.EXE (P020)
       690 5884                     ORACLE.EXE (P009)
       737 6064                     ORACLE.EXE (P021)
       739 6012                     ORACLE.EXE (P010)
已选择33行。
数据库完成open后查看数据库状态,数据库恢复正常:
SQL> startup
ORACLE 例程已经启动。
Total System Global Area 2.0577E+10 bytes
Fixed Size                  2184672 bytes
Variable Size            8589937184 bytes
Database Buffers         1.1945E+10 bytes
Redo Buffers               39743488 bytes
数据库装载完毕。
数据库已经打开。
SQL> select instance_name,status from v$instance;
INSTANCE_NAME    STATUS
---------------- ------------
bmi              OPEN
SQL>
SQL> select name,open_mode from v$database;
NAME      OPEN_MODE
--------- --------------------
BMI       READ WRITE
SQL> 

注意:本次故障中,需要实施同事明白Oracle数据库的启动和关闭过程;重启操作系统前,需要先关闭oracle监听、确定当前数据库中没有执行计划任务或存储过程、
关闭oracle数据库实例、关闭oracle数据库服务、重启操作系统,如果不是这个顺序,就可能导致数据文件损坏,数据库启动需要恢复而打开过程很慢,需要耐心等待。




相关实践学习
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
目录
相关文章
|
3月前
|
Oracle 关系型数据库 数据库
数据库数据恢复—服务器异常断电导致Oracle数据库报错的数据恢复案例
Oracle数据库故障: 某公司一台服务器上部署Oracle数据库。服务器意外断电导致数据库报错,报错内容为“system01.dbf需要更多的恢复来保持一致性”。该Oracle数据库没有备份,仅有一些断断续续的归档日志。 Oracle数据库恢复流程: 1、检测数据库故障情况; 2、尝试挂起并修复数据库; 3、解析数据库文件; 4、导出并验证恢复的数据库文件。
|
7月前
|
Oracle 关系型数据库 MySQL
【YashanDB知识库】oracle dblink varchar类型查询报错记录
这篇文章主要介绍了 Oracle DBLINK 查询崖山 DB 报错的相关内容,包括 ODBC 安装配置、数据源配置、dblink 环境配置、问题原因分析及规避方法。问题原因是 dblink 连接其他数据库时 varchar 类型转换导致的,还介绍了 long 类型限制、char 等类型区别,规避方法是修改参数 MAX_STRING_SIZE 支持 32K。
|
9月前
|
Oracle 关系型数据库 数据库
【YashanDB知识库】oracle dblink varchar类型查询报错记录
在使用Oracle DBLink查询VARCHAR类型数据时,可能会遇到多种报错。通过了解常见错误原因,采取合适的解决方法,可以有效避免和处理这些错误。希望本文提供的分析和示例能帮助你在实际工作中更好地处理DBLink查询问题。
226 10
|
消息中间件 Oracle 关系型数据库
实时计算 Flink版操作报错之同步Oracle时出现主题为空的报错该怎么解决
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
资源调度 Oracle 关系型数据库
实时计算 Flink版产品使用问题之同步oracle表时,任务不报错,但是读不到数据,是什么导致的
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
16天前
|
Oracle 关系型数据库 Linux
【赵渝强老师】Oracle数据库配置助手:DBCA
Oracle数据库配置助手(DBCA)是用于创建和配置Oracle数据库的工具,支持图形界面和静默执行模式。本文介绍了使用DBCA在Linux环境下创建数据库的完整步骤,包括选择数据库操作类型、配置存储与网络选项、设置管理密码等,并提供了界面截图与视频讲解,帮助用户快速掌握数据库创建流程。
193 93
|
3月前
|
存储 Oracle 关系型数据库
服务器数据恢复—光纤存储上oracle数据库数据恢复案例
一台光纤服务器存储上有16块FC硬盘,上层部署了Oracle数据库。服务器存储前面板2个硬盘指示灯显示异常,存储映射到linux操作系统上的卷挂载不上,业务中断。 通过storage manager查看存储状态,发现逻辑卷状态失败。再查看物理磁盘状态,发现其中一块盘报告“警告”,硬盘指示灯显示异常的2块盘报告“失败”。 将当前存储的完整日志状态备份下来,解析备份出来的存储日志并获得了关于逻辑卷结构的部分信息。
|
29天前
|
SQL Oracle 关系型数据库
Oracle数据库创建表空间和索引的SQL语法示例
以上SQL语法提供了一种标准方式去组织Oracle数据库内部结构,并且通过合理使用可以显著改善查询速度及整体性能。需要注意,在实际应用过程当中应该根据具体业务需求、系统资源状况以及预期目标去合理规划并调整参数设置以达到最佳效果。
95 8
|
3月前
|
SQL Oracle 关系型数据库
比较MySQL和Oracle数据库系统,特别是在进行分页查询的方法上的不同
两者的性能差异将取决于数据量大小、索引优化、查询设计以及具体版本的数据库服务器。考虑硬件资源、数据库设计和具体需求对于实现优化的分页查询至关重要。开发者和数据库管理员需要根据自身使用的具体数据库系统版本和环境,选择最合适的分页机制,并进行必要的性能调优来满足应用需求。
125 11
|
3月前
|
存储 Oracle 关系型数据库
【赵渝强老师】Oracle RMAN的目录数据库
Oracle RMAN默认将备份元信息存储在控制文件中,但控制文件损坏或丢失会导致恢复失败,且备份增多会使控制文件无限增长。为解决这些问题,Oracle引入了RMAN目录数据库(Catalog Database),专门用于存储RMAN备份的元信息。使用目录数据库可提升备份管理效率,支持多数据库共享、长期备份历史记录存储,并可保存RMAN脚本。本文详细介绍了如何创建目录数据库、注册目标数据库及其操作步骤。