ISAM 105 error
Hi All,
We have had HCL working on a bad page issue in one of our instances.
Throughout the process, they have logged in and made changes to pages in a
dbspace.
Yesterday, we started experiencing issues where we could no longer retrieve
information written to the database. NOTE: it is an image database, stored in
blobspace.
The corruption is on very old records, not anywhere near where new records
would be written. So it is fathomable that the HCL changes made might be the
cause, but I'm wondering if it might be something else that someone has run
across.... or at least if someone knows more ways to verify how the problem
occurred or how to fix it.
Here is the gist:
Informix 12.10.FC4 on Solaris 10
Trying to create an index on the integer field in a table structured:
create table img_mag_table
(
img_mag_serial_id integer,
img_mag_image byte in ucc2dobjs,
img_mag_image100 byte in ucc2dobjs,
img_mag_image200 byte in ucc2dobjs,
img_mag_image_ur byte in ucc2dobjs
);
The error:
create index mag_sn_idx on img_mag_table(img_mag_serial_id);
212: Cannot add index.
105: ISAM error: bad isam file format.
From the log:
14:27:40 Maximum server connections 4
14:27:40 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0,
Pl og used 16, Llog used 4
14:37:07 Assert Failed: Page Check Error in next_scan:bad data page
14:37:07 IBM Informix Dynamic Server Version 12.10.FC4
14:37:07 Who: Session(121, informix@devdata2, 12776, 10ef3b158)
Thread(1523, xchg_3.0, 10ef04128, 1)
File: rsdebug.c Line: 1116
14:37:07 Results: Possible inconsistencies in 'ucc2:"informix".img_mag_table'
14:37:07 Action: Run 'oncheck -cD 5242930'
14:37:07 stack trace for pid 1909 written to
/soft/prodinformix/foghorn/tmp/af.9 db8773
14:37:07 See Also: /soft/prodinformix/foghorn/tmp/af.9db8773, shmem.9db8773.0
14:37:25 Page Check Error in next_scan:bad data page
14:37:40 Checkpoint Completed: duration was 0 seconds.
14:37:40 Tue Jun 20 - loguniq 51784, logpos 0x1cd20fc, timestamp: 0x537910d
Inte rval: 739472
14:37:40 Maximum server connections 4
14:37:40 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0,
Pl og used 40, Llog used 26
Running oncheck -cDI ucc2:img_mag_table does not fix the problem.
oncheck -cD 5242930 is the same thing, as seen by systables:
tabname img_mag_table
owner informix
partnum 5242930
nrows 6300518.000000
ustlowts 2017-06-18 01:12:05.00000
Any clues? Could this NOT be related to the work HCL was doing? I know there
is vagueness about that work, just wondering if anyone has seen something
similar *without* people mucking around with the internals of the chunk pages.
Thanks Much,
Michael Hoffman
Hi,
The device which contains the bad page, it is on a raw disk or some kind of
filesystem volume, if so, which type of filesystem?
Are there any messages in the OS logs?
When was a oncheck last run on the affected object?
Have you tried running:
oncheck -cR
oncheck -cc
oncheck -ce
to check everything before the server accesses that object is fine??
It could be a storage issue on an Informix bug (they do happen). We would need
to know more about this particular environment to be able to comment.
Regards,
David.
> On 20 June 2017 at 21:51 MICHAEL HOFFMAN <offdisc@gmail.com> wrote:
>
>
> Hi All,
> We have had HCL working on a bad page issue in one of our instances.
> Throughout the process, they have logged in and made changes to pages in a
> dbspace.
>
> Yesterday, we started experiencing issues where we could no longer retrieve
> information written to the database. NOTE: it is an image database, stored in
> blobspace.
>
> The corruption is on very old records, not anywhere near where new records
> would be written. So it is fathomable that the HCL changes made might be the
> cause, but I'm wondering if it might be something else that someone has run
> across.... or at least if someone knows more ways to verify how the problem
> occurred or how to fix it.
>
> Here is the gist:
> Informix 12.10.FC4 on Solaris 10
>
> Trying to create an index on the integer field in a table structured:
> create table img_mag_table
> (>
> img_mag_serial_id integer,
>
> img_mag_image byte in ucc2dobjs,
>
> img_mag_image100 byte in ucc2dobjs,
>
> img_mag_image200 byte in ucc2dobjs,
>
> img_mag_image_ur byte in ucc2dobjs
> );
>
> The error:
> create index mag_sn_idx on img_mag_table(img_mag_serial_id);>
> 212: Cannot add index.>
> 105: ISAM error: bad isam file format.>
> >From the log:
> 14:27:40 Maximum server connections 4
> 14:27:40 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0,
> Pl og used 16, Llog used 4
>
> 14:37:07 Assert Failed: Page Check Error in next_scan:bad data page
> 14:37:07 IBM Informix Dynamic Server Version 12.10.FC4
> 14:37:07 Who: Session(121, informix@devdata2, 12776, 10ef3b158)
>
> Thread(1523, xchg_3.0, 10ef04128, 1)
>
> File: rsdebug.c Line: 1116
> 14:37:07 Results: Possible inconsistencies in 'ucc2:"informix".img_mag_table'
> 14:37:07 Action: Run 'oncheck -cD 5242930'
> 14:37:07 stack trace for pid 1909 written to
> /soft/prodinformix/foghorn/tmp/af.9 db8773
> 14:37:07 See Also: /soft/prodinformix/foghorn/tmp/af.9db8773, shmem.9db8773.0
> 14:37:25 Page Check Error in next_scan:bad data page
> 14:37:40 Checkpoint Completed: duration was 0 seconds.
> 14:37:40 Tue Jun 20 - loguniq 51784, logpos 0x1cd20fc, timestamp: 0x537910d
> Inte rval: 739472
>
> 14:37:40 Maximum server connections 4
> 14:37:40 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0,
> Pl og used 40, Llog used 26
>
> Running oncheck -cDI ucc2:img_mag_table does not fix the problem.
> oncheck -cD 5242930 is the same thing, as seen by systables:>
> tabname img_mag_table
> owner informix
> partnum 5242930
> nrows 6300518.000000
> ustlowts 2017-06-18 01:12:05.00000
>
> Any clues? Could this NOT be related to the work HCL was doing? I know there
> is vagueness about that work, just wondering if anyone has seen something
> similar *without* people mucking around with the internals of the chunk
pages.
>
> Thanks Much,
> Michael Hoffman
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
Hi David,
raw device. (Always raw devices! ;-) )
On a Sparc Solaris 10 server.
The oncheck -cDI was run right after the error. But we've been running them on
that table for the past three weeks during the HCL corrections.
The other onchecks have the possibility of crashing the system, especially
-ce, so I don't run them. I will try -cc tomorrow since that shouldn't hit the
bad pages on the problem chunk.
Thanks,
Michael
Perhaps, try:create index mag_sn_idx on img_mag_table(img_mag_serial_id) in
<aparticularidxdbspace>;
-- without specifying an index dbspace, the new index will go to the dbspace
where the table is created and which is being full or is NOT big enough ...?
-- if the above doesn't work, save data, then drop recreate the table?
finderr 212
-212 Cannot add index.
This statement attempts to add an index, either explicitly with CREATE
INDEX or implicitly as part of processing a SELECT on multiple
unindexed tables. In any case, some error prevents the index from being
created. For more information, check the accompanying ISAM error code.
Insufficient disk space is a common cause of this problem.
Let's go GreenThis email contains 100% recycled electrons.
From: MICHAEL HOFFMAN <offdisc@gmail.com>
To: ids@iiug.org
Sent: Tuesday, June 20, 2017 7:32 PM
Subject: Re: ISAM 105 error [39410]
Hi David,
raw device. (Always raw devices! ;-) )
On a Sparc Solaris 10 server.
The oncheck -cDI was run right after the error. But we've been running them on
that table for the past three weeks during the HCL corrections.
The other onchecks have the possibility of crashing the system, especially
-ce, so I don't run them. I will try -cc tomorrow since that shouldn't hit the
bad pages on the problem chunk.
Thanks,
Michael
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.