Understanding AlwaysOn Architecture is extremely important when building a solution with failover clusters and availability groups. Microsoft has just released two very important white papers related to this subject. Both the white papers are written by top experts in industry and have been reviewed by excellent panel of experts. Every time I talk with various organizations who are adopting the SQL Server 2012 they are always excited with the concept of the new feature AlwaysOn. One of the requests I often here is the related to detailed documentations which can help enterprises to build a robust high availability and disaster recovery solution. I believe following two white paper now satisfies the request.

AlwaysOn Architecture Guide: Building a High Availability and Disaster Recovery Solution by Using AlwaysOn Availability Groups

SQL Server 2012 AlwaysOn Availability Groups provides a unified high availability and disaster recovery (HADR) solution. This paper details the key topology requirements of this specific design pattern on important concepts like quorum configuration considerations, steps required to build the environment, and a workflow that shows how to handle a disaster recovery.

AlwaysOn Architecture Guide: Building a High Availability and Disaster Recovery Solution by Using Failover Cluster Instances and Availability Groups

SQL Server 2012 AlwaysOn Failover Cluster Instances (FCI) and AlwaysOn Availability Groups provide a comprehensive high availability and disaster recovery solution. This paper details the key topology requirements of this specific design pattern on important concepts like asymmetric storage considerations, quorum model selection, quorum votes, steps required to build the environment, and a workflow.

If you are not going to implement AlwaysOn feature, this two Whitepapers are still a great reference material to review as it will give you complete idea regarding what it takes to implement AlwaysOn architecture and what kind of efforts needed. One should at least bookmark above two white papers for future reference.

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

SQL Server 2012 has many interesting features but the most talked feature is AlwaysOn. Performance tuning is always a hot topic. I see lots of need of the same and lots of business around it. However, many times when people talk about performance tuning they think of it as a either query tuning, performance tuning, or server tuning. All are valid points, but performance tuning expert usually understands the business workload and business logic before making suggestions. For example, if performance tuning expert analysis workload and realize that there are plenty of reports as well read only queries on the server they can for sure consider alternate options for the same. If read only data is not required real time or it can accept the data which is delayed a bit it makes sense to divide the workload.

A secondary replica of the original data which can serve all the read only queries and report is a good idea in most of the cases where there is plenty of workload which is not dependent on the real time data. SQL Server 2012 has introduced the feature of AlwaysOn which can very well fit in this scenario and provide a solution in Read-Only Workloads. Microsoft has recently announced a white paper which is based on absolutely the same subject. I recommend it to read for every SQL Enthusiast who is are going to implement a solution to offload read-only workloads to secondary replicas.

Download white paper AlwaysOn Solution Guide: Offloading Read-Only Workloads to Secondary Replicas

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

I have received a lot of inquiries about how to learn High Availability. Please reach out to my friends at Koenig Solutions.

The SQL Server 2012 offers a plethora of solutions for high-availability that assures 99.999% server and database Availability. These solutions enhance database and server availability, hide the failures of software or hardware and maintain application availability to curtail user downtime. It simplifies management and deployment of high availability systems with incorporated monitoring and configuration tools.  It also enhances performance and cost efficiency of IT utilizing up to four Active Secondary. An SQL Server 2012 High Availability course helps you develop capabilities that contribute in taking your career to new horizons. Some of the key capabilities are utilizing standby hardware to the fullest, implementing disaster recovery and high availability and raising the total application uptime significantly.

UPDATE: Since the blog post I have received a lots of inquiries about how to learn High Availability. Please reach out to my friends at Koenig Solutions.

SQL Server 2012 High Availability Features

• AlwaysOn Availability Groups- This is a feature of enterprise level that helps in maximizing user database availability. It entails the Server instances of SQL to exist in WSFC (Windows Server Failover Cluster) nodes.
• AlwaysOn Failover Cluster Instances – This feature influences work of WSFC (Windows Server Failover Cluster). It offers high availability locally using the redundancy feature at the level of the server-instance.
• Database Mirroring- It enhances DB availability by providing support to instantaneous failover. DB mirroring can easily be employed for maintenance of a single standby DB or mirror DB, for an equivalent production DB which is called a principal DB.
• Log Shipping-It executes at the DB level. Users can maintain warm standby DBs (or secondary DB) for just one production DB, called the primary DB.
• Multi-site Clustering – Various enterprises have their data centers located in multiple locations. The main reason for such a step is to maintain redundancy and use a secondary data center for disaster recovery. In this way, organizations can protect their site from failure; whether it is infrastructure, power, network or any other on-site disaster.

Several solutions are there that have executed failover clustering of SQL Server and Windows Server with the multi-site model.  Multiple nodes are included in a multi-site failover cluster. These nodes are scattered across data centers or various physical sites, aiming to offer availability through data centers if a disaster occurs at any site. At times, multi-site failover clusters are considered as multi-subnet clusters, stretch clusters or failover clusters that are dispersed geographically.

High Availability and Disaster Recovery Methodologies

Mastering the Disaster Recovery and High Availability capabilities in SQL Server 2012 environment helps add on to an IT professional’s existing skill-set and allows them to enjoy a promising career ahead. You can build the competencies necessary for a database administrator, developer or architect to understand and manage SQL Server 2012 internal infrastructure. Here are a few methodologies for high availability and disaster recovery-

