Hello Tony,

I am (not really) happy to know I'm not the only one to face this kind of
STUPID preformance problem with ADSM.
My conclusion was the same: decrease RecLog size to hold room for an
emergency extend.
But now, the service is down for at least 5 days. If the LOADDB don't crash
and if I don't need to do an AUDITDB.

Nice product on a demonstration implementation with 3 clients and a "big"
1GB DB ;-)

Best regards,

Francis

PS. Our IBM representative will hear about it. One more time.

> ----------
> From:         Tony Rynan[SMTP:tonyr AT AU1.IBM DOT COM]
> Sent:         maandag 22 november 1999 22:50
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Help: ANY HINTS TO SPEED UP LOADDB are welcome
>
> Hi Francis,
>
> I had the same unfortunate occurence recently and have decided to make the
> log size 5.2GB leaving room for an emergency extension of up to 200MB.
>
> It's a waste of useful log space but means recovery takes minutes instead
> of 15 hours.
>
> regards Tonyr
>
> "MAES, FRANCIS" <francis.maes AT FORTISBANK DOT COM> on 23/11/99 00:09:56
>
> Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> To:   ADSM-L AT VM.MARIST DOT EDU
> cc:    (bcc: Tony Rynan/Australia/IBM)
> Subject:  Help: ANY HINTS TO SPEED UP LOADDB are welcome
>
>
>
>
> Hello,
>
> Due to a server cancel during a DB BACKUP with a RECLOG FULL and at
> maximum
> size (5.4GB), it is impossible to restart the server, impossible to extend
> the RECLOG.
> The only way I've found is to DUMP, FORMAT and LOADDB the DB.
> The duration of the DUMP DB was about 6 hours for 428.632.091 DB entries
> and
> 30497 MB copied (DB size 60GB).
> The FORMAT was quick but the LOADDB is VERY VERY SLOW!!
> About 10 times slower as the DUMP DB. This means an elapsed time of about
> 60
> hours !!!!!
> Any ideas to speed up this process are welcome.
>
> Best regards
>
> Francis
>