Question: What is the Transactional Replication Supported Version Matrix?

Answer: Most of the projects I do are about Comprehensive Database Performance Health Check. When we start a new project we have limited data and our workflow is not intense. However, I often like to get involved with projects which are not related to performance tuning when I have enjoyed working with them earlier.

Recently, while working on the health check project, one of the realizations which we had with our client was that we need to have another instance of our server where we can forward our read requests. Now the ideal solution was to configure AlwaysOn but that was not something would work out due to licensing issues of the version which the client had available. Additionally, the need for the data was near real-time hence we can’t do the traditional backup/restore or log shipping.

After carefully thinking we decided to opt for the replication. When we started to work with the replication the very first question raised was about the supported version for the transactional replication.

The rules for the supported versions are pretty simple and clearly written on the Replication Backward Compatibility.

The rules for transactional replications are:

• A Distributor can be any version as long as it is greater than or equal to the Publisher version
• A Publisher can be any version as long as it less than or equal to the Distributor version
• A Subscriber to a transactional publication can be any version within two versions of the Publisher version

In short:

• Publisher version <= Distributor version
• Subscriber (two versions) => Publisher or Subscriber (two versions) <= Publisher

For example, our client was using SQL Server 2012 for a publisher. We can use either SQL Server 2012, 2014, 2016, 2017 or 2019 as a distributor and SQL Server 2008/R2, 2012, 2014, or 2016 as a subscriber. You can see the complete matrix over the Transactional Replication Matrix.

Reference: Pinal Dave (http://blog.SQLAuthority.com)

First appeared on What is Transactional Replication Supported Version Matrix? – Interview Question of the Week #274

It is not possible to Propagation of Compatibility Level in AlwaysOn or mirroring from primary to secondary mirroring. Well, that’s what I wanted to share in this blog post.

I often get the question in Comprehensive Database Performance Health Check about Propagation of Compatibility Level in AlwaysOn. Let us discuss that today. Let us say that if you have a primary server where you are modifying compatibility level, will that automatically reflect on the secondary server. The answer is no, it is not going to happen.

If you want to change the compatibility level of your secondary server, you will have to failover your workload from a primary server to the secondary server and change your compatibility on the secondary server, and later on failback if you want to use your other server.

Here are my few recent videos and I would like to know what is your feedback about them. You can subscribe to my youtube channel here.

• Forwarded Records and Performance – SQL in Sixty Seconds #155
• Hide Code in SSMS – SQL in Sixty Seconds #154
• Zoom in SSMS – SQL in Sixty Seconds #153
• Transfer Schema of Table – SQL in Sixty Seconds #152
• Find a Table in Execution Plan – SQL in Sixty Seconds #151

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – AlwaysOn and Propagation of Compatibility Level

How to Find Instance Name for Availability Group Listener? I was recently asked this by DBA at  Comprehensive Database Performance Health Check. Well, the question is very valid if you are familiar with how Availability Group Listener works.

If you are connected to an Availability Group listener, the name displayed in Object Explorer and Properties may be different from what your instance name is actually. In this case, you may have to just use the T-SQL for the same.

Here is the T-SQL for the same.

SELECT @@Servername

Once you run the command above, it will give you a different server name from the Availability Group Listener name. Well, that’s it for today. What do you think of this small but very important blog post?

If you liked this blog, please do not forget to subscribe to my YouTube Channel – SQL in Sixty Seconds.

Here are my few recent videos and I would like to know what is your feedback about them.

• Read Only Tables – Is it Possible? – SQL in Sixty Seconds #179
• One Scan for 3 Count Sum – SQL in Sixty Seconds #178
• SUM(1) vs COUNT(1) Performance Battle – SQL in Sixty Seconds #177
• COUNT(*) and COUNT(1): Performance Battle – SQL in Sixty Seconds #176
• COUNT(*) and Index – SQL in Sixty Seconds #175
• Index Scans – Good or Bad? – SQL in Sixty Seconds #174
• Optimize for Ad Hoc Workloads – SQL in Sixty Seconds #173
• Avoid Join Hints – SQL in Sixty Seconds #172
• One Query Many Plans – SQL in Sixty Seconds #171

Reference: Pinal Dave (http://blog.SQLAuthority.com)

First appeared on SQL SERVER – Find Instance Name for Availability Group Listener

SQL Server 2022 introduces an intriguing feature – the Query Store for secondary replicas. This feature extends the Query Store functionality from primary replicas to secondary replica workloads. In this post, we explore this feature, how to enable it, and some considerations regarding its usage. This feature is currently in preview, meaning it’s not yet intended for production deployments.

What is the Query Store for Secondary Replicas?

The Query Store for secondary replicas feature allows secondary replicas to send query execution information back to the primary replica, which would typically be stored in the Query Store. The primary replica then persists this data within its own Query Store. This results in a shared Query Store between the primary and all secondary replicas. The Query Store exists on the primary replica and stores data for all replicas together.

Enabling the Query Store for Secondary Replicas

Before enabling the Query Store for secondary replicas, you must enable trace flag 12606. Here’s how you can enable the trace flags:

• Launch SQL Server Configuration Manager in Windows.
• Right-click on the SQL Server instance service for your SQL Server 2022 (16.x) instance in the list of SQL Server Services and select Properties.
• Select the Start Parameters tab and add the values: -T12606.

Remember, you must restart the SQL Server instance service for these changes to take effect.

Setting up the Query Store for Secondary Replicas

Firstly, you must have an Always On availability group on your SQL Server instance. If Query Store is not already enabled and in READ_WRITE mode on the primary replica, you must enable it with the following commands:

ALTER DATABASE [DBName] SET QUERY_STORE = ON;
GO
ALTER DATABASE [DBName] SET QUERY_STORE
( OPERATION_MODE = READ_WRITE );

To enable the Query Store on all secondary replicas, connect to the primary replica and execute the following:

ALTER DATABASE [DBName]
FOR SECONDARY SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE);
GO

To disable the Query Store on all secondary replicas, you can use a similar command:

ALTER DATABASE [DBName]
FOR SECONDARY SET QUERY_STORE = OFF;
GO

Conclusion

We must consider the performance implications as we delve into using the Query Store for secondary replicas. The same channel is used by secondary replicas to send query information back to the primary replica and to keep secondary replicas updated. This can result in the Query Store size growing and potential slowdowns during heavy system loads.

Despite these considerations, the Query Store for secondary replicas in SQL Server 2022 paves the way for more efficient data sharing between primary and secondary replicas. While this feature is not yet ready for production deployments, understanding its workings and performance implications is invaluable for database administrators and developers preparing for future advancements in SQL Server technology.

Before you test this feature on your development server, I recommend reading the official documentation. Any updates or changes will be documented there first.

You can always reach out to me on Twitter.

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on SQL SERVER – Query Store Feature for Secondary Replicas