Before you upgrade to SQL Server 2008, you must make sure that all committed transactions from published tables have been processed by the Log Reader Agent. To make sure that all transactions have been processed, perform the following steps for each database that contains transactional publications:

1. Make sure that the Log Reader Agent is running for the database. By default, the agent runs continuously.
   
2. Stop user activity on published tables.
   
3. Allow time for the Log Reader Agent to copy transactions to the distribution database, and then stop the agent.
   
4. Execute sp_replcmds to verify that all transactions have been processed. The result set from this procedure should be empty.
   
5. Execute sp_replflush to close the connection from sp_replcmds.
   
6. Perform the server upgrade to SQL Server 2008.
   
7. Restart SQL Server Agent and the Log Reader Agent if they do not start automatically after the upgrade.
   

After upgrade, run the Snapshot Agent for each merge publication and the Merge Agent for each subscription to update replication metadata. You do not have to apply the new snapshot, because it is not necessary to reinitialize subscriptions. Subscription metadata is updated the first time the Merge Agent is run after upgrade. This means that the subscription database can remain online and active during the Publisher upgrade.

Merge replication stores publication and subscription metadata in a number of system tables in the publication and subscription databases. Running the Snapshot Agent updates publication metadata and running the Merge Agent updates subscription metadata. It is only required to generate a publication snapshot. If a merge publication uses parameterized filters, each partition also has a snapshot. It is not necessary to update these partitioned snapshots. (In SQL Server 2000, parameterized filters were referred to as dynamic filters, and partitioned snapshots were referred to as dynamic snapshots).

Run the agents from SQL Server Management Studio, Replication Monitor, or from the command line. For more information about running the Snapshot Agent, see the following topics:

• How to: Create and Apply the Initial Snapshot (SQL Server Management Studio)
  
• How to: Start and Stop a Replication Agent (SQL Server Management Studio)
  
• How to: Create the Initial Snapshot (Replication Transact-SQL Programming)
  
• Replication Agent Executables Concepts
  

For more information about running the Merge Agent, see the following topics:

• How to: Synchronize a Pull Subscription (SQL Server Management Studio)
  
• How to: Synchronize a Push Subscription (SQL Server Management Studio)
  
• How to: Synchronize a Pull Subscription (Replication Programming)
  
• How to: Synchronize a Push Subscription (Replication Programming)
  

After upgrading SQL Server in a topology that uses merge replication, change the publication compatibility level of any publications if you want to use new features. For more information, see Using Multiple Versions of SQL Server 2008 in a Replication Topology.

Before upgrading from one edition of SQL Server 2008 to another, verify that the functionality you are currently using is supported in the edition to which you are upgrading. For more information, see the section "SQL Server 2008 Replication Features" in the topic Features Supported by the Editions of SQL Server 2008.

In versions of SQL Server prior to SQL Server 2005, agents ran, by default, under the context of the SQL Server Agent service account. SQL Server 2005 introduced fine-grained control over each account under which the replication agents run and make Windows Integrated connections to databases and other resources; a different account can be specified for each agent. For more information, see Security and Protection (Replication) and Replication Agent Security Model.

The new security model has the following implications for upgrading and running SQL Server 2000 in a topology:

• Replication scripts created from SQL Server 2000 should be upgraded for SQL Server 2008 in order to take advantage of security enhancements. For more information, see How to: Upgrade Replication Scripts (Replication Transact-SQL Programming).
  
• A Distributor or Subscriber upgraded from SQL Server 2000 to SQL Server 2008 continues to run under the SQL Server Agent account and likely has more privileges than it requires. After upgrade we recommend that you specify separate accounts for the agents with the appropriate minimum privileges. To specify separate accounts:
  
  1. Script out the publication and subscriptions.
     
  2. Make changes to the scripts. For more information, see How to: Upgrade Replication Scripts (Replication Transact-SQL Programming).
     
  3. Drop the publication and subscriptions. For more information, see Publishing Data and Database Objects and Subscribing to Publications.
     
  4. Recreate them using the modified scripts.
     
  For information on the privileges required by agents, see Replication Agent Security Model; for information on managing logins and passwords, see Managing Logins and Passwords in Replication. New replication configurations created after an upgrade requires specific account configuration for each replication agent.
  

  Note:

  Any agents configured to use SQL Server Authentication for local database connections is changed to use Windows Authentication. Local connections are those connections made by an agent to an instance of SQL Server running on the same computer as the agent. For example, the Merge Agent for a pull subscription runs at the Subscriber, so the connections it makes to the Subscriber are local connections.

• Participants in a replication topology running previous versions of SQL Server retain the previous replication security model unchanged. For example:
  
  • A pull subscription to a Subscriber running SQL Server 2000 does not use the new security model because the Merge Agent or Distribution is created at the Subscriber.
    
  • A push subscription from a Distributor running SQL Server 2008 to a Subscriber running SQL Server 2000 uses the new security model because the Merge Agent or Distribution is created at the Distributor.
    
  • A Publisher running SQL Server 2000 with a Distributor running SQL Server 2008 does not use the new security model (for the Snapshot Agent, Log Reader Agent, or Queue Reader Agent) because the agents are created in the context of the publication database.
    
• SQL Server 2005 and SQL Server 2008 use the same security model.
  

The Web synchronization option for merge replication requires that the SQL Server Replication Listener (replisapi.dll) be copied to the virtual directory on the Internet Information Services (IIS) server used for synchronization. When you configure Web synchronization, the file is copied to the virtual directory by the Configure Web Synchronization Wizard. If you upgrade the SQL Server components installed on the IIS server, you must manually copy replisapi.dll from the COM directory to the virtual directory on the IIS server. For more information about configuring Web synchronization, see Configuring Web Synchronization.

To ensure replication settings are retained when restoring a backup of a replicated database from a previous version: restore to a server and database with the same names as the server and database at which the backup was taken.

Reference

Concepts

Other Resources