Oracle Cloud Infrastructure Documentation

View Patch and Maintenance Window Information, Set the Patch Level

Autonomous Database uses predefined maintenance windows to automatically patch your database. You can view maintenance and patch information and see details for Autonomous Database maintenance history.

Parent topic: Managing and Viewing Maintenance Windows, Patching Options, Work Requests, and Customer Contacts

About Scheduled Maintenance and Patching

All Autonomous Database instances are automatically assigned to a maintenance window and different instances can have different maintenance windows.

Autonomous Database uses these maintenance windows to patch the entire stack used to run your database, including the database software, database dictionary, operating systems, Exadata storage, firmware, and more.

Patches include bug fixes, security fixes, and new features. Critical security fixes are always applied as soon as they are available. Patches are deployed uniformly across all databases, so you do not need to track one-off patches. After a fix for an issue is implemented, for example an issue seen in one database, the fix is deployed to all Autonomous Database instances.

All patches undergo a rigorous testing and validation process that is part of a continuous integration and development pipeline. Fixes are validated in multiple stages and environments before they are deployed to Early patch level and Always Free databases, followed by Regular patch level databases. This pipeline allows regressions to be caught and fixed before the patch is deployed to all databases. In the unlikely case that patching introduces a regression, Oracle has processes to mitigate the problem, including actions such as the following:

  • Rolling back either a subset of the patch or the entire patch.

  • Setting database parameters to disable the patch that introduced the regression.

  • Applying an online patch to fix the problem without any downtime or connection disruption.


Description of autonomous-database-continuous-integration.eps follows
Description of the illustration autonomous-database-continuous-integration.eps

Automatic Regression Detection for Autonomous Database provides proactive handling of regressions and enables automated issue detection, diagnosis, and mitigation. This can reduce or eliminate the need for you to manually investigate issues and file service requests. Automatic Regression Detection monitors all databases, in both the Early and Regular patch levels, but it is especially useful when you test a workload on an Early patch level database. If Automatic Regression Detection finds an issue and identifies a regression, it automatically reports the issue with detailed information to diagnose it. This automated reporting, as part of the continuous delivery patching cycle, allows Oracle to mitigate or fix the issue before changes reach production databases (Regular patch level databases).  Automatic Regression Detection may not be able to find every issue; in cases where you see issues yourself, you can file a service request.

Automatic Regression Detection includes the following:

  • Automatic Regression Detection monitors the database and, in the event of an incident, files a bug for the incident with detailed diagnostic information extracted from the Automatic Workload Repository.

  • The incident reporting system produces notifications to Oracle Cloud Infrastructure Operations and Development teams with Oracle Automatic Incident Monitoring.

  • Issues are mitigated by analyzing the Automatic Regression Detection alerts.

  • Learning and improvements are made to Automatic Regression Detection on an ongoing basis.

The Autonomous Database Details page shows the Patch level field and the Next maintenance field that includes the date and time for the upcoming maintenance window; the date is updated automatically when the next maintenance window is scheduled. The View history link provides details on past maintenance. The Target component field shows the component to be updated in the next maintenance window.

Description of adb_patch_level.png follows
Description of the illustration adb_patch_level.png

When Autonomous Data Guard is enabled the console also shows maintenance information for a local standby database.

The Maintenance area includes the following information:

Maintenance Field Description

Patch level

Shows the patch level for the instance. There are two patch level options: Regular and Early. Click Edit to manage patch level settings.

See Set the Patch Level for more information.

Next maintenance

Specifies the time period for the next scheduled maintenance window. Click View history to see details on past maintenance.

See View Maintenance Event History for more information.

Target component

Lists the target components for the upcoming maintenance window. Possible values are:

  • Database: when the patch applies to the database home and executables.

  • Dictionary: when the patch applies to the data dictionary and to Oracle APEX.

  • Infrastructure: when the patch applies to the Exadata hardware or to the Grid Infrastructure.

Next maintenance (local peer)

Specifies the time period for the next scheduled maintenance window for a local Autonomous Data Guard standby. Click View history to see details on past maintenance.

Target component (local peer)

Lists the target components for the upcoming maintenance window on the Autonomous Data Guard. Possible values are:

  • Database: when the patch applies to the database home and executables.

  • Dictionary: when the patch applies to the data dictionary and to Oracle APEX.

  • Infrastructure: when the patch applies to the Exadata hardware or to the Grid Infrastructure.

