Veritas-bu

Re: [Veritas-bu] Understanding DSSU

2010-09-07 05:49:00
Subject: Re: [Veritas-bu] Understanding DSSU
From: Nic Solomons <Nic.Solomons AT attenda DOT net>
To: Veritas List <veritas-bu AT mailman.eng.auburn DOT edu>
Date: Tue, 7 Sep 2010 10:39:01 +0100
What you are describing is the same behaviour I see across my environments.
Not aware of any functional modification that 'fixes' this, either...

Once NB assigns a resource to a job, it will wait on that resources 
availability. It does this for DSSUs, Tape heads, everything.

i.e. as you are seeing, if a job is running against one DSSU, and that DSSU 
goes full during the job, it will wait on cleanup processes, until timing out. 
No spillover.
Same with tape heads, if you have a job running against a tape head, and that 
tape goes full, and the only other available media is running jobs in another 
head, that job will never switch heads.

I think someone mentioned disk pools, which would do what you want (configured 
through volume manager, or using nbdevconfig at CLI) - but i'm assuming you are 
using Basic Disk units currently, and Disk Pools are Advanced Disk (which has 
an additional license cost associated).  Of course, if you switch to advanced 
disk, it means you can use SLPs instead of DSSUs as well...

Additional/advanced functionality - theres always a cost :P

Cheers,
Nic


-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu 
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Nate 
Sanders
Sent: 03 September 2010 19:32
To: Rusty.Major AT sungard DOT com
Cc: Sanders, Nate; Veritas List; veritas-bu-bounces AT mailman.eng.auburn DOT 
edu
Subject: Re: [Veritas-bu] Understanding DSSU

After checking all 6 DSSUs only one contained 6 images that were
expired. This for sure does not explain why we continue seeing failed
jobs, especially tiny failed jobs.

So is my understanding of Storage Groups not correct? When one unit says
its full, shouldn't the job proceed to the next unit in the group? This
is certainly not the behavior we are seeing based on logs and errors.


On 09/02/2010 02:43 PM, Rusty.Major AT sungard DOT com wrote:
> I first did an ls -l and grabbed the image ID of the images I thought were 
> too old and should have been destaged and expired off of the DSSU.
> I then took those images and ran them through bpimagelist to see if they had 
> a copy on tape (or if it should have been expired).
> Those that had a copy on tape or should have been expired were bpexpdate'd.
>
> If you aren't familiar with these commands, read up on them in the commands 
> guide and do some practicing with them. Especially with bpexpdate.
>
> Rusty Major, MCSE, BCFP, VCS ▪ Sr. Storage Engineer ▪ SunGard Availability 
> Services ▪ 757 N. Eldridge Suite 200, Houston TX 77079 ▪ 281-584-4693
> Keeping People and Information Connected® ▪ http://availability.sungard.com/
> P Think before you print
> CONFIDENTIALITY:  This e-mail (including any attachments) may contain 
> confidential, proprietary and privileged information, and unauthorized 
> disclosure or use is prohibited.  If you received this e-mail in error, 
> please notify the sender and delete this e-mail from your system.



The information contained in this e-mail and its attachments is confidential.
It is intended only for the named address(es) and may not be disclosed to 
anyone else without Attenda's consent.
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu