SQL Anywhere database replication - Not Applying Messages with Old Resend Count

Author

Not Applying Messages with Old Resend Count

Grigoris Tsolakidis

2005-07-08, 3:23 am

Hi.
I know that this is a post which appear many times in this group.
I know what this message mean - but just want to know - is there another
way to handle this situation without reextracting the remote user which face
this kinds of
problems ( I am talking not for the case where this message appears because
of the latency
of the message system but when the remoting just stop to replicate and just
loop with this message
and resend count increase)

Rob Waywell

2005-07-08, 1:24 pm

Have you had a chance to review this tech doc:

SQL Remote Error Messages: Their Probable Causes and Possible Remedies
http://www.ianywhere.com/developer/...e_remedies.html

--
-----------------------------------------------
Robert Waywell
Sybase Adaptive Server Anywhere Developer - Version 8
Sybase Certified Professional

Sybase's iAnywhere Solutions

Please respond ONLY to newsgroup

EBF's and Patches: http://downloads.sybase.com
choose SQL Anywhere Studio >> change 'time frame' to all

To Submit Bug Reports:
http://case-express.sybase.com/cx/c...sc?CASETYPE=Bug

SQL Anywhere Studio Supported Platforms and Support Status
http://my.sybase.com/detail?id=1002288

Whitepapers, TechDocs, and bug fixes are all available through the iAnywhere
Developer Community at www.ianywhere.com/developer
"Grigoris Tsolakidis" <gcholakidis@hotmail.com.spam-remove> wrote in message
news:42ce253b@forums
-2-dub...
> Hi.
> I know that this is a post which appear many times in this group.
> I know what this message mean - but just want to know - is there another
> way to handle this situation without reextracting the remote user which
> face this kinds of
> problems ( I am talking not for the case where this message appears
> because of the latency
> of the message system but when the remoting just stop to replicate and
> just loop with this message
> and resend count increase)
>

Grigoris Tsolakidis

2005-07-09, 3:23 am

Yes many times. It sugest to reextract the database when this happend.
Unfortunly in my case it happend lets say 2 times in 6 months in site with
15 remoting
databases. That means a whole day labor work, extract the database + find
the not replicated messages
from log file and e.t.c....+ ungry customer
I need to find better way to deal with this situation

Ï "Rob Waywell" <rwaywell@no_spam.ianywhere.com> Ýãñáøå óôï ìÞíõìá
news:42ceb5f5$1@foru
ms-1-dub...
> Have you had a chance to review this tech doc:
>
> SQL Remote Error Messages: Their Probable Causes and Possible Remedies
> http://www.ianywhere.com/developer/...e_remedies.html
>
> --
> -----------------------------------------------
> Robert Waywell
> Sybase Adaptive Server Anywhere Developer - Version 8
> Sybase Certified Professional
>
> Sybase's iAnywhere Solutions
>
> Please respond ONLY to newsgroup
>
> EBF's and Patches: http://downloads.sybase.com
> choose SQL Anywhere Studio >> change 'time frame' to all
>
> To Submit Bug Reports:
> http://case-express.sybase.com/cx/c...sc?CASETYPE=Bug
>
> SQL Anywhere Studio Supported Platforms and Support Status
> http://my.sybase.com/detail?id=1002288
>
> Whitepapers, TechDocs, and bug fixes are all available through the
> iAnywhere
> Developer Community at www.ianywhere.com/developer
> "Grigoris Tsolakidis" <gcholakidis@hotmail.com.spam-remove> wrote in
> message news:42ce253b@forums
-2-dub...
>
>

Rob Waywell

2005-07-11, 9:23 am

Here is the excerpt from my TechWave presentation from 2002 that discusses
how to break a resend loop:

Breaking a Messaging Loop

>Many common "error" messages are actually warnings It is possible to
>encounter message loops, in which the system is not self-correcting Usually
>due to a combination of:
1.Replication frequency
2.Message system latency
3.Large individual transactions
>Need to verify that you are in a loop and then manually intervene to break
>the cycle

Verfiying a Messaging Loop
At the Consolidated

1) SELECT * FROM SYS.SYSREMOTEUSERS;
OUTPUT TO 'cons_before. txt';

