Posts Tagged ‘Performance’

SQL Server 2014: New function sys.fn_hadr_is_primary_replica March 25th, 2014

Vinod Kumar

My latest explorations have been to look at what are the fine print details that got added with SQL Server 2014. Especially, I have been exploring what has fundamentally changed when it comes to SQL Server 2014 – AlwaysOn capabilities. Though at the outset this looks simple and basic, some of these enhancements are pretty cool and needs a mention. Hence you are getting these bunch of blogposts inspired by this learning.

In SQL Server 2012, we had this neat little function – sys.fn_hadr_backup_is_preferred_replica which allowed us to be used during the backup operation if the replica we are running backup against is the preferred replica as per the AlwaysOn configuration. Though it was a neat addition there was no way to figure out if the node on which the Maintenance plan was running was ever the Primary replica. To illustrate the enhancement, I am having the following configuration as shown in the figure below.

As you can see I have two servers SQLALWAYSON01 and SQLALWAYSON02 servers and the -01 server is the PRIMARY. With SQL Server 2014, there is a new function that gets introduced – sys.fn_hadr_is_primary_replica. This nifty function when passed with the database name will return 1 if it is run on the PRIMARY. Else it will return you 0, if invoked from the secondary replicas.

In my opinion this is a critical and nifty option because you might want to do certain operations ONLY on the Primary like index rebuilding, full backups or whatever. Apart from these values, if you by any chance pass a non-AG database to the function it will return you NULL as shown in the figure below. Do let me know if you will use this function and what are the scenario’s you will find this useful. It can surely be a great learning for me too to listen from you.

This post is inspired from Book content: SQL Server 2012 AlwaysOn Joes 2 Pros®: A Tutorial for Implementing High Availability and Disaster Recovery using AlwaysOn Availability Groups” (Paperback, Kindle).

Continue reading...


SQL Server AlwaysOn–SQL 2014 Readable Secondary changes March 20th, 2014

Vinod Kumar

This is in continuation to the post around SQL Server AlwaysOn-Readable Secondary Setting which I posted earlier. With every new release there are multiple enhancements and I know by the time we published our book on AlwaysOn many of these features were not quite available and we missed writing about them.

One of the main addition with SQL Server 2014 for AlwaysOn is the capability to have 8 secondary replica. This is has been discussed exclusively in the book and the number of synchronous nodes etc remain as in SQL Server 2012. Nothing much changes. It is important to understand that commits don’t wait for async replica’s hardening, so there will be not much of an impact wrt to deployments are concerned.

Enhanced Readable Secondary with SQL Server 2014

So what are the new scenario’s that we are talking about from a readability point of view? In SQL Server 2012, when the availability on the secondary databases was either NOT SYNCHRONIZED (Data movement SUSPENDED) or in RESOLVING state we were not able to connect to the secondary node for ReadOnly workloads.

Scenario 1: In SQL Server 2012 if we take the Availability group to Offline mode, the secondary databases get into a RESOLVING state and we get the following error:

Unable to access database ‘AdventureWorks2012′ because its replica role is RESOLVING which does not allow connections. Try the operation again later. (Microsoft SQL Server, Error: 983)

From SQL Server 2014, existing connections made to the secondary replica directly can still be served and new connections will also be allowed.

Scenario 2: In SQL Server 2012, if data movement gets suspended, the availability database gets into a NOT SYNCHRONIZED state. In such scenarios the connections are refused and we get the following error:

The target database, ‘AdventureWorks2012′, is participating in an availability group and is currently not accessible for queries. Either data movement is suspended or the availability replica is not enabled for read access. To allow read-only access to this and other databases in the availability group, enable read access to one or more secondary availability replicas in the group.

Or we might get a read access error on the secondary. Either way, with SQL Server 2014, this is no longer a problem as read directly to the secondary is possible even when the synchronization is suspended.

Note: Irrespective of the scenario mentioned above, the read operation cannot be performed using the Listener and routing list. In either of the case of RESOLVING or NOT SYNCHRONIZED state if you use the Availability Group Listener name/IP we will get the below error.

Unable to access the ‘AdventureWorks2012′ database because no online secondary replicas are enabled for read-only access. Check the availability group configuration to verify that at least one secondary replica is configured for read-only access. Wait for an enabled replica to come online, and retry your read-only operation.

Thought this is a critical hidden enhancement with AlwaysOn, it can surely come in handy for Hybrid scenarios, or when quorum is lost scenarios where we still get the ability to read from our secondary directly as a last resort and worst case operation.

This post is inspired from Book content: SQL Server 2012 AlwaysOn Joes 2 Pros®: A Tutorial for Implementing High Availability and Disaster Recovery using AlwaysOn Availability Groups” (Paperback, Kindle).

Continue reading...


SQL Server 2014: SELECT INTO is parallel March 7th, 2014

Vinod Kumar

