Merge branch 'main' of https://github.com/MicrosoftDocs/sql-docs-pr into julyrelease2022

Author: tdoshin

.openpublishing.redirection.azure-sql.json

@@ -455,6 +455,11 @@
       "redirect_url": "/azure/azure-sql/virtual-machines/windows/ways-to-connect-to-sql",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/azure-sql/database/service-tier-hyperscale-named-replicas-faq.yml",
+      "redirect_url": "/azure/azure-sql/database/service-tier-hyperscale-frequently-asked-questions-faq#read-scale-out-questions",
+      "redirect_document_id": true
+    },
     {
       "source_path_from_root": "/azure-sql/database/scripts/auditing-threat-detection-cli.md",
       "redirect_url": "/azure/defender-for-cloud/defender-for-sql-introduction",

azure-sql/database/monitor-tune-overview.md

@@ -70,7 +70,7 @@ In the Azure portal, Azure SQL Database and Azure SQL Managed Instance provide m
 
 ### Azure SQL Database and Azure SQL Managed Instance resource monitoring
 
-You can quickly monitor a variety of resource metrics in the Azure portal in the **Metrics** view. These metrics enable you to see if a database is reaching 100% of processor, memory, or IO resources. High DTU or processor percentage, as well as high IO percentage, indicates that your workload might need more CPU or IO resources. It might also indicate queries that need to be optimized.
+You can quickly monitor a variety of resource metrics in the Azure portal in the **Metrics** view. These metrics enable you to see if a database is approaching the limits of CPU, memory, IO, or storage resources. High DTU, CPU or IO utilization may indicate that your workload needs more resources. It might also indicate that queries need to be optimized. See [Microsoft.Sql/servers/databases](/azure/azure-monitor/essentials/metrics-supported#microsoftsqlserversdatabases), [Microsoft.Sql/servers/elasticPools](/azure/azure-monitor/essentials/metrics-supported#microsoftsqlserverselasticpools) and [Microsoft.Sql/managedInstances](/azure/azure-monitor/essentials/metrics-supported#microsoftsqlmanagedinstances) for supported metrics in Azure SQL Database and Azure SQL Managed Instance.
 
   ![Resource metrics](./media/monitor-tune-overview/resource-metrics.png)
 

azure-sql/database/service-tier-hyperscale-frequently-asked-questions-faq.yml

@@ -428,7 +428,7 @@ sections:
           You can connect to these additional read-only compute replicas by setting the `ApplicationIntent` property in your connection string to `ReadOnly`. Any connections marked with `ReadOnly` are automatically routed to one of the HA secondary replicas, if they were added for your database. For details, see [Use read-only replicas to offload read-only query workloads](read-scale-out.md).
           
       - question: |
-          How do I validate if I have successfully connected to secondary compute replica using SSMS or other client tools?
+          How do I validate if I have successfully connected to secondary compute replica using SQL Server Management Studio (SSMS) or other client tools?
         answer: |
           You can execute the following T-SQL query: `SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability')`. The result is `READ_ONLY` if you are connected to a read-only secondary replica, and `READ_WRITE` if you are connected to the primary replica. Note that the database context must be set to the name of your database, not to the `master` database.
           
@@ -455,13 +455,44 @@ sections:
       - question: |
           Can I add indexes and views on my secondary compute replicas?
         answer: |
-          No. Hyperscale databases have shared storage, meaning that all compute replicas see the same tables, indexes, and other database objects. If you want additional indexes optimized for reads on secondary, you must add them on the primary.
+          No. Hyperscale databases have shared storage, meaning that all compute replicas see the same tables, indexes, and other database objects. If you want additional indexes optimized for reads on secondary, you must add them on the primary. You can still create temporary tables (table names prefixed with # or ##) on each secondary replica to store temporary data. Temporary tables are read-write.
 
       - question: |
           How much delay is there going to be between the primary and secondary compute replicas?
         answer: |
           Data latency from the time a transaction is committed on the primary to the time it is readable on a secondary depends on current log generation rate, transaction size, load on the replica, and other factors. Typical data latency for small transactions is in tens of milliseconds, however there is no upper bound on data latency. Data on a given secondary replica is always transactionally consistent, thus larger transactions take longer to propagate. However, at a given point in time data latency and database state may be different for different secondary replicas. Workloads that need to read committed data immediately should run on the primary replica.
 
+      - question: |
+          Can a named replica be used as a failover target?
+        answer: |
+          No, named replicas cannot be used as failover targets for the primary replica. Add HA replicas for that purpose.
+
+      - question: |
+          How can I distribute a read-only workload across my named replicas?
+        answer: |
+          Since every named replica may have a different service level objective and thus be used for different use cases, there is no built-in way to direct read-only traffic sent to the primary to a set of named replicas. For example, you may have eight named replicas, and you may want to direct OLTP workload only to named replicas 1 to 4, while all the Power BI analytical workloads will use named replicas 5 and 6 and the data science workload will use replicas 7 and 8. Depending on which tool or programming language you use, strategies to distribute such workload may vary. One example of creating a workload routing solution to allow a REST backend to scale out is here: [OLTP scale-out sample](https://github.com/Azure-Samples/azure-sql-db-named-replica-oltp-scaleout).
+
+      - question: |
+          Can a named replica be in a region different from the region of the primary replica?
+        answer: |
+          No, as named replicas use the same page servers of the primary replica, they must be in the same region.
+
+      - question: |
+          Can a named replica impact availability or performance of the primary replica?
+        answer: |
+          A named replica cannot impact the availability of the primary replica. Named replicas, under normal circumstances, are unlikely to impact the primary's performance, but it can happen if there are intensive workloads running. Just like an HA replica, a named replica is kept in sync with the primary via the transaction log service. If a named replica, for any reason, is not able to consume the transaction log fast enough, it will start asking the primary replica to slow down (throttle) its log generation, so that it can catch up. While this behavior will not impact the primary's availability, it may impact performance of write workloads on the primary. To avoid this situation, make sure that your named replicas have enough resource headroom – mainly CPU – to process transaction log without delay. For example, if the primary is processing numerous data changes, it is recommended to have named replicas with at least the same Service Level Objective as the primary, to avoid saturating CPU on the replicas and thus forcing the primary to slow down.
+
+      - question: |
+          What happens to named replicas if the primary replica is unavailable, for example because of planned maintenance?
+        answer: |
+          Named replicas will still be available for read-only access, as usual.
+
+      - question: |
+          How can I improve availability of named replicas?
+        answer: |
+          By default, named replicas do not have any HA replicas of their own. A failover of a named replica requires creating a new replica first, which typically takes about 1-2 minutes. However, named replicas can also benefit from higher availability and shorter failovers provided by HA replicas. To add HA replicas for a named replica, you can use the parameter `ha-replicas` with [AZ CLI](/cli/azure/sql/db/replica#az_sql_db_replica_create), or the parameter `HighAvailabilityReplicaCount` with [PowerShell](/powershell/module/az.sql/set-azsqldatabase), or the `highAvailabilityReplicaCount` property with [REST API](/rest/api/sql/2021-02-01-preview/databases/create-or-update). The number of HA replicas can be set during the creation of a named replica and can be changed – only via AZ CLI, PowerShell or REST API – anytime after the named replica has been created. Pricing of HA replicas for named replicas is the same of HA replicas for regular Hyperscale databases.
+    
+
 additionalContent: |
 
   ## Next steps

azure-sql/database/service-tier-hyperscale-named-replicas-faq.yml

@@ -393,15 +393,14 @@
         href: database/hyperscale-architecture.md
       - name: Hyperscale backups 
         href: database/hyperscale-automated-backups-overview.md
-      - name: FAQ
-        displayName: Hyperscale frequently asked questions
-        href: database/service-tier-hyperscale-frequently-asked-questions-faq.yml
       - name: Replicas
         displayName: Hyperscale replicas
         href: database/service-tier-hyperscale-replicas.md
-      - name: Replicas FAQ
-        displayName: Hyperscale replicas frequently asked questions
-        href: database/service-tier-hyperscale-named-replicas-faq.yml
+      - name: FAQ
+        displayName: Hyperscale frequently asked questions
+        href: database/service-tier-hyperscale-frequently-asked-questions-faq.yml
+
+
 
     - name: Purchasing models
       items: 

azure-sql/toc.yml

@@ -144,20 +144,20 @@ For more information on the Setspn tool, required permissions and examples on ho
 The following example illustrates the syntax used to manually register an SPN for a TCP/IP connection using a domain user account:  
 
 ```
-setspn -A MSSQLSvc/myhost.redmond.microsoft.com:1433 redmond\accountname  
+setspn -S MSSQLSvc/myhost.redmond.microsoft.com:1433 redmond\accountname  
 ```
 
 > [!NOTE]
 > If an SPN already exists, it must be deleted before it can be reregistered. You do this by using the `setspn` command together with the `-D` switch. The following examples illustrate how to manually register a new instance-based SPN. For a default instance using a domain user account, use:  
 
 ```  
-setspn -A MSSQLSvc/myhost.redmond.microsoft.com redmond\accountname  
+setspn -S MSSQLSvc/myhost.redmond.microsoft.com redmond\accountname  
 ```  
 
 For a named instance, use:  
 
 ```  
-setspn -A MSSQLSvc/myhost.redmond.microsoft.com:instancename redmond\accountname  
+setspn -S MSSQLSvc/myhost.redmond.microsoft.com:instancename redmond\accountname  
 ```  
 
 ##  <a name="Client"></a> Client Connections