What should be your steps and consideration to monitor the SQL Server Replication?

• Set the agent profiles, schedules, properties, and notifications for replication agents.
• View and troubleshoot agent activity, including verifying when agents last ran, monitoring agent activity, and analyzing replication performance.
• Receive notification through a replication alert when an event occurs on a replication agent.
• Validate subscriptions to ensure that data values are the same at the Publisher and at Subscribers.
• Reinitialize one or all subscriptions to a publication as needed.
• Manage replication agents from a central location.

Have you ever used Replication Monitor component of SQL Server Enterprise Manager?

Yes: for viewing the status of replication agents and troubleshooting potential problems at the Distributor. Replication Monitor shows up as a node in SQL Server Enterprise Manager under the server that is enabled as a Distributor when the user is a member of the sysadmin fixed server role.

What do you know about the Heterogeneous Database Replication and have you ever tried to replicate data from SQL Server to non-SQL Server subscribers?

Yes, Heterogeneous data source means data source other than SQL Server.

SQL Server supports publishing of data using ODBC or OLEDB driver.

It also supports publishing data from Oracle to SQL Server and publishing data from SQL Server to non-SQL Server Subscribers.

Does activity need to be stopped on a database when it is published?

No. Activity can continue on a database while a publication is being created. Be aware that producing a snapshot can be resource-intensive, so it is best to generate snapshots during periods of lower activity on the database (by default a snapshot is generated when you complete the New Publication Wizard).

What happens if the Snapshot Agent has not completed when the Distribution or Merge Agent starts?

It will not cause an error if the Distribution Agent or Merge Agent runs at the same time as the Snapshot Agent.

Should I script my replication configuration?

Yes. Scripting the replication configuration is a key part of any disaster recovery plan for a replication topology.

How do I replicate data over the Internet?

Replicate data over the Internet using:

A Virtual Private Network (VPN). For more information, see Publish Data over the Internet Using VPN.

The Web synchronization option for merge replication. For more information, see Web Synchronization for Merge Replication.

Does replication work over low bandwidth connections? Does it use compression?

Yes, replication does work over low bandwidth connections. For connections over TCP/IP, it uses the compression provided by the protocol but does not provide additional compression. For Web synchronization connections over HTTPS, it uses the compression provided by the protocol and also additional compression of the XML files used to replicate changes.

In Transactional replication, If a table in database ‘A’(Publisher) is dropped, will the table get dropped in ‘B’(Subscriber)?

You cannot drop a table that is replicated. You have to first drop the article.

In Transactional Replication, If we drop a column in a table in database ‘A’, what will happen to the column in the same table in database ‘B’?

Issuing ALTER TABLE … DROP COLUMN at the Publisher, will result in the command being replicated to the Subscriber.

How can I prevent the snapshot agent failing with ‘Server execution failed’?

The value of:

“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\SQLServerAgent\Subsystems\Snapshot”

should be changed to:

C:\Program Files\Microsoft SQL Server\MSSQL\BINN\SQLREPSS.DLL,C:\Program Files\Microsoft SQL Server\80\COM\SNAPSHOT.EXE,ReplStart,ReplEvent,ReplStop,120

What is the effect of running a bulk insert command on a replicated database?

For transactional replication, bulk inserts are tracked and replicated like other inserts. For merge replication, you must ensure that change tracking metadata is updated properly.

What Options we use to secure Replication Data?

Ensure that SQL Browser is running and TCP/IP is enabled. Enforce TDE (Transparent Data Encryption) so that every data bit is encrypted.

Why you should consider Compressed Snapshots?

Compressing snapshot files in the alternate snapshot folder can reduce snapshot disk storage requirements and, in some cases, improve the performance of transferring snapshot files across the network when they are used for replication over the Internet. However, compressing the snapshot requires additional processing by the Snapshot Agent when generating the snapshot files, and by the merge agent when applying the snapshot files.

What are the different stored procedure to manage tracer tokens?

• sp_posttracertoken (used to push a token into a publication).
• sp_helptracertokens (returns a row for each tracer token that has been inserted at a publisher for a given publication).
• sp_helptracertokenhistory (returns latency information for a given token id value retrieved from either of the procedures above).
• sp_deletetracertokenhistory (removes token records from the system meta tables).

