How to Create a Backup Site ?

Hi There,

My Boss ask me how to create a Backup site for Ingres Database, I looked
at Ingres Documentation and the only solution that I can found was use
ingres replicator to whole the database.

I ask you guys. There are other ways to do that ?

There are a way to replicate journal like a Oracle Standby Database ?

Thank you All !!

Regards

Thiago Zerbinato
Ribeirao Preto, SP
Brazil

On Aug 20, 2008, at 8:38 AM, thiagomz wrote:

> Hi There,
>
> My Boss ask me how to create a Backup site for Ingres Database, I
> looked
> at Ingres Documentation and the only solution that I can found was use
> ingres replicator to whole the database.
>
> I ask you guys. There are other ways to do that ?
>

It depends on a few things, but mainly on whether you need
the standby to be exact up to the most recent committed transaction,
or if you can tolerate the standby being a couple minutes out of
date in the worst case.

If you need a standby that is guaranteed to be always
exactly in sync with the primary, I think your only
option right now is replication. You can use the
traditional Ingres replicator or the HVR product.
HVR might be easier to set up and keep running.
I think Ingres Corp is working with Golden Gate on a
log based replicator, but I don't know any details or
timeframes.

If you can tolerate the standby being possibly a few minutes
out of date, what you can do is set up an exactly identical
Ingres installation on another machine. This installation
has to have the same directory paths as the primary. You then
take checkpoints on the primary and rollforward them on the
standby. Journal files get copied incrementally from primary
to standby, and if the primary fails, the journals are
rolled forward on the backup. (There's an incremental
journal rollforward feature that I think is in ingres2006r3
that makes this much easier. With older versions you have to
be careful to restore the checkpoint snapshot with +c -j,
and only restore the journals if needed since you only get
one shot.) You can use something like rsync to minimize the
data transferred between primary and standby.

With the journal-copy solution, you'll probably want to issue
trace point DM1314 before copying a new journal increment.
DM1314 forces an early journal cycle so that you don't miss
transactions that are sitting in the transaction log, waiting
for the next journal cycle.

Karl

On Aug 20, 2008, at 10:14 AM, Gerard Schoorl wrote:

> HVR already supports log-based capture for Ingres databases.
> Support is from Ingres 2.6, unto and including Ingres 2006 R3.


Thanks for the correction, Gerard; I see I'm a bit behind the times!

Karl



>
> -----Original Message-----
> From: info-ingres-bounces-at-kettleriverconsulting.com
> [mailto:info-ingres-bounces-at-kettleriverconsulting.com] On Behalf Of
> Karl
> & Betty Schendel
> Sent: Wednesday, August 20, 2008 3:29 PM
> To: Ingres and related product discussion forum
> Subject: Re: [Info-Ingres] How to Create a Backup Site ?
>
>
> On Aug 20, 2008, at 8:38 AM, thiagomz wrote:
>
>> Hi There,
>>
>> My Boss ask me how to create a Backup site for Ingres Database, I
>> looked
>> at Ingres Documentation and the only solution that I can found was
>> use
>> ingres replicator to whole the database.
>>
>> I ask you guys. There are other ways to do that ?
>>
>
> It depends on a few things, but mainly on whether you need
> the standby to be exact up to the most recent committed transaction,
> or if you can tolerate the standby being a couple minutes out of
> date in the worst case.
>
> If you need a standby that is guaranteed to be always
> exactly in sync with the primary, I think your only
> option right now is replication. You can use the
> traditional Ingres replicator or the HVR product.
> HVR might be easier to set up and keep running.
> I think Ingres Corp is working with Golden Gate on a
> log based replicator, but I don't know any details or
> timeframes.
> ...

Guys,

Thank all ! I´ll try that´s possible solutions.

Regargs,

Thiago

thiagomz escreveu:
> Hi There,
>
> My Boss ask me how to create a Backup site for Ingres Database, I looked
> at Ingres Documentation and the only solution that I can found was use
> ingres replicator to whole the database.
>
> I ask you guys. There are other ways to do that ?
>
> There are a way to replicate journal like a Oracle Standby Database ?
>
> Thank you All !!
>
> Regards
>
> Thiago Zerbinato
> Ribeirao Preto, SP
> Brazil

Hi all!
I am running Ingres 2.6 sp5 on a Tru64 box.
My disaster recovery schema, include a periodic copy (about each 20
minutes) of production environment journals to another machine file system.
According to mails below, I want to execute trace point DM1314, just
before copying journal files to remote machine.
Is there any known risk to do this?

Your comments will be appreciated

Regards

Oscar Carlés

