ADSM-L

UNLOADDB/LOADDB Performance Note

2002-07-17 09:33:26
Subject: UNLOADDB/LOADDB Performance Note
From: William White <White AT UNICC DOT ORG>
Date: Wed, 17 Jul 2002 11:38:56 +0200
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
William White
Mainframe Services Group
International Computing Centre (ICC)
e-mail: white AT unicc DOT org
<Prev in Thread] Current Thread [Next in Thread>