What is the use of XACT_ABORT Parameter?

XACT_ABORT ON ensures that any errors encountered during execution at the Publisher cause the entire execution to be rolled back, avoiding the Distribution Agent failure.

If XACT_ABORT is set to OFF, and an error occurs during execution of the procedure at the Publisher, the same error will occur at the Subscriber, causing the Distribution Agent to fail.

What is a Merge Replication?

Merge replication, like transactional replication, typically starts with a snapshot of the publication database objects and data. Subsequent data changes and schema modifications made at the Publisher and Subscribers are tracked with triggers. The Subscriber synchronizes with the Publisher when connected to the network and exchanges all rows that have changed between the Publisher and Subscriber since the last time synchronization occurred.

Merge replication allows various sites to work autonomously and later merge updates into a single, uniform result. Because updates are made at more than one node, the same data may have been updated by the Publisher and by more than one Subscriber.

In which situations, Merge Replication is suitable?

• Multiple Subscribers might update the same data at various times and propagate those changes to the Publisher and to other Subscribers.
• Subscribers need to receive data, make changes offline, and later synchronize changes with the Publisher and other Subscribers.
• Each Subscriber requires a different partition of data.
• Conflicts might occur and, when they do, you need the ability to detect and resolve them.
• The application requires net data change rather than access to intermediate data states.

What should be your best practice for tracking Merge Replication?

To track changes, merge replication must be able to uniquely identify every row in every published table. To accomplish this merge replication adds the column rowguid to every table.

What is a Snapshot Replication?

Snapshot replication distributes data exactly as it appears at a specific moment in time and does not monitor for updates to the data. When synchronization occurs, the entire snapshot is generated and sent to Subscribers.

Snapshot replication can be used by itself, but the snapshot process is also commonly used to provide the initial set of data and database objects for transactional and merge publications.

How Snapshot replication is differ than other type of replication and In which situation, it is recommended?

Data is mostly static and does not change often. When it does change, it makes more sense to publish an entirely new copy to Subscribers.

It is acceptable to have copies of data that are out of date for a period of time.

Replicating small volumes of data in which an entire refresh of the data is reasonable.

Snapshot replication is mostly appropriate when you need to distribute a read-only copy of data, but it also provides the option to update data at the Subscriber.

Snapshot replication has a lower continuous overhead on the Publisher than transactional replication, because incremental changes are not tracked. However, if the dataset set being replicated is very large, it will require substantial resources to generate and apply the snapshot. Consider the size of the entire data set and the frequency of changes to the data when evaluating whether to utilize snapshot replication.

Would you please explain basic, how Snapshot works?

Snapshots can be generated and applied either immediately after the subscription is created or according to a schedule set at the time the publication is created. The Snapshot Agent prepares snapshot files containing the schema and data of published tables and database objects, stores the files in the snapshot folder for the Publisher, and records tracking information in the distribution database on the Distributor.

You specify a default snapshot folder when you configure a Distributor, but you can specify an alternate location for a publication instead of or in addition to the default.

What do you require to plan before setup a Snapshot Replication?

• Transferring and storing snapshot files:
• You have the option of storing snapshot files in a location other than or in addition to the default location, which is often located on the Distributor. Alternate locations can be on another server, on a network drive, or on removable media.
• Scheduling snapshots:
• To plan the optimum schedule for running the Snapshot Agent, estimate the length of time it takes the Snapshot Agent to complete the snapshot. Because the snapshot is created using bcp, perform a test bulk copy of your data set and time how long it takes to complete. If your data set is very large, perform the bulk copy on a sample of the data set and extrapolate the lapse time to the entire data set.

Before Transaction Replication, what should be your planning?

• Transaction log space.
• Disk space for the distribution database.
• Primary keys for each table to be published.
• Immediate updating and queued updating.
• Transforming replicated data.
• text and image data types in transactional replication.
• Identity ranges.
• Constraints and NOT FOR REPLICATION.

Before Merge Replication, what should be your planning?

• Timestamp columns.
• Identity ranges.
• Data integrity.
• Primary keys.
• Synchronizing with alternate synchronization partners.
• Row-level tracking and column-level tracking.
• Triggers and business rules.
• text and image data types in merge replication.
• Conflict resolution.
• Occassional maintenance for online/offline applications

