ADSM-L

Re: EXPIRE INVENTORY processing in V3

1998-03-02 09:00:00
Subject: Re: EXPIRE INVENTORY processing in V3
From: Ben Bullock <bbullock AT MICRON DOT COM>
Date: Mon, 2 Mar 1998 07:00:00 MST
  I'm not sure this will add anything to the discussion other than "yes, we
have the same problem", but here is our situation.

 I am wrestling the same problem with expires on my db. Here is how we are set
up:

RS/6000 R30... w/8 cpu
AIX 4.2.1
1Gb ram
ADSM 2.1.5.15
32 4.5Gb SSA disks


  The DB is about 26Gb with 23Gb used (5,411,651 pages). We have about
23,500,000 files backed up, all of them from SUN, NT and Novell file servers.
Oh, cache hit % is 98.00

 Our expire inventory takes about 36 hours and deletes about 500,000 files,
and we try to run it about twice a week, but while it is running, the reclaims
and stgpool backups run *very* slow.

  In monitoring this job, we see that it pauses a *long* time (almost 8 hours)
on one server that has about 3 million files backed up. We also see that there
are a lot of I/O waits to the disks that hold the database, probably because
we have 2 dbvols on each disk. We have done this because of lack of disk space
& SSA drawers.

  At this point we are wondering 2 things:
1. Will our performance improve dramatically if we create only 1 dbvol on each
   SSA disk?

  This would be a waste since we have 4.5 gb disks, but have been unable to
  create a dbvol larger than 2Gb, eventhough IBM claims we can make it as
  large as we want. AIX and DSFMT can create it, but ADSM will say it's
  "unavailable" when I try to define a dbvol that is larger than 2Gb.

2. Do we have a db problem with that very large filespace? Is there a way to
audit the DB to check it out? ("dsmserv auditdb" does not seem appropriate in
this case).

Thanks,
Ben Bullock
Micron Technology

 ---------- Start of forwarded message ----------

>Hello everyone,

>There has been discussion about changes to the Expiration
>Processing in later versions of V2 and V3 releases of the
>server.  I was hoping someone from Development/Support
>could give us an overview of exactly how Expiration works.

>For example, our current problem is that we have let
>expiration run for up to 5 days and it has never (recently)
>completed.  Yesterday I stopped it at the following point:
>287,312 examined and 256,474 deleted.  I immediately
>restarted it and the examined to deleted ratio as it
>progressed was about the same! Today after approximately 16
>hours the stats are: 97,778 examined and 97,075 deleted.

>Did it start over from the beginning or does it pick up
>from where it left off?

>Is there any way for me to query the total number of
>objects in my database so I can get an idea of how much is
>left to be examined?

>Is there any reason I should let it fully complete, or can
>I start and cancel expiration as required by my daily
>scheduled activities?

>Finally, do these stats seem low or normal?  We have a 20GB
>database running on an RS/6000 J40 (4 CPU) with AIX 4.2.1
>and ADSM V3.1 (+latest fix), and by the way I just noticed
>our Cache Hit Pct is 96.45%

>Thanks very much,

>Scott.
>Scott McCambly
>AIX/NetView/ADSM Specialist - Unopsys Inc.  Ottawa,
>Ontario, Canada (613)238-5620

This seems awfully slow.  I run expire inventory once a
week.  My adsm is on mvs, the adsm version is 2.1.0.13.  The
db is 5.8 million pages  (about 23 Gb).  It ran in 5 hr, 23
min and expired 237,323 backups. This is pretty much how it
goes every week.
the version 2 message doesn't report 'object examined.  The
cache hit ratio is 98.51, just a little better than yours
but not enough to account for the huge performance
difference.

To count the number of object, do a 'query occupancy',
capture the output and sum the number of files.  I think you
should exclude the files in copypools.  I have 31,000,000
files.

We are comparing apples and oranges as far as the hardware
is concerned, so I can't say if that alone would account for
the difference. I have an s/390 9672-r41 (1 processor, 45
mips)  with escon channels to STK Iceberg dasd.
--
-----------------------------------------------------------
-----------------------------------------------------------
Bill Colwell
Bill Colwell
Draper Lab
bcolwell AT draper DOT com
-----------------------------------------------------------
=========================================================================
<Prev in Thread] Current Thread [Next in Thread>