When does a DB2 database become inconsistent?

[Rahul Babbar]

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

[kschlamb]

On Nov 30, 5:51 am, Rahul Babbar <[e-mail]:

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

[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 <[e-mail]:

>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

[Knut Stolze]

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