Before planning to Replication, What should be your consideration?

• Whether replicated data needs to be updated, and by whom.
• Your data distribution needs regarding consistency, autonomy, and latency.
• The replication environment, including business users, technical infrastructure, network and security, and data characteristics.
• Types of replication and replication options.
• Replication topologies and how they align with the types of replication.

Why you should use a separate disk drive for all databases which are involved in Replication?

This applies to the publication database, the distribution database, and the subscription database. You can decrease the time it takes to write transactions by storing the log files on a disk drive different than the one used to store the database. You can mirror that drive, using  a Redundant Array of Inexpensive Disks (RAID)-1, if you require fault tolerance.

Use RAID 0 or 0+1 (depending on your need for fault tolerance) for other database files. This is a good practice regardless of whether or not replication is being used.

Can you tell me some of the common replication DMV’s and their use?

• sys.dm_repl_articles – Contains information about each article being published. It returns data from the database being published and returns a row for each object being published in each article.
• sys.dm_repl_schemas – Contains information about each table and column being published. It returns data from the database being published and returns one row for each column in each object being published
• sys.dm_repl_traninfo – Contains information about each transaction in a transactional replication.

I have transactional replication configured in my production environment with multiple subscribers.  The business team has requested that one of the subscriptions be reinitialized, because they think there is some missing data.

What are the different option to reinitialized subscriptions?

Option 1: Using SQL Server Management Studio (SSMS).

In SSMS go to Replication -> Local Publications -> Locate your publication and expand it.

To do this, right click that subscription and select the ‘reinitialize’ option.

Option 2: Using Replication Monitor

In SSMS go to Replication -> right click on replication and select ‘Launch Replication Monitor’.

On the left pane, under ‘My publishers’, click on the publisher node and expand to get a list of the subscriptions.

In the ‘All Subscriptions’ tab, you need to select the appropriate subscription and click on ‘Reinitialize Subscription’.

How you can solve Error: Could not find stored procedure error and how to recover.

How you can recreate the missing stored procedures?

We can use sp_scriptpublicationcustomprocs system stored procedure which has been available since SQL Server 2000 Service Pack 1.

The only parameter for the sp_scriptpublicationcustomprocs is the publication name and this stored procedure must be executed on the published database.

EXEC sp_scriptpublicationcustomprocs @publication='Publication_Name';

The output from this stored procedure will be the creation code of INSERT, UPDATE, and DELETE stored procedures for each article that belongs to the ‘Publication_Name’ publication.

T-SQL script to check status of Replication.

SELECT 
    publisher
    , publisher_db
    , publication
    , agent_name
    , last_distsync
    , CASE
        WHEN status = 1 THEN 'Started'
        WHEN status = 2 THEN 'Succeeded'
        WHEN status = 3 THEN 'In progress'
        WHEN status = 4 THEN 'Idle'
        WHEN status = 5 THEN 'Retrying'
        WHEN status = 6 THEN 'Failed'
    END AS StatedStates    
FROM distribution..MSreplication_monitordata

What is Replication in SQL Server?

As per the msdn help,

Replication is a set of technologies for copying and distributing data and database objects from one database to another and then synchronizing between databases to maintain consistency. Using replication, you can distribute data to different locations.

Database replication is the frequent electronic copying data from a database in one computer or server to a database in another so that all users share the same level of information. The result is a distributed database in which users can access data relevant to their tasks without interfering with the work of others.

What is Publishers?

The Publisher is a server that makes data available for replication to other servers. In addition to being the server where you specify which data is to be replicated, the Publisher also detects which data has changed and maintains information about all publications at that site.

What is Distributors?

Distributor is a bridge between publisher and subscriber. Distributor gathers all the published data and holds it until it sends it across to all subscriber. So as it is a bridge who sits in between publisher and subscriber, it supports multiple publisher and subscriber concept.

What is Subscribers?

Subscribers are servers that receive replicated data and it is the end source or the final destination to which data has to be transmitted.

What is a Snapshot Agent?

The Snapshot Agent is used with all types of replication. It prepares the schema and the initial bulk copy files of published tables and other objects, stores the snapshot files, and records information about synchronization in the distribution database. The Snapshot Agent runs at the Distributor.

What is a Log Reader Agent?

