Migrate to Innovate Summit:
Learn how migrating and modernizing to Azure can boost your business's performance, resilience, and security, enabling you to fully embrace AI.Register now
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
This article provides samples to configure and manage an Azure SQL Database Hyperscale named replica.
Create a Hyperscale named replica
The following sample scenarios guide you to create a named replica WideWorldImporters_NamedReplica for database WideWorldImporters, using the Azure portal, T-SQL, PowerShell, or Azure CLI.
The following example creates a named replica WideWorldImporters_NamedReplica for database WideWorldImporters using T-SQL. The primary replica uses service level objective HS_Gen5_4, while the named replica uses HS_Gen5_2. Both use the same logical server named contosoeast.
In the Azure portal, browse to the database for which you want to create the named replica.
On the SQL Database page, select your database, scroll to Data management, select Replicas, and then select Create replica.
Choose Named replica under Replica configuration. Select an existing server or create a new server for the named replica. Enter named replica database name and configure the Compute + storage options if necessary.
In the Configure database page, select Yes for Would you like to make this database zone redundant?
Add at least one High-Availability Secondary Replica to your configuration.
Select Apply.
Select Review + create, review the information, and then select Create.
The named replica deployment process begins.
When the deployment is complete, the named replica displays its status.
Return to the primary database page, and then select Replicas. Your named replica is listed under Named replicas.
The following example creates a named replica WideWorldImporters_NamedReplica for database WideWorldImporters using T-SQL. The primary replica uses service level objective HS_Gen5_4, while the named replica uses HS_Gen5_2. Both use the same logical server named contosoeast.
The following example creates a named replica WideWorldImporters_NamedReplica for database WideWorldImporters using the PowerShell cmdlet New-AzSqlDatabaseSecondary. The primary replica uses service level objective HS_Gen5_4, while the named replica uses HS_Gen5_2. Both use the same logical server named contosoeast.
To configure a zone redundant Hyperscale named replica, you must specify both the –ZoneRedundant and -HighAvailabilityReplicaCount input parameters for New-AzSqlDatabaseSecondary.
The following example creates a named replica WideWorldImporters_NamedReplica for database WideWorldImporters using the Azure CLI command az sql db replica create. The primary replica uses service level objective HS_Gen5_4, while the named replica uses HS_Gen5_2. Both use the same logical server named contosoeast.
Azure CLI
az sql db replica create -g MyResourceGroup -n WideWorldImporters -s contosoeast --secondary-type named --partner-database WideWorldImporters_NamedReplica --partner-server contosoeast --service-objective HS_Gen5_2
To configure a zone redundant Hyperscale named replica, you must specify both the –zone-redundant and ha-replicas input parameters for az sql db replica create.
Azure CLI
az sql db replica create -g MyResourceGroup -n WideWorldImporters -s contosoeast --secondary-type named --partner-database WideWorldImporters_NamedReplica --partner-server contosoeast --service-objective HS_Gen5_2 --ha-replicas1-zone-redundant
To validate if a named replica is being created:
Azure CLI
az sql db show -g MyResourceGroup -n WideWorldImporters -s contosoeast
As there is no data movement involved, in most cases a named replica will be created in about a minute. Once the named replica is available, it will be visible from the Azure portal or any command-line tool like AZ CLI or PowerShell. A named replica is usable as a regular read-only database.
Connect to a Hyperscale named replica
To connect to a Hyperscale named replica, you must use the connection string for that named replica, referencing its server and database names. There is no need to specify the option ApplicationIntent=ReadOnly as named replicas are always read-only.
Just like for HA replicas, even though the primary, HA, and named replicas share the same data on the same set of page servers, data caches on each named replica are kept in sync with the primary. The sync is maintained by the transaction log service, which forwards log records from the primary to named replicas. As the result, depending on the workload being processed by a named replica, application of the log records might happen at different speeds, and thus different replicas could have different data latency relative to the primary replica.
Modify a Hyperscale named replica
You can define the service level objective of a named replica when you create it, via the ALTER DATABASE command or in any other supported way (Portal, AZ CLI, PowerShell). If you need to change the service level objective after the named replica has been created, you can do it using the ALTER DATABASE ... MODIFY command on the named replica itself.
In the following example, WideWorldImporters_NamedReplica is the named replica of WideWorldImporters database.
Azure HPC is a purpose-built cloud capability for HPC & AI workload, using leading-edge processors and HPC-class InfiniBand interconnect, to deliver the best application performance, scalability, and value. Azure HPC enables users to unlock innovation, productivity, and business agility, through a highly available range of HPC & AI technologies that can be dynamically allocated as your business and technical needs change. This learning path is a series of modules that help you get started on Azure HPC - you
Administer an SQL Server database infrastructure for cloud, on-premises and hybrid relational databases using the Microsoft PaaS relational database offerings.