一条sql语句导致的数据库宕机问题及分析

之前分享过一篇博文,是一条sql语句"导致"的数据库宕机,上次是另有原因,这次真碰到一个案例,而且是在重要的环境上,希望大家引以为戒。
数据库是基于Linux64的版本,版本是11.2.0.2.0,已经打了最新的psu.
数据库的访问用户数大约在1000左右,当时查看服务器的cpu已经是100%了,有大约10个进程都是cpu 100%,数据库逻辑读也是超高,一秒钟大约是接近百兆的情况,sga是12G,已用了sga的自动管理(sga_target=0), 查看内存组件时发现buffer_cache已经有shrink的迹象,而且buffer_cache的min_size还是有一点小,就在可用范围内给buffer cache 增大了几百兆的样子,生成了一个ADDM, 报告里第一条就是希望设置sga_target为一个特定的值,性能可能会有一定的提升,当时想,sga_max_size都已经是12G了,设置sga_target=12G也没有问题吧
就按照它的提示做了,
alter system set sga_target=12G;
结果命令提顿了几秒钟,然后就崩出来一个end_of_communicaiton的ora错误,我感觉出问题了,已查看进程,数据库是真down掉了。
查看alert日志,发现时由于resize_sga的ora-600问题导致的,所有的在线进程都被自动给kill掉了。

然后马上和相应的team来协调,把数据库先startup了。再查看具体的信息。
alert日志如下:
Thread 1 advanced to log sequence 14054 (LGWR switch)

  Current log# 2 seq# 14054 mem# 0: /dbtestPR1/oracle/TEST01/redolog_A2/redo/redo02A.log

  Current log# 2 seq# 14054 mem# 1: /dbtestPR1/oracle/TEST01/redolog_B2/redo/redo02B.log

Wed Apr 09 20:07:10 2014

Archived Log entry 14090 added for thread 1 sequence 14053 ID 0xb8c6d509 dest 1:

Wed Apr 09 20:40:13 2014

Errors in file /opt/app/oracle/dbtestpr1/diag/rdbms/TEST01/TEST01/trace/TEST01_mman_27182.trc (incident=360075):

ORA-00600: internal error code, arguments: [kmgsb_resize_sga_target_1], [0], [768], [4], [], [], [], [], [], [], [], []

Incident details in: /opt/app/oracle/dbtestpr1/diag/rdbms/TEST01/TEST01/incident/incdir_360075/TEST01_mman_27182_i360075.trc

Use ADRCI or Support Workbench to package the incident.

See Note 411.1 at My Oracle Support for error and packaging details.

Errors in file /opt/app/oracle/dbtestpr1/diag/rdbms/TEST01/TEST01/trace/TEST01_mman_27182.trc:

ORA-00600: internal error code, arguments: [kmgsb_resize_sga_target_1], [0], [768], [4], [], [], [], [], [], [], [], []

MMAN (ospid: 27182): terminating the instance due to error 822

Wed Apr 09 20:40:14 2014

opiodr aborting process unknown ospid (25518) as a result of ORA-1092

Wed Apr 09 20:40:14 2014

ORA-1092 : opitsk aborting process

Wed Apr 09 20:40:14 2014

Wed Apr 09 20:40:14 2014

opiodr aborting process unknown ospid (27776) as a result of ORA-1092opiodr aborting process unknown ospid (10547) as a result of ORA-1092

Wed Apr 09 20:40:14 2014

opiodr aborting process unknown ospid (7458) as a result of ORA-1092

Wed Apr 09 20:40:14 2014

Wed Apr 09 20:40:14 2014

ORA-1092 : opitsk aborting process

ORA-1092 : opitsk aborting process

Wed Apr 09 20:40:14 2014

ORA-1092 : opitsk aborting process

Wed Apr 09 20:40:14 2014

opiodr aborting process unknown ospid (30719) as a result of ORA-1092

Wed Apr 09 20:40:14 2014

ORA-1092 : opitsk aborting process

.......

ORA-1092 : opitsk aborting process

Wed Apr 09 20:40:14 2014

System state dump requested by (instance=1, osid=27182 (MMAN)), summary=[abnormal instance termination].

System State dumped to trace file /opt/app/oracle/dbtestpr1/diag/rdbms/TEST01/TEST01/trace/TEST01_diag_27176.trc

Instance terminated by MMAN, pid = 27182

查看metalink,确实有这样的一个bug.
Bug 10173135 - Resize SGA_TARGET crashes instance with ORA-600 [kmgsb_resize_sga_target_1] (Doc ID 10173135.8)

而且影响的版本如下:

Product (Component) Oracle Server (Rdbms)
Range of versions believed to be affected Versions BELOW 12.1
Versions confirmed as being affected
Platforms affected Generic (all / most platforms affected)

真是撞到枪口上了,查看了下,在11.2.0.3.0中才修复了这个问题。
然后自我总结了下,发现sga的自动管理操作还是需要谨慎,新特性的使用也是如此,一定要有足够的把握才能使用。

时间: 2024-10-01 13:38:33