The Log Reader Agent is used with transactional replication. It moves transactions marked for replication from the transaction log on the Publisher to the distribution database. Each database published using transactional replication has its own Log Reader Agent that runs on the Distributor and connects to the Publisher (the Distributor can be on the same computer as the Publisher).

What is a Distribution Agent?

The Distribution Agent is used with snapshot replication and transactional replication. It applies the initial snapshot to the Subscriber and moves transactions held in the distribution database to Subscribers. The Distribution Agent runs at either the Distributor for push subscriptions or at the Subscriber for pull subscriptions.

What is a Merge Agent?

The Merge Agent is used with merge replication. It applies the initial snapshot to the Subscriber and moves and reconciles incremental data changes that occur. Each merge subscription has its own Merge Agent that connects to both the Publisher and the Subscriber and updates both. The Merge Agent runs at either the Distributor for push subscriptions or the Subscriber for pull subscriptions.

What is a Queue Reader Agent?

The Queue Reader Agent is used with transactional replication with the queued updating option. The agent runs at the Distributor and moves changes made at the Subscriber back to the Publisher. Unlike the Distribution Agent and the Merge Agent, only one instance of the Queue Reader Agent exists to service all Publishers and publications for a given distribution database.

What are the different types of Replication available in SQL Server?

• Transactional Replication
• Merge Replication
• Snapshot Replication

What is the Transactional Replication?

SQL Server Transactional replication is typically used in server-to-server scenarios that require high throughput, including improving scalability and availability, data warehousing and reporting, integrating data from multiple sites, integrating heterogeneous data, and offloading batch processing.

Transactional replication typically starts with a snapshot of the publication database objects and data. As soon as the initial snapshot is taken, subsequent data changes and schema modifications made at the Publisher are usually delivered to the Subscriber as they occur (in near real time).

The data changes are applied to the Subscriber in the same order and within the same transaction boundaries as they occurred at the Publisher; therefore, within a publication, transactional consistency is guaranteed.

In which, situation Transactional Replication is suitable?

• You want incremental changes to be propagated to Subscribers as they occur.
• The application requires low latency between the time changes are made at the Publisher and the changes arrive at the Subscriber.
• The application requires access to intermediate data states. For example, if a row changes five times, transactional replication allows an application to respond to each change (such as firing a trigger), not simply the net data change to the row.
• The Publisher has a very high volume of insert, update, and delete activity.
• The Publisher or Subscriber is a non-SQL Server database, such as Oracle.

How Transactional Replication works?

Transactional replication is implemented by the SQL Server Snapshot Agent, Log Reader Agent, and Distribution Agent. The Snapshot Agent prepares snapshot files containing schema and data of published tables and database objects, stores the files in the snapshot folder, and records synchronization jobs in the distribution database on the Distributor.

The Log Reader Agent monitors the transaction log of each database configured for transactional replication and copies the transactions marked for replication from the transaction log into the distribution database, which acts as a reliable store-and-forward queue. The Distribution Agent copies the initial snapshot files from the snapshot folder and the transactions held in the distribution database tables to Subscribers.

Incremental changes made at the Publisher flow to Subscribers according to the schedule of the Distribution Agent, which can run continuously for minimal latency, or at scheduled intervals.

What do you know about the peer-to-peer transaction publication topology?

• Each location has identical data and acts as both a Publisher and Subscriber.
• The same row can be changed only at one location at a time.
• This topology is best suited for server environments requiring high availability and read scalability.

What do you know about the Bidirectional Transactional Replication?

Bidirectional transactional replication is a specific transactional replication topology that allows two servers to exchange changes with each other: each server publishes data and then subscribes to a publication with the same data from the other server.

Is it possible to publish the execution of Stored Procedure?

If you have one or more stored procedures that execute at the Publisher and affect published tables, consider including those stored procedures in your publication as stored procedure execution articles. The definition of the procedure (the CREATE PROCEDURE statement) is replicated to the Subscriber when the subscription is initialized; when the procedure is executed at the Publisher, replication executes the corresponding procedure at the Subscriber.

The stored procedure definition at the Publisher is propagated to each Subscriber. However, you can also modify the stored procedure at the Subscriber. This is useful if you want different logic to be executed at the Publisher and Subscriber.