E_DM942C_DMPP_ROW_UNCOMP

What can cause uncompression to fail? The *.t00 data files all have
data in them.

E_DM942C_DMPP_ROW_UNCOMP Uncompression of a row has failed.
Database mydb, table ii3b7 pp5-my_table, owner ingres, page 4753,
TID 00252208. Record size 0, uncompressed record size 0.

The log file is full of these messages, and obviously a select returns
no rows.

Thanks

Dennis

d underscore roesler at agilent dot com

Dennis Roesler wrote:
> What can cause uncompression to fail? The *.t00 data files all have
> data in them.
>
> E_DM942C_DMPP_ROW_UNCOMP Uncompression of a row has failed.
> Database mydb, table ii3b7 pp5-my_table, owner ingres, page 4753,
> TID 00252208. Record size 0, uncompressed record size 0.
>
> The log file is full of these messages, and obviously a select returns
> no rows.

VDBA shows 2688502 rows with a table size of 0 K.

d underscore roesler at agilent dot com

On Jun 17, 2008, at 2:32 PM, Dennis Roesler wrote:

> What can cause uncompression to fail? The *.t00 data files all have
> data in them.

I don't think there is any legit reason for uncompression to fail.
It's barely possible that you might be able to sneak garbage
data past the original row compression if you fastload the
table, or if you use RAAT. However since this is obviously
a partitioned table I'd say that neither of those situations
apply.

>
> E_DM942C_DMPP_ROW_UNCOMP Uncompression of a row has failed.
> Database mydb, table ii3b7 pp5-my_table, owner ingres, page 4753,
> TID 00252208. Record size 0, uncompressed record size 0.

Is there any other DMxxxx message?
The zero sizes happen (in dm1c) when the uncompressor or row-converter
return a not-OK status. The only place I can see that happening
for normal (data) uncompression is if the uncompressed row becomes
longer than the supposed uncompressed-row size, which would imply
either a screwed-up row size or broken compressed-row data.
All the other situations appear to issue an additional error that
ought to be logged.

The other way this can happen is if the row is NOT compressed, but
alter table add/drop/alter column is in effect; but the same
comment applies, i.e. if there is no other message it would seem
that the converted row got too big.

>
> The log file is full of these messages, and obviously a select returns
> no rows.

Might be interesting to try DM801 to see if you can get any
non-error rows out of the table.

My guess is that either the catalog row width is broken for some
reason, or the table files have been corrupted in some peculiar way.
(e.g. it's looking at the wrong files, something like that. The
page headers are OK but the row data isn't.)

Karl

Karl & Betty Schendel wrote:
>
> On Jun 17, 2008, at 2:32 PM, Dennis Roesler wrote:
>

>> E_DM942C_DMPP_ROW_UNCOMP Uncompression of a row has failed.
>> Database mydb, table ii3b7 pp5-my_table, owner ingres, page 4753,
>> TID 00252208. Record size 0, uncompressed record size 0.
>
> Is there any other DMxxxx message?
hostname::[55854 , 52da5000]: Tue Jun 17 11:59:57 2008
E_DM9580_CONFIG_DBSERVICE_ERROR An error was detected in the dbservice
flags (131072) for database iidbdb. You may need to run upgradedb to
correct invalid iitree tuples.

hostname::[55854 , 52da5000]: Tue Jun 17 11:59:57 2008
E_DM9580_CONFIG_DBSERVICE_ERROR An error was detected in the dbservice
flags (131072) for database iidbdb. You may need to run upgradedb to
correct invalid iitree tuples.

This was also in the log file. I did try to run a verifydb in report
mode, but I don't remember what time it was that I ran that.

>
> Might be interesting to try DM801 to see if you can get any
> non-error rows out of the table.

Setting this and running a select * returns no rows.

Cheers

Dennis

Dennis Roesler wrote:
> Karl & Betty Schendel wrote:
>>
>> On Jun 17, 2008, at 2:32 PM, Dennis Roesler wrote:
>>
>
>>> E_DM942C_DMPP_ROW_UNCOMP Uncompression of a row has failed.
>>> Database mydb, table ii3b7 pp5-my_table, owner ingres, page 4753,
>>> TID 00252208. Record size 0, uncompressed record size 0.
>>
>> Is there any other DMxxxx message?
> hostname::[55854 , 52da5000]: Tue Jun 17 11:59:57 2008
> E_DM9580_CONFIG_DBSERVICE_ERROR An error was detected in the dbservice
> flags (131072) for database iidbdb. You may need to run upgradedb to
> correct invalid iitree tuples.
>
> hostname::[55854 , 52da5000]: Tue Jun 17 11:59:57 2008
> E_DM9580_CONFIG_DBSERVICE_ERROR An error was detected in the dbservice
> flags (131072) for database iidbdb. You may need to run upgradedb to
> correct invalid iitree tuples.
>
> This was also in the log file. I did try to run a verifydb in report
> mode, but I don't remember what time it was that I ran that.
>

Are these a result of another problem, or indicative of the current problem?

hostname::[55854 , 52da5000]: Tue Jun 17 11:59:57 2008
E_DM9580_CONFIG_DBSERVICE_ERROR An error was detected in the dbservice
flags (131072) for database iidbdb. You may need to run upgradedb to
correct invalid iitree tuples.

hostname::[55854 , 53a1c000]: Tue Jun 17 12:13:58 2008
E_RD0132_QUERY_TREE consistency check - invalid tree node was read in
from catalogs

On Jun 17, 2008, at 4:59 PM, Dennis Roesler wrote:

>
> Are these a result of another problem, or indicative of the current
> problem?
>
> hostname::[55854 , 52da5000]: Tue Jun 17 11:59:57 2008
> E_DM9580_CONFIG_DBSERVICE_ERROR An error was detected in the dbservice
> flags (131072) for database iidbdb. You may need to run upgradedb to
> correct invalid iitree tuples.
>
> hostname::[55854 , 53a1c000]: Tue Jun 17 12:13:58 2008
> E_RD0132_QUERY_TREE consistency check - invalid tree node was
> read in
> from catalogs
>

Probably something different. It looks like a database created
in 32-bit mode is now running in 64-bit mode, or vice versa.
That would affect iitree things (views etc), but as far as I know
doesn't normally affect table data.

It's not impossible that they are related, but I think you'd see
other DMF access messages if they were.

Karl

Karl & Betty Schendel wrote:
>
> On Jun 17, 2008, at 4:59 PM, Dennis Roesler wrote:
>
>>
>> Are these a result of another problem, or indicative of the current
>> problem?
>>
>> hostname::[55854 , 52da5000]: Tue Jun 17 11:59:57 2008
>> E_DM9580_CONFIG_DBSERVICE_ERROR An error was detected in the dbservice
>> flags (131072) for database iidbdb. You may need to run upgradedb to
>> correct invalid iitree tuples.
>>
>> hostname::[55854 , 53a1c000]: Tue Jun 17 12:13:58 2008
>> E_RD0132_QUERY_TREE consistency check - invalid tree node was read in
>> from catalogs
>>
>
> Probably something different. It looks like a database created
> in 32-bit mode is now running in 64-bit mode, or vice versa.
> That would affect iitree things (views etc), but as far as I know
> doesn't normally affect table data.
>
> It's not impossible that they are related, but I think you'd see
> other DMF access messages if they were.

Thanks for the info on this problem. The data was an archive of other
databases and we ended up recreating the tables from their source databases.

Dennis