LogShipping: recover_replace of logs too slow. Can we tune it?

[Former Member]

Hello,

after having trouble with bad pages on MaxDB we built up a standby db with LogShipping to be prepared for future trouble. All in all, it works. We wrote a script, that makes a dbmcli session. It begins with recover_start, after that it continues with ongoing recover_replace commands. Our productive db writes logs every hour (at least). When the system load is high (during heavy batch jobs for example), it writes several GBs of logs during one hour. We then have the situation, that recovering of 1 hour logs of the productive system takes several hours to recover into the standby db, the standby system is not able to follow up in time. The hardware of the standby db doesn´t show high activity (cpu, memory, network, disk).

Here the question:

Has anybody an idea to speed up the log recovery? Perhaps any maxdb parameters (the standby db is offline during log recovery)?

Any help appreciated. Thanks.

Frank

Edited by: Frank Sievering on Apr 10, 2011 9:04 AM

[lbreddemann · Accepted solution]

Hello Frank,

the database is not offline during recovery, but in ADMIN mode - so, technically it would be possible to perform some system monitoring.

Unfortunately, DBAnalyzer is not available during ADMIN mode, so you'd have to resort to manually interpreting the x_cons output.

Once often seen issue is the DB CACHE size on the standby db being to small.

Also worth to check is the I/O performance - which can also be checked via x_cons (time enable + show t_cnt + IO queues on MaxDB >=7.7).

regards,

Lars

[Former Member · Accepted solution]

Hello Lars,

yes, thats it!

We understimated the (cache-) memory demand for the standby db. We put more memory into the (virtual) machine, increased the MaxDB Cache (6GB instead of 1,5), and now the shipping is running significantly faster, fast enough to follow the original db.

And of course you are right, during restore the db is in admin mode.

Thank you very much, you helped us a lot.

Frank