> Thanks Art, only one doubt as usual ...
> >Changes to the onconfig file ONLY take place when the server is
> >bounced with the sole exception of the TAPE* parameters and, IFF the
> >change is made using onmonitor instead of an editor, the LTAPE*
> Well, I think I changed it via onconfig file, but I said then to my
> customer to shutdown after finishing working that day ... and he did
Then it should have taken effect.
> >Same thing that happens without it except that there will always be
> >one full logical log file empty if a long transaction rollback fills
> >all of the logs trying to rollback. Then ***you can shutdown***, change
> >LBU_PRESERVE to 0 and have a reasonable expectation that there will
> >be enough logspace in that one remaining log to complete the rollback
> >during fast recovery.
> When fails, it tries to rollback but if it cannot ... what happens
> with the transaction. Which is its state ? shall it commit it the
> rest ?
When a long transaction begins to rollback there is no other immediate
effect. After a while the rollback records and other transactions may
cause the logs to reach the LTXEHWM which will halt all other
transactions in an attempt to reserve the remaining log space for the
rollback of this long transaction. At this point no update processing
is occurring for ANY other thread. If the logs fill to the point
where there is no space for any more rollback records in backed up
logical logs, or except for one if LBU_PRESERVE is set to 1, then
the engine will hang waiting for you to backup the logical logs. In
general this cannot be done because there is no room in the logs for
the checkpoint and begin archive records to be written either so the
engine is hung for updates. Soon the next checkpoint period will
occur and that will block readers also until the checkpoint record
can be written and it cannot since there is no room so the engine
goes into CHKPT REQ mode and hangs altogether. At this point if you
have set LBU_PRESERVE you can run onmode -ky and shutdown the engine
then clear LBU_PRESERVE to release the last logical log for reuse,
and restart the engine to single user mode so you will have a chance
to complete Fast Recovery and complete the pending rollbacks and
then backup the logical logs. If you have NOT set LBU_PRESERVE you
are hosed and have to call tech support to truncate the last logical
log or two on disk to allow the rollbacks. In this case some
committed transactions MAY be lost or rolled back due to the
truncation but this is unlikely unless you have the LTX parameters
set way too low.
Quote:> So, when you say "you can shutdown" is immediately after the fail
> occurs ?? if not, what happens if you shutdown after a while ? can
> users go on ?
> >> can I do in order to make it carry on ? by adding more logs in that
> >> moment ? is that possible ?
> Would be good
Unfortunately it's a catch 22. To add logical logs you have to a) log
that fact, b) create a level 0 archive to enable the new logs.
Unfortunately there is no logical log space free, in this case, to
enable you to perform these two tasks so...
Art S. Kagel