nitpick: You mentioned the term 'standby' which often times can indicate the replicate database in a warm standby configuration.  A warm standby configuration can only have a single replicate database so the answer would be 'no' to the question of having two standby databases (if your client is using a warm standby configuration).

If your client is using (or can use) a multi-site availability (MSA) configuration then the answer is 'yes' to having two 'standby' (aka replicate) databases.  (In the simplest setup you would create a database replication definition for the primary database and then two database subscriptions - one subscription for each replicate database.)

----------

As to the question about delaying the application of transactions to one of the replicate databases the answer is 'yes, this is doable'.  You would configure the 4-hr delay on the replicate database's DSI connection via the dsi_timer configuration, eg:

alter connection to <ds>.<db> set dsi_timer to '04:00'

NOTE: Keep in mind that the repserver managing this DSI connection will need a stable queue large enough to hold at least 4 hours of the client's heaviest transaction volumes.

----------

As for the question of auto-failover options ...

nitpick: Repserver doesn't have an auto-failover capability; this capability would come from an external source that has the ability to determine when/how to perform a failover; this would include insuring application/user connections are routed to the new primary database after the failover.

For sake of discussion I'll assume your client has some means of determining when to perform a failover and the ability to conduct the actual failover (to include issuing the necessary replication-related commands to the repserver(s) and associated databases; to include insuring application/user connections are routed to the new primary database) ...

The answer to your question is 'yes, it would be possible to failover to the non-delayed replicate database'.  The details on *how* to perform the failover would rely heavily on your client's environment.

Assuming you perform a failover to the non-delayed replicate, would the client expect transactions to flow from the new primary database to the 4-hr delayed database?  And what about transactions flowing from the new primary database to the old primary database?  If the answer is 'yes' then you'll want an additional MSA repdef/subscription configuration in place with the repdef defined on the new primary database and matching subscriptions to the old primary database and the 4-hr delayed database.

In addition what Mark wrote:

In the simplest setup you would create a database replication definition for the primary database and then two database subscriptions - one subscription for each replicate database

I would suggest configuration using "Warm Standby" for production server and standby server (that with no delay) and based on created logical connection (configuration of two servers in "Warm Standby" seen as one logical connection) I would create MSA replicating into second  standby server (that with 4h delay).

In that case I could make "switch active" (fast failover) between servers with no delay with no need of changing configuration for second standby (it doesn't matter which server in logical connection is active or standby). Second standby server  will still receive all transactions.

I would suggest configuration using "Warm Standby" for production server and standby server (that with no delay) and based on created logical connection (configuration of two servers in "Warm Standby" seen as one logical connection) I would create MSA replicating into second  standby server (that with 4h delay).

Yeah, that would work, too! ;-)

I've had intermittent problems at a couple recent clients where the 'switch active' command has been very finicky (eg, fails to complete the switch due to a stray/missing network packet) so I guess I've become a bit gun shy with recommending warm standby.

I thought I'd seen Luc Van der Veurst do a write-up on an environment where he'd replaced all of his warm standby configs with MSA configs ... and how he was able to perform his switches faster with MSA than with warm standby.  I can't recall/find where that post is (assuming I'm not imagining the write-up) so perhaps Luc will see this thread and jump in, eh ...

Dear All,

I have tried sysadmin hibernate_off it doesnt work. as it was test setup  i decided to build up again but with  RS 15.7.1 SP200 , is it ceritied by SAP ?

Regards

Mohammad

I would like to add that using traditional "warm standby" might not satisfy the requirements, if the desire is to be able to also fail-over to the delayed copy.

If the delayed copy is never to become the primary, then a warmstandby pair subscribed to a 3rd copy is OK.  But if the intent is to be able to failover to either standby location, I think we should recommend an MSA only solution - the benefit would be that the failiover procedures would be the same.  With a mix of wamstandby and MSA, you have to maintain two differnet failover processes - which might be confusing to maintain.

Guys, thank you for your quick responses and and invaluable help!

Hi Mohammed,

No, I do not think SAP has certified SP200 with Business Suite for ASE.

SP200 begins to support some new ASE 16.0 features - which require additional certification (both RepServer and ASE certification).

I don't think that means your testing will fail, but it is not certified.

Reqards,
Stephen

Hello Stephen,

Thanks , I have started setting up replication environment but  installation master end up saying version not recognized.

SWPM used is latest one (SWPM10SP05_2-20009707.SAR)

any ideas

Regards

Moammad

Hi Mohammad,

Sorry - I should have thought of that - the SAP installer will not recognize the SP200 version for Replication Server or DR Agent.  (As we identified  - SP200 is not certified, which ends up meaning not supported by SAP tooling).

