Merge pull request #36650 from JustPies/jpzoneterms-2-19

551033 Remediate availability zone terminology

Author: v-regandowner

azure-sql/database/high-availability-sla-local-zone-redundancy.md

@@ -49,7 +49,7 @@ There are three availability architectural models:
 - **Local storage model** that is based on a cluster of database engine processes. The local storage model relies on the fact that there's always a quorum of available database engine nodes. This architecture targets mission-critical applications with high IO performance, high transaction rate and guarantees minimal performance impact on your workload during maintenance activities.
 - **Hyperscale model** which uses a distributed system of highly available components such as compute nodes, page servers, log service, and persistent storage. Each component supporting a Hyperscale database provides its own redundancy and resiliency to failures. Compute nodes, page servers, and log service run on Azure Service Fabric, which controls health of each component and performs failovers to available healthy nodes as necessary. Persistent storage uses Azure Storage with its native high availability and redundancy capabilities. To learn more, see [Hyperscale architecture](hyperscale-architecture.md).
 
-Within each of the three availability models, SQL Database supports local redundancy and zonal redundancy options. Local redundancy provides resiliency within a datacenter, while zonal redundancy improves resiliency further by protecting against outages of an availability zone within a region.
+Within each of the three availability models, SQL Database supports local redundancy and zone redundancy options. Local redundancy provides resiliency within a datacenter, while zone redundancy improves resiliency further by protecting against outages of an availability zone within a region.
 
 The following table shows the availability options based on service tiers:
 
@@ -229,7 +229,7 @@ Consider the following limitations:
 
 In Azure SQL Database, a [server](logical-servers.md) is a logical construct that acts as a central administrative point for a collection of databases. At the server level, you can administer logins, authentication method, firewall rules, auditing rules, threat detection policies, and failover groups. Data related to some of these features, such as logins and firewall rules, is stored in the `master` database. Similarly, data for some DMVs, for example [sys.resource_stats](/sql/relational-databases/system-catalog-views/sys-resource-stats-azure-sql-database), is also stored in the `master` database.
 
-When a database with a zone-redundant configuration is created on a logical server, the `master` database associated with the server is automatically made zone-redundant as well. This ensures that in a zonal outage, applications using the database remain unaffected because features dependent on the `master` database, such as logins and firewall rules, are still available. Making the `master` database zone-redundant is an asynchronous process and will take some time to finish in the background.
+When a database with a zone-redundant configuration is created on a logical server, the `master` database associated with the server is automatically made zone-redundant as well. This ensures that in a zone outage, applications using the database remain unaffected because features dependent on the `master` database, such as logins and firewall rules, are still available. Making the `master` database zone-redundant is an asynchronous process and will take some time to finish in the background.
 
 When none of the databases on a server are zone-redundant, or when you create an empty server, then the `master` database associated with the server is **not zone-redundant**. To migrate your Azure SQL Database to use zone redundancy, follow the steps in [Migrate Azure SQL Database to availability zone support](enable-zone-redundancy.md).
 

docs/t-sql/statements/create-database-transact-sql.md

@@ -1081,7 +1081,7 @@ By default, the metadata catalog for system object names is collated to `SQL_Lat
 
 Specifies how the point-in-time restore and long-term retention backups for a database are replicated. Geo restore or ability to recover from regional outage is only available when database is created with `GEO` backup storage redundancy. Unless explicitly specified, databases created with T-SQL use geo-redundant backup storage.
 
-Use `GEOZONE` for geo-zone redundant storage. Geo-zone redundant storage (GZRS) offers the highest level of protection against zonal outages as well as regional outages for any workload.
+Use `GEOZONE` for geo-zone redundant storage. Geo-zone redundant storage (GZRS) offers the highest level of protection against zone outages as well as regional outages for any workload.
 
 To enforce data residency when you're creating a database by using T-SQL, use `LOCAL` or `ZONE` as input to the `BACKUP_STORAGE_REDUNDANCY` parameter.