ADSM-L

Re: [ADSM-L] Managing/deleting DBSNAPSHOTs

2010-12-21 15:32:29
Subject: Re: [ADSM-L] Managing/deleting DBSNAPSHOTs
From: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 21 Dec 2010 14:52:45 -0500
Thanks for all the comments/suggestions.

I did try the reconcile volumes but it reported no problems to fix.  I
will keep this command handy and run it as necessary or perhaps regularly
to prevent future problems.

Yes, it was the "delg=0".

Once corrected for all servers, I went back and force/deleted all
snapshots, ran an "expire inventory" and that took care of it, for now.

Again, thanks!
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html



From:
"J. Pohlmann" <jpohlmann AT SHAW DOT CA>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
12/21/2010 01:41 PM
Subject:
Re: [ADSM-L] Managing/deleting DBSNAPSHOTs
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



Zoltan, use reconcile volumes fix=yes at the source server to get rid of
dangling archive objects at the target server. I have a couple of
customers
that have a PMR open for the archive objects of virtual volumes not being
deleted at the target server. You might want to open a PMR too so that
there
is more evidence of this phenomenon. This started with v6.1 and in one
installation that is not using tape but instead file device class at the
target server I had to run regular reconcile volumes fix=yes commands
because they ran out of space. Regardless of whether you are using file or
disk device class to store the data at the target server, reconcile
volumes
fix=yes at the source server will communicate with the target server to
inactivate the dangling archive objects. Then run expire inv at the target
server to physically remove the objects. For file device class, the flat
files will be deleted (assuming they are scratch volumes) and for disk
device class volumes the pages will be freed up.

 And, yes, the comment about delg=0 is quite correct. Use q server f=s to
find out what it is, then update server <name> delg=0.

Regards,

Joerg Pohlmann

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Tuesday, December 21, 2010 07:18
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Managing/deleting DBSNAPSHOTs

We have setup a small, offsite TSM server to function as a repository of
across-the-wire DBSNAPSHOT database backups for our production TSM
servers.
We want each server to perform daily dbsnapshot backups to this server.
Since the offsite server currently has limited disk space (2-dbsnapshots
for
all servers), we need to expire/purge the previous
dbsnapshot-1 before we can perform another dbsnapshot.

I have everything configured and the dbsnapshots work as expected.

My problem is this.  How to I get the dbsnapshots to expire/go away on the
offsite server?  What controls the expiration of the dbsnapshots?  I have
run "delete volhist devclass todate=today-1 type=dbsnapshot" commands and
it
says they are deleted but the space is not release on the offsite server?
I
have had to perform manual "delete filespace ... type=server"
on the offsite server but that deletes everything in the filespace.

What am I missing?
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit
http://infosecurity.vcu.edu/phishing.html

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