Using "save_interval" for non-warm standby DSI?

[sladebe]

We had a problem where a repserver crashed with a segmentation fault and an insert was silently lost to a subscription DSI connection database.   We have several subscription replicate databases, but only one was missing a single row.   It's not bad considering how much data we're moving, but the customer is still complaining.

I'm going to research the cause of the seg fault with tech support, but my is there any possibility of setting the save_interval for the non-warm standby DSI connection so that the repserver automatically reapplies transactions that it thinks were recently delivered, when the repserver is booting?

Just for background for others reading this, save_interval!=strict isn't typically used with logical/warm-standby connections because it can result in data loss.

Thanks in advance

Ben

[sladebe]

Responding to my own question, here's what I've figured out:

I was incorrect about the "insert was silently lost" problem.  It was actually a partially processed set of deletes (in separate transactions).   Apologies.

The save_internal is mainly for the situation where the destination ASE server crashes and loses a little bit of recent data.   In that scenario, you can boot the repserver with the problem DSI suspended, run "sysadmin restore_dsi_saved_segments" and old transactions will be reapplied, with transactions that are older than the rs_lastcommit date being ignored

[former_member89972]

SAP/Sybase replication is robust to handle start/stops of various components. So what you observed looks like an exception.

I can understand the concern/complain from a customer because single insert missing can be a big issue if it was for a huge dollar amount e.g. a big stock trade transaction. 

At the same time setting up user expectation will also help.  E.g. in replication system  you should emphasize that primary data is "the" standard set of rows. So you can always materialize table or missing rows etc. In case of crashes you could have some sanity checks like row counts etc. built to point out exceptions.   You could also use rs_subcmp utility to monitor the health of critical data between primary and replicate(s) databases.

If users/developers are ready to go extra mile you could creatively use identity column to find any gaps in case of crash.  Home grown check-sums for rows in a table could be another way of maintaining accuracy.

save_interval may help.  It will also increase your disk space requirements depending on what number you choose.

HTH

Avinash

[terry_penna]

Hi Benjamin

What you are suggesting using a save_interval will work fine for the non-warm standby DSI  connection. 

I do hope you opened an incident to investigate the supposedly silent loss of an insert when the SRS crashed?  That should not have happened and from a support standpoint should be investigated.

Regards

Terry

[sladebe]

Re: Save interval will work for a non-standby DSI connection.

After reading things some more, for repserver to ASE connections, the repserver documentation only talks about explicitly replaying save_interval transactions using the "sysadmin restore_dsi_saved_segments" command after a ASE dataserver crash (w/loss of recently applied data in the ASE server).   At least, as far as I can find.

Note that in the documentation for the "sysadmin restore_dsi_saved_segments" it says:

"The DSI must be explicitly suspended before you can use this command to restore saved segments."

So for my scenario (after a hard repserver crash), maybe I have to boot the repserver in standalone mode (boots with all DSIs down by default), run the restore_dsi_saved_segments command on all DSIs, then reboot the repserver in normal mode.

I'll run a test and see what happens.   Stay tuned for updates