IDS 7.23UC6 Chunk Down! Help request

Could someone please help. Our chunk is down? Someone accidentally removed the link to the informix chunk? We've restored it but this did not solve the problem. What does bring the chunk online again? Im also getting informix assertions. What do those mean? Do I have to restore our level 0 backup? Thanks ditmar Logfile (part of...) Fri Jun 18 03:00:03 1999 03:00:03 Event alarms enabled. ALARMPROG = '/var/informix/no_log.sh' 03:00:09 DR: DRAUTO is 0 (Off) 03:00:09 INFORMIX-OnLine Initialized -- Shared Memory Initialized. 03:00:09 Physical Recovery Complete: 0 Pages Restored. 03:00:09 Logical Recovery Started. 03:00:12 Logical Recovery Complete. 0 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks 03:00:12 Dataskip is now OFF for all dbspaces 03:00:15 On-Line Mode 03:00:15 Checkpoint Completed: duration was 0 seconds. 03:22:05 Checkpoint Completed: duration was 6 seconds. 03:41:05 Logical Log 3616 Complete. 03:41:08 Logical Log 3616 - Backup Started "Logical Log 3616 Complete."nformix/ 03:41:23 Logical Log 3616 - Backup Completed 03:43:49 Checkpoint Completed:l duration was 0 seconds.g 3616 - BackupComplete 04:03:50 dynamically allocated new shared memory segment (size 8388608) 12:06:52 Checkpoint Completed: duration was 2 seconds. 12:25:32 Checkpoint Completed: duration was 0 seconds. 12:25:32 Level 0 Archive started on b5rootdbs, b5plogdbs, b5llogdbs, b5datdbs,b5idx1dbs 12:47:18 Checkpoint Completed: duration was 1 seconds. 12:48:17 dynamically allocated new shared memory segment (size 8388608) 13:00:17 dynamically allocated new shared memory segment (size 8388608)ted.6:48 Archive on b5rootdbs, b5plogdbs, b5llogdbs, b5datdbs, b5idx1dbs Comple 5idx1dbsh 2 16 "Archive completed: 'b5rootdbs, b5plogdbs, b5llogdbs, b5datdbs, b 13:06:51 Checkpoint Completed: duration was 2 seconds. 18:11:46 Checkpoint Completed: duration was 0 seconds. 18:58:48 INFORMIX-OnLine Stopped.Fri Jun 18 19:09:31 1999 19:09:31 Event alarms enabled. ALARMPROG = '/var/informix/no_log.sh' 19:09:37 DR: DRAUTO is 0 (Off) 19:09:37 Cannot Open Primary Chunk '/dev/raw_links/b5dat1dbs', errno = 2 19:09:37 INFORMIX-OnLine Initialized -- Shared Memory Initialized. 19:09:37 Physical Recovery Started. 19:09:37 Assert Failed: WARNING! pthdrpage:ptalloc:bad bfget 19:09:37 Who: Session(5, root@majestix, 0, -972380724) Thread(14, fast_rec, c6087558, 1) 19:09:37 Results: Cannot use TBLSpace page for TBLSpace 5242881 19:09:37 Action: Run 'oncheck -pt 5242881' 19:09:37 See Also: /tmp/af.e7d51 19:09:38 Message 19293 not found. 19:09:38 Physical Recovery Complete: 0 Pages Restored. 19:09:38 Logical Recovery Started. 19:09:38 Process exited with return code 127: /bin/sh /bin/sh -c /var/informix/ no_log.sh 3 11 "Cannot open Chunk: '/dev/raw_links/b5dat1dbs'." "Cannot OpenPri mary Chu Process exited with return code 127: /bin/sh /bin/sh -c /var/informix/ no_log.sh 3 1 "Table failure: 'TBLSpace 5242881'." "pthdrpage:ptalloc:bad bfget" Assertion FailedTBLSpace header c61de450: 00000000 00000000 c6084c48 00500001 ........ ..LH.P.. c61de460: 00000000 00500004 00000000 00000001 .....P.. ........ c61de470: c60842f8 00000004 00000000 c60cf458 ..B..... .......X c61de480: 62357465 6d706462 73202020 20202020 b5tempdb s c61de490: 20200069 6e666f72 6d697800 54424c53 .infor mix.TBLS c61de4a0: 70616365 20202020 20202020 20200000 pace .. c61de4b0: 20202020 20202020 20202020 20202020 c61de4c0: 20202020 20202020 20202020 20202000 . c61de4d0: 00000000 00000000 c2ca94b8 c61de480 ........ ........ c61de4e0: 00000001 00000032 c60844a8 00000004 .......2 ..D..... c61de4f0: 000007ff c2ca9688 7b00b804 7b00b804 ........ {...{... c61de500: 002dae7b 001c3ffb 00000000 00000000 .-.{..?. ........ c61de510: 00000000 00000000 c6084c48 00000032 ........ ..LH...2 c61de520: 00400000 10000000 c60844a8 00000004 .@...... ..D..... c61de530: 000007ff c0cfa800 00004420 c6084c48 ........ ..D ..LH c61de540: c0cf0c20 00000001 00000000 c6085780 ... .... ......W. c61de550: 00000000 00000000 00000008 c0cec800 ........ ........ c61de560: 1a809d8b .... 19:09:37 19:09:37 Assert Failed: WARNING! pthdrpage:ptalloc:bad bfget 19:09:37 Who: Session(5, root@majestix, 0, -972380724) 19:09:37 Action: Run 'oncheck -pt 5242881' 19:09:37 See Also: /tmp/af.e7d51 19:09:37 Stack for thread: 14 fast_rec base: 0xc61de018 len: 36864 pc: 0x00000000 tos: 0xc61def70 ( 0) 0x002f2dd8 afstack + 0xf0 [/var/informix/bin/oninit] ( 1) 0x002f25a4 mt_affail + 0x314 [/var/informix/bin/oninit] ( 2) 0x002f27dc mt_afwarn + 0xa4 [/var/informix/bin/oninit] ( 3) 0x001dcba8 rsam_afwarn + 0x18 [/var/informix/bin/oninit] ( 4) 0x00192d60 pthdrget + 0x578 [/var/informix/bin/oninit] ( 5) 0x001909dc ptalloc + 0x96c [/var/informix/bin/oninit] ( 6) 0x0019750c open_pp + 0xa4 [/var/informix/bin/oninit] ( 7) 0x001a5fe0 physrecover + 0x358 [/var/informix/bin/oninit] ( 8) 0x001a8dc0 fast_recovery + 0x440 [/var/informix/bin/oninit] ( 9) 0x002f3798 startup + 0xa0 [/var/informix/bin/oninit] (10) 0x002ec648 mt_swap_threads + 0xdc [/var/informix/bin/oninit]

Thanks Ditmar

I've read in the newgroup how to bring up the chunk with onspaces (onspaces -s dbspacename -p chunkpath -o chunkoffset -O -y) This helped. Thanks, but how can I test the database integrity? Help is greatly appreciated, Greetings Ditmar

dde@bart.nl wrote: > > I've read in the newgroup how to bring up the chunk with onspaces > (onspaces -s dbspacename -p chunkpath -o chunkoffset -O -y) > > This helped. Thanks, but how can I test the database integrity? The direct answer is: oncheck -cDI database:tablename The integrity of the data on that chunk(s) will depend on why the chunk was marked offline, when it happened, and what data should have been updated on the chunk that was not. If your engine took itself offline immediately after the chunk was marked down there should be no damage, only a few seconds of lost transactions but everything will be consistent. Same thing if the engine was configured to freeze when the chunk went down. If, on the third hand, you had the engine set to continue then you MAY have some corruption. Oncheck can detect the problem and correct many inconsistencies. However, if oncheck detects a bad index, drop and recreate it in dbaccess, oncheck does not use parallel index building code and so is very slow. Art S. Kagel