ADSM-L

Re: ADSM Database reduction question

2000-02-01 12:25:06
Subject: Re: ADSM Database reduction question
From: Bill Colwell <bcolwell AT DRAPER DOT COM>
Date: Tue, 1 Feb 2000 12:25:06 -0500
The tsm 3.7 server has improved dumpdb, loaddb facilities which should do
a reorg in a reasonable amount of time while actually
doing some good.  The b-tree splitting is done in a manner that makes the
resulting db use the minumum size.

Study the appendix in the admin reference for 3.7.


--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <DB62908E2717D21197E100805F8BF685010E9473@UUG-RES-MP03>, on 02/01/00
In <DB62908E2717D21197E100805F8BF685010E9473@UUG-RES-MP03>, on 02/01/00
   at 12:25 PM, "Bates, Richard" <Richard.Bates AT VERTEX.CO DOT UK> said:

>Robert,

>I can't remember where I found this info (list or manual) but here goes:

>"The ADSM Server database has a b-tree organisation with internal
>references 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
>occurs, 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
>minimise free space fragmentation and may allow the database size to be
>reduced."

>We have exactly the same problem on our ADSM servers.  As far as I
>understand the only way round this is to perform a dsmserv dumpdb and
>loaddb.  I think it was mentioned on the list recently that an online
>defrag tool would be useful.

>Last weekend we tried this on our server (10gb database, 0.5gb memory,
>AIX 4.3, SP wide node).  The dumpdb took just over an hour.  We had to
>cancel the loaddb as we were looking at a 72 hour load time.  We restored
>the database from a normal DB backup.

>We still have the problem, so if you do find another way, please let me
>know.

>Richard.

>=====================================
>Technical Services (ADSM) - Dawson House
>Int: 33298  Ext: 01925 233298
>=====================================

>> -----Original Message-----
>> From: Burton, Robert [SMTP:ROBERT.BURTON AT ROYALBANK DOT COM]
>> Sent: 01 February 2000 15:57
>> To:   ADSM-L AT VM.MARIST DOT EDU
>> Subject:      ADSM Database reduction question
>>
>> We have a 23,576 MB database, that originally was running at 94% utilised.
>> By moving clients to other servers and
>> deleting filespace we have reduced our capacity to 37.3%.  We are trying
>> to
>> reclaim some database volumes.
>> We have a spare 1112 MB of free space in the database.  According to my
>> calculation 37% of 23576 MB is approx.
>> 9000 MB which means we have large quantity of wasted space in the
>> database.
>>
>> Is there anyway to compress the database to get rid of the wasted free
>> space?  I tried deleting database volumes using our freespace in the
>> database. This did not reclaim the space on the deleted volume it just
>> copied the volume being deleted (valid data & space) to the freespace.
>>
>> Any suggestions would be appreciated....
>>
>>
>> Robert Burton
>> Open Systems Storage Analyst
>> Royal Bank of Canada
>> (416) 348-3849
>> Robert.Burton AT RoyalBank DOT com


>**********************************************************************
>This email and any files transmitted with it are confidential and
>intended solely for the use of the individual or entity to whom they are
>addressed. If you have received this email in error please notify the
>system manager.

>This footnote also confirms that this email message has been swept by
>MIMEsweeper for the presence of computer viruses.

>www.mimesweeper.com
>**********************************************************************

--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
=========================================================================
<Prev in Thread] Current Thread [Next in Thread>