ON-Bar Logical Logs to Disk
Clifton Bean asked how to send ON-Bar logical logs to disk while archives go to the storage manager (7.30, Digital Unix). Doug Agnew said ON-Bar sends logs to the storage manager only, and the manager must be treated as mission-critical. Fred Prose switches to ontape for logs during outages and forces a level 0 afterwards; Doug questioned whether mixed restores work. Not tested in the thread.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
I am looking for any remarks, comments, how-to information on how to use ON-Bar with the logs going to disk (in case of a storage manager failure) and archives going to the storage manager. We are using 7.30, about to migrate to 7.31, Digital Unix.
Clifton, OnBar is going to send the logs to the storage manager, period. No options. Besides, if the storage manager fails, you're not going to be restoring from any backups anyhow. Also, if you back them up with something other than OnBar, how would you process them in conjunction with a restore from OnBar? If your concern is that you will not be able to back up your logs while the storage manager is down and thereby risk causing the database to grind to a halt, then you have a legitimate concern. The best approach to take may be to investigate potential 'long-term' failure scenarios of the storage manager (things that can't be cured in the timeframe before the logs fill up) and determine how to recover/prevent/bypass them. I'm thinking of those nasty things like: the SM machine dying permanently or the SM database (they all have one) being corrupted. Once you commit to OnBar, then the SM becomes a mission-critical piece of software and should be treated like any other production system. I know I'm preaching to the choir but it deserves to be said anyway. Doug "Clifton M. Bean" <cmbean@email.msn.com> wrote in message news:#Uxs7aHGAHA.279@cpmsnbbsa07... > I am looking for any remarks, comments, how-to information on how to use > ON-Bar with the logs going to disk (in case of a storage manager failure) > and archives going to the storage manager. We are using 7.30, about to > migrate to 7.31, Digital Unix. > > > >
In the event that our Storage manager (ADSM) is not going to be available
for any length of time (longer than the number of logical logs will hold) we
revert to ontape and the internal 9mm drive. When things are back online we
leave the internal drive doing the LLogs until the nightly backup. At that
time we stop ontape and force the next nightly onbar to a level 0. After
that point, I really don't care than my logical logs are in two different
places and media because my recovery point is the onbar level 0 and any logs
written after that point.
Fred,
The question comes to mind (not impugning your procedure, but just have to
ask the obvious):
Have you ever restored from your OnBar backup, applied logs from OnBar and
then applied logs from ontape?
I don't know that it is even possible, but have not tested it. It would
seem that OnBar would apply what logs it could and then put the system into
Quiescent state, thinking that it had done all that needed to be done. I
don't know that you can do logical restore from ontape after that. Would be
VERY interested if you have succeeded.
Thanks,
Doug
"Fred Prose" <fprose@supreme.sp.state.az.us> wrote in message
news:8p967m$cj4@netnews.state.az.us...
> In the event that our Storage manager (ADSM) is not going to be available
> for any length of time (longer than the number of logical logs will hold)
we
> revert to ontape and the internal 9mm drive. When things are back online
we
> leave the internal drive doing the LLogs until the nightly backup. At
that
> time we stop ontape and force the next nightly onbar to a level 0. After
> that point, I really don't care than my logical logs are in two different
> places and media because my recovery point is the onbar level 0 and any
logs
> written after that point.
>
>