• Easy monitoring of the high availability configuration with AlwaysOn dashboard. It is an illustrative configuration to keep your DB up to the mark.
• In case a failover happens, it helps in controlling the same. Also, it helps to remove false instances and DB failover.
• Setting up Availability Group will ensure multiple database failover as a single unit. This ascertains that the application has all databases available, up and running.
• With Availability Group Listener, you get a comprehensive set of alternative choices and a faultless application failover.

SQL Server 2012 High Availability Benefits

SQL Server 2012 has developed a platform which brings you a good amount of benefits that can add to your SQL server set up. These benefits include-

• Diminished cost of Hardware without shared storage using AlwaysOn.
• For performance improvement, secondary replica can take the load of performing backups rather than unnecessarily burdening the primary server.
• With the AlwaysOn High Availability feature, availability of your applications is enhanced.
• Automated page repair and high latency system support.
• Provides confidence to deliver in mission critical situations.

SQL Server 2012 High Availability is a new course which can prove to be a feather in the cap of IT professionals. They can further their skills in High Availability and Disaster Recovery in SQL Server 2012 set up. SQL Server 2012 offers you everything required for addressing data dependability and availability at correct time and correct price at every level of the enterprise. With this, you will learn various techniques for leveraging SQL Server technologies for acquiring high-availability of database solutions.

I have received a lot of inquiries about how to learn High Availability. Please reach out to my friends at Koenig Solutions.

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

While preparing for a demo about SQL migration, one of the demo was to show the steps needed to upgrade Evaluation edition to full version of SQL Server. The steps are pretty simple and already blogged at many place on the internet. One of my own blog also shows that:

SQL SERVER – Evaluation Period Has Expired – How to Activate SQL Server?

While doing that, I saw a strange warning message during upgrade:

The AlwaysOn Availability Groups feature is enabled on this instance of SQL Server and it is not supported in the edition being changed to. Before proceeding, disable AlwaysOn Availability Groups on the server instance. For more information, see SQL Server Books Online.

Here is what I saw in SystemConfigurationCheck_Report.htm saved in the same folder where setup logs are stored. I have been fortunate to get into such warnings that help me go over the internet and do my own research. But the best way is to learn to get into such pitfalls and get help from experts online and from friends circle. Fortunate to get help from a number of them lately ESP when working with AlwaysOn environments.

Then I searched on the internet and checked Detail.txt to see if there is anything interesting.

(10) 2013-08-21 05:31:39 Slp: Sco: Attempting to connect script
(10) 2013-08-21 05:31:39 Slp: Connection string: Data Source=.;Initial Catalog=master;Integrated Security=True;Pooling=False;Connect Timeout=300;Application Name=SqlSetup
(10) 2013-08-21 05:31:39 Slp: Connected successfully…
(10) 2013-08-21 05:31:39 SQLEngine: –IsAlwaysOnFeatureEnabled: Engine_IsAlwaysOnFeatureEnabled: IsHADREnabled: = 1
(10) 2013-08-21 05:31:39 Slp: Sco: Attempting to dispose script
(10) 2013-08-21 05:31:39 Slp: Sco: Attempting to disconnect script
(10) 2013-08-21 05:31:39 Slp: Sco:SqlScriptStatementCompleted: Rows affected 1
(10) 2013-08-21 05:31:39 Slp: Current SqlServer Connection closed…
(10) 2013-08-21 05:31:39 Slp: Evaluating rule        : Engine_IsAlwaysOnFeatureEnabled
(10) 2013-08-21 05:31:39 Slp: Rule evaluation done   : Warning
(10) 2013-08-21 05:31:39 Slp: Rule evaluation message: The AlwaysOn Availability Groups feature is enabled on this instance of SQL Server and it is not supported in the edition being changed to. Before proceeding, disable AlwaysOn Availability Groups on the server instance. For more information, see SQL Server Books Online.

Above script confirmed that SQL Server was connected to get the feature. I checked my setup media by installing one of the instance on test server. To double check, on the page where I need to accept the license terms I can see it’s the Enterprise Core edition. Now, I was wondering why I receive this warning. I also checked the Summary.txt file and saw below

Package properties:
Description:                   Microsoft SQL Server 2012
ProductName:                   SQL Server 2012
Type:                          RTM
Version:                       11
SPLevel:                       0
Installation location:         E:\x64\setup\
Installation edition:          Enterprise Edition: Core-based Licensing

I checked with my few expert friends and they told me that if the destination is enterprise, then I can ignore the warning and proceed with the upgrade. I would guess it is an issue with the setup. In my case, the edition upgrade just completed successfully and I was able to continue using AlwaysOn Availability Group.

If you ever receive this warning, you should be able to move forward and trust me, nothing would happen to the availability group. Have you ever received this warning earlier and what did you do?

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

[Notes from Pinal]: The basic nature of human is greedy. When we get one thing which we desire the next thing. In the early world of SQL Server we got a secondary server as a backup or high availability. In earlier times the secondary server was not readable, it just served as a backup. At this point of time our human nature kicked in and we want to get more from the server, which was just sitting there most of the time. We wanted to make our secondary server readable. This is when I reached out to Kenneth and asked him what can we do to make our secondary server as a readable.

