Table of Contents

Search

  1. Preface
  2. Upgrade Overview
  3. Pre-Upgrade Tasks
  4. Database Tasks
  5. Application Server Tasks
  6. Hub Store Upgrade
  7. Hub Server Upgrade (In-place Upgrade)
  8. Process Server Upgrade (In-place Upgrade)
  9. Resource Kit Upgrade (In-place Upgrade)
  10. Post-Upgrade Tasks
  11. Search Configuration Upgrade
  12. Hierarchies Upgrade
  13. ActiveVOS Post-Installation Tasks for the Application Server
  14. ActiveVOS Post-Upgrade Tasks for Business Entity Adapter
  15. ActiveVOS Post-Upgrade Tasks for Subject Areas Adapter
  16. Appendix A: Troubleshooting the Upgrade Process
  17. Appendix B: Frequently Asked Questions
  18. Appendix C: Processing Existing ActiveVOS Tasks
  19. Appendix D: Configuring Metadata Caching

Upgrading from Version 10.1, 10.2, 10.3, or 10.4

Upgrading from Version 10.1, 10.2, 10.3, or 10.4

Appendix A: Troubleshooting the Upgrade Process

Appendix A: Troubleshooting the Upgrade Process

If the upgrade fails or you encounter issues during the upgrade, use the following information to troubleshoot the problem.
The EAR files do not deploy within the permitted time in JBoss environments.
As you increase the number of Operational Reference Stores, the EAR file deployment time increases. If the EAR file deployment time exceeds the permitted deployment time in JBoss environments, the upgrade fails.
To resolve the issue, increase the permitted deployment time to accommodate the EAR file deployment time. The default permitted deployment time is 600 seconds.
  1. Increase the value of the
    deploy.wait.time
    property in the
    build.properties
    file in the following directory:
    <infamdm installation directory>/hub/server/bin
  2. Navigate to the following directory:
    <JBoss installation directory>/standalone/configuration
  3. Configure the following code in the
    standalone-full.xml
    file to increase the timeout value:
    <subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1"> <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" deployment-timeout="1200"/> </subsystem>
The Hub Server upgrade fails.
To resolve the issue, redeploy the EAR file to retry the Hub Server upgrade.
In JBoss environments, if you manually change the configuration of data sources in the
standalone-full.xml
file when JBoss is running, you lose the configuration changes when you run the
patchInstallSetup
script.
  1. Navigate to the following directory:
    <
    MDM Hub installation directory
    >/hub/server
  2. Run the following command to deploy the Hub Server application and apply changes to the application server configuration.
    If you do not have embedded ActiveVOS in your environment, you do not need to include the ActiveVOS user names and passwords in the command.
    On UNIX
    WebLogic
    patchInstallSetup.sh -Dweblogic.password=<WebLogic password> -Ddatabase.password=<MDM Hub Master database password> -Davos.username=<ActiveVOS Console username> -Davos.password=<ActiveVOS Console password> -Davos.jdbc.database.password=<ActiveVOS database password>
    WebSphere with security enabled
    patchInstallSetup.sh -Dwebsphere.password=<WebSphere password> -Ddatabase.password=<MDM Hub Master database password> -Davos.username=<ActiveVOS Console username> -Davos.password=<ActiveVOS Console password> -Davos.jdbc.database.password=<ActiveVOS database password>
    WebSphere with security disabled
    patchInstallSetup.sh -Ddatabase.password=<MDM Hub Master database password> -Davos.username=<ActiveVOS Console username> -Davos.password=<ActiveVOS Console password> -Davos.jdbc.database.password=<ActiveVOS database password>
    JBoss
    patchInstallsetup.sh -Ddatabase.password=<MDM Hub Master database password> -Davos.username=<ActiveVOS Console username> -Davos.password=<ActiveVOS Console password> -Davos.jdbc.database.password=<ActiveVOS database password>
    On UNIX, if you include an exclamation mark (!) character in the password, you must include a backslash before the exclamation mark (!) character. For example, if the password is
    !!cmx!!
    , enter
    \!\!cmx\!\!
    .
    On Windows
    WebLogic
    patchInstallSetup.bat -Dweblogic.password=<WebLogic password> -Ddatabase.password=<MDM Hub Master database password> -Davos.username=<ActiveVOS Console username> -Davos.password=<ActiveVOS Console password> -Davos.jdbc.database.password=<ActiveVOS database password>
    WebSphere with security enabled
    patchInstallSetup.bat -Dwebsphere.password=<WebSphere password> -Ddatabase.password=<MDM Hub Master database password> -Davos.username=<ActiveVOS Console username> -Davos.password=<ActiveVOS Console password> -Davos.jdbc.database.password=<ActiveVOS database password>
    WebSphere with security disabled
    patchInstallSetup.bat -Ddatabase.password=<MDM Hub Master database password> -Davos.username=<ActiveVOS Console username> -Davos.password=<ActiveVOS Console password> -Davos.jdbc.database.password=<ActiveVOS database password>
    JBoss
    patchInstallsetup.bat -Ddatabase.password=<MDM Hub Master database password> -Davos.username=<ActiveVOS Console username> -Davos.password=<ActiveVOS Console password> -Davos.jdbc.database.password=<ActiveVOS database password>
    The ActiveVOS Console credentials are the same credentials as the administrative user in the application server.
    The ActiveVOS database credentials are the same credentials that were used to run the create_bpm script.
