This is an IBM response to a similar problem I'd reported. I think it
helps explain
about the DB.
The ADSM Server database has a b-tree organization with internal refrences
to index nodes and siblings. The database grows sequentially from the
beginning to end, and pages that are deleted internally are re-used later
when
new information is added. The only utility that can compress the database
so
that "gaps" of deleted pages are not present is the database dump/load
utility.
After extensive database deletion occurrs, due to expiration processing or
filespace/volume delete processing, pages in the "middle" of the space
allocated for the database may become free, but pages closer to the
beginning
or end of the database still allocated. To reduce the size of your
database sufficient
free pages must exist at the end of the linear database space that is
allocated
over your database volumes. A database dump followed by a load will remove
free pages from the beginning of the database space to minimize free space
fragmentation and may allow the database size to be reduced.
Request 961007122512 has been entered into our requirements database to
request the development of a utility that would compress fragmented free
space
and allow your server database to be reduced without affecting server
availability.
We will consider this requirement for a future ADSM release.
Jerry Lawson <jlawson AT THEHARTFORD DOT COM> on 03/09/98 10:55:36
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: Claudia Masters/Texas Utilities)
Subject: Data Base Reduction assistance required.... :-(
Date: March 9, 1998 Time: 9:40 AM
From: Jerry Lawson
The Hartford Insurance Group
(860) 547-2960 jlawson AT thehartford DOT com
---------------------------------------------------------------------------
--
--
Another fine mess I've gotten myself into......
Another fine mess I've gotten myself into......
As an oldtimer on this list, I know this question has come up before, but I
can't remember exactly when, so I thought I'd ask it again - which means I
have to plead guilty to not paying good attention the first time it was
asked. But based on what I do remember, this is perhaps the most
ridiculous
example of this problem that's been posted......
I am trying to reduce my DB, but it will not reduce past a point, even
though
the $%#@ thing is EMPTY! :-(
Here's what I did/have done.....
I needed to run a stress test of ADSM, so I borrowed an extra 3380 volume
and
added a DB file out there. I started with a 96MB file that was 12% full,
then added an additional 1248 MB. All was well. I ran my stress test.
(For
the record, I defined a new Policy domain, added a new client, and ran the
backups).
The test completed successfully. I then deleted the file spaces that I had
backed up for the test, then deleted the client itself. I tried to reduce
the DB, but it told me that I could only reduce 1176 MB. Since I also was
doing a couple of other odds and ends at the same time, I thought - must be
something else I did that wrote something out to the new DB vol. So, I
cleaned up what I could, but that didn't help - I can't reduce any further.
I then went after it with a club - I exported all of the defined users, and
then deleted all of their associated file spaces, and when that was done,
deleted their node definitions. Still I can not get the DB to reduce
further.
I then went and deleted all of the policy domains associated with the
nodes,
(but I did leave "Standard"). Still can't reduce.
I then stopped and thought about it for a minute - what is using the DB
space? Ah ha - it must be the activity log information. So I changed the
log to 0 days retention. ADSM stopped logging, but didn't clean up after
itself - it left all of the old log out there! This was last Friday, so I
reset the log retention to 1 day, and left for the weekend - assuming that
the normal expiration would clean everything up.
Alas - this was not to be - I came in this morning, and found that I did
indeed have only 1 days worth of activity log, but I still can't reduce th
elog any further. So, I sat back and tried to think of what else was
holding
the space ------ ah yes - must be some tape volume entries. So, I went in
and did a delete volhist today command and cleaned this out. But no
success
here either - I still cannot reclaim any more space.
Here are the stats:
Current: Original
Available Space 1340 96
Assigned Capacity 164 96
Max extension 1176 0
Max reduction 0 0
Currently, utilization (and MAX utilization) is 0.5 % - only 222 pages out
of
approximately 42K pages in the DB. The Q DB output also says that I have
changed .87MB since the last backup, which is 100% of my DB!
By now you have to know my question - if I am using so little of my DB, why
can't I reduce it any further? What can I do to get back to 96MB (short
of
deleting the DB and doing disaster recovery)?
The guy who loaned me the DASD wants it back :-(((
BTW - Is it Monday?
---------------------------------------------------------------------------
--
--
Jerry
Jerry
Insanity is doing the same thing over and over..and expecting the results
to
be different - Anon.
|
