Upgrade Postprocessing

Once the database has been fully upgraded, run the validate index command to check the current schema and output the latest required database indices. This command is currently supported on Oracle, DB2 and SQL Server:

validate index;

Any missing indices can be added by database administrators. For example, you may see:

*** Missing index: mxSchema_mxId_Index on mxSchema
   Recommended index:
     create index mxSchema_mxId_Index on mxSchema(mxId) nologging
*** Non-standard index: MXATTRTYPE_MXPARENT_INDEX on mxAttrType
*** Missing index: mxSrvLat_mxLattice_Index on mxSrvLat
   Recommended index:
     create index mxSrvLat_mxLattice_Index on mxSrvLat(mxLattice) nologging
*** Non-standard index: MXOTHERADMIN_MXOWNER_INDEX on mxOtherAdmin
*** Non-standard index: LXBO_86305D44_LXPOLICY_INDEX on lxBO_86305d44
*** Non-standard index: LXBO_53B41316_LXPOLICY_INDEX on lxBO_53b41316

A non-standard index may indicate that custom indices have been added and their names do not match the out-of-the-box definitions. It could also suggest that there is an older, no longer recommended index, or an index of the same name as a recommended index, but that is not defined the same. These should be reviewed by the database administrator. The database administrator should add and remove required indices on all vaults.

If you are upgrading from a version prior to V6R2010x and/or will be using VPM products for the first time with this release, you may want to add physical and logical ids to all business objects and relationships with the upgrade physicalid command. If not run, these ids are generated upon request, so VPM integrations won’t fail, but running the command now could improve performance of all VPM operations.

Physical and logical IDs are not required for other collaborative business process products.

This is a time-consuming operation (approximately 30 mins per 10 million objects); however, it can be interrupted (killed) and restarted to pick up from where it left off. The system does not need to be offline when running this operation; you should run it as a background process during non-peak hours.

If you do choose to run this command, you should use a separate tablespace and indexspace for the new MxIdent table. For example:

set system tablespace DBTABLESPACE;
set system indexspace DBINDEXSPACE;
upgrade physicalid;

Starting with V6R2012, the upgrade command creates the mxTNR table to control type/name/revision uniqueness. However, the conversion to the new TNR constraint management is not complete until the upgrade TNR command is also run. This command switches the uniqueness constraints from the vault-specific lxBo tables to the system-wide mxTNR table. The upgrade is split into two commands because upgrade TNR can be time consuming and you may want to manage its execution separately. Tests have shown that upgrade TNR takes approximately 15 minutes for every 10 million objects.

Earlier versions of ENOVIA Live Collaboration (i.e. Matrix) supported the MX_CHECK_DUPLICATE_NAMES environment variable that allowed you to set object type name revision uniqueness to be only within a vault (i.e. different vaults could contain their own version of an object with same type name revision). MX_CHECK_DUPLICATE_NAMES was set to false primarily to improve the performance of create operations, but it also had the side effect of allowing objects of the same type name revision to be created in different vaults. In most cases, this side-effect was undesirable - if any such objects were introduced to the system, they could cause problems with some applications and would have to be cleaned up (renamed) to insure the uniqueness across all vaults. This environment variable is NOT recognized starting in V6R2012, and a new way of handling unique constraints will be delivered in a future release.

To see if there are duplicate objects in your system, you can run:

validate unique TNR;

If you found duplicates but don’t want to allow it, fix the objects (that is, rename so all are unique) before running upgrade TNR. To move all existing unique constraints from the lxBO table to mxTNR table for all the objects in the database use the following command:

upgrade TNR [notglobal] [tablespace DBTABLE] [indexspace DBINDEX];

Only use notglobal if you found duplicate objects in the database and want to allow duplicate TNRs in different vaults. (NOTE: Allowing this may create problems for applications/customizations that are not expecting such duplicate objects).

Include tablespace and indexspace if you want a separate space for the mxTNR table and its indices. This is recommended. It may take an hour or more for upgrade TNR to finish.

We recommend that you run the upgrade TNR command when the system is off-line. It is not necessary to run it at the time of the upgrade, so you can schedule it when convenient.

After an upgrade, you should update the statistics on the database with:

validate level 4