rootdbs full error
Posted in 2006
On IDS 7.31 with Enterprise Replication, the passive server's rootdbs filled up and apps failed, with "CDR QUEUER: Send Queue DB space is FULL"; the syscdr table trg_receive_sbuf had ~183,000 rows. Advice given: the send/receive queue spool defaults to rootdbs unless separate dbspaces are configured, so add a chunk to rootdbs to let the queued data drain, then move the queues to their own dbspaces; alternatively stop/delete the replicates. Since it was the receive queue backing up, the apply/datasync threads were likely not processing (possibly a known NIF flow-control block with large transactions), so contacting tech support was recommended. No confirmed outcome is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: Storage & Space Management, Connectivity: ESQL/C, 4GL & Embedded SQL, Versions, Editions & End-of-Life
Hi all, IDS 7.31 online.log gave an error "CDR QUEUER: Send Queue DB space is FULL - waiting for space" this morning. Also, I saw that rootdbs was full and 4gl applications didn't run. There is two IDS 7.31 and replication is defining active - passive. Problem is passive server. When I seek the problem on syscdr db tables, trg_receive_sbuf table has approx. 183000 rows. It looks like too much. I think table trg_receive_sbuf is fulling by the replication engine. I tried to stop-start replication and empty the related table bu not rootdbs. Aslo, replication didn't run on passive server. Is there any way to emptying that syscdr table? Or, how can I empty the rootdbs? Thanks for advice. Mustafa
You should now think about sending the send AND receive queues to a dbspace other than rootdbs. If you do not define separate dbspaces for those two while configuring for replication they will be defaulted to rootdbs. jp "Mustafa Sert" <msert@meteor.gov .tr> To Sent by: ids@iiug.org ids-bounces@iiug. cc org Subject rootdbs full error [6917] 06/12/2006 09:43 AM Please respond to ids@iiug.org Hi all, IDS 7.31 online.log gave an error "CDR QUEUER: Send Queue DB space is FULL - waiting for space" this morning. Also, I saw that rootdbs was full and 4gl applications didn't run. There is two IDS 7.31 and replication is defining active - passive. Problem is passive server. When I seek the problem on syscdr db tables, trg_receive_sbuf table has approx. 183000 rows. It looks like too much. I think table trg_receive_sbuf is fulling by the replication engine. I tried to stop-start replication and empty the related table bu not rootdbs. Aslo, replication didn't run on passive server. Is there any way to emptying that syscdr table? Or, how can I empty the rootdbs? Thanks for advice. Mustafa ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
If the trg_receive_sbuf table is holding stuff, then that means that th= e apply is not working correctly. I'd contact tech support to have them check into the problem if I were you. M.P. = "Mustafa Sert" = <msert@meteor.gov = .tr> = To Sent by: ids@iiug.org = ids-bounces@iiug. = cc org = Subj= ect rootdbs full error [6917] = 06/12/2006 08:43 = AM = = = Please respond to = ids@iiug.org = = = Hi all, IDS 7.31 online.log gave an error "CDR QUEUER: Send Queue DB space is FULL - waiting for space" this morning. Also, I saw that rootdbs was full and 4gl applications didn't run. There is two IDS 7.31 and replication is defining active - passive. Problem is passive server. When I seek the problem on syscdr db tables, trg_receive_sbuf table has= approx. 183000 rows. It looks like too much. I think table trg_receive_sbuf is fulling by the replication engine. I tried to stop-start replication and empty the related table bu not rootdbs. Aslo, replication didn't run on passive server. Is there any way to emptying that syscdr table? Or, how can I empty the= rootdbs? Thanks for advice. Mustafa ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. =
YOU need add a chunk to root dbspace to let it fininsh the current buffered data. After that, add a new dbspaces to replication buffer. Frank Qu Madison Pruet wrote: >If the trg_receive_sbuf table is holding stuff, then that means that th= >e >apply is not working correctly. I'd contact tech support to have them >check into the problem if I were you. > >M.P. > >= > >"Mustafa Sert" = > ><msert@meteor.gov = > >..tr> = >To > >Sent by: ids@iiug.org = > >ids-bounces@iiug. = >cc > >org = > >Subj= >ect > >rootdbs full error [6917] = > >06/12/2006 08:43 = > >AM = > >= > >= > >Please respond to = > >ids@iiug.org = > >= > >= > >Hi all, >IDS 7.31 online.log gave an error >"CDR QUEUER: Send Queue DB space is FULL - waiting for space" >this morning. >Also, I saw that rootdbs was full and 4gl applications didn't run. >There is two IDS 7.31 and replication is defining active - passive. >Problem is passive server. >When I seek the problem on syscdr db tables, trg_receive_sbuf table has= > >approx. 183000 rows. It looks like too much. >I think table trg_receive_sbuf is fulling by the replication engine. I >tried to stop-start replication and empty the related table bu not >rootdbs. Aslo, replication didn't run on passive server. >Is there any way to emptying that syscdr table? Or, how can I empty the= > >rootdbs? >Thanks for advice. >Mustafa > >***********************************************************************= >******** > >Forum Note: Use "Reply" to post a response in the discussion forum. > >= > > >******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > -- Yunyao "Frank" Qu Computer Sciences Corporation(CSC) NOAA/CLASS, (301)817-4696
If this were the send buffer, I'd agree. But since this is the receive= buffer, then I think the first question is why the receive datasync thr= eads are not processing the data. One thing to check out. Normally we don't use the receive queue stable= storage unless there is a large transaction being processed. You might= want to check to see if the NIF is in flow block. There was a bug that= I fixed several years ago in which we would go into flow control (nif BLO= CK) when we had a large transaction and would not correctly come out of the= block. If the NIF is blocking and the data sync is not processing anything, then it is possible that you are running into this problem an= d that the complete transaction is not getting transmitted. Again - I'd contact tech support to have them analyze the problem. M.P. = "Yunyao (Fra...." = <Yunyao.Qu@noaa.g = ov> = To Sent by: ids@iiug.org = ids-bounces@iiug. = cc org = Subj= ect Re: rootdbs full error [6920] = 06/12/2006 09:42 = AM = = = Please respond to = ids@iiug.org = = = YOU need add a chunk to root dbspace to let it fininsh the current buffered data. After that, add a new dbspaces to replication buffer. Frank Qu Madison Pruet wrote: >If the trg_receive_sbuf table is holding stuff, then that means that t= h=3D >e >apply is not working correctly. I'd contact tech support to have them >check into the problem if I were you. > >M.P. > >=3D > >"Mustafa Sert" =3D > ><msert@meteor.gov =3D > >..tr> =3D >To > >Sent by: ids@iiug.org =3D > >ids-bounces@iiug. =3D >cc > >org =3D > >Subj=3D >ect > >rootdbs full error [6917] =3D > >06/12/2006 08:43 =3D > >AM =3D > >=3D > >=3D > >Please respond to =3D > >ids@iiug.org =3D > >=3D > >=3D > >Hi all, >IDS 7.31 online.log gave an error >"CDR QUEUER: Send Queue DB space is FULL - waiting for space" >this morning. >Also, I saw that rootdbs was full and 4gl applications didn't run. >There is two IDS 7.31 and replication is defining active - passive. >Problem is passive server. >When I seek the problem on syscdr db tables, trg_receive_sbuf table ha= s=3D > >approx. 183000 rows. It looks like too much. >I think table trg_receive_sbuf is fulling by the replication engine. I= >tried to stop-start replication and empty the related table bu not >rootdbs. Aslo, replication didn't run on passive server. >Is there any way to emptying that syscdr table? Or, how can I empty th= e=3D > >rootdbs? >Thanks for advice. >Mustafa > >**********************************************************************= *=3D >******** > >Forum Note: Use "Reply" to post a response in the discussion forum. > >=3D > > >**********************************************************************= ********* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > -- Yunyao "Frank" Qu Computer Sciences Corporation(CSC) NOAA/CLASS, (301)817-4696 ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. =
1) If you want replication to continue to work, solve the problem with replication (may be something wrong) and add space to rootdbs. 2) If you want to stop ER, you can remove replicates. cdr stop <replicate> cdr delete <replicate> Mustafa Sert escreveu: Hi all, IDS 7.31 online.log gave an error "CDR QUEUER: Send Queue DB space is FULL - waiting for space" this morning. Also, I saw that rootdbs was full and 4gl applications didn't run. There is two IDS 7.31 and replication is defining active - passive. Problem is passive server. When I seek the problem on syscdr db tables, trg_receive_sbuf table has approx. 183000 rows. It looks like too much. I think table trg_receive_sbuf is fulling by the replication engine. I tried to stop-start replication and empty the related table bu not rootdbs. Aslo, replication didn't run on passive server. Is there any way to emptying that syscdr table? Or, how can I empty the rootdbs? Thanks for advice. Mustafa ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. -- Jairo Gubler Analista de Sistemas APL - IBD (Interfaces e Banco de Dados) DÍGITRO TECNOLOGIA E-mail: [1]jairo.gubler@digitro.com.br Fone: (48) 3281 7213 Fax: (48) 3281 7299 Site:[2]www.digitro.com.br References 1. mailto:jairo.gubler@digitro.com.br 2. http://www.portaldigitro.com.br/