Upgrade a Domain

For an existing Oracle WebLogic Server for OCI domain, you can upgrade the WebLogic Server release from 12c (12.2.1.3) to WebLogic Server release 12c (12.2.1.4).

Following are the advantages of this documented process over the traditional in-place upgrade:
  • The stack has the latest scripts on disk volumes.
  • There is an easier roll back process. Since the original stack with 12.2.1.3 is still available, only the database has to be rolled back for a JRF instance.
  • The WebLogic binaries are the latest. You do not have to locate the WebLogic installers and apply the required patches.

Backup the Database

  1. Complete the Create an on-demand full backup of a database procedure in Backing Up a Container Database to Oracle Cloud Infrastructure Object Storage in the Oracle Cloud Infrastructure documentation.
  2. Return here to continue with the next step.

Create a 12.2.1.4 Instance

  1. Create a 12.2.1.4 instance, which is identical to the 12.2.1.3 instance that you plan to upgrade.

    Ensure that you provide a unique name to the 12.2.1.4 instance and use the same networking as the 12.2.1.3 instance. See Create a Stack.

    Note:

    If you are using a reserved IP with your load balancer, then delete the load balancer on the source instance to free up the reserved IP address.
  2. Return here to continue with the next step.

Stop the WebLogic Server Processes on the Source 12.2.1.3 Instance

  1. Log in to the source instance as an opc user.
  2. Run the following command:
    sudo su - oracle
    /opt/scripts/restart_domain.sh -o stop
    Run the following command to confirm if there are any running processes:
    jps

    If there are any processes running, then run kill -9 against each of the processes.

  3. Log in to each of the non-administration compute instance as an opc user.
  4. Run the following command:
    sudo su - oracle
    /opt/scripts/restart_domain.sh -o stop
    Run the following command to confirm if there are any running processes:
    jps

    If there are any processes running, then run kill -9 against each of the processes.

  5. Log in to administration compute instances as an opc user.
  6. Run the following command:
    sudo su - oracle
    /opt/scripts/restart_domain.sh -o stop
    Run the following command to confirm if there are any running processes:
    jps

    If there are any processes running, then run kill -9 against each of the processes.

Replace the Domain on the Target 12.2.1.4 Instance with Cloning

  1. Clone the source 12.2.1.3 domain contents. See Clone a JRF or non-JRF Instance using a Script.

    Note:

    • Clone only the data block volumes. Do not use to the -m argument to clone the Middleware volumes.
    • Cloning might fail at the StartServers step, as your applications may not be upgraded to handle 12.2.1.4 binaries. If this error occurs, ignore the error and continue with the next step.
      Run the following command:
      python3 create_clone.py -p StartAppGateway
  2. After you have run the cloning script on all the VMs, stop the WebLogic servers by running the following command on each VM:
    sudo su - oracle
    /opt/scripts/restart_domain.sh -o stop
    Run the following command to confirm if there are any running processes:
    jps

    If there are any processes running, then run kill -9 against each of the processes.

  3. Are you upgrading a JRF instance?

Set up VNC Server

To use the Reconfiguration Wizard and Upgrade Assistant (Fusion Middleware tools) during the upgrade process, you need a graphical user interface (GUI) environment. The instructions in this step explain how to set up a VNC server and use port forwarding through a bastion host. If you are familiar with using X11, then X11 forwarding can be used to forward the GUI to your local desktop and you can skip this step.

Note:

This step is not applicable for a non-JRF instance.
  1. Log in to administration compute instance as an opc user.
  2. Run the following command to install the GUI packages on the target 12.2.1.4 instance:
    sudo bash
    yum group install "Server with GUI"
    # enter 'y' when prompted.
  3. As an opc user, run the following command to set up the VNC server for the oracle user on the administration compute instance:
    sudo bash
    yum install tigervnc-server -y
    exit
    sudo su - oracle
    vncpasswd
    # enter the password and confirmation password.
    # respond with "n" when prompted if this should be a view only password
    exit
    sudo bash
    cp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@\:1.service
    vi /etc/systemd/system/vncserver@\:1.service
     Replace <USER> with oracle
    systemctl daemon-reload
    systemctl enable vncserver@\:1.service
    systemctl start vncserver@\:1.service
    systemctl status vncserver@\:1.service
    # Confirm it is running
     
    # Set up the firewall to allow the VNC server port to be accessed:
    iptables -I INPUT -m state --state NEW -p tcp --destination-port 5901 -j ACCEPT
  4. Sign in to the Oracle Cloud Infrastructure Console and update the subnet to have a security list that enables inbound access to the VNC server port 5901.

    Note:

    If you have not already set up your bastion VM to be able to access VMs as the opc user, then place your private key pem for the opc user on the disk. This is used for port forwarding.
  5. Create the tunnel by accessing the bastion host as the opc user:
    ssh -i <privatekey.ppk> -L <vnc_port_on_wlsm-private-ip>:<wlsvm-private-ip>:<port_on_bastion> <wlsvm-private-ip>
    Following is an example, where the IP address of the administration compute instance is 10.1.1.1 and the private key for the opc user is in ~/.ssh/id_rsa
    ssh -i ~/.ssh/id_rsa -L 5901:10.1.1.1:5901 10.1.1.1
Windows instructions for launching GUI
  1. Install and launch PuTTY.
  2. For Host Name, type the bastion IP address.
  3. For Saved Sessions, type bastion.
  4. Under Category, go to Connection > Data.
  5. For Auto-logion username, type opc.
  6. Under Category, go to Connection > Data > SSH > Tunnels.
  7. Type the following values for the respective fields:
    • Source port: 5901
    • Destination: localhost:5901
  8. Click Add.
  9. Under Category, go to Connection > Data > SSH > Auth.
  10. For Private key file for authentication, browse and select the xperiment private key that you have created.
  11. Under the Category, select Session.
  12. Select Save and then select Open to establish the connection
  13. Verify that you connected successfully to the putty session.
  14. Install a VNC Viewer and set up a new connection to use localhost:5901 to verify that you can connect correctly.

    Note:

    Ensure that you have set up the vncserver as the oracle user, as this creates a session with the oracle user even though you have port forwarding via the opc user ssh keys.

Perform Readiness Check

Perform a readiness check to determine if your service instance is ready for upgrade.

Note:

This step is not applicable for a non-JRF instance.
  1. By using the VNC viewer session, start the Upgrade Assistant.
    export USER_MEM_ARGS=-Djava.security.egd=file:/dev/urandom
    /u01/app/oracle/middleware/oracle_common/upgrade/bin/ua -readiness

    Setting USER_MEM_ARGS to use the /dev/urandom device reduces the time it takes to run the Oracle Fusion Middleware upgrade tools.

  2. Use the Upgrade Assistant to perform a readiness check. See Upgrade from a previous 12c release to 12.2.1.4 in Upgrading to the Oracle Fusion Middleware Infrastructure
  3. On the Readiness Check Type screen, select the domain-based readiness check.
    The domain-based readiness check enables the Upgrade Assistant to discover and select all upgrade-eligible schemas or component configurations in the domain specified in the Domain Directory field.
  4. On the End of Readiness screen in the Upgrade Assistant, review the results of the readiness check (Readiness Success or Readiness Failure).
    • If the readiness check is successful, click View Readiness Report to review the complete report. Oracle recommends that you review the Readiness Report before you perform the upgrade even when the readiness check is successful. Use the Find option to search for a particular word or phrase within the report. The report also indicates where the completed Readiness Check Report file is located.
    • If the readiness check encounters an issue or error, click View Log to review the log file, identify and correct the issues, and then restart the readiness check.

Upgrade Infrastructure Schemas

This step helps to identify if you have an earlier version of infrastructure database schemas or have installed other Oracle products.

Note:

