崩溃恢复(crash recovery)与 AUTORESTART参数

关于这个参数设置的影响,在生产系统中经历过两次:

第一次是有套不太重要的系统安装在虚拟机,这套系统所有应用(DB2 WAS IHS)都配置到/etc/rc.local中,每次启动机器会自动拉起应用,然后有次虚拟机宕机,重启后检查了各个应用进程都正常启动,但是前台页面访问异常无法访问,然后到后台手动连接数据库报:

SQL1015N  The database is in an inconsistent state.  SQLSTATE=55025

根据SQL1015N提示:需要执行RESTART DATABASE DBNAME命令,执行后然后数据库可以正常连接

第二次是一套HA服务器的主机电源故障发生系统切换,切换到备机后,检查应用都正常被拉起,但是前台无法访问,和第一次是相同的问题,AUTORESTART参数被设置了OFF

这个参数解释如下:

如果DB2数据库遭受断电或者异常关闭,数据库没有干净的关闭,那么数据库在启动的时候将会进行crash recovery. 但是如果数据库参数AUTORESTART设置为OFF的话,在启动数据库后DB2不会进行CRASH RECOVERY。关于crash recovery,在db2diag.log日志会有相关体现

下面重现这一场景:

/* 1   设置AUTORESTART为OFF   */
[[email protected] ~]$ db2 UPDATE DATABASE CONFIGURATION for limtdb USING AUTORESTART OFF IMMEDIATE
DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.
[[email protected] ~]$ db2 get db cfg for limtdb|grep -i AUTORESTART
 Auto restart enabled                      (AUTORESTART) = OFF

[[email protected] yunwei]$ db2 connect to limtdb

   Database Connection Information

 Database server        = DB2/LINUXX8664 10.1.0
 SQL authorization ID   = DB2INST1
 Local database alias   = LIMTDB

/* 2   插入一条数据但不提交,为了数据库处于不一致性   */
[[email protected] yunwei]$ db2  +c "insert into A values(15485,'asdas','asdas')"
DB20000I  The SQL command completed successfully.
[[email protected] yunwei]$
/* 3  kill数据库,模拟异常宕机情况   */
[[email protected] yunwei]$ ps -ef|grep db2sys
db2inst1  5287  5285  1 08:07 pts/1    00:00:04 db2sysc 0
db2inst1  5827  3612  0 08:12 pts/1    00:00:00 grep db2sys
[[email protected] yunwei]$ kill -9 5287
/* 4  启动数据库,此时数据库没有进行崩溃恢复,因为AUTORESTART为OFF  */
[[email protected] yunwei]$
[[email protected] yunwei]$ db2start
12/19/2014 08:13:04     0   0   SQL1063N  DB2START processing was successful.
SQL1063N  DB2START processing was successful.
[[email protected] yunwei]$
[[email protected] yunwei]$
/* 5  此处报错是因为刚才的db2bp进程没有terminate  */
[[email protected] yunwei]$ db2 connect to limtdb
SQL0752N  Connecting to a database is not permitted within a logical unit of
work when the CONNECT type 1 setting is in use.  SQLSTATE=0A001
[[email protected] yunwei]$ db2 terminate
DB20000I  The TERMINATE command completed successfully.
/* 6  再次启动时候报数据库不一致 */
[[email protected] yunwei]$ db2 connect to limtdb
SQL1015N  The database is in an inconsistent state.  SQLSTATE=55025
/* 7  db2 ? SQL1015N 有一条建议: using the RESTART DATABASE command*/
[[email protected] yunwei]$ db2 restart database limtdb
DB20000I  The RESTART DATABASE command completed successfully.
 /* 8  数据库可以正常连接*/
[[email protected] yunwei]$ db2 connect to limtdb

   Database Connection Information

 Database server        = DB2/LINUXX8664 10.1.0
 SQL authorization ID   = DB2INST1
 Local database alias   = LIMTDB

/* 9   以下是设置AUTORESTART为ON情况下,数据库宕机重启(不需要执行RESTART DATABASE) */
[[email protected] yunwei]$
[[email protected] yunwei]$ db2 UPDATE DATABASE CONFIGURATION for limtdb USING AUTORESTART ON IMMEDIATE
DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.
[[email protected] yunwei]$
[[email protected] yunwei]$ db2 get db cfg for limtdb|grep -i AUTORESTART
 Auto restart enabled                      (AUTORESTART) = ON
[[email protected] yunwei]$
[[email protected] yunwei]$
[[email protected] yunwei]$ db2  +c "insert into A values(15485,'asdas','asdas')"
DB20000I  The SQL command completed successfully.
[[email protected] yunwei]$ ps -ef|grep db2sys
db2inst1  5870  5868  1 08:13 pts/1    00:00:03 db2sysc 0
db2inst1  6122  3612  0 08:16 pts/1    00:00:00 grep db2sys
[[email protected] yunwei]$ kill -9 5870
[[email protected] yunwei]$ db2start
12/19/2014 08:16:35     0   0   SQL1063N  DB2START processing was successful.
SQL1063N  DB2START processing was successful.
[[email protected] yunwei]$ db2 connect to limtdb
SQL0752N  Connecting to a database is not permitted within a logical unit of
work when the CONNECT type 1 setting is in use.
[[email protected] yunwei]$ db2 terminate
DB20000I  The TERMINATE command completed successfully.
[[email protected] yunwei]$ db2 connect to limtdb

   Database Connection Information

 Database server        = DB2/LINUXX8664 10.1.0
 SQL authorization ID   = DB2INST1
 Local database alias   = LIMTDB
