1. Installing and Configuring Oracle Enterprise Data Quality
  2. Upgrading Enterprise Data Quality

9 Upgrading Enterprise Data Quality

You can upgrade Enterprise Data Quality 12c (12.2.1.4.0) to 14c (14.1.2.0.0).

Note:

Read Planning an Upgrade of Oracle Fusion Middleware for additional guidelines for preparing to upgrade to Oracle Fusion Middleware 14c (14.1.2.0.0).

Introduction to Upgrading Enterprise Data Quality (EDQ) to 14c (14.1.2.0.0)

Before you begin, review all introductory information to understand the standard upgrade topologies and upgrade paths for Enterprise Data Quality 14c (14.1.2.0.0).

The upgrade procedures in this guide explain how to upgrade an existing Enterprise Data Quality 12c (12.2.1.4) domain to Oracle Fusion Middleware 14c (14.1.2.0.0). If your domain contains other components that also need to be upgraded, links to supporting documentation are provided.

Note:

For general information about Fusion Middleware upgrade planning and other upgrade concepts and resources, see Planning an Upgrade of Oracle Fusion Middleware.

The following topics describe the concepts related to upgrading Enterprise Data Quality EDQ:

Pre-Upgrade Requirements

Before you begin to upgrade Enterprise Data Quality 14c (14.1.2.0.0), you may need to perform the following tasks:

Note:

Before you start the upgrade, make sure that you have reviewed the Oracle Fusion Middleware Upgrade Planning Roadmap.

Depending on your existing 12c (12.2.1.4.0) configuration, you may need to perform some additional tasks before starting the upgrade.

Converting the Case Management Schema to use Oracle Text

If you are using EDQ Case Management, and you have high data volumes and alerts, you may wish to perform some or all these steps and test functionality, before proceeding to a full upgrade of EDQ to version 14c (14.1.2.0.0).

If migration to Oracle text has been performed already, the migration should be a no-op, but in this case it is important to check that indexes have the correct names - the migration script checks for index by name and if the index already exists with a different name then the script will try to recreate the index and this will fail.

Caution: The migration can take a significant time if it includes a large number of cases and alerts. You may wish to perform some of the steps before the standard upgrade process.

The following steps can all be done before the migration and tested on an existing system. You can perform the full conversion to Oracle text first and test the result before upgrading to 14c (14.1.2.0.0).
  • Conversion of attachment LONG_RAW to BLOB
  • Conversion of supplementary data LONG_RAW to BLOB
  • Population of the JSON column

Note:

Before you begin the migration, note that the EDQ configuration schema user must have the CTXAPP role and the CREATE ANY JOB system privilege. If the migration is performed using the FMW upgrade assistant, then this is handled automatically. If the migration is performed manually, using the migration.jar tool, the role and privilege must be added to the user before running the migration. The script checks the user to ensure that these are present.

  1. Convert the attachment data column from LONG RAW to BLOB.

    Case management attachment data is stored in the ATTACHMENT_BINARY column of the DN_ATTACHMENT table. In 12.2.1.4.0 and earlier this column was created as LONG RAW. The migration process converts the column to BLOB by using this SQL:
    ALTER TABLE dn_attachment MODIFY (attachment_binary BLOB);

    After conversion, indexes on the table become invalid and each index is rebuilt with:

    ALTER INDEX xname REBUILD ONLINE;

    The full process is performed using this script, written using the internal EDQ JDBC simple scripting language:

    
\if oracle
  \if count('user_tab_columns', "table_name = 'DN_ATTACHMENT' and COLUMN_NAME = 'ATTACHMENT_BINARY' and DATA_TYPE = 'LONG RAW'") > 0
 
    \message ++ Converting dn_attachment attachment_binary column to BLOB
    ALTER TABLE dn_attachment MODIFY (attachment_binary BLOB);
 
    -- rebuild indexes
 
    \set rs = select("SELECT INDEX_NAME FROM USER_INDEXES WHERE TABLE_NAME = 'DN_ATTACHMENT' AND INDEX_TYPE = 'NORMAL'")
 
    \while rs -> next()
      \set xname = rs -> getString("INDEX_NAME")
      \print '++ Rebuilding index ' || xname
      ALTER INDEX ${xname} REBUILD ONLINE;
    \done   
 
  \else
    \message -- dn_supplementarydata the_data column does not need converting
  \fi
