On the other hand, if you are not satisfied that the databases involved are up to date, or if you know that the databases are definitely out of synch, then issuing the REMOTE RESET command will increase rather than decrease the gap in data between the consolidated and remote databases. Even in this situation, you may choose to issue the REMOTE RESET commands to reset the message tracking system and allow transactions to be replicated while a new database is being extracted and deployed.
For more information on the REMOTE RESET command, please refer to the following section of the documentation:
Replication and Syncronization Guide
PART 3. Reference
CHAPTER 25. Command Reference for Adaptive Server Anywhere
REMOTE RESET statement
URL:
http://manuals.sybase.com:80/onlinebooks/group-sas/awg0700e/dbrsen7/@Generic__BookView
 

Appendix A - Recommendations for Re-extracting Remote Databases

The primary difference between the re-extraction of an existing remote database and the extraction of a new remote database is that messages may currently be in transit to the consolidated database in the event of a re-extraction. Any messages that are in transit likely contain valid data. In order to ensure that the most data possible is recovered, the re-extraction process should ensure that valid messages are not rejected as a result of the re-extract.

The 2 basic techniques for ensuring that all valid messages are received and applied are:

1) Wait out the message transport layers latency period
This option is suitable when it is known that messages are typically received within a given time period. As an example, file based messages are present in the inbox of the receiving end as soon as dbremote completes sending them. In contrast, MAPI or SMTP based messages will have some latency as the mail servers forward them from the sending node to the receiving node.
To wait out the latency period, the following process would be used:
i) Run dbremote for the last time on the remote database that is about to be re-extracted
ii) Wait until the latency period has expired
iii) Run dbremote for the last time on the consolidated database to apply any messages that were sent from the remote
iv) Re-extract the remote database at this point
*Note that since the point of the re-extraction was the loss of a log file, step (i) will not be applicable if the log file was lost on the remote database
2) Extract the new remote database under a different remote user id.
This option is suitable when the latency period is not known, or if the remote database is going to continue to generate messages while the replacement database is re-extracted and deployed to the remote site. Under this option, a new remote user will be created with the same subscriptions as the existing remote user. Typically the 'generation' of this new remote user would be reflected in the remote user id. Since this approach does not overwrite the information in the sys.sysremoteuser table for the existing remote user id, messages from that user can continue to be received and applied.
It is important to remember that in this scenario messages may also be in transit from the consolidated database to a remote database, the data represented by transactions contained in those messages will already exist at the consolidated site and will be included in the remote database that gets extracted.

A typical implementation of this process would be:
i) For an existing remote user (i.e. "user1", create a new remote user with a higher generation id reflected in its name (i.e. "user1a")
-this new remote user will require its own unique message address
-you will need to create subscriptions for the new user that correspond to the subscriptions for the existing user
ii) Extract and deploy a database for the new remote user ("user1a")
iii) Once the new database has been received and is in use at the remote site, wait out the latency period and then drop the old remote user ("user1")

The "0-0000000-00" Message as a Special Case
The first message that is sent from each of the consolidated and the new remote database is the "0" message. This message contains information that is required to initialize the sys.sysremoteuser table with the log offsets required by the message tracking system. Since this message is a special case, any instance of this message can be applied by any newly extracted database that has not previously applied a message of this type. Given the following series of events, the special case "0" message could be incorrectly applied to a newly extracted database:

1) Extract a remote database using the extraction utility
2) Run dbremote to send the "0" message
3) Extract the same remote database a second time while the first instance of the "0" message is still sitting in that remotes inbox
4) Run dbremote and apply the first instance of the "0" message.
- this message is now out of context since it contains log offset information from prior to the second extraction of this database
- the sys.sysremoteuser table of this remote database will now contain incorrect log offset information
- running dbremote to apply further messages to this remote database will likely result in the reporting of the error "Missing message ..."
*Note: not all instances of this error/warning are due to this behavior. In many cases, the "Missing message ..." error is a sign that the SQL Remote message tracking system is working as expected.

Due to this behavior, it is strongly recommended that the inbox for a remote database be emptied out before the new database is deployed. Two techniques for ensuring that an incorrect "0" message does not get applied to a newly extracted remote database are:

1) Exchange the first set of messages at the consolidated site before deploying the new remote database.
- it is possible to change the message type of a database after it is extracted
- this means that you can use the file message type to perform a full cycle of replication after extracting the remote database and before deploying it
- a full cycle of replication is:
a)dbremote on the consolidated to generate the "0" message
b)dbremote on the remote to receive and apply the "0" message from the consolidated, and generate its own "0" message to send to the consolidated
c)dbremote on the consolidated to receive and apply the "0" message from the remote
2) Perform an initial run of dbremote with the "-r", "-a" and "-b" switches after deploying the new remote database.
- the "-r" and "-a" switches tell dbremote to receive but not apply any messages currently waiting for the database
- the "-b" switch tells dbremote/sssremote to run in batch mode
- performing a single iteration of dbremote with these switches will have the effect of cleaning out the message directory
- the negative side effect of t

上一页  [1] [2] [3] [4]  下一页