• Limit of two replicas (primary and secondary)
• No read access on secondary replica
• One database per group

1. Can I create more than 1 availability group?

2. Can I use automatic failover?

3. Can I configure more than 2 replicas?

4. Does a Basic Availability Group support databases with FILESTREAM?

5. Can I have SQL FCI as a replica?

6. Do I need a listener for each group?

7. Can I take a snapshot of the database that is running on the secondary replica?

Prerequisites

The prerequisites are the same as for a traditional Enterprise AlwaysOn Availability Group. You still need to Create a Windows Failover Cluster and Enable AlwaysOn Availability Groups on each instance. More information can be found on Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups

Setup a New Basic Availability Group

You can still use the “New Availability Group Wizard” in the management studio to create your basic Availability Group. Of course, T-SQL and PowerShell can also be used.

Specify the name of the Availability that you want to create.

Please also note the new option “Database level Health Detection”. You can now configure AlwaysOn Availability Groups to failover when a database goes offline. This was not possible in previous editions of SQL Server.

Select the database that you want to add to the Availability Group. One of the limitations of Basic HA is that you’re only allowed to add 1 database per group. The wizard will return an error when you try to add more than 1 database into the group.

When you specify the replicas for your Availability Group, you will notice 2 other limitations:

• Limit of two replicas (primary and secondary). After you’ve added the secondary replica, the “Add Replica” button will automatically be disabled.
• No read access on secondary replica. The wizard only has the “No” option, so you can’t configure a readable secondary.

Please note that you can configure Synchronous or Asynchronous commit mode. This is a difference compared to database mirroring where you could only use synchronous commit mode in SQL Server Standard Edition. With Basic HA, we allow asynchronous commit mode, to be able to create your secondary replica in Azure. This allows you to create even a basic disaster recovery solution with SQL Server Standard Edition!

The endpoint configuration is still needed and there is no difference compared to the traditional Enterprise Availability Groups

Basic HA doesn’t allow you to use a readable secondary, which means that there are no backups possible on the secondary replica. You will notice that the Backup Preferences are completely disabled

Basic HA also supports the usage of an Availability Group Listener. Creating the listener is the same procedure as the traditional Enterprise listener. The Basic HA group is limited to 1 listener.

The next step is setting up the data synchronization between the 2 replicas. Again, there is no difference here between Standard and Enterprise Edition

With SQL Sever 2016, you could also use the new option Direct Seeding. This method will seed the secondary replica over the network. It does not require you to backup and restore a copy of the primary database on the replica. However, this is currently not available in the wizard but only with T-SQL.

After you finish the wizard, you have setup your first Basic HA Availability Group.

1. The login is not a member of sysadmin fixed server role,
2. The server is in running upgrade scripts mode and you’re not connecting over DAC,
3. The ID of the session (SPID) you already used once to connect through this mechanism is different than that of the session ID you’re trying to use right now (i.e. attempting to connect over more than one session)

BACKUP DATABASE AdventureWorks2014  
TO URL = 'https://mystorageaccount.blob.core.windows.net/mycontainer/AdventureWorks2014.bak' 
WITH CREDENTIAL = 'mycredential',COMPRESSION, STATS = 5;
GO 

• The name of the credential must match the container path
• IDENTITY='SHARED ACCESS SIGNATURE' , this is a mandatory string and cannot be changed
• use the SAS key in the secret clause

USE master
GO
CREATE CREDENTIAL 'https://<mystorageaccountname>.blob.core.windows.net/<mystorageaccountcontainername>' -- this name must match the container path, start with https and must not contain a forward slash.
   WITH IDENTITY='SHARED ACCESS SIGNATURE' -- this is a mandatory string and do not change it. 
   , SECRET = '<SAS Token>' -- this is the shared access signature key that you obtained in Lesson 1. 
GO

BACKUP DATABASE AdventureWorks2016  
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2016.bak';
GO

Create your Azure SQL Sample Database

Generate SQL Workload Script

Generating the workload

Create the Azure Table

Create the Runbook

<#
.SYNOPSIS  Generate SQL Workload on AdventureWorks   .DESCRIPTION  Generate SQL Workload on AdventureWorks    .EXAMPLE  SQLWorkload    .NOTES  AUTHOR: Pieter Vanhove  LAST EDIT: December 31, 2015  #>
  workflow SQLWorkload
{  param
 (  # Fully-qualified name of the Azure DB server 
 [parameter(Mandatory=$true)]   [string] $SqlServerName,
   # Fully-qualified name of the Azure DB server 
 [parameter(Mandatory=$true)]   [string] $SqlDatabaseName,
   # Credentials for $SqlServerName stored as an Azure Automation credential asset
 # When using in the Azure Automation UI, please enter the name of the credential asset for the "Credential" parameter
 [parameter(Mandatory=$true)]   [PSCredential] $Credential,
   # The storage account where the Azure Table is stored
 [parameter(Mandatory=$true)]   [string] $StorageAccount,
   # Define the Storage Account Key
 [parameter(Mandatory=$true)]   [string] $StorageKey
    )     inlinescript{     # Setup credentials and parameters 
 $ServerName = $Using:SqlServerName
 $DatabaseName = $Using:SqlDatabaseName
 $UserId = $Using:Credential.UserName  $Password = ($Using:Credential).GetNetworkCredential().Password  $StorageAccountName=$Using:StorageAccount
 $StorageAccountKey=$Using:StorageKey
   # Create connection for the database
 $DatabaseConnection = New-Object System.Data.SqlClient.SqlConnection
 $DatabaseCommand = New-Object System.Data.SqlClient.SqlCommand
   #Create Azure Storage Context 
 $Ctx = New-AzureStorageContext $StorageAccountName -StorageAccountKey $StorageAccountKey
 $TableName = "SQLWorkload"
   #Get a reference to a table.
 $table = Get-AzureStorageTable –Name $TableName -Context $Ctx
   #Create a table query.
 $TableQuery = New-Object Microsoft.WindowsAzure.Storage.Table.TableQuery
  #Define columns to select.
 $list = New-Object System.Collections.Generic.List[string]
 $list.Add("Query")
 
 
WHILE(1 -eq 1)   {      # Pick a Random Query from the input object 
    $ID = Get-Random -Minimum 1 -Maximum 38;     Write-Output $ID
    #Set query details.
    $TableQuery.FilterString = "ID eq $ID"
    $TableQuery.SelectColumns = $list
         #Execute the query.
    $Query = $table.CloudTable.ExecuteQuery($TableQuery)          #Exectute the query against the database
    $DatabaseConnection.ConnectionString = "Server=$ServerName; Database=$DatabaseName; User ID=$UserId; Password=$Password;Connection Timeout=300"
    $DatabaseConnection.Open();     # Create command for a specific database $DBName
    $DatabaseCommand.Connection = $DatabaseConnection
    $DatabaseCommand.CommandText = $Query.Properties["Query"].StringValue          $NonQueryResult = $DatabaseCommand.ExecuteNonQuery()                                              # Close connection
    $DatabaseConnection.Close()     #Write-Output $Query.Properties["Query"].StringValue
          # Sleep for 250 miliseconds between loops 
    Start-Sleep -Milliseconds 250    }
}
}

• $SqlServerName = The fully qualified name of your logical SQL Server
• $SqlDatabaseName = The name of your database, in my example AdventureWorks2014
• $Credential = This is the Azure Credential that you have just created to authenticate against your logical SQL Server
• $StorageAccount = The storage account that has been used for your Azure Table
• $StorageKey = The Storage Account Key to connect to your storage account

Launch the SQL Workload

Monitoring the workload

Conclusion