How could you replicate data between different schemas?

When we setup replication we don’t change a lot of the default values. One of the default configuration values is Replication Schema which is set to Destination Object Owner ( Subscriber Articles Owner) will be same as of Source Object Owner.

If we have Publication articles configured under the ABC schema then by default the Subscriber schema will also be ABC. By adjusting the subscriber schema, we can create the tables on the subscriber under a different schema without impacting the existing tables.

Would you please explain the output of sp_replcounters?

• Database – publisher database
• Replicated transactions – Number of transactions in the log awaiting delivery to the distribution database
• Replication rate trans/sec – Average number of transactions per second delivered to the distribution database
• Replication latency – Average time, in seconds, that transactions were in the log before being distributed
• Replbeginlsn – Log sequence number (LSN) of the current truncation point in the log
• Replendlsn – LSN of the next commit record awaiting delivery to the distribution database

What should I do if my system is running out of memory when too many agents synchronize?

You can limit the number of concurrent synchronizations; in merge this is done on the GUI or by setting the @max_concurrent_merge property of sp_addmergepublication. For other agents you’ll need to make the necessary edits to the registry.

What options are there to delete rows on the publisher and not on the subscriber?

One option is to replicate stored procedure execution instead of the actual DELETE command.  You can create two different versions of the stored procedures one on the publisher that does the delete and the other on the subscriber that does not do the delete.

Another option is to not replicate DELETE commands.

How do I drop a table that is being replicated?

First drop the article from the publication using sp_droparticle, sp_dropmergearticle, or the Publication Properties – <Publication> dialog box, and then drop it from the database using DROP <Object>.

How do I remove a table from a publication?

Remove a table from the publication using sp_droparticle, sp_dropmergearticle, or the Publication Properties – <Publication> dialog box.

Does replication work in conjunction with clustering?

Yes. No special considerations are required because all data is stored on one set of disks on the cluster.

Why can’t I run TRUNCATE TABLE on a published table?

TRUNCATE TABLE is a non-logged operation that does not fire triggers. It is not permitted because replication cannot track the changes caused by the operation: transactional replication tracks changes through the transaction log; merge replication tracks changes through triggers on published tables.

Does replication resume if a connection is dropped or do we need to reinitialize the replication?

Yes. Replication processing resumes at the point at which it left off if a connection is dropped. If you are using merge replication over an unreliable network, consider using logical records, which ensures related changes are processed as a unit.

What options are available to delete rows on the publisher and not on the subscriber?

One option is to replicate stored procedure execution instead of the actual DELETE command.  You can create two different versions of the stored procedures one on the publisher that does the delete and the other on the subscriber that does not do the delete.

Another option is to not replicate DELETE commands.

What should be our ultimate steps for Enhancing Replication Performance?

• Setting a minimum amount of memory.
• Using a separate disk drive for the transaction log for all databases involved in replication.
• Consider adding memory to servers used in replication.
• Using multiprocessor computers.
• Setting a fixed size for the distribution database.
• Publishing only the amount of data required.
• Running the Snapshot Agent only when necessary and at off-peak times.
• Placing the snapshot folder on a drive not used to store database or log files.
• Using a single snapshot folder per publication.
• Consider using compressed snapshot files.
• Reducing the distribution frequency when replicating to numerous Subscribers.
• Consider use of pull or anonymous subscriptions.
• Reduce the verbose level of replication agents to ‘0’ except during initial testing, monitoring, or debugging.
• Run agents continuously instead of on very frequent schedules.
• Consider using the –UseInprocLoader agent property.

Why backup of Publisher, Distributor and Subscriber is very important?

Publication databases are the primary, or central source, of data in a replication topology; therefore, even the most basic recovery plan should include regular backups at the Publisher. Back up the publication database and then make transaction log backups and/or differential database backups.

Backing up the Distributor involves backing up the distribution database, the msdb database, and the master system database. This allows you to recover from almost any type of failure without having to re-create publications or reconfigure replication.

Backing up the Distributor preserves the snapshot of the publication as well as the history, error, and replication agent information for your application.

