Hello Marty,

The bug number for this is 122216.



We'll send out some information shortly about a webinar on this topic -
July 22nd looks a probable date (it'll be 2-0 in the Ashes by then! ).

Regards, Mike





From: Michael Flower
Sent: 19 June 2009 15:22
To: 'Martin Bowes'; Ingres and related product discussion forum
Subject: RE: closed journals and incremental rollforwarddb



Hello Marty,

I don't have a bug number yet. When I get one, I'll pass it on.



I agree with your thoughts about -on_error_prompt . It doesn't fit well
in a batch script scenario.

I'm going to give a webinar about the incremental rollforward soon. Hope
you're going to listen.

Regards, Mike



Michael Flower

Director Education Services

Ingres Europe Limited

michael.flower (AT) ingres (DOT) com <mailto:michael.flower (AT) ingres (DOT) com>



From: Martin Bowes [mailto:martin.bowes (AT) ctsu (DOT) ox.ac.uk]
Sent: 19 June 2009 15:14
To: Michael Flower; Ingres and related product discussion forum
Subject: RE: closed journals and incremental rollforwarddb



Hi Mike,



That IUA presentation you gave couldn't have come at a better time. I'd
been waiting to get my grubby little paws on 9.2.0 for the incremental
.... and had it on my list O'things to do.



It'd be really sweet if this could be solved properly as you indicate.
Do you have a bug number I can track?



One of the problems I expect to face is that I'm will be doing this on
very large databases, things with checkpoint tar files of at least
500+G. I don't want to have to flop those on the network if I can avoid
it. Furthermore, my next item on the List O'things is to implement fast
backups using the SAN snapshot technique. So I wont have an actual
checkpoint tar file in most cases. More hacking of cktmpl.def is on the
way!



The -on_error_prompt sounds like what I need for the moment...although
I'm trying to run this as a batch program so I can see some extra
jiggery-pokery coming on there too.



Marty



From: Michael Flower [mailto:Michael.Flower (AT) ingres (DOT) com]
Sent: 19 June 2009 15:04
To: Martin Bowes; Ingres and related product discussion forum
Subject: RE: closed journals and incremental rollforwarddb



Hello Marty,

Glad that the IUA presentation gave you lots of inspiration!



A source journal is not 'closed' by a ckpdb in a manner that the
-incremental feature can detect.



I raised this point internally (a week before my IUA presentation).
There should be the ability to incrementally rollforward through all
journals (regardless of missing intermittent checkpoints). It's
currently being investigated.



A workaround is to use the flag -on_error_prompt

This will provide you with the ability to rollforward a non-closed
Journal. Not ideal, but it should save you having to copy across all the
files from the new checkpoint.



Regards, Mike





From: Martin Bowes [mailto:martin.bowes (AT) ctsu (DOT) ox.ac.uk]
Sent: 19 June 2009 14:41
To: Ingres and related product discussion forum
Cc: Michael Flower
Subject: closed journals and incremental rollforwarddb



Hi All,



I've just started tinkering with the incremental rollforwarddb in
9.2.0...and gee its sweet!



But...when is a source journal closed off?



I'm currently running alterdb -next_jnl_file on the source database
before transferring journals to my target host.

All of which seems cool. It closes the current journal and starts a new
one, the incremental rollforwarddb then proceeds as expected straight
out of the box with no tinkering.



But when I ckpdb the source database, run the journal transfer and try
an incremental rollforwarddb on the target it barfs at the journal
before the checkpoint, complaining that it is not closed. Subsequent
journal transfers and incrementals stall at this journal and refuse to
go past this point.



Surely the checkpoint would close the journal regardless of whether it
was an online/ofline checkpoint?



So my attempts at an incremental rollforwarddb stop as soon as I
checkpoint the source database. I have to restart the process from
scratch.



Comments from anyone?



Martin Bowes