What is Transaction Replication in SQL Server?

Basically, the transaction replication works between N number of Servers. If one server is being
changed by a committed transaction, the rest servers simultaneously updated through transaction
replication. The server on which the transaction is performed is known as the primary server or
publisher and the servers that receive the committed transaction is known as secondary servers or
subscribers. The transaction replication provides an exceptional backup to the regular database
changes.
Mainly, the transactional replication starts by receiving a primary server snapshot and thereafter it is
copied to the secondary servers. Then all the changes of primary server are logged in real time and
replicated on the secondary servers. Transactional replication doesn’t copy only effected changes,
but it does replicate to each change through replication agents.

See more information and the steps for creating transactional repliaction :

https://docs.microsoft.com/en-us/sql/relational-databases/replication/tutorial-replicating-data-
between-continuously-connected-servers?view=sql-server-ver15

Advantages or use cases for transactional replication:

 Transactional replication used for the critical databases which require less downtime
 It is useful when where data need on an incremental basis
 It is useful for the database where a large amount of data changes frequently

Limitations:
 cannot drop a table
 cannot drop a pk
 cannot rename a table
 cannot truncate a table
 Transactional Replication Concerns:
Does the transaction replication have any load on the primary server when its moving data out?
There will be an impact on the publisher but depending on how you set up your transactional
replication schema that can be very small. One big problem that can become an issue is if you have a
local distributor, especially if you are dealing with a large amount of publications being replicated to
multiple subscribers in a push configuration. If that is the case, one way to alleviate the server impact
is to have a remote distributor.

Also, by design with transactional replication the Log Reader Agent is doing just that: reading the
transaction log of the publisher. There are many strategies to reduce this impact, such as replicating
stored procedure executions instead of the resulting data.

2.If the subscriber server goes down, will the primary still function

Yes, the publisher will still function. Commands to get replicated will be queuing up and depending
on how long your retention is setup for and how long the subscriber is disconnected you may need to
reinitialize the subscription.

Requirements for MS SQL Server

Replication
The following ports must be opened for inbound traffic:
TCP 1433, 1434, 2383, 2382, 135, 80, 443;
UDP 1434.
Note : This is important to configure Windows firewall and enable the
appropriate ports for inbound traffic on each host before installing MS
SQL Server. Hosts attended in MS SQL replication must resolve each other
by a hostname.
Before configuring MS SQL Server replication, the following software must
be installed for MS SQL Server:
 .NET Framework – a set of libraries
 MS SQL Server – the database server software
 MS SQL Server Management Studio (SSMS) – software for managing
MS SQL databases with the GUI (graphical user interface).
 Configuring the Environment
Check that you have installed the features required for MS SQL Server
replication once the MS SQL Server installation is complete. Database
engine services, such as SQL Server replication and R-Services, must be
selected during MS SQL Server installation. The default installation path is
used in this example (C:\Program Files\Microsoft SQL Server).

Other settings:
 The mixed authentication mode (Windows authentication and MS
SQL Server authentication)
 Data root directory: D:\MSSQL_Server\
 System database directory:
D:\MSSQL_Server\MSSQL13.MSSQLSERVER1\MSSQL\Data
 User database directory:
D:\MSSQL_Server\MSSQL13.MSSQLSERVER1\MSSQL\Data
 User database log directory:
D:\MSSQL_Server\MSSQL13.MSSQLSERVER1\MSSQL\Data
 Backup directory:
D:\MSSQL_Server\MSSQL13.MSSQLSERVER1\MSSQL\Backup

Preparing for MS SQL Server

Replication
You have to configure the servers before you can start database
replication. In our example, one Windows account will be used for MS SQL
Server replication agents.
Create the mssql user on both servers and set the same password.
The mssql user is a member of the following groups in this example:
 Administrators (local administrators on local machines, not domain
administrators)
 SQLRUserGroupMSSQLSERVER1
 SQLServer2005SQLBrowserUser$MSSQL01
You can edit users and groups by pressing Win+R, opening CMD and
running the lusrmgr.msc command.
Two Windows Server machines used in this example are not in Active
Directory. If you use Active Directory, you can create the mssql user on the
domain controller.

Configuring the Publisher

1.The Publisher should be configured on the main server where the
master database to be replicated is stored. Select Replication, right
click Local Publications and, in the context menu, select New Publication.
New Publication Wizard opens.
2.Publication Database. Select the database you want to replicate.
Hit Next for each step in the wizard to continue.
3.Publication Type. For this step, you can select MS SQL Server
replication types for a database. Select transactional publication.
4.Articles. Select the needed objects, such as tables, procedures, views,
indexed views and user defined functions to publish as articles. It is
possible to select replication of the custom fields in the tables and select
article properties if needed.
5. In this below screen shot I select Do not replicate Delete statement for
Delete delivery format , because I don’t want to delete the data in the
target DB as we are maintaining archival data.

Filter Table Rows. No filters are added in this example (this is the default
configuration of filters). You can add filters if needed.
6.Snapshot Agent. For this step, you should specify when to run the
Snapshot Agent. Let’s configure the Agent to run immediately. Tick the
checkbox Create a snapshot immediately and keep the snapshot available to
initialize subscriptions.
7.Agent Security. Tick Use the security settings from the Snapshot Agent.
Click the Security Settings button to select the account under which the
Agent will run.
In the opened Snapshot Agent Security window, enter the credentials of
the mssql Windows user (we need to create this user as prerequisite).
Select connect to the Publisher By impersonating the process account. Hit
OK to save settings and go back to the wizard.

In the below screen shot I selected Run under the Sql server Agent service
account, this is not recommended security.
After defining the needed user, you can see this user in the Snapshot
Agent and Log Reader Agent sections.

