Perform the following prerequisite steps as necessary:

• Open the Oracle Cloud Infrastructure Console by clicking the next to Cloud.

• From the Oracle Cloud Infrastructure left navigation menu click Oracle Database and then click Autonomous Database.

• On the Autonomous Databases page select an Autonomous Database from the links under the Display name column.

To view maintenance history, do the following:

The DBA_CLOUD_PATCH_INFO view provides patch information related to reported bugs (bugs reported by a customer). You can use this information to determine if a bug you reported is fixed and the patch version where the fix was applied to your Autonomous Database instance. If there were no customer bugs in a patch, DBA_CLOUD_PATCH_INFO does not include any rows for that patch.

To view patch information for a specific patch, do the following:

To view patch information for all available patches:

SELECT * FROM DBA_CLOUD_PATCH_INFO;

Notes for viewing patch information:

• The view DBA_CLOUD_PATCH_INFO is available to the ADMIN user.

• Patch information and details on resolved issues is available from ADBS-21.7.1.1 onwards (starting in July 2021).

• The view DBA_CLOUD_PATCH_INFO has the following columns:

  BUG_NUM, BUG_TITLE, COMPONENT_NAME, PATCH_VERSION

See View Maintenance Status Notifications for details about the patches applied during maintenance.

When you select patch level Early, patches are applied for the Autonomous Database instance one week before the Regular scheduled patch. The Next Maintenance field in the Oracle Cloud Infrastructure Console reflects a maintenance window date and time based on the patch level.

The default patch level for provisioning an Autonomous Database instance is Regular. The default patch level for cloning is the patch level specified for the source database.

Provisioning or cloning an instance and setting the patch level to Early allows you to use and to test upcoming patches before they are applied to all systems. Oracle recommends you select the Early patch level for your development and test databases if you want to test the upcoming patches before the patches reach production. You can also test your workloads using Oracle Real Application Testing to capture a workload on a production system and replay it with Early patch level. See Test Workloads with Oracle Real Application Testing for more information.

To change the patch level for an existing Autonomous Database, do the following:

1. On the Autonomous Database Details page, under Maintenance, in the Patch level field click Edit.
   Note
   
   The Edit button may be disabled under the following circumstances:

   • If early patch level is not available in your region for your database version.
   • If your database has Autonomous Data Guard enabled.
   • If your database is on early patch level and it is not feasible to move it to regular patch level. In this case, you should try again after the next maintenance window.
2. Select the patch level, Regular or Early, and click Submit.

   The time it takes to change the patch level depends on the size of your database. You may see brief connection drops during this time.

Reporting Patch Issues to Oracle Support

When you report an issue for an Early patch level database, Oracle Support takes the necessary actions to prevent the problem from propagating to Regular patch level databases. A few examples of the possible actions are:

• The patch that caused the problem is removed before the regular patch level databases are patched.

• The patch that caused the problem is disabled using database parameters when it is being applied to the regular patch-level databases.

• Patching of regular patch level databases is paused until corrective action is taken.

If you have an issue to report, file a service request at Oracle Cloud Support or contact your support representative.

Oracle provides a service level objective of zero regressions in your production database. See Zero-Regression Service Level Objective for more information.

Notes for patching level:

• The option to set the patch level is not available in every region. In some regions all Autonomous Database instances are provisioned or cloned at the Regular patch level.

• Autonomous Data Guard is only available for instances with patch level Regular. When you configure an Autonomous Database instance with patch level Early, you cannot enable Autonomous Data Guard.

• Always Free Autonomous Database instances do not provide the Early patch level option.

• When the patch level of a source Autonomous Database instance is Regular, in regions that support the Early patch level you can set the patch level of a clone to Early.

To show notification information:

The following provides details about the DESCRIPTION field values.

• Maintenance run has ended: Specifies maintenance has completed. The MAINTENANCE_STATUS shows the value COMPLETED with the start and end timestamps for the completed maintenance in ACTUAL_START_DATE and ACTUAL_END_DATE.