Customer contacts

When customer contacts are set, Oracle sends notifications to the specified email addresses for Autonomous Database service-related issues.

See View and Manage Customer Contacts for Operational Issues and Announcements for more information.

Notes for scheduled maintenance and patching:

  • The Autonomous Database operations team never accesses your data unless you explicitly grant permission through a Service Request for a specified duration.

  • If your database is in the stopped state during the maintenance window, the database changes from the patch are applied when you start your database.

  • Your database remains available during the maintenance window. New connections to the database will always succeed. Your existing database connections may get disconnected briefly, depending on the component being patched; however, you can immediately reconnect and continue using your database:

    • For Database patches, existing connections may get disconnected if they are running for longer than the drain time after patching starts.

    • For Infrastructure patches, existing connections may get disconnected if they are running for longer than the drain time after patching starts.

    • For Dictionary patches, existing connections may get disconnected if they are holding locks on the dictionary objects being patched. Otherwise, the existing connections will not be impacted. For example, if your application is running a procedure in the DBMS_CLOUD package during patching and the package needs to be patched, the session using that package may get disconnected.

      See SESSION_EXIT_ON_PACKAGE_STATE_ERROR for more information.

  • You can use Oracle Cloud Infrastructure Events to be notified when maintenance begins and ends. See Information Events on Autonomous Database for more information.

  • If you want to change the assigned maintenance window to a different 2-hour window on either Saturday or Sunday in the region's local time zone, file a Service Request at Oracle Cloud Support.

    If you want a specific time period for your maintenance window on either Saturday or Sunday in the region's local time zone, you can request the time period with the same Service Request. If you request a specific time period for your maintenance window, the change can only be made if the time period you request is available for your database.

  • If your database's allocated storage is 384 TB, you can choose a custom 2-hour window by filing a Service Request at Oracle Cloud Support (that is you can file a Service Request to request a specific day and time period on either Saturday or Sunday in the region's local time zone for your maintenance window).

See Test Workloads Against an Upcoming Patch for information on capturing a workload from a production database and replaying the workload on a target early patch level refreshable clone.

See Zero-Regression Service Level Objective for details on the zero-regression SLO for Autonomous Database.

View Maintenance Event History

You can view Autonomous Database maintenance event history for details about past maintenance events, such as the title, state, start time, and stop time.

Perform the following prerequisite steps as necessary:

  • Open the Oracle Cloud Infrastructure Console by clicking the navigation icon 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:

  1. On the Autonomous Database Details page, under Next Maintenance, click View history.
  2. The Oracle Cloud Infrastructure Console displays the Maintenance History page.
  3. (Optional) Use the Search and Filter selector to filter events by state.

    For example, if you select Succeeded, the Maintenance History page shows only the maintenance events with the Succeeded state.

The Maintenance History page shows details for each maintenance event, including the following:
Field Description

Title

The name of the maintenance event.

Maintenance type

Planned or Unplanned.

Target component

 The type of the resource on which the maintenance event occurs: Database, Dictionary, or Infrastructure.

State

Succeeded, Failed, or In progress.

Start Time

Maintenance start time.

End Time

Maintenance end time.
Note

Maintenance event history is available starting with maintenance events after February 2021.

View Patch Level and Patch Details

You can view Autonomous Database patch information, including a list of resolved issues and components.

View Patch Level for an Autonomous Database Instance

From the Oracle Cloud Infrastructure Console Autonomous Database details page, you can view the patch level for the instance.

  1. On the Autonomous Database information tab, the Maintenance area shows the instance patch level. The choices are: Regular and Early.
  2. If you want to change the patch level, click Edit.

See Set the Patch Level for more information.

The DBA_CLOUD_PATCH_INFO view provides patch information related to reported bugs (this is a list of bugs reported by a customer). You can use this information to determine if a bug you reported is fixed and to determine 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:

  1. Select the Autonomous Database patch that you want to view. The Maintenance history page on the Oracle Cloud Infrastructure Console shows the list of patches under the Title column.
  2. For a selected patch, find additional details by querying the DBA_CLOUD_PATCH_INFO view.

    For example, for patch ADBS-25.4.4.2, use the following query: 

    SELECT * FROM DBA_CLOUD_PATCH_INFO WHERE PATCH_VERSION = 'ADBS-25.4.4.2';
  3. For an issue of interest, query the view to obtain details for the issue:
    SELECT * FROM DBA_CLOUD_PATCH_INFO WHERE PATCH_VERSION = 'ADBS-25.4.4.2' and BUG_NUM = bug_number;

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.

