> For the complete documentation index, see [llms.txt](https://docs.tessell.com/tessell/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tessell.com/tessell/database-engines/tessell-for-oracle/db-services/my-services/patching.md).

# Patching

Tessell releases new Oracle PSUs to the platform within 2 weeks of Oracle's release. When a higher Oracle quarterly patch version is available, **Patch Available** appears next to the service status on both the My Services dashboard and the database service home page.

***

## How do I know when a patch is available?

Two visual cues appear:

* **Patch Available** label next to the service status on the My Services dashboard.
* A patch icon on the service status row — hovering shows available versions.

Click **Patch Now** to open the patch wizard.

***

## How do I apply an Oracle patch?

> **Note:** Tessell highly recommends taking a snapshot of the database before patching to prevent any data loss.

1. Hover over **Patch Available** next to the service status → click **Patch Now**.
2. In the **Patch Database Engine Version** window:
   1. Select the target Oracle version from the dropdown list.
   2. (Optional) Adjust the number of instances to patch if the service has more than one instance. By default, all instances are included. The primary and HA instances are always patched together — you cannot deselect the HA instance from the primary.
   3. Review the estimated service downtime shown in the dialog.
   4. Select the **Patch Database Engine Version** checkbox.
   5. Click **Start Patch**.

Tessell then performs the following steps automatically:

1. Submits the request to patch DB service instances from the older to the new version.
2. Installs the new Oracle binaries.

   > **Note:** In a multi-service deployment, binary installation is performed only for the first service being patched.
3. Patches the DB service instance(s).
4. Sets the service status to **Ready** and updates Tessell metadata.

***

## How does Tessell minimize downtime during HA patching?

For HA services, Tessell uses **Standby-First patching with rollover**:

1. The standby (HA replica) is patched first while the primary continues serving traffic.
2. A **switchover** is performed to promote the patched standby to primary — this is the only period of downtime, limited to the switchover duration.
3. The original primary (now standby) is patched.
4. By default, roles remain swapped after patching (the patched standby becomes the permanent primary).

> **Note:** If you want the original primary and standby roles restored after patching, contact Tessell support to enable the role-restore feature flag. When enabled, a second switchover is triggered at the end of patching to restore the original roles.

***

## When is source patching blocked?

Patching the source is blocked when an active clone refresh schedule exists at a lower patch version. If a clone has an active refresh schedule and the clone is at a lower patch version than your intended patch target, Tessell blocks the source patch operation.

**Resolution:** Delete or pause the clone's refresh schedule before patching the source.

> **Note:** Tessell also supports publishing one-off Oracle patches to the platform. Contact Tessell support if you need a specific one-off patch applied.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.tessell.com/tessell/database-engines/tessell-for-oracle/db-services/my-services/patching.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.