Difference between revisions of "Category:RepServer"

From SybaseWiki
Jump to: navigation, search
m
 
Line 1: Line 1:
[[:Category:RepServer]]
+
=Replicating System Procedures like sp_addlogin / sp_password / etc.=
 +
 
 +
This seems to be a classic problem at warm-standby environments. Mark A. Parsons found a solution for this, but here is a much easier one. The description given below is a kind of template based on the requirement to replicate the execution of sp_addlogin. You can easily modify it for other Sybase supplied system stored procedures.
 +
* Setup a database (e.g. myDatabase) for warm standby as you normally do.
 +
* Grant the neccesary roles to the maintenance user to succesfully execute system stored procedures (like sso_role for sp_addlogin)
 +
* create a wrapper stored procedure like this template
 +
 
 +
use myDatabase
 +
go
 +
create procedure sp_addlogin @loginame varchar(30),
 +
                              @passwd  varchar(31)
 +
as
 +
-- trick the RepAgent
 +
commit tran
 +
 
 +
exec sybsystemprocs..sp_addlogin @loginame, @passwd
 +
 
 +
-- Start a new transaction (only at the standby side)
 +
if  proc_role("replication_role") > 0
 +
    begin tran
 +
go
 +
 
 +
* mark the new procedure for replication: sp_setrepproc sp_addlogin,"function"
 +
 
 +
That's all. Each execution of sp_addlogin in the myDatabase will create a login at the primary and the standby server.
 +
 
 +
Just a couple of remarks:
 +
* The template given above is not complete with regard to the parameters that need to be passed to sybsystemprocs..sp_addlogin. It's just a template.
 +
* even when a transaction fails on the primary side (for instance when the login already exists) it will be replicated to the standby side failing there as well. This will bring down the DSI connection. You can add some extra checks in the template to prevent common errors. To exit the procedure prematurely in those cases, do not give a "commit", but a "rollback".
 +
* When you do not need to replicate table modifications in the myDatabase, do not mark the database with sp_reptostandby. This is to prevent unnecessary transactions flowing through the RepAgent to the Replication Server.
 +
* This method has not been tested thorougly.
 +
* Do not mark the sp_addlogin stored procedure in sybsystemprocs for replication. When you do this, RepAgent adds an implicit "begin transaction" before the execution of the stored procedure, causing it to fail.
 +
* There is no need to change the Sybase supplied system stored procedures so this method is save with regard to upgrades.
 +
 
 +
 
 +
[[Category:RepServer]]

Revision as of 14:00, 17 March 2006

Replicating System Procedures like sp_addlogin / sp_password / etc.

This seems to be a classic problem at warm-standby environments. Mark A. Parsons found a solution for this, but here is a much easier one. The description given below is a kind of template based on the requirement to replicate the execution of sp_addlogin. You can easily modify it for other Sybase supplied system stored procedures.

  • Setup a database (e.g. myDatabase) for warm standby as you normally do.
  • Grant the neccesary roles to the maintenance user to succesfully execute system stored procedures (like sso_role for sp_addlogin)
  • create a wrapper stored procedure like this template
use myDatabase
go
create procedure sp_addlogin @loginame varchar(30),
                             @passwd   varchar(31)
as
-- trick the RepAgent
commit tran
 
exec sybsystemprocs..sp_addlogin @loginame, @passwd
 
-- Start a new transaction (only at the standby side)
if  proc_role("replication_role") > 0
    begin tran
go
  • mark the new procedure for replication: sp_setrepproc sp_addlogin,"function"

That's all. Each execution of sp_addlogin in the myDatabase will create a login at the primary and the standby server.

Just a couple of remarks:

  • The template given above is not complete with regard to the parameters that need to be passed to sybsystemprocs..sp_addlogin. It's just a template.
  • even when a transaction fails on the primary side (for instance when the login already exists) it will be replicated to the standby side failing there as well. This will bring down the DSI connection. You can add some extra checks in the template to prevent common errors. To exit the procedure prematurely in those cases, do not give a "commit", but a "rollback".
  • When you do not need to replicate table modifications in the myDatabase, do not mark the database with sp_reptostandby. This is to prevent unnecessary transactions flowing through the RepAgent to the Replication Server.
  • This method has not been tested thorougly.
  • Do not mark the sp_addlogin stored procedure in sybsystemprocs for replication. When you do this, RepAgent adds an implicit "begin transaction" before the execution of the stored procedure, causing it to fail.
  • There is no need to change the Sybase supplied system stored procedures so this method is save with regard to upgrades.