Karl & Betty Schendel wrote:
> On Aug 20, 2008, at 8:38 AM, thiagomz wrote:
>
>
>> Hi There,
>>
>> My Boss ask me how to create a Backup site for Ingres Database, I
>> looked
>> at Ingres Documentation and the only solution that I can found was use
>> ingres replicator to whole the database.
>>
>> I ask you guys. There are other ways to do that ?
>>
>>
>
> It depends on a few things, but mainly on whether you need
> the standby to be exact up to the most recent committed transaction,
> or if you can tolerate the standby being a couple minutes out of
> date in the worst case.
>
> If you need a standby that is guaranteed to be always
> exactly in sync with the primary, I think your only
> option right now is replication. You can use the
> traditional Ingres replicator or the HVR product.
> HVR might be easier to set up and keep running.
> I think Ingres Corp is working with Golden Gate on a
> log based replicator, but I don't know any details or
> timeframes.
>
> If you can tolerate the standby being possibly a few minutes
> out of date, what you can do is set up an exactly identical
> Ingres installation on another machine. This installation
> has to have the same directory paths as the primary. You then
> take checkpoints on the primary and rollforward them on the
> standby. Journal files get copied incrementally from primary
> to standby, and if the primary fails, the journals are
> rolled forward on the backup. (There's an incremental
> journal rollforward feature that I think is in ingres2006r3
> that makes this much easier. With older versions you have to
> be careful to restore the checkpoint snapshot with +c -j,
> and only restore the journals if needed since you only get
> one shot.) You can use something like rsync to minimize the
> data transferred between primary and standby.
>
> With the journal-copy solution, you'll probably want to issue
> trace point DM1314 before copying a new journal increment.
> DM1314 forces an early journal cycle so that you don't miss
> transactions that are sitting in the transaction log, waiting
> for the next journal cycle.
>
> Karl
>
> _______________________________________________
> Info-Ingres mailing list
> Info-Ingres-at-kettleriverconsulting.com
> http://www.kettleriverconsulting.com...fo/info-ingres
>
>


--
Lic. Oscar Carlés Barriocanal
Director de Servicios al Cliente
Íntegra S.R.L.
Telefax: (595 21) 424473 RA
Asunción - Paraguay

On Aug 22, 2008, at 5:43 PM, Oscar Carlés wrote:

> Hi all!
> I am running Ingres 2.6 sp5 on a Tru64 box.
> My disaster recovery schema, include a periodic copy (about each 20
> minutes) of production environment journals to another machine file
> system.
> According to mails below, I want to execute trace point DM1314, just
> before copying journal files to remote machine.
> Is there any known risk to do this?
>

It's safe enough.

I should have added, in order to ensure that the archive cycle has
finished, it is a good idea to wait a few seconds after issuing the
DM1314 trace point (to give the archiver time to notice and wake up),
and then issue logstat -header commands until ARCHIVE no longer
shows in the status. It's quite possible that the cycle will
already be finished, but if you see ARCHIVE in the status then
the archiver is still doing its thing and you need to wait longer.

Another point, it doesn't matter which database you issue the
DM1314 against, it applies to the whole installation.

Karl

Karl & Betty Schendel escreveu:
>
> On Aug 22, 2008, at 5:43 PM, Oscar Carlés wrote:
>
>> Hi all!
>> I am running Ingres 2.6 sp5 on a Tru64 box.
>> My disaster recovery schema, include a periodic copy (about each 20
>> minutes) of production environment journals to another machine file
>> system.
>> According to mails below, I want to execute trace point DM1314, just
>> before copying journal files to remote machine.
>> Is there any known risk to do this?
>>
>
> It's safe enough.
>
> I should have added, in order to ensure that the archive cycle has
> finished, it is a good idea to wait a few seconds after issuing the
> DM1314 trace point (to give the archiver time to notice and wake up),
> and then issue logstat -header commands until ARCHIVE no longer
> shows in the status. It's quite possible that the cycle will
> already be finished, but if you see ARCHIVE in the status then
> the archiver is still doing its thing and you need to wait longer.
>
> Another point, it doesn't matter which database you issue the
> DM1314 against, it applies to the whole installation.
>
> Karl
>
>

Karl,

The event "DM1314 trace point" is the same as execute an "alterdb mydb
-next_jnl_file" ?

--
Regards,

Thiago Zerbinato
Oracle/Ingres DBA
Ribeirao Preto/SP
Brazil

On Aug 25, 2008, at 3:07 PM, thiagomz wrote:

> Karl & Betty Schendel escreveu:
>>
>> On Aug 22, 2008, at 5:43 PM, Oscar Carlés wrote:
>>>
>>> According to mails below, I want to execute trace point DM1314, just
>>> before copying journal files to remote machine.
>>> Is there any known risk to do this?
>>>
>>
>> It's safe enough.
>>
> Karl,
>
> The event "DM1314 trace point" is the same as execute an "alterdb mydb
> -next_jnl_file" ?

No, it's not quite the same. DM1314 forces the archiver to run
even though a consistency point has not been reached (consistency
points and database close are the two main archiver cycle triggers).
The archiver cycle is run normally and no new journal file is
started unless the size guideline has been reached.

The alterdb -next_jnl_file command forces a new journal file to
start. I think it also forces a journaling cycle, like DM1314,
but I'm not 100% sure of that ... I'd have to take a look
at the code.

Karl