8. Complete the Wizard. Check your publication configuration and

hit Finish to create a new publication.

The publication is now created and you can see the publication in Object
Explorer by going to Replication > Local Publications.

Configuring the Subscriber

MS SQL Server replication can be either pull or push replication. If you
configure push replication, you should configure the Subscriber to run
agents on the main database server (MSSQL01 in this case). If you
configure pull replication, the Subscriber must be configured to run
agents on the second machine (MSSQL02), i.e. the machine on which the
database replica will be created. Let’s configure push replication and
create a new subscription on the first MS SQL Server
(MSSQL01\MSSQLSERVER1) where the master database resides.
In Object Explorer go to Replication, right click Local Subscriptions and,
in the context menu, select New Subscriptions.

The New Subscription Wizard opens.

1.Publication. Select the publication for which to create a new
subscription. In our example, the name of the Publisher is PublisherDB
and the publication name (that was created earlier) is new Publication.
Hit Next for each step in the wizard to continue.
Distribution Agent Location. For this step, you have to select the
replication type by selecting either push subscription or pull subscription.
In our example, we want all agents to run on the source server side,
hence, the first option is selected to create push subscription. It allows you
to manage MS SQL Server replication centrally.
Subscribers. By default, the server on which you run the wizard is
displayed as the Subscriber and the subscription database is not defined.
Let’s add a new subscriber and select a subscription database located on
the second database server (Azure Sql DB). Click Add Subscriber and, in the
context menu, select Add SQL Server Subscriber.
In the popup window, enter the credentials for the Azure SQL server and
hit Connect.
Tick the checkbox of your second server on which your database replica
will be stored (MSSQL02\MSSQLSERVER2) and, in the Subscription
Database drop-down menu, select a new database or an existing database
restored from a backup that will be used as a database replica. In our
example, the AdventureWorks2016r was created on the second server by
restoring the main (source) AdventureWorks2016 database from a backup
to start replication. Replication is started by replicating only new data but
not by copying the entire database after starting the replication process.
Thus, AdventureWorks2016r is selected as a subscription database in the

current example.
Distribution Agent Security. Click the button with three dots (…) and
select the user and other security options for the Distribution Agent.
In the opened Distribution Agent Security window, set the Distribution
Agent to run on the MSSQL01 host under the mssql user account. Enter the
password for the mssql Windows user. Select Connect to the Distributor by
impersonating the process account and select Connect to the Subscriber run
on the AZURE server user account. Hit OK to save settings.

Now subscription properties are set.

Synchronization Schedule. Select the Agent that is located on the
Distributor to Run continuously for the current Subscriber.
Initialize Subscriptions. Tick the Initialize checkbox and in the drop-down
menu select immediately  for when to initialize subscription. You can also
select the Memory Optimized  option if needed.
Complete the Wizard. You can check your subscriptions settings and
hit Finish to create the subscription.

Azure Data Sync

What is Data sync:
SQL Data Sync is Azure service which allows you to synchronize data across
multiple Azure SQL databases and on-premises SQL Server databases .
How it works:
SQL Data Sync uses a hub- spoke topology to synchronize data.

1.Data Sync Works By Tracking Data Changes By Using Insert, Update And Delete
Triggers In A Separate Table In The User Database. Then Sync Db Takes Care Of
Merging The Tracked Data To All Other Member Databases
Note: Data Sync Related Tables Will Be Created In Syncdb ,Source And Destination
Databases
Basic Requirements:
1.You have to open outbound TCP port 1433 in the firewall for data sync client
agent communicate with the server
2.Add your Public IP into firewall white list
3.Set the Allow access to Azure services to ON
4. Need Primary key for every tables which is going to participate in data sync

Limitations:
1. Currently Azure SQL Data Sync does not support Azure SQL Database
Managed Instance
2. Data sync doesn't support Azure active directory authentication
3. Data sync is not supported for SQL Server express editions
4. Data sync doesn't support tables with the same name but different schema
a. Ex:dbo
b. log
5. schema changes are not automatically synced.
6. we have to manually add column/remove column in destination database
when a new column is created or dropped in metadata sync group. and
Need to refresh schema in the portal.
7. Check datatypes are supported or not by data sync
8. A table participating in data sync can't have an identify column that's not
the primary key
9. The datetime data type cannot be used for a primary key
10.Existing triggers on the source tables aren't provisioned.
 11.the names of objects (databases, tables, and columns) can't contain the
printable characters period (.), left square bracket ([), or right square
bracket (]).
12.Maximum tables in one sync group is 500
13.Maximum columns that one table can have in one sync group is 1000
15.
14.Maximum number of sync groups any database can belong to is 5 a.

17.
16.Maximum number of endpoints in a single sync group is 30 a.
18.Columns up to 24 MB in size can be synced
19.Minimal sync interval is 5 minutes
20.Make Sure .Net 4.5 or above Installed (for data sync client agent)
21.Views and stored procedures aren't created on the destination database.
22.Columns with User Defined Data Types aren't supported
23.Indexes on XML type columns, CHECK constraints aren't provisioned.
24.Data Sync can't sync read-only or system-generated columns
A. Computed columns
B. System-generated columns for temporal tables.

Demo Environment: Azure sql database to Onpremise [Bidirectional]

Azure SQL Databases Bi Directional On Premise SQL Server

Sqlazure Testdb

syncdb
xxx.database.windows.net domain\user

Common Reasons why data sync get fails?

 1. Check data sync agent is in online or not.
2. Check enough drive space is there or not on which drive you installed data
sync agent
3. If data sync service account got deleted and disabled or service stopped
4. By changing the data sync agent token key
5. For not following limitations

Note: All the Limitations will be changed from time to time.