Linchpin People are database coaches and wellness experts for a data driven world. In this 107th episode of the Notes from the Fields series database expert Kenneth Urena (partner at Linchpin People) shares very interesting conversation related to how to create readable secondary server in SQL Server standard edition.

AlwaysOn Availability groups are a great technology to create up-to-date, readable secondary’s and distribute read-only load to servers that are not involved in read/write operations. There is one main license requirement, though: your servers need to be running SQL Server Enterprise edition.

So, what happens if you need this functionality, but you are running SQL Server Standard Edition? Transactional Replication is a tool you might want to look to for answers.

This post will demystify some of the misconceptions about transactional replication, and review the considerations and tips you need to successfully configure this technology:

Understanding Transactional Replication

Transactional replication is composed of 3 main roles: The Publisher, The Distributor and The Subscriber.

This is how it works – The Publisher tracks what Objects of the database (Articles) are going to be published, then the Distributor get the changes from the Publisher and makes it available for the Subscriber to consume.

Transactional Replication Requirements

The physical implementation of this technology requires at least 3 databases:

• The Source Database: This database is your actual production database, and it is going to hold the publication on the Publisher.
• The Distribution Database: This database will host all the articles modifications per subscriber per database. It also has a timeframe to keep this information available.
• The Destination database: This database is where all the data will get replicated, and potentially you can redirect the read only queries to take place. This database is hosted on the subscriber host.

Configuring Transactional Replication Properly

In replication the roles can be hosted by the same server. But this choice may actually cause a worse problem than the one we are trying to solve (load balancing). It is because of this that you should keep the following tips in mind before configuring transactional replication:

1. Make sure all of the tables on the source database have primary keys, otherwise that article can’t be include in the publication.
2. Since the goal is take load out of the primary server, make sure to configure the distribution role on a different server than the primary. If you don’t have the budget to configure a distribution server, you can use the subscriber as distributor. Otherwise you will be overloading the server during high traffic.
3. The configuration can be done as follows:
   

4. If the subscriber is going to host the distributor database, make sure the secondary server has the same version (or greater) of SQL server than the publisher.
5. If you are planning to host publications from different servers, with multiple databases on each server, on the same distributor server, it is possible to configure one distribution database per publisher server as follows:

USE MASTER
EXEC sp_adddistributor @distributor = N'DESKTOP-QVDC9JE\SQL2016', @password = N'secret'
GO
EXEC sp_adddistributiondb @database = N'distribution', @data_folder = N'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\Data', @log_folder = N'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\Data', @log_file_size = 2, @min_distretention = 0, @max_distretention = 72, @history_retention = 48, @security_mode = 1
GO
USE [distribution]
IF (NOT EXISTS (SELECT * FROM sysobjects WHERE name = 'UIProperties' AND TYPE = 'U '))
CREATE TABLE UIProperties(id INT)
IF (EXISTS (SELECT * FROM:: fn_listextendedproperty('SnapshotFolder', 'user', 'dbo', 'table', 'UIProperties', NULL, NULL)))
EXEC sp_updateextendedproperty N'SnapshotFolder', N'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\ReplData', 'user', dbo, 'table', 'UIProperties'
ELSE
EXEC sp_addextendedproperty N'SnapshotFolder', N'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\ReplData', 'user', dbo, 'table', 'UIProperties'
GO
EXEC sp_adddistpublisher @publisher = N'DESKTOP-QVDC9JE\SQL2016', @distribution_db = N'distribution', @security_mode = 1, @working_directory = N'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\ReplData', @trusted = N'false', @thirdparty_flag = 0, @publisher_type = N'MSSQLSERVER'
GO

6. If you plan to have multiple subscribers on different servers to the same publication, make sure to configure that publication as pull, so the distribution database doesn’t get overloaded.

7. If your publication contains most of the tables of the source database, it will be quicker to initialize the subscriber from backups. Just make sure the publication is configured to allow initialization from backups as follows:

• Expand the Replication folder
• Expand the Local Publication folder
• Right click over the Publication
• Click on Properties
• Select Subscription Options
• Make sure Allow Initialization from Backup Files is on true

Readable Secondary’s and More Balanced Loads – voila!

Although it may require a bit more setup, transactional replication provides a satisfactory replacement for Enterprise level AlwaysOn Availability Groups in the Standard Edition of SQL Server. So long as you take care to configure and maintain the tool properly, this technology should go a long way towards helping you create up-to-date, readable secondary’s and distribute load balancing in a workable manner.

If you want me to take a look at your server and its settings, or if your server is facing any issue we can Fix Your SQL Server.

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

[Notes from Pinal]: If we get one server, we want two servers, and if we get two servers, we want four servers. If we know we are going to get only two servers, we try our best to get maximum out of our available server. Maximum utilization of resources is always our primary goal. In this blog post we are going to talk about almost the same story where we try to get maximum out of our servers. Let us assume that we have two servers, how do we get maximum performance from them. Well, our generic answer would be that we will keep the most important task on our primary server and move all the not so important task on secondary server. This is common sense and essential too. This is when I reached out to Eduardo and asked him what can we do to make our primary server faster by offloading backups to secondary replica.

