About Patching and Rollback

You can quickly and easily apply patches to an Oracle Java Cloud Service instance to ensure that it contains the latest bug fixes and performance improvements.

What Kinds of Patches are Available

You can patch different Oracle software components that comprise your service instance. These are often Patch Set Updates (PSU). PSUs are cumulative. Each PSU contains all the previous PSUs bug fixes in addition to any bug fixes released after the previous PSU. You can also apply a tools patch that patches the internal scripts that perform tooling operations such as backup and scaling. A tools patch is available after a PSU becomes available in production, and is applied automatically after a few hours if you do not apply it yourself.

You apply all these types of patches in the same way.

About Operating System (OS) Patching

Java Cloud Service does not provide cloud tooling for OS patching. You are responsible for installing OS patches to existing service instances.

You can obtain Oracle Linux OS patches from the Oracle’s Unbreakable Linux Network if you have an Oracle Linux support subscription. You can also obtain Linux OS patches from Oracle Linux Public Yum server: http://public-yum.oracle.com. Java Cloud Service nodes are preconfigured to enable you to install and update packages from the repositories on the Oracle public Yum server. The repository configuration file is in the /etc/yum.repos.d directory on the nodes. You can install, update, and remove packages by using the yum utility.

Note:

You are responsible to applying the required security updates published through the Oracle public Yum server.

Do not install OS patches for other Linux distributions. Also, if you plan to use your service instance for production applications, Oracle recommends that you avoid installing any test, development, or preview OS packages that might be available in the repository.

WARNING:

You can run yum update only with the repos provided in the OS. If you use the yum repos from other Linux systems to run the yum update, the system might become unstable and it is difficult to recover the OS back to working state.

When to Apply Patches

New approved patches are typically available and displayed on the Patching page of the console on a quarterly basis. Apply the most recent patches promptly. Delaying patches could cause your service to be unsupported for future patching.

Note:

Apply patches only when they become available on the Patching page for your service instance. Applying patches manually between PSUs causes precheck failure. If you have applied patches manually, remove them before patching.

What Happens When Patching Starts

As patching starts, the patching operation first performs internal prechecks for the following types of issues:

• Presence of manually-applied patches

• Disk space shortage

• Missing database connectivity

• Servers not running

• Storage access failure

Note:

Patching is not supported for service instances where Oracle Java Cloud Service Fusion Middleware—Oracle WebCenter Portal, Oracle Java Cloud Service Fusion Middleware—Oracle Data Integrator, or any other product that modifies the MW_HOME directory are installed. If you attempt to patch a service instance where any of these products are installed, patching prechecks issue an error message and patching does not start.

If the prechecks fail, the patching operation will fail and leave the Java Cloud Service instance untouched.

Next, the target Oracle software components are restarted to ensure that they can be restarted again after the patching operation performs a binary swap.

The prechecks do not check whether another administration task (backup, restoration, or scaling) is in progress, which would prevent patching.

You can also perform prechecks without attempting to patch, and first remedy any problems found.

If backups are configured and enabled on your service instance, an automatic backup is created only after patching prechecks succeed. If you need to restore the state of the service instance, use the backup and run patching again.

Note:

If automatic backup fails, then the patching operation fails and does not apply the patch.

What Happens During Patching

Most patching operations are rolling operations, so the service functions with very little interruption during the patch process. The patching operation shuts down one node at a time and applies the patch to the server or servers on the node. After each node is patched, it is automatically restarted. If there is a load balancer, the load balancer automatically detects that the server is down and does not send requests to that server. The other servers process application requests without interruption. The patching operation continues patching the servers on one node at a time until all servers are patched.

For example, if you have a two-node cluster, one node keeps running while the other is being patched.

If a load balancer is provisioned, when you patch the load balancer, the other server processes remain running. No requests will be routed to these servers during load balancer patching. The load balancer is stopped while patching is in progress.

What Happens When Patching is Not Fully Successful or Fails

If a patching operation fails, the patch information is displayed in the Patch History section. You can click on the icon to see an error report. After patching operation failure, the operation automatically reverts any change it has made to the service instance. The operation moves the service instance back to the same state it was in before the patching operation started. If patching fails and the operation fails to revert the service back to the previous state, you can use the backup created at the beginning of the patching operation to restore the service manually.

Note:

If you had applied patches from a source other than your service to your service instance, these patches will not be restored if you restore the service manually.

What Happens if Coherence is Enabled

Applying a patch will perform a rolling restart of Managed Coherence Servers on the Coherence data tier. By default, the patching operation checks that the StatusHA state for a Coherence member is NODE-SAFE before shutting down the node to apply the patch. You might choose to override the default behavior.

When to Roll Back a Patch

You can roll back a patch if you find that a patch is incompatible with applications deployed on your Java Cloud Service, or for any other possible reason.

Patches for the load balancer cannot be rolled back.

What Happens During a Rollback Operation

The rollback operation shuts down the server processes while the patch is rolled back, so the service is temporarily unavailable.

How to View Patching History

The patching history is displayed on the Java Cloud Service Patching page. The history shows the patch number, the name of the administrator who applied the patch, and any notes. When the rollback operation is complete, the patch information stays in the patch history section, but the Roll Back button is grayed-out. The patch information also reappears in the list of available patches, so you can try applying the patch again.

How to Restore the Instance Configuration

If backups are configured and enabled on your service instance, each patch, whether failed or successful, has a backup. Rolling back a patch restores the binaries to the specific version recorded at the time of the backup, without modifying the configuration data. If necessary, you can also restore the configuration after rollback by using the Backup page.