Merging changes synced from https://github.com/MicrosoftDocs/sql-docs-pr (branch live)

Author: Learn Build Service GitHub App

azure-sql/database/features-comparison.md

@@ -72,7 +72,7 @@ This article lists the currently known issues with [Azure SQL Managed Instance](
 
 Long-term backups can be listed and managed on Azure portal page for an Azure SQL Managed Instance on _Backups_ tab. The page lists active or deleted databases, basic information about their long-term backups, and link for managing backups. Clicking on the _Manage_ link opens a new side blade with list of backups. Due to an issue with the filtering logic, the list shows backups for both active database and deleted databases with the same name. This requires a special attention when selecting backups for deletion, to avoid deleting backups for a wrong database.
 
-**Workaround**: Use displayed _Backup time (UTC)_ information in the list to differentiate backups belonging to databases with the same name that existed on the instance at different periods. Alternatively, use PowerShell commands [Get-AzSqlInstanceDatabaseLongTermRetentionBackup](https://learn.microsoft.com/powershell/module/az.sql/get-azsqlinstancedatabaselongtermretentionbackup) and [Remove-AzSqlInstanceDatabaseLongTermRetentionBackup](https://learn.microsoft.com/powershell/module/az.sql/remove-azsqlinstancedatabaselongtermretentionbackup), or CLI commands [az sql midb ltr-backup list](https://learn.microsoft.com/cli/azure/sql/midb/ltr-backup?view=azure-cli-latest#az-sql-midb-ltr-backup-list) and [az sql midb ltr-backup delete](https://learn.microsoft.com/cli/azure/sql/midb/ltr-backup?view=azure-cli-latest#az-sql-midb-ltr-backup-delete) to manage long-term backups using _DatabaseState_ parameter and _DatabaseDeletionTime_ return value to filter backups for a database.
+**Workaround**: Use displayed _Backup time (UTC)_ information in the list to differentiate backups belonging to databases with the same name that existed on the instance at different periods. Alternatively, use PowerShell commands [Get-AzSqlInstanceDatabaseLongTermRetentionBackup](/powershell/module/az.sql/get-azsqlinstancedatabaselongtermretentionbackup) and [Remove-AzSqlInstanceDatabaseLongTermRetentionBackup](/powershell/module/az.sql/remove-azsqlinstancedatabaselongtermretentionbackup), or CLI commands [az sql midb ltr-backup list](/cli/azure/sql/midb/ltr-backup?view=azure-cli-latest#az-sql-midb-ltr-backup-list) and [az sql midb ltr-backup delete](/cli/azure/sql/midb/ltr-backup?view=azure-cli-latest#az-sql-midb-ltr-backup-delete) to manage long-term backups using _DatabaseState_ parameter and _DatabaseDeletionTime_ return value to filter backups for a database.
 
 ### The event_file target of the system_health event session is not accessible
 

azure-sql/database/transparent-data-encryption-byok-overview.md

@@ -12,6 +12,7 @@ ms.custom: sqldbrb=1, build-2023, build-2023-dataai, ignite-2023
 ---
 
 # What is Azure SQL Managed Instance?
+
 [!INCLUDE[appliesto-sqlmi](../includes/appliesto-sqlmi.md)]
 
 This article provides an overview of Azure SQL Managed Instance, a fully managed platform as a service (PaaS) database engine that handles most database management functions such as upgrading, patching, backups, and monitoring without user involvement.

azure-sql/managed-instance/doc-changes-updates-known-issues.md

@@ -382,6 +382,8 @@
       href: database/logical-servers.md
     - name: Serverless
       href: database/serverless-tier-overview.md
+    - name: T-SQL differences from SQL Server
+      href: database/transact-sql-tsql-differences-sql-server.md
     - name: In-memory OLTP in Azure SQL Database
       items:
       - name: In-memory OLTP overview
@@ -630,8 +632,6 @@
   - name: How to
     href: database/how-to-content-reference-guide.md
     items:
-    - name: T-SQL differences
-      href: database/transact-sql-tsql-differences-sql-server.md
     - name: Plan and manage costs 
       href: database/cost-management.md      
     - name: Connect and query

azure-sql/managed-instance/sql-managed-instance-paas-overview.md

@@ -39,6 +39,7 @@ To use Automated Backup, review the following prerequisites:
 
 - Target _user_ databases must use the full recovery model. System databases don't have to use the full recovery model. However, if you require log backups to be taken for `model` or `msdb`, you must use the full recovery model. For more information about the impact of the full recovery model on backups, see [Backup under the full recovery model](/previous-versions/sql/sql-server-2008-r2/ms190217(v=sql.105)). 
 - The SQL Server VM has been registered with the [SQL IaaS Agent extension](sql-server-iaas-agent-extension-automate-management.md) and the **Automated Backup** feature is enabled. Since Automated Backup relies on the extension, Automated Backup is only supported on target databases from the default instance, or a single named instance. If there's no default instance, and multiple named instances, the SQL IaaS Agent extension fails and Automated Backup won't work. 
+- If you're running automated backups on a secondary Always On availability group replica, the replica must be **Readable** for the backups to succeed. 
 
 ## Settings
 
@@ -49,7 +50,7 @@ The following table describes the options that can be configured for Automated B
 | Setting | Range (Default) | Description |
 | --- | --- | --- |
 | **Automated Backup** | Enable/Disable (Disabled) | Enables or disables Automated Backup for an Azure VM running SQL Server 2016 or later Developer, Standard, or Enterprise. |
-| **Retention Period** | 1-90 days (90 days) | The number of days to retain backups. |
+| **Retention Period** | 1-90 days (90 days) | The number of days the service retains backup metadata in `msdb`. After the retention period expires for a backup, the metadata is deleted from `msdb`, but files aren't deleted from the storage container. You can use a [lifecycle management policy](/azure/storage/blobs/lifecycle-management-policy-configure) for your storage account to balance backup retention with cost management according to your business needs.    |
 | **Storage Account** | Azure storage account | An Azure storage account to use for storing Automated Backup files in blob storage. A container is created at this location to store all backup files. The backup file naming convention includes the date, time, and database GUID. |
 | **Encryption** |Enable/Disable (Disabled) | Enables or disables backup encryption. When backup encryption is enabled, the certificates used to restore the backup are located in the specified storage account in the same `automaticbackup` container using the same naming convention. If the password changes, a new certificate is generated with that password, but the old certificate remains to restore prior backups. |
 | **Password** |Password text | A password for encryption keys. This password is only required if encryption is enabled. In order to restore an encrypted backup, you must have the correct password and related certificate that was used at the time the backup was taken. |
@@ -440,6 +441,7 @@ The following table lists possible errors and solutions when working with Automa
 | **Managed backup fails intermittently/Error:Execution timeout Expired** | This is a known issue fixed in [CU18](https://support.microsoft.com/topic/kb5017593-cumulative-update-18-for-sql-server-2019-5fa00c36-edeb-446c-94e3-c4882b7526bc#bkmk_14913295) for SQL Server 2019 and [KB4040376] for SQL Server 2014-2017.|
 | **Error: The remote server returned an error: (403) Forbidden**  | Repair the [SQL IaaS Agent extension](sql-agent-extension-troubleshoot-known-issues.md#repair-extension). | 
 | **Error 3202: Write on Storage account failed 13 (The data is invalid)** | Remove the immutable blob policy on the storage container and make sure the storage account is using, at minimum, TLS 1.0.  | 
+| **Error 3063: Write to backup block blob device. Device has reached its limit of allowed blocks.** | This can happen if you're running automated backups from a secondary Always On availability group replica that has the `Readable` configuration set to `NO`. For automated backups to work on a secondary replica, the replica must be readable. | 
 
 
 

azure-sql/toc.yml

@@ -34,7 +34,7 @@ The following sections describe each option in more detail. The final section of
 
 Automated Backup provides an automatic backup service for SQL Server Standard and Enterprise editions running on a Windows VM in Azure. This service is provided by the [SQL Server IaaS Agent Extension](sql-server-iaas-agent-extension-automate-management.md), which is automatically installed on SQL Server Windows virtual machine images in the Azure portal.
 
-All databases are backed up to an Azure storage account that you configure. Backups can be encrypted and retained for up to 90 days.
+All databases are backed up to an Azure storage account that you configure. Backups can be encrypted and the metadata is retained in `msdb` for up to 90 days, though the service doesn't automatically delete backups past their retention date. You can use a [lifecycle management policy](/azure/storage/blobs/lifecycle-management-policy-configure) for your storage account to balance backup retention with cost management according to your business needs.
 
 SQL Server 2016 and higher VMs offer more customization options with Automated Backup. These improvements include:
 

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

@@ -27,7 +27,7 @@ helpviewer_keywords:
  You must be connected to the server instance that hosts the primary replica in SSMS. The secondary replica must be healthy, which includes being connected to the current primary replica and in the secondary role.
 
    > [!NOTE]
-   > The secondary replica does not need to be readable to offload backups to it. Backups will still succeed on the secondary replica even if `Readable Secondary` is set to `no`. 
+   > The secondary replica does not need to be readable to offload backups to it. Backups will still succeed on the secondary replica even if `Readable Secondary` is set to `no`, with the exception of [managed backups](../../../relational-databases/backup-restore/sql-server-managed-backup-to-microsoft-azure.md#Prereqs). 
   
 
 ##  <a name="Permissions"></a> Permissions  

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

@@ -146,7 +146,7 @@ sudo pcs property set cluster-recheck-interval=2min
 
 If you already have an availability group resource managed by a Pacemaker cluster, Pacemaker package 1.1.18-11.el7 introduced a behavior change for the `start-failure-is-fatal` cluster setting when its value is `false`. This change affects the failover workflow. If a primary replica experiences an outage, the cluster is expected to fail over to one of the available secondary replicas. Instead, users notice that the cluster keeps trying to start the failed primary replica. If that primary never comes online (because of a permanent outage), the cluster never fails over to another available secondary replica. Because of this change, a previously recommended configuration to set `start-failure-is-fatal` is no longer valid, and the setting needs to be reverted back to its default value of `true`.
 
-Additionally, the AG resource needs to be updated to include the `failover-timeout` property.
+Additionally, the AG resource needs to be updated to include the `failure-timeout` property.
 
 To update the property value to `true` run:
 
@@ -438,7 +438,7 @@ crm configure property cluster-recheck-interval=2min
 
 If you already have an availability group resource managed by a Pacemaker cluster, Pacemaker package 1.1.18-11.el7 introduced a behavior change for the `start-failure-is-fatal` cluster setting when its value is `false`. This change affects the failover workflow. If a primary replica experiences an outage, the cluster is expected to fail over to one of the available secondary replicas. Instead, users notice that the cluster keeps trying to start the failed primary replica. If that primary never comes online (because of a permanent outage), the cluster never fails over to another available secondary replica. Because of this change, a previously recommended configuration to set `start-failure-is-fatal` is no longer valid, and the setting needs to be reverted back to its default value of `true`.
 
-Additionally, the AG resource needs to be updated to include the `failover-timeout` property.
+Additionally, the AG resource needs to be updated to include the `failure-timeout` property.
 
 To update the property value to `true` run:
 
@@ -468,7 +468,7 @@ Node level fencing ensures that a node doesn't run any resources. This is done b
 
 For more information, see:
 
-- [Pacemaker Clusters from Scratch](https://clusterlabs.org/pacemaker/doc/deprecated/en-US/Pacemaker/1.1/html/Clusters_from_Scratch)
+- [Pacemaker Clusters from Scratch](https://clusterlabs.org/pacemaker/doc/deprecated/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/index.html)
 - [Fencing and STONITH](https://clusterlabs.org/pacemaker/doc/crm_fencing.html)
 - [SUSE HA documentation: Fencing and STONITH](https://documentation.suse.com/sle-ha/15-SP1/)
 
@@ -739,7 +739,7 @@ Resource level fencing ensures that no data corruption occurs if there's an outa
 
 Node level fencing ensures that a node doesn't run any resources. This is done by resetting the node, and the Pacemaker implementation is called STONITH. Pacemaker supports a great variety of fencing devices, for example, an uninterruptible power supply or management interface cards for servers.
 
-For more information, see [Pacemaker Clusters from Scratch](https://clusterlabs.org/pacemaker/doc/deprecated/en-US/Pacemaker/1.1/html/Clusters_from_Scratch) and [Fencing and Stonith](https://clusterlabs.org/pacemaker/doc/crm_fencing.html).
+For more information, see [Pacemaker Clusters from Scratch](https://clusterlabs.org/pacemaker/doc/deprecated/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/index.html) and [Fencing and Stonith](https://clusterlabs.org/pacemaker/doc/crm_fencing.html).
 
 Because the node level fencing configuration depends heavily on your environment, we disable it for this tutorial (it can be configured at a later time). Run the following script on the primary node:
 
@@ -761,7 +761,7 @@ sudo crm configure property cluster-recheck-interval=2min
 
 If you already have an availability group resource managed by a Pacemaker cluster, Pacemaker package 1.1.18-11.el7 introduced a behavior change for the `start-failure-is-fatal` cluster setting when its value is `false`. This change affects the failover workflow. If a primary replica experiences an outage, the cluster is expected to fail over to one of the available secondary replicas. Instead, users notice that the cluster keeps trying to start the failed primary replica. If that primary never comes online (because of a permanent outage), the cluster never fails over to another available secondary replica. Because of this change, a previously recommended configuration to set `start-failure-is-fatal` is no longer valid, and the setting needs to be reverted back to its default value of `true`.
 
-Additionally, the AG resource needs to be updated to include the `failover-timeout` property.
+Additionally, the AG resource needs to be updated to include the `failure-timeout` property.
 
 To update the property value to `true` run:
 

docs/database-engine/availability-groups/windows/configure-backup-on-availability-replicas-sql-server.md

@@ -582,7 +582,7 @@ The AG resource you created is a type of resource called a *clone*. The AG resou
    On RHEL 7.7 and Ubuntu 18.04, and later versions, you might encounter a warning with the use of `--master`, or an error like `sqlag_monitor_0 on ag1 'not configured' (6): call=6, status=complete, exitreason='Resource must be configured with notify=true'`. To avoid this situation, use:
 
    ```bash
-   sudo pcs resource create <NameForAGResource> ocf:mssql:ag ag_name=<AGName> meta failover-timeout=30s master notify=true
+   sudo pcs resource create <NameForAGResource> ocf:mssql:ag ag_name=<AGName> meta failure-timeout=30s master notify=true
    ```
 
 1. Create the IP address resource for the AG that will be associated with the listener functionality.