崩溃恢复 [英] crash recovery

问题描述

我在Windows 64位2003服务器上有db2 udb v8.1，在db2服务器之后

启动，我在db2diag.log中发现这个，这个错误是什么？


2004-05-05-15.28.30.780000实例：DB2节点：000

PID：1692（db2syscs.exe）TID：2860 Appid：AC10040A.GD5F.00FC56D8BEC5

基本系统实用程序sqledint探测器：30


需要进行崩溃恢复。


2004-05-05-15.28.31.890000实例：DB2节点：000

PID：1692（db2syscs.exe）TID：2860 Appid：AC10040A.GD5F.00FC56D8BEC5

恢复管理器sqlpresr探测器：410数据库：NJIPD


崩溃恢复开始了。 LowtranLSN 00000006107760AD MinbuffLSN

000000060EAC1CA4

2004-05-05-15.28.31.980001实例：DB2节点：000

PID：1692 （db2syscs.exe）TID：2860 Appid：AC10040A.GD5F.00FC56D8BEC5

恢复管理器sqlprecm探测：125数据库：NJIPD


与3个代理使用并行恢复5个QSets 35个队列和4个块

2004-05-05-15.29.12.640000实例：DB2节点：000

PID：1692（db2syscs.exe）TID：2860 Appid ：AC10040A.GD5F.00FC56D8BEC5

恢复管理器sqlprecm探测：400数据库：NJIPD

DIA2051W崩溃恢复的前进阶段已经完成。下一个LSN是

" 000000061077B300" ;.


2004-05-05-15.29.29.860000实例：DB2节点：000

PID：1692（db2syscs.exe）TID：2860 Appid：AC10040A.GD5F.00FC56D8BEC5

恢复管理器sqlpresr探测：1450数据库：NJIPD


剩下的配置更改要应用。


2004-05-05-15.29.30.240001实例：DB2节点：000

PID：1692（db2syscs.exe）TID： 2860 Appid：AC10040A.GD5F.00FC56D8BEC5

恢复管理器sqlpresr探测：3170数据库：NJIPD


崩溃恢复完成。下一个LSN是000000061111C00C


2004-05-05-15.38.43.420000实例：DB2节点：000

PID：4004（db2dasstm.exe）TID：4092 Appid：none

客户端配置cfgReadDbcDirectory探测器：5

DB_CONFIG：


0x000006FBFCFC5230：456E 7469 7265 2044 4243 4647 00整个

DBCFG。


PID：4004 TID：4092节点：000标题：Sqlcode

SQL -1024

2004-05-05-16.03.14.010000实例：DB2节点：000

PID：3356（db2dasstm.exe）TID：3440 Appid：none

客户端配置cfgReadDbcDirectory探测：5

DB_CONFIG：


0x000006FBFCFC5230：456E 7469 7265 2044 4243 4647 00整个

DBCFG。


PID：3356 TID：3440节点：000标题：Sqlcode

SQL -1024


为什么会有崩溃恢复？什么是LSN？

解决方案

" xixi" <哒**** @ yahoo.com>在消息中写道

news：c0 ************************** @ posting.google.c om ...

我在Windows 64位2003服务器上有db2 udb v8.1，在db2服务器启动之后，我在db2diag.log中发现了这个错误？

当使用SQL异常终止的应用程序和DB2滚动返回对前一个提交点的任何更新时发生崩溃恢复。这可以在用户

应用程序或DB2应用程序中发生。崩溃恢复成功完成。


如果DB2本身崩溃（或操作系统），那么当DB2启动时崩溃将发生
恢复下次。在某些情况下，

某些线程可能是不确定的。这意味着DB2不确定是否要回滚以前的工作，并且DBA输入可能需要解决此问题。


崩溃恢复与前滚不同复苏。前滚

恢复在先前的备份恢复时发生，并且从备份的

点更新直到当前时间点（通常）重新应用
通过日志
。前滚恢复需要归档日志记录，或者激活用户

退出程序以进行记录。

" xixi" <哒**** @ yahoo.com>在消息中写道

news：c0 ************************** @ posting.google.c om ...

我在Windows 64位2003服务器上有db2 udb v8.1，在db2服务器启动之后，我在db2diag.log中发现了这个错误？

当使用SQL异常终止的应用程序和DB2滚动返回对前一个提交点的任何更新时发生崩溃恢复。这可以在用户

