AlwaysOn

How to move AlwaysON AG Databases ?

Back in 2011, we have seen how to move a database which is participating in DB Mirroring here. In this blog post, let’s see how to move a database which is participating in a AG to a new drive(location). In my AG setup,I’ve three replicas(2 near Replicas-Sync mode and 1 far replica sitting in a different data center-Async mode). The database which I will be moving to a new location is “sales”. See below for current paths.

1

Now we shall move these files to below mentioned new location (In this post, let’s see method two mentioned below):

E:\Devices\MSSQL13.MSSQLSERVER\MSSQL\DATA ( MDF File)
F:\Devices\MSSQL13.MSSQLSERVER\MSSQL\Data ( LDF File)

Method one:

Remove the database from AG.
Detach the database.
Move the files physically to new location(s).
Attach the database.
Rejoin the database in your AG.

Method Two:
In this method we shall see how to move files without removing the database from AG.

Steps to perform in sequence:

Suspend data movement for the database which you are working on to all replicas.
Logically move the database files(On all the Replicas).
Stop the SQL Server services. – This step will create an outage for all other databases residing on this instance.
Now move the physical MDF and LDF files to your new location.
Start the SQL service from config manager.
Resume data movement.

Before proceeding any further, I made sure the new path exists on of my  replicas.

1.

2

2. Run this on all the replicas.

3

Now…I stopped SQL Services and moved physical files to new locations and started SQL Server.

3. Now resume data movement.

4

Voila…Now it’s all set as per my requirement.

5

That is it folks for today! Have fun…

SQL Server AlwaysOn Availability Groups Terminology….!

In SQL Server 2012, with AlwaysOn being introduced there are lot of new terms/words which we need to get used to as we support SQL Sever 2012. Well, Just getting used to those terms is not enough…we’ve to understand the terminology. In this short Post let me define what I’ve understood so far with these new fancy terms.

Availability Groups(AG) : – Group of Databases which move together from one Instance to other. Each Instance can have multiple AGs, where each AG contains multiple Databases.

Listener :- It’s a virtual entity which moves around to the current Primary Server for a given AG.

Replicas :- All the SQL Servers involved in your AG are considered as Replicas. Even current Primary Server is treated as a Replica, not just the secondaries…! So, replicas are not Just secondary SQL Instances. They are differentiated by using Primary Replica and Secondary Replica.

Note: AGs run on top of Windows Clustering. So is it a new clustering?? Nope! Same old Windows Clustering, but with a flavor of no Shared Storage. FYI, SQL Instances in my lab are 3 Standalones which are built on top of a 3 Node Windows Cluster with no shared Storage!

Note: your SQL Server Instances can be clustered as well, which adds more complexity, but is needed for some customers based on their own business needs. Typically, MSFT calls this scenario as AlwaysOn Failover Clustered Instance.

AlwaysOn Failover Cluster is not same as AlwaysOn Availability Groups!

How to add a new Database to an existing AlwaysOn Availability Group?

In this post, let us see how to add a new database to an existing AlwaysOn Availability Group. Let’s assume we’ve a sales AG already in place and application team requested us(DBA) team to add one more Database to this Group as they need them to be available all together. For this Example let’s assume the new Database Name is “Sales_Q1” – Of Course this would be more realistic Name in your Real world deployments!

Please see my current Availability Grp Status Below:

At a glance, you can see 3 Databases currently Sales_1, Sales_2 and Sales_3 participating in my AG. Also you can see only 2 nodes out of 3 are Powered Up(See SreeSQLDR status  as Down) and the Primary Replica is SreeSQLA.

Now, let me create a new Database named “Sales_Q1”. See below

As you can see I’ve just created a new Database(Simple Recovery Model) which is not yet added to my AG. Now, let’s try to add this Database and see how SQL behaves by default.

Step1: Right Click on Availability Databases and select Add Database.

Step2:

As you can see Wizard is smart enough to recognize your Database needs Full Recovery Model to participate in your AG.

Step3: I changed the Recovery Model to Full and refreshed the Wizard, now….See below for what it says

Cool…now it says you need a Full backup to be taken.

Step4: Now I tool full backup and placed on a share where all the nodes have access to. Now it says you are good to go as you can see below 🙂

Step 5:  Now it’s time to choose how do you want to start synch. I’ve selected Full by providing the share(I placed by backup here) where all my nodes participating in my AG have access to.

Step 6:  Time to Join all other Nodes by connecting. Notice I can’t proceed further(Next button is greyed out)

