Perform Pre-Upgrade Steps

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

Note: This upgrade path is valid only for source applications certified with both OUAW 2.7.0.0.13 and OUAW 2.8.0.0.0.

On this page:

Preparation Steps

Notes:

  • Customers need to apply the patch 2.7.0.0.13 with the required tech stack before upgrading from 2.7.0.0.13 to 2.8.0.0.0.
  • 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. Increase the log retention period to 60 days from the Global Configuration page in Apex to make sure that the ODI operator logs are available during and after the upgrade.
  3. Increase the ODI log level to 5 or 6 from the Global Configuration page in Apex to ensure the ODI log level is set to its maximum.

  4. Stop the source application.
  5. Make sure that the database is up and running in both the source and the target.
  6. Make sure that the primary keys of all replication tables are present. Use the following query to retrieve the tables that are missing the primary key.

    Copy
    SELECT * FROM MDADM.B1_SOURCE_TABLE S WHERE PROD_FLG = '<configured source product value>' AND BASE_REPLICATE_FLG ='Y'
    AND NOT EXISTS (SELECT 1 FROM ALL_CONSTRAINTS C WHERE CONSTRAINT_TYPE ='P' AND OWNER='<replication schema name for configured source>' AND S.TBL_NAME=C.TABLE_NAME);

  7. 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

  8. Stop BI_RUN_ALL, then follow these steps from the ODI:
    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 Studio, navigate to the Topology tab.
    5. Right-click OracleDIAgent , then select Update Schedule.
  9. 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. If any rows are returned, that means jobs are not complete yet.

  10. Stop the Oracle Data Integrator admin and managed servers.

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

  11. Stop the OBIEE Services.

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

  12. Stop the Apex admin and managed servers.

    Copy
    cd <Domain Home>/<apex_domain>/bin       
    ./stopManagedWeblogic.sh <apex_server>       
    ./stopWeblogic.sh

  13. Stop the GG process EXTRACT from the source and the REPLICATS from the target database server.

    Copy
    cd <Goldengate Home>       
    ./ggsci       
    stop <EXTRACT/REPLICATS> <Context Code>

  14. Stop the Goldengate Manager and JAGENT from the source and the target database servers after the GoldenGate process cleanup.

    Copy
    cd <Goldengate Home>
    ./ggsci      
    stop JAGENT
    stop mgr

Back to Top

GoldenGate Processes Cleanup

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

Note: Existing GG 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 and log in to the GG command line interface (that is, the 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 <gg user name>, password <Password>
    GGSCI> unregister extract <primary extract name> database

    Note: Execute 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 are unregistered, make sure there is no data related to this context in the source database's DBA_CAPTURE view. Execute in the source database the query below. No result should be displayed.

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

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

    Copy
    GGSCI> Delete extract <extract & 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>/dirprm/.
  11. Note: Do not modify or remove any other parameter file. For example do not modify or remove manager.prm or jagent.prm.

  12. 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 (that is, the 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 cmd 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>/dirprm/.

    Note: Do not modify or remove any other parameter file. For example, do not modify or remove manager.prm or jagent.prm.

  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