\fi

    Note:

    To avoid long execution times in the migration process, this conversion can be performed and tested before the upgrade. The existing 12.2.1.4.x will function without issues if the column has already been converted. If this is done it is important that table indexes are rebuilt as above, to avoid serious performance issues.

  2. Drop obsolete indexes.

    In 12.2.1.4.x case management tables have indexes used to improve the performance of the Lucene indexing process. Lucene has been removed in 14c (14.1.2.0.0) and these indexes are no longer required. The SQL used to drop the indexes is: 

    ALTER TABLE dn_case DISABLE CONSTRAINT pk_dn_case; 
DROP INDEX idx_dn_case_indl;
ALTER TABLE dn_case ENABLE CONSTRAINT pk_dn_case;
DROP INDEX idx_dn_case_indexed;
DROP INDEX idx_dn_casecomment_ind;
DROP INDEX idx_dn_casehistory_ind;
DROP INDEX idx_dn_casetrans_ind;
DROP INDEX idx_dn_supplementarydata2;

    In each case the DROP is executed only if the index exists.

  3. Create new indexes.

    New indexes are created to improve the performance of SQL case management filters. The following SQL is used:
    CREATE INDEX idx_dn_case_permission ON dn_case(permission);
CREATE INDEX idx_comment_cid ON dn_casecomment(case_id);
CREATE INDEX idx_comment_del ON dn_casecomment(deleted_flag);

    In each case the CREATE is not performed if an index with the same name exists already. If conversion to Oracle text has already been performed, it is important that existing indexes have the names shown here.

  4. Convert supplementary data column from LONG RAW to BLOB.

    Case management source data is stored in the THE_DATA column of the DN_SUPPLEMENTARYDATA table. In 12.2.1.4.0 and earlier this column was created as LONG RAW. The migration process converts the column to BLOB by using this SQL: 

    ALTER TABLE dn_supplementarydata MODIFY (the_data BLOB);
    After conversion, indexes on the table become invalid and each index is rebuilt with:
    ALTER INDEX xname REBUILD ONLINE;

    The full process is performed using this script, written using the internal EDQ JDBC simple scripting language:

    \if oracle
  \if count('user_tab_columns', "table_name = 'DN_SUPPLEMENTARYDATA' and COLUMN_NAME = 'THE_DATA' and DATA_TYPE = 'LONG RAW'") > 0
 
    \message ++ Converting dn_supplementarydata the_data column to BLOB
    ALTER TABLE dn_supplementarydata MODIFY (the_data BLOB);
 
    -- rebuild indexes
 
    \set rs = select("SELECT INDEX_NAME FROM USER_INDEXES WHERE TABLE_NAME = 'DN_SUPPLEMENTARYDATA' AND INDEX_TYPE = 'NORMAL'")
 
    \while rs -> next()
      \set xname = rs -> getString("INDEX_NAME")
      \print '++ Rebuilding index ' || xname
      ALTER INDEX ${xname} REBUILD ONLINE;
    \done   
 
  \else
    \message -- dn_supplementarydata the_data column does not need converting
  \fi
