Veritas-bu

[Veritas-bu] Reprioritizing queued jobs

2002-04-04 17:20:57
Subject: [Veritas-bu] Reprioritizing queued jobs
From: Mark.Donaldson AT experianems DOT com (Donaldson, Mark)
Date: Thu, 4 Apr 2002 15:20:57 -0700
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1DC26.FE51DB90
Content-Type: text/plain

Spectacular - thanks for the complete reply - this will solve a world of
problems I have with drive availability.

-----Original Message-----
From: Larry Kingery [mailto:larry.kingery AT veritas DOT com]


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 
"If it weren't for trucks, there wouldn't be tailgates" -- some country song

------_=_NextPart_001_01C1DC26.FE51DB90
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: [Veritas-bu] Reprioritizing queued jobs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Spectacular - thanks for the complete reply - this will solve a 
world of problems I have with drive availability.</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Larry Kingery [<A HREF="mailto:larry.kingery AT veritas 
DOT com">mailto:larry.kingery AT veritas DOT com</A>]</FONT>
</P>
<BR>

<P><FONT SIZE=2>Donaldson, Mark writes:</FONT>
<BR><FONT SIZE=2>&gt; Your explanation describes the exact situation that I 
just posted back</FONT>
<BR><FONT SIZE=2>&gt; to the list. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Now, about multiple storage units... one of my early 
spectacular</FONT>
<BR><FONT SIZE=2>&gt; problems was not having all drives of equal density in my 
STU, like the</FONT>
<BR><FONT SIZE=2>&gt; book said (SAG: p24-top).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Drives with the same density must be in the same storage 
unit. For</FONT>
<BR><FONT SIZE=2>&gt; example, if a</FONT>
<BR><FONT SIZE=2>&gt; robot has two drives of the same density, add only a 
single storage unit</FONT>
<BR><FONT SIZE=2>&gt; for the</FONT>
<BR><FONT SIZE=2>&gt; robot.</FONT>
</P>

<P><FONT SIZE=2>That's a simple explanation which covers most cases and 
unfortunately</FONT>
<BR><FONT SIZE=2>is worded so that it implies it's a rule.&nbsp; It's not, it's 
a heuristic.</FONT>
<BR><FONT SIZE=2>&quot;... you only need to add a single storage unit&quot; or 
&quot;... you will</FONT>
<BR><FONT SIZE=2>normally want to configure a single storage unit&quot; would 
have been</FONT>
<BR><FONT SIZE=2>better.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In my case, I have 4 DTL7000 drives.&nbsp; Your 
suggestion is to divide up</FONT>
<BR><FONT SIZE=2>&gt; these four drives into two STU's, say 3-drives &amp; 1 
drive.</FONT>
</P>

<P><FONT SIZE=2>Almost.&nbsp; My suggestion is to make two storage units, one 
with only</FONT>
<BR><FONT SIZE=2>three drives (assuming you want to reserve one).&nbsp; The 
other would have</FONT>
<BR><FONT SIZE=2>between one and four drives, whatever you want the max used by 
the db</FONT>
<BR><FONT SIZE=2>backups to be.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>It's okay to have the sum of your STU drive numbers be greater 
than</FONT>
<BR><FONT SIZE=2>the number of drives.&nbsp; An STU drive configuration number 
can be</FONT>
<BR><FONT SIZE=2>thought of as &quot;the MAXIMUM number of drives in use by 
jobs using this</FONT>
<BR><FONT SIZE=2>stu definition at any time&quot;.</FONT>
</P>

<P><FONT SIZE=2>See, you're not dividing up some resources.&nbsp; You're 
telling one set of</FONT>
<BR><FONT SIZE=2>jobs that they are allowed to use a different number 
concurrently than</FONT>
<BR><FONT SIZE=2>some other set of jobs.</FONT>
</P>

<P><FONT SIZE=2>Note that restores and (the read portion of) duplications don't 
use</FONT>
<BR><FONT SIZE=2>storage units.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I can't assign specific drive ID's to a STU so am I safe 
to assume that</FONT>
<BR><FONT SIZE=2>&gt; NB won't get confused?&nbsp; </FONT>
</P>

<P><FONT SIZE=2>Correct.&nbsp; Note however this means that if one drive is 
down, the</FONT>
<BR><FONT SIZE=2>&quot;other&quot; stu could be all the (3) available 
drives.</FONT>
</P>

<P><FONT SIZE=2>&gt; Do I have to fake it with the DLT &amp; DLT2 as</FONT>
<BR><FONT SIZE=2>&gt; drive types?</FONT>
</P>

<P><FONT SIZE=2>No.&nbsp; You *could*, but you don't have to.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; How can I do this?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -Mark</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Larry Kingery [ <A HREF="mailto:larry.kingery AT 
veritas DOT com">mailto:larry.kingery AT veritas DOT com</A></FONT>
<BR><FONT SIZE=2>&gt; &lt;<A HREF="mailto:larry.kingery AT veritas DOT 
com">mailto:larry.kingery AT veritas DOT com</A>&gt; ]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, April 04, 2002 2:12 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Donaldson, Mark</FONT>
<BR><FONT SIZE=2>&gt; Cc: Veritasbu&quot;</FONT>
<BR><FONT SIZE=2>&gt; &lt;veritas-bu AT mailman.eng.auburn DOT 
edu&gt;&quot;@localhost.localdomain</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [Veritas-bu] Reprioritizing queued 
jobs</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Note that priority is not the first parameter used when 
determining</FONT>
<BR><FONT SIZE=2>&gt; which job to run next.&nbsp; If you're using multiplexing 
(which I think we</FONT>
<BR><FONT SIZE=2>&gt; all know), jobs which are eligible to run using a tape 
that's already</FONT>
<BR><FONT SIZE=2>&gt; mounted run before ones with a higher priority which 
would require</FONT>
<BR><FONT SIZE=2>&gt; another tape.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; An example.&nbsp; We have one drive with mpx level of 
two.&nbsp; No</FONT>
<BR><FONT SIZE=2>&gt; ALLOW_MULTIPLE_RETENTIONS_PER_MEDIA</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Job&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
State&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Retention&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Priority</FONT>
<BR><FONT SIZE=2>&gt; ---&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
-----&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --------</FONT>
<BR><FONT SIZE=2>&gt; 
A&nbsp;&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;&nbsp; 0</FONT>
<BR><FONT SIZE=2>&gt; 
B&nbsp;&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</FONT>
<BR><FONT SIZE=2>&gt; 
C&nbsp;&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;&nbsp; anything</FONT>
<BR><FONT SIZE=2>&gt; 
D&nbsp;&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;&nbsp; anything</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Now, let's say job D finishes.&nbsp; A new fragment will 
be started and C</FONT>
<BR><FONT SIZE=2>&gt; and A will run together.&nbsp; Since A could be started 
RIGHT NOW, it won</FONT>
<BR><FONT SIZE=2>&gt; over the higher priority job B (which needed to use a 
different tape</FONT>
<BR><FONT SIZE=2>&gt; due to retention level being different).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; To answer your original question, no you can't change the 
scheduling</FONT>
<BR><FONT SIZE=2>&gt; order.&nbsp; Set up a stu with no more than N-M drives 
and send all the</FONT>
<BR><FONT SIZE=2>&gt; &quot;other&quot; jobs to it, where N is the number of 
actual drives and M is</FONT>
<BR><FONT SIZE=2>&gt; the number you want to reserve for the DB.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Donaldson, Mark writes:</FONT>
<BR><FONT SIZE=2>&gt; &gt; I thought that was only for resolving priority when 
the jobs start at</FONT>
<BR><FONT SIZE=2>&gt; &gt; the same scheduled time - however, with your note I 
dove again into</FONT>
<BR><FONT SIZE=2>&gt; the</FONT>
<BR><FONT SIZE=2>&gt; &gt; SAG and it doesn't seem that way.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; I'll bump the priority up and see what 
happens.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; -Mark</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; From: Geoffrey Hazel [ <A HREF="mailto:geoffh AT 
us.ibm DOT com">mailto:geoffh AT us.ibm DOT com</A></FONT>
<BR><FONT SIZE=2>&gt; &lt;<A HREF="mailto:geoffh AT us.ibm DOT 
com">mailto:geoffh AT us.ibm DOT com</A>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &lt; <A HREF="mailto:geoffh AT us.ibm DOT 
com">mailto:geoffh AT us.ibm DOT com</A> &lt;<A HREF="mailto:geoffh AT us.ibm 
DOT com">mailto:geoffh AT us.ibm DOT com</A>&gt; &gt; ]</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; You must have a class defined for these user 
backups. What about</FONT>
<BR><FONT SIZE=2>&gt; setting</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; the class priority up to 99 or something higher than 
the other</FONT>
<BR><FONT SIZE=2>&gt; classes?</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; ---------------|</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; I use User Backups &amp; User Archives (bpbackup 
&amp; bparchive) to manage</FONT>
<BR><FONT SIZE=2>&gt; hot</FONT>
<BR><FONT SIZE=2>&gt; &gt; DB</FONT>
<BR><FONT SIZE=2>&gt; &gt; backups &amp; archived redo logs.&nbsp; When the DB 
sends a set of files, I</FONT>
<BR><FONT SIZE=2>&gt; want</FONT>
<BR><FONT SIZE=2>&gt; &gt; NB</FONT>
<BR><FONT SIZE=2>&gt; &gt; to jump right on it - regardless of queued jobs 
ahead of it.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Is there any way of reprioritizing jobs that are 
queued?&nbsp; (I'm willing</FONT>
<BR><FONT SIZE=2>&gt; &gt; to</FONT>
<BR><FONT SIZE=2>&gt; &gt; let active jobs complete first)</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; -Mark</FONT>
</P>

<P><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>Larry Kingery </FONT>
<BR><FONT SIZE=2>&quot;If it weren't for trucks, there wouldn't be 
tailgates&quot; -- some country song</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1DC26.FE51DB90--

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