473,387 Members | 1,700 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,387 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 9485
"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: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...

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.