07-12-2008, 04:06 AM
Repserver DBA Tips
Don't remove the secondary truncation point !
When your replication system is up and running, that's how you want to keep it. When something goes wrong, leading to replication being halted somewhere along the chain of events, this can eventually lead to the transaction log of the primary dataserver filling up. In such cases, a DBA could decide to remove the secondary truncation point in the transaction log (a.k.a. the "LTM truncation point"), to allow the primary dataserver to continue processing. While this may indeed be a solution from one point of view, be aware that this will likely cause your replication system to get out of sync because primary transactions won't be replicated anymore. As a DBA, you will then have to re-synch the primary and replicated data; depending on the complexity of your replication system, this may be anywhere between a minor headache and a complete nightmare. Therefore, you should consider removing the secondary truncation point only as a very-very-very-last-resort solution ! It may be more practical to allocate extra disk space for stable queues so that primary log transfer can continue than to reconcile primary and replicate data afterwards.
Have some disk space ready for emergencies
See the previous point. One good feature of RepServer is that you can not only extend the stable queues (using the add partition command), but you can also shrink them again through drop partition -- this command can be issued at any time, and will drop the partition as soon as there's no data on it anymore. Therefore, keep some disk space at hand which you can use to extend the stable queues should this ever be necessary.
How long can your system survive without a DBA ?
There's an interesting (and important) issue with respect to the sizing of your stable queues. Basically, your primary system should be able to continue for at least the time period that no DBA will be looking after the system -- and preferable a little longer than that. Depending on your system and organisation, such a no-DBA period can be a night, a weekend or just a few hours. Getting this sizing right will require monitoring the data volume being replicated.
If you like being paged, you could a cron job checking the free space in the stable queues and paging you when it fills up; very much like the sort of thing that tells you when a dataserver's transaction log fills up (pagers are most popular in America - Europeans can do something similar by having an SMS message sent to a GSM phone). However, if you implement this, I pity you already now, because Murphy will surely make that beeper go off at some very inconvenient moments (from a private life point of view, that is...).
Don't use the RepServer "sa" login
When creating or dropping a subscription, the replicate RepServer will log into the primary RepServer and -when using automatic materialization- into the primary dataserver. It will do this using the same login and password as you used to log into the replicate RepServer (where the subscription is created from). This implies that the same login and password must exist in the replicate and primary RepServer and the primary dataserver.
Therefore, when using the RepServer "sa" login, this means the "sa" password in the dataserver cannot simply be changed anymore as it would be out of sync with the RepServer's "sa" password, causing subscription creation to fail. When there are multiple primary dataservers in the replication system, they would all need to have the same password for their "sa" login. Therefore, best don't use the RepServer "sa" login to avoid this sort of dependency.
I prefer to create a login named "ra" (kinda short for "rep admin") in all RepServers and dataservers with the same passwords everywhere, and give these logins all necessary privileges. This way, I never have to use the RepServer "sa" login anymore, avoiding the problems described above.
Handle your RSSD with care
The RSSD, which is an ASE database, is the place where RepServer stores all the data it needs to be able to operate (not counting its configuration file), including administrative data such as the state and position of the stable queues. Otherwise, the RepServer itself doesn't store any data at all, with the exception of the configuration file, specifying where the RSSD is located. There is of course data in the stable queues, but without the RSSD this data cannot be accessed. This makes the RSSD an important database in your replication system, so ensure the RSSD is treated with the same care as your normal production databases. All considerations about recoverability, database dumps, log dumps and DBCC checks apply to the RSSD as well. For the same reason, don't enable the "trunc log on chkpt" option on the RSSD as this affects recoverability.
Reference :
Sybase Tips & Tricks
by Rob Verschoor
Don't remove the secondary truncation point !
When your replication system is up and running, that's how you want to keep it. When something goes wrong, leading to replication being halted somewhere along the chain of events, this can eventually lead to the transaction log of the primary dataserver filling up. In such cases, a DBA could decide to remove the secondary truncation point in the transaction log (a.k.a. the "LTM truncation point"), to allow the primary dataserver to continue processing. While this may indeed be a solution from one point of view, be aware that this will likely cause your replication system to get out of sync because primary transactions won't be replicated anymore. As a DBA, you will then have to re-synch the primary and replicated data; depending on the complexity of your replication system, this may be anywhere between a minor headache and a complete nightmare. Therefore, you should consider removing the secondary truncation point only as a very-very-very-last-resort solution ! It may be more practical to allocate extra disk space for stable queues so that primary log transfer can continue than to reconcile primary and replicate data afterwards.
Have some disk space ready for emergencies
See the previous point. One good feature of RepServer is that you can not only extend the stable queues (using the add partition command), but you can also shrink them again through drop partition -- this command can be issued at any time, and will drop the partition as soon as there's no data on it anymore. Therefore, keep some disk space at hand which you can use to extend the stable queues should this ever be necessary.
How long can your system survive without a DBA ?
There's an interesting (and important) issue with respect to the sizing of your stable queues. Basically, your primary system should be able to continue for at least the time period that no DBA will be looking after the system -- and preferable a little longer than that. Depending on your system and organisation, such a no-DBA period can be a night, a weekend or just a few hours. Getting this sizing right will require monitoring the data volume being replicated.
If you like being paged, you could a cron job checking the free space in the stable queues and paging you when it fills up; very much like the sort of thing that tells you when a dataserver's transaction log fills up (pagers are most popular in America - Europeans can do something similar by having an SMS message sent to a GSM phone). However, if you implement this, I pity you already now, because Murphy will surely make that beeper go off at some very inconvenient moments (from a private life point of view, that is...).
Don't use the RepServer "sa" login
When creating or dropping a subscription, the replicate RepServer will log into the primary RepServer and -when using automatic materialization- into the primary dataserver. It will do this using the same login and password as you used to log into the replicate RepServer (where the subscription is created from). This implies that the same login and password must exist in the replicate and primary RepServer and the primary dataserver.
Therefore, when using the RepServer "sa" login, this means the "sa" password in the dataserver cannot simply be changed anymore as it would be out of sync with the RepServer's "sa" password, causing subscription creation to fail. When there are multiple primary dataservers in the replication system, they would all need to have the same password for their "sa" login. Therefore, best don't use the RepServer "sa" login to avoid this sort of dependency.
I prefer to create a login named "ra" (kinda short for "rep admin") in all RepServers and dataservers with the same passwords everywhere, and give these logins all necessary privileges. This way, I never have to use the RepServer "sa" login anymore, avoiding the problems described above.
Handle your RSSD with care
The RSSD, which is an ASE database, is the place where RepServer stores all the data it needs to be able to operate (not counting its configuration file), including administrative data such as the state and position of the stable queues. Otherwise, the RepServer itself doesn't store any data at all, with the exception of the configuration file, specifying where the RSSD is located. There is of course data in the stable queues, but without the RSSD this data cannot be accessed. This makes the RSSD an important database in your replication system, so ensure the RSSD is treated with the same care as your normal production databases. All considerations about recoverability, database dumps, log dumps and DBCC checks apply to the RSSD as well. For the same reason, don't enable the "trunc log on chkpt" option on the RSSD as this affects recoverability.
Reference :
Sybase Tips & Tricks
by Rob Verschoor