\fi

    Note:

    To avoid long execution times in the migration process, the conversion can be performed and tested before the upgrade. 12.2.1.4.x will function without issues if the column has already been converted. If this is done it is important that table indexes are rebuilt as above, to avoid serious performance issues in the later JSON population step.

  5. Add JSON column to supplementary data table.

    Source data filters use Oracle text predicates on a JSON array stored in the a column naned JSON in the DN_SUPPLEMENTARYDATA table. This step adds the column to the table. If conversion to Oracle text has already been performed, the column is not added and the later JSON population step is not performed. This SQL is used: 

    ALTER TABLE dn_supplementarydata ADD json BLOB CONSTRAINT jcheck CHECK (json IS JSON);

  6. Create Oracle text support objects.

    Oracle CTX object are created for use in the text indexes. This step is not performed if the DN_TEXTPPREF preference already exists so nothing will be performed here if conversion to Oracle text has already been done. This SQL is used: 

    BEGIN
  CTX_DDL.create_preference('dn_textpref', 'BASIC_LEXER');
  CTX_DDL.create_stoplist('dn_textstop', 'BASIC_STOPLIST');
  CTX_DDL.create_preference('dn_wordlist', 'BASIC_WORDLIST'); 
  CTX_DDL.set_attribute('dn_wordlist', 'PREFIX_INDEX', 'TRUE');
  CTX_DDL.set_attribute('dn_wordlist', 'PREFIX_MAX_LENGTH', '3');
END;

    If you with to tune any of the preferences, you can modify this SQL and execute it before performing the migration process.

  7. Create Oracle text indexes.

    Text indexes are created to allow free-text searching on case key, description and comment strings, and a JSON index is created to support source data searches. The following SQL is used:

    CREATE INDEX dn_case_key_text ON dn_case(key_label)           
  INDEXTYPE IS CTXSYS.CONTEXT
  PARAMETERS('sync (every "freq=secondly;interval=20") lexer dn_textpref stoplist dn_textstop wordlist dn_wordlist');

CREATE INDEX dn_case_desc_text ON dn_case(description)
  INDEXTYPE IS CTXSYS.CONTEXT
  PARAMETERS('sync (every "freq=secondly;interval=20") lexer dn_textpref stoplist dn_textstop wordlist dn_wordlist');


CREATE INDEX dn_casecomment_text ON dn_casecomment(case_comment)
  INDEXTYPE IS CTXSYS.CONTEXT
  PARAMETERS('sync (every "freq=secondly;interval=20") lexer dn_textpref stoplist dn_textstop wordlist dn_wordlist');

CREATE SEARCH INDEX dn_supp_json ON ${dn_supplementarydata} (json) FOR JSON
  PARAMETERS('sync (every "freq=secondly;interval=20") wordlist dn_wordlist memory 1g');

    In each case the CREATE is not performed if an index with the same name already exists. If conversion to Oracle text has already been performed, it is important that existing indexes have the names shown here.

    Note:

    The memory 1g clause in the JSON index parameters increases the memory used to create the index, significantly reducing the fragmentation level of the populated index. If the database has limited memory available, this setting can be reduced.

  8. Drop DN_LUCENEX8 table.

    The DN_LUCENEX8 table was used to store Lucene index files in a clustered environment. The table is not used in 14.1.2.0.0. 

    DROP TABLE dn_lucenex8 PURGE;

  9. Populate JSON column in supplementary data table.

    If the JSON column was added to DN_SUPPLEMENTARYDATA in step 5, a conversion tool is used to populate the column in existing records. This process can take several hours for large volumes. If you wish to run the conversion outside of the standard migration step you can add the JSON column before the migration and then run the conversion later. Conversion performance will be improved if the sdjson tool is run on the database host, to reduce network round-trips.

    To run the conversion manually, use the sdjson.jar tool shipped with EDQ:
    $ java -jar sdjson.jar oracle:#service@HOST:PORT/USER/PW

Upgrading from 12c (12.2.1.4.0) to 14.1.2.0.0

Upgrading from an installation of EDQ 14.1.2.0.0 that uses the Oracle database and the WebLogic application server as its platform to EDQ 14.1.2.0.0 is essentially a two-part process:

Part 1: Perform a Partial Installation of EDQ 14.1.2.0.0