Rather than trying to work around the lack of tooling support, my recommendation would be to revert back to the supported SP120 version of Replication Server.

Regards,
Stephen

Mark A. Parsons wrote:

 

I thought I'd seen Luc Van der Veurst do a write-up on an environment where he'd replaced all of his warm standby configs with MSA configs ... and how he was able to perform his switches faster with MSA than with warm standby.  I can't recall/find where that post is (assuming I'm not imagining the write-up) so perhaps Luc will see this thread and jump in, eh ...

I mentioned it in a thread about admin quisce_force_rsi command earlier this year, but that thread has been deleted (http://scn.sap.com/message/14764886 ). I find it still difficult to find information on the sap website :-), I also thought I wrote something about it recently, but can't find it.

I posted the following on the ISUG SIG-Replication mailing list, in oktober 2012 :

____________________________________________________________________

I used to have 5 warm-standby pairs, one had 52 replicated databases.

I defined 4 replication servers for that one server, each replicating 13 databases, so that I could do a switch to standby in parallel.

It took some investigation to switch to standby as fast as possible because trying to do things in parallel was causing deadlocks in the rssd_db and then manual intervention was necessary, causing extra minutes downtime.

Putting sleeps in between commands increased the time to switch too much, so I examined what happened in the system tables and wrote a script that checks some status columns in a loop and continues when a certain value is reached.

Switching to standby took 2 to 3 minutes, nerve breaking minutes because there is always something that can go wrong.

About 2 years ago, I replaced all warm-standby pairs by MSA bi-directional replication.

We still use it in an active-passive setup, so there are no conflicts that could raise like in an active-active situation.

Switching to standby now takes at most 9 seconds, and nothing can go wrong since there is no switch command that needs to be executed.

The actions that are performed during a switch are :

- locking the users on the active server

- remove the logical ip address from the active server

- kill all user connections on the active server

- insert a row in a table in all replicated databases in the active server and wait until the rows arrived at the standby server

- unlock the users on the standby server

- add the logical ip address to the standby server, now becoming the active server.

Almost all 9 seconds go to the test that all statements in the queues are replicated.

(I also do this test before the switch so that the replication server has a connection to all databases and therer is no delay in replicating).

The 9 seconds switch time are for the server with 52 replicated databases.

Switching a server with only 10 replicated databases takes about 6 seconds.

Our application servers reconnect to the database server automatically, so a user who doesn't do a database request within those 9
seconds doesn't notice that database servers were switched.

I work in a hospital where we have 4 time windows of 3 hours per year to do maintenance.

If a host needs maintenance, I can now make the host free in seconds, so this can be done without warning the users, thanks to MSA.

There are some disadvantages.

- There are more statements to set it up.

- Replication definitions, necessary to define a primary key, now require all columns, so each time you alter a table and add/change/modify a column, you also need to modify the replication definitions (you need 2, one at both sides)

- We have DML replication set on, so I have to be carefull to set replication off when I want to do some maintenance on the standby server

- We also have table replication from one msa-pair to another, this also requires more setup since after a switch, the server receives last commit information from another server. To adderss this, I copy rs_lastcommit information from active to standby during the switch process.

- ...

But I value the advantages much higher :

- faster switch, without stress :-), since basically, it's just an IP adres that needs to be moved to another system.

- disadvantage of having to define all columns in a replication definition, becomes an advantage when you want to remove columns from a table (that can be done at the standby site first after removing the columns from the replication definition)

- and it's possible to add a 3rd (4th, ...) server to the setup which makes it possible to test new versions of ASE with the ability to return to the previous version without breaking your MSA setup.

Our current situation is that we have 6 pairs of 2 12.5.4 ASE servers.

We have 2 datacenters and each pair has one server running in each datacenter.
To each pair, I added a 3rd 15.7 server with bi-directional replication to the other 2.

Any of the 3 can become the active server within at most 9 seconds and will then replicate to the other 2.

_________________________________________________________________________________

I'm still happy with this setup :-).

We don't have automatical fail-over (we also didn't have it when we were using warm-standby).

There are too many unknown factors: is the server really down ? what's the status of the replication system ? will there be data loss ? ...

We prefer to make the decission wether to restart the server on the same host, or to switch to the standby system ourselves.

Luc.

i have a question regarding sybase replication warm standby sync up and appreciate the clarification.

let us suppose in a warm standby setup, the standby data has gone out of sync with the primary database.

the log contains committed as well as uncommitted data.

but even uncommitted data is sent to rep server.

so in a tran log let us suppose there are 12 transactions. till transaction 7, it has been committed on the primary database (that i think is the primary truncation point).

and let us suppose that the secondary truncation point is at the 9th transaction - till which data has been sent to the rep server.

but we do the dump database at the 12th transaction, where the dump marker is inserted.

