Re: online crash

rswa@perth.DIALix.oz.au (Radio Spares) wrote: >Dear All, >I have come across this problem with online 7.10.UC1 on a Spacr 5 running >Solaris 2.4. I have a cursor that does a count on 1 table with a where cause >of 1 = 1. The count works but when the cursor is closed it brings the >engine down (see online log below). >This program worked fine on version 5 of informix and the problem has only >happened since the upgrade. I have test 100's of other programs on the new >engine and they all work fine. It just appears to be this one. >The RDS is 6.01.UD3. I have contacted informix support and they are working on >this but if anyone else knows of this problem and how to fix it I would >appreciate the help. >Also I have installed the patches listed in the machine notes for >this release biut they have made no difference to this problem. >TIA >Jason Harris (RSWA) >--Excerpt from online.log >09:10:43 INFORMIX-OnLine Initialized -- Shared Memory Initialized. >09:10:44 Physical Recovery Started. >09:10:44 Physical Recovery Complete: 0 Pages Restored. >09:10:44 Logical Recovery Started. >09:10:44 Logical Recovery allocating 10 worker threads ('OFF_RECVRY_THREADS'). >09:10:48 Logical Recovery Complete.> 0 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks >09:10:49 Dataskip is now OFF for all dbspaces >09:10:49 Quiescent Mode >09:10:49 Checkpoint Completed: duration was 0 seconds. >09:10:52 On-Line Mode >09:11:53 Assert Failed: Internal Error - Segmentation Violation >09:11:53 Who: Session(9, jasonh@rsdev, 557, 6) > Thread(74, scan_10.0, a03b380, 1) >09:11:53 Results: OnLine must abort >09:11:53 Action: Reinitialize shared memory >09:11:53 See Also: /tmp/af.37fead, shmem.37fead.0 >09:12:05 rsdebug.c, line 3557, thread 74, proc id 542, Segmentation Violation. >09:12:05 PANIC: Attempting to bring system down >-- end of excerpt I can't be sure (I am at home) but I think your error is similar to one I received several weeks ago. Anyhow it is worth a check. PDQ in UC1 is buggy. If you have it turned on then it's a good idea to turn it off by setting PDQ priority to zero in onmonitor. Symtoms of the problem are - Shared memory not being freed up nicely and lots more shared memory than you would expect being used up. onstat -g seg shows segments holding 3 or 4 pages open even when noone is connected. For a period of time I was rolling online every morning to clean up shared memory Setting PDQ to zero has meant a hugely smaller signature in shared memory and the system runniing clean as a whistle. I am told the fix is in UD1 but I am holding out until 7.2 (next month?) as it is not a problem for us performance-wise. HTH Peter Tashkoff Auckland, New Zealand e-mail ptash@iconz.co.nz