Backing up the Subscriber involves backing up the subscription database and, optionally, the msdb and master system databases. The msdb and master databases need to be backed up only if it is a Subscriber that uses pull subscriptions and only if there is a need to be able to restore after a total system loss.

How can grants on the subscription database be configured to match grants on the publication database?

• Execute GRANT statements at the subscription database directly.
• Use a post-snapshot script to execute the statements.
• Use the stored procedure sp_addscriptexec to execute the statements.

What happens to permissions granted in a subscription database if a subscription is reinitialized?

By default, objects at the Subscriber are dropped and recreated when a subscription is reinitialized, which causes all granted permissions for those objects to be dropped.

What is a Local Subscriber?

A local subscriber is one that is defined with a priority setting used in conflict resolution. The priority setting is from 1 to 99.

What is a Global Subscriber?

A global subscriber has no priority and uses the distributor as the proxy for determining priority for conflict resolution.

I am running out of disk space for one of my SQL Server replicated databases. I would like to move the database files of my publication database, which is part of transactional replication, to a drive on the same server, which is has more free space.

What are the different options to do this task?

Option 1: sp_detach_db

Before using this option, we need to disable the publishing option using the sp_replicationdboption stored procedure.

if this stored procedure does not work, we need to use the sp_removedbreplication stored procedure, which removes all the replication objects in the database.

After that, we can use sp_detach_db option.

Option 2: ALTER DATABASE MODIFY FILE

Using this option we can modify the file path, but before that we have to make database offline and after changing the new path we have to make database online.

We are using replicated Subscriber databases for reporting and other purposes in our environment. As such, we have differing index needs based on the user activity on the publisher tables vs. the subscriber tables.

Unfortunately, whenever we reinitialize replication, we have missing indexes on the tables. Since the index needs are different between the publisher and subscriber, I do not also want to replicate all indexes from the publisher using the schema options that I wrote previously. How can I address these issues?

SQL Server Replication has a feature at the snapshot level called “Run additional scripts” which can be setup before and/or after the snapshot is refreshed. These options provide an opportunity to address our differing index needs between the publisher and subscriber.

For more details, You can visit this article.

T-SQL script to read Replication error log.

EXEC sys.sp_readerrorlog 0,1,'Replication','-'

We set up replication initially by using the GUI and accepting all defaults and now due to growth we need to change our default replication snapshot folder location to another drive since the current location is a local disk and cannot be expanded to accommodate our growth.

How it is possible?

For more details, You can visit this article. 

What is the role of the Immediate Sync option for SQL Server Replication?

You can see that the immediate_sync option set to TRUE is useful especially if you have the requirement of adding new subscriptions during the course of the retention period. You can also see that the data in the distribution database replication tables gets maintained even though the data is already replicated from the publisher to the subscriber.

We have two instances SERV1 and SERV2 with publication database db1 on SERV1 and subscriber database db1 on SERV2. Now we need to move the subscriber from SERV2 to SERV3 without dropping the existing subscription and creating a new subscription on the new server.

How it is possible?

• Create a full SQL Server database backup on existing Subscriber.
• Copy SQL Server backup and restore on new Subscriber with KEEP_REPLICATION option.
• Update replication tables on SQL Server Publisher database.
• Update the SQL Server replication tables on new Subscriber database.
• Update SQL Server replication tables on Distribution database.
• Modify the SQL Server Agent Job.
• Re-enable Synchronizing for the SQL Server Publication.

What is Parameterized Row Filters option of Merge Replication?

• Parameterized row filters allow different partitions of data to be sent to different Subscribers without requiring multiple publications to be created.
• A parameterized row filter uses a WHERE clause to select the appropriate data to be published.
• you specify one or both of the following system functions: SUSER_SNAME() and HOST_NAME().

What is a tracer tokens?

Tracer tokens were introduced with Sql Server 2005 transactional replication as a way to monitor the latency of delivering transactions from the publisher to the distributor and from the distributor to the subscriber(s).

A tracer token is basically a small piece of data that is inserted into the transaction log for the given publication just as if it were data for a standard database transaction and is treated basically the same way as well.

What is Article?

