Merge branch 'perfdocs' of https://github.com/sarat0681/azure-docs-pr into perfdocs

Author: sarat0681

articles/postgresql/flexible-server/how-to-bulkload_data.md

@@ -33,7 +33,7 @@ The preferred method to load the data into the database is by copy command. If t
 
 #### Drop indexes
 
-Before a initial data load it is advised to drop all the indexes in the tables. It is always more efficient to create the indexes after the data load.
+Before an initial data load, it is advised to drop all the indexes in the tables. It is always more efficient to create the indexes after the data load.
 
 #### Drop constraints
 
@@ -43,7 +43,7 @@ To achieve strong performance, it's advised to drop unique key constraints befor
 
 ##### Foreign key constraints
 
-It's is advised to drop foreign key constraints before initial data load and recreate once data load is completed.
+It's advised to drop foreign key constraints before initial data load and recreate once data load is completed.
 
 Changing the `session_replication_role` parameter to replica also disables all foreign key checks.However, be aware making the change can leave data in an inconsistent state if not properly used.
 
@@ -92,7 +92,7 @@ A value of 0.9 is always recommended.
 
 `max_wal_size`
 
-The max_wal_size can be set to maximum allowed value on the Flexible server, which is 64 GB while we do the initial data load.
+The max_wal_size can be set to the maximum allowed value on the Flexible server, which is 64 GB while we do the initial data load.
 
 `wal_compression`
 

articles/postgresql/flexible-server/how-to-high-io-utilization.md

@@ -75,7 +75,7 @@ ORDER BY duration DESC;
 
 High IO can also be seen in scenarios where a checkpoint is happening too frequently. One way to identify this is by checking the Postgres log file for the following log text "LOG: checkpoints are occurring too frequently."
 
-You could also investigate using an approach where periodic snapshots of `pg_stat_bgwriter` with a timestamp is saved.Using the snapshots saved the average checkpoint interval, number of checkpoints requested and number of checkpoints timed can be calculated. 
+You could also investigate using an approach where periodic snapshots of `pg_stat_bgwriter` with a timestamp is saved. Using the snapshots saved the average checkpoint interval, number of checkpoints requested and number of checkpoints timed can be calculated. 
 
 #### Disruptive autovacuum daemon process
 
@@ -147,11 +147,11 @@ select round (pg_wal_lsn_diff ('LSN value when run second time', 'LSN value when
 
 ##### `checkpoint_completion_target`
 
-A good practice would be to set it to 0.9.As an example a value of 0.9 for a `checkpoint_timeout` of 5 minutes indicates the target to complete a checkpoint is 270 sec [0.9*300 sec].A value of 0.9 provides fairly consistent I/O load.A aggressive value of `check_point_completion_target` may result in increased IO load on the server.
+A good practice would be to set it to 0.9. As an example, a value of 0.9 for a `checkpoint_timeout` of 5 minutes indicates the target to complete a checkpoint is 270 sec [0.9*300 sec]. A value of 0.9 provides fairly consistent I/O load. An aggressive value of `check_point_completion_target` may result in increased IO load on the server.
 
 ##### `checkpoint_timeout`
 
-The `checkpoint_timeout` value can be increased from default value set on the server.Please note while increasing the `checkpoint_timeout` take into consideration that increasing the value would also increase the time for crash recovery.
+The `checkpoint_timeout` value can be increased from default value set on the server. Please note while increasing the `checkpoint_timeout` take into consideration that increasing the value would also increase the time for crash recovery.
 
 #### Autovacuum tuning to decrease disruptions
 

articles/postgresql/flexible-server/how-to-pgdump-restore.md

@@ -42,7 +42,7 @@ Before the starting the pg_dump process, consider if table vacuuming is necessar
 select schemaname,relname,n_dead_tup,n_live_tup,round(n_dead_tup::float/n_live_tup::float*100) dead_pct,autovacuum_count,last_vacuum,last_autovacuum,last_autoanalyze,last_analyze from pg_stat_all_tables where n_live_tup >0;
 ```
 
-The **dead_pct** column in the above query gives percentage of dead tuples when compared to live tuples.A high dead_pct value for a table might point to the table not being properly vacuumed.For tuning autovacuum, review the article [Autovacuum Tuning](./how-to-autovacuum-tuning.md).
+The **dead_pct** column in the above query gives percentage of dead tuples when compared to live tuples. A high dead_pct value for a table might point to the table not being properly vacuumed. For tuning autovacuum, review the article [Autovacuum Tuning](./how-to-autovacuum-tuning.md).
 
 
 As a one of case perform manual vacuum analyze of the tables that are identified.
@@ -109,9 +109,9 @@ Here's an example of how this syntax might appear:
 
 Create a virtual machine in the same region, same availability zone (AZ) preferably where you have both your target and source servers or at least have the virtual machine closer to source server or a target server. Use of Azure Virtual Machines with high-performance local SSD is recommended. For more details about the SKUs review
 
-[Edv4 and Edsv4-series](https://docs.microsoft.com/azure/virtual-machines/edv4-edsv4-series)   
+[Edv4 and Edsv4-series](/azure/virtual-machines/edv4-edsv4-series)   
 
-[Ddv4 and Ddsv4-series](https://docs.microsoft.com/azure/virtual-machines/ddv4-ddsv4-series)
+[Ddv4 and Ddsv4-series](/azure/virtual-machines/ddv4-ddsv4-series)
 
 ## Next steps