UDN-企业互联网技术人气社区

板块导航

浏览  : 1067
回复  : 0

[讨论交流] 一则数据库无法启动的奇怪案例分析

[复制链接]
巡山霉少女的头像 楼主
发表于 2016-3-5 19:41:37 | 显示全部楼层 |阅读模式
本帖最后由 巡山霉少女 于 2016-3-5 19:42 编辑

  关于数据库的启停,以前一直认为是最简单,最没有技术含量的任务,但是接手的环境越多,越来越证明我最初的想法是错误的。数据库的启停是一个敏感操作,重启一定是有着特定的原因和需求。而且这个过程中存在这太多的可能性,很可能在同一会话窗口中,停掉数据库再次启动就会报错;很可能硬件扩容,也会导致数据库实例无法启动;这个时候重启前的准备和分析就尤为重要。

  在此大体把启停中的问题归为三类,数据库无法启动,数据库无法登录,数据库宕机。我们在此主要讨论数据库无法启动的场景。

  看起来很简单的一件事情,重启的过程中总是可能节外生枝,总是感觉数据库实例有时候不是那么配合,总是在启动过程中会发牢骚。从我的经历来看,我碰到的绝大多数问题都发生在open阶段。

  对于数据库无法启动的原因大体有以下几个方面需要考虑。

  1)系统内核参数设置不当,比如当前的内核参数设置在需要增加数据库级的配置的情况下是否能够满足,或者在硬件扩容的情况下,现有的内核参数是否需要做相应的调整。举个例子,之前看到一个数据库环境中的内存为16G,但是实际上process只设置了150,很明显可以充分利用这部分资源, 在申请维护窗口重启的过程中,发现调整了process大小之后,数据库实例无法启动,根本原因就是内核参数shmmax设置过低导致。

  2)数据库参数变量设置不当,数据库参数或者变量的一些设置可能会和现有的资源使用情况冲突,在这种情况下,数据库参数的设置很可能过高或者过低,导致硬件资源的使用无法满足。比如数据库层面的process大小还是需要和系统内核参数有一个映射,设置不能太高。

  我们以一个真实的案例来说明

  这是我接手的一套测试环境。这是一套11gR2的环境。

  当我准备连接到环境的时候,首先查看数据库的进程情况。

  可以看到目前的环境存在两个数据库实例newtest和test04,在此我们需要连接newtest.

  
  1. $ ps -ef|grep smon

  2.   oracle 1451 1 0 Feb02 ? 00:00:30 ora_smon_newtest

  3.   oracle 9133 1 0 Feb03 ? 00:00:58 ora_smon_test04

  4.   oracle 24734 24596 0 17:36 pts/0 00:00:00 grep smon
复制代码


  但是使用sqlplus登录的时候却碰到了一个非常奇怪的问题。

  
  1. $ sqlplus / as sysdba

  2.   SQL*Plus: Release 11.2.0.4.0 Production on Wed Feb 17 17:36:08 2016

  3.   Copyright (c) 1982, 2013, Oracle. All rights reserved.

  4.   Connected to an idle instance.

  5.   SQL>
复制代码


  按理说应该直接使用sys用户连接到了数据库实例,但是在此却显示是一个空实例。这到底是哪里出了问题呢。首先排除了ORACLE_SID大小写,乱码的问题。

  查看数据库日志也没有发现任何异常信息,实例还是active的。

  在此我们先卖个关子,继续往下看。

  因为是测试环境,所以也可以做一些简单的尝试,于是我就尝试启动数据库实例。

  Nomount阶段竟然没有报出任何的错误。

  
  1. SQL> startup nomount

  2.   ORACLE instance started.

  3.   Total System Global Area 4993982464 bytes

  4.   Fixed Size 2261808 bytes

  5.   Variable Size 1006636240 bytes

  6.   Database Buffers 3976200192 bytes

  7.   Redo Buffers 8884224 bytes
复制代码


  这个时候都有些怀疑是否之前的分析是正确的。

  继续把实例置为mount阶段,这个时候就抛出了下面的问题。

  
  1. SQL> alter database mount;

  2.   alter database mount

  3.   *

  4.   ERROR at line 1:

  5.   ORA-00205: error in identifying control file, check alert log for more info
复制代码


  这个时候,查看日志就是一个很好的办法,在11g中可以使用adr的方式来查看,或者使用下面的方式来直接找到日志所在目录。

  
  1. SQL> show parameter background_dump_dest

  2.   NAME TYPE VALUE

  3.   ------------------------------------ ----------- ------------------------------

  4.   background_dump_dest string /U01/app/oracle/diag/rdbms/new

  5.   test/newtest/trace
复制代码


  得到的日志如下:

  
  1. MMNL started with pid=16, OS id=24683

  2.   starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...

  3.   starting up 1 shared server(s) ...

  4.   ORACLE_BASE from environment = /DATA/app/oracle

  5.   Wed Feb 17 17:36:21 2016

  6.   alter database mount

  7.   ORA-00210: cannot open the specified control file

  8.   ORA-00202: control file: '/U01/app/oracle/fast_recovery_area/newtest/control02.ctl'

  9.   ORA-27086: unable to lock file - already in use

  10.   Linux-x86_64 Error: 11: Resource temporarily unavailable

  11.   Additional information: 8

  12.   Additional information: 1449

  13.   ORA-00210: cannot open the specified control file

  14.   ORA-00202: control file: '/U01/app/oracle/oradata/newtest/control01.ctl'

  15.   ORA-27086: unable to lock file - already in use

  16.   Linux-x86_64 Error: 11: Resource temporarily unavailable

  17.   Additional information: 8

  18.   Additional information: 1449

  19.   ORA-205 signalled during: alter database mount...
