> 1). Is there is more comprehensive planning information
> available which might help prevent some of the problems mentioned here?
Not really. The conversion utility as shipped for version 1 is
broken. APAR PN47179 addresses a lot of these issues, but I still
don't have a copy of the code to see if it fixes everything.
We're still having a few residual problems after the conversion
so I hope the APAR will fix everything (even if it does involve
a possible 24 hour DBAUDIT run...sigh). Note that IBM is not
recommending anyone try to convert from WDSF to ADSM until this
APAR clears - it's *really* pervasive.
I can give you numbers from our experience, but your mileage may
vary, depending on your workload. On a heavily loaded 9121-320
with roughly 2.6 million catalog entries:
> o How long the recommended WDSF audit takes
About 3.5 hours
> o How long the DSSERV DBDUMP to tape takes
About 2.5 hours
> o How long the DSMSERV DBCNVT from tape takes
Plan for at least 36 hours. Ours took 22.5 hours.
> o What system resources (CPU, Memory) will be required for each step.
The audit step is I/O intensive (reads every record in the
database several different ways) and will run fine in whatever
setup your WDSF server is running in now. The DBDUMP step
occupies a tape drive for the duration, but isn't otherwise all
that noticeable. The DSMSERV DBCNVT step is *extremely* resource
intensive. It sat at 22-24% of the CPU for the entire conversion
process, and consumed a tape drive for that duration. It required
at least a 32M virtual machine, and 64M is good insurance.
> 2). Is there a specific state the ADSM server must be in before I do
> the conversion? For example, am I allowed to have additional client
> nodes, non-default storage pools and policy domains defined, and must
> the default storage pools and domains be present at the time the
> conversion is done?
No. The server is assumed to be in a pristine state by the
conversion utility -- and I mean in the state immediately
following a DSMDBP run that includes formatting and reserving the
DB and log disks. If you have existing information in the ADSM
server, either offload it with the EXPORT option, or be willing
to toss it. I hope the APAR I mentioned above fixes this...
> 3). What will happen if ADSM tries to convert data for
> a client node that is already defined? Administrators?
Bad things. Don't do this. EXPORT the whole mess and reload it
later. Make sure you understand the explanation of the IMPORT
process in the administrator guide so you can decide what'll be
left.
> 4). One thing which bothers me about the conversion process is the reuse
> of the WDSF repository disks. This strikes me as inviting trouble
> and ought to be avoided. In environments (like ours) where there
> is enough disk to run two separate WDSF and ADSM servers, it occurs
> to me that one could do the following:
I complained about this too. I don't understand why the ADSM
server needs write access to the WDSF repositories; I can
understand the need to read the old disks, but I'm confused on
the write requirement. I think the developer I spoke with
mentioned that this would be fixed in the APAR.
> o On the WDSF server, delete all the DISK repository volumes with the
> RECLAIM
> option. When all have been deleted, all the data will be
> on tape, and
> there
> won't be any repository disk to convert. You can then delete the WDSF
> disk repository level as well.
> [...]
> I'd appreciate it if people could comment on the viability of this
> approach. I'm most concerned about whether the conversion utility
> could handle the situation where no repository disks are defined, and,
> of course, for other show stoppers I haven't forseen.
That's a really good idea. I wish I'd thought of that. Would have
saved me a lot of grief.
|
