重启数据库的一场闹剧-阿里云开发者社区

开发者社区> jeanron100> 正文

重启数据库的一场闹剧

简介: 在几周前,某个测试环境在尝试impdp导入dump的时候报了错误,有个DBA立马做了kill session的操作,但是持续了5个小时,session状态还是KILLED,于是他们就在等待session被pmon回收。
+关注继续查看
在几周前,某个测试环境在尝试impdp导入dump的时候报了错误,有个DBA立马做了kill session的操作,但是持续了5个小时,session状态还是KILLED,于是他们就在等待session被pmon回收。结果又等了几个小时,还是KILLED状态。
最后两拨DBA在交接的时候把这个问题就说明了一下,另外一个DBA继续尝试impdp就报了下面的错误。

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

ORA-31626: job does not exist

ORA-31637: cannot create job XXXXXX for user xxxxxx

ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95

ORA-06512: at "SYS.KUPV$FT_INT", line 798

ORA-31635: unable to establish job resource synchronization
看起来还是很微妙的。
等到我受到邮件的时候,客户已经在抱怨了,我连入了环境,想看个究竟。那个session还是KILLED状态。
 SQL> select sid,serial#,status,machine,username from v$session where status='KILLED';
       SID    SERIAL# STATUS   MACHINE                                                          USERNAME
---------- ---------- -------- ---------------------------------------------------------------- ------------------------------
      4182      18078 KILLED   gpnuatndb01                                                      XXXXX07

因为已经做了kill操作,对应的进程已经不好定位了。所以作为一个小教训,自己会在kill session的时候尝试也找到对应的进程号。
从日志来看,其实没有相关的session和出问题的这个用户有关。
SELECT s.username,
      s.sid,
      s.serial#,
      t.used_ublk,
      t.used_urec,
      rs.segment_name,
      r.rssize,
      r.status
FROM  v$transaction t,
      v$session s,
      v$rollstat r,
      dba_rollback_segs rs
WHERE s.saddr = t.ses_addr
AND   t.xidusn = r.usn
AND   rs.segment_id = t.xidusn
ORDER BY t.used_ublk DESC;   

USERNAME                              SID    SERIAL#  USED_UBLK  USED_UREC SEGMENT_NAME                       RSSIZE STATUS
------------------------------ ---------- ---------- ---------- ---------- ------------------------------ ---------- ---------------
                                    11485      16129         16        266 _SYSSMU38_1987388439$             2220032 ONLINE
ABPDB10                              7912      46179          2         14 _SYSSMU83_1638092214$             2220032 ONLINE
ABPAPP6                             10393      35829          2         14 _SYSSMU68_660871585$              2220032 ONLINE
ABPAPP22                            15633      21311          1         14 _SYSSMU16_3995703066$             2220032 ONLINE
ABPAPP2                             11388      34725          1          2 _SYSSMU22_455640068$              2220032 ONLINE
ABPAPP22                             7838      44651          1          2 _SYSSMU31_2604536652$             2220032 ONLINE
ABPAPP6                              9473      16735          1          2 _SYSSMU33_1095900139$             2220032 ONLINE
CHIDB7                               9953      59583          1         14 _SYSSMU35_3472989533$            67231744 ONLINE
ABPAPP8                             12508      55865          1          2 _SYSSMU36_1444610389$             2220032 ONLINE
ABPAPP22                             7277      46993          1          2 _SYSSMU37_1673962577$             2220032 ONLINE
ABPAPP22                             7878      40061          1          2 _SYSSMU41_4063564024$             2220032 ONLINE
ABPAPP2                              7302      58443          1          2 _SYSSMU40_1843747856$             2220032 ONLINE
ABPAPP2                             12519      28683          1          2 _SYSSMU45_779001323$              2220032 ONLINE
ABPAPP2                              8380      65241          1         14 _SYSSMU47_1833818776$             2220032 ONLINE
ABPAPP8                              9973      44481          1          2 _SYSSMU52_429211313$              2220032 ONLINE
所以从这个角度来看,其实后台并没有在持续回滚,应该是系统级的进程还没有释放导致了数据库端标记为了KILLED,但是没有实际采取行动。
查看alert日志也没有什么特别之处。
但是过了一会,突然发现多出来很多的日志,最关键的是数据库怎么突然down了,日志和pmon也有一定的关系。
Archived Log entry 1037518 added for thread 1 sequence 1037564 ID 0xd5242bc1 dest 1:
Tue May 26 10:41:25 2015
PMON failed to acquire latch, see PMON dump
Tue May 26 10:42:26 2015
PMON failed to acquire latch, see PMON dump
Tue May 26 10:44:06 2015
PMON failed to acquire latch, see PMON dump
Tue May 26 10:45:06 2015
PMON failed to acquire latch, see PMON dump
Tue May 26 10:46:46 2015
PMON failed to acquire latch, see PMON dump
Tue May 26 10:47:12 2015
Thread 1 cannot allocate new log, sequence 1037566
Checkpoint not complete
  Current log# 3 seq# 1037565 mem# 0: /oravl02/oradata/UATDB1/redo_g3_m1.dbf
  Current log# 3 seq# 1037565 mem# 1: /oravl03/oradata/UATDB1/redo_g3_m2.dbf
Tue May 26 10:47:13 2015
Completed checkpoint up to RBA [0xfd4fb.2.10], SCN: 13552283008295
Beginning log switch checkpoint up to RBA [0xfd4fe.2.10], SCN: 13552283030199
Thread 1 advanced to log sequence 1037566 (LGWR switch)
  Current log# 4 seq# 1037566 mem# 0: /oravl02/oradata/UATDB1/redo_g4_m1.dbf
  Current log# 4 seq# 1037566 mem# 1: /oravl03/oradata/UATDB1/redo_g4_m2.dbf
