>I understand DB2 keeps its log data first in buffers, then writes it to one of
>a set of active log data set. Finally the data will be written to archive
>>datasets when active log data sets fill up. The active data sets are used
>round robin.
>I found a sentence in a DB2 manual stating that the data is being copied from
>the active to the archive data set.
>I'm guessing that "copy" means the physical part not the logical view of where
>the data is. That would be "move". It is not clear whether the data
>in the active data set would still be used by DB2 after it has been copied to
>the archive data set.
Yes. It is more like "move" or "dump" or "offload" when going from active to
archive logs, the same as SMF's MANx to SMFDUMP with CLEAR. R.S.'s analogy is
excellent (& could be expanded to discuss writing buffers to MANx similar to
the active log, though not simply).
>I doubt DB2 will physically delete the data from the active data set after
>writing it to an archive data set. The question is, does DB2 remember that
>>the data is still also available in the active data set, as long as it has
>not started reusing it? I think not. A block of log data will only ever be in
>one >place, buffer, active *or* archive data set.
DB2 will use the "optimal" source when it has to read log data: 1) in-memory
(buffers) not yet written to the active log, 2) active log, 3) archive log.
>Some insight, anyone? Pointers to the right FM would be nice, too. May need to
>be able to point someone to a FM so he can read hinself.
Dual logging (i.e. 2 copies) for at least the BSDS & active logs is highly
recommended for both recovery and performance (maybe read from copy 2 while
write to copy 1 (?), just guessing, doc not very specific.)
Look at I/O in the ...MSTR address space for logging (...DBM1 is database I/O);
the offload messages in ...MSTR will easily give you an idea how busy things
are & identify peak logging, plus warn you if the active logs are too small
(very frequent offloads); especially look for dynamic re-allocation of
previously offloaded logs, indicating too small/few active logs (easily fixed)
or potentially catastophic application problem (good luck.)
Ensure your archive log (if on DASD) is at least as big as your online log (I
missed that a couple of times over the years.)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
