Merge pull request #260130 from MicrosoftDocs/main

12/4 11:00 AM IST Publish

Author: Saisang

articles/machine-learning/how-to-autoscale-endpoints.md

@@ -256,15 +256,15 @@ rule_scale_in = ScaleRule(
         metric_resource_uri = deployment.id, 
         time_grain = datetime.timedelta(minutes = 1),
         statistic = "Average",
-        operator = "GreaterThan", 
+        operator = "less Than", 
         time_aggregation = "Last",
         time_window = datetime.timedelta(minutes = 5), 
-        threshold = 70
+        threshold = 30
     ), 
     scale_action = ScaleAction(
         direction = "Increase", 
         type = "ChangeCount", 
-        value = 2, 
+        value = 1, 
         cooldown = datetime.timedelta(hours = 1)
     )
 )
@@ -495,4 +495,4 @@ To learn more about autoscale with Azure Monitor, see the following articles:
 - [Understand autoscale settings](../azure-monitor/autoscale/autoscale-understanding-settings.md)
 - [Overview of common autoscale patterns](../azure-monitor/autoscale/autoscale-common-scale-patterns.md)
 - [Best practices for autoscale](../azure-monitor/autoscale/autoscale-best-practices.md)
-- [Troubleshooting Azure autoscale](../azure-monitor/autoscale/autoscale-troubleshoot.md)
+- [Troubleshooting Azure autoscale](../azure-monitor/autoscale/autoscale-troubleshoot.md)

articles/synapse-analytics/sql-data-warehouse/maintenance-scheduling.md

@@ -100,6 +100,40 @@ During preview, some regions might not yet support the full set of available **D
 
    ![Message about region availability](./media/maintenance-scheduling/maintenance-not-active-toast.png)
 
+## Frequently asked questions
+
+### What is the expected frequency for the maintenance.
+
+Maintenance can happen more than once per month, because maintenance can include OS updates, security patches and drivers, internal Azure infrastructure updates, and DW patches and updates. Every customer has a twice-weekly schedule of maintenance cycles between through Saturday–Sunday, and Tuesday–Thursday.
+
+### What changes have been made after the maintenance is completed, even though my dedicated SQL pool version remains the same?
+
+After a maintenance update is completed, the SQL pool version may remain unchanged. This is because maintenance can include OS updates, security patches and drivers, internal Azure infrastructure updates, and DW patches and updates. Only if a Synapse DW patch or update is included in the maintenance will you see a change to the SQL Dedicated Pool version.
+
+### Is it possible to upgrade the version of my dedicated SQL pool on demand?
+
+- No, scheduled maintenance handles the management of dedicated SQL pools. However, you might have some options to trigger the maintenance once the cycle started, depending on your situation. Verify [Skip or change maintenance schedule](#skip-or-change-maintenance-schedule)
+- It's important to keep in mind that the dedicated SQL Pool is a Platform as a Service (PaaS) feature. This implies that Microsoft Azure handles all kinds of tasks related to the service, such as infrastructure, maintenance, updates, and scalability. Scheduled maintenance can be tracked by setting an alert/notification so you stay informed of impending maintenance activity.
+
+### What changes, if any, should be made before or after the dedicated SQL pool maintenance is completed?
+
+- During maintenance, your service will be briefly taken offline, similar to what occurs during a pause, resume, or scale operation. Typically, the overall maintenance operation is completed in well under 30 minutes. However, it could take a little longer, depending on database activity during the maintenance window. We recommend pausing ETL, table updates, and especially transactional operations to avoid longer than normal maintenance. For example:
+- If your instance is extremely busy during the planned window, especially with frequent update and delete activity, the maintenance operation might take longer than the normal time. To reduce the chance of extended maintenance activity, we recommend limiting activity to mostly read-only queries against the database if possible, and especially avoiding long-running transactional queries (see the next item).
+- If there are active transactions when the maintenance begins, they are canceled and rolled back, potentially causing delays in restoring the online service. To prevent this situation, we recommend ensuring that there are no long-running transactions active at the start of your maintenance window.
+
+### We were notified about an upcoming dedicated SQL pool scheduled maintenance with tracking ID 0000-000, but it was subsequently canceled or rescheduled. What prompted the cancellation or rescheduling of the maintenance?
+
+There are various factors that could lead to the cancellation of scheduled maintenance, including actions such as:
+- Pausing or scaling operations after receiving a pending maintenance notification while the cycle is initiated.
+- If you are targeting different Service Level Objectives (SLOs) during the maintenance cycle, such as transitioning from any SLO higher than DW400c and then scaling back to an SLO lower or equal to DW400c, or vice versa, a cancellation could occur. This is because maintenance windows are not applicable for DW400c or lower performance levels, and they can undergo maintenance at any time.
+- Internal infrastructure factors, such as actual changes to planned maintenance scheduling by the release team.
+- Maintenance may be canceled or rescheduled if internal monitoring detects that maintenance is taking longer than expected. Maintenance must be completed within the Service Level Agreements (SLAs) defined by customer maintenance window settings.
+
+### Are there any best practices that I need to consider for our workload during the maintenance window?
+
+- Yes, if possible, pause all transactional and ETL workloads during the planned maintenance interval to avoid errors or delays in restoring the online service. Long-running transactional operations should be completed prior to an upcoming maintenance period.
+- For workloads to be resilient to interruptions caused by maintenance operations, use retry logic for both the connection and the command (query) levels, applying longer retry intervals and/or more retry attempts to withstand an extended connection loss that can extend up to or greater than 30 minutes in some cases.
+
 ## Next steps
 
 - [Learn more](../../azure-monitor/alerts/alerts-metric.md?toc=/azure/synapse-analytics/sql-data-warehouse/toc.json&bc=/azure/synapse-analytics/sql-data-warehouse/breadcrumb/toc.json) about creating, viewing, and managing alerts by using Azure Monitor.