We're down to destaging every 2 hours. This is as low as it has ever
been. When we were on NBU 5.1MP6 we were destaging between 4-6 hours
with 0 failed jobs. It doesn't seem to add up to me, I've also run
checks against dead images on the DSSU's. Out of 6 DSSU's and thousands
of images, only 6 showed up as being abandoned.
On 09/09/2010 09:30 AM, Larry Fahnoe wrote:
> Here's a quick little script that will validate images on DSSU and let you
> know if there are images that are not in the catalog. I'd make sure the
> contents of your DSSUs make sense before I looked further. You might also
> want to destage more frequently.
>
> --Larry
>
> #!/bin/sh
>
> usage() {
> echo "usage: `basename $0` storage_unit_path"
> }
>
> if [ $# -ne 1 ]
> then
> usage
> exit 1
> fi
>
> cd $1
> for BACKUP_ID in `ls -1 *.info *.img | sed -e 's/_C.*$//' | sort | uniq`; do
> copies=`bpimagelist -backupid $BACKUP_ID 2>/dev/null | awk '/^IMAGE/
> {print $21}'`
> if [ -z "$copies" ]
> then
> echo $BACKUP_ID not found in catalog
> else
> if [ $copies -eq 1 ]
> then
> echo "$BACKUP_ID waiting (copies=$copies)"
> else
> echo "$BACKUP_ID destaged (copies=$copies)"
> fi
> fi
> done
>
>
> On Thu, Sep 9, 2010 at 9:09 AM, Nate Sanders <sandersn AT dmotorworks DOT
> com<mailto:sandersn AT dmotorworks DOT com>> wrote:
> Yeah it sounds like disk pools may be the answer. The thing that has me
> confused is that for 9 straight days before our 5.1MP6-->6.5.6 upgrade,
> I had 0 failed jobs. I found two problems in two different policies that
> were the cause of all previous DSSU troubles and as able to fix them. So
> suddenly after no change but the NBU software version, we're seeing a
> %35 increase in the number of failed jobs on DSSU.
>
>
> On 09/07/2010 04:39 AM, Nic Solomons wrote:
>
>> 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>
>> [mailto: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<mailto:Rusty.Major AT sungard DOT com>
>> Cc: Sanders, Nate; Veritas List; veritas-bu-bounces AT mailman.eng.auburn
>> DOT edu<mailto: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<mailto: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.
>>
>>
> --
> Nate Sanders Digital Motorworks
> System Administrator (512) 692 - 1038
>
>
>
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential. If
> the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by e-mail
> and delete the message and any attachments from your system.
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT
> edu<mailto:Veritas-bu AT mailman.eng.auburn DOT edu>
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
>
> --
> Larry Fahnoe, Fahnoe Technology Consulting, fahnoe AT FahnoeTech DOT com
> 952/925-0744 Minneapolis, Minnesota
> www.FahnoeTech.com<http://www.FahnoeTech.com>
>
--
Nate Sanders Digital Motorworks
System Administrator (512) 692 - 1038
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
