By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,851 Members | 1,746 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,851 IT Pros & Developers. It's quick & easy.

When does a DB2 database become inconsistent?

P: n/a
Hi All,

When could be the possible reasons that could make a database
inconsistent?

I was told by somebody that it could become inconsistent if you "
force all the applications to a close on that database and
transactions are not committed or rollbacked"

I infact, don't believe it, because i suppose when we do a "force
applications all", then the applications should be automatically
rollbacked. I mean this should be the case.

Can anybody explain it with the others reasons leading to a database
being inconsistent?

Thanks a lot

Rahul
Nov 30 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
On Nov 30, 5:51 am, Rahul Babbar <rahul.babb...@gmail.comwrote:
Hi All,

When could be the possible reasons that could make a database
inconsistent?

I was told by somebody that it could become inconsistent if you "
force all the applications to a close on that database and
transactions are not committed or rollbacked"

I infact, don't believe it, because i suppose when we do a "force
applications all", then the applications should be automatically
rollbacked. I mean this should be the case.

Can anybody explain it with the others reasons leading to a database
being inconsistent?

Thanks a lot

Rahul
Hi Rahul,

Can you explain what exactly you mean by inconsistent as I'm not sure
if my response here is what you are looking for.

When a database is started, it is considered "consistent" (and you'll
see this in the database configuration output). What this really
means is that what is on disk for the database is consistent. Now,
the first piece of write/update type of work that happens flips the
database to inconsistent. The reason being that changes are usually
buffered in the bufferpool and what is on disk is not guaranteed to be
consistent. If an inconsistent database comes down abnormally (DB2
crashes, is killed, machine is shut down, etc) then it needs to go
through crash recovery (usually happens automatically as the part of
the first connect/activate that occurs afterwards). When a database
is shutdown normally (deactivated, last connection goes away, etc) all
of the in-memory changes are flushed to disk and the database is now
considered consistent again (and won't require any kind of crash
recovery the next time it's started).

In the case of "force applications all", it is my understanding that
the agents are being forced, but cleanup and the flushing of changes
should still occur when the last one is forced off, leaving the
database consistent afterwards.

Regards,
Kelly Schlamb
Nov 30 '07 #2

P: n/a
aj
"Inconsistent" was probably a poor choice of words on IBM's part,
although I can't think of a better one right now. When I first
began using DB2, I remember this concerning me also.
It makes it sound like there is something wrong w/ the database,
when in fact it just means that the database is being used.

I've always though of it as "there are in-flight transactions",
although strictly speaking Kelly is correct about there being
stuff in the bufferpool that is not yet on disk...

aj
ks******@ca.ibm.com wrote:
On Nov 30, 5:51 am, Rahul Babbar <rahul.babb...@gmail.comwrote:
>Hi All,

When could be the possible reasons that could make a database
inconsistent?

I was told by somebody that it could become inconsistent if you "
force all the applications to a close on that database and
transactions are not committed or rollbacked"

I infact, don't believe it, because i suppose when we do a "force
applications all", then the applications should be automatically
rollbacked. I mean this should be the case.

Can anybody explain it with the others reasons leading to a database
being inconsistent?

Thanks a lot

Rahul

Hi Rahul,

Can you explain what exactly you mean by inconsistent as I'm not sure
if my response here is what you are looking for.

When a database is started, it is considered "consistent" (and you'll
see this in the database configuration output). What this really
means is that what is on disk for the database is consistent. Now,
the first piece of write/update type of work that happens flips the
database to inconsistent. The reason being that changes are usually
buffered in the bufferpool and what is on disk is not guaranteed to be
consistent. If an inconsistent database comes down abnormally (DB2
crashes, is killed, machine is shut down, etc) then it needs to go
through crash recovery (usually happens automatically as the part of
the first connect/activate that occurs afterwards). When a database
is shutdown normally (deactivated, last connection goes away, etc) all
of the in-memory changes are flushed to disk and the database is now
considered consistent again (and won't require any kind of crash
recovery the next time it's started).

In the case of "force applications all", it is my understanding that
the agents are being forced, but cleanup and the flushing of changes
should still occur when the last one is forced off, leaving the
database consistent afterwards.

Regards,
Kelly Schlamb
Nov 30 '07 #3

P: n/a
Rahul Babbar wrote:
I infact, don't believe it, because i suppose when we do a "force
applications all", then the applications should be automatically
rollbacked. I mean this should be the case.
This is correct.

--
Knut Stolze
DB2 z/OS Utilities Development
IBM Germany
Dec 3 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.