Veritas-bu

[Veritas-bu] Reprioritizing queued jobs

2002-04-04 17:11:46
Subject: [Veritas-bu] Reprioritizing queued jobs
From: larry.kingery AT veritas DOT com (Larry Kingery)
Date: Thu, 4 Apr 2002 17:11:46 -0500 (EST)
Donaldson, Mark writes:
> Your explanation describes the exact situation that I just posted back
> to the list. 
> 
> Now, about multiple storage units... one of my early spectacular
> problems was not having all drives of equal density in my STU, like the
> book said (SAG: p24-top).
> 
> 
> Drives with the same density must be in the same storage unit. For
> example, if a
> robot has two drives of the same density, add only a single storage unit
> for the
> robot.

That's a simple explanation which covers most cases and unfortunately
is worded so that it implies it's a rule.  It's not, it's a heuristic.
"... you only need to add a single storage unit" or "... you will
normally want to configure a single storage unit" would have been
better.

> 
> 
> In my case, I have 4 DTL7000 drives.  Your suggestion is to divide up
> these four drives into two STU's, say 3-drives & 1 drive.

Almost.  My suggestion is to make two storage units, one with only
three drives (assuming you want to reserve one).  The other would have
between one and four drives, whatever you want the max used by the db
backups to be.  

It's okay to have the sum of your STU drive numbers be greater than
the number of drives.  An STU drive configuration number can be
thought of as "the MAXIMUM number of drives in use by jobs using this
stu definition at any time".

See, you're not dividing up some resources.  You're telling one set of
jobs that they are allowed to use a different number concurrently than
some other set of jobs.

Note that restores and (the read portion of) duplications don't use
storage units.

> 
> I can't assign specific drive ID's to a STU so am I safe to assume that
> NB won't get confused?  

Correct.  Note however this means that if one drive is down, the
"other" stu could be all the (3) available drives.

> Do I have to fake it with the DLT & DLT2 as
> drive types?

No.  You *could*, but you don't have to.

