Merge pull request #259844 from markingmyname/stats

[Repo stats] Fix absolute links and metadata

Author: JamesJBarnett

articles/dms/known-issues-azure-sql-migration-azure-data-studio.md

@@ -1,8 +1,8 @@
 ---
 title: Query Store best practices in Azure Database for PostgreSQL - Flex Server
 description: This article describes best practices for Query Store in Azure Database for PostgreSQL - Flex Server.
-author: ssen-msft
-ms.author: ssen
+author: markingmyname
+ms.author: maghan
 ms.service: postgresql
 ms.subservice: flexible-server
 ms.topic: conceptual
@@ -18,22 +18,25 @@ ms.date: 7/1/2023
 This article outlines best practices for using Query Store in Azure Database for PostgreSQL.
 
 ## Set the optimal query capture mode
+
 Let Query Store capture the data that matters to you. 
 
 |**pg_qs.query_capture_mode** |	**Scenario**|
 |---|---|
 |_All_	|Analyze your workload thoroughly in terms of all queries and their execution frequencies and other statistics. Identify new queries in your workload. Detect if ad hoc queries are used to identify opportunities for user or auto parameterization. _All_ comes with an increased resource consumption cost. |
-|_Top_	|Focus your attention on top queries - those issued by clients.
-|_None_	|If set to None, Query Store will not capture any new queries. You've already captured a query set and time window that you want to investigate and you want to eliminate the distractions that other queries may introduce. _None_ is suitable for testing and bench-marking environments. _None_ should be used with caution as you might miss the opportunity to track and optimize important new queries. |
+|_Top_ |Focus your attention on top queries - those issued by clients.
+|_None_	|If set to None, Query Store won't capture any new queries. You've already captured a query set and time window that you want to investigate and you want to eliminate the distractions that other queries may introduce. _None_ is suitable for testing and bench-marking environments. _None_ should be used with caution as you might miss the opportunity to track and optimize important new queries. |
 
 
 > [!NOTE] 
 > **pg_qs.query_capture_mode** supersedes **pgms_wait_sampling.query_capture_mode**. If pg_qs.query_capture_mode is _none_, the pgms_wait_sampling.query_capture_mode setting has no effect. 
 
 
 ## Keep the data you need
-The **pg_qs.retention_period_in_days** parameter specifies in days the data retention period for Query Store. Older query and statistics data is deleted. By default, Query Store is configured to retain the data for 7 days. Avoid keeping historical data you do not plan to use. Increase the value if you need to keep data longer.
+
+The **pg_qs.retention_period_in_days** parameter specifies in days the data retention period for Query Store. Older query and statistics data is deleted. By default, Query Store is configured to retain the data for seven days. Avoid keeping historical data you don't plan to use. Increase the value if you need to keep data longer.
 
 
 ## Next steps
+
 - Learn how to get or set parameters using the [Azure portal](howto-configure-server-parameters-using-portal.md) or the [Azure CLI](howto-configure-server-parameters-using-cli.md).

articles/postgresql/flexible-server/concepts-query-store-best-practices.md

@@ -1,57 +1,63 @@
 ---
 title: Query Store scenarios - Azure Database for PostgreSQL - Flex Server
 description: This article describes some scenarios for Query Store in Azure Database for PostgreSQL - Flex Server.
-author: ssen-msft
-ms.author: ssen
+author: markingmyname
+ms.author: maghan
+ms.date: 11/30/2023
 ms.service: postgresql
 ms.subservice: flexible-server
 ms.topic: conceptual
-ms.date: 7/1/2023
 ---
+
 # Usage scenarios for Query Store - Flexible Server
 
 [!INCLUDE [applies-to-postgresql-flexible-server](../includes/applies-to-postgresql-flexible-server.md)]
 
-You can use Query Store in a wide variety of scenarios in which tracking and maintaining predictable workload performance is critical. Consider the following examples: 
-- Identifying and tuning top expensive queries 
-- A/B testing 
-- Keeping performance stable during upgrades 
-- Identifying and improving ad hoc workloads 
+You can use Query Store in a wide variety of scenarios in which tracking and maintaining predictable workload performance is critical. Consider the following examples:
+- Identifying and tuning top expensive queries
+- A/B testing
+- Keeping performance stable during upgrades
+- Identifying and improving improvised workloads
+
+## Identify and tune expensive queries
+
+### Identify longest running queries
 
-## Identify and tune expensive queries 
+Use Query Store views on the azure_sys database of your server to quickly identify the longest running queries. These queries typically tend to consume the most resources. Optimizing your longest running queries can improve performance by freeing up resources used by other queries running on your system.
 
