Merge branch 'master' into patch-103

Author: saveenr

articles/mariadb/concepts-backup.md

@@ -14,33 +14,47 @@ Azure Database for MariaDB automatically creates server backups and stores them
 
 ## Backups
 
-Azure Database for MariaDB takes full, differential, and transaction log backups. These backups allow you to restore a server to any point-in-time within your configured backup retention period. The default backup retention period is seven days. You can optionally configure it up to 35 days. All backups are encrypted using AES 256-bit encryption.
+Azure Database for MariaDB takes backups of the data files and the transaction log. These backups allow you to restore a server to any point-in-time within your configured backup retention period. The default backup retention period is seven days. You can [optionally configure it](howto-restore-server-portal.md#set-backup-configuration) up to 35 days. All backups are encrypted using AES 256-bit encryption.
 
-These backup files are not user-exposed and cannot be exported. These backups can only be used for restore operations in Azure Database for MariaDB. You can use [mysqldump](howto-migrate-dump-restore.md) to copy a database.
+These backup files are not user-exposed and cannot be exported. These backups can only be used for restore operations in Azure Database for MySQL. You can use [mysqldump](howto-migrate-dump-restore.md) to copy a database.
 
-### Backup frequency
+The backup type and frequency is depending on the backend storage for the servers.
 
-#### Servers with up to 4-TB storage
+### Backup type and frequency
 
-For servers which support up to 4-TB maximum storage, full backups occur once every week. Differential backups occur twice a day. Transaction log backups occur every five minutes.
+#### Basic storage servers
 
-#### Servers with up to 16-TB storage
-In a subset of [Azure regions](concepts-pricing-tiers.md#storage), all newly provisioned servers can support up to 16-TB storage. Backups on these large storage servers are snapshot-based. The first full snapshot backup is scheduled immediately after a server is created. That first full snapshot backup is retained as the server's base backup. Subsequent snapshot backups are differential backups only. 
+The Basic storage is the backend storage supporting [Basic tier servers](concepts-pricing-tiers.md). Backups on Basic storage servers are snapshot-based. A full database snapshot is performed daily. There are no differential backups performed for basic storage servers and all snapshot backups are full database backups only.
 
-Differential snapshot backups occur at least once a day. Differential snapshot backups do not occur on a fixed schedule. Differential snapshot backups occur every 24 hours unless the transaction log (binlog in MariaDB) exceeds 50-GB since the last differential backup. In a day, a maximum of six differential snapshots are allowed. 
+Transaction log backups occur every five minutes.
 
-Transaction log backups occur every five minutes. 
+#### General purpose storage servers with up to 4-TB storage
+
+The General purpose storage is the backend storage supporting [General Purpose](concepts-pricing-tiers.md) and [Memory Optimized tier](concepts-pricing-tiers.md) server. For servers with general purpose storage up to 4 TB, full backups occur once every week. Differential backups occur twice a day. Transaction log backups occur every five minutes. The backups on general purpose storage up to 4-TB storage are not snapshot-based and consumes IO bandwidth at the time of backup. For large databases (> 1 TB) on 4-TB storage, we recommend you consider
+
+- Provisioning more IOPs to account for backup IOs  OR
+- Alternatively, migrate to general purpose storage that supports up to 16-TB storage if the underlying storage infrastructure is available in your preferred [Azure regions](./concepts-pricing-tiers.md#storage). There is no additional cost for general purpose storage that supports up to 16-TB storage. For assistance with migration to 16-TB storage, please open a support ticket from Azure portal.
+
+#### General purpose storage servers with up to 16-TB storage
+
+In a subset of [Azure regions](./concepts-pricing-tiers.md#storage), all newly provisioned servers can support general purpose storage up to 16-TB storage. In other words, storage up to 16-TB storage is the default general purpose storage for all the [regions](concepts-pricing-tiers.md#storage) where it is supported. Backups on these 16-TB storage servers are snapshot-based. The first full snapshot backup is scheduled immediately after a server is created. That first full snapshot backup is retained as the server's base backup. Subsequent snapshot backups are differential backups only.
+
+Differential snapshot backups occur at least once a day. Differential snapshot backups do not occur on a fixed schedule. Differential snapshot backups occur every 24 hours unless the transaction log (binlog in MariaDB) exceeds 50 GB since the last differential backup. In a day, a maximum of six differential snapshots are allowed.
+
+Transaction log backups occur every five minutes.
+ 
 
 ### Backup retention
 
 Backups are retained based on the backup retention period setting on the server. You can select a retention period of 7 to 35 days. The default retention period is 7 days. You can set the retention period during server creation or later by updating the backup configuration using [Azure portal](howto-restore-server-portal.md#set-backup-configuration) or [Azure CLI](howto-restore-server-cli.md#set-backup-configuration). 
 
 The backup retention period governs how far back in time a point-in-time restore can be retrieved, since it's based on backups available. The backup retention period can also be treated as a recovery window from a restore perspective. All backups required to perform a point-in-time restore within the backup retention period are retained in backup storage. For example, if the backup retention period is set to 7 days, the recovery window is considered last 7 days. In this scenario, all the backups required to restore the server in last 7 days are retained. With a backup retention window of seven days:
+
 - Servers with up to 4-TB storage will retain up to 2 full database backups, all the differential backups, and transaction log backups performed since the earliest full database backup.
 -	Servers with up to 16-TB storage will retain the full database snapshot, all the differential snapshots and transaction log backups in last 8 days.
 
-#### Long term retention of backups
-Long term retention of backups beyond 35 days is currently not natively supported by the service yet. You have a option to use mysqldump to take backups and store them for long term retention. Our support team has blogged a [step by step article](https://techcommunity.microsoft.com/t5/azure-database-for-mysql/automate-backups-of-your-azure-database-for-mysql-server-to/ba-p/1791157) to share how you can achieve it. 
+#### Long-term retention of backups
+Long-term retention of backups beyond 35 days is currently not natively supported by the service yet. You have a option to use mysqldump to take backups and store them for long-term retention. Our support team has blogged a [step by step article](https://techcommunity.microsoft.com/t5/azure-database-for-mysql/automate-backups-of-your-azure-database-for-mysql-server-to/ba-p/1791157) to share how you can achieve it. 
 
 ### Backup redundancy options
 

articles/mariadb/concepts-pricing-tiers.md

@@ -17,7 +17,7 @@ You can create an Azure Database for MariaDB server in one of three different pr
 | Compute generation | Gen 5 |Gen 5 | Gen 5 |
 | vCores | 1, 2 | 2, 4, 8, 16, 32, 64 |2, 4, 8, 16, 32 |
 | Memory per vCore | 2 GB | 5 GB | 10 GB |
-| Storage size | 5 GB to 1 TB | 5 GB to 4 TB | 5 GB to 4 TB |
+| Storage size | 5 GB to 1 TB | 5 GB to 16 TB | 5 GB to 16 TB |
 | Database backup retention period | 7 to 35 days | 7 to 35 days | 7 to 35 days |
 
 To choose a pricing tier, use the following table as a starting point.

articles/mariadb/concepts-server-logs.md

@@ -39,7 +39,7 @@ For local server storage, you can list and download slow query logs using the Az
 Azure Monitor Diagnostic Logs allows you to pipe slow query logs to Azure Monitor Logs (Log Analytics), Azure Storage, or Event Hubs. See [below](concepts-server-logs.md#diagnostic-logs) for more information.
 
 ## Local server storage log retention
-When logging to the server's local storage, logs are available for up to seven days from their creation. If the total size of the available logs exceeds 7 GB, then the oldest files are deleted until space is available.
+When logging to the server's local storage, logs are available for up to seven days from their creation. If the total size of the available logs exceeds 7 GB, then the oldest files are deleted until space is available. The 7 GB storage limit for the server logs is available free of cost and cannot be extended. 
 
 Logs are rotated every 24 hours or 7 GB, whichever comes first.
 

articles/mysql/concepts-server-logs.md

@@ -39,7 +39,7 @@ For local server storage, you can list and download slow query logs using the Az
 Azure Monitor Diagnostic Logs allows you to pipe slow query logs to Azure Monitor Logs (Log Analytics), Azure Storage, or Event Hubs. See [below](concepts-server-logs.md#diagnostic-logs) for more information.
 
 ## Local server storage log retention
-When logging to the server's local storage, logs are available for up to seven days from their creation. If the total size of the available logs exceeds 7 GB, then the oldest files are deleted until space is available.
+When logging to the server's local storage, logs are available for up to seven days from their creation. If the total size of the available logs exceeds 7 GB, then the oldest files are deleted until space is available.The 7 GB storage limit for the server logs is available free of cost and cannot be extended. 
 
 Logs are rotated every 24 hours or 7 GB, whichever comes first.
 
@@ -139,4 +139,4 @@ Once your slow query logs are piped to Azure Monitor Logs through Diagnostic Log
     
 ## Next Steps
 - [How to configure slow query logs from the Azure portal](howto-configure-server-logs-in-portal.md)
-- [How to configure slow query logs from the Azure CLI](howto-configure-server-logs-in-cli.md)
+- [How to configure slow query logs from the Azure CLI](howto-configure-server-logs-in-cli.md)

articles/synapse-analytics/get-started-analyze-sql-on-demand.md

@@ -31,13 +31,13 @@ In this section, you'll use a serverless SQL pool to analyze NYC Taxi data in an
 1. Paste the following code into the script.
 
     ```
-SELECT
-    TOP 100 *
-FROM
-    OPENROWSET(
-            BULK 'https://contosolake.dfs.core.windows.net/users/NYCTripSmall.parquet',
-        FORMAT='PARQUET'
-    ) AS [result]
+    SELECT
+        TOP 100 *
+    FROM
+        OPENROWSET(
+                BULK 'https://contosolake.dfs.core.windows.net/users/NYCTripSmall.parquet',
+            FORMAT='PARQUET'
+        ) AS [result]
     ```
 1. Click **Run**
 

articles/synapse-analytics/get-started-create-workspace.md

@@ -60,6 +60,14 @@ After your Azure Synapse workspace is created, you have two ways to open Synapse
 * Open your Synapse workspace in the [Azure portal](https://portal.azure.com), in the **Overview** section of the Synapse workspace, select **Open** in the Open Synapse Studio box.
 * Go to the `https://web.azuresynapse.net` and sign in to your workspace.
 
+## Place sample data into the primary storage account
+
+* Download this file to your computer: https://azuresynapsestorage.blob.core.windows.net/sampledata/NYCTaxiSmall/NYCTripSmall.parquet 
+* In Synapse Studiio, navigate to the the Data Hub. Click **Linked**.
+* Under the category **Azure Data Lake Storae Gen2** you'll see an item with a name like **workspacename ( Primary - workspacename )**
+* Click on the container marked **Primary**
+* Click **Upload** and select the `NYCTripSmall.parquet` file you downloaded
+
 ## Next steps
 
 > [!div class="nextstepaction"]