Set the Patch Level

When you provision or clone an Autonomous Database instance you can select a patch level to apply to upcoming patches. You can also edit the patch level after an Autonomous Database instance is provisioned. There are two patch level options: Regular and Early.

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.

Note

Setting the patch level is only available on an Autonomous Database instance that uses the ECPU compute model.
To set the patch level while provisioning or cloning an instance, do the following:

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.

View Maintenance Status Notifications

The DB_NOTIFICATIONS view stores information about maintenance status notifications for your Autonomous Database instance.

To show notification information:

  1. Connect to your Autonomous Database instance.
  2. Use the following query to view maintenance (patching) information.
    SELECT * FROM DB_NOTIFICATIONS WHERE TYPE = 'MAINTENANCE';

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.

Column Datatype Description
TYPE VARCHAR2(128)

Specifies the type of the notification.

Valid value is: MAINTENANCE.

TIME TIMESTAMP(6) WITH TIME ZONE

Time when the notification entry was added.
EXPECTED_START_DATE TIMESTAMP(6) WITH TIME ZONE

Scheduled maintenance start time.
EXPECTED_END_DATE TIMESTAMP(6) WITH TIME ZONE

Scheduled maintenance end time.
ACTUAL_START_DATE TIMESTAMP(6) WITH TIME ZONE

Actual maintenance start time.
ACTUAL_END_DATE TIMESTAMP(6) WITH TIME ZONE

Actual maintenance end time.
MAINTENANCE_PRODUCT VARCHAR2(128)

Product/component for which maintenance is scheduled/ongoing.
MAINTENANCE_STATUS VARCHAR2(128)

Current status of the maintenance.
DESCRIPTION VARCHAR2(128)

The notification message details.
PATCH_ID VARCHAR2(128)

Patch version.

Best Practices to Maintain Application Availability During Maintenance Windows

Provides information on best practices to maintain application availability and to minimize application disruption during a scheduled maintenance window.

Autonomous Database patches are applied during a scheduled maintenance window as rolling patches. Using rolling patches, your Autonomous Database instance is made available on new cluster nodes before patching starts on the original nodes where it was running. After the database is available on new cluster nodes, all new connections are directed to the new nodes. This means the database remains online and available during maintenance and new database connection requests will succeed during the maintenance window.

Existing database connections on the original nodes are subject to draining for 5-minutesFoot 1. During the draining period the database waits for the client to release existing connections. After the draining period, if there are any database connections left on the original nodes, the remaining connections are disconnected and patching starts. The following best practices can help you to ensure that database connections are drained during the draining period and are reconnected to the new nodes, so that applications do not see disruptions during a maintenance window.

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.

Connection Pool Version Oracle JDBC Driver Version Recommended Settings
Universal Connection Pool (UCP) 23ai 23ai Use the default settings.
Universal Connection Pool (UCP) 19.12 or later 19.13 or later ValidateConnectionOnBorrow=true

Add oracle.jdbc.defaultConnectionValidation=LOCAL to your JDBC driver connection properties.

Weblogic 14.1.1 or later 19.13 or later

test-connections-on reserve=true

test-table-name=SQL ISVALID

seconds-to-trust-an-idle-pool-connection=0

Apply the patch for the bug 35731335. See Patch 35731335 for more information.

Hikari 6.0.0 or later 19.21 or later

Set com.zaxxer.hikari.aliveBypassWindowMs to -1.

Set oracle.jdbc.defaultConnectionValidation to SOCKET in your JDBC properties.

Set com.zaxxer.hikari.enableRequestBoundaries to true.

Tomcat 9.0, 10.0, or 11.0 Any version

If you are using Tomcat with UCP, follow the UCP recommendations above.

If you are using Tomcat with the JDBC Driver, call any Oracle JDBC draining API: isValid(), isUsable(), pingDatabase(), or endRequest().

Set oracle.jdbc.defaultConnectionValidation to SOCKET in your JDBC properties.

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.


Footnote Legend

Footnote 1: Note that this draining time may change in future releases.