Azure Tech Hub: Your One-Stop Cloud Solution

What sets the Hyperscale tier apart from General Purpose or Business Critical models is its ability to keep storage and compute resources independent of each other.With Hyperscale, storage is flexible and can be increased as needed without adjusting DTU or vCore counts. For example, databases in Elastic Pools can reach around 3 TB of storage at their current vCore allocations. While conventional tiers require scaling up vCores to unlock more storage beyond this benchmark, Hyperscale lets you boost your database size without adding unnecessary computing resources, making storage upgrades simple and cost-efficient.

How to Use Hyperscale Elastic Pools
Elastic pools in Azure SQL Database allow multiple databases to tap into a shared reservoir of performance resources, supporting cost savings and streamlined management. With the Hyperscale tier, this shared approach is elevated further, offering:

• Massive Storage Potential: Manage databases that grow up to 128 TB, ready for all your future data needs.
• Optimised Resource Scaling: Scale compute and storage independently to tailor performance precisely, avoiding surprise charges.
• Quickly Scale and Restore: Adapt to changing workloads in moments and benefit from fast backup and restore processes to reduce delays.

Hyperscale Pool Architecture Explained
Traditionally, a single Hyperscale database relies on three main independent systems: its compute resources, “Page Servers” handling storage, and the log service for transaction management. Within a Hyperscale elastic pool, all databases access shared compute and log resources for optimal efficiency. If you enable high availability, Azure creates a separate, dedicated set of compute and log systems for every high-availability pool.
Here’s what makes up a Hyperscale elastic pool:

• An elastic pool includes a main pool for primary Hyperscale databases, plus up to four extra pools for high-availability configurations when enabled.
• Primary databases in this pool use the same SQL Server engine processes, sharing CPU, vCores, RAM, and SSD cache for better resource distribution.
• If high availability is turned on, extra pools are spun up to house read-only database replicas that mirror the main pool, with a maximum of four high-availability replica pools per primary pool. These read-only replicas share the pool’s compute, RAM, and SSD cache.
• The pool’s databases access a unified log service, but the high-availability read-only replicas do not, since they don’t handle write operations.
• Every Hyperscale database maintains its own set of page servers, which are shared with its secondary replica counterparts in the high-availability setup.
• Geo-replicated Hyperscale secondary databases can be moved into a different elastic pool as needed.
• To connect to a read-only replica, set ApplicationIntent=ReadOnly in your connection string – you’ll be automatically routed to a suitable high-availability pool instance.

The illustration above reflects the design of a Hyperscale elastic pool.

How Hyperscale Can Save You Money
The Hyperscale tier is especially cost-effective for businesses managing large datasets, but who don’t require high compute power:

• Compute and Storage Decoupled: Unlike the classic tiers where storage means more spend on compute, Hyperscale allows you to add storage on demand without affecting your compute bill.
• Real-World Savings: Some organisations have reported reductions in database costs by half when they switched to Hyperscale, thanks to these flexible options.

How to Convert Databases to Hyperscale Elastic Pools with PowerShell
You can use PowerShell to migrate several General Purpose databases into an existing Hyperscale elastic pool—let’s call it hsep1. Here’s a basic step-by-step guide for the process:

1. Use the Get-AzSqlElasticPoolDatabase command to list all databases inside the General Purpose elastic pool called gpep1.
2. Filter the results with Where-Object so you only see databases whose names start with “gpepdb”.
3. For each database, run the Set-AzSqlDatabase cmdlet – this shifts the database to the Hyperscale tier and adds it to hsep1.
   • With the -AsJob option, you can run several conversions simultaneously. For single conversions, just drop -AsJob.

$dbs = Get-AzSqlElasticPoolDatabase -ResourceGroupName "myResourceGroup" -ServerName "mylogicalserver" -ElasticPoolName "gpep1" $dbs | Where-Object { $_.DatabaseName -like "gpepdb*" } | %

Set-AzSqlDatabase

-ResourceGroupName"myResourceGroup" -ServerName"mylogicalserver" -DatabaseName ($_.DatabaseName) -ElasticPoolName"hsep1" -AsJob}

Restrictions and Known Issues
It’s important to understand these key limitations:

• You cannot switch an existing non-Hyperscale elastic pool directly to Hyperscale. For alternative solutions, see the conversion instructions.
• Downgrading a Hyperscale elastic pool to a non-Hyperscale pool is not supported.
• If you need to “reverse migrate” databases from a Hyperscale elastic pool, you must first remove the database from the pool. Only then can it be converted back to a general-purpose standalone database.
• With the Hyperscale tier, zone redundancy must be set when the database or pool is created; it cannot be changed later. More about this can be read at Migrating Azure SQL Database to availability zone support.
• You cannot add a named replica into a Hyperscale elastic pool. Attempting this will trigger an UnsupportedReplicationOperation error. To achieve this, create the replica as a separate Hyperscale database instead.

How to Migrate to Hyperscale and Optimise Adaptability
Switching to the Hyperscale performance tier is designed to be as smooth as possible:

• Seamless Online Migration: Begin with a background data copy, keeping your existing database accessible. A short switchover window completes the transition, keeping downtime to a minimum.
• Easy Rollback: If the Hyperscale tier doesn’t suit your requirements, you can move your database back to other service tiers, ensuring your solution remains agile.

Top Points to Remember
When considering Hyperscale for your SQL databases:

• Type of Workloads: Ideal for systems with high storage needs but moderate compute loads, such as data lakes, analytics, or archival systems.
• Performance Review: Check that Hyperscale’s available throughput and response times support your performance objectives.
• Cost Analysis: Compare projected Hyperscale expenses to your current outlay to make a well-informed decision.

How to Troubleshoot Common Migration Problems
If you experience delays or failures during migration, ensure the target Hyperscale resources are available and check your pool limits. Standard errors can often be resolved by removing non-supported features or by verifying your Azure subscription permissions.
For detailed step-by-step troubleshooting, refer to the official Azure documentation or consult with your database administrator.

Summary
Azure SQL Database’s Hyperscale tier delivers a powerful and affordable option for managing large-scale data workloads. It allows for independent scaling of compute and storage, letting businesses increase performance as needed without significant cost increases. Careful planning and review of your application needs can help you get the most out of Hyperscale’s flexibility and reduce unnecessary expenditures while maintaining optimal performance levels.