I am appending this reply on behalf of Dale McInnis, Technical Manager, DB2
Data Protection and Recovery.
Regards, Nancy
Dale McInnis
07/07/98 01:43 PM
To: ADSM-L AT VM.MARIST DOT EDU, kmedcalf AT dessus DOT com@ internet
cc:
From: Dale McInnis/Toronto/IBM @ IBMCA
Subject: Re: DB2 Backup and Expiration
Hi all,
The attached note was forwarded to me and I would like to respond to some of
the comments made.
Let me start by introducing myself. My name is Dale McInnis and I am the
manager responsible for backup, recovery and datalinks in the DB2 family of
products. Prior to this I was the architect who redesigned backup and recovery
in DB2 Common Server.
Perhaps a little background information would be useful.
DB2/6000 V1 was the first workstation database product to support ADSM. In
this release the backup was completely serialised, permitting only a single
ADSM session to be established. The naming convention used for the ADSM object
created by backup was the following:
File Space Name: <dbname>
High Level Qualifier: "NODE_0"
Low Level Qualifier: "FULL_BACKUP"
DB2 Common Server (V2) 's design point was to increase performance through-out
the entire product, including the utilities. This is when my team and I came up
with the current backup/restore design. There were a number of major changes
introduced, namely:
1) Support of tablespace level backup - allowing you to backup only portions of
the database instead of the entire database
2) Support of multiple media backup targets or restore sources - eliminating
one of the major backup bottlenecks.
Support for multiple targets introduced some interesting design issues. One of
the items we had to deal with was now each database backup could consist of
several files. If you backed up a database several times how would you know
which series of parts belonged to which database. As such we introduced a
timestamp into the backup naming convention as well as a sequence number of
indicate which part this was. The new naming convention used for the ADSM
object created by backup was the following:
File Space Name: <dbname>
High Level Qualifier: "NODE_0"
Low Level Qualifier: "FULL_BACKUP.<timestamp>.<seq_number>" or
"TSP_BACKUP.<timestamp>.<seq_number>"
Thus each ADSM backup became a unique object. We considered changing to ADSM
ARCHIVE instead of ADSM BACKUP, however we wanted to ensure that there was no
way the ADSM server could delete the only backup image with the DBA being
involved. It also make restoring backup level backup images much easier (IBM
always support restore up to 2 prior releases of backup images). This resulted
in the creation of the db2adutl utility so that the DBAs could manage their
ADSM objects. ADSM will never delete its only copy of a backup image, however
for old DB2 backups you want to be able to reclaim the space they used. This
can be done by first setting the management class used by DB2 so that the
number of inactive copies kept is 0, and secondly by running the db2adutl
utility to delete unwanted DB2 backup images. Please note that you want to have
a separate ADSM management class for DB2 object.
I hope this gives you some insight as to why things are the way they are.
_____________________________________________
Dale M. McInnis IBM Toronto Lab
Technical Manager, DB2 Data Protection and Recovery
Email: dmcinnis AT ca.ibm DOT com
Phone: (416) 448-2397, Fax: (416) 448-4414, T/L: 778-2397
---------------------- Forwarded by Nancy Young/San Jose/IBM on 07/07/98 07:55
8 07:55
AM ---------------------------
ADSM-L AT VM.MARIST DOT EDU on 07/06/98 04:07:11 PM
Please respond to kmedcalf AT dessus DOT com
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: DB2 Backup and Expiration
> Thanks for your answer to Gary. We are also dealing
> with the same issue here with AIX DB2 backing up to ADSM V2.1
> (version 2.1 because DB/2 did not certify their version 5 to
> work with ADSM 3.x until late last month). I DELETE the
> unwanted backups with DB2ADUTL and run expire inventory but
> the files are still on tape. Is there another step to making
> them go away? Any information would be appreciated.
The DB2 data is backed up (type=BACKUP) using a unique filename everytime.
The files are never automatically expired/deleted by the client. (A
non-braindead programmer would either have used type=ARCHIVE if the
filenames were unique, or made the filename == the database name if
type=BACKUP, in order that ADSM storage management would work as designed.
Unfortunately, IBMers tend to be little brain-dead when it comes to computer
systems -- particularly when trying to understand why anyone would want to
use one.)
In order to kick in the policy, you have to mark the unwanted backups
DELETED with DB2ADUTL, at which point they will be expired and removed just
like any other backup file deleted from a client machine in accordance with
the policy set.
Yes, it is stupid. Then again, its a glossy brochure feature, not something
designed to be used in other than a glossy brochure marketting environment
(obviously, by the idiotic design).
|
