debuglevel
diff --git a/‎azure-sql/database/high-availability-sla.md‎
Lines changed: 7 additions & 7 deletions b/‎azure-sql/database/high-availability-sla.md‎
Lines changed: 7 additions & 7 deletions
diff --git a/‎azure-sql/database/maintenance-window-faq.yml‎
Lines changed: 12 additions & 12 deletions b/‎azure-sql/database/maintenance-window-faq.yml‎
Lines changed: 12 additions & 12 deletions
@@ -44,7 +44,7 @@ Within each of the three availability models, SQL Database supports local redund
 The following table shows the availability options based on service tiers: 
 
 
-| Service tier | High availability model | Locally-redundant availability | Zone-redundant availability |
+| Service tier | High availability model | locally redundant availability | Zone-redundant availability |
 |---|---|---| --- |
 | General Purpose (vCore) | Remote storage  |  Yes | Yes |
 | Business Critical (vCore) | Local storage  | Yes | Yes |
@@ -55,11 +55,11 @@ The following table shows the availability options based on service tiers:
 
 
 
-## Locally-redundant availability 
+## Locally redundant availability 
 
-Locally-redundant availability is based on storing your database to [locally-redundant storage (LRS)](/azure/storage/common/storage-redundancy#locally-redundant-storage) which copies your data three times within a single datacenter in the primary region and protects your data in the event of local failure, such as a small-scale network or power failure. LRS is the lowest-cost redundancy option and offers the least durability compared to other options.  If a large-scale disaster such as fire or flooding occurs within a region, all replicas of a storage account using LRS may be lost or unrecoverable. As such, to further protect your data when using the locally-redundant availability option, consider using a more resilient storage option for your [database backups](automated-backups-overview.md#backup-storage-redundancy). This does not apply to Hyperscale databases, where the same storage is used for both data files and backups. 
+Locally redundant availability is based on storing your database to [locally redundant storage (LRS)](/azure/storage/common/storage-redundancy#locally-redundant-storage) which copies your data three times within a single datacenter in the primary region and protects your data in the event of local failure, such as a small-scale network or power failure. LRS is the lowest-cost redundancy option and offers the least durability compared to other options.  If a large-scale disaster such as fire or flooding occurs within a region, all replicas of a storage account using LRS may be lost or unrecoverable. As such, to further protect your data when using the locally redundant availability option, consider using a more resilient storage option for your [database backups](automated-backups-overview.md#backup-storage-redundancy). This does not apply to Hyperscale databases, where the same storage is used for both data files and backups. 
 
-Locally-redundant availability is available to all databases in all service tiers. 
+Locally redundant availability is available to all databases in all service tiers. 
 
 ### <a id="general-purpose-service-tier-zone-redundant-availability"></a> Basic, Standard and General Purpose service tiers 
 
@@ -138,7 +138,7 @@ Consider the following when configuring your General Purpose databases with zone
   - (North America) South Central US
   - (North America) West US 2  
   - (South America) Brazil South
-- For zone redundant availability, choosing a [maintenance window](maintenance-window.md) other than the default is currently available in [select regions](maintenance-window.md#azure-region-support).  
+- For zone redundant availability, choosing a [maintenance window](maintenance-window.md) other than the default is currently available in [select regions](maintenance-window.md#azure-sql-database-region-support-for-maintenance-windows).  
 - Zone-redundant configuration is only available in SQL Database when standard-series (Gen5) hardware is selected. 
 - Zone-redundancy is not available for Basic and Standard service tiers in the DTU purchasing model. 
 
@@ -156,7 +156,7 @@ Consider the following when configuring your Premium or Business Critical databa
 
 - When using the Business Critical tier, zone-redundant configuration is only available when the Gen5 hardware is selected. 
 - For up to date information about the regions that support zone-redundant databases, see [Services support by region](/azure/availability-zones/az-region).
-- For zone redundant availability, choosing a [maintenance window](./maintenance-window.md) other than the default is currently available in [select regions](maintenance-window.md#azure-region-support).
+- For zone redundant availability, choosing a [maintenance window](./maintenance-window.md) other than the default is currently available in [select regions](maintenance-window.md#azure-sql-database-region-support-for-maintenance-windows).
 
 ### <a id="hyperscale-service-tier-zone-redundant-availability"></a> Hyperscale service tier
 
@@ -167,7 +167,7 @@ Enabling this configuration ensures zone-level resiliency through replication ac
 Consider the following limitations:
 
 - Zone redundant configuration can only be specified during database creation. This setting can't be modified once the resource is provisioned. Use [Database copy](database-copy.md), [point-in-time restore](recovery-using-backups.md#point-in-time-restore), or create a [geo-replica](active-geo-replication-overview.md) to update the zone redundant configuration for an existing Hyperscale database. When using one of these update options, if the target database is in a different region than the source or if the database backup storage redundancy from the target differs from the source database, the [copy operation](database-copy.md#database-copy-for-azure-sql-hyperscale) will be a size of data operation.
-- For zone redundant availability, choosing a [maintenance window](maintenance-window.md) other than the default is currently available in [select regions](maintenance-window.md#azure-region-support).
+- For zone redundant availability, choosing a [maintenance window](maintenance-window.md) other than the default is currently available in [select regions](maintenance-window.md#azure-sql-database-region-support-for-maintenance-windows).
 - Only standard-series (Gen5) hardware is supported.
 - Named replicas aren't currently supported.
 - There's currently no option to specify zone redundancy when migrating a database to Hyperscale using the Azure portal. However, zone redundancy can be specified using Azure PowerShell, Azure CLI, or the REST API when migrating an existing database from another Azure SQL Database service tier to Hyperscale. Here's an example with Azure CLI: `az sql db update --resource-group "myResourceGroup" --server "myServer" --name "myDB" --edition Hyperscale --zone-redundant true`
 
@@ -10,7 +10,7 @@ metadata:
   ms.author: wiassaf
   ms.reviewer: mathoma
   ms.custom: 
-  ms.date: 12/01/2022
+  ms.date: 07/31/2023
   monikerRange: "=azuresql||=azuresql-db||=azuresql-mi"
 
 title: Maintenance window FAQ
@@ -24,23 +24,23 @@ sections:
 
       - question: What is the default maintenance policy if I don't choose any specific window? 
         answer: |
-          Maintenance events will occur during the default window 5PM to 8AM local time, Monday - Sunday. 
+          Maintenance events occur during the default window 5PM to 8AM local time, Monday - Sunday. 
 
       - question: Users work in a different time zone than the Azure data center. Which time zone is local?
         answer: |
           Local time is determined by the location of Azure region that hosts the resource and may observe daylight saving time in accordance with local time zone definition. It isn't determined by the time zone configured on SQL database (always UTC) or managed instance.
 
       - question: Can I choose a specific time/day for the maintenance window?
         answer: |
-          No, you can choose between pre-scheduled weekday or weekend windows. The maintenance can happen anytime or day within the window.  
+          No, you can choose between prescheduled weekday or weekend windows. The maintenance can happen anytime or day within the window.  
 
       - question: What happens once I choose a maintenance window? 
         answer: | 
-          Configuring maintenance window is a long running asynchronous operation, similar to changing the service tier of your Azure SQL resource. The resource is available during the process, except a short reconfiguration that happens at the end of the operation and typically lasts up to 8 seconds even in case of interrupted long-running transactions. To minimize the impact of the reconfiguration, you should perform the operation outside of the peak hours. For Azure SQL Managed Instance, the IP address of the managed instance will change.
+          Configuring maintenance window is a long running asynchronous operation, similar to changing the service tier of your Azure SQL resource. The resource is available during the process, except a short reconfiguration that happens at the end of the operation and typically lasts up to 8 seconds even in case of interrupted long-running transactions. To minimize the impact of the reconfiguration, you should perform the operation outside of the peak hours. 
 
       - question: What types of updates are typically performed during a maintenance window? 
         answer: |
-          The maintenance event may contain updates for hardware, firmware, operating system, satellite software components, or the SQL database engine. They're typically combined into a single batch to minimize the incidence of maintenance events. In case of SQL Managed Instance, updates are combined in two batches, one focused on physical infrastructure, and another one focused on SQL engine and logical infrastructure.
+          The maintenance event may contain updates for hardware, firmware, operating system, satellite software components, or the SQL database engine. They're typically combined into a single batch to minimize the incidence of maintenance events. In case of SQL Managed Instance, updates are combined in two batches, one focused on physical infrastructure, and another one focused on SQL engine and logical infrastructure. For Azure SQL Managed Instance, the IP address of the SQL managed instance changes.
 
       - question: How frequent the updates are?
         answer: |
@@ -104,7 +104,7 @@ sections:
 
       - question: Can I configure a different maintenance window for each Azure SQL database in an elastic pool?
         answer: |
-         If the database is part of an elastic pool, the maintenance window configuration of the elastic pool will be applied. Single databases outside of an elastic pool can have their own maintenance window configuration.
+         If the database is part of an elastic pool, the maintenance window configuration of the elastic pool is applied. Single databases outside of an elastic pool can have their own maintenance window configuration.
 
       - question: What are supported options to configure a maintenance window for an existing Azure SQL Database or SQL managed instance?
         answer: |
@@ -120,7 +120,7 @@ sections:
 
       - question: I'm not able to set up advance notifications for planned maintenance, will I still see planned maintenance event in Service Health dashboard?
         answer: |
-          In case of [Azure SQL Database](sql-database-paas-overview.md), if advance notifications aren't configured, Service Health won't show the planned maintenance events. In case of [Azure SQL Managed Instance](../managed-instance/sql-managed-instance-paas-overview.md), you are able to see planned maintenance event in Service Health dashboard even if advance notifications aren't configured.
+          For [Azure SQL Database](sql-database-paas-overview.md), if advance notifications aren't configured, Service Health won't show the planned maintenance events. For [Azure SQL Managed Instance](../managed-instance/sql-managed-instance-paas-overview.md), planned maintenance events are visible in the Service Health dashboard, even if advance notifications aren't configured.
 
       - question: Does advance notification cover all maintenance events? 
         answer: | 
@@ -138,17 +138,17 @@ sections:
         answer: |
           Yes, you can [retrieve the list of impacted resources](advance-notifications.md#retrieve-the-list-of-impacted-resources) by using [Azure Resource Graph Explorer](/azure/governance/resource-graph/overview). You will receive an advance notification email that contains the notification ID and a link to the Azure Resource Graph Explorer. 
           
-      - question: The notification says "In Progress", but window has not started yet?
+      - question: The notification says "In Progress", but window hasn't started yet?
         answer: |
-          There is a period of 1 hour in which notifications are sent. This means that you can receive notification 25 to 24 hours before the event, 1 hour to 1 minute before the window opens, and 1 minute to 1 hour after the window is closed. Even though the notification title is "In Progress", the content of the notification contains the maintenance window start and end time and that is the moment when maintenance will begin and end.  
+          There's a period of 1 hour in which notifications are sent. This means that you can receive notification 25 to 24 hours before the event, 1 hour to 1 minute before the window opens, and 1 minute to 1 hour after the window is closed. Even though the notification title is "In Progress", the content of the notification contains the maintenance window start and end time and that is the moment when maintenance will begin and end.  
           
-      - question: Is there a scenario where I do not get notification about planned event?
+      - question: Is there a scenario where I don't get notification about planned event?
         answer: |
-          Yes, in case that you have created a new resource, executed scaling operation, or changed maintenance window, your database or instance can end up on the machine that is already scheduled for upgrade. In this case, you will be notified only when deployment window starts and ends. For all future deployments, you will get advance notification about planned events.
+          Yes, in case that you have created a new resource, executed scaling operation, or changed maintenance window, your database or instance can end up on the machine that is already scheduled for upgrade. In this case, you are notified only when deployment window starts and ends. For all future deployments, you will get advance notification about planned events.
           
       - question: Can I check if my instance has been upgraded in the last X days?
         answer: |
-          You can check this only if you have configured advanced notifications in the service health. You can use the [Azure Resource Graph Explorer](/azure/governance/resource-graph/overview) to [retrieve a list of maintenance events](maintenance-window.md#retrieving-list-of-maintenance-events), or use the [Service Health overview page](/azure/service-health/service-health-overview).
+          You can check this only if you have configured advanced notifications in the service health. You can use the [Azure Resource Graph Explorer](/azure/governance/resource-graph/overview) to [retrieve a list of maintenance events](maintenance-window.md#retrieve-list-of-maintenance-events), or use the [Service Health overview page](/azure/service-health/service-health-overview).
 
 additionalContent: |
  ## See Also