故障分析:数据库一致性关闭缓慢问题诊断

想必我们大家都知道,Shutdown immediate即一致性关闭数据库,数据库下次启动不需要做实例恢复即可open数据库。那么当数据库一致性关闭出现缓慢等状况时,该怎么办呢?那我们就来一起分析一下,数据库一致性关闭缓慢问题。

shutdown immediate在数据库中会做哪些操作?

从以上图得知在shutdownimmediate关闭数据库只需要在数据库中强制选择检查点并关闭文件,不需要等待当前事物处理结束,不需要等待当前会话结束,不允许新连接。

引发shutdown immediate slowly and hanging的原因

>>>>

processes still continue to beconnected to the database and do not terminate

>>>>

如果数据库在关闭的时候,有进程持续连接数据,并且不能被中断,就会造成shutdown immediate slowly或者hanging

>>>>

SMON is cleaning temp segments orperforming delayed block cleanouts

>>>>

Temp segment cleanup: 在数据库中如果有大量的sql做排序操作,pga中分配的sort_area_size太小,不能满足排序的需要时候,就会占用临时段进行排序,这些分配的临时段分区,一旦分配,直到数据库shutdown 的时候才会释放。所以当我在进行数据库关闭时,有大量的临时分区被分配需要立刻被释放,这会引起row cache 的资源竞争,从而导致数据库shutdownimmediate变慢或者hanging。

>>>>

Uncommitted transactions are beingrolled back

>>>>

当数据库需要以一致性关闭数据库时,如果此刻数据库中正好存在运行的大事物,这时候数据库需要对大事物进行回滚(请不要误解之前提到的知识点,之前提到shutdown immediate 不需要等待事物是指不要等待此事物提交结束,而是要对此刻所有未提交的事物进行回滚),因为大事物的回滚需要很长的时间,所以就会在执行shutdownimmediate时感觉solwly或者hanging。当然对于事物的回滚,我们可以通过设置隐藏参数来加快回滚,但是另外考虑到高速的回滚设置会引起资源竞争,这样可能会加剧shutdown immediate变慢(有的特殊情况除外)

>>>>

Oracle Bug

>>>>

Oracle BUG oracle的某些BUG也会导致shutdownimmedaite变慢

以下是我在mos上搜索的BUG证明BUG也会导致shutdown immediate

Bug 6512622 - SHUTDOWN IMMEDIATE hangs / OERI[3708] (文档 ID 6512622.8)

Bug 5057695: Shutdown Immediate Very Slow To CloseDatabase (文档 ID 428688.1)

Bug 23309880 - SHUTDOWN IMMEDIATE may hang on primarydatabase if DG broker is configured (文档 ID 23309880.8)

那当数据库出现hanging或者slowly时,我们应该如何做?

当数据库需要进行一致性关闭时,建议首先去检查下一些视图用来进行确认。

1>for large queries

select count(*) from v$session_longops where time_remaining>0;

通过以上SQL查询数据库当前环境是否存在长会话操作

2>for large transactions

select sum(used_ublk) from v$transaction;

通过以上SQL查询数据库中此时是否存在大事物操作

当我们查询出来第一个sql的值大于0或者第二个sql是一个很大的值,在执行shutdown immediate 的时候就会相对花费一个比较长的时间。

当查询出来第一个值大于0,第二个值为0时,我们可以在执行shutdown immedaite slowly时改用shutdown abort来关闭数据库,因为此时数据库中是没有事物在运行的,我们使用shutdown abort来关闭数据库,下次启动数据库很容易就会达到一致性的状态。

对于查询出来第一个值大于0,第二个值也是一个很大值的情况,shutdown abort的操作就不适用,尤其是当我们需要对数据库进行冷备份的时候,必须一致性关闭。另外如果在存在大事物时强制关闭数据库,会导致数据库在下次启动需要花费大量时间,也有可能会导致数据库不能正常open(因为有可能发生下次数据库启动时,在线日志损坏)

另外如果有大事物正在运行,我们可以通过一些脚本去评估事物回滚或者commit的操作哪个会在最短的时间执行完成,从而确认是等待当前事物提交结束执行shutdown immedaite还是rollback 事物后执行shutdown immediate。

如何排查其他原因导致的故障

最直接的方法当然是查看alert和trace日志了。

通过查看alter和trace日志我们就可以看到数据库shutdown immediate是否是因为数据库正在做临时段清除操作或者是一些进程持续连接数据库无法正常中断又或者是因为Oracle 的某种BUG导致的shutdown immediate slowly and hanging

如果我们发现是因为临时段清除导致的数据库无法正常关闭,也可以通过shutdown abort的方式重启数据库。

当是因为一些数据库连接无法正常终止而导致的数据库shutdown immedaite slowly and hanging,我们可以在操作系统层面采用Kill 方式终止进程之后,再采用shutdown immediate的方式关闭数据库

当是因为某些BUG导致的shutdown immediate slowly and hanging,我们可以通过查询MOS来确认数据库BUG,进而通过打补丁的方式解决问题。

case:Shutdown Immediate Hang Waiting for MMON process

当我使用shutdown immediate停止某一套数据库环境的时候,发现数据库停止hang waiting(数据库版本11.2.0.1)

首先我查看alert日志,在alter日志中发现以下信息:

Shutting down instance (immediate)

Stopping background process SMCO

Shutting down instance: further logons disabled

Stopping background process QMNC

Stopping background process MMNL

Thu Aug 05 13:28:48 2010

Background process MMNL not dead after 10 seconds

Killing background process MMNL

Stopping background process MMON

Thu Aug 05 13:29:20 2010

Background process MMON not dead after 30 seconds

