Re: Logging error: Assert failed !!!
Posted in 1996
In article <52tovo$ah1@omis001.omnitel.it>, Matteo Prinetti
<Matteo.Prinetti@omnitel.it> writes
>I'm plagued with following problem:
>
>(DEC OSF 3.2A , Informix 7.1.2UC1 Online Dynamic Server)
>
>I have 200.000 locks defined. When i try a transcation that
>takes all the locks (example: delete from x - x contains
>more than 200.000 records) the db shut down and cannot
>recover anymore (olnly using the tbzero utility i can
>restore the db).
>The dump message is:
>
>========== START ============
>Sat Sep 28 10:18:40 1996
>10:17:56 logread: page doesn't match loguniq 1005 or pagenum 834
>10:17:56 pg_uniqid = 941, pg_number = 834>page header
>05c77000: 11c91100 e5a73c03 00000001 fc070000 ......<. ........
>05c77010: ad030000 42030000 ....B...
>10:17:56 logread: cannot read loguniq 1005 logpos 0x3426dc
>10:17:56 logerr('logread')
>10:17:56 tx 0x945e6f0, tx_flags 0x92403
>10:17:56 tx_loguniq 1005, tx_logpos 0x3426dc
>10:17:56
>10:17:56 Assert Failed: Logical Logging error for 'HDELETE' in>'logread'
>10:17:56 Who:Session(454, fds@omid018.omnitel.it, 2327, 155576048)
> Thread(1261, sqlexec, 942fce0, 3)
>10:17:56 Results: OnLine must abort
>10:17:56 Action: Reinitialize shared memory
>10:17:56 See Also: /usr/users/fds/FDS_DATA/dbtmp/af.4eddf33
>10:17:56 Stack for thread: 1261 sqlexec>
> base: 0x000000000afc07a0
> len: 525312
> pc: 0x000000012037f870
> tos: 0x000000000b0402f8
>
>0x0000000000000000 ***unknown***
>============= END =====
>
>Anyone experienced something with this ?
>
>Matteo Prinetti
>
>
On one your logical logs is corrupted - check your disk layout and
make sure no filesystems are overlapping where the logical logs are
held. Also you should be using raw disk for your online chunks. This
error could occur if you were using cooked files for the dbspace where
the logical logs are kept and you the filesystem used became corrupt.
Even if fsck 'fixed' it the filesystem has probably been incorrectly
fixed. fsck will make the filesystem consistent again but will not make
it the same as before the corruption occured. That is why you should be
suing raw disk.
--
David Williams