Linchpin People are database coaches and wellness experts for a data driven world. In this 108th episode of the Notes from the Fields series database expert Eduardo Castro (partner at Linchpin People) shares very interesting conversation related to how to improve performance of SQL Server by offloading backups to a secondary replica in SQL Server standard edition.

Microsoft introduced AlwaysOn in SQL Server 2012 as a way to bring a high availability option to scenarios where the database administrator doesn’t have a SAN.

AlwaysOn is based on the concept of availability groups that support the grouping of several user databases that can fail over together to other server in case of an interruption of the main server. Each availability group defines partners known as availability replicas. Each replica is part of the availability group and is hosted in a separate instance of SQL Server.

The following picture shows a basic configuration with one primary and two replicas:

One of the main features of AlwaysOn, besides the high availability scenarios, is the option to have active secondary replicas.

Two common questions I get after my sessions on this topic are:

1. How to improve OLTP performance in scenarios where there is a lot of reporting being done during peak hours?
2. How to improve the speed of backups without affecting our main server throughput?

This is where AlwaysOn Active Secondary Replicas come to work. Basically in AlwaysOn, you have the option to use your replicas to distribute the load from the primary server and send the backups and read-only operations to one of the replicas.

If you are creating the AlwaysOn for the first time, you need to configure the backup priority during the Availability Group Wizard. The following picture shows how you can set it up so the backups are run in the secondary replicas. In this way, you can specify that the backups are run in the replica.

If you have already created your AlwaysOn Availability Group, and you haven’t configured where the backups are run, you must alter you group using T-SQL as shown below.

ALTER AVAILABILITY GROUP [@MyOLTPAvailablityGroup] MODIFY REPLICA ON <@MyOLTPInstanceA> WITH (BACKUP PRIORITY = 80)


If you need to automate this task you can create a PowerShell script as shown:

Set-SqlAvailabilityReplica -BackupPriority 80 -Path SQLSERVER: \Data\AvailabiltiyGroups\AvailabiltiyReplicas\<@ MyOLTPAvailablityGroup >

In case you want to configure a Read-only secondary after you have created the Availability Group, then you must alter the current configuration to include the read only routing, as show below:
ALTER AVAILABILITY GROUP MyOLTPAvailablityGroup
MODIFY REPLICA ON 'MySQLServerName'
WITH (
SECONDARY_ROLE (
READ_ONLY_ROUTING_URL = 'TCP://address:port' )
)

Once you have run the scripts, you can modify the connection string of the applications that are read-only to include the following parameter ApplicationIntent=Read-only, in this way the Availablity Group will redirect the read-only connections to the proper secondary replica.

Conclusion

If you want to leverage all the potential of AlwaysOn you should consider its high availability features, but the value of spending some time configuring the secondary read-only replicas and backups will also help you balance the request of your systems, optimize the resource usage and speed up your SQL Server.

If you want me to take a look at your server and its settings, or if your server is facing any issue we can Fix Your SQL Server.

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

[Notes from Pinal]: In my career, I have seen many database experts who are great with what they do, but when they have to work with clustering or AlwaysOn solutions, they usually avoid it. The reason is that there are not many experts who know this subject well enough. One thing I always personally felt […]

The post SQL SERVER – Attaching and Restoring Database in a SQL Server Clustering Configuration Generates An Error – Notes from the Field #115 appeared first on Journey to SQL Authority with Pinal Dave.

This is one of the common issues which I heard from my clients using SQL Server and they don’t know why it happens. What is resolving state in SQL Server AlwaysOn? When there is an availability group, the replica would be either in primary state or secondary state – when its online in failover cluster […]

The post SQL SERVER – AlwaysOn Availability Group Stuck in Resolving State For Long time appeared first on Journey to SQL Authority with Pinal Dave.

Writing some typical interview questions have been on my list always. I look for new ways of tricking the person and most importantly, some of the interview questions are designed to make sure the person has strong fundamentals. This blog is one such attempt to understand the basics of the AlwaysOn Availability Group.

The post SQL SERVER – Adding File to Database in AlwaysOn Availability Group appeared first on Journey to SQL Authority with Pinal Dave.

Understanding AlwaysOn Architecture is extremely important when building a solution with failover clusters and availability groups. Microsoft has just released two very important white papers related to this subject. Both the white papers are written by top experts in industry and have been reviewed by excellent panel of experts. Every...

The post SQLAuthority News – 2 Whitepapers Announced – AlwaysOn Architecture Guide: Building a High Availability and Disaster Recovery Solution appeared first on Journey to SQL Authority with Pinal Dave.

SQL Server 2012 has many interesting features but the most talked feature is AlwaysOn. Performance tuning is always a hot topic. I see lots of need of the same and lots of business around it. However, many times when people talk about performance tuning they think of it as a...

The post SQLAuthority News – Microsoft Whitepaper – AlwaysOn Solution Guide: Offloading Read-Only Workloads to Secondary Replicas appeared first on Journey to SQL Authority with Pinal Dave.

