20250226 improve linkage, headings

Author: WilliamDAssafMSFT

azure-sql/database/automated-backups-change-settings.md

@@ -161,7 +161,7 @@ To configure backup storage redundancy when you're creating a new database, you
 
 By default, all databases in Azure SQL Database use geo-redundant storage for backups. Geo-restore is disabled if a database is created or updated with locally redundant or zone-redundant backup storage.
 
-This example creates a database in the [General Purpose](service-tier-general-purpose.md) service tier with local backup redundancy:
+This example creates a database in the [General Purpose](service-tiers-sql-database-vcore.md#general-purpose) service tier with local backup redundancy:
 
 ```azurecli
 az sql db create \
@@ -222,7 +222,7 @@ For syntax details, see [az sql db copy](/cli/azure/sql/db#az-sql-db-copy). For
 
 To configure backup storage redundancy when you're creating a new database, you can specify the `-BackupStorageRedundancy` parameter with the `New-AzSqlDatabase` cmdlet. Possible values are `Geo`, `Zone`, and `Local`. By default, all databases in Azure SQL Database use geo-redundant storage for backups. Geo-restore is disabled if a database is created with locally redundant or zone-redundant backup storage.
 
-This example creates a database in the [General Purpose](service-tier-general-purpose.md) service tier with local backup redundancy:
+This example creates a database in the [General Purpose](service-tiers-sql-database-vcore.md#general-purpose) service tier with local backup redundancy:
 
 ```powershell
 # Create a new database with geo-redundant backup storage.  
@@ -244,7 +244,7 @@ For details, see [Set-AzSqlDatabase](/powershell/module/az.sql/set-azsqldatabase
 
 Carefully consider the configuration option for `--backup-storage-redundancy` when you're creating a Hyperscale database. You can specify storage redundancy only during the database creation process for Hyperscale databases. The selected storage redundancy option will be used for the lifetime of the database for both data storage redundancy and backup storage redundancy. Learn more in [Hyperscale backups and storage redundancy](hyperscale-automated-backups-overview.md#data-and-backup-storage-redundancy).
 
-Existing databases can migrate to different storage redundancy through [database copy](database-copy.md) or point-in-time restore. This example creates a database in the [Hyperscale](service-tier-general-purpose.md) service tier with zone redundancy:
+Existing databases can migrate to different storage redundancy through [database copy](database-copy.md) or point-in-time restore. This example creates a database in the [Hyperscale](service-tiers-sql-database-vcore.md#general-purpose) service tier with zone redundancy:
 
 ```powershell
 # Create a new database with geo-redundant backup storage.  

azure-sql/database/features-comparison.md

@@ -84,7 +84,7 @@ The following table lists the major features of SQL Server and provides informat
 | [Link feature](../managed-instance/managed-instance-link-feature-overview.md) | No | Yes |
 | [Linked servers](/sql/relational-databases/linked-servers/linked-servers-database-engine) | No, see [Elastic query](elastic-query-horizontal-partitioning.md) | Yes. Only to [SQL Server and SQL Database](../managed-instance/transact-sql-tsql-differences-sql-server.md#linked-servers) without distributed transactions. |
 | [Linked servers](/sql/relational-databases/linked-servers/linked-servers-database-engine) that read from files (CSV, Excel)| No. Use [BULK INSERT](/sql/t-sql/statements/bulk-insert-transact-sql#e-importing-data-from-a-csv-file) or [OPENROWSET](/sql/t-sql/functions/openrowset-transact-sql#g-accessing-data-from-a-csv-file-with-a-format-file) as an alternative for CSV format. | No. Use [BULK INSERT](/sql/t-sql/statements/bulk-insert-transact-sql#e-importing-data-from-a-csv-file) or [OPENROWSET](/sql/t-sql/functions/openrowset-transact-sql#g-accessing-data-from-a-csv-file-with-a-format-file) as an alternative for CSV format. Track these requests on [SQL Managed Instance feedback item](https://feedback.azure.com/d365community/idea/db80cf6e-3425-ec11-b6e6-000d3a4f0f84)|
-| [Log shipping](/sql/database-engine/log-shipping/about-log-shipping-sql-server) | [Availability through redundancy](high-availability-sla-local-zone-redundancy.md) is included with every database. Disaster recovery is discussed in [Overview of business continuity](business-continuity-high-availability-disaster-recover-hadr-overview.md). | Natively built in as a part of [Azure Data Migration Service (DMS)](/azure/dms/tutorial-sql-server-to-managed-instance) migration process. Natively built for custom data migration projects as an external [Log Replay Service](../managed-instance/log-replay-service-migrate.md).<br /> Not available as High availability solution, because other [Availability through redundancy](high-availability-sla-local-zone-redundancy.md) methods are included with every database and it isn't recommended to use Log-shipping as HA alternative. Disaster recovery is discussed in [Overview of business continuity](business-continuity-high-availability-disaster-recover-hadr-overview.md). Not available as a replication mechanism between databases - use secondary replicas on [Business Critical tier](service-tier-business-critical.md), [failover groups](failover-group-sql-db.md), or [transactional replication](../managed-instance/replication-transactional-overview.md) as the alternatives. |
+| [Log shipping](/sql/database-engine/log-shipping/about-log-shipping-sql-server) | [Availability through redundancy](high-availability-sla-local-zone-redundancy.md) is included with every database. Disaster recovery is discussed in [Overview of business continuity](business-continuity-high-availability-disaster-recover-hadr-overview.md). | Natively built in as a part of [Azure Data Migration Service (DMS)](/azure/dms/tutorial-sql-server-to-managed-instance) migration process. Natively built for custom data migration projects as an external [Log Replay Service](../managed-instance/log-replay-service-migrate.md).<br /> Not available as High availability solution, because other [Availability through redundancy](high-availability-sla-local-zone-redundancy.md) methods are included with every database and it isn't recommended to use Log-shipping as HA alternative. Disaster recovery is discussed in [Overview of business continuity](business-continuity-high-availability-disaster-recover-hadr-overview.md). Not available as a replication mechanism between databases - use secondary replicas on [Business Critical tier](service-tiers-sql-database-vcore.md#business-critical), [failover groups](failover-group-sql-db.md), or [transactional replication](../managed-instance/replication-transactional-overview.md) as the alternatives. |
 | [Logins and users](/sql/relational-databases/security/authentication-access/principals-database-engine) | Yes, but `CREATE LOGIN` and `ALTER LOGIN` statements are limited. Windows logins are not supported. Microsoft Entra logins are in preview. `EXECUTE AS LOGIN` isn't supported - use `EXECUTE AS USER`.  | Yes, with some [differences](../managed-instance/transact-sql-tsql-differences-sql-server.md#logins-and-users). See [Windows Authentication for Azure SQL Managed Instance](../managed-instance/winauth-implementation-aad-kerberos.md) - the process requires Active Directory synchronization to Microsoft Entra ID. |
 | [Maintenance window](maintenance-window.md) selection | Yes | Yes |
 | [Configure advance notifications for planned maintenance events](advance-notifications.md) | Yes | Yes |

azure-sql/database/migrate-dtu-to-vcore.md

@@ -67,7 +67,7 @@ ALTER DATABASE <database name> MODIFY (EDITION = '<service tier, such as Hypersc
 
 ## Choose the vCore service tier and service objective
 
-For most DTU to vCore migration scenarios, databases and elastic pools in the Basic and Standard service tiers map to the [General Purpose](service-tier-general-purpose.md) service tier. Databases and elastic pools in the Premium service tier map to the [Business Critical](service-tier-business-critical.md) service tier. Depending on application scenario and requirements, the [Hyperscale](service-tier-hyperscale.md) service tier can often be used as the migration target for databases and elastic pools in all DTU service tiers.
+For most DTU to vCore migration scenarios, databases and elastic pools in the Basic and Standard service tiers map to the [General Purpose](service-tiers-sql-database-vcore.md#general-purpose) service tier. Databases and elastic pools in the Premium service tier map to the [Business Critical](service-tiers-sql-database-vcore.md#business-critical) service tier. Depending on application scenario and requirements, the [Hyperscale](service-tier-hyperscale.md) service tier can often be used as the migration target for databases and elastic pools in all DTU service tiers.
 
 To choose the service objective, or compute size, for the migrated database in the vCore model, you can use a basic but approximate rule of thumb: every 100 DTUs in the Basic or Standard tiers require *at least* 1 vCore, and every 125 DTUs in the Premium tier require *at least* 1 vCore.
 

azure-sql/database/resource-limits-vcore-elastic-pools.md

@@ -49,8 +49,7 @@ vCore resource limits are listed in the following articles, please be sure to up
 /database/resource-limits-vcore-single-databases.md
 /database/resource-limits-vcore-elastic-pools.md
 /database/resource-limits-logical-server.md
-/database/service-tier-general-purpose.md
-/database/service-tier-business-critical.md
+/database/service-tiers-sql-database-vcore.md
 /database/service-tier-hyperscale.md
 /managed-instance/resource-limits.md
 --->
@@ -955,8 +954,7 @@ vCore resource limits are listed in the following articles, please be sure to up
 /database/resource-limits-vcore-single-databases.md
 /database/resource-limits-vcore-elastic-pools.md
 /database/resource-limits-logical-server.md
-/database/service-tier-general-purpose.md
-/database/service-tier-business-critical.md
+/database/service-tier-database-vcore.md
 /database/service-tier-hyperscale.md
 /managed-instance/resource-limits.md
 --->

azure-sql/database/resource-limits-vcore-single-databases.md

@@ -53,8 +53,7 @@ vCore resource limits are listed in the following articles, please be sure to up
 /database/resource-limits-vcore-single-databases.md
 /database/resource-limits-vcore-elastic-pools.md
 /database/resource-limits-logical-server.md
-/database/service-tier-general-purpose.md
-/database/service-tier-business-critical.md
+/database/service-tier-sql-database-vcore.md
 /database/service-tier-hyperscale.md
 /managed-instance/resource-limits.md
 --->

azure-sql/database/reverse-migrate-from-hyperscale.md

@@ -25,7 +25,7 @@ Reverse migration is available under the following conditions:
 
 - Reverse migration is only available within 45 days of the original migration to Hyperscale.
 - Databases originally created in the Hyperscale service tier aren't eligible for reverse migration.
-- You might reverse migrate to the [General Purpose](service-tier-general-purpose.md) service tier only. Your migration from Hyperscale to General Purpose can target either the serverless or provisioned compute tiers. If you wish to migrate the database to another service tier, such as [Business Critical](service-tier-business-critical.md) or a [DTU based service tier](service-tiers-dtu.md), first reverse migrate to the General Purpose service tier, then change the service tier.
+- You might reverse migrate to the [General Purpose](service-tiers-sql-database-vcore.md#general-purpose) service tier only. Your migration from Hyperscale to General Purpose can target either the serverless or provisioned compute tiers. If you wish to migrate the database to another service tier, such as [Business Critical](service-tiers-sql-database-vcore.md#business-critical) or a [DTU based service tier](service-tiers-dtu.md), first reverse migrate to the General Purpose service tier, then change the service tier.
 - Reverse migration to databases with less than 2 vCores is not supported. You can scale the database down to fewer than 2 vCores once the migration is complete.
 - Direct reverse migration from, or to, an elastic pool isn't supported. You can reverse migrate only a Hyperscale single database to a General Purpose single database.
     - If the Hyperscale database is part of a [Hyperscale elastic pool](./hyperscale-elastic-pool-overview.md), you have to first remove it from the Hyperscale elastic pool prior to reverse migration.

azure-sql/database/serverless-tier-overview.md

@@ -17,7 +17,7 @@ ms.custom:
 # Serverless compute tier for Azure SQL Database
 [!INCLUDE [appliesto-sqldb](../includes/appliesto-sqldb.md)]
 
-Serverless is a [compute tier](service-tiers-sql-database-vcore.md#compute) for single databases in Azure SQL Database that automatically scales compute based on workload demand and bills for the amount of compute used per second. The serverless compute tier also automatically pauses databases during inactive periods when only storage is billed and automatically resumes databases when activity returns. The serverless compute tier is available in the [General Purpose](service-tier-general-purpose.md) service tier and the [Hyperscale](service-tier-hyperscale.md) service tier.
+Serverless is a [compute tier](service-tiers-sql-database-vcore.md#compute) for single databases in Azure SQL Database that automatically scales compute based on workload demand and bills for the amount of compute used per second. The serverless compute tier also automatically pauses databases during inactive periods when only storage is billed and automatically resumes databases when activity returns. The serverless compute tier is available in the [General Purpose](service-tiers-sql-database-vcore.md#general-purpose) service tier and the [Hyperscale](service-tier-hyperscale.md) service tier.
 
 > [!NOTE]
 > Auto-pause and auto-resume are currently only supported in the General Purpose service tier.
@@ -78,7 +78,7 @@ The following table describes serverless support based on purchasing model, serv
 | **Category** | **Supported** | **Not supported**|
 |:---|:---|:---|
 | **Purchasing model** | [vCore](service-tiers-vcore.md) | [DTU](service-tiers-dtu.md) |
-| **Service tier** | [General Purpose](service-tier-general-purpose.md) <br/> [Hyperscale](service-tier-hyperscale.md) | Business Critical| 
+| **Service tier** | [General Purpose](service-tiers-sql-database-vcore.md#general-purpose) <br/> [Hyperscale](service-tier-hyperscale.md) | Business Critical| 
 | **Hardware** | Standard-series (Gen5) | All other hardware |  
 
 ## Autoscaling
@@ -718,4 +718,4 @@ Currently, 80 maximum vCores with availability zone support in serverless for th
 ## Related content
 
 - To get started, see [Quickstart: Create a single database - Azure SQL Database](single-database-create-quickstart.md).
-- For serverless service tier choices, see [General Purpose](service-tier-general-purpose.md) and [Hyperscale](service-tier-hyperscale.md).
+- For serverless service tier choices, see [General Purpose](service-tiers-sql-database-vcore.md#general-purpose) and [Hyperscale](service-tier-hyperscale.md).

azure-sql/database/service-tier-hyperscale.md

@@ -24,7 +24,7 @@ Azure SQL Database is based on SQL Server Database Engine architecture that is a
 
 The Hyperscale service tier is suitable for all workload types. Its cloud-native architecture provides independently scalable compute and storage to support the widest variety of traditional and modern applications. Compute and storage resources in Hyperscale substantially exceed the resources available in the General Purpose and Business Critical tiers.
 
-For details on the General Purpose and Business Critical service tiers in the vCore-based purchasing model, see [General Purpose](service-tier-general-purpose.md) and [Business Critical](service-tier-business-critical.md) service tiers. For a comparison of the vCore-based purchasing model with the DTU-based purchasing model, see [Compare vCore and DTU-based purchasing models of Azure SQL Database](purchasing-models.md).
+For details on the General Purpose and Business Critical service tiers in the vCore-based purchasing model, see [General Purpose](service-tiers-sql-database-vcore.md#general-purpose) and [Business Critical](service-tiers-sql-database-vcore.md#business-critical) service tiers. For a comparison of the vCore-based purchasing model with the DTU-based purchasing model, see [Compare vCore and DTU-based purchasing models of Azure SQL Database](purchasing-models.md).
 
 The Hyperscale service tier is currently only available for Azure SQL Database, and not for Azure SQL Managed Instance.
 
@@ -126,8 +126,7 @@ vCore resource limits are listed in the following articles, please be sure to up
 /database/resource-limits-vcore-single-databases.md
 /database/resource-limits-vcore-elastic-pools.md
 /database/resource-limits-logical-server.md
-/database/service-tier-general-purpose.md
-/database/service-tier-business-critical.md
+/database/service-tiers-sql-database-vcore.md
 /database/service-tier-hyperscale.md
 /managed-instance/resource-limits.md
 --->

azure-sql/database/service-tiers-sql-database-vcore.md

@@ -4,7 +4,7 @@ description: The vCore purchasing model lets you independently scale compute and
 author: WilliamDAssafMSFT
 ms.author: wiassaf
 ms.reviewer: sashan, moslake, mathoma, dfurman, srinia
-ms.date: 09/12/2024
+ms.date: 02/26/2025
 ms.service: azure-sql-database
 ms.subservice: performance
 ms.topic: conceptual
@@ -137,7 +137,9 @@ In the architectural model for the General Purpose service tier, there are two l
 
 Whenever the database engine or operating system is upgraded, some part of underlying infrastructure fails, or if some critical issue is detected in the `sqlservr.exe` process, Azure Service Fabric moves the stateless process to another stateless compute node. There's a set of spare nodes that is waiting to run new compute service if a failover of the primary node happens in order to minimize failover time. Data in Azure storage layer isn't affected, and data/log files are attached to newly initialized process. This process guarantees 99.99% availability by default and 99.995% availability when [zone redundancy](high-availability-sla-local-zone-redundancy.md#zone-redundant-availability) is enabled. There might be some performance impacts to heavy workloads that are in-flight due to transition time and the fact the new node starts with cold cache.
 
-### When to choose this service tier
+<a id="when-to-choose-this-service-tier"></a>
+
+#### When to choose the General Purpose service tier
 
 The General Purpose service tier is the default service tier in Azure SQL Database designed for most of generic workloads. If you need a fully managed database engine with a default SLA and storage latency between 5 ms and 10 ms, the General Purpose tier is the option for you.
 
@@ -153,7 +155,9 @@ Both the database engine process and underlying .mdf/.ldf files are placed on th
 
 In addition, the Business Critical cluster has a built-in [Read Scale-Out](read-scale-out.md) capability that provides a free-of charge read-only replica used to run read-only queries (such as reports) that won't affect the performance of the workload on your primary replica.
 
-#### When to choose this service tier
+<a id="when-to-choose-this-service-tier-1"></a>
+
+#### When to choose the Business Critical service tier
 
 The Business Critical service tier is designed for applications that require low-latency responses from the underlying SSD storage (1-2 ms in average), faster recovery if the underlying infrastructure fails, or need to off-load reports, analytics, and read-only queries to the free of charge readable secondary replica of the primary database.
 
@@ -172,7 +176,9 @@ The Hyperscale service tier is suitable for all workload types. Its cloud native
 
 To learn more, review [Hyperscale service tier for Azure SQL Database](service-tier-hyperscale.md).
 
-### When to choose this service tier
+<a id="when-to-choose-this-service-tier-2"></a>
+
+#### When to choose the Hyperscale service tier
 
 The Hyperscale service tier removes many of the practical limits traditionally seen in cloud databases. Where most other databases are limited by the resources available in a single node, databases in the Hyperscale service tier have no such limits. With its flexible storage architecture, a Hyperscale database grows as needed - and you're billed only for the storage capacity you use.