Tue May 26 10:47:13 2015
Archived Log entry 1037519 added for thread 1 sequence 1037565 ID 0xd5242bc1 dest 1:
Tue May 26 10:47:46 2015
PMON failed to acquire latch, see PMON dump
Tue May 26 10:48:05 2015
Shutting down instance (immediate)
Stopping background process SMCO
Shutting down instance: further logons disabled
Tue May 26 10:48:06 2015
Completed checkpoint up to RBA [0xfd4fe.2.10], SCN: 13552283030199
Completed checkpoint up to RBA [0xfd4fd.2.10], SCN: 13552283023016
Completed checkpoint up to RBA [0xfd4fc.2.10], SCN: 13552283015563
Stopping background process QMNC
Tue May 26 10:49:16 2015
PMON failed to acquire latch, see PMON dump
Tue May 26 10:50:16 2015
PMON failed to acquire latch, see PMON dump
因为当时是早班时间,也没多想,正在琢磨是不是什么bug导致的宕机,简单收集完信息,就是尽快把数据库给启动起来。
启动的时候也报错了。当时就有些凌乱了。
SQL> startup mount
ORACLE instance started.
Total System Global Area 1.2727E+10 bytes
Fixed Size                  2280384 bytes
Variable Size            1.0855E+10 bytes
Database Buffers         1577058304 bytes
Redo Buffers              292958208 bytes
Database mounted.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00450: background process 'QMNC' did not start
ORA-00443: background process "QMNC" did not start
Process ID: 47857
Session ID: 10341 Serial number: 3

赶紧去查看日志,有些疑惑的是,数据库怎么启动起来了。我用sqlplus反复尝试都没有问题。真是奇怪。
对于这种问题还是相信日志,我去找对应时间点的日志,从日志来看
数据库似乎是使用了shutdown immediate的方式停掉的。有可能是人为的。

Tue May 26 10:48:05 2015

Shutting down instance (immediate)

Stopping background process SMCO

我发送了封邮件抄给组内去确认,还没有得到消息。
然后继续查看日志,看到后面又启动了两次,一次启动失败,一次启动成功,但是我只启动了一次啊。
最后得到确认,是另外一个远在菲律宾的dba启动的,但是事先没有发送邮件。这样问题就清楚了,但是也算是大清早的一场闹剧。2个人同时在启动数据库,最后也没有造成什么影响,可见oracle还是很健壮的,对于启库的并发都考虑了。:)
这个案例带给我们的其实就是在清理session的时候,最好还是先绑定一下系统级操作进程,然后再清除,这样也会给自己带来很多便利,清除完成后,做一个确认检查,可能session通过kill方式不一定能释放系统进程资源,这个时候在判断没有回滚事务的前提下,
可以采用手工清理系统进程号的方式来完成。
至于启库的闹剧还是完全可以避免的,还是协调的时候出了点问题。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
一则数据库无法重启的案例分析
  今天一个开发的同事找到我,说有个问题想咨询一下我,突然想起他昨天让我帮他处理一个工单,他这么一问我才想起来还没做,结果他说是另外一件事,说有个开发测试的环境,数据库报04031的错误,想让我帮忙看看是怎么回事,这种问题刚好就找对了。
833 0
记一次数据库重启后归档急剧增加的问题
在本地的环境中测试外部表的性能,由于空间有限,不一会儿归档的空间就爆了。然后文件貌似出现了系统级的问题,刚刚rm掉的归档日志文件。隔了几秒钟再ls,就出现了。
979 0
阿里云服务器ECS远程登录用户名密码查询方法
阿里云服务器ECS远程连接登录输入用户名和密码,阿里云没有默认密码,如果购买时没设置需要先重置实例密码,Windows用户名是administrator,Linux账号是root,阿小云来详细说下阿里云服务器远程登录连接用户名和密码查询方法
2247 0
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
3972 0
开始启用公司数据重要等级划分和备份恢复方案啦
"数据中心的容灾备份和业务连续对公司来说有多重要?我们来看看国外在这方面的一些统计吧:金融业在灾难停机两天内所受损失为日营业额的50%;如果在两星期内无法恢复信息系统,75%的公司将业务停顿,43%的公司将再也无法开业;没有实施灾难备份措施的公司60%将在灾难后2-3年间破产。
886 0
阿里云服务器安全组设置内网互通的方法
虽然0.0.0.0/0使用非常方便,但是发现很多同学使用它来做内网互通,这是有安全风险的,实例有可能会在经典网络被内网IP访问到。下面介绍一下四种安全的内网互联设置方法。 购买前请先:领取阿里云幸运券,有很多优惠,可到下文中领取。
9325 0
Oracle数据库重启后密码失效的问题(r12笔记第91天)
  前几天,我和系统运维的同事处理一个看似诡异的问题,他找到我说应用服务器启动的时候报了DB的Error,但是错误信息有限,他也没法完全定位到错误的原因,所以就希望我来帮忙看看这个问题是怎么回事,怎么解决。
1304 0
重启数据库的一场闹剧
在几周前,某个测试环境在尝试impdp导入dump的时候报了错误,有个DBA立马做了kill session的操作,但是持续了5个小时,session状态还是KILLED,于是他们就在等待session被pmon回收。
744 0
+关注
jeanron100
Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
1180
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载