20220524 1354 build review

WilliamDAssafMSFT · WilliamDAssafMSFT · commit 4707740b3edd · 2022-05-24T13:54:26.000-07:00
diff --git a/articles/synapse-analytics/migration-guides/netezza/1-design-performance-migration.md b/articles/synapse-analytics/migration-guides/netezza/1-design-performance-migration.md
@@ -251,7 +251,7 @@ You can edit existing Netezza CREATE TABLE and CREATE VIEW scripts to create the
 
 However, all the information that specifies the current definitions of tables and views within the existing Netezza environment is maintained within system catalog tables. These tables are the best source of this information, as it's guaranteed to be up to date and complete. User-maintained documentation may not be in sync with the current table definitions.
 
-Access the information in these tables via utilities such as nz_ddl_table and generate the `CREATE TABLE DDL` statements for the equivalent tables in Azure Synapse.
+Access the information in these tables via utilities such as `nz_ddl_table` and generate the `CREATE TABLE DDL` statements for the equivalent tables in Azure Synapse.
 
 Third-party migration and ETL tools also use the catalog information to achieve the same result.
 
@@ -263,7 +263,7 @@ During a migration exercise, extract the data as efficiently as possible. Use th
 
 This is a simple example of an external table extract:
 
-```
+```sql
 CREATE EXTERNAL TABLE '/tmp/export_tab1.csv' USING (DELIM ',') AS SELECT * from <TABLENAME>;
 ```
 
diff --git a/articles/synapse-analytics/migration-guides/netezza/2-etl-load-migration-considerations.md b/articles/synapse-analytics/migration-guides/netezza/2-etl-load-migration-considerations.md
@@ -41,7 +41,7 @@ If enabled, Netezza query history tables contain information that can determine
 
 Here's an example query that looks for the usage of a specific table within a given time window:
 
-```
+```sql
 SELECT FORMAT_TABLE_ACCESS (usage),
   hq.submittime
 FROM "$v_hist_queries" hq
@@ -59,7 +59,9 @@ AND
   OR instr(FORMAT_TABLE_ACCESS(usage),'del') > 0
 )
 AND status=0;
+```
 
+```output
 | FORMAT_TABLE_ACCESS | SUBMITTIME
 ----------------------+---------------------------
 ins                   | 2015-06-16 18:32:25.728042
@@ -162,7 +164,7 @@ Use the metadata from the Netezza catalog tables to determine whether any of the
 
 For example, this Netezza SQL query shows columns and column types:
 
-```
+```sql
 SELECT
 tablename,
   attname AS COL_NAME,
@@ -174,7 +176,9 @@ FROM _v_table a
 WHERE a.tablename = 'ATT_TEST'
 AND a.schema = 'ADMIN'
 ORDER BY attnum;
+```
 
+```output
 TABLENAME | COL_NAME    | COL_TYPE             | COL_NUM
 ----------+-------------+----------------------+--------
 ATT_TEST  | COL_INT     | INTEGER              | 1
@@ -255,7 +259,7 @@ Once the database tables to be migrated have been created in Azure Synapse, you
 
 - **File Extract**&mdash;Extract the data from the Netezza tables to flat files, normally in CSV format, via nzsql with the -o option or via the `CREATE EXTERNAL TABLE` statement. Use an external table whenever possible since it's the most efficient in terms of data throughput. The following SQL example, creates a CSV file via an external table:
 
-  ```
+  ```sql
   CREATE EXTERNAL TABLE '/data/export.csv' USING (delimiter ',')
   AS SELECT col1, col2, expr1, expr2, col3, col1 || col2 FROM your table;
   ```
