Replication depends on access to operations in the transaction log, and access to old transaction logs is sometimes required. This section describes how to set up backup procedures at the consolidated and remote databases to ensure proper access to old transaction logs.
It is crucial to have good backup practices at SQL Remote consolidated database sites. A lost transaction log could easily mean having to re-extract remote users. At the consolidated database site, a transaction log mirror is recommended.
For information on transaction log mirrors and other backup procedure information, see Backup and data recovery.
All transaction logs must be guaranteed available until they are no longer needed by the replication system.
In many setups, users of remote databases may receive updates from the office server every day or so. If some messages get lost or deleted, and have to be resent by the message-tracking system, it is possible that changes made several days ago will be required. If a remote user takes a vacation, and messages have been lost in the meantime, changes weeks old may be required. If the transaction log is backed up daily, the log with the changes will no longer be running on the server.
Because the transaction log continually grows in size, space can become a concern. You can use an event handler on transaction log size to rename the log when it reaches a given size. Then you can use the delete_old_logs option to clean up log files that are no longer needed.
For more information about controlling transaction log size, see BACKUP statement.
Setting the transaction log directory
Backup utility options
Managing old transaction logs
Recovery from database media failure for consolidated databases
Backup procedures at remote databases
Upgrading consolidated databases
Unloading and reloading a database participating in replication
|Send feedback about this page via email or DocCommentXchange||Copyright © 2008, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.0|