Hi All,

I'm running on II 9.1.1 (a64.lnx/103)NPTL +p13001.

Recently we have found a strange problem with verifydb that looks a lot like bug 115634 or bug 115456, but with some bizarre new twist.

The table has a nullable blob column, over half of which are empty strings.That's 700+ rows.

verifydb complains about only 1 of them. We get messages like:
W_DM5060_NO_ETAB_SEGMENT WARNING: Segment number 1 in extension tablewith index 491 was not found when looking for extension segments for peripheral data-type in field monitor_comment for record with Tuple ID 67589.
....
W_DM505F_TOO_MANY_BAD_SEGS WARNING: Verifydb was unable to find a peripheral segment that matches the current coupon after more than 491 tries, checking on this coupon will be terminated, and verifydb will skip to the next coupon.

In that particular case we can update the field to be null, the verifydb runs clean.
update the field to be the string '~' and the verifydb runs clean.
Return the field to the original value of ''...and the verifydb again showsthis one record in trouble.

This is unlike the workaround for the known bugs.

When we check with hex(blob_column) we find that the errant row is the onlyone like:
0100000000000000000000000000000100000000BF63000000 00000000000000

The BF63 refers to the associated iietab table.

Typically for the non reported rows where the nullable blob is an enpty string the data looks like:
01000000000000000000000001000000000000000000000000 00000000000000

No matter what we do to the errant rows data it always returns a pointer tothe iietab table ... and only for this one row.

Ideas?

Martin Bowes

On Aug 2, 2010, at 8:11 AM, Martin Bowes wrote:

I'd say this is mostly a verifydb bug, although whatever the dbms server is doing
isn't helping.

Blob coupons have an embedded length (the 2nd and 3rd i4's in the coupon).
When the length is zero, there is no need to store anything in an etab, so the
etab ID is irrelevant. It's supposed to be zero, but the DBMS server is leaving
it nonzero for some reason. (I would guess failure to properly initialize
a coupon either in the sequencer or in ADF.)

Verifydb shouldn't be looking at the etab stuff if the length is zero.
At worst, I could see verifydb complaining about a nonzero etab when
the length is zero, but it would be a low severity warning. So
what verifydb is doing is a bug and should have an issue raised.

10.0 is a lot more careful about coupon handling on the server side, so
I would hope that it wouldn't happen in 10.0. Verifydb would have the
same problem in 10.0 if it were to see the same dirty coupon.

Karl

Hi Karl,

I can only replicate the problem by doing a checkpoint restore. I've transferred the database to a 9.2.0 platform using that technique, verified that the verifydb problem is still present and I am now upgrading that installation to 10.0.0.

I'll let you know what happens when this completes.

Marty

-----Original Message-----
From: Karl Schendel [mailto:schendel (AT) kbcomputer (DOT) com]
Sent: 02 August 2010 13:29
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] empty nullable string and long varchar


On Aug 2, 2010, at 8:11 AM, Martin Bowes wrote:

I'd say this is mostly a verifydb bug, although whatever the dbms server is doing
isn't helping.

Blob coupons have an embedded length (the 2nd and 3rd i4's in the coupon).
When the length is zero, there is no need to store anything in an etab, so the
etab ID is irrelevant. It's supposed to be zero, but the DBMS server is leaving
it nonzero for some reason. (I would guess failure to properly initialize
a coupon either in the sequencer or in ADF.)

Verifydb shouldn't be looking at the etab stuff if the length is zero.
At worst, I could see verifydb complaining about a nonzero etab when
the length is zero, but it would be a low severity warning. So
what verifydb is doing is a bug and should have an issue raised.

10.0 is a lot more careful about coupon handling on the server side, so
I would hope that it wouldn't happen in 10.0. Verifydb would have the
same problem in 10.0 if it were to see the same dirty coupon.

Karl



_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres

Hi Karl,

Yep it appears to be OK in 10.

Marty

-----Original Message-----
From: Martin Bowes [mailto:martin.bowes (AT) ctsu (DOT) ox.ac.uk]
Sent: 02 August 2010 14:59
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] empty nullable string and long varchar

Hi Karl,

I can only replicate the problem by doing a checkpoint restore. I've transferred the database to a 9.2.0 platform using that technique, verified that the verifydb problem is still present and I am now upgrading that installation to 10.0.0.

I'll let you know what happens when this completes.

Marty

-----Original Message-----
From: Karl Schendel [mailto:schendel (AT) kbcomputer (DOT) com]
Sent: 02 August 2010 13:29
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] empty nullable string and long varchar


On Aug 2, 2010, at 8:11 AM, Martin Bowes wrote:

I'd say this is mostly a verifydb bug, although whatever the dbms server is doing
isn't helping.

Blob coupons have an embedded length (the 2nd and 3rd i4's in the coupon).
When the length is zero, there is no need to store anything in an etab, so the
etab ID is irrelevant. It's supposed to be zero, but the DBMS server is leaving
it nonzero for some reason. (I would guess failure to properly initialize
a coupon either in the sequencer or in ADF.)

Verifydb shouldn't be looking at the etab stuff if the length is zero.
At worst, I could see verifydb complaining about a nonzero etab when
the length is zero, but it would be a low severity warning. So
what verifydb is doing is a bug and should have an issue raised.

10.0 is a lot more careful about coupon handling on the server side, so
I would hope that it wouldn't happen in 10.0. Verifydb would have the
same problem in 10.0 if it were to see the same dirty coupon.

Karl



_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres


_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres