Perform Pre-Upgrade Steps

This page details the actions to take before upgrading Oracle Utilities Analytics Warehouse from version 2.8.0.1.2 to version 2.9.0.0.0.

On this page:

Notes:

  • Customers need to upgrade to the latest supported tech Stack on 2.8.0.1 (for example: OAS 7.0). See section Supported Platforms and Hardware Requirements in the Installation Guide 2.8.0.1 before performing the upgrade activities from 2.8.0.1.2 to 2.9.0.0.0.
  • This upgrade path is only valid for source applications that are certified with both OUAW 2.8.0.1.2 and OUAW 2.9.0.0.0, so Source Application Upgrade is not included in this upgrade path.
  • Before proceeding with the prerequisite steps on the target and the source database servers, ensure you have a rollback plan in case it is necessary to revert the changes.

  1. Ensure that data in the source is in sync with the replication tables.

    Note: The Lag for Chkpt and Time Since Chkpt in both the source and target databases should be 0.

  2. Make sure that the ODI operator logs are available during and after the upgrade.

    Note: This can be ensured by increasing the log retention period to 60 days from the Global Configuration page in Apex.

  3. Make sure the ODI log level is set to maximum in Global Configuration.

    Note: This can be ensured by increasing the ODI log level to 5 or 6 from the Global Configuration page in Apex.

  4. Log in to Oracle Utilities Analytics Warehouse ODI server and start the ODI client.

    Copy
    export JAVA_HOME=<JAVA HOME>
    export PATH=$JAVA_HOME/bin:$PATH
    cd <FMW Home>/odi/studio
    ./odi

  5. Stop BI_RUN_ALL from ODI studio and follow these steps:
    1. Log in to Oracle Data Integrator Studio.
    2. Navigate to Designer > Load plan and Scenarios > Framework > B1_RUN_ALL > Scheduling.
    3. Double-click Global/WLS_AGENT, select Inactive, and save the changes.
    4. On the studio, navigate to the Topology tab.
    5. Right-click OracleDIAgent and select Update Schedule.
  6. Run the following query from the target database server to check if all jobs are complete.

    Copy
    SELECT * FROM mdadm.b1_jobs_vw WHERE  status_flg in ('W','P','R');

    Note: No rows should be returned from the query mentioned above. If any rows are returned, that means jobs are not yet completed. Wait until they complete.

  7. Stop both Oracle Data Integrator admin, and managed servers.

    Copy
    cd <Domain Home>/<odi_domain>/bin
    ./stopManagedWeblogic.sh <ODI_server1>
    ./stopWeblogic.sh

  8. Stop the OAS services:

    Copy
    cd <Domain Home>/<OAS_domain>/bitools/bin
    ./stop.sh

  9. Stop Apex admin and managed servers.

    Copy
    cd <Domain Home>/<apex_domain>/bin
    ./stopManagedWebLogic.sh <apex_server1>
    ./stopWebLogic.sh

  10. Stop the source application. Ensure the database is up and running in both the source and the target.
  11. Stop all EXTRACTS, REPLICATS, MANAGER, JAGENT, and PMSRVR from the source and target GoldenGate.

    Copy
    cd <Goldengate Home>       
    ./ggsci       
    stop *
    stop MANAGER
    stop JAGENT
    stop PMSRVR

Back to Top

GoldenGate Classic Processes Cleanup

Warning: GoldenGate processes cannot be rolled back once these have been cleaned up. Perform the GoldenGate process cleanup only if you have decided to upgrade Oracle Utilities Analytics Warehouse from version 2.8.0.1.2 to version 2.9.0.0.0.

Note: Existing GG classic processes need to be cleaned up in both the source and target databases.

Clean Up the GG Processes on the Source Database

  1. On the source database, log in to the GG command line interface (ggsci prompt).

  2. Stop all extract and pump processes associated to this instance.

  3. Unregister the primary extract processes on the source system related to this context.

    Copy
    GGSCI> dblogin userid <gguser name>, password <Password>
    GGSCI> unregister extract <primary extract name> database

    Note: Run this command for each primary extract process created for context code. Primary extract process suffix with "X" and pump extract process suffix with "P". Once the extract process is unregistered, make sure that there is no data related to this context in the source database's DBA_CAPTURE view.

    Run this query in the source database and verify that no results are displayed.

    Copy
    select * from dba_capture where capture_name like '%<contextcode>%';

  4. Delete each one of the instance's extract and pump processes.

    Copy
    GGSCI> Delete extract <extract and pump process name>

  5. Clean up all trail files present in <Source GG Home>/dirdat/<Context Code>.

  6. Clean up all instance-related checkpoint files present in <Source GG Home>/dirchk/.

  7. Clean up all context-related report files present in <Source GG Home>/dirrpt/.

  8. Clean up all context-related temporary files present in <Source GG Home>/dirtmp.

  9. Clean up all context-related obey files present in <Source GG Home>/diroby/.

  10. Clean up all context-related parameter files present in <Source GG Home>/dirrpm/.

    Note: Do not modify or remove any other parameter file. For example, do not modify or remove manager.prm or jagent.prm. But the manager and jagent param files can be removed if you opt to uninstall Goldengate Classic.

  11. Check if there is any data in the source GG owner schema B1_OGG_SYNC_LOG table.

    If there is data for OGG_MODEL_CD, delete the records pertaining to the instance that is to be de-registered.

    Copy
    select OGG_MODEL_CD FROM <GG Owner Schema>.B1_OGG_SYNC_LOG WHERE OGG_MODEL_CD like '<context code>%';
    DELETE FROM <GG Owner Schema>.B1_OGG_SYNC_LOG WHERE OGG_MODEL_CD like '<context code>%';
    COMMIT;

Back to Top

Clean Up the GG Processes on the Target Database

  1. On the target database, log in to the GG command line interface (ggsci prompt).

  2. Stop all replicat processes associated to this context.

  3. Log in to the database by using the DBLOGIN command from the GGSCI command prompt.

    Use the DBLOGIN credential from the <Context Code>.oby file that is located in the <Goldengate Home>/dirtmp directory.

  4. Delete from the target system all replicat processes related to this context.

    Copy
    GGSCI> Delete replicat <replicat process name>

  5. Clean up all trail files present in <Source GG Home>/dirdat/<Context Code>.

  6. Clean up all instance-related checkpoint files present in <Target GG Home>/dirchk/.

  7. Clean up all context-related report files present in <Target GG Home>/dirrpt/.

  8. Clean up all context-related temporary files present in <Target GG Home>/dirtmp.

  9. Clean up all context-related obey files present in <Target GG Home>/diroby/.

  10. Clean up all context-related parameter files present in <Target GG Home>/dirrpm/.

    Note: Do not modify or remove any other parameter file. For example, do not modify or remove manager.prm or jagent.prm. But the manager and jagent param files can be removed if you opt to uninstall Goldengate Classic.

  11. Ensure that no entry is present in the checkpoint table for the replicat processes related to the current context.

    Copy
    Select * from mdadm.b1_checkPoint where group_name like '<context code>%';

Back to Top