As you can see in the above Screenshot I’m not allowed to proceed any further. (Remember from my first screenshot? I didn’t powered UP my DR Node…) Just wanted to show you how this wizard behaves if any one of the nodes participating in AG is down. Once, I powered up my DR machine, I was able to connect to that Instance and was able to proceed Next.

Step7: It validated all my configurations and did it’s magic behind the scenes 🙂

Note: You can script out the entire process while you are at summary Screen.
Finally, see below for how it looks once I added new DB to our AG.

You can see Sales_q1 added to the AG successfully. Perfect! Hope this helps.

Setting up SQL Server 2012 AlwaysOn Availability Groups – Part3

In the previous Post(part-2) we have seen prerequisites for Installing SQL Server Instances participating in an AG. In this post, let’s see how to configure an actual AG…Am alllllllll excited 🙂

Before proceeding any further, Few points to be noted:

1.I’ve created a share on Node “SreeSQLA” which all the 3 Instances need visibility to.(Hence added SQL Service account(s) with Read/Write access).

2.All the Databases participating in AG should be in Full Recovery Model and a Full backup should be taken(Same as DB Mirroring Requirements we had). Well, the whole concept of AG’s was built on top of DB Mirroring. Same EndPoints concept is used here, In fact it uses the same TCP Ports for endpoints which Mirroring uses by default.

3.We have to enable “AlwaysOn Avaiability” option on all the Instances in SQL Server configuration Manager(Service Restart is required).

Here is the Snapshot of my Cluster manager before I enable AlwaysOn on SQL Instances…(Just keep this in mind that there are no Roles for now)

Now, Where can I enable AlwaysOn Availability?

Open your SQL Server Config Manager and go to Services and select SQL Server Properties and you can see a new tab as shown below.

As you can see it automatically detected my Windows Cluster name! All you’ve to do is Enable, Apply, Okay and Restart SQL Services.(Also make sure you enabled TCP/IP  under your network Protocols)

We are all set to begin our Database(s) part now. For my lab am creating 3 User Databases as “Sales1,2 and 3”. (As I mentioned earlier make sure to use Full Recovery Model and Take a Full backup for the first time and I will place it in my share which I created, Note- You can manually sync databases Initially as you did for DB Mirroring)

In my Lab, SreeSQLA is my primary(prod) Instance and SreeSQLB is sitting in the same datacenter(for HA), where I’ll be using Synchronous Mode and assuming SreeSQLB is my DR Site and I’ll be using Asynchronous Mode. (So, I have 3 Replicas in total…Primary replica at my Production Site and 2 Secondary Replicas at SreeSQLB and SreeSQLDR).

Step1: I created 3 Databases on my Production Server(SreeSQLA) and placed full backups on my share.

Step2: Navigate to AlwaysOn High Availability Node in your Object Explorer and select “New Availability Group Wizard” as shown below.

Step3: Name your AG.

Step4: Select your Databases you want in your AG. (You can see below where it says all the Prerequisites are met 🙂 )

Step5:  This is Interesting, where you’ve to select all your replicas, Backup preferences, Create End Points and Create/Assign an IP for your Listener.

Adding Replicas – I Clicked on Add Replica Button and connected to SreeSQLB and SreeSQLDR and chosen Primary and Secondary roles as per my requirement as shown below.

EndPoints: I left it to defaults. ( Make sure your Firewall is not blocking this port)

Backup Preferences: I selected to allow Backups only on My Secondary replicas and I avoided SreeSQLB as shown below. ( You can select as you wish depending on your requirement)

Listener: This is the one which clients connect to and which floats across machines. As you can see I specified a Name, Port and IP for this Listener. Note – Each AG can have only one Listener. Recommended not to use DHCP for IP in your Prod Environments. We’ll be using different subnet for our DR site in real world, for that all you have to do is, add another Static IP from your DR Server Subnet. – Starting SQL Server 2012 we’ve OR Dependency for your IP’s! ( Well, you may need to work with your Network Team for this for all your Static IPs mumbo jumbo)

Now..It’s time to select how you want to initiate Data Synchronization. I’ll provide my Share and let wizard to take care of it as needed, since my database are tiny!

Click Next and it validates our configuration and I got all Green Check Marks as you can see below..Hurray 🙂

All you are left with now is clicking Next and Finish and keep your fingers crossed as I did for this setup(This is my very First AG I ever setup…Very exciting stuff! )

After few seconds I got success message and now Object Explorer on my Production Instance Looks like this.

Huhuuuuuuuuuu….I Did it! See, it’s not that difficult. Now it’s time to understand all the nuts and bolts of this awesome technology.

