Re: ER /checksum failures
The cdr utility is an ESQL/C program and is subject to the issues that =
any
client program can encounter - locked resources is one of those things.=
While most of the activity that "cdr check" does is reading, when it
encounters an inconsistancy, then it will try to push that row through =
the
system. That in turn can cause the deadlock problem because it means t=
hat
we're going to have to do some updating.
I would suggest opening a case with tech support on the locked resource=
problem. We could probably do some work to make it so that the tool wa=
s a
bit more robust in such cases.
On the core file. I chose to force a segv when ever the tool encounter=
ed a
logic problem. That way if the tool was used as a background job, at l=
east
we'd have a core file if things got crazy. Again - I'd open a case. W=
e
might want to use a debugger or 'adb' on the core file to see what the
problem was. Also, it'd help to have the schema definition of the tabl=
e.
The error that you got indicates that we had some difficulty in determi=
ning
the primary key, but I would have expected to also see an SQL error as =
part
of the message.
Now to get to what I think that you want to do - which is to ensure
consistancy.
Be aware that unless there is no activity on the system, then there wi=
ll
be changes in flight which can make it appear that there is inconsistan=
cy
where there is not, it's just that the rows are in flight. One thing t=
hat
you might want to do is to run "cdr check -v" which will display the
primary keys of the rows which are currently inconsistant (which could
easily be simply in-flight.) From the primary keys you could manually =
push
those rows through the system by performing a dummy update.
M.P.
=
jpierrot@chubb.co =
m =
=
To
11/17/2006 09:43 ids@iiug.org =
AM =
cc
Madison Pruet/Dallas/IBM@IBMUS =
Subj=
ect
ER /checksum failures =
=
=
=
=
=
=
Checksum is producing the FOLLOWING errors below, does anyone have any =
idea
why it is happening?
Of the 92 replicates 7 fail to work with checksum.
3 fail with "ISAM error: deadlock detected" when running in repair mode=
(-R).
These same 3 work just fine when run in check only mode.
4 fail with "Memory fault(coredump)"
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Informix Version
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IBM Informix Dynamic Server Version 10.00.UC4
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Server
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
AIX 5.2 32 bit
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
For the 3 that fail with "deadlock error"
here is an example of running check sum in check only mode
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
$ time cdr check repl --all -m g_toltp -r chb_legacy_rel
------ Statistics for chb_legacy_rel ------
Node Rows Extra Missing Mismatch Processed
---------------- --------- --------- --------- --------- ---------
g_toltp 1542937 0 0 0 0
g_trptg 1542958 25 4 89 0
WARNING: replicate is not in sync
real 15m35.95s
user 0m17.90s
sys 0m1.37s
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
For the 3 that fail with "deadlock error"
here is an example of running check sum in repair mode
Notice how long before failure. Almost at the end.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
$ time cdr check repl -R --all -m g_toltp -r chb_legacy_rel
------ Statistics for chb_legacy_rel ------
ERROR Code -243 Isam -143 File replcheck.ec Line 4429
fetch of cur_2632
Could not position within a table (%s).
ISAM error: deadlock detected
real 15m14.39s
user 0m17.15s
sys 0m1.83s
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
for the 4 that core dump
here is an example of running check sum in check only mode
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
$ time cdr check repl --all -m g_toltp -r quote_cvg
Error at line:4273 - Select index parts for sysadm.quote_cvg
***ABORTING***
repl-check.ksh[3]: 175450 Memory fault(coredump)
=