*** Original Author: ADSM-L @ MARIST - ** Remote User **; 09/26/96 04:56pm
>Received: from VM.MARIST.EDU by AUDUCADM.DUC.AUBURN.EDU (IBM MVS SMTP V3R1)
> with TCP; Thu, 26 Sep 96 16:56:19 CDT
>Received: from VM.MARIST.EDU by VM.MARIST.EDU (IBM VM SMTP V2R3)
> with BSMTP id 2980; Thu, 26 Sep 96 16:40:07 EDT
>Received: from VM.MARIST.EDU (NJE origin LISTSERV@MARIST) by VM.MARIST.EDU
> (LMail V1.2b/1.8b) with BSMTP id 5487; Thu, 26 Sep 1996 16:40:05 -0400
>Received: from VM.MARIST.EDU by VM.MARIST.EDU (LISTSERV release 1.8b) with NJE
> id 2640 for ADSM-L AT VM.MARIST DOT EDU; Thu, 26 Sep 1996 16:40:01
> -0400
>Received: from MARIST (NJE origin SMTP@MARIST) by VM.MARIST.EDU (LMail
> V1.2b/1.8b) with BSMTP id 5475; Thu, 26 Sep 1996 16:40:01 -0400
>Received: from gatekeeper.hcc.com by VM.MARIST.EDU (IBM VM SMTP V2R3) with TCP;
> Thu, 26 Sep 96 16:39:58 EDT
>Received: by gatekeeper.hcc.com (5.65/jj-092193); id AA08069; Thu, 26 Sep 1996
> 16:41:29 -0400
>Received: by brw-exc-02.bridgewater.ne.hcc.com with SMTP (Microsoft Exchange
> Server Internet Mail Connector Version 4.0.993.5) id
> <01BBABC9.978A2590 AT brw-exc-02.bridgewater.ne.hcc DOT com>; Thu,
> 26 Sep
> 1996 16:41:40 -0400
>X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
>Encoding: 47 TEXT
>Message-ID:
> <c=US%a=ATTMAIL%p=HOECHST%[email protected]
> er.ne.hcc.com>
>Date: Thu, 26 Sep 1996 16:41:33 -0400
>Reply-To: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>Sender: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>From: "Pittson, Timothy ,Corp,US" <tpittson AT HIMAIL.HCC DOT COM>
>Subject: Re: (Fwd) Reduction of Database
>To: Multiple recipients of list ADSM-L <ADSM-L AT VM.MARIST DOT EDU>
>
David,
No, you don't need to reinitialize the database - you're doing a full
database dump and a partial database reload (as you suspected the -t
parameter tells ADSM just to load those tables). Just make sure when
you shut down ADSM before the dump to do it with a HALT QUIESCE so you
don't have to do a database audit after the reload - that is a VERY
painful process. You will get checkpoint messages on the database load
but, after awhile they're intermittent so you can't use that as an
indicator. I'd also recommend using a non-ADSM utility (i.e. DSS or FDR
on MVS) to do physical dumps of your ADSM database, logfiles, and all
other files (other than disk storage pools) before you start the
database reload - ADSM is not very forgiving on the reload syntax and I
ended up having to restore the whole database and recovery log to rerun
the reload because I had a PARM statement syntax error on the load and
it would not let me rerun it. I'm not sure how long you're job will
run but I can't imagine it running longer than the reload I did - our
db was about 6.2 GB and the partial reload took a little under 7 hours.
Good luck !!!
Tim Pittson
tpittson AT himail.hcc DOT com
>----------
>From: David Ong SMTP:david AT BABYONG.NSC DOT COM
>Sent: Thursday, September 26, 1996 3:52 PM
>To: Multiple recipients of list ADSM-L
>Subject: Re: (Fwd) Reduction of Database
>
>Tim,
>
>Thanks for the reply. I wonder if you can clarify a couple of things for me?
>In
>II08975, the instruction to dump & load the db does not include
>re-initializing
>the db with a dsmserv install command. It seems to imply that the -t option
>used
>will simply dump & load the particular tables involved. Is this what you mean
>by
>partial reload in your note?
>
>Also, as far as progress messages go, I am looking for some indication that
>the
>reload is still going ok as opposed to simply waiting for the process to end
>in
>5 or 10 or 20 hours.
>
*** Comments From: STEWAJM - Stewart, Mike; 09/27/96 07:17am
David;
I went through the same process sometime back. For about a
3 GB database I think the _entire_ process took about 6 hours or so.
Like Tim, I had a syntax error on the reload parm.
After that, the databases were marked and I had to do
restore. I ran through the process on a test database the day before
and thought I could slip it in early one weekday morning.
I think I had planned on about 2-3 hours. I was very glad I had
run through it on a test database the day before since I also
tested the recovery procedures which I used.
This was on MVS on a 9672 model 1.
|
