Merge pull request #23230 from MicrosoftDocs/main

7/15 AM Publish

Author: huypub

azure-sql/database/temporal-tables-retention-policy.md

@@ -97,7 +97,7 @@ LEFT JOIN sys.tables T2
 ON T1.history_table_id = T2.object_id WHERE T1.temporal_type = 2
 ```
 
-## How ages rows are deleted
+## How aged rows are deleted
 
 The cleanup process depends on the index layout of the history table. It is important to notice that *only history tables with a clustered index (B-tree or columnstore) can have finite retention policy configured*. A background task is created to perform aged data cleanup for all temporal tables with finite retention period.
 Cleanup logic for the rowstore (B-tree) clustered index deletes aged row in smaller chunks (up to 10K) minimizing pressure on database log and IO subsystem. Although cleanup logic utilizes required B-tree index, order of deletions for the rows older than retention period cannot be firmly guaranteed. Hence, *do not take any dependency on the cleanup order in your applications*.

azure-sql/includes/auto-failover-group-terminology.md

@@ -30,10 +30,9 @@ ms.date: 03/01/2022
   - Relocate the databases to a different region
   - Return the databases to the primary region after the outage has been mitigated (failback)
 
-  >
   > [!NOTE]
-  > During planned failovers or disaster recovery drills, the primary databases and the target secondary geo-replica databases should have matching service tiers. If a secondary database has lower memory than the primary database, you may encounter out-of-memory issues, preventing full recovery after failover.  If this happens, the affected geo-secondary database may be put into a limited read-only mode called **checkpoint-only mode**. To avoid this, upgrade the service tier of the secondary database to match the primary database during the planned failover, or drill. Service tier upgrades can be size-of-data operations, and take a while to finish. 
-  > 
+  > If a database contains in-memory OLTP objects, the primary databases and the target secondary geo-replica databases should have matching service tiers, as in-memory OLTP objects are always hydrated in memory. A lower service tier on the target geo-replica database may result in out-of-memory issues. If this happens, the affected geo-secondary database replica may be put into a limited read-only mode called **in-memory OLTP checkpoint-only** mode. Read-only table queries are allowed, but read-only in-memory OLTP table queries are disallowed on the affected geo-secondary database replica. Planned failover is blocked if all replicas in the geo-secondary database are in checkpoint only mode. Unplanned failover may fail due to out-of-memory issues. To avoid this, upgrade the service tier of the secondary database to match the primary database during the planned failover, or drill. Service tier upgrades can be size-of-data operations, and may take a while to finish.
+
 - **Unplanned failover**
 
   Unplanned or forced failover immediately switches the secondary to the primary role without waiting for recent changes to propagate from the primary. This operation may result in data loss. Unplanned failover is used as a recovery method during outages when the primary is not accessible. When the outage is mitigated, the old primary will automatically reconnect and become a new secondary. A planned failover may be executed to fail back, returning the replicas to their original primary and secondary roles.

azure-sql/managed-instance/log-replay-service-migrate.md

@@ -9,7 +9,7 @@ ms.topic: how-to
 author: danimir
 ms.author: danil
 ms.reviewer: mathoma
-ms.date: 07/14/2022
+ms.date: 07/15/2022
 ---
 
 # Migrate databases from SQL Server to SQL Managed Instance by using Log Replay Service (Preview)
@@ -84,6 +84,14 @@ Continuous mode migration needs to be used when you don't have the entire backup
 | **2.2. Stop the operation if required (optional)**. | If you need to stop the migration process, use PowerShell ([stop-azsqlinstancedatabaselogreplay](/powershell/module/az.sql/stop-azsqlinstancedatabaselogreplay)) or the Azure CLI ([az_sql_midb_log_replay_stop](/cli/azure/sql/midb/log-replay#az-sql-midb-log-replay-stop)). <br /><br /> Stopping the operation deletes the database that you're restoring to SQL Managed Instance. After you stop an operation, you can't resume LRS for a database. You need to restart the migration process from the beginning. |
 | **3. Cut over to the cloud when you're ready**. | If LRS was started in autocomplete mode, the migration will automatically complete once the specified last backup file has been restored. <br /><br />  If LRS was started in continuous mode, stop the application and workload. Take the last log-tail backup and upload it to Azure Blob Storage. Ensure that the last log-tail backup has been restored on managed instance. Complete the cutover by initiating an LRS `complete` operation with PowerShell ([complete-azsqlinstancedatabaselogreplay](/powershell/module/az.sql/complete-azsqlinstancedatabaselogreplay)) or the Azure CLI [az_sql_midb_log_replay_complete](/cli/azure/sql/midb/log-replay#az-sql-midb-log-replay-complete). This operation stops LRS and brings the database online for read and write workloads on SQL Managed Instance. <br /><br /> Repoint the application connection string from SQL Server to SQL Managed Instance. You'll need to orchestrate this step yourself, either through a manual connection string change in your application, or automatically (for example, if your application can read the connection string from a property, or a database). |
 
+### Migrating large databases
+
+If migrating large databases of several terrabytes in size, consider the following:
+- Single LRS job can run for a maximum of 30 days. On expiry of this timeframe, the job will be automatically canceled.
+- In the case of long-running jobs, system updates will interrupt and prolong migration jobs. It's highly recommended to use [maintenance window]( ../database/maintenance-window.md) to schedule planned system updates. Plan your migration around the scheduled maintenance window.
+- Migration jobs interrupted by system updates will be automatically suspended and resumed for General Purpose managed instances, and restarted for Business Critical managed instances. These updates will affect the timeframe of your migration.
+- To increase the upload speed of your SQL Server backup files to Azure Blob Storage, provided there's a sufficient network bandwidth from your infrastructure, consider using parallelization with multiple threads.
+
 ## Getting started
 
 Consider the requirements in this section to get started with using LRS to migrate. 
@@ -128,15 +136,16 @@ We recommend the following best practices:
 - Split full and differential backups into multiple files, instead of using a single file.
 - Enable backup compression to help the network transfer speeds.
 - Use Cloud Shell to run PowerShell or CLI scripts, because it will always be updated to the latest cmdlets released.
-- Configure [maintenance window](../database/maintenance-window.md) to allow scheduling of system updates at a specific day/time. This configuration will help achieve a more predictable time of database migrations.
+- Configure [maintenance window](../database/maintenance-window.md) to allow scheduling of system updates at a specific day/time. This configuration will help achieve a more predictable time of database migrations, as impactful system upgrades interrupt migration in progress.
+- Plan to complete a single LRS migration job within a maximum of 30 days. On expiry of this timeframe, the LRS job will be automatically canceled.
 
 > [!IMPORTANT]
 > - You can't use databases being restored through LRS until the migration process completes. 
 > - LRS doesn't support read-only access to databases during the migration.
 > - After the migration completes, the migration process is finalized and can't be resumed with additional differential backups.
 
 > [!TIP]
-> System updates on managed instance will take precedence over database migrations in progress. All pending LRS migrations in case of a system update on Managed Instance will be suspended and resumed once the update has been applied. This system behavior might prolong migration time, especially in cases of very large databases. To achieve a predictable time of database migrations, consider configuring [maintenance window](../database/maintenance-window.md) allowing scheduling of system updates at a specific day/time, and consider running and completing migration jobs outside of the scheduled maintenance window day/time.
+> System updates on managed instance will take precedence over database migrations in progress. All pending LRS migrations in case of a system update on Managed Instance will be suspended and resumed once the update has been applied. This system behavior might prolong migration time, especially in cases of large databases. To achieve a predictable time of database migrations, consider configuring [maintenance window](../database/maintenance-window.md) allowing scheduling of system updates at a specific day/time, and consider running and completing migration jobs outside of the scheduled maintenance window day/time.
 > 
 
 ## Steps to migrate
@@ -349,6 +358,8 @@ When you use autocomplete mode, the migration completes automatically when the l
 
 When you use continuous mode, the service continuously scans Azure Blob Storage folder and restores any new backup files that keep getting added while migration is in progress. The migration completes only after the manual cutover has been requested. Continuous mode migration needs to be used when you don't have the entire backup chain in advance, and when you plan to add new backup files once the migration is in progress. This mode is recommended for active workloads for which data catch-up is required.
 
+Plan to complete a single LRS migration job within a maximum of 30 days. On expiry of this timeframe, the LRS job will be automatically canceled.
+
 > [!NOTE]
 > When migrating multiple databases, LRS must be started separately for each database pointing to the full URI path of Azure Blob storage container and the individual database folder.
 > 
@@ -498,6 +509,7 @@ Consider the following limitations of LRS:
 - If using autocomplete mode, the entire backup chain needs to be available in advance on Azure Blob Storage. It isn't possible to add new backup files in autocomplete mode. Use continuous mode if you need to add new backup files while migration is in progress.
 - LRS must be started separately for each database pointing to the full URI path containing an individual database folder. 
 - LRS can support up to 100 simultaneous restore processes per single managed instance.
+- Single LRS job can run for the maximum of 30 days, after which it will be automatically canceled.
 
 > [!TIP]
 > If you require database to be R/O accessible during the migration, a much longer timeframe to perform the migration, and the best possible minimum downtime, consider the [link feature for Managed Instance](managed-instance-link-feature-overview.md) as a recommended migration solution in these cases.

azure-sql/managed-instance/resource-limits.md

@@ -75,6 +75,7 @@ Support for the premium-series hardware (public preview) is currently available
 | North Central US | Yes | Yes | 
 | North Europe | Yes | Yes | 
 | Norway East | Yes | | 
+| South Africa North | Yes | | 
 | South Africa West | Yes | | 
 | South Central US | Yes | Yes | 
 | Southeast Asia | Yes |  | 

azure-sql/virtual-machines/windows/automated-backup-sql-2014.md

@@ -23,7 +23,7 @@ ms.custom: devx-track-azurepowershell
 
 > [!div class="op_single_selector"]
 > * [SQL Server 2014](automated-backup-sql-2014.md)
-> * [SQL Server 2016/2017](automated-backup.md)
+> * [SQL Server 2016 and later](automated-backup.md)
 
 Automated Backup automatically configures [Managed Backup to Microsoft Azure](/sql/relational-databases/backup-restore/sql-server-managed-backup-to-microsoft-azure) for all existing and new databases on an Azure VM running SQL Server 2014 Standard or Enterprise. This enables you to configure regular database backups that utilize durable Azure Blob storage. Automated Backup depends on the [SQL Server infrastructure as a service (IaaS) Agent Extension](sql-server-iaas-agent-extension-automate-management.md).
 
@@ -253,4 +253,4 @@ You can find additional backup and restore guidance for SQL Server on Azure VMs
 
 For information about other available automation tasks, see [SQL Server IaaS Agent Extension](sql-server-iaas-agent-extension-automate-management.md).
 
-For more information about running SQL Server on Azure VMs, see [SQL Server on Azure virtual machines overview](sql-server-on-azure-vm-iaas-what-is-overview.md).
+For more information about running SQL Server on Azure VMs, see [SQL Server on Azure virtual machines overview](sql-server-on-azure-vm-iaas-what-is-overview.md).

azure-sql/virtual-machines/windows/automated-backup.md

@@ -23,7 +23,7 @@ ms.custom: devx-track-azurepowershell
 
 > [!div class="op_single_selector"]
 > * [SQL Server 2014](automated-backup-sql-2014.md)
-> * [SQL Server 2016 +](automated-backup.md)
+> * [SQL Server 2016 and later](automated-backup.md)
 
 Automated Backup v2 automatically configures [Managed Backup to Microsoft Azure](/sql/relational-databases/backup-restore/sql-server-managed-backup-to-microsoft-azure) for all existing and new databases on an Azure VM running SQL Server 2016 or later Standard, Enterprise, or Developer editions. This enables you to configure regular database backups that utilize durable Azure blob storage. Automated Backup v2 depends on the [SQL Server infrastructure as a service (IaaS) Agent Extension](sql-server-iaas-agent-extension-automate-management.md).
 

azure-sql/virtual-machines/windows/backup-restore.md

@@ -52,7 +52,7 @@ To restore a database, you must locate the required backup file(s) in the storag
 
 For more information on how to configure Automated Backup for SQL VMs, see one of the following articles:
 
-- **SQL Server 2016/2017**: [Automated Backup v2 for Azure Virtual Machines](automated-backup.md)
+- **SQL Server 2016 and later**: [Automated Backup v2 for Azure Virtual Machines](automated-backup.md)
 - **SQL Server 2014**: [Automated Backup for SQL Server 2014 Virtual Machines](automated-backup-sql-2014.md)
 
 ## <a id="azbackup"></a> Azure Backup for SQL VMs
@@ -101,8 +101,8 @@ Beginning with SQL Server 2012 SP1 CU2, you can back up and restore directly to
 
 For more information, see the one of the following articles based on your version of SQL Server:
 
-- **SQL Server 2016/2017**: [SQL Server Backup to URL](/sql/relational-databases/backup-restore/sql-server-backup-and-restore-with-microsoft-azure-blob-storage-service)
-- **SQL Server 2014**: [SQL Server 2014 Backup to URL](/sql/relational-databases/backup-restore/sql-server-backup-and-restore-with-microsoft-azure-blob-storage-service?viewFallbackFrom=sql-server-2014)
+- **SQL Server 2016 and later**: [SQL Server Backup to URL](/sql/relational-databases/backup-restore/sql-server-backup-and-restore-with-microsoft-azure-blob-storage-service)
+- **SQL Server 2014**: [SQL Server 2014 Backup to URL](/previous-versions/sql/2014/relational-databases/backup-restore/sql-server-backup-to-url?view=sql-server-2014)
 - **SQL Server 2012**: [SQL Server 2012 Backup to URL](/previous-versions/sql/sql-server-2012/jj919148(v=sql.110))
 
 ### Managed Backup
@@ -114,7 +114,7 @@ Beginning in SQL Server 2016, Managed Backup got additional options for scheduli
 For more information, see one of the following articles based on your version of SQL Server:
 
 - [Managed Backup to Microsoft Azure for SQL Server 2016 and later](/sql/relational-databases/backup-restore/sql-server-managed-backup-to-microsoft-azure)
-- [Managed Backup to Microsoft Azure for SQL Server 2014](/sql/relational-databases/backup-restore/sql-server-managed-backup-to-microsoft-azure?viewFallbackFrom=sql-server-2014)
+- [Managed Backup to Microsoft Azure for SQL Server 2014](/previous-versions/sql/2014/relational-databases/backup-restore/sql-server-managed-backup-to-microsoft-azure?view=sql-server-2014)
 
 ## Decision matrix
 
@@ -132,7 +132,7 @@ The following table summarizes the capabilities of each backup and restore optio
 | Long-term backup retention policy (months, years) |   | ![Green checkmark.](./media/backup-restore/yes.png) |   |
 | Built-in support for SQL Server Always On |   | ![Green checkmark.](./media/backup-restore/yes.png) |   |
 | Backup to Azure Storage account(s) | ![Green checkmark.](./media/backup-restore/yes.png)(automatic) | ![Green checkmark.](./media/backup-restore/yes.png)(automatic) | ![Green checkmark.](./media/backup-restore/yes.png)(customer managed) |
-| Management of storage and backup files | | ![Green checkmark.](./media/backup-restore/yes.png) |  |
+| Management of storage and backup files | | ![Green checkmark.](./media/backup-restore/yes.png) |   |
 | Backup to attached disks on the VM |   |   | ![Green checkmark.](./media/backup-restore/yes.png) |
 | Central customizable backup reports |   | ![Green checkmark.](./media/backup-restore/yes.png) |   |
 | Consolidated email alerts for failures |   | ![Green checkmark.](./media/backup-restore/yes.png) |   |