应用程序或DB2应用程序中发生。崩溃恢复成功完成。


如果DB2本身崩溃（或操作系统），那么当DB2启动时崩溃将发生
恢复下次。在某些情况下，

某些线程可能是不确定的。这意味着DB2不确定是否要回滚以前的工作，并且DBA输入可能需要解决此问题。


崩溃恢复与前滚不同复苏。前滚

恢复在先前的备份恢复时发生，并且从备份的

点更新直到当前时间点（通常）重新应用
通过日志
。前滚恢复需要归档日志记录，或者用户

退出程序进行记录，激活。

Mark A写道：
< blockquote class =post_quotes>" xixi" <哒**** @ yahoo.com>在消息中写道
新闻：c0 ************************** @ posting.google.c om ...

我在Windows 64位2003服务器上有db2 udb v8.1，在db2服务器启动之后，我在db2diag.log中发现了这个错误？

在DB2本身崩溃（或操作系统）的情况下，当DB2下次启动时会发生崩溃恢复。在某些情况下，某些线程可能是不确定的。这意味着DB2不确定是否回滚以前的工作，并且DBA输入可能需要解决此问题。

崩溃恢复与前滚恢复不同。前滚
恢复以前的备份恢复，并从备份的
点更新，直到当前时间点（通常）通过日志重新应用
。前滚恢复需要归档日志记录，或者激活用户
退出程序进行记录。

我不认为这个描述是非常正确的。


每当数据库被激活并且状态不一致时，就会发生崩溃恢复。 不一致的状态内存（即缓冲池）中有数据尚未写入磁盘，

和/或数据库发生故障时有飞行中的事务。

如果应用程序崩溃/异常终止，则不会发生崩溃恢复和

DB2因此回滚任何打开的事务。


通过将活动日志文件（无论是否使用存档日志记录，无论是否使用存档日志记录）应用于数据库，崩溃恢复都可以正常工作。在日志链的

末尾，任何正在进行的交易都会回滚，并且

恢复完成。


当你正常关闭（停用）数据库时，DB2将刷新它的缓冲池，并且数据库将保持一致状态。

祝你好运，


----- =通过Newsfeeds.Com发布，未经审查的Usenet新闻= -----
http://www.newsfeeds.com - 世界排名第一的新闻组服务！

----- ==超过100,000个新闻组 - 19个不同的服务器！ = -----

i have db2 udb v8.1 on windows 64 bit 2003 server, after db2 server
start , i found this in the db2diag.log, is this error?

2004-05-05-15.28.30.780000 Instance:DB2 Node:000
PID:1692(db2syscs.exe) TID:2860 Appid:AC10040A.GD5F.00FC56D8BEC5
base sys utilities sqledint Probe:30

Crash Recovery is needed.

2004-05-05-15.28.31.890000 Instance:DB2 Node:000
PID:1692(db2syscs.exe) TID:2860 Appid:AC10040A.GD5F.00FC56D8BEC5
recovery manager sqlpresr Probe:410 Database:NJIPD

Crash recovery started. LowtranLSN 00000006107760AD MinbuffLSN
000000060EAC1CA4

2004-05-05-15.28.31.980001 Instance:DB2 Node:000
PID:1692(db2syscs.exe) TID:2860 Appid:AC10040A.GD5F.00FC56D8BEC5
recovery manager sqlprecm Probe:125 Database:NJIPD

Using parallel recovery with 3 agents 5 QSets 35 queues and 4 chunks
2004-05-05-15.29.12.640000 Instance:DB2 Node:000
PID:1692(db2syscs.exe) TID:2860 Appid:AC10040A.GD5F.00FC56D8BEC5
recovery manager sqlprecm Probe:400 Database:NJIPD

DIA2051W Forward phase of crash recovery has completed. Next LSN is
"000000061077B300".

2004-05-05-15.29.29.860000 Instance:DB2 Node:000
PID:1692(db2syscs.exe) TID:2860 Appid:AC10040A.GD5F.00FC56D8BEC5
recovery manager sqlpresr Probe:1450 Database:NJIPD

There remains configuration changes to apply.

2004-05-05-15.29.30.240001 Instance:DB2 Node:000
PID:1692(db2syscs.exe) TID:2860 Appid:AC10040A.GD5F.00FC56D8BEC5
recovery manager sqlpresr Probe:3170 Database:NJIPD

