ADSM-L

Re: UNLOADDB/LOADDB Performance Note

2002-07-17 10:12:29
Subject: Re: UNLOADDB/LOADDB Performance Note
From: Jim Kirkman <jmk AT EMAIL.UNC DOT EDU>
Date: Wed, 17 Jul 2002 10:10:32 -0400
I'd be interested in hearing  how long these improvements in db processing time
last. From what I've read on this list it seems these kind of improvements can
be short lived, or am I wrong about that?

You're right, 10 hrs. seems like a long time for a reload.

William White wrote:

> Dear  TSM'ers,
>
> I recently saw several postings regarding TSM performance for UNLOADDB and
> LOADDB.
> Last weekend I did it and here are the results.
>
> Environment:   OS/390 V2.8;   IBM 9672-RC4;   STK 9840 tape
>
> UNLOADDB:
>
> Command: UNLOADDB DEVCLASS=RTAPE SCRATCH=YES CONSISTENT=YES
>
> TSM server V4.1.2, recovery log 1488 MB, database 8376 MB (from ANR0200I
> and ANR0201I messages)
> Job issued ANR4013I messages at about 15 second intervals up to 82385957
> database entries,
> then no more messages for 2 hours and 16 min.
> Finally:
> Copied 1823964 database pages, 280 bit vectors, 0 bad database pages,
> 50668494 database entries,
> 4369 MB copied.
> The job ran for 144.36 minutes on a lightly loaded system.
>
> REFORMAT:
>
> I had some difficulty with the documentation, because it referred to member
> ASAMPLIB(ANRINST).
> As far as I can see, the syntax of the parameter field is not documented
> anywhere.  When I
> used '/FORMAT n LOGNAME1 LOGNAME2 ... LOGNAMEn m DBNAME1 DBNAME2 ...
> DBNAMEm' the LOADDB
> failed with a message "database not initialized."  Then I tried
> "/LOADFORMAT ..." with the
> same operand syntax as /FORMAT and it worked.  With /LOADFORMAT you get a
> message:
>
> ANR1004I Server formatting complete, database ready for loading.
>
> LOADDB:
> The job ran for 619.02 minutes and produced these messages at the end:
> ANR4032I LOADDB: Copied 1823962 database records.
> ANR4033I LOADDB: Copied 273 bit vectors.
> ANR4035I LOADDB: Encountered 0 bad database records.
> ANR4036I LOADDB: Copied 50668494 database entries.
> ANR4037I LOADDB: 4369 Megabytes   copied.
> ANR4004I LOADDB: Database load process completed.
> ANR4404I LOADDB: Loaded a consistent dump image - a database audit
> (AUDITDB)
> ANR4404I is NOT required.
>
> There was one other problem:  A bit vector error prevented one of the DASD
> storage pool
> volumes from coming online.  The support center pointed me to APAR PQ49053.
> I applied
> PTF's for TSM V4.1.6 and followed the recovery instructions in the APAR
> text.  One bit
> vector was recreated and now the server is running normally.
>
> The database went from over 90% to 63% utilized.
>
> Expiration processing went from 7-8 hours to 3 hours and database backup
> went from 2-3
> hours to slightly more than one hour.
>
> I was surprised that the LOADDB operation took four times as long as the
> unload, but
> that's what you get when you do something for the first time.
>
> Regards,
> www.
>
> ---------------------------------------------------------
> William White
> Mainframe Services Group
> International Computing Centre (ICC)
> e-mail: white AT unicc DOT org

--
Jim Kirkman
Jim Kirkman
AIS - Systems
UNC-Chapel Hill
966-5884
<Prev in Thread] Current Thread [Next in Thread>