diff --git a/articles/synapse-analytics/migration-guides/netezza/3-security-access-operations.md b/articles/synapse-analytics/migration-guides/netezza/3-security-access-operations.md
@@ -31,7 +31,7 @@ For more information on the [Azure Synapse security](/azure/synapse-analytics/sq
 
 #### Netezza authorization options
 
-The IBM® Netezza® system offers several authentication methods for Netezza database users:
+The IBM&reg; Netezza&reg; system offers several authentication methods for Netezza database users:
 
 - **Local authentication**: Netezza administrators define database users and their passwords by using the `CREATE USER` command or through Netezza administrative interfaces. In local authentication, use the Netezza system to manage database accounts and passwords, and to add and remove database users from the system. This method is the default authentication method.
 
@@ -74,13 +74,13 @@ See the following sections for more details.
 > [!TIP]
 > Migration of a data warehouse requires more than just tables, views, and SQL statements.
 
-The information about current users and groups in a Netezza system is held in system catalog views `_v_users` and `_v_groupusers`. Use the nzsql utility or tools such as the Netezza® Performance, NzAdmin, or the Netezza Utility scripts to list user privileges. For example, use the dpu and dpgu commands in nzsql to display users or groups with their permissions.
+The information about current users and groups in a Netezza system is held in system catalog views `_v_users` and `_v_groupusers`. Use the nzsql utility or tools such as the Netezza&reg; Performance, NzAdmin, or the Netezza Utility scripts to list user privileges. For example, use the `dpu` and `dpgu` commands in nzsql to display users or groups with their permissions.
 
 Use or edit the utility scripts `nz_get_users` and `nz_get_user_groups` to retrieve the same information in the required format.
 
-Query system catalog views directly (if the user has `SELECT` access to those views) to obtain current lists of users and roles defined within the system. See examples:
+Query system catalog views directly (if the user has `SELECT` access to those views) to obtain current lists of users and roles defined within the system. See examples to list users, groups, or users and their associated groups:
 
-```
+```sql
 -- List of users
 SELECT USERNAME FROM _V_USER;
 
@@ -106,7 +106,7 @@ In Netezza, the individual permissions are represented as individual bits within
 
 The simplest way to obtain a DDL script that contains the `GRANT` commands to replicate the current privileges for users and groups is to use the appropriate Netezza utility scripts:
 
-```
+```sql
 --List of group privileges
 nz_ddl_grant_group -usrobj dbname > output_file_dbname;
 
@@ -120,7 +120,7 @@ Netezza supports two classes of access rights,&mdash;Admin and Object. See the f
 
 | Admin Privilege            | Description | Azure Synapse Equivalent |
 |----------------------------|-------------|-----------------|
-| Backup                     | Allows user to create backups. The user can run backups. The user can run the command nzbackup. | \* |
+| Backup                     | Allows user to create backups. The user can run backups. The user can run the command `nzbackup`. | \* |
 | [Create] Aggregate         | Allows the user to create user-defined aggregates (UDAs). Permission to operate on existing UDAs is controlled by object privileges. | CREATE FUNCTION \*\*\* |
 | [Create] Database          | Allows the user to create databases. Permission to operate on existing databases is controlled by object privileges. | CREATE DATABASE |
 | [Create] External Table    | Allows the user to create external tables. Permission to operate on existing tables is controlled by object privileges. | CREATE TABLE |
@@ -185,7 +185,7 @@ Netezza administration tasks typically fall into two categories:
 
 - Database administration, which is managing user databases and their content, loading data, backing up data, restoring data, and controlling access to data and permissions.
 
-IBM® Netezza® offers several ways or interfaces that you can use to perform the various system and database management tasks:
+IBM&reg; Netezza&reg; offers several ways or interfaces that you can use to perform the various system and database management tasks:
 
 - Netezza commands (nz* commands) are installed in the /nz/kit/bin directory on the Netezza host. For many of the nz* commands, you must be able to sign into the Netezza system to access and run those commands. In most cases, users sign in as the default nz user account, but you can create other Linux user accounts on your system. Some commands require you to specify a database user account, password, and database to ensure that you've permission to do the task.
 
@@ -251,7 +251,7 @@ For more information, see [Azure Synapse operations and management options](/azu
 
 Netezza appliances are redundant, fault-tolerant systems and there are diverse options in a Netezza system to enable high availability and disaster recovery.
 
-Adding IBM® Netezza Replication Services for disaster recovery improves fault tolerance by extending redundancy across local and wide area networks.
+Adding IBM&reg; Netezza Replication Services for disaster recovery improves fault tolerance by extending redundancy across local and wide area networks.
 
 IBM Netezza Replication Services protects against data loss by synchronizing data on a primary system (the primary node) with data on one or more target nodes (subordinates). These nodes make up a replication set.
 
diff --git a/articles/synapse-analytics/migration-guides/netezza/4-visualization-reporting.md b/articles/synapse-analytics/migration-guides/netezza/4-visualization-reporting.md
@@ -170,9 +170,9 @@ When it comes to migrating to Azure Synapse, there are several things that can i
 
 BI tool reports and dashboards, and other visualizations, are produced by issuing SQL queries that access physical tables and/or views in your data warehouse or data mart. When it comes to migrating your data warehouse or data mart schema to Azure Synapse, there may be incompatibilities that can impact reports and dashboards, such as:
 
-- Non-standard table types supported in your legacy data warehouse DBMS that don't have an equivalent in Azure Synapse (like the Teradata time-series tables)
+- Non-standard table types supported in your legacy data warehouse DBMS that don't have an equivalent in Azure Synapse.
 
-- Data types supported in your legacy data warehouse DBMS that don't have an equivalent in Azure Synapse. For example, Teradata Geospatial or Interval data types.
+- Data types supported in your legacy data warehouse DBMS that don't have an equivalent in Azure Synapse.  
 
 In many cases, where there are incompatibilities, there may be ways around them. For example, the data in unsupported table types can be migrated into a standard table with appropriate data types and indexed or partitioned on a date/time column. Similarly, it may be able to represent unsupported data types in another type of column and perform calculations in Azure Synapse to achieve the same. Either way, it will need refactoring.
 
diff --git a/articles/synapse-analytics/migration-guides/netezza/5-minimize-sql-issues.md b/articles/synapse-analytics/migration-guides/netezza/5-minimize-sql-issues.md
@@ -130,7 +130,7 @@ Edit existing Netezza `CREATE TABLE` and `CREATE VIEW` scripts to create the equ
 
 However, all the information that specifies the current definitions of tables and views within the existing Netezza environment is maintained within system catalog tables. This is the best source of this information as it's guaranteed to be up to date and complete. Be aware that user-maintained documentation may not be in sync with the current table definitions.
 
-Access this information by using utilities such as nz_ddl_table and generate the `CREATE TABLE DDL` statements. Edit these statements for the equivalent tables in Azure Synapse.
+Access this information by using utilities such as `nz_ddl_table` and generate the `CREATE TABLE DDL` statements. Edit these statements for the equivalent tables in Azure Synapse.
 
 > [!TIP]
 > Third-party tools and services can automate data mapping tasks.
diff --git a/articles/synapse-analytics/migration-guides/teradata/1-design-performance-migration.md b/articles/synapse-analytics/migration-guides/teradata/1-design-performance-migration.md
@@ -186,39 +186,39 @@ There are a few differences in SQL Data Manipulation Language (DML) syntax betwe
 
 - `QUALIFY`&mdash;Teradata supports the `QUALIFY` operator. For example:
 
-  ```
+  ```sql
   SELECT col1
   FROM tab1
-  WHERE col1=\'XYZ\'
+  WHERE col1='XYZ'
   QUALIFY ROW_NUMBER () OVER (PARTITION by
   col1 ORDER BY col1) = 1;
   ```
 
   The equivalent Azure Synapse syntax is:
 
-  ```
-  SELECT \* FROM (
+  ```sql
+  SELECT * FROM (
   SELECT col1, ROW_NUMBER () OVER (PARTITION by col1 ORDER BY col1) rn
-  FROM tab1 WHERE col1=\'XYZ\'
+  FROM tab1 WHERE col1='XYZ'
   ) WHERE rn = 1;
   ```
 
-- Date Arithmetic&mdash;Azure Synapse has operators such as `DATEADD` and `DATEDIFF` which can be used on `DATE` or `DATETIME` fields. Teradata supports direct subtraction on dates such as 'SELECT DATE1&mdash;DATE2 FROM...'
+- Date Arithmetic&mdash;Azure Synapse has operators such as `DATEADD` and `DATEDIFF` which can be used on `DATE` or `DATETIME` fields. Teradata supports direct subtraction on dates such as 'SELECT DATE1-DATE2 FROM...'
 
 - In Group by ordinal, explicitly provide the T-SQL column name.
 
-- LIKE ANY&mdash;Teradata supports LIKE ANY syntax such as:
+- Teradata supports LIKE ANY syntax such as:
 
-  ```
-  SELECT \* FROM CUSTOMER
+  ```sql
+  SELECT * FROM CUSTOMER
   WHERE POSTCODE LIKE ANY
-  ('CV1%', 'CV2%', CV3%');
+  ('CV1%', 'CV2%', 'CV3%');
   ```
 
   The equivalent in Azure Synapse syntax is:
 
-  ```
-  SELECT \* FROM CUSTOMER
+  ```sql
+  SELECT * FROM CUSTOMER
   WHERE
   (POSTCODE LIKE 'CV1%') OR (POSTCODE LIKE 'CV2%') OR (POSTCODE LIKE 'CV3%');
   ```
@@ -271,7 +271,7 @@ You can edit existing Teradata CREATE TABLE and CREATE VIEW scripts to create th
 
 However, all the information that specifies the current definitions of tables and views within the existing Teradata environment is maintained within system catalog tables. These tables are the best source of this information, as it's guaranteed to be up to date and complete. User-maintained documentation may not be in sync with the current table definitions.
 
-Access the information in these tables via views into the catalog such as DBC.ColumnsV, and generate the equivalent CREATE TABLE DDL statements for the equivalent tables in Azure Synapse.
+Access the information in these tables via views into the catalog such as `DBC.ColumnsV`, and generate the equivalent CREATE TABLE DDL statements for the equivalent tables in Azure Synapse.
 
 Third-party migration and ETL tools also use the catalog information to achieve the same result.
 
diff --git a/articles/synapse-analytics/migration-guides/teradata/2-etl-load-migration-considerations.md b/articles/synapse-analytics/migration-guides/teradata/2-etl-load-migration-considerations.md
@@ -41,10 +41,11 @@ If enabled, Teradata system catalog tables and logs contain information that can
 
 Here's an example query on dbc.tables that provides the date of last access and last modification:
 
-```
-Select TableName, CreatorName, CreateTimeStamp, LastAlterName,
-LastAlterTimeStamp, AccessCount, LastAccessTimeStamp from DBC.Tables t
-Where DataBaseName = 'databasename'
+```sql
+SELECT TableName, CreatorName, CreateTimeStamp, LastAlterName,
+LastAlterTimeStamp, AccessCount, LastAccessTimeStamp 
+FROM DBC.Tables t
+WHERE DataBaseName = 'databasename'
 ```
 
 If logging is enabled and the log history is accessible, other information, such as SQL query text, is available in table DBQLogTbl and associated logging tables. For more information, see [Teradata log history](https://docs.teradata.com/reader/wada1XMYPkZVTqPKz2CNaw/PuQUxpyeCx4jvP8XCiEeGA).
diff --git a/articles/synapse-analytics/migration-guides/teradata/3-security-access-operations.md b/articles/synapse-analytics/migration-guides/teradata/3-security-access-operations.md
@@ -80,8 +80,8 @@ After data extraction, use Teradata system catalog tables to generate equivalent
 
 The information about current users and roles in a Teradata system is found in the system catalog tables `DBC.USERS` (or `DBC.DATABASES`) and `DBC.ROLEMEMBERS`. Query these tables (if the user has `SELECT` access to those tables) to obtain current lists of users and roles defined within the system. The following are examples of queries to do this for individual users:
 
-```
-/\*\*\*SQL to find all users\*\*\*/
+```sql
+/***SQL to find all users***/
 SELECT
 DatabaseName AS UserName
 From dbc.databases
@@ -114,7 +114,7 @@ There's no way to retrieve existing passwords, so you need to implement a scheme
 
 In a Teradata system, the system tables `DBC.ALLRIGHTS` and `DBC.ALLROLERIGHTS` hold the access rights for users and roles. Query these tables (if the user has `SELECT` access to those tables) to obtain current lists of access rights defined within the system. The following are examples of queries for individual users:
 
-```
+```sql
 /**SQL for AccessRights held by a USER***/
 SELECT UserName, DatabaseName,TableName,ColumnName,
 CASE WHEN Abbv.AccessRight IS NOT NULL THEN Abbv.Description ELSE 
@@ -255,7 +255,7 @@ Teradata Database contains many log tables in the Data Dictionary that accumulat
 
 #### Dictionary tables to maintain
 
-Reset accumulators and peak values using the DBC.AMPUsage view and the ClearPeakDisk macro provided with the software:
+Reset accumulators and peak values using the `DBC.AMPUsage` view and the `ClearPeakDisk` macro provided with the software:
 
 - `DBC.Acctg`: resource usage by account/user
 
diff --git a/articles/synapse-analytics/migration-guides/teradata/5-minimize-sql-issues.md b/articles/synapse-analytics/migration-guides/teradata/5-minimize-sql-issues.md
@@ -102,7 +102,7 @@ The Azure environment also includes specific features for complex analytics on t
 > [!TIP]
 > Assess the impact of unsupported data types as part of the preparation phase.
 
-Most Teradata data types have a direct equivalent in Azure Synapse. This table shows these data types together with the recommended approach for handling them. In the table, Teradata column type is the type that's stored within the system catalog&mdash;for example, in DBC.ColumnsV.
+Most Teradata data types have a direct equivalent in Azure Synapse. This table shows these data types together with the recommended approach for handling them. In the table, Teradata column type is the type that's stored within the system catalog&mdash;for example, in `DBC.ColumnsV`.
 
 | Teradata column type | Teradata data type | Azure Synapse data type |
 |----------------------|--------------------|----------------|
@@ -151,7 +151,7 @@ Most Teradata data types have a direct equivalent in Azure Synapse. This table s
 
 Use the metadata from the Teradata catalog tables to determine whether any of these data types are to be migrated and allow for this in the migration plan. For example, use a SQL query like this one to find any occurrences of unsupported data types that need attention.
 
-```
+```sql
 SELECT
 ColumnType, CASE
 WHEN ColumnType = '++' THEN 'TD_ANYTYPE' 
@@ -203,7 +203,7 @@ Edit existing Teradata `CREATE TABLE` and `CREATE VIEW` scripts to create the eq
 
 However, all the information that specifies the current definitions of tables and views within the existing Teradata environment is maintained within system catalog tables. This is the best source of this information as it's guaranteed to be up to date and complete. Be aware that user-maintained documentation may not be in sync with the current table definitions.
 
-Access this information via views onto the catalog such as DBC.ColumnsV and generate the equivalent `CREATE TABLE DDL` statements for the equivalent tables in Azure Synapse.
+Access this information via views onto the catalog such as `DBC.ColumnsV` and generate the equivalent `CREATE TABLE DDL` statements for the equivalent tables in Azure Synapse.
 
 > [!TIP]
 > Third-party tools and services can automate data mapping tasks.
@@ -227,20 +227,20 @@ Be aware of these differences in SQL Data Manipulation Language (DML) syntax bet
 
 - `QUALIFY`&mdash;Teradata supports the `QUALIFY` operator. For example:
 
-  ```
+  ```sql
   SELECT col1
   FROM tab1
-  WHERE col1=\'XYZ\'
+  WHERE col1='XYZ'
   QUALIFY ROW_NUMBER () OVER (PARTITION by
   col1 ORDER BY col1) = 1;
   ```
 
   The equivalent Azure Synapse syntax is:
 
-  ```
-  SELECT \* FROM (
+  ```sql
+  SELECT * FROM (
   SELECT col1, ROW_NUMBER () OVER (PARTITION by col1 ORDER BY col1) rn
-  FROM tab1 WHERE col1=\'XYZ\'
+  FROM tab1 WHERE col1='XYZ'
   ) WHERE rn = 1;
   ```
 
@@ -250,16 +250,16 @@ Be aware of these differences in SQL Data Manipulation Language (DML) syntax bet
 
 - `LIKE ANY`&mdash;Teradata supports `LIKE ANY` syntax such as:
 
-  ```
-  SELECT \* FROM CUSTOMER
+  ```sql
+  SELECT * FROM CUSTOMER
   WHERE POSTCODE LIKE ANY
-  ('CV1%', 'CV2%', CV3%');
+  ('CV1%', 'CV2%', 'CV3%');
   ```
 
   The equivalent in Azure Synapse syntax is:
 
-  ```
-  SELECT \* FROM CUSTOMER
+  ```sql
+  SELECT * FROM CUSTOMER
   WHERE
   (POSTCODE LIKE 'CV1%') OR (POSTCODE LIKE 'CV2%') OR (POSTCODE LIKE 'CV3%');
   ```
