IDS Forum

RE: Ontape/logical logs

Posted By: Sebastian, Norma J.
Date: Thursday, 30 September 2004, at 9:34 a.m.

In Response To: Re: Ontape/logical logs (Martin Fuerderer )

Thanks Martin :)

At my current place of employment, the DBAs before me couldn't get HDR
or ER working so they made a homegrown solution with the expect scripts.
I don't know why they couldn't get HDR or ER working, they left no
notes. Perhaps it was because there is a big distance between the
production database and the hotsite database (like several U.S. states)
with not a big enough/fast enough data pipe between the 2 at the time.
Maybe they found that the distance and speed of pipe was such that the
HDR or ER solution actually impacted the production database negatively
by having the extra overhead of trying to communicate to the hotsite.
In any case, they created quite a cool solution that didn't impact the
production database at all, the production database didn't know/care
that there was a hotsite. I gained a lot of respect for the people
before me when I started maintaining those scripts (I can't take credit
for the creation.... Only wish I could).

Have a good one!
Norma Jean



-----Original Message-----
From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On
Behalf Of Martin Fuer....
Sent: Thursday, September 30, 2004 4:55 AM
To: ids@iiug.org
Subject: Re: Ontape/logical logs [3504]

Hi,

no, you are not. You can let the running "ontape -r" command apply as
many logs as you want (or have), but once it has finished there is no
way to start applying logs again.
The reason for this is, at the point where you tell the "ontape -r"
command that you have no more logical logs, the database is (at least
generally) in an inconsistent state. That means there will be some open
transactions. With no more logs available (as you told the "ontape -r"
that there are no more logs), there is "no hope" that these transactions
will ever be committed. To avoid that these transactions stay open for
the remaining eternety, they are rolled back. This is the so-called
"transaction clean-up phase" of the restore.
Now the database is logically consistent.
Applying new log files would mean that you would want to continue where
you were before the "transaction clean-up", i.e. you would want to
continue those open transactions. But as they have already been rolled
back, there's no way to continue them. Therefore it's not possible to
apply more logical logs after a restore has finished.

You can split the restore into the physical restore ("ontape -p")
followed by the logical restore ("ontape -l") but the same applies, as
soon as you have finished that "ontape -l" command there was a
"transaction clean-up" and no return to log applying is possible.

Having said all this, it becomes clear that Norma Jean Sebastian is
absolutely correct (as always :) , because HDR (High-availability Data
Replication) is doing exactly what you are trying to achieve manually.
It keeps the secondary server (the slave) in this "log recovery phase",
i.e. after a physical restore (and possibly restoring some logical logs
from tape) it will not do the "transaction clean-up".
Instead it will always wait for new logical log records to arrive so
that they can be applied. This is done automatically, i.e. the primary
(master) and secondary server "talk to each other" to figure out, when
log records are to be transfered from primary to secondary and applied
there. This is ongoing at the discretion of transactions, rather than a
whole log file at the time it becomes full. So it gives you a hot
standby that is much more up-to-date. It also gives you the added
benefit that you can still use this secondary server for querying data
(obviously you can't modify data on the slave).

There's more benefit to gain, so I recommend reading the manual
"Administrator's Guide", especially the chapter about "High-Availability
Data Replication".

Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich
Data Management Solutions

forum.subscriber@iiug.org wrote on 30.09.2004 02:21:09:

> Hi all,
>
> I'm reasonably new when it comes to Informix, so I hope this isn't an
often-
> asked question. I've set up a disaster recovery server for our main
Informix
> server, to which I automatically send my level 0/level 1 backups and
logical
> logs, as they're written to disk. I've performed a restore with
> 'ontape
-r'
> successfully, but have a question. Once I finish performing the ontape

> command, am I able to apply each logical log in turn, as it's sent to
the
> backup server, to bring it up to date ? I thought 'ontape -l' might be
what
> I
> needed, but it doesn't seem to work...
>
> I realise 'ontape -r' is able to apply logical logs, but I'd obviously

> prefer not to have to restore the entire database if we ever have a
> severe
crash.
>
> Any help appreciated,
>
> Cheers,
>
> Peter



-----------------------------------------
============================================================ The
information contained in this message may be privileged and confidential
and protected from disclosure. If the reader of this message is not the
intended recipient, or an employee or agent responsible for delivering
this message to the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this communication is
strictly prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and deleting it
from your computer. Thank you. Tellabs
============================================================

Messages In This Thread

• Ontape/logical logs
  Peter Skipworth -- Wednesday, 29 September 2004, at 8:21 p.m.
  • RE: Ontape/logical logs
    Sebastian, Norma J. -- Wednesday, 29 September 2004, at 11:37 p.m.
  • Re: Ontape/logical logs
    Martin Fuerderer -- Thursday, 30 September 2004, at 5:54 a.m.
    • RE: Ontape/logical logs
      Sebastian, Norma J. -- Thursday, 30 September 2004, at 9:34 a.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.