I assume you mean 78 million entries for a total of 6.9GB. Then yes it does
take that long to do a LOADDB. I've heard of slightly larger databases
taking over 48 hours to reload.
----- Original Message -----
From: "William Boyer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, April 15, 2001 5:50 PM
Subject: Should LOADDB take this long?
> TSM 3.7.3.0 running on OS/390 2.9
>
> Last night our automated processes to shut the system down didn't take
into
> account that TSM would take a few extra minutes to halt due to reclamation
> running. The automation script ended up taking TCPIP and CA-TLMS and
> DFSMSRmm (in warn mode) down while TSM was still up and trying to close
out
> his tape processing. TSM ended up abending with a EC6. After our downtime,
> TSM wouldn't come back up. It would sit there in a CPU loop with no I/O.
The
> last message in the joblog was "ANR0306I Recovery log volume mount in
> progress." WOuld come up any farther. I managed to get an DUMPDB to run
and
> it took only 1/2 hour and dumped over 78million database entries for a
total
> of 6.9MB. I then did a FORMAT for all the db/log volumes and started the
> LOADDB last night at 20:15. It is still running and it is now 22 hours
later
> and has only processed 70million of those database entries.
>
> I searched the archives, but there wasn't much on LOADDB. Should LOADDB
take
> this long when the DUMPDB only took 1/2hour? Good thing this is a holiday
> weekend or the users and managers would be more upset than they
> are. I tell them, Hey it wasn't my shutdown script that corrupted the
> system!!!
>
> Also, if anyone has any ideas on how I could have averted having to do the
> DUMP/LOADDB processes I would be more than happy to hear them. I just
> couldn't think of any way to bypass the recovery log processing during
> startup, or to have the load cleared by itself.
>
> TIA,
> Bill Boyer
> "Some days you are the bug, some days you are the windshield." - ??
