Hi Karl,

Hey remember I said that I'd try the 'brute force and bloody ignorance approach' to editing the location paths embedded into the journal files...

So close and yet so far....

It appears that some of the paths are split. Just some, not all.

Here is a snippet from an 'od' on a journal file:
5640740 000 000 000 000 000 060 000 000 000 057 163 141 156 057 144 142
\0 \0 \0 \0 \0 0 \0 \0 \0 / s a n / d b
5640760 144 141 164 141 061 057 111 111 057 151 156 147 162 145 163 057
d a t a 1 / I I / i n g r e s /
5641000 001 000 001 000 143 160 137 143 165 162 141 137 154 151 166 145
001 \0 001 \0 c p _ c u r a _ l i v e
5641020 040 040 040 040 040 040 040 040 040 040 040 040 040 040 040 040
5641040 040 040 040 040 136 000 000 000 170 103 000 000 253 000 000 000
^ \0 \0 \0 x C \0 \0 253 \0 \0 \0
5641060 000 100 000 000 305 000 000 000 144 141 164 141 057 144 145 146
\0 @ \0 \0 305 \0 \0 \0 d a t a / d e f
5641100 141 165 154 164 057 143 160 137 143 165 162 141 137 154 151 166
a u l t / c p _ c u r a _ l i v
5641120 145 040 040 040 040 040 040 040 040 040 040 040 040 040 040 040
e

So my attempt to find and alter the paths /san/dbdata1/II/ingres/data/default/cp_cura_live didn't quite succeed.

Back to the drawing board.

Marty

Hi Karl,

Its caused by a sysmod.

For some reason I am yet to fathom the system is busy doing Fcreates and Frenames and they are coming along with the format I expect ... and then one splits the location path string .... and then its back to normal for the rest.

What should be easy is never easy. The good news is that I can replicate this on an empty database and not the 360G monster I've been playing with to develop the code.

Marty

-----Original Message-----
From: Karl Schendel [mailto:schendel (AT) kbcomputer (DOT) com]
Sent: 30 November 2011 12:21
To: Martin Bowes
Subject: Re: [Info-Ingres] Recovery via edited configuration file


On Nov 30, 2011, at 6:59 AM, Martin Bowes wrote:

I'd be very curious to know what exactly that is, and whether it's a single log
record or two. I can't offhand think of any log record that has the path split
into the prefix and remainder.

Karl

Hi Karl et al,

Try this...
createdb bowtest
ckpdb +j bowtest
sysmod bowtest

cd to the databases journal area...
strings j0000001.jnl | grep dbdata | awk '{print $1}' | sort | uniq -c
410 /dbdata1/II/ingres/data/default/bowtest

So after the first sysmod all the paths are OK ... no splits.

Do another sysmod
strings j0000001.jnl | grep dbdata | awk '{print $1}' | sort | uniq -c
1 /dbdata1/II/ingres/data/default/
810 /dbdata1/II/ingres/data/default/bowtest

So we now have 1 split path.

Do a third sysmod....
strings j0000001.jnl | grep dbdata | awk '{print $1}' | sort | uniq -c
1 /dbdata1/II/ingres/data/default/
1 /dbdata1/II/ingres/data/default/b
1210 /dbdata1/II/ingres/data/default/bowtest

So we have two split paths...and they've split differently.

It looks like the brute force option is not going to fly.

Marty


-----Original Message-----
From: Karl Schendel [mailto:schendel (AT) kbcomputer (DOT) com]
Sent: 30 November 2011 16:01
To: Martin Bowes
Subject: Re: [Info-Ingres] Recovery via edited configuration file

Hi Marty,

It might be a RAWDATA record used for outputting partitioning info. Are there partitioned
tables in your empty database? or are you saying that you can do createdb, ckpdb +j, sysmod,
and then this stuff happens?

Karl


On Nov 30, 2011, at 10:12 AM, Martin Bowes wrote:

Hi Karl,

I had a suspicion that it may be a log block boundary.

I'm going to test a recovery on a database which has had no sysmod on it and see if rollforwarddb can cope.

Given that rollforwarddb can read the journals then I suspect the way to go forward here is to alter rollforwarddb to have a path swapping ability.

To which my response is 'Holy snapping duck shit'.

Marty

-----Original Message-----
From: Karl Schendel [mailto:schendel (AT) kbcomputer (DOT) com]
Sent: 01 December 2011 13:30
To: Martin Bowes
Subject: Re: [Info-Ingres] Recovery via edited configuration file

I think you're running into log splits of some sort. I've
never bothered to look into how the archiver copies log
records into the journal, but if it just copies blocks en masse,
it would be easy enough to get a log split. In any case,
you're right, this makes the notion of a brute force journal
fix-up a non starter; you'd need to write a program that
actually reads the journals as if it were rollforwarddb,
fixing up the relevant log records and rewriting back
into a revised journal. Not too hard if one were to start
with bits and pieces of dmfrfp.c and dmf/dmve, but not a
one-day project either.

The full paths really need to go.

Karl

On Dec 1, 2011, at 5:43 AM, Martin Bowes wrote: