ENOVIA Windows Vault Database Migration From V5R17 To V5R18

Introduction

These instructions apply only to migrating the Vault database. This process is required for successful migration from R17 to R18. However, you must also run the standard ENOVIA V5 VPM migration separately in order to achieve a complete migration from R17 to R18.

Remember that Vault data may be contained in the regular ENOVIA V5 VPM database (the same one that contains all the production data) or it may be in a separate database, or both. You will need to run this migration once for each database that contains Vault data. If you are uncertain about the location of your vault data, you should determine the names of all the databases that contain vault data before starting this Vault Migration script. You can only run this migration script on one database at a time. If you have multiple Vault databases, you will have to run the Vault database migration multiple times.

These instructions assume you have completed the standard ENOVIA V5 VPM database migration. If you have not completed it, please stop and run the ENOVIA V5 VPM database migration first.

These instructions do not cover migration of a Unix database. This is covered in a separate document.

These instructions do not cover migration of the Vault environment. This is covered in a separate document. You must change the ENOVIA V5 VPM environment in R18 to be able to use the R17 vault files. You must perform both the Vault environment changes and the Vault Database Migration in order to access the same vault information in R18 that you were using in R17.

Vault Database Migration Instructions

1. MAKE AN OFFLINE BACKUP OF ALL VAULT DATABASES and copy them to tape before starting any migration.
2. Ensure that you are migrating directly from V5R17 to V5R18. These procedures do not support any other releases or migration effort. Do not attempt to use any other releases of ENOVIA V5 VPM with these instructions. Also ensure that your V5R18 Vault path points to the same path as your V5R17 Vault.
3. Ensure that you have a working V5R17 installation, including a completely functional Oracle or DB2 database that conforms to the required level of Oracle or DB2 software and is up and running before beginning migration. There should be no users connected to ENOVIA LCA or the database at the time of migration.
4. Logon to the ENOVIA LCA product server with the ENOVIA administrator ID that you defined during your enoviadbsetup. This will be the same admnistrator ID that you used to run the regular database migration. DO NOT attempt to run the database migration as root.
5. cd to the code/command directory under your R18 product install path. This path will appear something like one of these:
   
   ~/aix_a/code/command
~/solaris_a/code/command
~/hp_b/code/command
   
   under the directory where you installed the product.
6. Create (for example, using the notepad editor) a batch file containing all the parameters you will need to run the migration script. The parameters should all wrap continuously as one line; there should be no carriage return. The batch file must have the suffix .bat to be executable. If it does not exceed the operating system limit for the length of a line, you could also type these commands directly onto a command line instead of using a command file.
7. If you are using a DB2 database, you will need to launch this vault database migration command line or command file from a DB2 command window. You can generate this window by going to a C:/ shell prompt or an MKS toolkit Korn shell and typing the command db2cmd. If you are using Oracle, you will need to launch this command from an MKS toolkit Korn shell. Failure to use the correct shell documented in this step will cause the script to fail. Other shells and command lines are not supported.
   
   The parameters are:
   
   DBVendor : ORACLE or DB2
   DBName : Database name
   DBAdmHome : Database administrator home directory
   (for userid that created the database in Oracle or DB2)
   DBAID : Database administrator ID (a user-id that has DBA permissions; may be different from the ID that owns the tables)
   IdxTbsName : Tablespace name for indexes inside the database
   TbsName : Tablespace name for tables inside the database (can be the same as IdxTbsName)
   
   For command line help with this script, simply type Upgrade518_Vault.sh -h and press Enter from the Unix command line and it will return some help text.
   
   Here is a sample of 2 executable files, one for Oracle and one for DB2. Notice the placement of the quotation marks and the direction of the slash “\” character:
   
   ORACLE:
   
   "C:\B18\intel_a\code\bin\catstart" -run "sh C:\B18\intel_a\code\command\Upgrade518NT_Vault.sh
-DBVendor ORACLE -DBName BOLODB -DBAdmHome C:\ora102 -DBAID vpm2adm -TbsName ENOTBS -IdxTbsName ENOTBS –tmp C:\migration\R18"
   
   DB2:
   
   "C:\B18D01\intel_a\code\bin\catstart" -run "sh C:\B18\intel_a\code\command\Upgrade518NT_Vault.sh
