Werner,
I _DO_ think, that insufficient space actually is the reason. I had a
similar situation last year, when I tried to load a database originally
sized less than 25 GB (i don't remeber the exact numbers). I needed
several attempts and only after spending more than 40 GB, the LOADDB
succeeded.
For sake of shortness I have described our problem not very exactly. I should have
mentioned that we have first tried db backup/restore. Unfortunately restore db failed
several times. We have been told by IBM support that the reason for the failure is an
inconsistency in the database and that audi
>-Original Message-
>From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
>Werner Baur
>Sent: Sunday, September 24, 2000 11:19 PM
>To: [EMAIL PROTECTED]
>Subject: Re: ADSM 3.1.2.40 DB unload/reload
>
>
>I'm very pleased to move 5 ADSM serv
ant
Symatrix Technology, Inc.
[EMAIL PROTECTED]
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Werner Baur
Sent: Sunday, September 24, 2000 11:19 PM
To: [EMAIL PROTECTED]
Subject: Re: ADSM 3.1.2.40 DB unload/reload
I'm very pleased to move 5 ADSM se
break
-Original Message-
From: Werner Baur [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 25, 2000 1:19 AM
To: [EMAIL PROTECTED]
Subject: Re: ADSM 3.1.2.40 DB unload/reload
I'm very pleased to move 5 ADSM servers to new machines until end of year.
In
order to be prepared to this i
>So we can safely exclude dump/load db as a way to move an large adsm server.
One should use a database backup and restore to do this, rather than
dump-load, as the latter are salvage utilities. Or...
>BTW: Does anyone have an idea how to move an production server from one machine to
>another?
I'm very pleased to move 5 ADSM servers to new machines until end of year. In
order to be prepared to this interesting task I am evaluating some ways to go.
Right now I am trying a dump/loaddb of one of the lareger ADSM databases.
Database size is about 70 GB, 550,000,000 entries. Dump db on a RS
Hi Tim,
My gut feel says that you won't do much better using disk than the numbers you are
referring to. Those are from my database and we used 3590 tape drives. We typically
see faster backup rates going to tape than to disk. Having said that, it you were to
do the test I'd be very interested
UNLOADDB is a DSMSERV utility added in TSM 3.7.
It's documented in the Admin ref for 4.1 under the topic "TSM Utilities".
It's not there in 3.1.2.40.
> -Original Message-
> From: Tim Melly [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, September 22, 2000 10:52 AM
> To: [EMAIL PROTECTED]
>
>Also, I didn't see anything in the ADSM Admin. Reference manual about
>"unloading" the *SM DB.
It's in the Admin Guide. Also in ADSM.QuickFacts.
I'm not convinced that this has any net positive effect, or that it's
worth the protracted effort. It's going to compact database records -
bring the
10 matches
Mail list logo