• Maintenance run is scheduled for the instance: Specifies a new maintenance has been scheduled. The MAINTENANCE_STATUS shows the value SCHEDULED with the expected start and end timestamps for the scheduled maintenance in EXPECTED_START_DATE and EXPECTED_END_DATE.

• Maintenance run has begun: Specifies the maintenance is in progress and provides the start timestamp for the active maintenance. The MAINTENANCE_STATUS shows the value IN_PROGRESS and ACTUAL_START_DATE stores the start timestamp.

The following table shows the DB_NOTIFICATIONS columns and datatypes.

Use a Connection Pool and Return Connections to the Pool

Using a connection pool is recommended to hide scheduled maintenance from your application. Running an application during the maintenance window has no impact on an application when the application does the following:

• Uses a connection pool with the recommended settings.
• Checks out a connection from the connection pool.
• Uses the connection for less than the drain time (5 minutes).
• Returns the connection to the connection pool.

The best practice for an application working with a connection pool is to follow these steps. The application checks out a connection, uses the connection for database processing, and then releases the connection back to the connection pool immediately when the work is complete (this makes the connection available for use by other threads).

When the draining period starts the connection pool handles re-establishing the available connections in the connection pool so that new connections connect to the newly available nodes. When an application checks out a new connection it does not see any disruptions (new connections use the new nodes). However, if a connection is checked out before the start of the maintenance or during the drain time and it performs processing that continues for more than the drain time, the connection will be disconnected. In this case, to avoid disruptions you can stop such long-running operations before maintenance starts and restart them when maintenance ends. To know when to stop and when to restart long running operations you can subscribe to events, as explained in the following section, "Subscribe to Information Events".

The following table shows some of the common connection pool types and the recommended versions and settings.

Use Connection Tests on the JDBC Driver if You Cannot Use a Connection Pool

If you cannot use a connection pool, the Oracle client drivers 19.13 (or later) can drain connections so your application does not see disruptions. To ensure connections are drained properly you can call any Oracle JDBC draining API: isValid(), isUsable(), pingDatabase(), or endRequest().

Subscribe to Information Events

If your application has long-running database operations that run for longer than the drain time (5 minutes), the pool or the JDBC driver cannot drain the connections, as they will not be released before the drain time ends. For such long running operations, to avoid disruptions you should not start the processes and jobs during or just before a maintenance window.

Autonomous Database publishes Information events to the OCI Events service to notify you about maintenance windows, including these Information events (with the event category Maintenance):

• When a new maintenance window is scheduled
• 24 hours before patching starts
• 60 minutes before patching starts
• When patching starts
• When patching ends

You can subscribe to Autonomous Database Information events, and optionally specify the event category maintenance, to receive notifications and to limit the notifications you receive to maintenance events. Then, based on the notification and rules you define, you can take actions to stop the long-running operations and to restart them after maintenance ends. Even though the announced maintenance windows are usually 2 hours long, actual patching happens in 5 to 10 minutes during that window. Using these events and your knowledge of the long running operations, you can determine when to stop long-running operations, and when to restart them.

See Use Autonomous Database Events for more information.

Handle PL/SQL Session State if Your Application is Using PL/SQL

The database parameter SESSION_EXIT_ON_PACKAGE_STATE_ERROR specifies the handling for a stateful PL/SQL package running in a session. When such a package undergoes modification, such as during planned maintenance for Oracle-supplied objects, the sessions that have an active instantiation of the package receive the following error when they attempt to run the package: ORA-04068: existing state of packages has been discarded.. However, the application code that receives the ORA-4068 error may not be equipped to handle this error with its retry logic.

Setting SESSION_EXIT_ON_PACKAGE_STATE_ERROR to TRUE provides different handling for this case. When SESSION_EXIT_ON_PACKAGE_STATE_ERROR is TRUE, instead of just raising the ORA-4068 error when the package state is discarded, the session immediately exits. This can be advantageous because many applications can handle session termination by automatically and transparently re-establishing the connection.

See SESSION_EXIT_ON_PACKAGE_STATE_ERROR for more information.