-DBVendor DB2 -DBName DB17 -DBAdmHome C:\DB2 -DBAID lcaadm -TbsName ENOTBS
-IdxTbsName ENOTBS -tmp C:\migration\R18"
8. chmod 700 vault.bat (where vault.bat is the command file you created in #6 above) You must give the full rights to execute this file to the ENOVIA Administrator ID which will run the upgrade shell using chgrp/chmod UNIX commands (the user identified above in Step #4).
9. Execute the vault.bat script from command line (For example: .\vault.bat or ./vault.bat ). You will be prompted to enter the password for the DBAID. This password will appear on the screen when you type it, so you must take steps to safeguard the privacy of this password.
10. Informational status messages will appear. At the end of the script a message will appear clearly indicating the outcome of all the steps. Note that one of the steps (when running with Oracle database) will pause at a step that attempts to connect to the database. It advises that if this step does not complete in less than 2 minutes, you should interrupt it and diagnose the reason for the failure of Oracle connections. If this connection failure (or hung condition) occurs, the best way to diagnose the problem is to attempt to connect to Oracle while running as the same userid that was executing the migration, using a command line like this:
    
    sqlplus DBAID/Password@DATABASE
    
    This should return an error that your database administrator can diagnose. Common causes for failure include:
    • Environment failure – not having the ORACLE_HOME value set properly or the PATH does not include $ORACLE_HOME/bin
    • Wrong database name
    • Wrong user-ID or wrong password
    • Oracle listener not running
    • tnsnames.ora file not containing the DATABASE name
    • database not started (use the Oracle startup command)
    • incorrect database admin home path on the migration script command line

    Once the database connection issues are resolved, you can restart the script from the beginning.

11. In case of failure, go to the directory you specified for the -tmp parameter and ensure that all *518* files are preserved. Some of them will be needed by Support to determine the cause and solution to the problem. Move these files to a safe location before running the program again. The script is completely restartable. If it fails for any reason, you can relaunch it without any actions needed to clean up.
12. Below is some sample output showing the results of a successful run of Upgrade518NT_Vault.sh

Now working on tables owned by these Users:
EV5ADM5
Now working on EV5ADM5...
Checking db2 results...
Number of DB2 errors found was: 0
Successfully completed update of DBNAME EV5ADM5 tables.
Status of R17->R18 Vault Migration = SUCCESS
13. You can verify the results by looking in the directory you designated in the –tmp option and viewing the file: Upgrade518NT_Vault_internal.log This file has a log of the actions that were taken on your database.
14. Vault database migration should take less than 5 minutes. If you find that the process is running longer than this, most likely something is wrong. See the tips above about what to do if the process gets hung.

ENOVIA UNIX Vault Database Migration From V5R17 To V5R18

Introduction

These instructions apply only to migrating the Vault database. This process is required for successful migration from R17 to R18. However, you must also run the standard ENOVIA V5 VPM migration separately in order to achieve a complete migration from R17 to R18.

Remember that Vault data may be contained in the regular ENOVIA V5 VPM database (the same one that contains all the production data) or it may be in a separate database, or both. You will need to run this migration once for each database that contains Vault data. If you are uncertain about the location of your vault data, you should determine the names of all the databases that contain vault data before starting this Vault Migration script. You can only run this migration script on one database at a time. If you have multiple Vault databases, you will have to run the Vault migration multiple times.

These instructions assume you have completed the standard ENOVIA V5 VPM database migration. If you have not completed it, please stop and run the standard migration first.

These instructions do not cover migration of a Windows database. This is covered in a separate document.

These instructions do not cover migration of the Vault environment. This is covered in a separate document. You must change the ENOVIA V5 VPM environment in R18 to be able to use the R17 vault files. You must perform both the Vault environment changes and the Vault Database Migration in order to access the same vault information in R18 that you were using in R17.

Vault Migration Instructions:

1. MAKE AN OFFLINE BACKUP OF ALL VAULT DATABASES and copy them to tape before starting any migration.
2. Ensure that you are migrating directly from V5R17 to V5R18. These procedures do not support any other releases or migration effort. Do not attempt to use any other releases of ENOVIA V5 VPM with these instructions. Also ensure that your V5R18 Vault path points to the same path as your V5R17 Vault.
3. Ensure that you have a working V5R17 installation, including a completely functional Oracle or DB2 database that conforms to the required level of Oracle or DB2 software and is up and running before beginning migration. There should be no users connected to ENOVIA LCA or the database at the time of migration.
4. Logon to the ENOVIA LCA product server with the ENOVIA administrator ID that you defined during your enoviadbsetup. This will be the same administrator ID that you used to run the regular database migration. DO NOT attempt to run the migration as root.
5. cd to the code/command directory under your R18 product install path. This path will appear something like one of these:
   
~/aix_a/code/command
~/solaris_a/code/command
~/hp_b/code/command
   
   under the directory where you installed the product.
6. Create (for example, using the vi editor) a command file (e.g. vault.sh) containing all the parameters you will need to run the migration script, starting the command with the ./catstart –run prefix. The parameters should all wrap continuously as one line; there should be no carriage return. If it does not exceed the operating system limit for the length of a line, you could also type these commands directly onto a command line instead of using a command file.
   
   The parameters are:
   
   DBVendor : ORACLE or DB2
   DBName : Database name
   DBAdmHome : Database administrator home directory (for userid that created the database in Oracle or DB2)
   DBAID : Database administrator ID (a user-id that has DBA permissions; may be different from the ID that owns the tables)
   IdxTbsName : Tablespace name for indexes inside the database
   TbsName : Tablespace name for tables inside the database (can be the same as IdxTbsName)
   
   For command line help with this script, simply type Upgrade518_Vault.sh -h and press Enter from the Unix command line and it will return some help text.
   
   Here is a sample of 2 executable files, one for Oracle and one for DB2:
   
   ORACLE:
   
   /installpath/R18/aix_a/code/command/catstart -run "Upgrade518_Vault.sh -DBVendor ORACLE -DBName ORA1718 -DBAdmHome /oracle/app/oracle/product/9.2.0 -DBAID dbausr -IdxTbsName ENOIDX -TbsName ENOTBS -tmp /tmp/mig"

   DB2:
   
   ./catstart -run "Upgrade518_Vault.sh -DBVendor DB2 -DBName DB1718 -DBAdmHome /home/db2adm -DBAID dbausr -IdxTbsName ENOTBS -TbsName ENOTBS -tmp /tmp/vaultmig"
7. chmod 700 vault.sh (where vault.sh is the command file you created in #6 above) You must give the full rights to execute this file to the ENOVIA Administrator ID which will run the upgrade shell using chgrp/chmod UNIX commands (the user identified above in Step #4).
8. Execute the vault.sh script from Unix command line (For example: ./vault.sh ). You will be prompted to enter the password for the DBAID. This password will not appear on the screen when you type it.
9. Informational status messages will appear. At the end of the script a message will appear clearly indicating the outcome of all the steps. Note that one of the steps (when running with Oracle database) will pause at a step that attempts to connect to the database. It advises that if this step does not complete in less than 2 minutes, you should press the Control-D buttons on your keyboard to interrupt it and diagnose the reason for the failure of Oracle connections. If this connection failure (or hung condition) occurs, the best way to diagnose the problem is to attempt to connect to Oracle on your Unix command line while running as the same userid that was executing the migration, using a command line like this:
   
   sqlplus DBAID/Password@DATABASE
   
   This should return an error that your database administrator can diagnose. Common causes for failure include:
   • Environment failure – not having the ORACLE_HOME value set properly or the PATH does not include $ORACLE_HOME/bin
   • Wrong database name
   • Wrong user-ID or wrong password
   • Oracle listener not running
   • tnsnames.ora file not containing the DATABASE name
   • database not started (use the Oracle startup command)
   • incorrect database admin home path on the migration script command line

   Once the database connection issues are resolved, you can restart the script from the beginning.

10. In case of failure, cd to the directory you specified for the -tmp parameter and ensure that all *518* files are preserved. Some of them will be needed by Support to determine the cause and solution to the problem. Move these files to a safe location before running the program again. The script is completely restartable. If it fails for any reason, you can relaunch it without any actions needed to clean-up.
11. Below is some sample output showing the results of a successful run of Upgrade518_Vault.sh

Now working on tables owned by these Users:
EV5ADM5
Now working on EV5ADM5...
Checking db2 results...
Number of DB2 errors found was: 0
Successfully completed update of DBNAME EV5ADM5 tables.
Status of R17->R18 Vault Migration = SUCCESS
12. You can verify the results by looking in the directory you designated in the –tmp option and viewing the file: Upgrade518_Vault_internal.log This file has a log of the actions that were taken on your database.
13. Vault database migration should take less than 5 minutes. If you find that the process is running longer than this, most likely something is wrong. See the tips above about what to do if the process gets hung.