时间: 2024-10-05 22:04:34

崩溃恢复(crash recovery)与 AUTORESTART参数的相关文章

insert buffer/change buffer double write buffer,双写 adaptive hash index(AHI) innodb的crash recovery innodb重要参数 innodb监控

https://yq.aliyun.com/articles/41000 http://blog.itpub.net/22664653/viewspace-1163838/ http://www.cnblogs.com/MYSQLZOUQI/p/5602206.html https://yq.aliyun.com/articles/222 主从不一致性的3种可能原因1.binlog format是不是row2.session级关闭binlog3.人工在slave修改数据 set sql_log_

Oracle实例的恢复、介质恢复( crash recovery)( Media recovery)

实例的恢复( crash recovery) 什么时候发生Oracle实例恢复? shutdown abort; 数据库异常down掉(机器死机,掉电...) 实例恢复的原因是数据有丢掉,使用redo数据恢复 实例恢复是一个自动的过程,不需要人工干预. 控制文件就是为了检查一致性,如果不一致就会实例恢复 实例恢复发生在那个阶段? sql>startup nomount(读取spfle) ,启动实例,oracle给自己分了一些内存,oracle的内存起来,这个时候没有实例恢复. SQL> sta

MySQL · 引擎特性 · InnoDB 崩溃恢复过程

MySQL · 引擎特性 · InnoDB 崩溃恢复过程 在前面两期月报中,我们详细介绍了 InnoDB redo log 和 undo log 的相关知识,本文将介绍 InnoDB 在崩溃恢复时的主要流程. 本文代码分析基于 MySQL 5.7.7-RC 版本,函数入口为 innobase_start_or_create_for_mysql,这是一个非常冗长的函数,本文只涉及和崩溃恢复相关的代码. 在阅读本文前,强烈建议翻阅我们之前的两期月报:1. MySQL · 引擎特性 · InnoDB

mysql数据库无法启动恢复 mysql数据库崩溃恢复 mysql数据库恢复

客户名称 保密 数据类型 mysql 5.5 innodb 数据容量 1500 MB 故障类型 服务器断电导致mysql无法启动.客户自己尝试innodb崩溃恢复从参数1-6无效. InnoDB: for more information. InnoDB: Error: trying to access page number 805281720 in space 0, InnoDB: space name .\ibdata1, InnoDB: which is outside the tabl

MySQL崩溃恢复过程常见错误分析

最近在和一个同事争论MySQL崩溃恢复中的一些常见错误时出现了一些分歧,他认为一些参数的设置会导致MySQL出现崩溃后恢复不起来的问题,但对此,我却不认同,虽然一些参数的设定会导致数据丢失,但应该不会引起数据库崩溃之后无法恢复的情况,因此,就想整理出MySQL崩溃恢复的过程来加深学习! 图一 mysql WAL过程 在正常情况下,数据写入会先写入redo_buffer_pool,然后在写入redo_log_file,这中间如果由于参数设置不当,可能会发生丢失,但不影响主机的崩溃恢复,但有以下两种

数据库的Instance/Crash Recovery

crash recovery是指单实例数据库发生了failure.或者rac数据库中的所有实例都发生了failure后进行的recovery.rac数据库crash后,rac中第一个重启启动的instance负责进行crash recovery.instance recovery是指rac环境中,剩下存活的instance的smon进程对已经发生failure的instance进行的recovery.实例恢复时可以查看视图gv$instance_recovery进行监控 Instance/Cra

UNDO及MVCC、崩溃恢复

UNDO特性:避免脏读.事务回滚.非阻塞读.MVCC.崩溃恢复 事务工作流程(图2) MVCC原理机制 崩溃恢复:redo前滚.undo回滚 长事务.大事务:危害.判断.处理 UNDO优化:实现undo分离.收缩undo表空间 0.undo物理存储研究 1>ibdata第五个数据块(系统事务表)中存储着128个undo段的段头块的地址 2>每一个undo段头块有1024行,两行记录一个事务,一共可以记录512个事务 3>一个数据行中存放XID.rollpointr 4>一个数据行被

SQL Server通过BOOT PAGE来进行Crash Recovery

SQL Server通过BOOT PAGE来进行Crash Recovery 看了盖总的一篇文章 http://www.eygle.com/archives/2008/11/oracle_internals_preface.html 数据文件的第一个Block记录了重要的检查点.SCN等信息,这些信息在启动时要被读取,这里就是这样一种体现. 我们看一下SQL Server的情况,使用DBCC fileheader命令,10为我的一个用户库SSS的数据库ID 环境:SQL Server2012 6

Background indexer crash recovery

报这种错误: Background Indexer Crash Recovery java.lang.StackOverflowError 解决办法:看看原来项目的jar 包有没有错的.右击项目->build path->configure Buid Path 查看libraries 如果有错误的,把jar 包删掉,如果有需要的话,添加正确的jar包即可.由于每个项目的jar 包是不同的.比如我的项目,就必须添加tomcat 下面的lib 包.只是思路是这样的. 即,我的问题解决了. Back