重启数据库的一场闹剧

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 在几周前,某个测试环境在尝试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方式不一定能释放系统进程资源,这个时候在判断没有回滚事务的前提下,
可以采用手工清理系统进程号的方式来完成。
至于启库的闹剧还是完全可以避免的,还是协调的时候出了点问题。
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
7月前
|
关系型数据库 MySQL Linux
Linux启动停止重启Mysql数据库针对各个版本的数据库
Linux启动停止重启Mysql数据库针对各个版本的数据库
43 0
|
2月前
|
数据库连接 网络安全 数据库
网站链接数据库失败,重启网站好了
网站链接数据库失败,重启网站好了
|
2月前
|
关系型数据库 MySQL Linux
易优CMS请重启MYSQL数据库,或者联系空间服务商处理[错误报错·····]出现以下提示该怎么办?-eyoucms
易优CMS请重启MYSQL数据库,或者联系空间服务商处理[错误报错·····]出现以下提示该怎么办?-eyoucms
|
1月前
|
SQL 关系型数据库 数据库连接
"Nacos 2.1.0版本数据库配置写入难题破解攻略:一步步教你排查连接、权限和配置问题,重启服务轻松解决!"
【10月更文挑战第23天】在使用Nacos 2.1.0版本时,可能会遇到无法将配置信息写入数据库的问题。本文将引导你逐步解决这一问题,包括检查数据库连接、用户权限、Nacos配置文件,并提供示例代码和详细步骤。通过这些方法,你可以有效解决配置写入失败的问题。
64 0
|
3月前
|
关系型数据库 数据库 网络虚拟化
Docker环境下重启PostgreSQL数据库服务的全面指南与代码示例
由于时间和空间限制,我将在后续的回答中分别涉及到“Python中采用lasso、SCAD、LARS技术分析棒球运动员薪资的案例集锦”以及“Docker环境下重启PostgreSQL数据库服务的全面指南与代码示例”。如果你有任何一个问题的优先顺序或需要立即回答的,请告知。
74 0
|
5月前
|
弹性计算 NoSQL 网络安全
软件开发常见之云数据库Redis连接不上如何解决,修改配置后,需要重启下redis服务,配置才能生效呢,是重启,而不是重载配置,最后导致的问题是点击了的重启,配置修改了之后必须点击重启,而不是修改
软件开发常见之云数据库Redis连接不上如何解决,修改配置后,需要重启下redis服务,配置才能生效呢,是重启,而不是重载配置,最后导致的问题是点击了的重启,配置修改了之后必须点击重启,而不是修改
|
5月前
|
SQL Java 持续交付
实时计算 Flink版产品使用问题之源数据库一直在新增表或修改表结构,需要进行相应的修改和重启,该如何简化
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
7月前
|
SQL 资源调度 关系型数据库
实时计算 Flink版产品使用合集之源表的数据被删除后,目标数据库在重启服务后没有进行相应的删除操作,是什么原因
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStreamAPI、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
前端开发 数据库
前端项目实战伍拾壹​react-admin+material ui-踩坑-创建数据库完数据库表需要重启
前端项目实战伍拾壹​react-admin+material ui-踩坑-创建数据库完数据库表需要重启
87 0
|
关系型数据库 Java MySQL
Java 最常见的面试题:一张自增表里面总共有 7 条数据,删除了最后 2 条数据,重启 mysql 数据库,又插入了一条数据,此时 id 是几?
Java 最常见的面试题:一张自增表里面总共有 7 条数据,删除了最后 2 条数据,重启 mysql 数据库,又插入了一条数据,此时 id 是几?