Crash recovery completed. Next LSN is 000000061111C00C

2004-05-05-15.38.43.420000 Instance:DB2 Node:000
PID:4004(db2dasstm.exe) TID:4092 Appid:none
Client Config cfgReadDbcDirectory Probe:5

DB_CONFIG:

0x000006FBFCFC5230 : 456E 7469 7265 2044 4243 4647 00 Entire
DBCFG.

PID:4004 TID:4092 Node:000 Title: Sqlcode
SQL -1024
2004-05-05-16.03.14.010000 Instance:DB2 Node:000
PID:3356(db2dasstm.exe) TID:3440 Appid:none
Client Config cfgReadDbcDirectory Probe:5

DB_CONFIG:

0x000006FBFCFC5230 : 456E 7469 7265 2044 4243 4647 00 Entire
DBCFG.

PID:3356 TID:3440 Node:000 Title: Sqlcode
SQL -1024

why there is a crash recovery? what is LSN?

解决方案

"xixi" <da****@yahoo.com> wrote in message
news:c0**************************@posting.google.c om...

i have db2 udb v8.1 on windows 64 bit 2003 server, after db2 server
start , i found this in the db2diag.log, is this error?

Crash recovery occurs when an application using SQL abends and DB2 rolls
back any updates to the previous commit point. This can occur in a user
application or a DB2 application. The crash recovery completed successfully.

In the case when DB2 itself crashes (or the operating system), then crash
recovery takes place when DB2 starts up the next time. In certain cases,
some threads may be "in-doubt" which means DB2 is not sure whether to roll
back previous work, and DBA input may required to resolve this.

Crash recovery is different than roll-forward recovery. Roll forward
recovery occurs when a previous backup is restored, and updates from the
point of the backup until the current point in time (usually) are reapplied
via the logs. Roll forward recovery requires archive logging, or the user
exit program for logging, be activated.

"xixi" <da****@yahoo.com> wrote in message
news:c0**************************@posting.google.c om...

i have db2 udb v8.1 on windows 64 bit 2003 server, after db2 server
start , i found this in the db2diag.log, is this error?

Crash recovery occurs when an application using SQL abends and DB2 rolls
back any updates to the previous commit point. This can occur in a user
application or a DB2 application. The crash recovery completed successfully.

In the case when DB2 itself crashes (or the operating system), then crash
recovery takes place when DB2 starts up the next time. In certain cases,
some threads may be "in-doubt" which means DB2 is not sure whether to roll
back previous work, and DBA input may required to resolve this.

Crash recovery is different than roll-forward recovery. Roll forward
recovery occurs when a previous backup is restored, and updates from the
point of the backup until the current point in time (usually) are reapplied
via the logs. Roll forward recovery requires archive logging, or the user
exit program for logging, be activated.

Mark A wrote:

"xixi" <da****@yahoo.com> wrote in message
news:c0**************************@posting.google.c om...

i have db2 udb v8.1 on windows 64 bit 2003 server, after db2 server
start , i found this in the db2diag.log, is this error?

Crash recovery occurs when an application using SQL abends and DB2 rolls
back any updates to the previous commit point. This can occur in a user
application or a DB2 application. The crash recovery completed successfully.

In the case when DB2 itself crashes (or the operating system), then crash
recovery takes place when DB2 starts up the next time. In certain cases,
some threads may be "in-doubt" which means DB2 is not sure whether to roll
back previous work, and DBA input may required to resolve this.

Crash recovery is different than roll-forward recovery. Roll forward
recovery occurs when a previous backup is restored, and updates from the
point of the backup until the current point in time (usually) are reapplied
via the logs. Roll forward recovery requires archive logging, or the user
exit program for logging, be activated.

I don''t think this description is quite correct.

Crash recovery occurs whenever a database is activated and it is in
an inconsistent state. "Inconsistent state" means that there was data
in memory (i.e. bufferpools) that had not yet been written to disk,
and/or there were transactions in flight when the database went down.
Crash recovery does not occur if an application crashes/abends and
DB2 consequently rolls back any open transaction(s).

Crash recovery works by applying the active log files (regardless of
whether you are using archive logging or not) to the database. At the
end of the log chain, any in-flight transactions are rolled back, and
the recovery is complete.

When you shut down (deactivate) the database normally, DB2 will flush
its bufferpools, and the database will be in a consistent state.
Good luck,


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

这篇关于崩溃恢复的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！