Migration of SQL Server 2012 Database Mirroring to AlwaysOn Availability group can get a bit tricky if you’re not quite familiar with the workings of SQL Server 2012. This article gives you a better idea about the migration process of database mirroring to AlwaysON Availability group.

To start with Migration, Basic setup required is as follows:

Install Active Directory on DC machine and name the Domain name as (Contoso.com). Add the other three machines viz. SQLNode1 ,SQLNode2,SQLNode3 to the domain and then switch off the window firewall, open the command prompt and ping to check whether all machines are connected to each other (make sure that you are logged in to the SQLNodes with the domain account not with the local administrator user). When the machines connectivity is ok, start to create the mirroring session between:

• SQLNode1 (PRINCIPAL)
• SQLNode2 (MIRROR)
• SQLNode3 (WITNESS)

We will create 3 mirroring sessions for mirroring and the databases are (AdventureWorks2012, AdventureWorksLT2012, TSQL2012 ) as shown in the figure below :-

As you can see that on SQLNode1, the AdventureWorks2012, AdventureWorksLT2012, TSQL2012 are the Principal and in Synchronized state where as on SQLNode2, AdventureWorks2012, AdventureWorksLT2012, TSQL2012 are in Mirror, Synchronized/ Restoring state.

Now to migrate the database from database mirroring to AlwaysOn, we have to create a WSFC (Windows Server Failover Cluster) by installing Failover Cluster feature from Server Manager (Add features option) as seen in the image below. The Cluster name is SQLCluster.Contoso.com and in the Nodes hierarchy all the three Nodes are visible that we have added to the Cluster.

Now to move the database from database mirroring to AlwaysOn, we have to first remove mirroring from all the three configured databases, that will bring the database on Secondary server i.e., SQLNode2 in Restoring mode.

To remove the mirroring session follow the steps :

• Right click all the three configured database go to its properties.

• In the Database Properties dialog box, select the Mirroring Page option and then click on remove Mirroring button and click on Yes button. This will remove the mirroring between SQLNode1 and SQLNode2 for that particular database.

• Repeat the same step for the other two databases.

Now under the SQLNode1 explore the AlwaysOn High Availability option and then Availability Groups. You will observe that there is no Availability group created yet. So your first step is to create a Availability Group and right click it and select New Availability Group Wizard.

It will open the New Availability Group Wizard, then click Next button and in the next page specify the Availability Group Name as DemoAG, and then click Next. In the select database page, you will find a list of all the databases on SQLNode1 from which you have to choose, which databases you want to move to the Availability group.

In front of each database name, you will find a status column that will show you the status of each database. for example

• Full Recovery Mode is required option is visible when you have not taken a Full backup on the Primary Replica.
• Meet Prerequisites option is visible and it means that you have already taken the full database backup and your database is ready to be added into the AlwaysOn.

On this page we will select all the three database on which we have previously configured the database mirroring (AdventureWorks2012, AdventureWorksLT2012, TSQL2012)and click Next.

Now in the specify Replicas in the Replicas tab, you will find that SQLNode1 node is already added and has the Primary role. On the same page click the Add Replica button and add the other two nodes (SQLNode2 and SQLNode3) that will be treated as Secondary Replica.

Select Automatic failover for SQLNode1 and SQLNode2 and in the Readable Secondary leave the option by default as NO.

Synchronous commit for SQLNode1, SQLNode2, SQLNode3 and in the Readable Secondary select the

Option Read-intent Only.

In the endpoint tab, you will find that the endpoint name has automatically been created and port number has automatically been configured.

In the backup preference tab, you can choose where you want to take the backup. Options are :

• Prefer Secondary
• Secondary Only
• Primary
• Any replica

In our demo we have chosen Secondary Only option. We can also choose the priority for backup storage on nodes and can exclude any node which we don’t want to take backup on.

Then in the Listener tab, choose create an availability group listener option with following configuration:

Listener DNS Name :DemoAGListener

Port : 1433

Network Mode : Static IP

then click Add and add the IPV4 Address in the following range : 192.168.0.7 and click OK.

Then in the select Data Synchronization page, choose from the following option :

Full :Automatically takes a full backup and log backup of each database and then completes data synchronization process.

Join : The full and log backup of the database has already been taken and we just need to join the selected databases to the availability group.

skip initial data synchronization: Manually takes a full backup and log backup of each database.

For our demo, we have chosen the Join option as we already have the databases in restoring mode on secondary replica.

Then On Validation Page, it will validate whether everything you configured is proper or not, click Next and then click Finish.

Finally we can monitor our Availability Group Replicas using Dashboard which will show us the Active replica and the list of databases configured for mirroring.

Now we can see that AlwaysOn High Availability has been configured and when we explore the Availability group hierarchy, we will find an Availability Group named DemoAAG which we have created and it is the Primary Replica.

Under the Availability replica folder, we can see the three Nodes added

• SQLNode1 (Primary)
• SQLNode2 (Secondary)
• SQLNode3 (Secondary)

Under Availability Databases we can see all the three database.

Under Availability Group Listener, we can see a Listener that we have created named DemoAAGListener.

We can also observe that the databases in the secondary replica are in Synchronized Mode.

