Veritas-bu

[Veritas-bu] How to change the working queue priority on the fly?

2000-11-21 16:27:33
Subject: [Veritas-bu] How to change the working queue priority on the fly?
From: W. Curtis Preston curtis AT colltech DOT com
Date: Tue, 21 Nov 2000 13:27:33 -0800
The only real solution, IMHO, is to create a disk-based storage pool that 
can hold 1-3 days worth of logical logs.  Backups and recoveries from disk 
are MUCH faster, and it gets around the problem you are describing.  Then 
you create a class that backs up that disk-based-storage unit to tape every 
hour.  Then you have a cron job that cleans it out once a day.

This is what we do.

At 05:49 PM 11/20/00 -0200, Gustavo Leite de Mendonca Chaves wrote:
>Dear admins,
>
>I'm facing a schedule problem for which I can't find a good solution
>so I decided to use your collective wisdom.
>
>I'm running NBU 3.2 with patch J0820412 on a Solaris 2.6 master server
>and I have a Solaris 2.7 as a slave server.  Each server is attached
>to two DLT7000 drives inside a STK 9714 library.  I also use the
>Informix option to backup an Informix database.
>
>My problem is that during the peak of the scheduled full/cumulative
>backups that goes from Friday/21:00:00 until Saturday/12:00:00 more or
>less all four drives are busy with tapes from the mensal(monthly) and
>semanal(weekly) pools so that the backups initiated by the Informix
>database for its logs can't be performed because they want to use
>tapes from the diario(daily) pool.
>
>One solution would be to increase the number of Informix log files so
>that they couldn't be filled in less than 15 hours but as things are
>they can be filled in less than 3 hours depending on the amount of
>work it's doing.  I would have to multiply the log space by 10 to be
>sure it was safe and I can't do it right now.
>
>To bypass the problem what I did (and still do) was to define two
>`Backup Policy' schedules for the Informix-ON-BAR class with
>complementary windows like so:
>
>         Schedule        Volume Pool     Window
>         Default-Policy  diario          Saturday(12:00) -> Friday(21:00)
>         Default-Weekend mensal          Friday(21:00)   -> Saturday(12:00)
>
>The intent is to direct the log backups to the diario pool most of the
>time and to direct them to the mensal pool during the peak scheduled
>backups when the chance of there being a mensal tape in one of the
>drives is very high.
>
>This kludge has worked more or less.  The problem is that when some
>drives go down or something else happens that cause a delay or a
>change to the peak period I have to foresee it and manually change the
>schedules above.  This has been very unreliable.
>
>What I really wanted was a way to tell the Default Policy schedule to
>automatically use a tape from another pool if all drives are busy with
>tapes not from the diario pool.  Or else, if I could simply tell NBU
>that the log backup jobs are so high priority that they should put
>them on the top of the working queue.  The Informix-ON-BAR class is
>already the most privileged one but this seems to not have the desired
>effect on the log backups.
>
>As a related issue, does anyone know how/if I can list the current
>working list to see how the queued jobs are sorted and how/if I can
>change the order myself?  I think this would be a very useful feature
>and would let me solve this particular problem.  What do you think?
>
>I'd appreciate any help you can give to me.
>
>Thanks.
>
>Gustavo.
>_______________________________________________
>Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

---
W. Curtis Preston, Principal Consultant at Collective Technologies
Email: curtis AT colltech DOT com                (Best way to contact me)
Work : 408 452 5555                       (Leave a message.)
Pager: 800 946 4646, pin#1436065        (If urgent.)

Tap into the Collective Intellect (TM): http://www.colltech.com
Backup & Restore resources:        http://www.backupcentral.com




<Prev in Thread] Current Thread [Next in Thread>