 |
Special Notes
R20 GA utility Upgrade520NT_Enovia.sh will support
migration of standard and customized LCA Windows Oracle and DB2
databases for Windows 2003 Professional and Windows 2003 Server. A
separate program (Upgrade520_Enovia.sh ) supports migration
of databases from R19 to R20 on UNIX.
As a prerequisite to the migration on Windows, MKS Toolkit version 7 or
higher must be installed on the machine that hosts the Enovia server. |
|
Scope & Purpose
This documentation allows a user to migrate an existing
ENOVIA V5 VPM V5R19 database
into a database containing structures and data that will support
ENOVIA V5 VPM V5R20 while
maintaining all the user-supplied data that was generated during use of the
product under ENOVIA V5 VPM
V5R19.
A database migrated through this process will be converted from R19 to
R20. The
migration process does NOT create a separate copy of the database, but
instead converts the existing database. Once you have performed this
migration, you cannot use
ENOVIA V5 VPM R19 on this
database without dropping it and restoring a backup image of the database
that was taken while it was still in R19. Attempting to run
ENOVIA V5 VPM V5R19 on the
database after it has been migrated to R20 is
unsupported. |
|
Assumptions
These instructions assume you are migrating directly from V5R19 to V5R20. This
procedure does not support any other releases or migration effort. Do not
attempt to use any other releases of
ENOVIA V5 VPM with these
instructions.
These instructions also assume you have a working V5R19 installation,
including a completely functional Oracle or DB2 database that is up and
running before beginning migration. Oracle or DB2 software should be at a
level supported in the
ENOVIA V5 VPM installation
documentation. There should be no users connected to
ENOVIA V5 VPM
or the database at the time of migration. |
|
Overview
For better documentation, error diagnosis, and restart ability, the R19 to
R20 migration is done in 7 steps that each perform a particular unit of
work on the database. The steps listed below generate their own unique
output log that contains the name of the step embedded in the file name,
located in the directory specified by the –TMP parameter. Thus, if a step
fails for some reason, we can look at the logs that pertain directly to
that step to determine the cause of the failure.
Before the official migration steps begin, we do some introductory
environmental preparation and checking the database availability by
connecting to it successfully. Then we use a function called GETMETAR20LIST,
which gets the list of all the Metadata that is used in R20. This is
a hard-coded list that was obtained from a CD-install of
R20 by
connecting to its database and doing "select schema name from
rdbentitymapping" and then eliminating VPMAdminSchema from the
list. This step does not change anything during migration; it simply loads
the values of some variables that will be needed later.
Then we proceed to the steps of migration as follows:
- DDL - This step is required. Uses R19 and R20
metadata to generate database scripts (DDL) necessary to make the
database structure changes to convert to R20 and
then executes the DDL to make the changes.
Output = Upgrade520.logGENERATEDDL, Upgrade520.logRUNGENDDL,
Upgrade520.logCustoProcessDDLSetup,
Upgrade520.logCustoProcessDDL
- ADMIN - This step is required. Runs AddCustoInAdmin (in a
customized environment) and LoadAdmin (in all environments). These make
changes to the database based on the contents of the VPMAdmin.adm file.
The ADMIN step has a dependency on the DDL step. You cannot run the
ADMIN step without simultaneously running the DDL step during a
migration. If you put DDL on the EXCLUSIONLIST, the ADMIN step running
alone will fail. You must run them both together during the same
execution of the migration script.
Output = Upgrade520.logADMIN
- MASKS - This step is required. Updates P&O
(People & Organizations) data (users, contexts and roles) and default
masks.
Output = Upgrade520.logMASKS
- STATS - This step is optional. Runs “update statistics”
(DB2) or “analyze statistics” (Oracle) on all the
ENOVIA V5 VPM tables in
the database to improve performance of the
ENOVIA V5 VPM product in
the future.
Output = Upgrade520.logSTATS
- GRAPH - This step is required. Updates the default status
graphs.
Output = Upgrade520.logGRAPH
|
 |