> 
> How can I do this?
> 
> -Mark
> 
> -----Original Message-----
> From: Larry Kingery [ mailto:larry.kingery AT veritas DOT com
> <mailto:larry.kingery AT veritas DOT com> ]
> Sent: Thursday, April 04, 2002 2:12 PM
> To: Donaldson, Mark
> Cc: Veritasbu"
> <veritas-bu AT mailman.eng.auburn DOT edu>"@localhost.localdomain
> Subject: RE: [Veritas-bu] Reprioritizing queued jobs
> 
> 
> Note that priority is not the first parameter used when determining
> which job to run next.  If you're using multiplexing (which I think we
> all know), jobs which are eligible to run using a tape that's already
> mounted run before ones with a higher priority which would require
> another tape.
> 
> An example.  We have one drive with mpx level of two.  No
> ALLOW_MULTIPLE_RETENTIONS_PER_MEDIA
> 
> Job          State       Retention      Priority
> ---          -----       ---------      --------
> A            Queued      1 week         0
> B            Queued      2 weeks        92
> C            Active      1 week         anything
> D            Active      1 week         anything
> 
> Now, let's say job D finishes.  A new fragment will be started and C
> and A will run together.  Since A could be started RIGHT NOW, it won
> over the higher priority job B (which needed to use a different tape
> due to retention level being different).
> 
> 
> To answer your original question, no you can't change the scheduling
> order.  Set up a stu with no more than N-M drives and send all the
> "other" jobs to it, where N is the number of actual drives and M is
> the number you want to reserve for the DB.
> 
> 
> Donaldson, Mark writes:
> > I thought that was only for resolving priority when the jobs start at
> > the same scheduled time - however, with your note I dove again into
> the
> > SAG and it doesn't seem that way.
> >
> > I'll bump the priority up and see what happens.
> >
> > -Mark
> >
> > -----Original Message-----
> > From: Geoffrey Hazel [ mailto:geoffh AT us.ibm DOT com
> <mailto:geoffh AT us.ibm DOT com> 
> > < mailto:geoffh AT us.ibm DOT com <mailto:geoffh AT us.ibm DOT com> > ]
> >
> > You must have a class defined for these user backups. What about
> setting
> >
> > the class priority up to 99 or something higher than the other
> classes?
> >
> > ---------------|
> >
> > I use User Backups & User Archives (bpbackup & bparchive) to manage
> hot
> > DB
> > backups & archived redo logs.  When the DB sends a set of files, I
> want
> > NB
> > to jump right on it - regardless of queued jobs ahead of it.
> >
> > Is there any way of reprioritizing jobs that are queued?  (I'm willing
> > to
> > let active jobs complete first)
> >
> > -Mark
> >
> 
> --
> Larry Kingery
>                            Free the mallocs
> 
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> 
> <TITLE></TITLE>
> 
> <META content="MSHTML 6.00.2713.1100" name=GENERATOR></HEAD>
> <BODY>
> <P><FONT size=2>Your explanation describes the exact situation that I just 
> posted back to the list.&nbsp;<BR><BR>Now, about multiple storage units... 
> one 
> of my early spectacular problems was not having all drives of equal density 
> in 
> my STU, like the book said (SAG: p24-top).</FONT></P><FONT size=2>
> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
>   <P><BR>Drives with the same density must be in the same storage unit. For 
>   example, if a<BR>robot has two drives of the same density, add only a 
> single 
>   storage unit for the<BR>robot.</P></BLOCKQUOTE>
> <P><BR>In my case, I have 4 DTL7000 drives.&nbsp; Your suggestion is to 
> divide 
> up these four drives into two STU's, say 3-drives &amp; 1 drive.<BR><BR>I 
> can't 
> assign specific drive ID's to a STU so am I safe to assume that NB won't get 
> confused?&nbsp; Do I have to fake it with the DLT &amp; DLT2 as drive 
> types?</P>
> <P>How can I do this?</P>
> <P>-Mark<BR><BR>-----Original Message-----<BR>From: Larry Kingery [<A 
> href="mailto:larry.kingery AT veritas DOT com">mailto:larry.kingery AT 
> veritas DOT com</A>]<BR>Sent: 
> Thursday, April 04, 2002 2:12 PM<BR>To: Donaldson, Mark<BR>Cc: 
> Veritasbu"<BR>&lt;veritas-bu AT mailman.eng.auburn DOT 
> edu&gt;"@localhost.localdomain<BR>Subject: 
> RE: [Veritas-bu] Reprioritizing queued jobs<BR><BR><BR>Note that priority is 
> not 
> the first parameter used when determining<BR>which job to run next.&nbsp; If 
> you're using multiplexing (which I think we<BR>all know), jobs which are 
> eligible to run using a tape that's already<BR>mounted run before ones with a 
> higher priority which would require<BR>another tape.<BR><BR>An example.&nbsp; 
> We 
> have one drive with mpx level of two.&nbsp; 
> No<BR>ALLOW_MULTIPLE_RETENTIONS_PER_MEDIA<BR><BR>Job&nbsp;&nbsp;&nbsp;&nbsp; 
> &nbsp;&nbsp;&nbsp;&nbsp; State&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
> Retention&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
> Priority<BR>---&nbsp;&nbsp;&nbsp;&nbsp; 
> &nbsp;&nbsp;&nbsp;&nbsp; -----&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
> ---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
> --------<BR>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; 
> Queued&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1 week 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
> 0<BR>B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; 
> Queued&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2 
> weeks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
> 92<BR>C&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; 
> Active&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1 week 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
> anything<BR>D&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; 
> Active&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1 week 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; anything<BR><BR>Now, let's say job 
> D 
> finishes.&nbsp; A new fragment will be started and C<BR>and A will run 
> together.&nbsp; Since A could be started RIGHT NOW, it won<BR>over the higher 
> priority job B (which needed to use a different tape<BR>due to retention 
> level 
> being different).<BR><BR><BR>To answer your original question, no you can't 
> change the scheduling<BR>order.&nbsp; Set up a stu with no more than N-M 
> drives 
> and send all the<BR>"other" jobs to it, where N is the number of actual 
> drives 
> and M is<BR>the number you want to reserve for the DB.<BR><BR><BR>Donaldson, 
> Mark writes:<BR>&gt; I thought that was only for resolving priority when the 
> jobs start at<BR>&gt; the same scheduled time - however, with your note I 
> dove 
> again into the<BR>&gt; SAG and it doesn't seem that way.<BR>&gt;<BR>&gt; I'll 
> bump the priority up and see what happens.<BR>&gt;<BR>&gt; 
> -Mark<BR>&gt;<BR>&gt; 
> -----Original Message-----<BR>&gt; From: Geoffrey Hazel [ <A 
> href="mailto:geoffh AT us.ibm DOT com">mailto:geoffh AT us.ibm DOT 
> com</A><BR>&gt; &lt;<A 
> href="mailto:geoffh AT us.ibm DOT com">mailto:geoffh AT us.ibm DOT 
> com</A>&gt; 
> ]<BR>&gt;<BR>&gt; You must have a class defined for these user backups. What 
> about setting<BR>&gt;<BR>&gt; the class priority up to 99 or something higher 
> than the other classes?<BR>&gt;<BR>&gt; ---------------|<BR>&gt;<BR>&gt; I 
> use 
> User Backups &amp; User Archives (bpbackup &amp; bparchive) to manage 
> hot<BR>&gt; DB<BR>&gt; backups &amp; archived redo logs.&nbsp; When the DB 
> sends 
> a set of files, I want<BR>&gt; NB<BR>&gt; to jump right on it - regardless of 
> queued jobs ahead of it.<BR>&gt;<BR>&gt; Is there any way of reprioritizing 
> jobs 
> that are queued?&nbsp; (I'm willing<BR>&gt; to<BR>&gt; let active jobs 
> complete 
> first)<BR>&gt;<BR>&gt; -Mark<BR>&gt;<BR><BR>--<BR>Larry 
> Kingery<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; Free the 
> mallocs<BR></P></FONT></BODY></HTML>

-- 
Larry Kingery 
"If it weren't for trucks, there wouldn't be tailgates" -- some country song