Anthony,
The problem is probably that your transaction log drive is
feverishly trying to satisfy the current running server log entries
as well as trying to restore and replay the old transaction log entries.
The disk head is probably moving all over the place and I/O requests
are taking lot more time than usual trying to satisfy
both the current active server and the restore/replay that
you are doing.
I may have some things for you to try...but first...
A few observations...as far as your comment about
not providing any benefit over the replication
server solution... that is not entirely true since
in the replication server solution you need to
provide multiple servers with enough capacity
to handle ALL of the databases from your production
servers whereas in the case of using an alternate server
just for restore... you just need enough space
for doing your specific restores.
And, you really only need to have one physical
"alternate" server that has a sole purpose
of doing these types of restores.
In addition, with the replication server solution
you will not have the same granularity on restore.
But, there is probably a way to get it to work
on the same server using a slightly modified
"Alternate Server Restore" procedure.
The key is try to off-load the log restore/replay
IOs to a different physical drive.
We haven't experimented very much with this but in theory
it should work...
Take a look at the README file under a section called:
Restoring Logged Databases to an Alternate Server
-------------------------------------------------
You should be able to modify this procedure
(starting with step 4)to a create an "alternate"
server on the same machine, (that you never actually start).
You would point the transaction log drive to a different physical
drive than the current active one.
Again, you should try this out on a test server before
actually implementing it on the production but
it should work. I hope this helps.
Thanks,
Del
----------------------------------------------------
Del Hoobler
Del Hoobler
IBM Corporation
hoobler AT us.ibm DOT com
Anthony S Colletti/Poughkeepsie/IBM@IBMUS AT VM.MARIST DOT EDU> on 01/03/2001
07:50:59 AM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Tivoli Data Protection for Domino performance
Has anyone experienced poor restore performance with TDP for Domino 1.1.1
and Domino Server 5.05 running on AIX 4.3.3 ? We are noticing that to
restore a fully backup copy of a 100MB file and apply logs for 3 days (we
average 70 logs per day) it is taking 1.5 - 2.0 hours to complete.
However, our full backup times are running around 12-14 hours for 1500 plus
databases. Anyone know of any reason why the apply logs is taking so much
longer than the full backup ? The only workaround I have seen so far is
to restore to an alternate server, but that is something I really didn't
want to resort to as it would provide no benefit over the current ADSM
Backups we are doing via replication backup servers.
Thanks in advance
Anthony Colletti
|