-### Identify longest running queries 
-Use Query Store views on the azure_sys database of your server to quickly identify the longest running queries. These queries typically tend to consume the most resources. Optimizing your longest running queries can improve performance by freeing up resources used by other queries running on your system. 
+### Target queries with performance deltas
 
-### Target queries with performance deltas 
 Query Store slices the performance data into time windows, so you can track a query's performance over time. This helps you identify exactly which queries are contributing to an increase in overall time spent. As a result you can do targeted troubleshooting of your workload.
 
-### Tuning expensive queries 
-When you identify a query with suboptimal performance, the action you take depends on the nature of the problem: 
+### Tune expensive queries
+
+When you identify a query with suboptimal performance, the action you take depends on the nature of the problem:
 - Make sure that the statistics are up-to-date for the underlying tables used by the query.
-- Consider rewriting expensive queries. For example, take advantage of query parameterization and reduce the use of dynamic SQL. Implement optimal logic when reading data like applying data filtering on database side, not on application side. 
-
-
-## A/B testing 
-Use Query Store to compare workload performance before and after an application change you plan to introduce or before and after migration. Example scenarios for using Query Store to assess the impact of changes to workload performance: 
-- Migration between PostgreSQL versions. 
-- Rolling out a new version of an application. 
-- Adding additional resources to the server. 
-- Creating missing indexes on tables referenced by expensive queries. 
-- Migration from Single Server to Flex Server. 
- 
-In any of these scenarios, apply the following workflow: 
-1. Run your workload with Query Store before the planned change to generate a performance baseline. 
-2. Apply application change(s) at the controlled moment in time. 
-3. Continue running the workload long enough to generate performance image of the system after the change. 
-4. Compare results from before and after the change. 
-5. Decide whether to keep the change or rollback. 
-
-
-## Identify and improve ad hoc workloads 
-Some workloads do not have dominant queries that you can tune to improve overall application performance. Those workloads are typically characterized with a relatively large number of unique queries, each of them consuming a portion of system resources. Each unique query is executed infrequently, so individually their runtime consumption is not critical. On the other hand, given that the application is generating new queries all the time, a significant portion of system resources is spent on query compilation, which is not optimal. Usually, this situation happens if your application generates queries (instead of using stored procedures or parameterized queries) or if it relies on object-relational mapping frameworks that generate queries by default. 
- 
-If you are in control of the application code, you may consider rewriting the data access layer to use stored procedures or parameterized queries. However, this situation can be also be improved without application changes by forcing query parameterization for the entire database (all queries) or for the individual query templates with the same query hash. 
-
-## Next steps
-- Learn more about the [best practices for using Query Store](concepts-query-store-best-practices.md)
+- Consider rewriting expensive queries. For example, take advantage of query parameterization and reduce the use of dynamic SQL. Implement optimal logic when reading data like applying data filtering on database side, not on application side.
+
+## A/B testing
+
+Use Query Store to compare workload performance before and after an application change you plan to introduce or before and after migration. Example scenarios for using Query Store to assess the impact of changes to workload performance:
+- Migration between PostgreSQL versions.
+- Rolling out a new version of an application.
+- Adding additional resources to the server.
+- Creating missing indexes on tables referenced by expensive queries.
+- Migration from Single Server to Flex Server.
+
+In any of these scenarios, apply the following workflow:
+1. Run your workload with Query Store before the planned change to generate a performance baseline.
+1. Apply application change(s) at the controlled moment in time.
+1. Continue running the workload long enough to generate performance image of the system after the change.
+1. Compare results from before and after the change.
+1. Decide whether to keep the change or rollback.
+
+## Identify and improve improvised workloads
+
+Some workloads don't have dominant queries that you can tune to improve overall application performance. Those workloads are typically characterized with a relatively large number of unique queries, each of them consuming a portion of system resources. Each unique query is executed infrequently, so individually their runtime consumption isn't critical. On the other hand, given that the application is generating new queries all the time, a significant portion of system resources is spent on query compilation, which isn't optimal. Usually, this situation happens if your application generates queries (instead of using stored procedures or parameterized queries) or if it relies on object-relational mapping frameworks that generate queries by default.
+
+If you are in control of the application code, you might consider rewriting the data access layer to use stored procedures or parameterized queries. However, this situation can be also be improved without application changes by forcing query parameterization for the entire database (all queries) or for the individual query templates with the same query hash.
+
+## Next step
+
+> [!div class="nextstepaction"]
+> [best practices for using Query Store](concepts-query-store-best-practices.md)