Killing background process MMON

License high water mark = 1

Thu Aug 05 13:34:23 2010

Active process 12377 user 'oracle' program 'oracle@bsf14f(MMON)'

Active process 12377 user 'oracle' program 'oracle@bsf14f(MMON)'

Active process 22755 user 'oracle' program 'oracle@bsf14f(M000)'

Active process 22755 user 'oracle' program 'oracle@bsf14f(M000)'

SHUTDOWN: waiting for logins to complete.

从以上信息我们可以看到数据库shutdown 正在等待mmon和mmon的slave进程终止,数据库无法正常终止进程

查看完alert日志之后,因为无法看到更详细的信息,因此做了dump systemstate分析

从systemstate中查看到以下信息:

(latch info) wait_event=0 bits=100

holding (efd=4) 38000b808 ksuosstats global area level=8

Location from where latch is held: ksu.h LINE:12921ID:ksugetosstat:

Context saved from call: 0

state=busy [holder orapid=16] wlstate=free [value=0]

waiters [orapid (seconds since: put on list, posted, alivecheck)]:

27 (985, 1281008063, 985)

waiter count=1

Process Group: DEFAULT, pseudo proc: 0x3bf51c538

O/S info: user: oracle, term: UNKNOWN, ospid: 12379 (DEAD)

OSD pid info: Unix process pid: 12379, image: oracle@bsf14f(MMNL)

从以上信息可以看到mmnl持有latch from ksugetosstat.

另外通过操作系统命令truss进程得到以下信息:

22395: open("/dev/kstat", O_RDONLY) = 19

22395: ioctl(19, KSTAT_IOC_CHAIN_ID, 0x00000000) = 227215

22395: ioctl(19, KSTAT_IOC_READ, "kstat_headers")Err#12 ENOMEM

22395: ioctl(19, KSTAT_IOC_READ, "kstat_headers") =227215

22395: ioctl(19, KSTAT_IOC_READ, "cpu_info352") =227215

22395: ioctl(19, KSTAT_IOC_READ, "cpu_info353") =227215

22395: ioctl(19, KSTAT_IOC_READ, "cpu_info354") =227215

...

22395: close(19) = 0

22395: open("/dev/kstat", O_RDONLY) = 19

22395: ioctl(19, KSTAT_IOC_CHAIN_ID, 0x00000000) = 227215

22395: ioctl(19, KSTAT_IOC_READ, "kstat_headers")Err#12 ENOMEM

22395: ioctl(19, KSTAT_IOC_READ, "kstat_headers") =227215

22395: ioctl(19, KSTAT_IOC_READ, "sysinfo") = 227215

22395: ioctl(19, KSTAT_IOC_READ, "cpu_stat352") =227215

22395: ioctl(19, KSTAT_IOC_READ, "cpu_stat353") =227215

从以上信息我们可以看到进程从在loop。

通过得知以上信息之后怀疑是oracle 11.2.0.1的BUG,因此查询MOS,在MOS查询文档确实是因为Oracle 11.2.0.1的BUG:Bug 9132776 - AWR SNAPSHOT NOT GENERATED AFTER 11.2 UPGRADE导致,最后应用补丁 one off Patch 9132776解决。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-12-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Pythonista

Nginx 分析access日志文件

722
来自专栏一名合格java开发的自我修养

Spring AOP不拦截从对象内部调用的方法原因

  拦截器的实现原理很简单,就是动态代理,实现AOP机制。当外部调用被拦截bean的拦截方法时,可以选择在拦截之前或者之后等条件执行拦截方法之外的逻辑,比如特殊...

611
来自专栏前端杂货铺

node中子进程同步输出

管道 通过“child_process”模块fork出来的子进程都是返回一个ChildProcess对象实例,ChildProcess类比较特殊无法手动创建该对...

2606
来自专栏容器云生态

redis超时原因排查

1.低效操作产生的延迟。单命令操作一半很快不会造成这样,SORT,LREM, SUNION,keys ,* 等操作都会影响响应时间。 使用进程监控程序(top,...

3756

Kafka体系结构:日志压缩

这篇文章是从我们介绍Kafka 体系结构的一系列文章中获得的启发,包括Kafka topic架构,Kafka生产者架构,Kafka消费者架构和Kafka生态系统...

1663
来自专栏北京马哥教育

MySQL 数据库上线后根据 status 状态优化

马哥linux运维 | 最专业的linux培训机构 ---- 网上有很多的文章教怎么配置mysql服务器,但考虑到服务器硬件配置的不同,具体应用的差别,那些文...

2726
来自专栏Linyb极客之路

Tomcat实战-调优方案

Tomcat的默认配置,性能并不是最优的,我们可以通过优化tomcat以此来提高网站的并发能力。提高Tomcat的性能可以分为两个方向。

1033
来自专栏从零学习云计算

kubernetes学习记录(11)——深入学习Service

在之前的周会上汇报Kubernetes学习结果的时候,被问到一个问题:“一个Service能否提供多种服务,能否代理多组Pod副本?”这里来做一定的研究。 Se...

1910
来自专栏Java3y

过滤器监听器面试题都在这里

以下我是归纳的过滤器监听器知识点图: ? 图上的知识点都可以在我其他的文章内找到相应内容。 监听器常见面试题 监听器有哪些作用和用法? 监听器有哪些作用和用法?...

2896
来自专栏高剑林的专栏

数据一致性和 io 类型

对于单一的存储系统来说,数据一致性,性能和可靠性是几个矛盾的指标。如何找到合适点,平衡几个指标的关系,从操作系统最底层提升产品的可靠性和性能,是一项长期的任务。

1.7K1

扫描关注云+社区