The MDM Hub clean upgrade fails.
After an upgrade to version 10.4, when you perform a clean upgrade, but use the existing database, the upgrade fails. The issue occurs because each time you perform a clean upgrade, new public and private key pairs are generated. You cannot use the new key pairs to access the existing database.
To resolve the issue, perform the following steps:
  1. Replace the new public and private key pairs for the Hub Server with the old public and private key pairs.
    The public and private key pairs for the Hub Server are stored in the following directory:
    <
    MDM Hub installation directory
    >/hub/server/resources/certificates
  2. Run the
    postInstallSetup
    script to deploy the Hub Server application and apply the changes to the application server configuration.
    For more information about running the
    postInstallSetup
    script, see the Hub Server Post-Installation Tasks chapter in the
    Multidomain MDM Installation Guide
    .
  3. Replace the new public and private key pairs for the Process Server with the old public and private key pairs.
    The public and private key pairs for the Process Server are stored in the following directory:
    <
    MDM Hub installation directory
    >/hub/cleanse/resources/certificates
  4. Run the
    postInstallSetup
    script to deploy the Process Server application and apply the changes to the application server configuration.
    For more information about running the
    postInstallSetup
    script, see the Process Server Post-Installation Tasks chapter in the
    Multidomain MDM Installation Guide
    .
The Process Server upgrade fails in a WebLogic environment.
When you upgrade the Process Server in a WebLogic environment, the upgrade might fail with the following error:
Unable to start application, deployment error msg: weblogic.management.ManagementException: [Deployer:149196]Rejecting start request for application siperian-mrm-cleanse.ear because stop request is running for the application.
To resolve the issue, use the WebLogic Administrative Console to manually deploy the
siperian-mrm-cleanse.ear
file, and then restart the application server.
The Process Server upgrade fails in a WebSphere environment.
When you upgrade the Process Server in a WebSphere environment, the upgrade might fail. Open the
patchinstallSetup.log
to see the following error:
Failed to load webapp: com/delos/cmx/server/Initialization.getCleanseLoggingConfiguration;loaded from file:/E:/IBM/WAS9053/AppServer/profiles/AppSrv01/installedApps/MDMWSDB2W16001Node02Cell/siperian-mrm-cleanse.ear.ear/lib/siperian-server
To resolve the issue, use the WebSphere Administration Console to manually undeploy the
siperian-mrm-cleanse.ear
file, and then run the
patchInstallSetup
script.
You can find the
patchInstallSetup
script in the following directory:
<MDM Hub installation directory>/hub/cleanse
The Process Server upgrade fails.
To resolve the issue, redeploy the EAR file to retry the Process Server upgrade.
If you manually change the configuration of data sources in the
standalone-full.xml
file when JBoss is running, you lose the configuration changes when you run the
patchInstallSetup
script.
  1. Navigate to the following directory:
    <
    MDM Hub installation directory
    >/hub/cleanse
  2. Run the following command to deploy the Process Server application and apply changes to the application server configuration.
    On UNIX
    WebLogic
    patchInstallSetup.sh -Dweblogic.password=<
    WebLogic password
    >
    WebSphere
    patchInstallSetup.sh -Dwebsphere.password=
    <WebSphere password>
    JBoss
    patchInstallsetup.sh
    On Windows
    WebLogic
    patchInstallSetup.bat -Dweblogic.password=<
    WebLogic password
    >
    WebSphere
    patchInstallSetup.bat -Dwebsphere.password=
    <WebSphere password>
    JBoss
    patchInstallsetup.bat
    On UNIX, if you include an exclamation mark (!) character in the password, you must include a backslash before the exclamation mark (!) character. For example, if the password is
    !!cmx!!
    , enter
    \!\!cmx\!\!
    .
