Re: Moving disk from one ASP to another

I posted a question last week about what folks would anticipate the time
to move of disks from ASP 3 to ASP 1. Just did all my DASD work over the
weekend and thought I'd just follow up with some times and such ("For the
archives") :

Here are the step I proposed and comments about it :

Verified weekend Domino and application backups ran ok.
I did a GO SAVE Option 21 first and that's about 2 hours 15 minutes.

First, I was thinking about doing a Manual IPL to and move one of the
drives from ASP 3 to ASP 1.
ASP 3 is currently 23 % utilized with four drives in it. So technically
all the data should fit on one drive.
So I'm doing this at the beginning so as I move data from ASP 3 to ASP 1,
I shouldn't worry about filling ASP 1. In addition ASP 1 has about 170 GB
free but I wouldn't plan on using more than 40 GB in a pinch during this
procedure.

This part took about two hours. I thought at the time since the same

RAID array was reading (from the disk to be moved) and writing (to the
other disk in that ASP) that the time was increased.

Back up Dvlp01\data\*.* to a *SAVF (currently about 11.5 GB)

I created a *SAVF in ASP1 and saving took about 14 minutes.

Un-mount the UDFS from DVLP01\data

Only took a few seconds

Restore Dvlp01\Data from the *SAVF.

Restore took about 15 minutes.

Back up Mail01\data\*.* to *SAVF (currently about 16.9 GB)

This was going on with the backup of DVLP01 server. The 16.9 GB to a

*SAVF in ASP3 (ASP 1 was getting highly utilized on all the volumes. The
one drive that I swapped over at the beginning only had about 4% utilized,
but the rest of the array was in the high 80s.) I decided to keep it in
ASP3 even though there was contention within the RAID array.

This took about 17 minutes

Un-mount the UDFS from Mail01\data

This only took a few seconds

Restore Mail01\dta fom *SAVF

This took 18 minutes

***Unplanned Step : STRASPBAL TYPE(*CAPACITY) ASP(1) TIMLMT(60).

The fact that the new drive was way under utilized and all the other

drives were too high, I felt that I needed to get some better
distribution. This ran for, um, 60 minutes.

Back up Apps01 (currently at 13.5 GB)

This again was going to a *SAVF in ASP 3 (contention). The process took

20 minutes and was running with MAIL01.

Restored Apps01

This ran about 15 minutes

Start Domino servers and make sure they work

I started them up and poked around a bit. The console are very verbose

so many 'errors' are merely warning.

I spent about 20 minutes verifying

***Unplanned Step : Backup the UDFS in /dev/QASP03/

To an LTO-2 drive so it was only about 20 minutes.

Delete UDFS files in ASP3.

This took longer than I expected. DLTUDFS doesn't work if there are

files within the UDFS. I had to mount it to another directory and then I
used my Windows drive mapping to get to the directory. Always seemed to
be a couple files Windows couldn't delete but I was able to get them via
WRKLNK and option 4. This took about half an hour.

At that point, ASP3 should be almost completely empty.

It was weird, there was .004% used in ASP3 but I deleted everything I

knew I had over there. I did a WRKLIB LIB(*ALL) ASP(3) and there were no
libraries and when I did a WRKLNK /dev/QASP03, again there were no
entries.

Anyone got any ideas if there is another way to have data in another ASP?

I guess it's secondary now, since it's deleted.

Shut down and IPL manual again into DST.

About 15 minutes to shutdown and IPL to DST
I had to Delete ASP 3 (after a few moments to pause and think before I

hit enter "What is the .004%!! utilized")


Move the remaining, 'near empty' DASD units to ASP 1.

This is what really got me. I thought that since there wasn't anything

on the disk, and therefore nothing to move around, that adding them would
be quick. No deal, as this was another 2 hours. I guess when you think
about it, you increasing the area single level storage can access and
there is probably a lot of addressing work that goes on.

IPL normal.

About 15 minutes.
At this point I decided to look at the Domino consoles one last time... I

nearly s### myself...

The first message I see is "HARDWARE ERROR " UNABLE TO WRITE TO DISK

...and some path". I verified that it was happening another Domino
server.

NOTE : for Domino people. The Domino administrator had mapped a drive to

the Domino \data directory and copied a new NAMES.NSF via Windows. He was
the owner of the object and caused QNOTES not to be able to write to the
database. Brought the servers down, changed ownership and brought them
back up. All looked good.


So there you have it, just a reference to things that happened. No
biggie, just thought I'd share a 13 1/2 hour day... or 3 1/2 hours over my
outage due to not knowing how long moving DASD between ASPs (empty or not)
would take - which was the deference.





Michael Smith
Technical Support and Data Center Manager
Farm Family Insurance cos.

V : (518) 431-5117
F : (518) 431-5985
E : Michael_Smith@xxxxxxxxxxxxxx
Business Hours : M - F : 8:30 - 4:30 EST