Now If we want to failover all the databases to the Secondary replica, we have to do it either manually by right clicking the Availability group that we have created and select failover, which will automatically switch the roles from Primary Replica(SQLNode1) to any of the Secondary Replica, if they are not in read-intent only mode.

We can also connect to the SQL Server by using the Listener name (DemoAAGListener) in the server name.

Hope this post was useful for you. Thanks Mukul for help in writing this blog post.

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

The post SQL SERVER – Migration of SQL Server 2012 Database Mirroring to AlwaysOn Availability Group appeared first on Journey to SQL Authority with Pinal Dave.

[Note from Pinal]: In this episode of the Notes from the Field series database expert Mike Lawell talks about his thoughts and observation about SQL Server 2016 and enhancements with AlwaysOn Availability Groups. When AlwaysOn was newly introduced, I was not able to catch up with the feature. I just thought it was just one of the subject which will not be developed by Microsoft, however, as the new versions of the SQL Server are now taking this feature to the next level, I am very delighted that I should have not worried at all. Let us see what Mike says in his own words about Enhancements with AlwaysOn Availability Groups.

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

The post SQL SERVER 2016 – Enhancements with AlwaysOn Availability Groups – Notes from the Field #121 appeared first on Journey to SQL Authority with Pinal Dave.

Recently I was trying to help a customer who was deploying AlwaysOn Availability Group in Microsoft Azure via template deployment.

The template was failing with below error