Operational Reference Store upgrade results in ORA-00955 error.
When you upgrade the Operational Reference Store, the upgrade is successful but the following error appears in the
sip_ant
log:
[exec] CREATE SEQUENCE "C_REPOS_ZDT_EVENT_SEQ" MINVALUE 1 MAXVALUE 99999999999999 INCREMENT BY 1 START WITH 1 CACHE 20 NOORDER CYCLE [exec] * [exec] ERROR at line 1: [exec] ORA-00955: name is already used by an existing object [exec]
You can safely ignore the error.
Change list promotion to an empty Operational Reference Store results in ORA-00910 error.
When you promote a change list to an empty Operational Reference Store, if the total length of the match column is greater than 4000, the following error occurs:
ORA-00910: specified length too long for its datatype
To promote a change list to an empty Operational Reference Store, ensure that the match column length that the MDM Hub adds to the external match input table does not exceed 4000. The match column length is the sum of the lengths of all base object columns that are sources of the match column and the number of source columns.
Operational Reference Store upgrade in an Oracle environment results in ORA-20005 error.
If you encounter error ORA-20005 when you run
sip_ant updateorsdatabase
, perform the following steps:
  1. Run the following command to grant the required permissions:
    exec dbms_java.grant_permission(upper('ORS_USER'),'SYS:java.net.SocketPermission','*', 'connect,resolve');
  2. Run the following command to confirm that the Java classes are loaded in Oracle:
    select dbms_java.longname(object_name), status from user_objects where object_type='JAVA CLASS';
  3. If the classes are not loaded, run the following command to reload the classes:
    loadjava -verbose -force -resolve -oracleresolver -user &ors_name/&ors_passwd@&tns_name siperian-cleansecaller.jar loadjava -verbose -force -resolve -oracleresolver -user &ors_name/&ors_passwd@&tns_name siperian-dbutil.jar
The Hub Store upgrade fails.
You cannot rerun the Hub Store upgrade on a partially upgraded schema. If the upgrade fails, restore the database from a full backup, and then rerun the Hub Store upgrade.
If the Hub Store upgrade fails because column names contain reserved words, contact Informatica Global Customer Support for scripts to migrate the data to renamed columns.
After upgrading from a non-English locale, some tables are in English and some are in the language of the locale.
If your Hub Store database environment is set to a non-English locale, you must change the character set to Unicode before you run the upgrade scripts to upgrade the MDM Hub Master Database and Operational Reference Stores. During the upgrade, all table metadata is translated to English with a translation key. If you did not select a Unicode character set, only some tables are translated.
Hub Console fails to launch
Verify that you are using a Java runtime environment (JRE) that is supported for the Hub Console. For system requirements, see the Product Availability Matrix for this version of
Multidomain MDM
on Informatica Network: https://network.informatica.com/community/informatica-network/product-availability-matrices/overview
The Hub Console fails to launch in a JBoss environment
In JBoss environments, if the JBoss application server does not restart, you cannot launch the Hub Console. The MDM Hub generates an error to indicate that the repository layer did not initialize.
To resolve the issue, run the following code in a batch file to restart JBoss:
rmdir C:\<JBoss installation directory>\standalone\tmp /s /q mkdir C:\<JBoss installation directory>\standalone\tmp C:\<JBoss installation directory>\bin\standalone.bat -c standalone-full.xml -b 0.0.0.0
Hub Console fails to launch in a Db2 environment
In an MDM Hub environment with Db2 datasources, the Hub Console fails to launch with the following errors:
SIP-09070: SIP-10318: Couldn't get users due to data access error.
SIP-10324: There was an unexpected exception when attempting to load data object(s). java.lang.NullPointerException
This issue is caused by a mismatch in the case used for the administrative user name in the MDM Hub and in the application server. For example, the MDM Hub has the administrative user DB2ADMIN (uppercase) while the application server has db2admin (lowercase).
To resolve the issue, ensure that the user name in the application server exactly matches the user name in the MDM Hub.
To avoid issues related to case-sensitivity, Informatica recommends using all uppercase letters when defining user names for Db2.
For example, if you are using WebSphere, set the user name in the WebSphere Console.
  1. Open the WebSphere Console.
  2. Navigate to
    Resources > Data sources > siperian-cmx_system-ds > Custom properties
    .
  3. In the User field, type in uppercase:
    DB2ADMIN
  4. In the Password field, type the password for this user.
  5. Click
    Apply
    , and then click
    Save
    .
  6. Restart WebSphere.
  7. Launch the Hub Console and log in.
