crash recovery

[xixi]

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(db2sys cs.exe) TID:2860 Appid:AC10040A. GD5F.00FC56D8BE C5
base sys utilities sqledint Probe:30

Crash Recovery is needed.

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

Crash recovery started. LowtranLSN 00000006107760A D MinbuffLSN
000000060EAC1CA 4

2004-05-05-15.28.31.980001 Instance:DB2 Node:000
PID:1692(db2sys cs.exe) TID:2860 Appid:AC10040A. GD5F.00FC56D8BE C5
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(db2sys cs.exe) TID:2860 Appid:AC10040A. GD5F.00FC56D8BE C5
recovery manager sqlprecm Probe:400 Database:NJIPD

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

2004-05-05-15.29.29.860000 Instance:DB2 Node:000
PID:1692(db2sys cs.exe) TID:2860 Appid:AC10040A. GD5F.00FC56D8BE C5
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(db2sys cs.exe) TID:2860 Appid:AC10040A. GD5F.00FC56D8BE C5
recovery manager sqlpresr Probe:3170 Database:NJIPD

Crash recovery completed. Next LSN is 000000061111C00 C

2004-05-05-15.38.43.420000 Instance:DB2 Node:000
PID:4004(db2das stm.exe) TID:4092 Appid:none
Client Config cfgReadDbcDirec tory Probe:5

DB_CONFIG:

0x000006FBFCFC5 230 : 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(db2das stm.exe) TID:3440 Appid:none
Client Config cfgReadDbcDirec tory Probe:5

DB_CONFIG:

0x000006FBFCFC5 230 : 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?

[Mark A]

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

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]

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

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.

[Ian]

Mark A wrote:

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

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. "Inconsiste nt 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! =-----

[Ian]

Mark A wrote:

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

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. "Inconsiste nt 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! =-----

[Mark A]

>> 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*****@mobile audio.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. "Inconsiste nt 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 "inconsiste nt state" while DB2 is still
running, or whether DB2 detects it the next time DB2 is activated.

Also, you description of "inconsiste nt 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 "Inconsiste nt 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.

[Mark A]

>> 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*****@mobile audio.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. "Inconsiste nt 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 "inconsiste nt state" while DB2 is still
running, or whether DB2 detects it the next time DB2 is activated.

Also, you description of "inconsiste nt 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 "Inconsiste nt 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.

[Gert van der Kooij]

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.

[Gert van der Kooij]

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.

[Mark A]

> > 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.n l> 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).