Hello Reinhard,

I'm happy to share some experience about the ADSM "big" servers management.

Backup and restore DB or add and delete DB volumes are both moving PAGES and
not logical entries.
The DB is not reorganized with these utilities.
Actually, the only utility that is logically copiing the DB is DUMP-LOADDB.

Now, with your information about the page splits management of LOADDB, I'm
thinking about a cancel of the LOADDB and a RESTORE DB based on the DB
backups (with point in time to the last Incr). This should be faster as the
LOADDB.

Should it be acceptable for a DB/2 or an IMS DB to be unavailable for 5 days
for a reorg? No, of course.
It is nice to have a proprietary DB to drive ADSM but the utilities needs to
be robust. We are not playing with ADSM but working with production
datas....

Best regards

Francis


> ----------
> From:         Reinhard Mersch[SMTP:mersch AT UNI-MUENSTER DOT DE]
> Sent:         mardi 23 novembre 1999 9:53
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Help: ANY HINTS TO SPEED UP LOADDB are welcome
>
> Francis,
>
> be cautious about that. I recently loaded our 25 GB DB (more than 90%
> filled) on a test server. The LOADDB died several times:
> ANR4019E : Load processing failed - insufficient database space.
> I had to spend more than 40 GB DB space, until it was successfull.
> The reason is: While the ADSM server is quite efficient about page
> splits, LOADDB uses the traditional B-tree page split algorithm, which
> results in DB pages, which are filled a little more than 50% on the
> average.
> Hopefully, this problem will not show up at your site. Especially since
> you have 62GB for 30GB used space.
>
> Regarding the desired DB reduction: wouldn't a combination of defining new
> and deleting old DB volumes have helped you? Anyway: I would be interested
> to hear from you, whether you achieved it via LOADDB.
>
> Best wishes.
>
> PS: We are four.
>
> MAES, FRANCIS writes:
>  > Yes, of course, it will be better to use a backup DB to restore but:
>  > - Our DB is 62GB big and the real used space is about 30GB. This crash
> was a
>  > good reason (not the exact term but my english is poor) to reorganize
> the
>  > DB. Otherwize, there is no way to reduce the DB once the space has been
>  > used.
>  > - The last Full Backup is 2 weeks old and there are 26 incr. The full
> of
>  > last week was missed. (problems are never coming alone). I was thinking
> it
>  > should take too much time to read back all the full and incr
> cartridges.
>  > (weekly full backup takes 6 to 7 hours to complete). Now, it seems that
>  > LOADDB may be slower as RESTORE DB but I'm not sure. It is to be
> tested. The
>  > problem is I have disk space enough for only one 62GB DB ;-).
>
>
> --
> Reinhard Mersch                        Westfaelische Wilhelms-Universitaet
> Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum
> Roentgenstrasse 9-13, D-48149 Muenster, Germany      Tel: +49(251)83-31583
> E-Mail: mersch AT uni-muenster DOT de                       Fax: 
> +49(251)83-31653
>