Hi Mohammed,
I am product manager for SRS. Can you please send me an email with your contact? I'd like to find out how to best provide help to you?
My email address is bill.zhang01@sap.com
Bill
↧
Re: Sybase Replication Switch Over
↧
Re: Sybase Replication Switch Over
Hello Stephen,
Thanks for note : 1868514 - SYB: SAP Sybase ASE and Replication Server: rolling upgrade
...I will refer note and try to do fail over as mentioned but note seems to more on doing upgrade on RS and DR Agent. rather switch over
Thanks
Mohammad
↧
↧
Re: text to varchar(max) conversion
Hi Mark,
Sorry, I didn't mention versions because most recent versions will do.
I tested with repserver 15.7.1 SP102, ase 15.7 #4 (I don't think a higher version would make a difference).
I don't know if mapping text to varchar(max) would help (if it would be allowed, it isn't because te types are not compatible). I already have replication definitions for MSA and previous versions had problems if you have multiple replication definitions.
Conversion between text and varchar(max) is implicit in ms sql.
It should be doable with function strings, but I have no experience with creating or modifying them.
The error message is "Argument data type varchar(max) is invalid for argument 1 of textptr functi."
I believe that trying to convert text to varchar between ASE servers would result in the same error.
Best Regards,
Luc.
↧
REPLICATION SERVER 15.7: why the RS command "admin quiesce_force_rsi" takes 60 seconds to do every time it is executed? Is there any way to shorten this time ?
Hi All,
1-The customer would like to know why the RS command "admin quiesce_force_rsi" takes 60 seconds to do every time it is
executed ?
2-Is there any way to shorten this time ?
3-Is it dependent on the route parameter "rsi_sync_interval" or any other parameter ?
The customer is running an MSA setup with PDS->PRS->RRS->RDS and when switching they aim to shorten the time it
takes for them to switch, and they have seen that every time they do the "admin quiesce_force_rsi" the first time it takes 60 seconds, and the second time (according to the steps in all manuals you should do it twice) it takes 0 seconds
4-So is it possible to cut down that 60 seconds in any way, and if so, what are the risk for doing so ?
5-What they would like to know is why the first quiesce always takes 60seconds and is there any way to minimize that time, and if they can minimize it ?
6-What are the concequences if they do ?
And
what parameter do they change it with, or is it hardcoded ?
Please need your advice
Thanks in advance
Regards,
Claude
↧
Re: REPLICATION SERVER 15.7: why the RS command "admin quiesce_force_rsi" takes 60 seconds to do every time it is executed? Is there any way to shorten this time ?
Hello Claude,
I don't have an answer to your questions, but I can tell what I do in our MSA environment.
We also have a PDB->PRS->RRS->RDB setup.
We have bi-directional replication setup, so in fact it is :
PDB<->PRS<->RRS<->RDB.
I have a perl script 'check_replication <srv_from> <srv_to>' that inserts a row in a table in each replicated database on <srv_from> and waits until the row arrived in all databases on <srv_to>.
To switch to the standby site, i have a switch_msa script that takes the following actions :
- derives what the <srv_from> and <srv_to> are,
- executes check_replication <srv_from> <srv_to> # to be sure there is no latency
- executes check_replication <srv_to> <srv_from> # just to be sure replication will work after the switch
- takes a way the logical_listener on <srv_from> # downtime starts here
- locks all user accounts on <srv_from>
- kills all user connections on <srv_from>
- executes check_replication <srv_from> <srv_to>
- unlocks all user accounts on <srv_to>
- defines the logical listener on <srv_to> # downtime ends
In a system with 54 replicated databases by 2 replication servers, it takes 5 to 9 seconds downtime.
Almost all of this time goes to the second "check_replication <srv_from> <srv_to>", but since the same command has been executed before the downtime starts, we are sure that all connections have been established and that it will finish in a reasonable time.
I think we could gain 1 or 2 seconds by introducing more parallellism into the check script, but we can live with a downtime that is less than 10 seconds.
Best Regards,
Luc.
↧
↧
Re: REPLICATION SERVER 15.7: why the RS command "admin quiesce_force_rsi" takes 60 seconds to do every time it is executed? Is there any way to shorten this time ?
I thought that the staff within the Sybase Support organisation knew their products better than putting out my case and questions right out in the open air on a discussion forum ! Especially since we pay a lot of money for your support ?
And is this really your normal procedure that will give me a better answer than you own senior technicians that should know how the Repserver really works ?
If that is the case, I'll better place my cases here in the future and save us a lot of money...
/Mike
↧
Re: REPLICATION SERVER 15.7: why the RS command "admin quiesce_force_rsi" takes 60 seconds to do every time it is executed? Is there any way to shorten this time ?
Hello Luc,
is your environment really an "MSA" with one repdef for each database and not a "WS" setup ?
/Mike
↧
Re: REPLICATION SERVER 15.7: why the RS command "admin quiesce_force_rsi" takes 60 seconds to do every time it is executed? Is there any way to shorten this time ?
Hello Mike,
It's really an MSA environment. one database repdef, one database subscription per direction.
But .... we have table replication definitions for each table to simplify the where clauses of updates and deletes, so that only primary key columns are used. I read somewhere that in more recent versions (or versions to come), this wouldn't be necessary anymore.
We use it as a Warm Standby system.
I'm very happy that I replaced all our WS pairs by MSA. With WS, switching 54 databases took 2 to 3 minutes (using 4 replication servers) and if one went wrong, it prevented us to switch. I always found that scary minutes.
Now with MSA, the operation is more 'static' and it requires 0 replication server commands to switch.
Another advantage is that the replication system isn't limited to 2 nodes.
Our replication systems now each contain 3 ase servers, 2 on solaris sparc, version 12.5.4, 2K pagesize, and one on solaris intel, version 15.7, 4K pagesize.
There is bi-directional MSA replication between each pair of the 3 (so 3 database replication definitions and 6 database subscriptions per database), one active and two standby where each of the 3 can become the active one in 5-9 seconds.
It's a great way to test and implement new versions of the database system while still maintaining the existing active/standby setup.
Beste Regards,
Luc.
↧
Re: REPLICATION SERVER 15.7: why the RS command "admin quiesce_force_rsi" takes 60 seconds to do every time it is executed? Is there any way to shorten this time ?
Hi Luc,
Your solution seems really interesting. I am however a bit confused with:
"- takes a way the logical_listener on <srv_from> # downtime starts here"
What do you mean with logical listener? Does that not imply a warm standby setup like Mikael mentioned? Or what exactly is it you do in this step?
/Alex
↧
↧
Re: REPLICATION SERVER 15.7: why the RS command "admin quiesce_force_rsi" takes 60 seconds to do every time it is executed? Is there any way to shorten this time ?
Hello Alexander,
When you have an active/standby system where you can switch between the 2 servers (refered to as physical servers), you usually also have a 'logical' server, i.e. a logical name so that aplications always connect to the same (logical) server.
Such a logical name is added to a dataserver with the sp_listener command.
That's why I called it a logical listener.
Bi-directional MSA setup is comparable to a WS setup. The difference is that with WS, to do the switch, you need to execute 'switch active for ..' and 'wait for switch for ..' commands in the replication server. With bi-directional MSA, replication is always active in both directions and doesn't require any replication server action when executing a switch. It's fast with 100% guarantee.
There are a few disadvantages: 1) with warm standby, you can create table replication definitions for warm standby with only the primary key columns. With MSA, you need to define all columns, and if you alter the table to add a column, you also need to alter the replication definition or that column wouldn't be replicated. 2) you need to be aware that if replication is bi-directional, you should always execute 'set replication off' before doing maintenance on the standby system.
Hope that answers your question,
Luc.
↧
Re: REPLICATION SERVER 15.7: why the RS command "admin quiesce_force_rsi" takes 60 seconds to do every time it is executed? Is there any way to shorten this time ?
Hello Luc,
Great now I understand much better what you mean. Thank you very much for the detailed explanation 
Alex
↧
Re: Sybase Replication Switch Over
Hi Mark,
your statement is not correct.
SAP LT Replication Server (SLT) is an own product without any relation to Sybase. It can be used for real time replication.
Best Regards,
Tobias
↧
Re: Sybase Replication Switch Over
Tobias,
Thanks for the correction.
Any ideas/suggestions on where Mohammad should be directing his questions for SAP apps using Sybase replication server? (There are separate groups for SAP on ASE and non-SAP on ASE ... haven't found (yet) a separate group for SAP on Sybase repserver.)
↧
↧
Re: Sybase Replication Switch Over
Puh, I would expect that this is the right forum, because it is a question related to SRS.
Sorry no idea.
Best,
Tobias
↧
Re: Sybase Replication Switch Over
Mohammad,
Sorry for the misdirection.
I can't find any other groups so I guess this is the 'right' place for SAP on Sybase repserver.
For general purpose comments on switching activities we'd need to know if your replication is setup using table-level replication (I kinda doubt this), MSA or WarmStandby. Unless you've got documentation that answers this question you can run the following:
- if using WarmStandby then you'll need a logical connection that relates your PDS.PDB to your RDS.RDB; you can log into the repserver and run 'admin logical_status'; if this returns some records that include your PDS.PDB and RDS.RDB pairs then you're using warm standby
- if using MSA you can log into the (e)RSSD and run rs_helpdbrep and rs_helpdbsub; if you're using MSA the output from these commands will show the database repdef and subscription related to your databases
Otherwise you'll need to a) wait for someone with SAP-centric/replication server knowledge to read this thread or b) open a case with SAP tech support to see if they have some documentation on how to switch databases in a SAP application/replication environment.
↧
Re: Sybase Replication Switch Over
Hi Mark,
Thanks for Input, I will run below commands and get back to you ....
Regards
Mohammad
↧
Re: Sybase Replication Switch Over
Hi Mohammed,
In Business Suite on ASE, there is a Sybase tool used by the SAP tooling for setting up and administering replication. That tool is called DR Agent - and is whose "sap_status path" output you are sharing in this thread.
Overview of the solution can be seen here:
While the DR Agent will participate in the replication failover processing, it is the SAP toolset that invokes it, and also manipulate the SAP environment to fail-over the SAP application as well.
I'll try to find correct link to that detailed information.
Regards,
Stephen
↧
↧
Re: Sybase Replication Switch Over
Hi Mohammed,
Please see SAP note 1868514 that describes using SAP tool saphostctrl to perform the failover.
Regards,
Stephen
↧
Re: Sybase Replication Switch Over
Hi Mohammed,
I am product manager for SRS. Can you please send me an email with your contact? I'd like to find out how to best provide help to you?
My email address is bill.zhang01@sap.com
Bill
↧
Sybase central replication manager plug-in?
Hi,
some one know where i can download the replication server / replication manager plug-in for sybase central?
i can not find this on the SAP marketplace.
B.R
Austin.Woo
↧