so when we load the database dump into the primary, it will start accepting replicated transactions from the 12th transaction - from where the dump marker starts.

so in this case won't the transactions from 7 to 12 be missed?

the above case assumes a scenario where the sync up can be done without doing a dump tran of the primary database. or does a warm standby sync up always require a dump tran with truncateonly/nolog, of the primary database (and also the related rs_zeroltm etc)?

I think with 15.6 there is a new way to do the sync up. but here I am referring to the pre-15 versions.

appreciate the clarification.

thanks,

nanda chandran

Think of the entries in the transaction log as being in single file, eg, 1,2,3,4,5 ...

The dump marker (DM) is placed into the transaction log along with the transactions, eg:

1,2,3,4,5,6,7,8,9,10,11,12,DM,13,14,15,...

The database dump will contain all transactions up to #12.

The repserver will apply transactions 1-12 as normal to the standby database.  When the DM is processed the DSI (for the standby database) will shutdown.  All transactions coming after the DM (eg, 13,14,15,...) will queue up waiting for the DSI to be resumed.

When the dump file is loaded all transactions up to #12 will also be loaded/applied in the standby database.

When the DSI is resumed the queued transactions (13,14,15,...) will be applied to the standby database,

mark, thanks for the reply.

so just to be clear : dump/clear the transaction log and zeroltm is  not mandatory for warm standby resync? you can simply take the dump of the primary and load it into the standby? btw I have done these refreshes somewhere in the past - but specifics have slipped off my mind.

and if transaction 7 and 8 are open transactions - for which commit was not received at the time of the dump - so the commits coming later through the DSI will be processed and transaction integrity maintained?

and btw is there any chance of the dbgenid going out of sync during this and needing to be upped?

appreciate the clarification.

No need to clear the PDB log or run rs_zeroltm.

There should be no genid issues because you aren't rolling the PDB back to an earlier point in time.

As for 'simply take the dump of the primary and load it into the standby' ... first you have to put the DSI (of the standby) into a mode of waiting for a dump marker.  While this is fairly easy with RS 15.6+ (due to some new resync capabilities), I'm a bit rusty on how to get a pre-15.6 DSI into the mode of waiting for a dump marker (short of dropping/recreating the connection).  I'm sure there's a way to force the mode by updating the RSSD but I don't know the details off the top of my head.

mark, btw not sure if you noticed the question about uncommitted transactions before the dump marker. appreciate your clarification on that.

>and if transaction 7 and 8 are open transactions - for which commit was not received at the time of the dump - so the commits coming later through >the DSI will be processed and transaction integrity maintained?

thanks.

1 - Uncommitted txns in the dump file will be rolled back upon loading in the RDB.

2 - Repserver plays transactions against the RDB in the order in which they were committed (not the order in which they were started).

3 - The dump marker is basically a tiny 'committed' transaction (w/ its own commit time).

If your 'uncommitted' transactions complete at some later time then they will have a commit time that's later than the dump marker's commit time sooo ...they won't come across in the db dump (ie, they're uncommitted so they'll be rolled back) ... and since they would be committed after the dump marker is created (ie, after the dump marker's commit time) means they'll be applied against the RDB once the DSI is resumed.

------------------

Put another way ...

Any transactions committed before the dump marker's commit time will come across in the database dump file.

Any transactions committed after the dump marker's commit time will come through replication, build up in the DSI/outbound queue, and when the DSI is resumed said transactions will be played against the RDB.

ok mark, but when the commit (post dump marker) comes in through the DSI, will the replicate dataserver have access to the  original transaction (which was rolled back)? is there a transaction id or something else, by which it keeps track of past transactions?

Each transaction has a unique oqid, which consists of the gen id, source database info, etc, etc, etc.

When a transaction is successfully applied/committed in the RDB the local rs_lastcommit table is updated.

Other than that I'm not sure what you're asking re: rolled back transactions.

oqid is used in replication - using the dbgenid, timestamp of log page, transaction id etc.

but we are talking about the uncommitted transactions in the  database dump and how they are reconciled during warm standby resync - or rather post sync up, when the commit comes thru the DSI.

so how is the linkup done between uncommitted transactions in the database dump (which are rolled back during db load) and their related commits coming in later through the DSI. so when the ASE gets a commit through the DSI, how does it link that commit to its actual transaction (which it has actually rolled back during database load because they didn't have a commit then)?

There is no 'link' between what was rolled back (from the db dump) and what actually shows up later as a committed transaction that's applied via the DSI.

What comes across in the db dump is an incomplete copy of what's still in the PDB.  The incomplete transaction is rolled back and discarded by the RDB.

When the transaction finally commits in the PDB it is forwarded to, and applied by, the DSI.