Changes made in the Provisioning tool cannot be applied in Db2 environments.
In Db2 environments, if the Operational reference Store is large and you apply changes in the Provisioning tool, the following error message appears:
Failed to set user workspace configuration.
To resolve this issue, increase the column length of the user workspace table by running the following Db2 commands on the Operational reference Store:
UPDATE C_REPOS_COLUMN SET DATA_LENGTH = 50000000 WHERE TABLE_NAME = 'C_REPOS_USER_WORKSPACE' AND COLUMN_NAME = 'WORKSPACE_DATA' ALTER TABLE C_REPOS_USER_WORKSPACE ALTER COLUMN WORKSPACE_DATA SET DATA TYPE BLOB(50M) REORG TABLE C_REPOS_USER_WORKSPACE COMMIT
IDD cannot use the legacy Data View to view records that are based on subject areas.
The default page to view records in IDD is the Entity View that is based on business entities.
To use the legacy Data View, set
dataview.enabled
to
true
in the
cmxserver.properties
file.
For more information, see the following How-to article:
Migrating IDD Applications to the Business Entity Data Model
.
IDD fails with the error SIP-BV-11500.
IDD can fail with the following error:
SIP-BV-11500 Fatal Error Operational Reference Store localhost-orcl-MDM_SAMPLE does not have a workflow engine configured. Each Operational Reference Store must have a workflow engine configured for use with the IDD even if workflow will not be used.
To resolve this issue, ensure that the primary workflow adapter is configured.
For more information, see the following KB article: https://kb.informatica.com/solution/23/Pages/55/381456.aspx?myk=381456.
When you validate the metadata, an error states that the object exists in the metadata but not in the database.
When you use the Repository Manager to fix the issue, the following error occurs: ORA-00955 Name is already used by an existing object.
To resolve the issue, ensure that the correct privileges for the proxy role are granted for the tables that encounter the error. Refer to a table that does not encounter the error to get the list of permissions that are required.
On Windows, when match tokens are generated, an error occurs.
The Generate Match Tokens process returns an error that says that the class
ssa.ssaname3.jssan3cl
cannot be initialized.
  1. Verify that the PATH environment variable includes the path to the following directory, which contains the dynamic linked library (DLL) files for SSA-NAME3:
    <MDM installation directory>/hub/cleanse/lib
  2. Verify that Microsoft Visual C++ Redistributable for Visual Studio 2019 is installed on the Process Server that performs search and match for the MDM Hub.
  3. If Microsoft Visual C++ Redistributable for Visual Studio 2019 is installed, use a dependency checker, such as Dependency Walker (depends.exe), to load
    jssan3cl.dll
    and confirm that the Visual C++ Redistributable was successfully applied.
    Visual C++ Redistributable for Visual Studio 2019 requires that Windows Server has operating system patches installed. Check the operating system requirements before installing Visual C++ Redistributable. For example, from a baseline version of Windows Server 2012, you must apply around 100 patches (totalling approximately 2 GB) to the operating system before you can successfully install Visual C++ Redistributable.
After you upgrade in a Microsoft SQL Server environment on a WebLogic application server, you cannot log in to the Hub Console.
A null pointer exception occurs when you log in to the Hub Console.
To resolve the issue, comment out the drop commands, create schema commands, and any role commands in the
xa_install.sql
script located in
<Microsoft SQL Server installation directory>\sqljdbc_4.0\enu\xa
. Run the script, and then restart the application server.
The upgrade component patchInstallSetup fails when you install the Hub Server on a WebSphere Application Server.
To resolve the issue, open the file
<WebSphere profile home>/properties/soap.client.props
and increase
com.ibm.SOAP.requestTimeout
, and then restart the WebSphere server profile. Run
patchInstallSetup.bat
again.
The entity360view.ear file fails to deploy when you upgrade the Hub Server in IBM AIX environments.
To resolve the issue, run the
patchInstallSetup.sh
script.

0 COMMENTS

We’d like to hear from you!