Before concluding, let me tell you this…From now on, your clients/Applications should connect to Listener Name(not the SQL Instance Name). See below for what it looked like when I connected using Listener Name.

Also, take a look now how my Failover Cluster manager looks like.

It created a Role for the Listener which we created via SSMS and NodeA is the current owner(Principal) of it. Perfect…Everything looks as expected 🙂

Have fun exploring AG guys..Make your self very familiar with this technology, you never know when your boss might say “Okay, Now it’s time to move on to SQL Server 2012”

Setting up SQL Server 2012 AlwaysOn Availability Groups – Part2

In the Previous Post, I explained how I created my 3 node Windows Cluster. Now, In this post let me show you Installing SQL Server 2012 on Windows Server 2012 for our AlwaysOn Setup.

As I already mentioned in previous post, we will be Installing 3 individual standalone SQL Instances(I’ll go with Just Default Instances to keep it simple) on three nodes participating in our Windows Cluster. FYI, I’ll be using the same Service account for all the three Instances.

Note: For Availability Groups, you should use the same service account on all the Instances participating, if you are using Kerberos Authentication. Use Separate Service accounts on your Production deployment only if you are 100% sure that your applications are not using Kerberos. 

I’ve already setup my service account in my AD and added as a user on all the 3 nodes locally and granted “Lock pages in memory” and granted “Perform Volume Maintenance Tasks” in local security policy.

Okay, now let’s begin the actual Installation.

Step1: I inserted my Media in my DVD drive and started setup.exe as you would do normally. Now I selected “New SQL Server Standalone Installation or add features to an existing Installation”. Got No Validation warnings as you can see below…

Step2: I proceeded further and Unchecked “Include SQL Server product Updates” – My Server is not connected to Internet/It can’t search Updates through WSUS in my case. Well, that’s fine! Once I clicked Okay, It started Installing base/Setup files as you can see below.

Everything worked fine as expected and got the below screen in few seconds…

Step3: Select your required features. I selected below shown features and Services.

Note: As you can see BIDS is gone. It has been replaced by SQL Server  Data Tools!

Step4: I selected Default Instance and my Root Installation is on E$ as you can see below(Screenshot Error, my bad).

Step5: Time to provide Service accounts. See below for my selection…

Step6: Time to choose Administrators. I’ll always add myself and the DBA group as Admins.

Very Important: Now, don’t just proceed with Next, go to Data Directories Tab and select your data and Log Drive paths. In my lab I’m having the same Drive letters and folder structure across all the 3 nodes and I recommend you to have a similar strategy for your real world deployments(Don’t leave it defaults…especially when dealing with named Instances, because SQL Server will create Folder specific to Instance name). This is required for successful Automatic Failover of your AG’s. If not you’ll end up with Database(s) not coming Online as expected and manual intervention is required(Similar behavior as DB Mirroring), which is not something we want in our real world deployments.

As you can see, I just created Folders named “Data” and “log” under my Data and Log Drives and will be doing the same on all other SQL Server Instances participating in this AG.

TempDB location is up to you and System Databases are also up to you. ( System Databases can’t participate in AG, same as Mirroring)

Everything is pretty simple/straightforward and went smooth right…..! Wait…..at this point my Installation had some issue and I got this annoying error Message.Erkkkkkkkkkkkkk…!@#$#

“Error While enabling Windows Feature : NteFx3, Error Code : -2146498298” while Enabling OS Feature ‘NetFx3’

Hmm this is something which we never expected at this stage, especially after we passed all the validations and checks at the final stage…! I Thought we will get this interruption only on Windows Server Core. Okay, Now we know we can expect this on Full Blown Windows as well(If we don’t take care of this prior to our SQL Server Installation)

Anyways, what is this all about? What is it talking about…What feature it is referring to? The Answer is “.NET 3.51 Payload“. Yes, we must manually enable .NET 3.51 Payload in Windows Server 2012. (Scroll a little but up and see the screenshot for Step3. you can see under the Prerequisites for selected features, it is saying that “Microsoft .NET framework 4.0 is already Installed, but it’s asking us to manually enable .NET framework 3.5 from GUI) For this you need to have Windows media handy or should be connected to Internet, OR you can enable this automatically by enabling Remote Management which you might not do on your Production Boxes.

So, How to Fix this Annoying thing? Yes, you are correct if you said PowerShell (Few of you might thought about DISM or Just GUI for adding this feature as you used to do in Win Server 2008R2….YMMV!)

