Getting a free version of RepServer

• A basic rule: when a thread is up and running, it will have a status such as "Active", "Awaiting Command", "Awaiting Message", or other variations of "Awaiting <something>".
  

• In a replicate RepServer, a "DSI" thread always comes with a corresponding "DSI EXEC" thread: together they represent the connection from the RepServer to a replicate database. There is also one such pair of threads for the RSSD.
  When the DSI/DSI EXEC threads have the status "Suspended", this can be the result of a suspend connection command (use resume connection to proceed). However, this also occurs when the RepServer was executing a command in that replicate database as part of a replicate transaction, and ran into an dataserver error. A common example is a "duplicate key" error when inserting an already existing key value into a replicate table having a unique index. You can try resuming the connection (using resume connection , but usually this results in the same error occurring again, suspending the connection once more. When this happens, the RepServer errorlog will always contain the error message returned by the dataserver.
  When you want to see the SQL commands that were issued as part of the replicate transaction, dump the first transaction in the corresponding queue (using sysadmin log_first_tran, see the RepServer QuickRef Guide for details).
  Once you understand why the SQL command leads to an error, you will have to take action to resolve the situation so that replication can continue. This may include manually modifying or removing data from the replicate table or deleting the replication transaction from the inbound queue (using the resume connection...skip transaction ).
  When you're running into replicate dataserver errors, you should have a good look at the design of your replication system as these errors suggest things are not going as was originally expected.
  

• When you're running RepServer 11.5 or later, a thread called "REP AGENT" represents the ASE RepAgent (or LTM) for the corresponding primary database. When running RepServer 11.0, these threads are called "LTM USER" instead.
  When the status of this thread is "Down", the RepAgent/LTM is not running. For an LTM, you will have to start the LTM process; to start an ASE RepAgent thread, run sp_start_rep_agen from within the primary database. If the RepAgent or LTM won't start, check the dataserver errorlog or LTM errorlog, respectively; there will be some kind of error message logged indicating why it cannot start.
  When the status of this thread is "Suspended", this is because the command suspend log transfer was run; issue resume log transfer to resume the thread.
  

• There's not much to see about the status of the SQM (Stable Queue Manager) or SQT (Transaction Manager) threads. You can get detailed information about what's happening to the queues using admin who, sqm or admin who, sqt (but let's leave it for now...).
  

• When using routes, an "RSI" thread represents the connection going from the your local RepServer to another RepServer. When the status of such a thread is "Connecting", this means the RepServer at the other end of the route is down, and your RepServer is periodically trying to reconnect.
  A thread called "RSI USER" is the incoming end of a route: a connection coming from another RepServer to your local RepServer. When the status is "Inactive", it means that the remote RepServer isn't running or suspended the route.
  

• rs_init is located in the install subdirectory of the RepServer installation tree ($SYBASE/$SYBASE_REP). Make sure this is in your PATH.
  

• A common problem is that you're trying to add a database and it appears that rs_init cannot access the dataserver because that server is not in the interfaces file. Adding the server to the interfaces file is the obvious solution, but then you'll find that it still makes no difference for rs_init. The reason is that rs_init reads the contents of the interfaces file when it starts; when making changes to the interfaces file, rs_init should be stopped and restarted for rs_init to notice the changes. Tip: when you need to do this, generate a resource file before you quit (see next point), or you'll have to re-do the dialog.
  
  
• On Unix, you can generate a resource file from rs_init by hitting CTRL-W (on NT, resource files cannot be generated or used with rs_init). This saves all the information you've entered in the preceding dialog into the resource file, which can be executed from the command line as rs_init -r <your_resource_file_name> .
  One problem is that the file format of rs_init resource files isn't documented very well. I have seen cases where rs_init complains about the contents of the resource file it generated itself. If you run into this sort of problem, there's no documentation that will help, but you may be able to fix it by manually editing the resouce file; this may require some creativity on your side, though.
  In one such case I remember, the error message said that the IDserver name was not specified (it said something like the IDservername being '' (=two single quotes)). This could be fixed by adding a line rs.rs_idserver_name: RSNAME , where RSNAME was the IDserver's name (funny enough, the resource file did contain a line saying rs.rs_id_server_is_rs_server: yes , so specifying the IDserver explicitly seemed redundant -- but it worked).
  If you're having any problems with invalid resource file contents, check the example resource files which exist in the init/rs subdirectory in the RepServer installation tree ($SYBASE/$SYBASE_REP). Try to figure out whatinformation rs_init wants in that resource file, and how you can supply it. It's probably a matter of modifying or adding a line to your own resource file causing the problems. You're on your own though, as there is no documentation here (only some comments in the example files): in the example above, my resource file was almost identical to the setupdb.rs example file, but the line I eventually added was copied from the install.rs file... that's where your creativity comes in.
  

• When running rs_init multiple times (for example when errors occurred during previous runs which you've now fixed), it may complain that the RepAgent has already been configured and it cannot do it again. The error message is:

Unable to execute query 
'exec sp_config_rep_agent "YOUR_DBNAME", enable, 
"YOUR_RSNAME", "YOUR_RSNAME_ra", 
"YOUR_RSNAME_ra_ps"' against server 'YOUR_DS_NAME'

When this error occurs, disable the RepAgent first as follows: sp_config_rep_agent YOUR_DBNAME, disable . Then re-run rs_init.

The following error may also be reported (it is related to the above message, and should disappear after disabling the RepAgent):

INTERNAL ERROR: "Database 'YOUR_DBNAME' is already
configured to use Replication Agent. Request to
enable Replication Agent has been ignored."
	

• rs_init may generate the following messages, which, despite the message saying it's an error, are really informational messages, and these can therefore be ignored. This often happens when re-running rs_init after fixing a previous error in the setup:

INTERNAL ERROR: "The replication status for
'rs_lastcommit' is already set to false. Replication
status for 'rs_lastcommit' does not change."

INTERNAL ERROR: "The replication status for
'rs_update_lastcommit' is already set to true.
Replication status for 'rs_update_lastcommit' does
not change."

• When adding a database which was previously dropped from the replication system, the following error may occur:

INTERNAL ERROR: "Settrunc() is not permitted when a
Rep Agent Thread is currently running on the database

This error means that the RepAgent is still running in that database. Stop the RepAgent as follows: sp_stop_rep_agent YOUR_DBNAME . Then re-run rs_init.

• When setting up a warm standby through rs_init, two common errors may occur:


• Before adding the active database for the warm standby, you must manually create a logical connection for the warm standby (using the command create logical connection SOME_SERVER.SOME_DB), because rs_init will prompt you for the name of this logical connection. You can not create this logical connection through rs_init. It is actually in the small print in the docs, but many people (including myself) found out the hard way (that's the RepServer way !).
  


• When adding the standby database using rs_init, this will normally fail because rs_init cannot log in to the dataserver containing the standby database. This is because the maintenance user login which rs_init tries to use, is not there yet; unlike the maintenance user login for the active database, which is created automatically by rs_init, the maintenance user login for the standby database isn't. Therefore, you must create this login manually and then re-run rs_init.
  
  

1> sysadmin sqt_dump_queue , 123, 1, 0
2> go
Msg 6024, Level 12, State 0:
Server 'REP_PRIM1':
Block read failed for queue '123:1', segment 304552,
block 26. OS dependent error is 'Could not initiate
aioread errno = 14

select * from rs_config

• an LTM is an extra OS-level process requiring an entry in the interfaces file; a RepAgent doesn't need this because it's an internal ASE thread.
  
• an LTM needs to be started explicitly by the DBA; once it has been configured, a RepAgent starts automatically when ASE starts.
  
• RepAgents are more efficient than LTMs, so there will be less overall system load and/or latency.
  
• an LTM can be greedy: when there's a large transaction to be replicated, LTMs have been known to allocate as much memory as needed for this transaction, but never deallocate it again, which may require the DBA to stop & restart the LTM. ASE RepAgents don't have this problem.
  

• Best keep the database names of active and standby databases the same. This lowers the risk of errors in client- or server-level software which may be referring to the database name explicitly -- remember, the purpose of a warm standby is, presumably, to be able to switch the active database at some point: your applications should still work correctly after that switch.
  Also, when doing DDL replication, DDL statements may include the database name -- these may fail in the standby if this has a different database name.
  

• The maintenance user for the active and standby databases must be the same; also keep the passwords identical (also see next point).
  

• You must ensure that logins and passwords are synchronised in the ASE servers containing the active and standby databases. This is to ensure that client applications can still log in after a switchover. RepServer doesn't give you solution for this, so you'll have to make something yourself. There are roughly two options for this: first, following Mark A. Parsons' ideas described elsewhere in this document; second, by amending sp_addlogin, sp_modifylogin, sp_droplogin and sp_password in such a way that they execute themselves as an RPC in the standby database after successfully completing in the active database -- this requires some hacking in the SQL text of these procedure.
  

• Also, the mapping between suid values (for logins) and uid values (for database users) should be kept identical in both servers. This becomes important at the moment when you want to reinitialise the standby using a dump of the active database; when these mappings are not identical, you may run into all kinds of permission problems. Note that this is always an issue when loading dumps into other servers, as such it is not a replication-specific point.
  The consequence of this issue is that you should not create logins in the standby server when these logins have not been created in the active server first.
  

• Be sure to keep replication settings identical in the active and standby databases. A classic mistake is to mark a specific table for replication in the active database, but forget to do this in the standby. There will probably not be a problem until you have to switch to the standby, when you (or likely, someone else) will find out that table is not properly replicating to the new standby...
  Therefore, every time when you execute sp_setreptable or sp_setrepproc in the active database, do the same in the standby. Similarly, when using sp_reptostandby , make sure the standby database has been configured in the same way.
  

• Try to keep things simple: stick to a 1-to-1 active-standby setup and simply replicate all tables. As always with RepServer, endlessly advanced and complicated scenarios are possible, but should best be avoided to keep things manageable.
  

• the most elegant solution is to solve this on network (DNS) level, independent of ASE and RepServer. Suppose you have two Unix systems, one named "batman", hosting the primary dataserver and one named "robin" for the standby server. Now make sure the client applications have interfaces files where the dataserver they connect to is specified on to run on a host named "gotham". However, there is no system named "gotham"; instead, the network is configured such that the name "gotham" resolves to "batman" (this can normally be done on DNS level on your LAN). When switching to the standby, reconfigure the DNS so that "gotham" now resolves to "robin". This way, the client applications do not need to do anything at all when switching to the standby (except reconnect). Obviously, the port numbers of the dataservers on both systems should be identical for this to work.
  

• the application user explicitly specifies that a different dataserver is now to be used; however this is not desirable, because you would like to hide these issues from the end-user.
  

• the interfaces file used by the client applications is changed so that they will connect to a different ASE server while using the same servername on client level. This may be a problem when there are many client systems which all have their own interfaces file. You'll have to figure out a way of getting this done.
  A solution which I've once seen for this is worth mentioning, particularly because of the dangers that come with it: you could add a second "query" line to the interfaces file, so that the first is for the active server, and the second for the standby. The idea is this: as long as the active server is up, all applications will connect to it, as it is the first "query" entry. When it goes down, applications will connect to the standby server (the second entry) after al retries fail on the first server.
  The danger of this approach is that when the first server is running fine but for any reason the connection attempts fail, the application will move on to the second query entry and happily connect to the standby database, and possibly execute DML statements there; obviously, this may lead to a lot of trouble in your database, so think *very* carefully before you'd use this trick...
  

• all applications could have a bit of logic built in which retrieve the server name of the ASE server they should connect to. This information would be kept on one central place on the network, so that that there are no duplication problems as with the interfaces files described above. Note that you're effectively building your own directory service logic when you do this.
  

• The unit of replication is a transaction, not just an individual DML statement.
  

• RepServer guarantees that replicated transactions are applied in the same order as they occurred on the primary side.
  

• In principle, when individual components (dataservers, RepServer, network connections) of a RepServer-based system are temporarily unavailable, this should be transparent to the overall replication system. When a component becomes available again, replication should continue with minimal or no further manual DBA action. Most of the time, this works quite well.
  

• In 2004, I published a book named "The Complete Sybase Replication Server Quick Reference Guide". As the title suggests, this is a rather complete QuickRef guide (covering up to RepServer version 12.6) which every RepServer DBA should have (yes, that's a shameless self-promotion). More information is here.

• Not a commercial book, but there's an excellent whitepaper on P&T for RepServer on the Sybase support website.
  

• John Kirkwood has published a useful book "Sybase Replication Server, an Administrator's Guide"; this book can be ordered at http://www.pagelink.demon.co.uk/.
  

• Another book is "Sybase Replication Server Primer" by C.B. Clifford, McGraw-Hill, ISBN 0-07011515-X. This book is only for those who have read all the existing RepServer manuals and still want more. It describes architecture and internals in detail, and is very technical. As such, it isn't easy reading.
  My 1995 edition covers only RepServer version 10 -- I don't know if there are new editions covering more recent versions. The book contains a useful appendix with SQL queries to manually query the RSSD.