Setup of standby with log shipping

[thomasschulz2]

Hello list,

I want to setup an standby database on a different server, based on regularly complete/incremental/log backups.

In the past we run this scenario (via bash scripts):

- complete backup (once a day)

- incremental backups (every 30 minutes)

- cold incremental backup in the case of normal switching from live to standby server

This scenario works fine for the 2-3 situations, where we have to switch between the servers.

Now I want to change this to a combination to (mix of bash and perl scripts):

- complete backup (once a week/month)

- incremental backup (once a day)

- log backups (every <n> minutes)

according to the maxdb documentation and due to the fact, that we have configured autolog on and this way generate about on log backup every hour.

In various tests I have found a solution, where I use a complete backup for initialization and then regularly restore the log backups from the original db to the standby db.

Here an example:

a) db_admin
   db_connect
   db_activate RECOVER <complete media> DATA

b) db_admin
   db_connect
   recover_start <log media> LOG 001

c) db_admin
   db_connect
   recover_start <log media> LOG 001
   recover_replace <log media> "<location of log media>" 002

d) db_admin
   db_connect
   recover_start <log media> LOG 002
   recover_replace <log media> "<location of log media>" 003

and so on ...

Here are my questions:

1. Is it correct, that I have to restore the last successful restored log (if not the first) from the previous session with "recover_start", before I can restore the next log with "recover_replace" in a new session?

2. Can't I mix the restoring of incremental and log backups in this way: log001, incremental data, log002, ...? In my tests I was able to restore the incremental data direct after the complete data, but not between the log backups.

3. Can I avoid the state change to OFFLINE after a log restore?

I have read various documentations about this subject, but didn't find detailed descriptions about the concrete interactions between these commands, when using them in shell or perl scripts, which are executed regularly.

Maybe somebody has developed something similar to this. I've seen some approaches from others, but none of them seems to cover completely the scenario above.

Regards,

Thomas

[thomasschulz2]

Hi Lars,

OK - then I add an additional "dbmcli ... db_admin" call after each log recovery.

Thanks for your help,

Thomas

[lbreddemann]

HI again,

just out of curiosity: why do you perform a db_admin after a log recovery?

To me it would be more sensible to perform the db_admin before the recovery of a log.

KR Lars

[thomasschulz2]

Hi Lars,

the idea behind the db_admin after log restore is only, to save some time (maybe only seconds) for the next restore and to hold the standby db in admin state. For completeness, every restore script starts with an initial db_admin.

Regards,

Thomas

Edited by: Thomas Schulz on Mar 5, 2008 4:26 PM

[lbreddemann]

>

> Here are my questions:
> 
> 1. Is it correct, that I have to restore the last successful restored log (if not the first) from the previous session with "recover_start", before I can restore the next log with "recover_replace" in a new session?
Yes, that's correct. As soon as you leave the restore session, you have to provide a 'overlap' of log information so that the recovery can continue.
> 2. Can't I mix the restoring of incremental and log backups in this way: log001, incremental data, log002, ...? In my tests I was able to restore the incremental data direct after the complete data, but not between the log backups.
No, that's not possible. After you've recovered some log-information the incremental backup cannot be appliead as a "delta" to the data are anymore as the data area has already changed.
> 3. Can I avoid the state change to OFFLINE after a log restore?

Of course - don't use recover_cancel

As soon as you stop the recovery, the database is stopped - no way around this.

There are some 3rd party tools available for this, like LIBELLE.

KR Lars

[thomasschulz2]

That means, that every time, I close the dbmcli session after a log restore, the db is in the state OFFLINE and have to be restarted to ADMIN again for the next restore in a new session?

Regards,

Thomas

[lbreddemann]

Hi Thomas,

yep, that's right.

But starting the DB to admin mode should not be an issue and should not take much time.

KR Lars