An article identifies a database object that is included in a publication. A publication can contain different types of articles, including tables, views, stored procedures, and other objects. When tables are published as articles, filters can be used to restrict the columns and rows of the data sent to Subscribers.

What is Publication?

A publication is a collection of one or more articles from one database. The grouping of multiple articles into a publication makes it easier to specify a logically related set of database objects and data that are replicated as a unit.

What is the use sp_replcounters?

Returns replication statistics about latency, throughput, and transaction count for each published database. This stored procedure is executed at the Publisher on any database.

What do you know about the trace token feature of Transaction Replication?

Transactional replication provides the tracer token feature, which provides a convenient way to measure latency in transactional replication topologies and to validate the connections between the Publisher, Distributor and Subscribers.

What permissions are needed to a user to monitor replication.

The replmonitor database role in the distribution database. These users can monitor replication, but cannot change any replication properties.

Does replicated database dependent on any recovery model?

Replication is not dependent on any particular recovery model. A database can participate in replication whether it is in simple, bulk-logged, or full.

Does replication encrypt data?

No. Replication does not encrypt data that is stored in the database or transferred over the network.

How we can generate Replication Script using SSMS?

• To script multiple objects from Management Studio
• Connect to the Distributor, Publisher, or Subscriber in Management Studio, and then expand the server node.
• Right-click the Replication folder, and then click Generate Scripts.
• Specify options in the Generate SQL Script dialog box.
• Click Script to File.
• Enter a file name in the Script File Location dialog box, and then click Save. A status message is displayed.
• Click OK, and then click Close.

Why does replication add a column to replicated tables?

To track changes, merge replication and transactional replication with queued updating subscriptions must be able to uniquely identify every row in every published table.

Have you ever used sp_repltrans stored procedure to find out data latency between publisher and subscriber in Transaction Replication?

Yes:

To check if replication is fine, we could run sp_repltrans on the publisher database. This displays the undistributed commands present in the publisher database. If your log reader agent is scheduled to run continuously and if this command returns no rows, replication is fine on the publisher side.

However, if your log reader agent is scheduled to run at intervals and there are changes that need to be sent to the distribution database, you would see rows returned when you execute this procedure which shows the LSNs of the transactions.

I have transactional replication configured in my production environment. The business team has requested that I do not replicate delete operations on certain articles. 

How you can achieve this?

In SSMS go to Replication -> Local Publications and right click on your publication and select Properties.  In the Publication Properties window click on ‘Articles’ and select the relevant article.  Go to “Article Properties” and select “Set Properties of Highlighted Table Article”.

In the article properties window, change the “DELETE delivery format” to “Do not replicate DELETE statements”.

Can a publication support push and pull at one time?

Yes, A publication can simultaneously support both push and pull subscriptions; however, any given subscriber is restricted to either a push or pull subscription.

Why we require to manage IDENTITY column and Why data cannot replicate because of IDENTITY column.

In replication topologies, where a publication contains an identity column and new rows can be inserted at Subscribers, additional configuration may be necessary to ensure that no duplicate identity values or constraint violations occur.

If successful, two different rows with a same identity value will exist on each replica. As a result,  each published article will contain multiple rows with the same identity values. If the identity column was defined as a primary key, or with a unique constraint, the data will not replicate.

Can we skip IDENTITY in the Replication?

Yes, we can use NOT FOR REPLICATION. The “Not For Replication” setting for identity columns allows replication to pass the ID value from the publisher to the subscriber without the subscriber creating a new ID.  Since identity columns will always generate a new number when records are inserted, this setting allows you to ensure the values on both your publisher and subscribers stay in synch.

How we should manage the IDENTITY column in Replicaton?

The simplest way to use automatic identity range handling, we must first enable the feature at the time the publication is created, assign a set of initial Publisher and Subscriber identity range values, and then assign a threshold value that determines when a new identity range is created.

Another one is, Using a primary key other than the identity column (for example, a composite key or a rowguid column), if an identity column is not necessary. This strategy eliminates the overhead of managing identity columns on the replicated data.

How to enable Replication Monior?

In Enterprise Manager, right-click on a SQL Server, and click Properties.

On the Replication tab, select Show Replication Monitor Group. Optionally, you can also select to add this server as a Distributor in the Replication Monitor Group.

