Just an idea ...

What I did in my nsrclone/nsrstage jobs is to split them: 
in way of giving 1 list of ssid to nsrclone/nsrstage
(and by consequence having to wait end of job to reclaim space
or for resource to be freezed), I split list based on size 
to clone/stage and/or amount of SSIDs:

If you look, when handling long ssid list, 
nsrstage takes time to purge mediadb and reclaim space.
When handling high amount of data, it takes time to complete
and resource locks occur in a longer period and sometime 
ends up in deadlock.

So, I reengineered my clone/stage process to definitively distribute 
my SSIDs list based on job size of 250GB and/or 30 SSIDs a time 
then I schedule my nsrclone/nsrstage jobs one by one.

Doing so, if a resource lock occurs (eg a tape needed for reading
due to savegroup autocloning, a recover, ...), request will be spooled and
operation will be performed between nsrclone/stage jobs. Another advantage
is that disk space of AFD devices will be faster reclaimed and resource
locks
faster freed.

HTH

TH


Kind regards - Bien cordialement - Vriendelijke groeten,

Thierry FAIDHERBE
Backup/Storage & System Management

LE FOREM
Département des Systèmes d'Information
Direction Infrastructure

Boulevard Tirou, 104  Tel:    +32 (0)71/206730
B-6000 CHARLEROI      Mobile: +32 (477)/995319
                      Fax:    +32 (0)71/206199 
BELGIUM               Mail : Thierry.faidherbe<at>forem.be

"The future belongs to those who believe in the beauty of their dreams",
Eleanor Roosevelt



-----Message d'origine-----
De : EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] De 
la
part de Francis Swasey
Envoyé : mardi 28 février 2012 19:34
À : NETWORKER AT LISTSERV.TEMPLE DOT EDU
Objet : Re: [Networker] daily networker contention...

I have not forgotten that simultaneous clones/stages and recoveries are not
possible today from
the same AFTD.

However, I do not see that task 1 issuing a clone for saveset A from AFTD0
to POOL0, task 2
issuing a clone for saveset B from AFTD1 to POOL0, and task 3 issuing a
stage from AFTD1 to
POOL1 must wind up with task 1 running, task 2 holding AFTD1 and waiting for
a tape in POOL0 to
be available, and task3 holding a tape in POOL1 waiting for AFTD1 to be
available.

Nope, it doesn't have to be that way.  If all of those tasks acquired their
source (AFTD0/1)
and THEN acquired their target (a tape in POOL0/1) - task 1 and 2 would run,
then task 3 would
run.  No problem.   As it is right now, task 1 runs, and task 2 & 3 deadlock
each other until
task 1 completes.  Then task2 and task3 fight it out over who gets to read
from AFTD1 and they
run in succession.  While task1 is running, both AFTDs  and both tape drives
are held hostage.

Frank


On 2/28/12 1:13 PM, bingo wrote:
> As long as 2 different initiators try to control the environment at the
same time using different destination pools this is the obvious result. My
suggestion: Let the DB admins run their backups but take control over
cloning and staging to avoid such problems in the future.
>
> I would also use the argument that you would be faster able to serve a
recover request. Do not forget that simultaneous clones/stages and
recoveries are not possible today.
>

-- 
Frank Swasey                    | http://www.uvm.edu/~fcs
Sr Systems Administrator        | Always remember: You are UNIQUE,
University of Vermont           |    just like everyone else.
  "I am not young enough to know everything." - Oscar Wilde (1854-1900)

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 with 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 with 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