Cleaned up docs regarding run options. More details on running managed_upgrade_2_acid.sql.

Author: dstreev

README.md

@@ -77,7 +77,7 @@ See the [config docs](./config.md) for details.
 To ease the launch of the application below, configure these core environment variables.
 
 ```
-hive-sre sre -db priv_dstreev -o ./sre-out` 
+hive-sre u3|sre -all|-hdp2|-hdp3|-cdh` 
 ```
 
 **NOTE** It is NOT necessary to use the `-cfg` option if your config is `$HOME/.hive-sre/cfg/default`.
@@ -102,7 +102,7 @@ Copy this encrypted password and place it in your configuration file for the con
 
 Using the **same** `-pkey <password-key>` you used to generate the encrypted password, we'll run `hive-sre`
 
-`hive-sre u3 -pkey cloudera ...`
+`hive-sre u3 -all|-hdp2|-hdp3|-cdh -pkey cloudera ...`
 
 When the `-pkey` option is specified **WITHOUT** the `-p` option (used previously), `hive-sre` will understand to **decrypt** the configuration passwords before connecting to the resources.  If you receive jdbc connection exceptions, recheck the `-pkey` and encrypted password from before.
 

src/main/resources/procs/h3_upg_procs.yaml

@@ -121,7 +121,25 @@ processes:
 
       -- Tables that are managed and aren't converted by this program, will be converted to 'EXTERNAL/purge' when they don't
       meet all the criteria for the conversion, regardless.  Using the 'action' elements of this report simply ensures
-      you are in control of the migration process.\n\n"
+      you are in control of the migration process.\n
+      
+      -- These conversions need to happen BEFORE the tables are accessed in CDP.  Generally, this is done AFTER the upgrade
+      to CDP and BEFORE the tables are turned over to the end users.  In some cases, due to the volume of changes needed,
+      the conversion can be run before the upgrade.  BUT the conversion WILL have an impact on table behavior.  Convert tables
+      in the legacy environment will NOT honor the 'purge' characteristics stated by the 'external.table.purge' TBLPROPERTIES.
+      So be advised of this caveat if you choose to run these conversions BEFORE the upgrade.\n
+      
+      -- The report includes the tables 'created_date' in the comment line above the 'ALTER'.  You can use:\n
+      --    grep -A1 'created date: yyyy-MM' managed_upgrade_2_acid.sql | grep 'ALTER TABLE' > beeline_run.sql\n
+      --         OR
+      --    grep 'ALTER TABLE' managed_upgrade_2_acid.sql | sort -k3 > beeline_run.sql\n
+      -- to target certain tables first and run this post upgrade to make them available asap.\n
+      
+      -- Consider breaking the file into multiple parts to increase throughput and reduce runtime.\n
+      -- The statement are meant to be run against 'hive'.  Use 'beeline -f <run.sql>'\n
+      
+      -- NOTE: This process CAN and SHOULD be run after the upgrade and after all the ALTER scripts have been run to ensure
+      --       you haven't missed any conversion.\n\n"
       record:             "-- This table 'could' be migrated to an ACID table unless changed.\n
                           -- Recommend forcing the manual conversion to ensure table isn't inadvertently migrated.\n
                           -- created date: %3$s\n

u3.md

@@ -75,7 +75,7 @@ For a while during the evolution of Hive 3, there was a separate 'catalog' for S
 ### Application Help
 
 ```
-usage: hive-sre u3|sre|perf -cdh|-hdp2|-hdp3|-all|-i <proc[,proc...]> -o <output-dir> [options]
+usage: hive-sre u3|sre|perf -cdh|-hdp2|-hdp3|-all|-i <proc[,proc...]> [options]
                 version:2.4.0.24.0-SNAPSHOT
 Hive SRE Utility
  -all,--all-reports                            Run ALL available processes.