Why is primary key needed in Transactional replication?

The reason is in the subscriber, rows are updated/deleted one-by-one using primary key.

Which all database objects can be included in replication?

• Tables
• Partitioned Tables
• Stored Procedures – Definition (Transact-SQL and CLR)
• Stored Procedures – Execution (Transact-SQL and CLR)
• Views
• Indexed Views
• Indexed Views as Tables
• User-Defined Types (CLR)
• User-Defined Functions (Transact-SQL and CLR)
• Alias Data Types
• Full text indexes
• Schema Objects

Can we rename a database used in Publication or subscription

No: we would need to drop the publications, rename the database and re-configure replication all over again.

Have you tried to replicate Database User Login information?

No: directly it is not possible, We require to create a DTS\SSIS package to transfer logins and passwords from a Publisher to one or more Subscribers.

Are tables locked during snapshot generation?

• The length of time that the locks are taken depends on the type of replication used:
• For merge publications, the Snapshot Agent does not take any locks.
• For transactional publications, by default the Snapshot Agent takes locks only during the initial phase of snapshot generation.
• For snapshot publications the Snapshot Agent takes locks during the entire snapshot generation process.

How do I manage constraints on published tables?

The NOT FOR REPLICATION option is specified by default for foreign key constraints and check constraints, it skips by the Replication Agent operations.

Can multiple publications use the same distribution database?

Yes. There are no restrictions on the number or types of publications that can use the same distribution database.

If you have multiple publications, you can configure multiple distribution databases at the Distributor to ensure that the data flowing through each distribution database is from a single publication.

How do I add or change indexes on publication and subscription databases?

Indexes can be added at the Publisher or Subscribers with no special considerations for replication.

How do I move or rename files for databases involved in replication?

A moving or renaming database files required detaching and reattaching the database. Because a replicated database cannot be detached, replication had to be removed from these databases first.

Data is not being delivered to Subscribers, what can be the possible reasons?

• The table is filtered, and there are no changes to deliver to a given Subscriber.
• One or more agents are not running or are failing with an error.
• Data is deleted by a trigger, or a trigger includes a ROLLBACK statement.
• A transactional subscription was initialized without a snapshot, and changes have occurred on the Publisher since the publication was created.
• Replication of stored procedure execution for a transactional publication produces different results at the Subscriber.
• The INSERT stored procedure used by a transactional article includes a condition that is not met.
• Data is deleted by a user, a replication script, or another application.

T-SQL script to check status of Replication Distribution Agents.

SELECT 
    a.name PublicationName
    , a.publication Publication
    , ditosu.comments AS MessageText
    , ditosu.[time] CommandDate
    , ditosu.xact_seqno xact_seqno
FROM MSdistribution_agents a
    INNER JOIN MSpublications p ON a.publisher_db = p.publisher_db
        AND a.publication = p.publication
    INNER JOIN MSdistribution_history ditosu ON ditosu.agent_id = a.id
ORDER BY ditosu.[time] DESC

SELECT 
	[error_text]
	,[time]	
FROM distribution..MSrepl_errors
ORDER BY [time] DESC

What should be your general steps to Implementing any type of Replication?

• Configuring Replication: Identify the Publisher, Distributor, and Subscribers in your topology.
• Publishing Data and Database Objects: Create the publication and define the data and database object articles in the publication, and apply any necessary filters to data that will be published.
• Subscribing to Publications: Create push, pull, or anonymous subscriptions to indicate what publications need to be propagated to individual Subscribers and when.
• Generating the Initial Snapshot: Indicate where to save snapshot files, whether they are compressed, and scripts to run before or after applying the initial snapshot.
• Applying the Initial Snapshot: Apply the snapshot automatically by synchronizing the subscription using the Distribution Agent or the Merge Agent.
• Synchronizing Data: Synchronizing data occurs when the Snapshot Agent, Distribution Agent, or Merge Agent runs and updates are propagated between Publisher and Subscribers.

What are your general steps to configure a Replication?

• Identifying a Distributor.
• Creating a distribution database on the Distributor.
• Enabling Publishers that will use the Distributor.
• Enabling publication databases.
• Enabling Subscribers that will receive published data.