一条sql语句导致的数据库宕机问题及分析的相关文章

一条sql语句“导致”的数据库宕机问题及分析

最近测试环境需要做一些变更,把测试环境切分成两套环境,存储空间也需要压缩压缩和整理. unix组的人已经开始做空间划分了,然后我们需要在此基础上重建一套环境. 有些数据文件使用空间不大,所以准备压缩一下. 用了下面的sql语句,结果跑了十几秒中就抛了下面的错误. SQL> set linesize 200 SQL> col name for a40 SQL> col resizecmd for a80 SQL> select a.file#,a.name,a.bytes/1024/

通过一条sql语句访问不同数据库服务器中的数据库对象的方法

对象|访问|服务器|数据|数据库|语句 在我们做数据库程序开发的时候,经常会遇到这种情况:需要将一个数据库服务器中的数据导入到另一个数据库服务器的表中.通常我们会使用这种方法:先把一个数据库中的数据取出来放到某出,然后再把这些数据一条条插入到目的数据库中,这种方法效率较低,写起程序来也很繁琐,容易出错.另外一种方法是使用bcp或BULK INSERT语句,将数据导入到一个文件中,再从此文件中导出到目的数据库,这种方法虽然效率稍高,但也有很多不如意的地方,单是在导入时怎样找到另外一台机器上的数据导

由一条sql语句导致的系统IO问题

早上来到公司,照例进行了简单的检查,发现系统负载不高,就开始计划一些sql tuning的工作,但是过了一会,在通过shell命令查找一些sql信息的时候,发现系统的反应有些慢,当时也没在意,当我查看v$session都开始慢的时候,感觉哪里出了什么问题了,最直观的感受就是一些命令的运行都很缓慢了. 首先查看了一下数据库的负载,发现在最近的一个多小时内负载高了很多.几乎是几十倍的速度. BEGIN_TIME------------------------- END_TIME-----------

一条sql 语句搞定数据库分页

antshome(原作)首发:CSDN 一条语句搞定数据库分页 select top 10 b.* from (select top 20 主键字段,排序字段 from 表名 order by 排序字段 desc) a,表名 b where b.主键字段 = a.主键字段 order by a.排序字段 10 = 每页记录数 20 = (当前页 + 1) * 每页记录数 以上语句即可以实现分页,但是最后取出的结果排序是升序,如果需要结果集为降序(例如时间),则有两种方法可以处理 1.使用以下语句

一条 sql 语句搞定数据库分页

分页|数据|数据库|语句 一条语句搞定数据库分页 select top 10 b.* from (select top 20 主键字段,排序字段 from 表名 order by 排序字段 desc) a,表名 b where b.主键字段 = a.主键字段 order by a.排序字段 10 = 每页记录数 20 = (当前页 + 1) * 每页记录数 以上语句即可以实现分页,但是最后取出的结果排序是升序,如果需要结果集为降序(例如时间),则有两种方法可以处理 1.使用以下语句,但效率可能要

MySQL的一条慢SQL查询导致整个网站宕机的解决方法_Mysql

直接切入正题吧: 通常来说,我们看到的慢查询一般还不致于导致挂站,顶多就是应用响应变慢 不过这个恰好今天被我撞见了,一个慢查询把整个网站搞挂了先看看这个SQL张撒样子: # Query_time: 70.472013 Lock_time: 0.000078 Rows_sent: 7915203 Rows_examined: 15984089 Rows_affected: 0 # Bytes_sent: 1258414478 use js_sku; SET timestamp=1465850117

一次数据库宕机问题的分析

今天来到办公室,发现有一台服务器中的数据库实例停掉了.这种情况真是意料之外,尤其是我还不是很熟悉这台机器的服务. 赶紧查看数据库日志,可以看到数据库在昨晚停掉了,从日志来看没有人为的痕迹. 在宕机之前,有下面的日志.在此截取一部分.TNS-12560: TNS:protocol adapter error opiodr aborting process unknown ospid (33498) as a result of ORA-609     ns secondary err code:

容灾切换中的数据库宕机问题简单分析(一)

最近对一个统计库做了计划内的容灾切换,即主备切换.操作的过程其实还是蛮顺利的.但是灾难切换中如果出现在问题,那就是灾难中的灾难了. 按照计划对配置信息做了同步,然后使用DG Broker做了SwitchOver操作. 这一次切换速度还是蛮快,我开了几个窗口看到日志都在不断输出,角色已经替换过来了.DG Broker切换的日志如下: DGMGRL> switchover to test29; Performing switchover NOW, please wait... New primary

Mssql,Access的sql经典SQL语句大全_数据库其它

下列语句部分是Mssql语句,不可以在access中使用. SQL分类: DDL-数据定义语言(CREATE,ALTER,DROP,DECLARE) DML-数据操纵语言(SELECT,DELETE,UPDATE,INSERT) DCL-数据控制语言(GRANT,REVOKE,COMMIT,ROLLBACK) 首先,简要介绍基础语句: 1.说明:创建 数据库 CREATE DATABASE database-name 2.说明:删除数据库 drop database dbname 3.说明:备份