This step is not applicable for a non-JRF instance.
  1. Start the Upgrade Assistant if you have not already done so. For example:
    export USER_MEM_ARGS=-Djava.security.egd=file:/dev/./urandom
    /u01/app/oracle/middleware/oracle_common/upgrade/bin/ua   
  2. Upgrade the schemas. See Upgrading Schemas Using the Upgrade Assistant in Upgrading to the Oracle Fusion Middleware Infrastructure:
  3. On the Selected Schemas screen, select All Schemas Used by a Domain, and then enter a domain directory name in the Domain Directory field.
    The All Schemas Used by a Domain selection allows the Upgrade Assistant to discover and select all components that have a schema available to upgrade in the domain specified in the Domain Directory field. This is also known as a domain-assisted schema upgrade. In addition, the Upgrade Assistant prepopulates connection information on the schema input screens.
  4. On the Upgrade Progress screen in the Upgrade Assistance, monitor the schema upgrade progress.
  5. Finish the schema upgrade process.
    • If the schema upgrade succeeds, click Close to complete the upgrade and close the wizard.
    • If the upgrade fails, click View Log to view and troubleshoot the errors. The logs are available in the following directory:
      /u01/app/oracle/middleware/oracle_common/upgrade/logs
  6. Remedy the database connection failure if one occurs. See Problems with Database Connectivity When Upgrading the Infrastructure Schema Database in Administering Oracle Java Cloud Service.
  7. Verify the schema upgrade was successful by checking that the schemas in schema_version_registry have been properly updated. See Problems with Database Connectivity When Upgrading the Infrastructure Schema Database in Upgrading to the Oracle Fusion Middleware Infrastructure.
    One way to verify the schema upgrade is to use SQL*Plus commands to obtain data from the SCHEMA_VERSION_REGISTRY.
    1. Find the Oracle Java Cloud Service instance's schema prefix in the Upgrade Assistant log file at /u01/app/oracle/middleware/oracle_common/upgrade/logs.
    2. Connect to the database as a user having Oracle DBA privileges and run the following commands from SQL*Plus to get the current version numbers.
      sqlplus / as sysdba
      SQL> connect <user_name>/<password>@<host_name>:<port>/<service_name> as sysdba
      SQL> SELECT MRC_NAME,COMP_ID,OWNER,VERSION,STATUS,UPGRADED FROM SCHEMA_VERSION_REGISTRY WHERE MRC_NAME like 'SP1556690734';
      Example output for the SCHEMA_VERSION_REGISTRY:
      MRC_NAME COMP_ID OWNER VERSION STATUS UPGRADED
      SP1556690734 IAU SP1556690734_IAU 12.2.1.2.0 VALID Y
      SP1556690734 IAU_APPEND SP1556690734_IAU_APPEND 12.2.1.2.0 VALID N
      SP1556690734 IAU_VIEWER SP1556690734_IAU_VIEWER 12.2.1.2.0 VALID Y
      SP1556690734 MDS SP1556690734_MDS 12.2.1.3.0 VALID Y
      SP1556690734 OPSS SP1556690734_OPSS 12.2.1.0.0 VALID Y
      SP1556690734 STB SP1556690734_STB 12.2.1.3.0 VALID Y
      SP1556690734 UCSUMS SP1556690734_UMS 12.2.1.0.0 VALID N
      SP1556690734 WLS SP1556690734_WLS 12.2.1.0.0 VALID N

Reconfigure the Domain