To perform a partial installation:

  1. Ensure that your environment satisfies all EDQ 14.1.2.0.0 System Requirements, as outlined in Supported Platforms and Component Versions, and upgrade your environment, if necessary.

  2. Download EDQ 14.1.2.0.0, as described in Downloading EDQ.

  3. Download the Fusion Middleware Infrastructure release 14.1.2.0.0.

    Note:

    The Oracle Fusion Middleware Infrastructure that you used to support your 12.2.1.4.0 release of EDQ will not support your new release of EDQ. Therefore, unless, you have already installed the 14.1.2.0.0 release of the Oracle Fusion Middleware Infrastructure for some other purpose, you will have to download it now.

  4. If your environment's current Java Development Kit does not support EDQ 14.1.2.0.0, install a supported Java Development Kit, as described in Installing a Java Development Kit to Support EDQ.

  5. If your environment's current Oracle Fusion Middleware Infrastructure does not support EDQ 14.1.2.0.0, install Oracle Fusion Middleware Infrastructure 14c (14.1.2.0.0), as described in Installing Oracle Fusion Middleware Infrastructure (includes Oracle WebLogic Server).

    Note:

    The new release of the Fusion Middleware Infrastructure will have to be installed in a different Fusion Middleware Home to your old release.

  6. If your environment's current Oracle Database does not support EDQ 14.1.2.0.0, upgrade the Oracle Database to a supported release.

  7. Install Enterprise Data Quality 14.1.2.0.0 assets, as described in Installing Enterprise Data Quality, ensuring that you install EDQ in your new Fusion Middleware Infrastructure's Fusion Middleware Home. This step entails installing the Oracle Fusion Middleware EDQ distribution. This is usually downloaded as a .zip file that contains a single file with a name similar to fmw_14.1.2.0.0_edq.jar. Running this .jar file invokes the Oracle Universal Installer. You do not need to configure or extend a WebLogic domain now, since you will upgrade the WebLogic domain using the Reconfiguration Wizard at a later stage.

    Note:

    This step places elements of Enterprise Data Quality in your environment's Fusion Middleware Home location. Some of these will be used later in the installation process. However, you will not have a working EDQ environment at this stage.

Part 2: Upgrade Your 12c (12.2.1.4.0) EDQ Environment

Before you upgrade to the 14c (14.1.2.0.0) EDQ Environment, here are a few considerations:

  • When upgrading EDQ instances that are configured for high availability:

    Enterprise Data Quality 14c (14.1.2.0.0) can be enabled for high availability by configuring several WebLogic Managed Servers within the same WebLogic Cluster.

    In EDQ 12.2.1.4.0, configuration for High Availability was simplified. All the WebLogic managed servers in a cluster can share the same database repository. In other words, only one pair of Config and Results datasources is required and all the WebLogic managed servers in a cluster can share the same base and local config directories.

    Oracle recommends that when you upgrade an instance of EDQ 12.2.1.4.0 to 14c (14.1.2.0.0) that is configured for high availability, you change its configuration to take advantage of the simplified approach to High Availability. To do this, perform the following tasks:

    • Upgrade only one database repository (in other words, only one pair of Config and Results schemas) using the Upgrade Assistant.

    • Run the Oracle Fusion Middleware Reconfiguration Wizard a single time, supplying the connection details of the database repository that you upgraded. As you run the Wizard, on the Advanced Options screen, ensure that you select the Managed Servers, Clusters and Coherence option, and then, referring to the EDQ High Availability Guide for release 14c (14.1.2.0.0), configure your upgraded EDQ instance for High Availability using the new, simplified architecture.

    • Ensure that all your WebLogic Managed Server's server parameters, including, its 'startup arguments' or 'Java options', are configured to point towards the same base and local config directories.

  • It is also possible to maintain the existing high availability configuration after an upgrade, by continuing to use multiple schemas and config areas. To do this:

    • Run the Upgrade Assistant separately against each pair of Config and Results schemas.

    • Disable coherence by setting coherence.clustering = false in the director.properties file.

