ADSM database restore taking a l-l-l-o-o-o-n-n-n-g-g-g t

 Make sure you have at least the following maintenance on AIX 4.2.1:

APAR IX67978
The corresponding ptfs are U448863 and U448885.
There was a change made to AIX 4.2.1 that these fixes back out.
It affected applications like ADSM which use write-through functions
to ensure data integrity.

>
> The system that we are having the problem on is a brand new machine; we
> have moved the load of an existing machine onto this machine.
>
> There were quite a number of software products that were at a later version
> on the new machine including AIX, ADSM, ATLDD and ATAPE.
>
> In order to troubleshoot the problem, we restored the exact same backup to
> the original server. The restore completed in 87 minutes. We then started
> upgrading each software component to the same version as the new server,
> re-running the restore after each change. The change and resulting restore
> time are shown below:
>
>      Atape 3.1.1.0       83  minutes
>      ADSM PTF13          85 minutes
>      ATLDD 3.1.0.5       85 minutes
>      AIX 4.2.1      495 minutes
>
> Obviouly there is an issue with AIX 4.2.1. We have since managed to
> decrease the restore time slightly. It was recommended to us by an IBMer
> that we issue the command /usr/samples/kernel/vmtune -c 1. Apparently this
> option should have been the default on 4.2.1, as it was on 4.1.5, but
> mistakenly wasn't. This reduced the restore time to 448 minutes, still a
> long way short of being acceptable.
>
> There are 3 things that have come out of our testing. First, for those of
> you who are planning a 4.2.1 upgrade, you may want to hold back until this
> is resolved. Or at least keep it in mind when you do. Second, for those
> already at 4.2.1, you may want to consider the vmtune change. Remember that
> this setting is volatile so needs to be issues with each reboot. And keep
> in mind the possible restore times. Third, does anyone have any ideas as to
> why this has occured? We still have the old machine sitting around so we
> are able to perform a few more tests (at least for the next week or so) to
> try and get this resolved.
>
>
> regards,
>
> Trevor
>