Note:

  • This step is not applicable for a non-JRF instance.
  • Running the reconfiguration wizard is not required for an upgrade from 12.2.1.3. However, if it is not run and you do not replace 12.2.1.3 with 12.2.1.4 in config.xml, then you will encounter the Incorrect Version Numbers After a Reduced Downtime Upgrade issue.
  1. Start the Reconfiguration Wizard as user oracle with the following logging options, with log_file as the absolute path of the log file you'd like to create for the domain reconfiguration session. This can be helpful if you need to troubleshoot the reconfiguration process.
    For example:
    /u01/app/oracle/middleware/oracle_common/common/bin/reconfig.sh -log_priority=all -log="/u01/reconfig0212.log"
  2. Perform the reconfiguration tasks as described in Upgrading to the Oracle Fusion Middleware Infrastructure. See Reconfiguring the Domain with the Reconfiguration Wizard.
  3. On the Advanced Configuration screen of the Reconfiguration Wizard, select Deployment and Services.
  4. Target the wsm-pm app to the Administration Server.
  5. Click Reconfig.
  6. Check the End of Configuration screen to learn whether the reconfiguration process completed successfully or failed.
    • If the reconfiguration is successful, Oracle WebLogic Server Reconfiguration Succeeded is displayed. The location of the domain that was reconfigured as well as the Administration Server URL (including the listen port) are displayed as well.
    • If the reconfiguration process did not complete successfully, an error message is displayed which indicates the reason. Take appropriate action to resolve the error.

Upgrade the Domain

Note:

This step is not applicable for a non-JRF instance.
  1. Start the Upgrade Assistant, for example:
    export USER_MEM_ARGS=-Djava.security.egd=file:/dev/./urandom
    /u01/app/oracle/middleware/oracle_common/upgrade/bin/ua   
  2. Use the Upgrade Assistant to upgrade the domain configurations. See Upgrading the Domain Configurations with the Upgrade Assistant in Upgrading to the Oracle Fusion Middleware Infrastructure.
  3. On the All Configurations screen, select All Configurations Used by a Domain and specify your domain location in the Domain Directory field. Enter the domain directory directly or click Browse to select a valid domain directory.
  4. On the Upgrade Summary page, review the summary of the options you have selected for the component configuration upgrade, and then click Upgrade to start the upgrade process.
  5. View the Upgrade Progress page to monitor the upgrade.
  6. View the results and finish the upgrade.
    • If the upgrade succeeds, the Upgrade Success page is displayed. Click Close to complete the upgrade and close the wizard.
    • If the upgrade fails, the Upgrade Failure screen is displayed. Click View Log to view and troubleshoot the errors. The logs are available at
      ORACLE_HOME/oracle_common/upgrade/logs

Restart Servers

Access the 12.2.1.4 instance as the opc user, and on each VM run the following command:
sudo su - oracle
/opt/scripts/restart_domain.sh

Post Upgrade

If the upgrade was successful, complete following tasks if they apply to your instance:
  • If you use a Hosting Provider to manage DNS, then reset the CNAME records at your Hosting Provider to point to the new IP addresses of the load balancer and WebLogic VMs.
  • Destroy the source 12.2.1.3 instance. See Destroy Stack Resources.

    WARNING:

    Do not Delete a JRF Database Schema or Delete the Identity Cloud Service Resources as these resources are required in the upgraded cloned instance.
  • Run the following commands to remove the UI libraries. This stops the VNC server, removes the VNC server package, and removes the Server with GUI group packages.
    # Remove VNC server
    sudo su - oracle
    vncserver -list
    # Locate the X Display value and kill this - typically this is :1
    vncserver -kill :1
    # Remove the Linux service
    exit
    sudo bash
    systemctl stop vncserver@\:1.service
    systemctl disable vncserver@\:1.service
    # Uninstall package
    yum remove tigervnc-server -y
    # Remove GUI
    yum group remove "Server with GUI"

Roll Back Upgrade

If the upgrade fails, you can roll back the upgrade. Since the source 12.2.1.3 instance is still present, only the database needs to be rolled back if you upgraded a JRF domain.

  1. Complete the Restore a database using a specific backup from Object Storage procedure in Recovering a Container Database from Object Storage in the Oracle Cloud Infrastructure documentation.
  2. If you use a reserved IP address on the load balancer, then you must delete the load balancer on the source instance prior to creating the 12.2.1.4 instance.
    1. Delete the load balancer or destroy the 12.2.1.4 stack to release the reserved IP address. See Destroy Stack Resources.
    2. Create a load balancer in Oracle Cloud Infrastructure again using the reserved IP address. See Configure SSL for a Domain.