What is called a Subscription Process?

A subscription is the request for data or database objects to be published to a specific Subscriber. A Subscriber can have several subscriptions to different publications.

A subscription defines what publication will be replicated, where and when. A subscription can be created either at the Publisher or at the Subscriber.

What is a Push Subscription?

With a push subscription, the Publisher propagates changes to a Subscriber without a request from the Subscriber. Changes can be pushed to Subscribers on demand, continuously, or on a scheduled basis. By default, the Distribution Agent or Merge Agent runs at the Distributor.

Because a Subscriber must explicitly be enabled at the Publisher to receive a push subscription, push subscriptions are known as named subscriptions.

What is a Pull Subscription?

With a pull subscription, the Subscriber requests changes made at the Publisher. Pull subscriptions allow the user to determine when the data changes are synchronized. By default, the Distribution Agent or the Merge Agent runs at the Subscriber.

Because a Subscriber must explicitly be enabled at the Publisher to receive a push subscription, pull subscriptions are known as named subscriptions.

What is an Anonymous Subscription?

An anonymous subscription is a type of pull subscription. Detailed information about the subscription and the Subscriber is not stored at the Publisher when using an anonymous subscription.

When we should use Push Subscription?

• Data will typically be synchronized on demand or on a frequently recurring schedule.
• Publications require near real-time movement of data without polling.
• The higher processor overhead at a Publisher using a local Distributor does not affect performance.
• You need easier administration from a centralized location (the Distributor).

When we should use Pulll Subscription?

• Administration of the subscription will take place at the Subscriber.
• The publication has a large number of Subscribers, and when it would be too resource-intensive to run all the agents at one site or all at the Distributor.
• Subscribers are autonomous, disconnected, and/or mobile. Subscribers will determine when they will connect to the Publisher/Distributor and synchronize changes.

When we should use Anonymous Subscriptions?

• Applications have a very large number of Subscribers.
• You do not want the overhead of maintaining extra information at the Publisher or Distributor.
• If Subscribers use the Internet to access publications.

Can we apply filters on a table to be published?

Yes, we can apply different filters on a table which is going to publish.

Different types of filter likes, Row filters, Column filter, Dynamic filter, Static filter, Join filter.

Can you modify the data of Subscriber?

Yes, With snapshot replication or transactional replication, replicated data is by default read only; however, you have the ability to modify replicated data at the Subscriber by using updatable subscriptions.

What do you know about Immediate Updating?

Immediate updating allows snapshot replication and transactional replication Subscribers to update the replicated data at the Subscriber and send those changes back to the Publisher and to other Subscribers.

What do you know about Queued Updating?

Queued updating allows snapshot replication and transactional replication Subscribers to modify published data without requiring an active network connection to the Publisher.

When you create a publication with the queued updating option enabled and a Subscriber performs INSERT, UPDATE, or DELETE statements on published data, the changes are stored in a queue. The queued transactions are applied asynchronously at the Publisher when network connectivity is restored.

Can we use Data Transformation Service (DTS Package) for publishing a data?

Yes, we can create a DTS package for replication either using the replication wizards or programmatically, such as using Microsoft Visual Basic.

What do you know about Alternate Synchronizing Partner?

Subscribers to merge publications can synchronize with servers other than the Publisher at which the subscription originated. Synchronizing with alternate partners provides the ability for a Subscriber to synchronize data even if the primary Publisher is unavailable.

This feature is also useful when mobile Subscribers have access to a faster or more reliable network connection with an alternate synchronization partner.

What is error 20598 for DELETEs?

• A error 20598 is due to a missing row on the subscriber and there are two scenarios that can cause this error:
• An UPDATE command cannot be replicated, because there is no record that matches the update condition on the subscriber.
• A DELETE command cannot be replicated, because there is no record that matches the delete condition on the subscriber.

How to fix error 20598 for DELETEs?

• On the subscriber, insert a dummy record with the exact primary key value of the deleted row. This PK value can be retrieved using sp_browsereplcmds.
• The other option is to modify the sp_MSDel_<schema><table_name> to comment out the error emitting codes when @@rowcount = 0.

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.