Before You Begin
- VERY IMPORTANT: Before starting the migration, make an
offline (cold) backup of your R19 database in the current Oracle or DB2
database environment and copy it off to tape or other offline storage
device.
- Ensure that you are migrating directly from V5R19 to V5R20. 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.
- Ensure that you have a working
V5R20
installation, including a completely functional Oracle or DB2 database
that is up and running before beginning migration.
- Oracle or DB2 software should be at the level required in the
documentation for
ENOVIA V5 VPM in
R20
- There should be no users connected to
ENOVIA V5 VPM or the database
at the time of migration.
- VERY IMPORTANT: Ensure that you have large transaction
logging capability in the database. DDL steps will fail if they
run out of logging during the extensive updates needed for successful
migration. Add transaction logs (DB2) or more table space to the rollback
segments (Oracle) as needed. The size needed depends on the size of your
database. We recommend you increase the logging space normally taken by
your database by 100% before starting migration, and more may be required
depending on your environment. Consult DB2 or Oracle documentation for
instructions on how to make these changes and how to undo them after
migration, if desired.
- If you are using DB2, ensure that the
STMTHEAP parameter
value on your database is set to at least 3500. You can check this by
logging in as the database administrator ID and running:
db2 get db cfg for <databasename> | grep STMT
If it is < 3500, increase it by using the following commands:
db2 update db cfg for <databasename> using STMTHEAP 3500;db2stop
force;
db2start
Consult DB2 documentation for more details about this parameter and how
to modify it.
- If you are using DB2, ensure that the
APPLHEAPSZ
parameter for your database is set to at least 1000 and your
LOCKLIST is set to at least 4000 and MAXLOCKS is set
to 40. Check this by logging in as the database administrator and
running:
db2 get db cfg for <databasename> | grep APPLHEAPSZ
db2 get db cfg for <databasename> | grep LOCKLIST
db2 get db cfg for <databasename> | grep MAXLOCKS
To increase it:
db2 update db cfg for <databasename> using APPLHEAPSZ 1000 LOCKLIST
4000 MAXLOCKS 40;
db2stop force;
db2start
- If using DB2, ensure that
STAT_HEAP_SZ database
configuration parameter is set to at least 9000 during the duration of
the 17 > 18 migration. To increase it:
db2 update db cfg for <databasename> using STAT_HEAP_SZ 9000
db2stop force;
db2start
Consult DB2 documentation for more details about these parameters and how
to modify them.
- If you have created your own Masks, you should save the Mask
information (the old version of the Default Mask + your own Mask) prior
to starting the migration. Refer to CAA-RADE R20
documentation: Migrating Existing ENOVIA Masks / Retrieving Needed Masks
for Merging.
-
IF YOU
HAVE CUSTOMIZED
security processes (from the customized modeler) in People &
Organization: There are some special steps you need to take if you want
to preserve these customizations and migrate them into R20. If you do
not take these steps, your basic P&O functionality will work, but the
customizations you added in R20 will be lost.
-
Exclude the MASKS step from the 19->20
database migration. See the information elsewhere in this document
on how to put MASKS on the
EXCLUSIONLIST
so that it is not executed during the migration.
-
Before migration begins, while the product is still active in R20,
export P&O data using the following commands:
-
cd $INSTALL_PATH/xxx_a/code/command
<-- referring to the installation path and the
aix_a, hp_a, solaris_a
directory where the product is installed
-
./catstart -run "VPMPeopleImport
-export /savepath/PeopleExportFile"
- > where
"/savepath"
is a path where your data will be saved and can be protected
from deletion or alteration until migration is completed.
-
After migration is finished (with the
MASKS step excluded), migrate your existing
customization using
CAA RADE .
See the documentation of CAA-RADE R20 "Migrating an Existing
Customization" for complete information. Be sure to include your
customized security processes in these updates.
Before Migration Begins: Ensure that you have a good
EnvName.txt file in your Install-Path/intel_a
directory. For example, if your install path is C:\Program
Files\Dassault Systemes\R19 , you will have a path under this
directory with the name of your operating system (like intel_a )
in it. Inside this directory, there should be a file named
EnvName.txt that contains the name of the
ENOVIA V5 VPM level you are
using. For example, the text inside the file will look something like
this:
ENOVIA_V5_VPM.V5R20.B20
Ensure that this file exists in both R19 and R20, that
it is named EnvName.txt , and that it contains the correct
name for the ENOVIA V5 VPM
environment that you are migrating at both levels.
- Set the
V5MEM environment variable in the .txt
file in your CATEnv directory to 8:
V5MEM=8
If you have a large number of ECOs and this parameter is not set, you
might experience an out-of-memory condition during the CMAFF
step of migration. If you do not want to set this value, you can also
manage memory usage by using the –cmaffsize parameter on the
migration command line as described below.
- Set the new R20 vault to the same Unix path as the LCA V5R19 vault
and follow the Vault documentation instructions for configuring the R20
vault using the R19 vault database and vault files. This must be done
before running the R19-R20 LCA database migration.
After your installation is completed, you must manually
change the information in the properties file to set the V5R20 Vault to
the same path as the old V5R19 Vault. To do this:
- cd to the Java Properties directory ~/<platform>_a/docs/java
(platform=WindowNT)
- edit the ENOVIAVaultServer.properties file
If you have defined your own Vault(s) - other than the one created
during product installation - you must recreate in V5R20 the additional vault(s) using the directions contained in the document “Setting Up the
Vault Server Manually in Windows” after migration is completed. Make the
same Java Properties changes to document these additional vaults as
well.
Important: You must perform this R20 vault configuration and activate
the R20 vault (pointing to the R19 database and R19 vault files paths)
before starting the migration utility documented here.
|
|
Migration Steps
|
|
Step 1: Install
V5R20 pointing to
existing V5R19 database
Follow the CD installation steps for
ENOVIA V5 VPM V5R20 with the
following special instructions:
- Use the same database vendor as
ENOVIA V5 VPM V5R19 used.
- Use the same database name and path as
ENOVIA V5 VPM V5R19.
Use a different Port Number for LCA V5R20 than LCA V5R19 used. Do not
select the Database objects nor the Startup Data options - this is
because we will be using the existing database and data from R19. You
may have to “unselect” these 2 options if they are selected by default. |
|
Step 2: Migrate V5R19 > V5R20
- Logon to the
ENOVIA LCA
product server with the ENOVIA administrator ID. DO NOT attempt to run
the migration as Administrator.
- cd to the code directory under your product install
path. This path appears like one of the following under the directory
where you installed the product.
cd <<R19
Install Path>>\intel_a\code
- 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.
- If you are migrating an Oracle database, the commands below must be
executed in an MKS Korn shell window. If you are migrating a DB2
database, the commands below must be executed in a DB2 Command Window
(Note: NOT a DB2 Command Editor and NOT a DB2 Command Line Processor).
Note that in no case is the Windows migration performed in the normal
Windows “command prompt.”
- The command line for the STANDARD option is as follows: [if
you are running CUSTOMIZED migration, go to Step 5 and DO NOT run Step
4.]
“C:\installpathR20\intel_a\code\bin\catstart” -run "sh
Upgrade520NT_Enovia.sh ... "
The info below goes into the (...) of the command line. Be sure to put
the double quotes (") around the command from the beginning of "sh
Upgrade520NT_Enovia.sh" to the end of the last parameter.
|
|
-DBVendor |
ORACLE or DB2
Example:
-DBVendor ORACLE |
|
-DBName |
The name of your
R20 database
which you are migrating to.
Example:
-DBName LCADB |
|
-DBAID |
The database administrator ID. If you are using DB2 with a
remote database on a separate machine from the
ENOVIA V5 VPM installation,
this parameter is the administrator-ID of the database on the REMOTE
machine where the database was built.
For Oracle users: The DBAID is usually not the ID that
created the database. It may be the ID that owns the tables, and this may
be the same ID as the ENOVIA administrator ID, but it could also be any
userid that has been granted dba permissions by the Oracle administrator.
We recommend that you ensure that the ENOVIA administrator ID has been
granted dba privileges on the Oracle database and use it as the DBA ID for
the purposes of migration. DO NOT use ‘system’ as your DBA or
ENOVIA V5 VPM administrator ID
during migration even if you used this as the DBA id during PLMDBSetup.
This will not work and is not supported.
Examples:
-DBAID db2adm
-DBAID ev5adm [where ev5adm is an Oracle ID that has DBA permissions] |
|
-DBAdmHome |
The home directory of the Oracle ID or the DB2 instance ID.
If you are using DB2 with a remote database on a separate machine from the
ENOVIA V5 VPM installation,
this parameter is the database instance home directory on the LOCAL machine
where you are running the migration, not any directory on the remote
machine where the database was built.
Examples:
-DBAdmHome E:\Program Files\SQLLIB
-DBAdmHome E:\Oracle\ora11 |
|
-TbsName |
The tablespace name used by
ENOVIA LCA for its database
tables.
Example:
-TbsName ENOTBS |
|
-IdxTbsName |
The tablespace name used by
ENOVIA LCA for its indexes
Example:
-IdxTbsName ENOTBS |
|
-TableOwner |
The ID that is owner of database tables - must use all
CAPITAL LETTERS. This parameter is optional. If not specified, default is
AdmUsr.
Example:
-TableOwner VPMADM |
|
-AdmUsr |
The ENOVIA administrative user ID specified in
PLMDBSetup.
Example:
-AdmUsr EV5ADM |
|
-EnvDir |
The full directory path to the CATEnv directory.
Example:
-EnvDir E:\Program Files\Dassault Systemes\B18\CATEnv |
|
-EnvName |
The name of the "ENOVIA V5 VPM~"
file in CATEnv directory without the ".txt".
Example
-EnvName
ENOVIA_V5_VPM.V5R20.B20 |
|
-R19path |
The path above <<R19 Install Path>>\intel_a directory on
your ENOVIA Release 19 configuration (the one that is being migrated in
this exercise.
Example:
-R19path E:\Program Files\Dassault Systemes\B19\intel_a |
|
-TMP |
A Windows path where errors, logs and debugging information
will go; ensure you have permission to write to this directory and 500
megabytes of free space; this parameter is optional
-
it will default to TEMP if not specified.
Example:
-TMP E:\Program Files\Dassault Systemes\tmp |
|
-Step |
-Step ALL runs all steps; or use -step STEPNAME to select a
single step. The migration is not complete until all required steps run
successfully. Note that Step names must be all capital letters.
Example:
-Step ALL |
|
-DBAPwd |
Optional. If you would prefer not to be prompted to type in
the DBA password, you can put it on the command line, but recognize that
this will expose the password to some security risk.
Example:
-DBAPwd password |
|
-AdmPwd |
Optional. If you would prefer not to be prompted to type in
the ENOVIA Admin ID password, you can put it on the command line, but
recognize that this will expose the password to some security risk.
Example:
-AdmPwd password |
|
|
|
|
|
|
|
|
*If the R19 release does not reside on the same
physical machine on which you are installing R20, then you
must make a copy of all the files in the ~code/dictionary
directory or directories in R19 and create a separate directory (or
directories) somewhere on your R20 machine,
and put a copy of all the R19 dictionary files under this directory
(ensuring that the R19 dictionary path has at least read permission to all
users). Then you can use this new directory name(s) as your parameter for
R19dict path. DO NOT overwrite any of the dictionary files that are in the
dictionary directory of your R20
installation. If you must copy R19 dictionary files, put them in a special
directory, such as a new one you create under TEMP.
For example, if you were working on an Windows machine and you copied the
files to a new directory called R19dict under C:\R19Copy ,
you would have the parameter -R19path C:\R19Copy\R19dict\intel_a .
The files should reside under subdirectories beneath R19dict
that follow the format C:\R19Copy\R19dict\intel_a\code\dictionary
such that all your dictionary files that used to be on the old machine
under the R19installpath\intel_a\code\dictionary are now
copied into C:\R19Copy\R19dict\intel_a\code\dictionary on the
new machine. |
|
For command line help with this script, simply
type Upgrade518NT_Enovia.sh , and press Enter from
the UNIX command line and it will return some help text.Here are two
sample executable files, one for Oracle and one for DB2:
DB2
“C:\installpathR20\intel_a\code\bin\catstart” –run “sh
C:\installpathR20\intel_a\code\command\Upgrade520NT_Enovia.sh -DBVendor
DB2 -DBName R19STD -DBAID ev5adm -DBAdmHome E:\Program Files\SQLLIB -TbsName
ENOTBS -IdxTbsName ENOTBS -TableOwner ev5adm -AdmUsr ev5adm -EnvDir
E:\Program Files\Dassault Systemes\B19\CATEnv -EnvName
ENOVIA_V5_VPM.V5R20.B20 -R19path E:\Program Files\Dassault Systemes\B18\intel_a
-TMP E:\Program Files\Dassault Systemes\tmp -Step ALL -DBAPwd ev5adm
-AdmPwd ev5adm”
ORACLE
“C:\installpathR20\intel_a\code\bin\catstart” –run “sh
C:\installpathR20\intel_a\code\command\Upgrade520NT_Enovia.sh -DBVendor
ORACLE -DBName R19STD -DBAID ev5adm -DBAdmHome E:\Oracle\ora11 -TbsName
ENOTBS -IdxTbsName ENOTBS -TableOwner ev5adm -AdmUsr ev5adm -EnvDir
E:\Program Files\Dassault Systemes\B19\CATEnv -EnvName
ENOVIA_V5_VPM.V5R20.B20 -R19path E:\Program Files\Dassault Systemes\B18\intel_a
-TMP D:\Projects\DataMigration\Logs\R19-R20\tmp.std.oracle -Step ALL -DBAPwd
ev5adm -AdmPwd ev5adm”
|
|
- The command line for the CUSTOMIZED option is as follows: [if
you are running STANDARD migration, go back to Step 4 and DO NOT run Step
5.] A Customized database is one that is used in an environment that has
been altered using customizations produced by the RADE tool.
“C:\installpathR20\intel_a\code\bin\catstart” –run “sh
Upgrade520NT_Enovia.sh ...”
The info below goes into the (...)"
"
of the command line. Be sure to put the double quotes ("")
around the command from the beginning of
""sh
Upgrade520NT_Enovia.sh .."
"
to the end of the last parameter.
|
|
-DBVendor |
ORACLE or DB2
Example:
-DBVendor ORACLE |
|
-DBName |
The name of your database.
Example:
-DBName R19CUS |
|
-DBAdmHome |
Home directory of the Oracle ID or the DB2 instance ID. If
you are using DB2 with a remote database on a separate machine from the
ENOVIA V5 VPM installation,
this parameter is the client database instance home directory on the LOCAL
machine where you are running the migration.
Examples:
-DBAdmHome E:\Program Files\SQLLIB
-DBAdmHome E:\Oracle\ora11 |
|
-TbsName |
The tablespace name used by
ENOVIA LCA for its database
tables.
Example:
-TbsName ENOTBS |
|
-IdxTbsName |
The tablespace name used by
ENOVIA LCA for its indexes.
Example:
-IdxTbsName ENOTBS |
|
-TableOwner |
The ID that is owner of database tables - must use all
CAPITAL LETTERS. This parameter is optional. If not specified, default is
AdmUsr.
Example:
-TableOwner VPMADM |
|
-AdmUsr |
The ENOVIA administrative user ID specified in
PLMDBSetup.
Example:
-AdmUsr EV5ADM |
|
-DBAID |
The database administrator ID. If you are using DB2 with a
remote database on a separate machine from the
ENOVIA V5 VPM installation,
this parameter is the administrator-ID of the database on the REMOTE
machine where the database was built.
For Oracle users: The DBAID is usually not the ID that
created the database. It may be the ID that owns the tables, and this may
be the same ID as the ENOVIA administrator ID, but it could also be any
userid that has been granted dba permissions by the Oracle administrator.
We recommend that you ensure that the ENOVIA administrator ID has been
granted dba privileges on the Oracle database and use it as the DBA ID for
the purposes of migration. DO NOT use system as your DBA or
ENOVIA V5 VPM
administrator ID during migration even if you used this as the DBA id
during PLMDBSetup. This will not work and is not supported.
Examples:
-DBAID db2adm
-DBAID ev5adm [where ev5adm is an Oracle ID that has DBA permissions] |
|
-EnvDir |
The full directory path to the CATEnv
directory.
Example:
-EnvDir E:\Program Files\Dassault Systemes\B19\CATEnv |
|
-EnvName |
The name of the
ENOVIA V5 VPM~ file in CATEnv
directory without the .txt
Example:
-EnvName
ENOVIA_V5_VPM.V5R20.B20 |
|
-R19path |
The path to the ~code/dictionary directory on
your ENOVIA V5 VPM Release 19
configuration (the one that is being migrated in this exercise)*.
Example:
-R19path E:\Program Files\Dassault Systemes\B19\intel_a |
|
-R19custo |
Path(s) (concatenated if necessary) to R19
customized dictionary directory(ies)
Example:
-R19custo
D:\Custo1\intel_a\code\dictionary;D:\Custo2\intel_a\code\dictionary |
|
-R19CustoWorkspace |
Path(s) (concatenated if necessary) to the
customized R19 Generator directory(ies).
Example:
-R19CustoWorkspace D:\Custo1\intel_a\reffiles\DBMS\Generator |
|
-TMP |
Optional
-
it will default to TEMP if not specified. A windows path where errors, logs
and debugging information will go; ensure you have permission to write to
this directory and 500 megabytes of free space.
Example:
-TMP D:\tmp |
|
-Step |
-Step ALL runs all steps; or use
-step
STEPNAME to select a single step. The migration is not complete until all
required steps run successfully. Note that Step names must be all capital
letters.
Examples:
-Step ALL
-Step STATS |
|
-DBAPwd |
Optional. If you would prefer not to be
prompted to type in the DBA password, you can put it on the command line,
but recognize that this will expose the password to some security risk.
Example:
-DBAPwd password |
|
-AdmPwd |
Optional. If you would prefer not to be
prompted to type in the ENOVIA Admin ID password, you can put it on the
command line, but recognize that this will expose the password to some
security risk.
Example:
-AdmPwd password |
|
-cmaffsize |
Optional. Number of affected objects to manage
in each iteration within the CMAFF step. Larger values create
faster performance but can use a lot of memory at once (possibly exceeding
the capacity of your computer). Small cmaffsize values can
greatly degrade performance if the database has a lot of affected objects.
Default if not specified = 500.
Acceptable values = 1 – 2000.
Example:
-cmaffsize 1000
If the CMAFF step fails with an out-of-memory error, you
should retry the step using a smaller value for –cmaffsize . |
|
|
|
|
|
|
|
*If the R19 release does not reside on the same
physical machine on which you are installing R20, then you
must make a copy of all the files in the ~code/dictionary directory or
directories in R19 and create a separate directory (or directories)
somewhere on your R20 machine,
and put a copy of all the R19 dictionary files under this directory
(ensuring that the R19 dictionary path has at least "read" permission to
all users). Then you can use this new directory name(s) as your parameter
for R19dict path. DO NOT overwrite any of the dictionary files that are in
the dictionary directory of your R20
installation. If you must copy R19 dictionary files, put them in a special
directory, such as a new one you create under TEMP.
For example, if you were working on an Windows machine and you copied the
files to a new directory called R19dict under C:\R19Copy , you
would have the parameter -R19path C:\R19Copy\R19dict\intel_a .
The files should reside under subdirectories beneath R19dict that follow
the format C:\R19Copy\R19dict\intel_a\code\dictionary such
that all your dictionary files that used to be on the old machine under the
R19installpath\intel_a\code\dictionary are now copied into
C:\R19Copy\R19dict\intel_a\code\dictionary on the new machine. |
|
For command line help with this script, simply
type Upgrade520NT_Enovia.sh and press Enter from
the UNIX command line and it will return some help text. |
|
Here are two sample executable files with
working command lines for CUSTO migration, one for Oracle
and one for DB2:
ORACLE:
“C:\installpathR20\intel_a\code\bin\catstart” –run “sh command\Upgrade520NT_Enovia.sh -DBVendor ORACLE -DBName
R1918CUS -DBAID ev5adm -DBAdmHome E:\Oracle\ora92 -TbsName ENOTBS -IdxTbsName
ENOTBS -TableOwner ev5adm -AdmUsr ev5adm -EnvDir E:\Program Files\Dassault
Systemes\B18\CATEnv -EnvName
ENOVIA_V5_VPM.V5R20.B20
-R19path E:\Program Files\Dassault Systemes\B17\intel_a -TMP E:\Program
Files\Dassault Systemes\tmp -Step ALL -R19custo D:\home\Custos\NAPR19CustoOra\intel_a\code\dictionary
-R19CustoWorkspace D:\home\Custos\NAPR19CustoOra\intel_a\reffiles\DBMS\Generator”
DB2:
“C:\installpathR20\intel_a\code\bin\catstart” –run “sh command\Upgrade518NT_Enovia.sh -DBVendor DB2 -DBName
R1918CUS -DBAID ev5adm -DBAdmHome E:\Program Files\SQLLIB -TbsName ENOTBS -IdxTbsName
ENOTBS -TableOwner ev5adm -AdmUsr ev5adm -EnvDir E:\Program Files\Dassault
Systemes\B18\CATEnv -EnvName
ENOVIA_V5_VPM.V5R20.B20
-R19path E:\Program Files\Dassault Systemes\B17\intel_a -TMP E:\Program
Files\Dassault Systemes\tmp -Step ALL -R19custo
D:\home\Custos\NAPR19CustoDb2\intel_a\code\dictionary -R19CustoWorkspace
D:\home\Custos\NAPR19CustoDb2\intel_a\reffiles\DBMS\Generator -DBAPwd
ev5adm -AdmPwd ev5adm” |
|
SPECIAL NOTE REGARDING THE -Step PARAMETER
The R19 migration has the capability to run the steps of migration in an
"all
but"
fashion -
that is, to run all the steps except the ones that you would like to
exclude. You might want to do this if:
- You do not want to run one of the optional steps
- You have experienced a problem on some steps but the others have
already succeeded. Rather than run the entire migration again, you can
correct the problem and then run with all the succeeded steps excluded.
To run all the steps except for one or more to be excluded, follow these
procedures:
- Create a text file called EXCLUSIONLIST (all capital letters)
under the directory provided in your –TMP parameter.
- List the steps inside this file that you DO NOT want to be
executed during the migration.
For example, you might create a file D:\tmp\EXCLUSIONLIST
that looks like this:
STATS
- Now run the migration with the –Step ALL parameter. It will run
all the steps except the ones you mentioned in the EXCLUSIONLIST.
- Notice that Step names are all capital letters and are all listed
in bold type in the OVERVIEW section of this
document above.
- It is not permitted to run the ADMIN step without running the DDL
step simultaneously, due to dependencies inside ADMIN.
- Recognize that some steps have dependencies on the successful
completion of other steps. If you try to run any individual step out
of order or without completion of its dependencies, the migration
script will stop and report that a dependency has been violated and
will advise you what to do.
- Run the (filename) script from the command prompt. Informational
status messages appear. Some steps will take several minutes, during
which no additional messages will appear.
- If you did not specify the DBAID password on the command line, a
prompt will appear as follows:
Enter password for Database Admin Id (xxxxxx):
where xxxxxx is the userid that you put into your command line as the
Database Administrator. Type the password for this userid. It will be
displayed on the screen.
- If you did not specify the ENOVIA Admin User password on the command
line, a prompt will appear as follows:
Enter password for EV5 Admin User (XXXXXX):
Where XXXXXXX is the userid that you put into your command line as the
ENOVIA Administrator. Type the password for this userid. It will not be
displayed on the screen.
- If running with the -Step ALL parameter, the failure of any critical
steps will abort the script and the other steps will not run. Optional
steps may allow the migration to continue if they fail. If a step fails:
- resolve the error and then rerun any steps that did not execute or
that failed the first time, in the order that they appear in the STATUS
message at the end of the failed execution (also documented in the
OVERVIEW above). This allows you to keep the results of any steps that
succeeded, but requires you to manually run each step for the rest of
the migration until they are all completed or use the -Step ALL with
the EXCLUSIONLIST
- or restore the database and run again with the -Step ALL parameter
after resolving the error. This wipes out all migration done so far and
completely starts over.
- Be patient. Migration of a large database can take several hours. If
the migration appears to be hung',
you can verify progress by opening a second command window and going to
the directory you gave as your TMP directory. Use the command
"ls
-lrt"
and look at the timestamp on the most recent Upgrade520* file. If more
than 1 hour passes with no activity in this directory, it is likely the
migration has stopped.
- If you used something other than CAARADE to customize your
ENOVIA V5 VPM R19
environment, and you have customized a schema, you now need to consult
with the author or maintainer of those customizations to obtain
instructions for migrating these customizations into
ENOVIA LCA R19.
If you have not already done, don’t forget to reconfigure your Vault
in R20 to point to the R19 Vault. You must follow the procedures
documented within the Migrating a Vault Server Manually chapter of R20
LCA documentation. There are no changes needed to the Vault database to
make it compatible with R20; however, you must still follow the steps
needed to point the R20 environment to the R19 vault files.
|
|
Special Notes on Migration of Lifecycles (Graphs)
General instructions for migration of customizations to ENOVIA object
lifecycles:
If you want to remove a lifecycle state for an object type, you should
either:
- ensure that no objects of this type exist in that state, or
- leave the state in the lifecycle graph, with an appropriate
transition to a state in the new lifecycle. In this case, users can
migrate the old data to the new lifecycle states as needed.
You may update the lifecycle either by editing the text of the lifecycle
VGraph file, or by editing the lifecycle in the
ENOVIA VPM Product Editor, then exporting
to a VGraph file and adding any specialized conditions and operations.
If necessary, you may retrieve the old customized lifecycle VGraph from
the old ENOVIA database, but you must do this before you migrate the ENOVIA
database to the new release. |
 |