ADSM-L

Re: ADSM database restore taking a l-l-l-o-o-o-n-n-n-g-g-g time

1997-08-24 21:02:47
Subject: Re: ADSM database restore taking a l-l-l-o-o-o-n-n-n-g-g-g time
From: Trevor Foley <Trevor.Foley AT BANKERSTRUST.COM DOT AU>
Date: Mon, 25 Aug 1997 11:02:47 +1000
Trevor Foley@BT_AUSTRALIA
25/08/97 11:02 AM

We have been doing some more testing with this problem.

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

>----------
>From:  Trevor Foley[SMTP:Trevor.Foley AT BANKERSTRUST.COM DOT AU]
>Reply To:      ADSM: Dist Stor Manager
>Sent:  Thursday, August 14, 1997 4:02 AM
>To:    ADSM-L AT VM.MARIST DOT EDU
>Subject:       ADSM database restore taking a l-l-l-o-o-o-n-n-n-g-g-g time
>
>Hi,
>
>We are currently moving an ADSM environment from one ADSM server to
another
>and the restore of the database on the new machines is taking what we
>consider to be unacceptably long.
>
>The original machine is an RS/6000 R40 dual processor running AIX 4.1.5
and
>ADSM 2.1.5.12, I don't have the versions of Atape and atldd handy but they
>are the ones that were required/recommended for ADSM 2.1.5.12. The new
>machine is an RS/6000 R50 dual processor running AIX 4.2.1, ADSM 2.1.5.13,
>Atape 3.1.1.0 and atldd 3.1.0.5.
>
>The backup of the database, which is 12 gb, 60% utilised, takes 40 minutes
>to 3590s on the R40 when unloaded. We have run the restore 3 times so far
>(2 trial runs) and each time has taken in excess of 5 hours.
>
>The command that we are using is:
>
>     dsmserv restore db devclass=atl3590 volume=d90179 commit=yes
>
>For those of you who have done a restore of a database of this size, are
>the times we are seeing surprisingly long (I sure hope so)? Any
suggestions
>for trying to shorten this time? We are going to try the restore on the
R40
>after the move and compare results.
>
>
>thanks,
>
>Trevor
>
<Prev in Thread] Current Thread [Next in Thread>