StatusMessage
{
“status”: “Failed”,
“error”: {
“code”: “ResourceDeploymentFailure”,
“message”: “The resource operation completed with terminal provisioning state ‘Failed’.”,
“details”: [
{
“code”: “DeploymentFailed”,
“message”: “At least one resource deployment operation failed. Please list deployment operations for details. Please see https://azure.microsoft.com/en-us/documentation/articles/resource-manager-common-deployment-errors/ for usage details.”,
“details”: [
{
“code”: “Conflict”,
“message”: “{\r\n \”status\”: \”Failed\”,\r\n \”error\”: {\r\n \”code\”: \”ResourceDeploymentFailure\”,\r\n \”message\”: \”The resource operation completed with terminal provisioning state ‘Failed’.\”,\r\n \”details\”: [\r\n {\r\n \”code\”: \”VMExtensionProvisioningError\”,\r\n \”message\”: \”VM has reported a failure when processing extension ‘configuringAlwaysOn’. Error message: \\\”DSC Configuration ‘CreateFailoverCluster’ completed with error(s). Following are the first few: PowerShell DSC resource MicrosoftAzure_xSqlAvailabilityGroupListener failed to execute Set-TargetResource functionality with error message: The running command stopped because the preference variable \\\”ErrorActionPreference\\\” or common parameter is set to Stop: An error occurred while attempting to bring the resource ‘SQLAUTHORITY-AG’ online.\\n The cluster resource could not be brought online by the resource monitor The SendConfigurationApply function did not succeed.\\\”.\”\r\n }\r\n ]\r\n }\r\n}”
}
] }
] }

The message looks very ugly, but it’s a direct copy paste from Azure. Here is the relevant message:

An error occurred while attempting to bring the resource ‘SQLAUTHORITY-AG’ online. The cluster resource could not be brought online by the resource monitor

I looked further into Event log into the node and found below interesting error.

Log Name: System
Source: Microsoft-Windows-FailoverClustering
Date: 7/26/2016 6:11:45 PM
Event ID: 1193
Task Category: Network Name Resource
Level: Error
Keywords:
User: SYSTEM
Computer: demo.sqlauthority.local
Description:
Cluster network name resource ‘alwayson-ag-sqlauth-listener01’ failed to create its associated computer object in domain ‘sqlauthority.local’ for the following reason: Resource online.
The associated error code is: -1073741790
Please work with your domain administrator to ensure that:
– The cluster identity ‘win-cluster$’ can create computer objects. By default all computer objects are created in the ‘Computers’ container; consult the domain administrator if this location has been changed.
– The quota for computer objects has not been reached.
– If there is an existing computer object, verify the Cluster Identity ‘win-cluster$’ has ‘Full Control’ permission to that computer object using the Active Directory Users and Computers tool.

Interesting thing was that the deployment worked first time but failed second time and all subsequent attempts.

Initially I thought it’s a well-known permission issue of CNO and VCO so I went to pre-stage it.  (Prestage Cluster Computer Objects in Active Directory Domain Services)

Later, we found that listener name was created in AD as “alwayson-ag-sq” due to 15 characters’ limit. When we deployed again, it was still creating same name even though I gave ‘alwayson-ag-sqlauth-listener01’ in template.

Solution: Make sure we are keeping computer names within the limit of 15 characters. (Naming conventions in Active Directory for computers, domains, sites, and OUs)

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

First appeared on SQL SERVER – Unable to Create Listener for AlwaysOn Availability Group in Azure via Template Deployment

Almost all the time, whenever there is a wizard, it’s a human habit to go with the defaults and finally click finish. Once of my client sent below email to me. In this blog post we are going to learn about Added New Node in Windows Cluster and AlwaysOn Availability Databases Stopped Working.

Hi Pinal,
We are trying to add new node to the AlwaysOn Availability Group and for that we must add new node to Windows cluster. Before doing this in production, we are trying to our test environment and we ran into issues. We noticed that as soon as node is added in windows, our databases which were part of an availability group went to not synchronizing state. Later I noticed that local disks were added to the cluster under “available storage”.

Have you seen this issue? What is wrong with our setup?

Thanks!

I asked for any error in event log and they shared below.

Log Name: System
Source: Microsoft-Windows-FailoverClustering
Event ID: 1069
Task Category: Resource Control Manager
Level: Error
Description: Cluster resource ‘Cluster Disk 2’ of type ‘Physical Disk’ in clustered role ‘Available Storage’ failed. The error code was ‘0x1’ (‘Incorrect function.’)

I told them that they must have followed the wizard and must have forgotten to “uncheck” the highlighted checkbox.

This is the default setting and has caused issues for many, including me during the demo. They also confirmed the same. What is the solution now?

SOLUTION/WORKAROUND

To work around this problem, we must remove the disk resource from Failover Cluster Manager. Once done, we need to bring these drives online in Disk Management once they are removed from Failover Cluster Manager.

Have you run into the same issue? Anywhere default setting in the wizard has caused the problem?

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

First appeared on SQL SERVER – Added New Node in Windows Cluster and AlwaysOn Availability Databases Stopped Working

One of my clients reported a usual behavior of the AlwaysOn availability group. He informed me that he is trying to add a login on the secondary replica in the AlwaysOn AG environment but it is failing with below error:

Msg 3906, Level 16, State 1, Line 3
Failed to update database “SCCMDB” because the database is read-only.

As a normal troubleshooting, I asked to do it from SQL Server Management Studio and got below error.

Create failed for Login ‘TestLogin’. (Microsoft.SqlServer.Smo)
Failed to update database “SCCMDB” because the database is read-only. (Microsoft SQL Server, Error: 3906)

One strange this which he informed me that it works well on primary replica.

I was curious to know why would creating a login would try to write information into a user database? As a part of troubleshooting, I asked to capture a profile trace while reproducing the error. I was able to see that there is a trigger getting fired while creating a login.

SOLUTION/WORKAROUND

We executed this query

SELECT t.name
,t.object_id
,t.is_disabled
,te.type_desc
FROM master.sys.server_triggers t
INNER JOIN master.sys.server_trigger_events te ON t.object_id = te.object_id

And found that there was a DDL trigger defined for the login creation which was logging an entry in SCCMDB.  Once we disabled the trigger, the issue was resolved.

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

First appeared on SQL SERVER – Unable to create login AlwaysOn availability group secondary replica

Along with performance consulting, sometimes I also get requests from a few clients to look at the AlwaysOn availability group related problems.

ENVIORNMENT:

Three node AlwaysOn availability group with multi-subnet cluster with two nodes (SQL-A and SQL-B) within one subnet and the third node (SQL-C) in second subnet.  All three instances are SQL Server 2014 build 12.0.4100.  There is a single Availability Group (ALWAYSONAG) which contains database TESTAG which is shown as not synchronizing.

ISSUE

I have asked more about database and found that the database was TDE enabled. They already followed the steps explained in books online to do backup and restore. But as soon as the database is added to availability group it fails. We found below error message in ERRORLOG and can see that database goes to not synchronizing.

2016-12-23 17:46:41.60 spid55 Starting up database ‘TESTAG’.
2016-12-23 17:46:41.65 spid55 The database ‘TESTAG’ is marked RESTORING and is in a state that does not allow recovery to be run.
2016-12-23 17:46:42.09 spid55 ALTER DB TESTAG with AGNAME:ALWAYSONAG
2016-12-23 17:46:42.09 spid55 ALTER DB param option: SET
2016-12-23 17:46:42.15 spid24s Starting up database ‘TESTAG’.
2016-12-23 17:46:42.16 spid24s Error: 15581, Severity: 16, State: 7.
2016-12-23 17:46:42.16 spid24s Please create a master key in the database or open the master key in the session before performing this operation.

As we can see in the error log there are messages that imply TDE encrypted databases cannot be decrypted by system SPID.

WORKAROUND / SOLUTION

We needed to add encryption by service master key to the database master key. This would allow SQL Server system SPIDs (like recovery spid) to automatically open it as required.

OPEN MASTER KEY DECRYPTION BY PASSWORD = 'Password goes here'
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY

As soon as we ran the command, the issue was resolved. I think this issue can also happen even with transaction log shipping based log restore also.

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

First appeared on SQL SERVER – AlwaysOn AG (Availability Group) and TDE Error – Please Create a Master Key

While applying patches on SQL server standalone instance, in the cluster, it failed with error as below in Summary.txt file. Let us learn about how to fix Exception data is: System.IO.IOException.

Overall summary:
Final result: The patch installer has failed to update the following instance: RTCLOCAL. To determine the reason for failure, review the log files.
Exit code (Decimal): -2058616824
Start time: 2017-01-02 03:23:07
End time: 2017-01-02 03:39:34
Requested action: Patch

When I looked into Detail.txt and searched for error, here was the place of failure.

‘C:\Windows\system32\hadrres.dll’. Exception data is: System.IO.IOException: The process cannot access the file ‘C:\Windows\system32\hadrres.dll’ because it is being used by another process.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite)
at Microsoft.SqlServer.Configuration.Cluster.UpdateClusterResourceAction.VersionCopy(String source, String target).

