473,322 Members | 1,232 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

crash recovery

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?
Nov 12 '05 #1
10 9477
"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.
Nov 12 '05 #2
"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.
Nov 12 '05 #3
Ian
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! =-----
Nov 12 '05 #4
Ian
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! =-----
Nov 12 '05 #5
>> 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.

"Ian" <ia*****@mobileaudio.com> wrote in message > >
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,


To be honest, I don't know for sure exactly what the db2dia.log means when
it said crash recovery took place. It may have only refer to a situation
when DB2 is activated in an inconsistent state, and not when an application
crashes and rolls back to the last commit point.

However, the common vernacular of the term "crash recovery" does include a
situation when an application crashes and rolls back to the last commit
point, whether DB2 detects the "inconsistent state" while DB2 is still
running, or whether DB2 detects it the next time DB2 is activated.

Also, you description of "inconsistent state" is not very clear. It should
include reapplying any data that been committed but not written to disk, and
backing out any updates data that has been written to disk, but not
committed. The key word is "committed".

Your assertion that "Inconsistent state means that there was data in memory
(i.e. bufferpools) that had not yet been written to disk" only holds true if
such data was committed.
Nov 12 '05 #6
>> 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.

"Ian" <ia*****@mobileaudio.com> wrote in message > >
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,


To be honest, I don't know for sure exactly what the db2dia.log means when
it said crash recovery took place. It may have only refer to a situation
when DB2 is activated in an inconsistent state, and not when an application
crashes and rolls back to the last commit point.

However, the common vernacular of the term "crash recovery" does include a
situation when an application crashes and rolls back to the last commit
point, whether DB2 detects the "inconsistent state" while DB2 is still
running, or whether DB2 detects it the next time DB2 is activated.

Also, you description of "inconsistent state" is not very clear. It should
include reapplying any data that been committed but not written to disk, and
backing out any updates data that has been written to disk, but not
committed. The key word is "committed".

Your assertion that "Inconsistent state means that there was data in memory
(i.e. bufferpools) that had not yet been written to disk" only holds true if
such data was committed.
Nov 12 '05 #7
In article <f5**************@news.uswest.net>, Mark A
(ma@switchboard.net) says...

To be honest, I don't know for sure exactly what the db2dia.log means when
it said crash recovery took place. It may have only refer to a situation
when DB2 is activated in an inconsistent state, and not when an application
crashes and rolls back to the last commit point.


It clearly described in the manuals. Check the control center
Concepts -> Administration -> Data recovery -> Crash recovery.

Nov 12 '05 #8
In article <f5**************@news.uswest.net>, Mark A
(ma@switchboard.net) says...

To be honest, I don't know for sure exactly what the db2dia.log means when
it said crash recovery took place. It may have only refer to a situation
when DB2 is activated in an inconsistent state, and not when an application
crashes and rolls back to the last commit point.


It clearly described in the manuals. Check the control center
Concepts -> Administration -> Data recovery -> Crash recovery.

Nov 12 '05 #9
> > To be honest, I don't know for sure exactly what the db2dia.log means
when
it said crash recovery took place. It may have only refer to a situation
when DB2 is activated in an inconsistent state, and not when an application crashes and rolls back to the last commit point.

"Gert van der Kooij" <ge**@invalid.nl> wrote in message
It clearly described in the manuals. Check the control center
Concepts -> Administration -> Data recovery -> Crash recovery.

I looked in the DB2 Information Center (not Control Center) as you suggested
and it clearly includes that transaction failure and recovery (rolling back
updates that were not committed) are part of crash recovery (in addition to
re-starting a database in an inconsistent state).

But that does not necessarily mean that the db2dia.log logs transaction
failures and their rollbacks. It may only log crash recovery that happens
when the database is activated (as a result of a database or database
manager crash/forced shutdown). I simply don't know for certain.

But it is clear from the documentation that you referred to, that the
concept of crash recovery includes both database failures (where crash
recovery would take place when the database was re-activated) and
transaction failure (where un-committed transactions would be rolled back
immediately while DB2 was still running).
Nov 12 '05 #10
> > To be honest, I don't know for sure exactly what the db2dia.log means
when
it said crash recovery took place. It may have only refer to a situation
when DB2 is activated in an inconsistent state, and not when an application crashes and rolls back to the last commit point.

"Gert van der Kooij" <ge**@invalid.nl> wrote in message
It clearly described in the manuals. Check the control center
Concepts -> Administration -> Data recovery -> Crash recovery.

I looked in the DB2 Information Center (not Control Center) as you suggested
and it clearly includes that transaction failure and recovery (rolling back
updates that were not committed) are part of crash recovery (in addition to
re-starting a database in an inconsistent state).

But that does not necessarily mean that the db2dia.log logs transaction
failures and their rollbacks. It may only log crash recovery that happens
when the database is activated (as a result of a database or database
manager crash/forced shutdown). I simply don't know for certain.

But it is clear from the documentation that you referred to, that the
concept of crash recovery includes both database failures (where crash
recovery would take place when the database was re-activated) and
transaction failure (where un-committed transactions would be rolled back
immediately while DB2 was still running).
Nov 12 '05 #11

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: xixi | last post by:
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...
0
by: richardshen | last post by:
Any suggestion about this? DB2 V8.1.5 WorkGroup Edition on Windows Professional 2000. Thanks. Message in DB2Diag.log 2004-07-18-16.54.29.479000 Instance:DB2 Node:000...
5
by: NG | last post by:
Hi, We are having DB2-V7.2 DB on AIX 5.2 machine. Recently we upgraded our system to fixpack 13 and activated activate AIX asynchronous IO function. Our DB is going to crash recovery with...
14
by: Jurgen Haan | last post by:
Hey all, at the company where I work we had a strange situation yesterday. Our DB2 database locked up, or as it later seemed, the DBM, or some connection manager. We couldn't open new...
1
by: Michel Esber | last post by:
Hello, Linux V8 FP12 with a 64 bit instance. My DBA called me and said our instance crashed and recovery would never end. $ db2 list utilities show detail ID ...
110
by: alf | last post by:
Hi, is it possible that due to OS crash or mysql itself crash or some e.g. SCSI failure to lose all the data stored in the table (let's say million of 1KB rows). In other words what is the worst...
2
by: Racerx | last post by:
Hi All : I use db2 8.1 fixpack 3 on AIX. I recieved the following message in the diaglog ====================================================== ADM7513W Database manager has started. ...
3
by: subhbhav | last post by:
Hi, Is there any way to get a db2 9.1 Windows UDB database which is in inconsistent state to start without recovery? We were loading data from a source and the database crashed. The Server...
3
by: John Wright | last post by:
I want to create an autosave and crash recovery module for my program. I imagine I would have to use a timer control on the form to call the autosave functionality but I need a starting point. I...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.