Sick server session

IDS 9.21 on Red Hat My client's database session is really not too well. The database server will not accept memory-type operations, such as onmode -k or onstat -F. There are also no oninit proceses running. An onstat -g seg shows single segments, but an ipcs -m shows multiple ones. In most other respects the server is OK, although it is the primary in an Enterprise Replication pair, and this proces is affected too, although there are clues that this may be unrelated. He's re-booting the Linux server tomorrow so hpefully all will come up cleanly, but I just wondered if anyone has seen similar behaviour in the past ....? thanks Neil

Having been re-booted, it's still ill: Now when the server is stopped, it starts up quickly into on-line mode, but continues to reject connections with the message 18:51:03 (1805) connection rejected - no calls allowed for sqlexec 18:51:03 listener-thread: err = -27002: oserr = 0: errstr = : Noconnections are allowed in for about 20 minutes until finally ... 19:14:05 CDR queuer initialization complete 19:14:05 DDR Log Snooping - Snooping started in log 217 19:14:06 CDR connection to server lost, id 2, name <g_host2>Reason: attempt to connect failed (This connect is failing because the replcation server is shut down). So it seems that the Enterprise replication initialisation is taking inordinately long - about 25 minutes - to fail. Any observations gratefully received. Neil Truby t:01932 724027 Director m:07798 811708 Ardenta Limited e:neil.truby@ardenta.com "Neil Truby" <neil.truby@ardenta.com> wrote in message news:bpmf18$1p43ib$1@ID-162943.news.uni-berlin.de... > IDS 9.21 on Red Hat > > My client's database session is really not too well. The database server > will not accept memory-type operations, such as onmode -k or onstat -F. > There are also no oninit proceses running. An onstat -g seg shows single > segments, but an ipcs -m shows multiple ones. In most other respects the > server is OK, although it is the primary in an Enterprise Replication pair, > and this proces is affected too, although there are clues that this may be > unrelated. > > He's re-booting the Linux server tomorrow so hpefully all will come up > cleanly, but I just wondered if anyone has seen similar behaviour in the > past ....? > > thanks > Neil > >

Neil, 1. I wud like to check time on both server. Make sure time diff. should not be more than 4-5 min. 2. How big is secondary database ? and can you afford to rebuild replication ? If yes, you need to use cdr delete server on primary and target both before rebuilding replication. Hari "Neil Truby" <neil.truby@ardenta.com> wrote in message news:bpnsrt$1kiag6$1@ID-162943.news.uni-berlin.de... > Having been re-booted, it's still ill: > > Now when the server is stopped, it starts up quickly into on-line mode, but > continues to reject connections with the message > > 18:51:03 (1805) connection rejected - no calls allowed for sqlexec > 18:51:03 listener-thread: err = -27002: oserr = 0: errstr = : No> connections are allowed in > > for about 20 minutes until finally ... > > 19:14:05 CDR queuer initialization complete > 19:14:05 DDR Log Snooping - Snooping started in log 217 > 19:14:06 CDR connection to server lost, id 2, name <g_host2>> Reason: attempt to connect failed > > (This connect is failing because the replcation server is shut down). > > So it seems that the Enterprise replication initialisation is taking > inordinately long - about 25 minutes - to fail. > > Any observations gratefully received. > Neil Truby t:01932 724027 > Director m:07798 811708 > Ardenta Limited e:neil.truby@ardenta.com > > "Neil Truby" <neil.truby@ardenta.com> wrote in message > news:bpmf18$1p43ib$1@ID-162943.news.uni-berlin.de... > > IDS 9.21 on Red Hat > > > > My client's database session is really not too well. The database server > > will not accept memory-type operations, such as onmode -k or onstat -F. > > There are also no oninit proceses running. An onstat -g seg shows single > > segments, but an ipcs -m shows multiple ones. In most other respects the > > server is OK, although it is the primary in an Enterprise Replication > pair, > > and this proces is affected too, although there are clues that this may be > > unrelated. > > > > He's re-booting the Linux server tomorrow so hpefully all will come up > > cleanly, but I just wondered if anyone has seen similar behaviour in the > > past ....? > > > > thanks > > Neil > > > > > >

"Hari Gupta" <hariog@yahoo.com> wrote in message news:3fbfd486$1@news.alphalink.com.au... > Neil, > > 1. I wud like to check time on both server. Make sure time diff. should not > be more than 4-5 min. Yes, it is. That's why database 2 has been brought down. They don't seem to have stopped ER though .... Thanks Neil