复制代码


  通过上面的错误信息可以很清晰看到控制文件已经被占用了。

  这个时候查看数据库实例的情况,发现结果让人大跌眼镜,竟然有两个实例为newtest.

  
  1. [oracle@BX_133_45 trace]$ ps -ef|grep smon

  2.   oracle 1451 1 0 Feb02 ? 00:00:30 ora_smon_newtest

  3.   oracle 9133 1 0 Feb03 ? 00:00:58 ora_smon_test04

  4.   oracle 24677 1 0 17:36 ? 00:00:00 ora_smon_newtest

  5.   oracle 24734 24596 0 17:36 pts/0 00:00:00 grep smon
复制代码


  那么这个问题该怎么解释呢,在Unix,Linux系统中,SID和ORACLE_HOME在一起哈希后会得到一个唯一的值作为SGA的key。

  当oracle实例启动时,在操作系统上的fork进程会根据Oracle_SID来创建相关后台进程。

  Oracle 11g 支持Oracle_SID的长度为12位,db_name的长度为8位。而在很早的版本中ORACLE_SID只支持4位,这也就是我们经常看到ORCL,PROD这样的数据库的一个原因吧。

  在这个场景中,ORACLE_SID没有任何问题,那么仔细来品味上面的话,另外一个可能就是ORACLE_HOME了。

  我们首先把刚刚没有启动的实例先停掉,避免有更多的干扰。

  查看共享内存段的情况如下,可见数据库实例还是没有受到影响。

  
  1. $ ipcs -m

  2.   ------ Shared Memory Segments --------

  3.   key shmid owner perms bytes nattch status

  4.   0x00000000 1114113 oracle 640 33554432 23

  5.   0x00000000 1146882 oracle 640 4982833152 23

  6.   0x849f1498 1179651 oracle 640 2097152 23

  7.   0x00000000 3211268 oracle 640 33554432 23

  8.   0x00000000 3244037 oracle 640 4982833152 23

  9.   0x9d2300b0 3276806 oracle 640 2097152 23
复制代码


  这个时候再次观察实例的smon进程,发现原来的进程依然存在。

  
  1. $ ps -ef|grep smon

  2.   oracle 1451 1 0 Feb02 ? 00:00:30 ora_smon_newtest

  3.   oracle 9133 1 0 Feb03 ? 00:00:58 ora_smon_test04

  4.   oracle 24779 24596 0 17:37 pts/0 00:00:00 grep smon
复制代码


  再次确认ORACLE_SID

  
  1. $ echo $ORACLE_SID

  2.   newtest
复制代码


  确认ORACLE_HOME

  
  1. $ echo $ORACLE_HOME

  2.   /DATA/app/oracle/11.2.0.4
复制代码


  好了,我们来开始分析:

  找到系统级所在的句柄,根据smon进程对应的进程号1451在/proc/1451下面,查看environ的设置情况,可以使用下面的方式来查看这个进程对应的环境变量ORACLE_HOME

  
  1. $ cat /proc/1451/environ|xargs -0 -n1 |grep ORACLE_HOME

  2.   ORACLE_HOME=/U01/app/oracle/product/11.2.0.2/db_1
复制代码

  这个时候真相浮出水面,原来是ORACLE_HOME设置不同。

  手工指定ORACLE_HOME,然后再次尝试

  
  1. $ export ORACLE_HOME=/U01/app/oracle/product/11.2.0.2/db_1

  2.   $ sqlplus / as sysdba

  3.   SQL*Plus: Release 11.2.0.4.0 Production on Wed Feb 17 17:49:00 2016

  4.   Copyright (c) 1982, 2013, Oracle. All rights reserved.

  5.   Connected to:

  6.   Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

  7.   With the Partitioning, OLAP, Data Mining and Real Application Testing options
复制代码


  这个时候就达到了预期的效果

  
  1. SQL> select database_role from v$database;

  2.   DATABASE_ROLE

  3.   PRIMARY
复制代码


  通过这个案例可以发现,在环境维护中需要遵循一定的规范,如果不严谨不规范,就会出现一些看似奇怪的问题;对于数据库实例的启动过程需要有深刻的理解,需要不断的反问自己为什么,怎么求证,能够说服自己才能让别人信服。

  云智慧监控宝数据库性能监控,支持MySQL、Oracle、SQLServer、MongoDB、Redis、Memcache等主流关系型及非关系型数据库。支持内网、外网双重生产环境,;实时统计性能指标,全面呈现分析报告。多维度及时告警,帮您快速发现性能瓶颈。

640.webp (3).jpg


  IO性能监控图表

640.webp (2).jpg


  内存进程图表

640.webp (1).jpg

相关帖子

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部