Note: Even the Error Message says, go and enable this feature using Server Manager GUI, it might fail!!!….Avoid GUI for fixing this.  Instead use awesome PowerShell guys. I’ll show you powershell way of doing this…

1. Insert your Windows Media in your DVD Drive(in My case it’s D:)

2. Open Powershell as Admin and type  “Install-WindowsFeature Net-Framework-Core -Source D:\Sources\sxs” without double Quotes and hit enter.

After a minute or two, I got success message as shown below 😀

Before fixing this, my Installation was only able to Install few components and my Core DB Engine failed Installing as you can see below.

Once I enabled .NET 3.5 via Powershell,  I was able to re-Install the required components which we had issues earlier without any further Issues. Btw, I enabled this on rest of my nodes at this point to avoid this issue… 🙂

(May be I’ll come up with a short Blog post later just on this Error message)

Strange things right?? Anyways besides this error,  understanding Service Accounts Requirements and Data,Log Files placements for your SQL Instances is very crucial.

I’ll proceed further and Install standalone Instances on the remaining 2 nodes as well for now….Let’s see enabling AlwaysOn and setting up in upcoming post.

Hope this helps if you get into same situation as me while Installing SQL server 2012 on top of Windows Sever 2012.

Cheers!

Setting up SQL Server 2012 AlwaysOn Availability Groups – Part1

I am in the process of setting up my lab for SQL Server AlwaysOn Availability Groups on top of Windows Server 2012 DataCenter Edition and would like to share my experiences . In this post, let me show you setting up your Windows Cluster which is the back bone for SQL Server AlwaysOn….

My Basic Lab setup:

4 VM’s (1 for DC/DNS and 3 other machines for SQL Server Instances). Before proceeding any further please make sure you understand the difference between AlwaysOn Failover Cluster and AlwaysOn Availability Groups(AG). They are not the same! Am talking about AG’s where I’ll be installing three individual Standalone SQL Instances on three different Windows Servers(These 3 windows servers will be acting as Nodes in a windows Failover Cluster, but with no shared Storage-No SAN required, can go with DASD’s or SSD’s or JBODS etc). In other words your Windows Servers participating in AG should be members of the same Cluster, but your SQL Server Instances can be Standalones which are completely isolated from each other! Hope am not confusing you…(Will explore more on SQL Server AG terminology in upcoming posts).

Note: All the Nodes participating in your Cluster should belong to same domain. Cluster validation may result in storage warnings as we are not using Shared Storage.

Step1: Build VM’s as needed.(For building VM’s and setting up networking Please see my previous posts on SQL Server 2008 Failover Clustering)

Step2: Build Windows Cluster

Am on Server Manager of NodeA as Domain Admin-Add Features/Roles and select Failover clustering Feature.

After few seconds I got success msg as shown below.

Perform the same on all the nodes you plan for creating an AG.(In my case I’ll install FC Feature on remaining 2 nodes as well).

Once done Installing this feature on all the nodes, I started Failover Cluster Manager on my machine SreeSQLA and started to create Failover Cluster. Added my 3 machines as you can see below.

Now, it’s time to validating my Cluster(You can do this even before starting creating your cluster). See below warnings I got on my cluster.

Network Warnings I got:

Basically complaining about single point of failures, I am ignoring as this is my lab.(In our Prod environments, we should take care of these warnings before building cluster).

Storage Warnings I got:

Ignore them as we are intentionally doing this…
Now I assigned a name and IP for my windows Cluster as you can see below.

You can see “Add all eligible Storage to the cluster” button which is new to Windows Server 2012 – I unchecked it and clicked Next. After few seconds…I got the below screen 🙂

Now, for verification, see SREEWINCLUST being added in my AD.

Perfect!! Now Let’s open Failover Cluster Manager from Administrative tools and see how it looks with this strange configuration we did without storage.

As you can see it selected Node Majority(Remember, we’ve No Quorum Disk – FYI, we can change as needed)

It’s listing 3 Nodes and Networks as expected, Interestingly you can see “Disks” and “Pools” under storage(This is new with Windows Server 2012). If you select Disks or Pools you should see nothing in the right side pane as seen below.

You will get 0 pools as well under storage Node. Interesting Huh???

You can double check your cluster ip by just pinging your Cluster Name as shown below and double check everything looks as expected.

I’ll stop right here for setting up the foundation(Windows Server Failover Cluster) for SQL Server AlwaysOn AG!- Let’s see some actual SQL DBA stuff in upcoming posts…Stay Tuned!

Hope you learned something new and also hoping this helps in setting up your own lab. Cheers!