Recently I was performance tuning and optimization for a customer and working on SELECT INTO statements code blocks. I saw a weird behavior and a self learning hit when I saw something interesting. In SQL Server 2014, this command seems to be running in parallel. Cool and a must from performance point of view. To reproduce this simple learning, I executed the below query on my SQL 2014 CTP2 box:

Looking at the execution plan revealed the following. Look at the Parallelism and Gather Stream to confirm the same.

Sometimes, there are these nifty tiny features that get added to the product that we stumble upon by accident. Since my TempDB is in compatibility of 120 (SQL 2014), I thought of making an interesting test. I changed my compatibility level to 100 for AdventureWorks and did the test again. To my surprise I saw the Parallelism is gone !!! Woot, that was quite a learning.

Do let me know if you get the same behavior on a pre-SQL 2014 box.

Continue reading...


SSMS Tips–Object Explorer Details February 5th, 2014

Vinod Kumar

Today’s blog is inspired from the use of common tools that we use day-in-day-out. For me when playing with SQL Server, it will be SQL Server Management Tool (SSMS.exe). This blog has a number of posts around SSMS Tips like – SSMS: T-SQL Debugger Shortcuts, SQL Server: SSMS Tips II, SQL Server 2012 : SSMS Tips, SQL Server 2012: Snippets and IntelliSense and few more. So do look at them too.

In this blog let me just talk about a simple addendum screen that we hardly use but has tons of valuable information hidden inside SSMS – it is Object Explorer Details. For easier understanding I am just going to use a number of pictures to illustrate what I have actually done :).

Once you are in SSMS, click on F7 shortcut or use the View –> Object Explorer Details keyboard navigation as shown in picture below.

This bring the Object Explorer Details in the usual location where we normally have the Query Window. You can navigate to any node like the Object Explorer or click on a node on Object Explorer and it will populate the related details in the Details pane as shown in the next image. Below we are at the AdventureWorksDW database and have selected the Tables node. This enumerates and lists all the tables in the given database with few interesting properties.

Some additional capability in the Details pane is the ability to search for an object using the Search box on the top and once we are at the object, we can go ahead and click the double arrow (as in figure) to synchronize the Object Explorer View. It is quite an handy feature to use.

The Columns in the Object Explorer Details are customizable and quite interesting. From the header if you right click we will be presented with a list of additional columns that we can include in our view. The list changes based on the node that you are currently on. So “right-click” every header and play to your hearts desire.

In the above options, I selected Data Space Used (KB) and Row Count for my example. We can also remove any unnecessary columns which we don’t want to see too. Now with this data it becomes interesting. In the below figure I have done two things, a) sorted the “Row Count” Column and then b) selected about 10 rows from the OED pane. Now just CTRL+C and take these values to Excel :).

I have pasted the same inside Excel and it looks like below.

Inside Excel we have the freedom to do a number of things. One of the features that I have loved using the suggested charts, formatting of Excel 2013. When the table is selected, a small icon appears on the bottom right side – click on it and I have selected the Formatting –> Data Labels.

Other shortcut to play around is ALT+F1 to get a chart quickly populated. Below is a sample output that I have shown.

I am sure you have played around with Object Explorer Details before. If you haven’t played around till date then I am sure you will do now. Do let me know if you find this interesting and we will followup with many of these tips in the future.

Continue reading...


SQL Server AlwaysOn-Readable Secondary Setting January 3rd, 2014

Vinod Kumar

Recently I was questioned by two different customers on the very topic and I thought it was worth writing a mini-post to start the year :). The question was simple, what is the fundamental difference of values of “Yes” and “Read-Intent only” values when we are configuring our AlwaysOn Availability Groups? Aren’t they the same?

If you check the configuration of AlwaysOn we will be presented with these three options and these can be changed even later. This blog is to simply explain what these three mean.

No: This is the easiest of the lot. It just means we will not allow any connections to this server.

Yes: This is used for legacy purposes where *any TDS client* who wants to connect to a secondary replica explicitly for reporting workload can connect.

Updated as per Robert Comments: You can still connect to a instance marked as Yes via the routing list as it is an readable copy.

Read-intent-only: In this option we explicitly need to give the connection string property of “ApplicationIntent=ReadOnly”. Read more about connection strings in my previous blog – SQL Server AlwaysOn–Connection Strings. The only difference here is that you have explicitly shown the intent that the connection is going to be read only and it removes the caveat of previous point because now the routing-list / listener takes care of routing your request to the first available readable secondary as per the configuration. Hence for all practical purposes, for new applications please use this option.

Irrespective to the option selected, if your application fires a write operation to a ReadOnly server, the application will fail on the first DML or DDL operation performed in that connection.

This post is inspired from Book content: SQL Server 2012 AlwaysOn Joes 2 Pros®: A Tutorial for Implementing High Availability and Disaster Recovery using AlwaysOn Availability Groups” (Paperback, Kindle).

Continue reading...