Analysis of backward compatibility of SQL Server replication

Although SQL Server 2008 has so far been considered a new version of the database system. But it will continue to update. For this reason, database administrators still need to consider backward compatibility issues when deploying SQL Server 2008. In order to reduce the problem of later upgrades, it is necessary for the database administrator to understand this topic. Specifically, it is important to understand which features in the SQLSERVER2008 database version might be discarded in future database versions. The database administrator will then be careful when deploying these features. Can not be used without, or with other functions to replace. In the future database upgrade process, then to adjust. I now take the data replication function as an example, talk about how to do this backwards compatibility.

A subscription that uses transactional replication is not recommended for expiration in SQL Server 2008.

In fact, this subscription retention period is like a "period of validity" or "warranty period." If the database system fails to complete the synchronization subscription within a valid warranty period, the contract job is deactivated or expires. If you assume that the maximum distribution retention period is 72 hours (this is the default setting for the SQL Server database, the administrator can adjust according to the situation), if the subscription is not synchronized within 72 hours, and there are changes in the distribution database that have not yet been delivered to the subscriber, The subscription job will be marked as deactivated by the purge distribution job running on the Distributor. When the database administrator wants to re-enable this subscription, the subscription must be reinitialized.

In the database, it is the sp_addpublication process that controls this subscription cycle. In this stored procedure, there is a @retention property. This property is primarily used to set the retention period for subscription activity. The value of this property is 336 hours by default. If the subscription activity is inactive during the retention period, the system will automatically delete it after it expires. In general, this value can be greater than the maximum retention period for the distribution database used by the publication service period. In other words, they have certain independence. If the database administrator wants the subscription to never expire, you need to set this parameter to 0. However, according to Microsoft's official information can be known, this parameter in future versions may be phased out. Because this property is improperly set, it can cause a series of adverse effects on merge replication, which affects the stability of the merge replication job. This parameter is best not used by the database administrator when deploying replication jobs to avoid incompatibility with subsequent versions of the database.

If you must use this parameter, it is best to follow some of the following recommendations.

One is if merge replication is used, then the retention period for the merge publication is best given a grace period. Because the database may be deployed in different time zones, if there is no grace period, then these subscribers that are distributed in different time zones may run into problems. To this end, I suggest that it is usually necessary to give it a 24-hour grace period. Even if the enterprise is not available now, it is likely that the database servers will be set up in different countries as the scale of the follow-up expands. For example, companies in the United States may set up a subscriber at a domestic office to improve the efficiency of the office. You should set a grace period of 24 hours for it at this time.

Second, try not to set this parameter to 0. Setting this parameter to 0 indicates that there is no retention period limit. Although this can be a certain degree, it simplifies the maintenance of the database administrator. However, setting the value of this parameter to 0 may result in a series of negative effects. This way, the database system will not be able to delete metadata, and so on.

To this end, the author of the recommendations, when implementing replication services, it is best not to use this parameter. If you have to use it, set a reasonable grace period for it, and it's best not to set this argument to 0. Although this is not a mandatory rule, but in order to replicate the service can be stable operation, the database administrator is best to consider the author of this proposal.

Second, non-SQL Server subscriber processing.

The SQL Server database is a good performance for horizontal compatibility. Not only can IT support SQL Server subscribers, but it can also support non-SQL Server Subscribers. If the enterprise needs a non-SQL Server subscriber, there are two channels for implementation, ODBC and OLE DB respectively. However, because ODBC is not as good at performance and security as OLE DB interfaces, the Microsoft database may no longer support ODBC interfaces in subsequent releases. So if you implement subscribers in version 2008, then it's best not to use this ODBC interface, instead of using OLE DB interfaces.