Final Parameter Values

(01) 2017-01-02 03:35:41 Slp: Parameter 0 : SQL Server 2012@RTM@KB3072779
(01) 2017-01-02 03:35:41 Slp: Parameter 1 : 0xE349FEF6
(01) 2017-01-02 03:35:41 Slp: Parameter 2 : 0x60797DC7
(01) 2017-01-02 03:35:41 Slp: Parameter 3 : 0xE02C15DF@1356@8
(01) 2017-01-02 03:35:41 Slp: Parameter 4 : 0x24C2C4E7
(01) 2017-01-02 03:35:41 Slp: Parameter 5 : HADRResourceDLLConfigpatch_HADRResourceDLLWorkflow
(01) 2017-01-02 03:35:41 Slp: Parameter 6 : 0x871FC66E
(01) 2017-01-02 03:35:41 Slp: Parameter 7 : 0x27FE6E93
(01) 2017-01-02 03:35:41 Slp: Parameter 8 : 0x27FE6E93

If I understand the message correctly, SQL setup is trying to copy file “hadrres.dll” from “c:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Binn\” to “C:\Windows\system32”. Due to some reason, we are getting error “The process cannot access the file ‘C:\Windows\system32\hadrres.dll’ because it is being used by another process”

Since the patch was incompletely installed, I found that SQL was not starting.

WORKAROUND/SOLUTION

I had no idea as to why copy is not working so I asked to rename files in C:\Windows\system32 folder and stop any monitoring software related services. After renaming, we could apply the patch and found new file copied via setup. We verified and found that version of the file was higher after installation was complete.

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

First appeared on SQL SERVER – UpdateHADRResource – Failed to version-copy file – Exception data is: System.IO.IOException

As a part of my independent consulting, I also provide a high level overview of the migration strategy. As a part of this engagement, my client wanted me to provide steps to move AlwaysOn availability group from DomainOld to DomainNew. This was happening because they were acquired by another company and they need to migrate all assets to a new domain.

Topology:

Here are the steps which I told them.

• Remove replica Node-03 from availability group.
• Evict Node-03 from the windows cluster.
• Since Node-03 is completely out of AG, we can rebuild Node-03 in DomainNew
• Create a new windows cluster having just one node Node-03.
• Use scripts to migrate all server level objects – logins, jobs, operators from Node-01 to Node-03.
• Node-02 also needs same steps as Node-03 with one difference that it would be part of the same cluster as Node-03 rather than new cluster.
• Configure database mirroring for user databases from Node-01 to Node-03.
• OUTAGE: failover mirror databases to Node03, break the mirror and point application to Node-03.
• Perform test and test and test.
• Evict Node-01 and decommission the original cluster.
• Rebuild Node-01 in the new domain and add it to the cluster.
• Backup and restore the database from the Node-03 to the two new nodes and implement AG across all three new nodes.

After getting above high level guidance, they executed the project and it went fine.

Hope this step would help others as well about AlwaysOn Availability Group.

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

First appeared on SQL SERVER – Migrating AlwaysOn Availability Group to New AD Domain

This is one of the common question which is asked via emails to me. “How to apply the patch in AlwaysOn Availability Group configuration?” OR “What are the steps we should do and things to take care while patching availability replica?”

There might be many articles which would provide same details, but I want to make it short and crisp.

I am going to pick step by step for an Availability Group with one secondary replica.

1. Make sure that we have taken good recent OS backup with system state (or VMware snapshot with SQL services stopped), a good recent backup of all databases and a successful completion of a checkdb on the primary node. {This is not mandatory, but to avoid “Ouch” moment}
2. From the node acting as the primary replica (SQL1), change the failover mode to manual
3. Refresh the affected databases on the secondary replica (SQL2) and make sure that everything is green on the dashboard.
4. Apply the patch (service pack of CU) on SQL2.
5. Repeat the Windows Update and/or software updates until all available patches are applied. Do not move on with the patching steps until all patches and post patch reboot and configuration tasks are completed.
6. Double check that patches have been applied, the cluster is healthy and AlwaysOn Availability Groups are functional.
7. Make sure that synchronization state is SYNCHRONIZED.
8. Fail over the availability group to the secondary replica (SQL2).
9. Refresh the affected databases on secondary Replica (former primary = SQL1) until the synchronization state is synchronized.
10. Apply the patch (service pack of CU) on SQL1.
11. Repeat the Windows Update and/or software updates until all available patches are applied. Do not move on with the patching steps until all patches and post patch reboot and configuration tasks are completed.
12. Double check that patches have been applied, the cluster is healthy and AlwaysOn Availability Groups are functional.
13. Make sure that synchronization state is SYNCHRONIZED.
14. Fail over the availability group to the primary node (back to SQL1).
15. Change the failover mode to Automatic now (which we changed in Step b)

In case things do not go as planned, you have followed step a) so you know what needs to be done.

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

First appeared on SQL SERVER – How to Apply Patch in AlwaysOn Availability Group Configuration?