To start the upgrade process:

  1. Back up your old EDQ environment.

    Before you begin, Oracle recommends that you make a complete backup of your old EDQ environment, including your EDQ domain.

  2. Stop the WebLogic Server Administration Server and all managed servers.

  3. Start the Upgrade Assistant to upgrade your EDQCONFIG (configuration), EDQRESULTS (results), EDQSTAGING (staging) schemas, as well as the OPSS, IAU and STB schemas in the EDQ repository database.

    1. Go to the following directory, where 14.1.2.0.0_FMW_HOME is the version 14.1.2.0.0 Oracle home directory:

      UNIX:

      14.1.2.0.0_FMW_HOME/oracle_common/upgrade/bin

      Windows:

      14.1.2.0.0_FMW_HOME\oracle_common\upgrade\bin

    2. Run the following program:

      Linux or UNIX:

      ./ua

      Windows:

      ua.bat

  4. At the Welcome screen, Review Important Reminders before Proceeding. The Welcome screen contains reminders to consider before proceeding with your upgrade. Make sure you read these and verify that you are ready to proceed. For assistance or more information on any screen, click Help. Otherwise, click Next.

  5. Select the type of upgrade and then select All Schemas Used by a Domain option. In the Domain Directory field, select your old EDQ environment's domain directory (this is likely to be similar to /OLD_FMW_HOME/user_projects/domains/edq_domain). Click Next.

  6. The Component List screen will display a list of the components (or in other words, schemas) to be upgraded in your old EDQ environment's domain. The following components will be listed:

    • Oracle Enterprise Data Quality Results

    • Oracle Audit Services

    • Oracle Platform Security Services

    • Common Infrastructure Services

    • Oracle Enterprise Data Quality Configuration

    Select the components and click Next.

  7. In the Prerequisites screen, verify that you have met the prerequisites, and provided that you have, check the relevant boxes. Note that the Upgrade Assistant will not verify that the prerequisites have been met. Click Next.

  8. Specify Database and Schema Credentials:

    1. The EDQ Results schema, IAU, OPSS, STB, and EDQ Configuration schema screens are displayed in succession.

    2. On the first screen, specify connection details for the database that contains the EDQ Results (EDQRESULTS) schema, and then click Connect. You are then prompted for the password for the schema user.

    3. The remaining screens are automatically populated with the database connection and schema credentials that you supplied on the EDQ Results Schema screen. If these entries are not correct for any schema, change the entries and ensure that a database connection is made.

  9. Complete the upgrade validation. On the Examine screen, the Upgrade Assistant performs a series of validations before upgrading the selected components. Ensure that all validations have succeeded.

  10. Initiate the Upgrade. Click Upgrade on the Upgrade Summary screen to initiate the upgrade. The Upgrade Progress screens shows information about the progress of the upgrade, and the Upgrade Success screen summarizes the upgrade.

  11. Reconfigure the EDQ Domain. In this step you will run the Oracle Fusion Middleware Reconfiguration wizard to complete the upgrade of your WebLogic Server domain environment.

  12. Check that the Staging Mode is set to Nostage, by performing the following steps:

    1. Log in to the WebLogic Remote console from any web browser.

    2. In the left pane, expand Environment and then click Servers. The Summary of Servers screen will be displayed.

    3. In the Summary of Servers screen, click your EDQ Managed WebLogic Server (for example: edq_server1).

    4. Select the Configuration tab, then the Deployment tab.

    5. From the Staging Mode menu, ensure that select Nostage is selected, and, if it is not, select it. Do not change any other server settings.

    6. Click Save.

  13. Stop Node Manager:

    1. If the Node Manager was not already running, and you started it using the command above, then stop it by closing the command shell from which it is running.

    2. If Node Manager was already running (for example, because it was already running as a service in your environment), then stop it using the appropriate means (for example, stop the Node Manager service).

  14. Start the Reconfiguration Wizard to upgrade the EDQ domain:

    1. Go to the following directory, where 14.1.2.0.0_FMW_HOME is the version 14c (14.1.2.0.0) Oracle home directory:

      Windows:

      14.1.2.0.0_FMW_HOME\oracle_common\common\bin

      UNIX:

      14.1.2.0.0_FMW_HOME/oracle_common/common/bin

    2. Start the domain reconfiguration wizard.

      Windows:

      reconfig.cmd -log=log_file

      UNIX:

      ./reconfig.sh -log=log_file

  15. Specify the full path and file name in place of log_file. Creating a log file can be helpful if you need to troubleshoot the reconfiguration process.

    Note:

    If the following error message is displayed, it indicates that the default cache directory is not valid:

    *sys-package-mgr*: can't create package cache dir

    You can change the cache directory by setting the environment variable CONFIG_JVM_ARGS. For example:

    CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

  16. Specify the domain. On the Select Domain screen, specify the full path to the location of your 12.2.1.4.0 EDQ domain (it is likely to be similar to FMW_HOME/user_projects/domains/edq_domain or FMW_HOME\user_projects\domains\edq_domain). You can also click Browse and use the file manager window to help you select the domain location.

  17. View the Reconfiguration Setup Progress.

    The Reconfiguration Setup Progress displays the reconfiguration progress and verifies whether the base domain that you selected can be reconfigured. The message Core WLS Infrastructure Reconfigured Successfully! indicates that the domain can be reconfigured to the 14.1.2.0.0 domain, and you can click Next to go to the next step. If this message is not returned, the domain cannot be reconfigured to the 14.1.2.0.0 domain. If this happens, check to see if the EDQ version is earlier than version 12c (12.2.1.4.0). If so, then you must first upgrade to EDQ 12c and then upgrade to version 14.1.2.0.0.

  18. Select the Domain Mode and JDK. It is not possible to change the Domain Mode from development to production or vice versa.

    On the Domain Mode and JDK screen, specify the location of the Java Development Kit (JDK) to use in the new EDQ domain. This must be a JDK that conforms to the system requirements of your new EDQ environment. For a list of JDKs that are supported for a specific platform, see Oracle Fusion Middleware Supported System Configurations.

    Note:

    You cannot change the Domain Mode at this stage. Your domain will retain its pre-upgrade domain mode.

  19. Select the Database Configuration Type:

    1. In the Database Configuration Type screen, the RCU Data option should be selected by default. The connection details for your EDQ repository database should be automatically populated, and the schema owner and password for the Common Infrastructure schema (STB) should be displayed. If this information is not automatically populated, or is not correct, make any necessary amendments.

    2. Click Get RCU Configuration. The Reconfiguration Wizard should report that it can connect to the Database Server and that it can retrieve schema data and bind local schema components with the retrieved data. If these steps fail, amend the connection data and click Get RCU Configuration again. Otherwise, click Next.

  20. Check the JDBC Component Schema. On the JDBC Component Schema screen, the schemas associated with your old EDQ domain are listed in the lower half of the screen. If you need to make changes, select the check box next to the data source name and then make the changes.

    Note:

    The correct connection details for the EDQ Staging schema that you created using the Repository Creation Utility in step 5, above, may not be displayed. If they are not, amend them so that they are correct.

  21. Test the JDBC Component Schema. On the JDBC Component Schema Test screen, test the data source connections that were detected. Select the schemas that you want to test and then click Test Selected Connections.

    Note:

    To test a connection, the database to which you are connecting must be running.

  22. Select Optional Advanced Configuration Options to select additional domain options:

    1. To make changes to the Managed Server configuration, select Managed Servers, Clusters and Coherence. For help with any of the options, click the Help button.

    2. To skip making these changes, click Next.

  23. Initiate the Domain Reconfiguration. On the Configuration Summary screen, review the configuration and then click Reconfig to start the reconfiguration process, or click Back to make changes.

  24. Finish the Reconfiguration. Wait for the message that states, Domain Reconfiguration Applied Successfully and then click Next.

    A check mark and the message Oracle WebLogic Server Reconfiguration Succeeded indicate that the reconfiguration was successful. Click Next, and then click Finish to dismiss the Reconfiguration wizard.

  25. Follow the instructions below to start the Upgrade Assistant and upgrade EDQ's domain configuration.

    1. Go to the following directory, where 14.1.2.0.0_FMW_HOME is the version 14c (14.1.2.0.0) Oracle home directory.

      Windows:

      14.1.2.0.0_FMW_HOME\oracle_common\upgrade\bin

      UNIX:

      14.1.2.0.0_FMW_HOME/oracle_common/upgrade/bin

    2. Run the following program:

      Linux or UNIX:

      ./ua

      Windows:

      ua.bat

    3. At the Welcome screen, Review Important Reminders before Proceeding. The Welcome screen contains reminders to consider before proceeding with your upgrade. Make sure you read these and verify that you are ready to proceed. For assistance or more information on any screen, click Help. Otherwise, click Next.

    4. At the Selected Schemas screen, select the All Configurations Used By a Domain option. At this point the name of the screen will change to All Configurations. In the Domain Directory field, select your old EDQ environment's domain directory (this is likely to be similar to /OLD_FMW_HOME/user_projects/domains/edq_domain), and click Next.

    5. At the Component List screen, review the list of components to be upgraded (it should consist of Oracle JRF, System Components Infrastructure, and Oracle Enterprise Data Quality Configuration), and click Next.

    6. At the Prerequisites screen, verify that you have met the prerequisites, and, provided that you have, check the relevant boxes (note that The Upgrade Assistant will not verify that the prerequisites have been met.). Then click Next.

    7. At the Examine screen, the Upgrade Assistant will validate that the components can be upgraded, returning statuses for either upgrade not necessary or succeeded for each of them. When the examination has finished, click Next.

    8. At the Upgrade Summary screen, click Upgrade.

    9. At the Upgrade Progress screen, wait until the upgrade has finished, and then click Next.

    10. At the Upgrade Success screen, click Close.

  26. Apply the Upgrade Changes to the Base Domain, using the following steps:

    1. Start the WebLogic Node Manager for the upgraded EDQ domain.

    2. Start the WebLogic Server Administration Server from the upgraded EDQ domain. If it is running, stop and then restart it.

      Windows:

      DOMAIN_HOME\bin\startWebLogic.cmd

      UNIX:

      DOMAIN_HOME/bin/startWebLogic.sh

    3. Log in to the WebLogic Server Administration Server console from any web browser.

    4. In the Domain Structure list, click Deployments.

    5. Under Deployments, select edq and then click Update.

    6. Click Next.

    7. Click Finish.

    8. To complete the upgrade, start the EDQ managed server.

      Note:

      The startManagedWebLogic.sh script is located in your EDQ WebLogic domain's bin directory. Running this script is one method of starting the EDQ WebLogic Managed Server. The startManagedWebLogic.sh script may be overwritten when the EDQ WebLogic Domain is reconfigured. Therefore, if you customized the script, any customization may have been lost during the upgrade process. This is a particularly important point to note if you embedded EDQ's Server Parameters (in other words, its 'startup arguments' or 'Java options') within this script. Without these, the EDQ Managed Server may not function correctly.

  27. Open a Web Browser, and navigate to your upgraded EDQ environment's Launchpad. Unless you changed any of the default options when installing EDQ, its address would be http://<your-server-name>:8001/edq.

  28. From the Launchpad, open the Director user interface and check to see the version of EDQ to confirm that the version is upgraded. From the menu in Director, click the Help > About option to check the version.

  29. Verify that all your projects have been successfully migrated.

    Note:

    On a correctly upgraded system, you do not need to specify the passwords for any data stores such as Oracle. No additional settings are required to ensure that you do not specify the passwords again.

  30. If any of your processes use Match Review, you will need to run these (or jobs of which they are a part) with intelligent execution turned off before you can access Match Review. You can turn off Intelligent Execution in a job or process's Run Preferences.