Home > Archive > SQL Anywhere database replication > November 2005 > Ever-increasing sr_transaction









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Ever-increasing sr_transaction
Gordon.Freeman@Sandtraps.com

2005-11-03, 8:25 pm

Configuration:
Two ASE 12.5.1 on Windows 2000 servers.
ssremote replication, two-way. Version as shipped with ASE 12.5.1.
FILE protocol.

Problem:

For long periods there may be no activity on the remote server, while the
consolidated server is in regular, daily operation.
SSRemote is running continuously on both servers. Stopping and starting
ssremote does not affect the problem described. The log files report that
messages are received, sent and applied, both servers. There are no
un-processed message files anywhere.
We noted that the number of rows in sr_transaction on the remote (only)
kept growing. At around 12000 rows I made a transaction on the remote
database. Immediately the number of rows dropped to almost nothing.

We have seen this before with different set-up and batch driven execution
and earlier versions of software. If there are no transactions on the
remote, sr_transaction is left un-processed until a transaction occurs at
the remote database.

I should like to see a solution to this. So far we have scheduled a
tranaction on the remote server , inserting and removing some rubbish in
one of the replicated tables, once every day.

Could this indicate an incorrect configuration , or is it a known bug ?

regards,

Gordon


Nick Elson

2005-11-03, 8:25 pm

Part of the problem is due to the fact that you
are running continuously at the mostly idle site.

You probably should just run
the receive (-r)
and the scan (-i)
phases continuously but run the send (-s) phase
periodically; stopping after each run.

Running the send phase continuously will keep
the traffic to a minimum and since there are
apparently no transactions to replicate this means
no traffic. In contrast, running the send phase in
batch (-b) mode tends to force a confirmation
cycle to occur and a queue rescan.

This queue scan alone should be enough but give
it a try to see though.

I am not certain what is actually accumulating in
the sr_transaction table, but it sounds a bit like
housekeeping information. If you run SSTRAN
you will probably see little or no new information.

While I am at this, you should probably know you
have reached the end of the support for SSRemote.
ASE 15 removes the functionality we need to
scan the log so SSRemote will be going away as
soon as you upgrade to 15.

Also, 12.5 has and ASE replicator technology that
may actual turn out to be a better match to your
requirements.


Good luck


<Gordon.Freeman@Sandtraps.com> wrote in message
news:4369eb00@forums
-2-dub...
> Configuration:
> Two ASE 12.5.1 on Windows 2000 servers.
> ssremote replication, two-way. Version as shipped with ASE 12.5.1.
> FILE protocol.
>
> Problem:
>
> For long periods there may be no activity on the remote server, while the
> consolidated server is in regular, daily operation.
> SSRemote is running continuously on both servers. Stopping and starting
> ssremote does not affect the problem described. The log files report that
> messages are received, sent and applied, both servers. There are no
> un-processed message files anywhere.
> We noted that the number of rows in sr_transaction on the remote (only)
> kept growing. At around 12000 rows I made a transaction on the remote
> database. Immediately the number of rows dropped to almost nothing.
>
> We have seen this before with different set-up and batch driven execution
> and earlier versions of software. If there are no transactions on the
> remote, sr_transaction is left un-processed until a transaction occurs at
> the remote database.
>
> I should like to see a solution to this. So far we have scheduled a
> tranaction on the remote server , inserting and removing some rubbish in
> one of the replicated tables, once every day.
>
> Could this indicate an incorrect configuration , or is it a known bug ?
>
> regards,
>
> Gordon
>
>



Sponsored Links





Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive | Programming forum archive

Copyright 2008 droptable.com