Thanks to Theodore Bush for the helpful information on our space issue
with oracle tars to tape. His experiences will help us make a far
better script for monitoring DLT space. We are defintely going to use
his ideas about the internal tape label and lock.sem to make the process
more reliabel, easier to use.
If anyone is interested, I will post a copy of the archive logging
script we come up with when it is tested and in place.
Thanks again. This list is a great resource.
susrod_at_hbsi.com
- consistency is the defense of a small mind
> ----------
> From: Theodore Bush[SMTP:kn7h_at_worldnet.att.net]
> Sent: Thursday, November 06, 1997 10:34 PM
> To: Susan Rodriguez
> Subject: Re: Space left on DLT's
>
> Hi Susan,
> Sorry...I did get you reply, just been up to my ears (ever known a
> sysadmin
> who wasn't?) here this week. OK...bear with me for a minute. I think
> I
> understand what your DBA wants to do.
>
> I *think* we are talking about the backing up the archive logs that
> Oracle
> writes. If so, if I recall correctly, the archive logs can either be
> forced at regular time intervals (in which case the file size are not
> constant) or, they maybe written when the size of the archive grows to
> some
> predetermined size (the later case is easiest for us to deal with).
> If I
> still on the right track, here's an outline of a solution I
> implemented:
>
> My GOALS:
> 1) Immediately (or as soon as practical) copy the new archive log to
> tape
> 2) Update a running log that the latest archive has been copied to
> tape
> (date, time, volume, etc)
> 3) Notify operations (ie me) when the tape needs to be changed (I
> understand you have a stacker...this will be fun!)
>
> Generic Solution...
> 1) I touched a zero lenght file in the archive directory to use a
> reference, and another file to act as a semaphore (called some like
> ref.sem
> and lock.sem)
>
> 2) Wrote a script that looks for anything NEWER then my ref.sem file
> in the
> archive directory. Anything I find that is newer is a new archive
> that
> needs to be written to tape.
> If the 'lock.sem' isn't present, copy (tar, cpio, whatever) touch
> the
> ref.sem, set the lock.sem, and copy the new archive log(s) to tape.
> If the
> lock sem IS present, it means I am currently copying an archive to
> tape.
> After the new archive has been successfully copied, update the log
> file,
> remove the lock.sem.
>
> 3) If you know the size of the archive files, then you can simple
> determine
> how many will fit on a DLT, and decrement each time. Otherwise, you
> know
> the capacity of the DLT, you can determine the size of the archive
> file,
> and keep a running tally of the space you have left (as you
> suggested). If
> you have enough space remaining, write the archive to the current
> tape, if
> not, switch to a new tape.
>
> 4) I call this script out of cron every 5 minutes are so; the overhead
> is
> minimal--if there is no new archive, I simple exit.
>
> I actually got a little more elaborate than this...I get *REALLY*
> spooky
> about and automated process blindly writting to tape. For this
> reason, I
> concocted a labeling scheme for all the tapes used for this purpose.
> There's a little extra efort in 'initializing' the tape, but with some
> simple checking in your script, you KNOW you're writting to the write
> tape.
> The other nice thing about this is if the external label, sticky or
> what
> ever happens to fall of, you can read the internal label and figure
> out
> what you have on your tape!
>
> I also wrote a a rather length script to handle backups of all the ASE
> services using the TZ877's based on vdump that would handle spanning
> volumes, automatically inventorying and managing tapes, etc (the nice
> stuff
> that NSR does; problem for us at the time was NSR was too much of a
> resource hog for our application and at that time it didn't handle ASE
> services well at all). Handling tape movement with the 877's is
> pretty
> straight forward.
>
> I know I've got these scripts around here somewhere (er, at least I
> did...lost the hard drive on my PC. Yes, I have backups, not quite as
> religious about my personal stuff as I am clients production
> stuff...).
> I'm a consultant in the Phoenix area, and this was about three clients
> ago;
> may take me a little while to locate them!
>
> Hope this helps a little and that I'm not totally off base. Let me
> know!
> Happy almost Thursday (in Arizona at least) and be sure to check out
> http://www.wild-a.com for all your adventure flying and areial
> photography
> needs!
>
> Ted
>
> ----------
> > From: Susan Rodriguez <SUSROD_at_HBSI.COM>
> > To: kn7h_at_worldnet.att.net
> > Subject: FW: Space left on DLT's
> > Date: Wednesday, November 05, 1997 10:10 PM
> >
> > I wonder if my reply to you went astray.
> >
> > We would really appreciate any help you might be able to offer us.
> >
> > Thanks,
> >
> >
> > susrod_at_hbsi.com
> >
> > - consistency is the defense of a small mind
> >
> >
> > > ----------
> > > From: Susan Rodriguez
> > > Sent: Sunday, November 02, 1997 12:26 PM
> > > To: 'Theodore Bush'
> > > Cc: Khalid Ridha
> > > Subject: RE: Space left on DLT's
> > >
> > > Thanks for responding. I haven't had anyone offer any practical
> > > advice.
> > >
> > > Our Oracle dba wants to write a script to keep track of his
> database
> > > archive logging tapes. The same set of 7 tapes stays in the 887
> for a
> > > week receiving tars of zipped archive logs. He has two goals. 1
> -
> > > verify that the archive logs are successfully tarring to the tape
> and
> > > 2 - know how much tape he has used and how much more is left on a
> > > particular tape.
> > >
> > > If you have any advice, examples, or suggestions, we would be most
> > > grateful.
> > >
> > > Thanks,
> > >
> > > Susan
> > > susrod_at_hbsi.com
> > >
> > > ----------
> > > From: Theodore Bush[SMTP:kn7h_at_worldnet.att.net]
> > > Sent: Monday, November 03, 1997 7:55 AM
> > > To: Susan Rodriguez
> > > Subject: Space left on DLT's
> > >
> > > Hi Susan,
> > > I ran into a similar problem using DLT's in an 877 stacker and
> > > implemented
> > > a solution very similar to what you are suggesting. I needed to
> > > support
> > > backup accross multiple labeled volumes in the stacker for
> backups; 1
> > > 1/2
> > > years latter the client is still using this stragegy.
> > >
> > > Feel free to email me if I can help.
> > >
> > > Ted Bush
> > > kn7h_at_worldnet.att.net
> > > http://www.wild-a.com
> > >
> > >
>
Received on Thu Nov 06 1997 - 21:46:19 NZDT