You could have created several posts ya know.
First off, a database can be expected to be inconsistent whenever there are in doubt transactions against the database. In other words, transactions that might in the future be committed or rolled back. As long as the database is "consistent" when there are no connections to the database then everything is cool. Otherwise you got a problem.
Second point - my viewpoint which may not be shared by everyone - you start diagnosis of performance problems by reducing the problem to some area. For instance: is it a database problem or not a database problem? If not a database problem, is it an application problem or a system problem. If it's a system problem is it hardware or operating system. Lots of tools availabe including snapshot monitors for db, dbm, locks, apps etc. Also db2diag.log, event monitors, OS event viewers and other monitoring tools. You should be able to quickly determine if the problem is in the database and use a logical progression to focus in on the issue.
Third: I'm not sure what you are implying with the question about keeping the database in roll forward enabled status. Essentially you turn log retain on to enable the database for rollforward recovery. Once turned on you're required to do a backup (7.2 at least). Once set it should never change without someone "resettting" the configuration. If the configuration is changing you need to contact IBM.
Fourth: what important parameters? Your best bet here is to review snapshot statistics, db2diag.log and look at your bufferpool hit ratios. My viewpoint and again others might disagree, is to reduce disk activity and within reason, make everything happen in memory. That means bufferpool and heap tuning as well as intelligent indexing against sql predicates.
dBforums
>
inconsistant status
12-29-06, 04:20
Linear Mode