>do this before running dbremote
2) DBREMOTE -v -o cons.out ...
3) SELECT * FROM SYS.SYSREMOTEUSERS
OUTPUT TO 'cons_after.txt
>do this after running dbremote

1) SELECT * FROM SYS.SYSREMOTEUSERS;
OUTPUT TO 'rem_before. txt';

>do this before running dbremote
2) DBREMOTE -v -o rem.out ...
3) SELECT * FROM SYS.SYSREMOTEUSERS
OUTPUT TO 'rem_after.txt
>do this after running dbremote

Verifying a Messaging Loop
What to Look For

>Check the sysremoteusers values See if the log offset markers are changing
>Look for progression Verify that the "rules" are satisfied Check the
>Dbremote output Look for repeating errors Look for repeating message #'s
>with increasing resend counts Compare the Dbremote output to the
>sysremoteusers values Verify that the errors/warnings being reported are
>valid

Verifying a Messaging Loop
Repeating Errors

..
E. 07/05 16:49:40. Missing message from "rem1" (5-0000375545-0000602378-0)
..
E. 07/05 16:49:59. Missing message from "rem1" (6-0000375545-0000932032-0)
..
E. 07/05 16:50:19. Missing message from "rem1" (7-0000375545-0001262219-0)
..
E. 07/05 16:50:39. Missing message from "rem1" (8-0000375545-0001592960-0)

Breaking a Messaging Loop

Two Steps:
1.Clean out the message system
>Ensure that all messages in transit have been received Allows the system to
>catch up if there are multiple resend requests in transit
2.Run a controlled replication cycle

>Assist the system in catching up Once the system is caught up, considering
>modifying the send frequency and patience settings to avoid reintroducing
>the loop -rp, -rd, -ru

Breaking a Messaging Loop
Clean Out the Message System

>Run Dbremote/Ssremote in receive only mode at both ends
dbremote -r .
>If you are using the File or FTP message type, this phase can be really
>quick If you are using an e-mail message type, you may want to run this for
>a couple of hours

Breaking a Messaging Loop
Run a Controlled Replication Cycle

>Pick one side to start on, either consolidated or remote I'll pick the
>consolidated for this illustration
1.Run Dbremote/Ssremote in send only mode
dbremote -s -c "dbn=cons;eng=cons;."
2.Count up all the messages, and wait until they appear in the inbox at the
other end
>In this case, we would be waiting for the messages to arrive at the remotes
>inbox
3.Run Dbremote/Ssremote to send & receive
dbremote -c "dbn=rem1;eng=rem1;."

4.Count up all the messages, and wait until they appear in the inbox at the
other end
>In this case, we would be waiting for the messages to arrive at the remotes
>inbox
5.Run Dbremote/Ssremote to send & receive
dbremote -c "dbn=cons;eng=cons;."
>At this point you should be up to date If you picked the 'wrong' end to
>start at, then you may need to complete 1 more replication cycle to satisfy
>all resend requests

--
-----------------------------------------------
Robert Waywell
Sybase Adaptive Server Anywhere Developer - Version 8
Sybase Certified Professional

Sybase's iAnywhere Solutions

Please respond ONLY to newsgroup

EBF's and Patches: http://downloads.sybase.com
choose SQL Anywhere Studio >> change 'time frame' to all

To Submit Bug Reports:
http://case-express.sybase.com/cx/c...sc?CASETYPE=Bug

SQL Anywhere Studio Supported Platforms and Support Status
http://my.sybase.com/detail?id=1002288

Whitepapers, TechDocs, and bug fixes are all available through the iAnywhere
Developer Community at www.ianywhere.com/developer
"Grigoris Tsolakidis" <gcholakidis@hotmail.com.spam-remove> wrote in message
news:42cedd4e$1@foru
ms-1-dub...
> Yes many times. It sugest to reextract the database when this happend.
> Unfortunly in my case it happend lets say 2 times in 6 months in site with
> 15 remoting
> databases. That means a whole day labor work, extract the database + find
> the not replicated messages
> from log file and e.t.c....+ ungry customer
> I need to find better way to deal with this situation
>
> Ï "Rob Waywell" <rwaywell@no_spam.ianywhere.com> Ýãñáøå óôï ìÞíõìá
> news:42ceb5f5$1@foru
ms-1-dub...
>
>

Sponsored Links