log_send vs. log_sent DBREMOTE

[VolkerBarth]

We use DBREMOTE for replicating Sybase 10.0 databases since several years, for me is not exactly clear what is the difference between log_send & log_sent in SYSREMOTEUSERS! Usually I had selten (or maybe never) seen DBs on which log_send <> log_sent! According to the documentation of Sybase I get only this text: 'Messages are sent only to subscribers for whom log_send is greater than log_sent.'

Now I have a weird case on which log_send is bigger than log_sent, but the borders of the online transaction log file is including the both offsets of log_send & log_sent (i.e. STARTOFFSET_LOGFILE < log_sent < log_send < ENDOFFSET_LOGFILE), but the DBREMOTE throws an error that the looked for offset is not existing.

I can manipulate the offsets in SYSREMOTEUSERS but not for all the fields (here all I need is to manipulate the log_send which is not possible).

Any explanation for such a situation? Is there any way to manipulate the log_send? or at least to assign it the value of log_sent.

[VolkerBarth]

or at least to assign it the value of log_sent

Setting log_sent to the log_send value might work but I don't know whether that will break synchronization... - In other words, I don't have a clue, I cannot remember a situation where both values were not identical.

Reg will know.

[Baron]

Can you but disclose how can I change the value of log_send so that it has the value of log_sent? I will do the manipulation on copies of DBs, and then check whether the tables are replicated, and then apply the change on productive DB.

It is good to have such a solution, then I will manipulate only the SYSREMOTEUSER on remote, otherwise, I will need to manipulate the SYSREMOTEUSER on Cons. too (the log_received & confirm_received for this remote)

[VolkerBarth]

Can you but disclose how can I change the value of log_send

That's a misunderstanding, I don't know how to do so. By saying "Setting log_sent to the log_send value" I simply suggested to modify log_sent so that its new value equals the (unchanged) value of log_send. And I generally don't recommend to modify sysremoteuser entries outside of the SQL Remote Agent (*) unless you are very aware of your actions and their consequences.

(*) And I assume that you already do know some "hidden way" to modify these values. That's not a documented feature, for a reason.

[Baron]

One more question please, according to my understanding the value of log_sent can only be a committed offset (Checkpoint). Am I correct?

if yes, then I hava another problem that I cant find the value of log_send in the 'translated transaction log file' as a committed checkpoint, but it is somewhere between two checkpoints.

[VolkerBarth]

What do you mean by "committed ckeckpoint"? IMHO checkpoints and commits are separate concepts.

In my understanding, SQL Remote sends only committed transactions, so the log offset entries in SYSREMOTEUSER should fit to offsets of committed transactions.

[Baron]

After manipulating the log_send and log_sent, I could let the DB to start generating messages, but aftere a while I got the same phenomenon. Log_Send > Log_sent, and DBREMOTE throws error stating: No log operation at offset of XXXX in the current transaction log, despite this offset XXXX is existing in the current online transaction log file

[VolkerBarth]

FWIW, here is another question by you with a similar error message with some hints by Reg how to check the online log for according operations at relevant offsets.

I don't know whether it applies here but the error situation there seems to have been due to a remote restored from an older backup so log offsets had been confirmed that were no longer contained in the current log although it contained the offset range...

[Baron]

This is not the case. I think something is going wrong with this DB. By starting the Database I get a warning: Performance warning: Database file "G:\\Temp\\XX\\XXX\\Daten\\DBXX.db" consists of 24 disk fragments.

Could such performance problem lead to errors in the behaviour of DBREMOTE?

[VolkerBarth]

That particular warning is very common, it just means the database file is split up into several disk fragments, and 24 is not a high number. It may slightly impact performance but certainly not SQL Remote, which relies primarily on scanning the transaction log...

[VolkerBarth]

Besides that, I'm certainly out of my wits, and I hope @Reg will have time to deal with this question...

[Baron]

But again to the first question: under which circumstances can be log_send > log_sent?