p175 wrote:
Try this as a test:
I've had a look at the DB CFG 'database_consistent' flag before, and
noticed that it 'usually' only returns to a YES state when the database
has been either restarted following all applications having
disconnected, or the database being 'deactivated' or NOT activated.
If that is indeed the case, a consistency state of YES would indicate a
non-active database or one that has had no activity. I just did a few
very simple tests, by logging on and updating a single field, the state
changes from the initial idle state of YES to NO, after commiting the
transaction and logging off, it remained NO. The only way I could get
it back to YES was to deactivate the database.
So, I deactivated and logged on again, made the same change, checked
the state, set to NO, committed and logged off and it's back to YES
again. Stands to reason therefore that if you find it in a YES state
after user activity then the database has not been activated ? You
could use an activity monitor such as evmon_activates to follow
activity and check the consistency flag from the DB CFG afterwards.
Might be flawed logic but .. hey it works .. heh
I don't think this is going to work reliably. At least I would not rely on
it at all. The description of the "database_consistent" information can be
found here:
http://publib.boulder.ibm.com/infoce...c/r0000282.htm
It is pretty clear in that this information only shows if at least one
transaction has not yet committed its changes. What is not so clear in the
description, however, is what the term "database" means. Here it can only
refer to the data on disk. So if all transactions are ended _and_ if their
data is written to disk already, then you should see the 'YES'. Otherwise,
you have running transactions or finished transactions with changes still
pending to be flushed. (Such a reading would be consistent with the
sentence "If the system "crashes" while the database is consistent, you do
not need to take any special action to make the database usable." In
particular, no crash recovery would be needed.)
Your observations regarding activating/deactivating and the value of
the 'consistent' db cfg parameter nicely line up with the above
description. Once you disconnect from a database that was not explicitly
activated, the database will be deactivated implicitly. This deactivation
will cause the remaining data changes to be flushed to disk. With an
explicitly activated database, the database remains active. So there is no
need that DB2 writes the changes to disk when you log of. Thus, the
consistency state has to be 'NO'.
--
Knut Stolze
DB2 Information Integration Development
IBM Germany