Re: Blocked:CKPT

Hi David, Well, I am following your piece of advice. I change user connection from SHM to TCP. I have another question. When ONDBSPACEDOWN=1 and engine blocked on CKPT, what is the effect of onmode -O? TIA, David... P.S.: this is not an exclusive David's chat (Dave Williams, Kosenko and I). Other people may participate ;-) ----- Message d'origine ----- De : David Williams <djw@smooth1.demon.co.uk> ' : <informix-list@iiug.org> Envoi' : mardi 9 f'vrier 1999 01:02 Objet : Re: Blocked:CKPT In article <79mdfk$nua$1@news.xmission.com>, David Andrieu <dandrieu@mail.atmel.fr> writes > >Hi David, > > I think you ar rigt. I changed ONDBSPACEDOWN and set it >to 1 (ABORT). However, all my dbspaces are HPUX-mirrored. >So I don't understand why an I/O error could occur. On an other >server, the dbspaces are informix-mirrored and it seems more >reliable. Now, I'm going to wait for the next I/O error in >order to see which disk is bad. >I notice I have this problem since someone modified a C library >in our application (mainly written in MF Cobol). I applied this >morning the path PHSS_15389 (millicode library milli.a). Do you >think if it is possible that there is a link between C libraries >corrupted and Informix problems? > >David... > If you are using a shared memory connection then your program could potentially access the engines shared memory and corrupt it! Try using TCP loopback connections instead.. > > > > >----- Message d'origine ----- >De : David Kosenko <davek@summitdata.com> >' : <informix-list@iiug.org> >Envoi' : jeudi 4 f'vrier 1999 20:25 >Objet : Re: Blocked:CKPT > > >On Wed, 03 Feb 1999 08:26:55 +0100, David Andrieu ><dandrieu@mail.atmel.fr> wrote: >> but I don't have messages in message.log like: >> >> Assert Failed: Chunk ... is being taken OFFLINE. >> Who: ... >> Result: ... >> Action: ... >> See Also: ...>> >>which occur when online tries to put a dbspace down. >>Or maybe it is a bug in 7.30.UC6. This message does not appear >>while online tries to put a dbspace down? > >No, because ONDBSPACEDOWN=2 will not mark the chunk as down - that is >the whole point behind this option. It is meant for cases where a >disk becomes temporarily unavailable (say because a SCSI cable got >unplugged). In that case, marking the chunk as down would require a >restore to recover it, even if the disk isn't really bad. A value of >2 (WAIT) means don't mark it as down, keep polling the device (in case >it becomes available again), and at the next checkpoint, block all >activity (the symptom originally reported). This is a very bad option >if your chunk really does go down - much better to either let the >server go down or markthe chunk as down and keep the server up, but >not block at the next checkpoint. > >Dave > > > -- David Williams