I agree.  I was about 1/2 through the change from big groups to small
groups when it became obvious that this wasn't a good plan.  So I
started looking around for other solutions.  I think what I'm going to
do is go back to medium sized groups(20-30 clients per), and move the
index backups out of the group.  What do you suggest the schedule be for
index backups?  Once in the morning... once every couple of hours during
the night?

For managing the index retention period do you just setup a group with
all the indexes for a specific retention/browse period?

Thanks!

Joel



-----Original Message-----
From: Legato NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
On Behalf Of Davina Treiber
Sent: Saturday, October 29, 2005 5:47 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] networker won't shutdown

Joel Fisher wrote:
> It actually is a pain to manage, but I've just become fed up with one
> client that hangs an entire group and then it doesn't run the next
> night.
> 
> Since I have an entry for the server in each group(for index retention
> length purposes) it does actually put quite a load on the server.  I'm
> trying to decide what I'm going to do about that.  It runs 600+
> bootstraps a night which cause the server to not respond at times.
I'm
> considering moving the indexes to another pool so that I don't have to
> worry about the retention time causing my media to not recycle.
> 
> By your response, I take it you use large groups.  Do you not have
> problems with hanging clients?  How do you handle your indexes?

This must be a management nightmare. This solution is like a 
sledgehammer to crack a nut, and as you have discovered, has introduced 
more problems as side-effects.

I would have chosen to solve the problem in a much more simple way, by 
using a simple script to kill off any overrunning groups. I believe I 
posted such a script recently. Even something that alerts you to 
long-running groups each day would be a good solution. I have used both 
of these approaches for different customers.

Given that you have taken this step though, you have a real problem with

bootstrap backups. Running 600+ bootstrap backups a day is a very bad 
thing, mainly because when the bootstrap backup runs it shuts down the 
media database for a couple of minutes (YMMV). (This is why you see the 
server becoming unresponsive. I don't know whether or not you run RMAN 
backups but in my recent experience, a boostrap backup is likely to kill

a running RMAN backup. It is not easily possible to prevent bootstraps 
from being saved, the only way I know is a bit of a kludge where you 
move out the save command on the server and replace it with a script 
that selectively does not save bootstraps, but allows other backups 
through. Obviously it needs to save the bootstrap sometimes, but the 
script can allow for this in a specified case.

You could implement such a solution, but this would be like (another 
cliche) the old woman who swallowed a fly, and I would advise you to go 
back to multiple clients in a group.

It is often sensible to take the index backups out of the normal groups,

and run them all in a single group (savegrp -O) to an index pool. This 
certainly seems like something you should do here, whatever group 
strategy you are using.

I really believe you have taken the wrong approach here, there are much 
easier solutions to your problem. I will email you a couple of scripts.

To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu 
if you have any problems
wit this list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER