> 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/availability-machines.md). # Availability Machines The Availability Machine (AM) is the data management and data governance hub for each Oracle database service in Tessell. It provides a centralised interface for snapshots, native RMAN backups, data sanitization, data access policies, and cloning — all in one place. Every provisioned database service automatically gets an associated AM. *** ## Prerequisites Ensure that you have created your database service in the **Provisioning** application under the **DB Services** app family. For more information, see [Provisioning an Oracle DB service](/tessell/database-engines/tessell-for-oracle/db-services/provisioning-an-oracle-db-service.md). *** ## What can I do in an Availability Machine? | Capability | Description | | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **Snapshots** | Automatically capture cloud-native, application-consistent point-in-time copies on a configured schedule; take manual ad-hoc snapshots at any time | | **Transaction logs** | Continuously archive transaction (redo) logs every 5 minutes to object storage for near-zero RPO and PITR | | **Native Backups** | Create Oracle RMAN full and incremental backups from the source CDB/PDB or from an existing snapshot | | **Sanitization** | Mask or anonymise sensitive data (PII, card numbers, etc.) using your own SQL scripts before creating copies for lower environments | | **Data Access Policies (DAP)** | Control what data is shared, with whom, in which region, and on what schedule — across subscriptions and clouds | | **Clones** | Provision a full database clone from any snapshot or PITR recovery point | | **Sharing** | Share the AM itself with other Tessell users (Co-owner or Read-only) | *** ## What does the Availability Machines dashboard show? Navigate to **DB Services → Availability Machines** to view the dashboard. It lists all AMs you can access. ### Dashboard filters | Filter | Behaviour | | ---------------- | --------------------------------------------- | | **Search** | Filter by database service name | | **Engine** | All, MySQL, Oracle, PostgreSQL, or SQL Server | | **Cloud** | All, AWS, Azure, or GCP | | **Owner** | Filter by a specific username or All | | **Subscription** | Filter by cloud subscription or All | | **Clear** | Reset all filters to defaults | ### Dashboard columns | Column | Description | | -------------------- | -------------------------------------------------------------------------- | | **Name** | Database service name with engine icon. Click to open the AM home page. | | **Cloud and Region** | Cloud provider and region where the source DB service is hosted | | **DAPs** | Number of data access policies configured for this AM | | **Source DB Status** | Current status of the associated database service (see table below) | | **Created** | Date, time, and username that provisioned the database service | | **Ellipsis icon** | Available only when the source DB is deleted — allows you to delete the AM | ### Source DB status reference | Status | Description | | ----------- | ----------------------------------------------------------------------------- | | **Ready** | Source database is running; connections are accepted | | **Stopped** | Source database is not running; connections are not accepted | | **Deleted** | Source database has been deleted; the AM remains until you delete it manually | *** ## What does the Availability Machine home page show? Clicking a service name on the dashboard opens its AM home page. The source DB status is shown next to the service name. ### Top-right buttons | Button | Action | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **DB Service** | Opens the My Services home page for this database service. See [My Services](/tessell/database-engines/tessell-for-oracle/db-services/my-services.md). | | **Dataflix** | Opens the Dataflix home page for this database service. See [Dataflix](/tessell/database-engines/tessell-for-oracle/db-services/dataflix.md). | | **Update RPO Policy** | Opens the RPO policy wizard to configure snapshot and native backup schedules and transaction log archival. | ### Summary panel Expand the top bar to view a summary of the AM, grouped into three sections: **RPO Policy and DB details** | Field | Description | | -------------------- | --------------------------------------------- | | **RPO Policy** | Retention days and backup type as configured | | **Transaction Logs** | Whether transaction log archival is enabled | | **Source DB Status** | Current status of the source database service | **Cloud details** | Field | Description | | ---------- | ------------------------------------------- | | **Cloud** | Cloud provider hosting the database service | | **Region** | Cloud region of the database service | **User details** | Field | Description | | ----------- | ---------------------------------------------------------------------------- | | **Owner** | Tessell account username of the AM owner | | **My role** | Your role: Owner, Co-owner, or Read-only | | **TRN** | Tessell Resource Name — globally unique identifier for use with Tessell APIs | The AM home page has the following tabs: **Data Flow**, **Snapshots**, **Sanitization**, **Native Backups**, **RPO Policies**, **Access Policies**, **Clones**, and **Sharing**. *** ## How do I update the RPO Policy? Click **Update RPO Policy** on the AM home page. The **Update RPO Policy and Schedule** window opens with three configurable sections: ### Include Transaction Logs Select the **Include Transactional Logs** checkbox to enable Tessell to archive transaction logs (Oracle archive logs) every 5 minutes. Logs are stored in Amazon S3 (AWS) or Azure Blob Storage (Azure). Transaction logs are required for PITR. ### Schedule Snapshots Toggle **Schedule Snapshots** to enable automated snapshot capture. Tessell uses cloud-native snapshots as the default backup mechanism. Snapshots are application-consistent, always incremental, and faster to restore than traditional backups. 1. Select a configuration type: **Standard** or **Custom**. 2. For **Standard**: * Specify snapshot retention (1–35 days). * Pick the daily time for snapshots. 3. For **Custom**: * Choose an RPO policy from the dropdown (create policies in [DB Governance](/tessell/app-families/governance/db-governance.md) under Governance). * Pick the daily time for snapshots. * Review the **RPO Policy Details** panel (policy description, type, and whether PITR is enabled). 4. Under **Snapshot frequency**, configure: | Field | Description | | -------------- | ------------------------------------------------------------------------------------------------- | | **RPO Policy** | Selected policy options: PITR, Daily, Weekly, Monthly, and/or Yearly Snapshots | | **Every** | Frequency for weekly/monthly/yearly schedules. Daily shows the scheduled time. Disabled for PITR. | | **Keep for** | Retention period (days) per the selected RPO policy | ### Schedule Native Backups Toggle **Schedule Native Backups** to enable automated Oracle RMAN backups. Backups are stored in the object storage of your cloud subscription. > **Best practice:** If multiple database services share a VM, stagger native backup times across services to avoid resource contention. 1. Select a configuration type: **Standard** or **Custom**. 2. For **Standard**: * Specify retention (7–35 days). * Choose a **Full backup day**, **Full backup time**, and **Incremental backup time**. 3. For **Custom**: * Choose an RPO policy from the dropdown. * Choose **Full backup day**, **Full backup time**, and **Incremental backup time**. * Review the **RPO Policy Details** panel. 4. Under **Backup frequency**, configure: | Field | Description | | -------------------- | --------------------------------------------------------------------------------------- | | **Policy Frequency** | Selected policy options: PITR, Daily, Weekly, Monthly, and/or Yearly Backups | | **Every** | Frequency for weekly/monthly/yearly. Daily shows the scheduled time. Disabled for PITR. | | **Keep for** | Retention period (days) per the selected RPO policy | 5. Click **Update** to apply all changes. *** ## What does the Data Flow tab show? The Data Flow tab is a visual representation of how data moves through the AM. * The **source DB box** represents your primary database service. * The **AM box** (centre) is the data management layer receiving continuous data from the source. * The **RPO policy box** (handshake icon) shows the configured backup schedule. * **Region boxes** show where snapshots and logs are replicated to, as configured by DAPs. A continuous stream flows from the source DB to the AM, representing ongoing snapshot and log capture. For multi-AZ services, snapshots and logs are taken from the primary node. Regions with manual snapshots only do not show a continuous data stream. Use the **+** / **−** icons (bottom left) to zoom in or out, or the expand icon to view in full screen. *** ## Snapshots Tessell automatically captures snapshots on the schedule defined by your RPO policy. You can also take manual ad-hoc snapshots at any time. The Snapshots tab shows all snapshots for the service. ### Snapshot status reference | Status | Description | | ------------- | ------------------------------------------------------------ | | **Available** | Snapshot is complete and ready to use | | **Queued** | Snapshot is scheduled and waiting for a prior task to finish | | **Creating** | Snapshot capture is in progress | | **Failed** | Snapshot did not complete successfully | ### Snapshot table columns | Column | Description | | ----------------- | --------------------------------------------------------------------------------------------------------------------- | | **Snapshot Name** | Name of the snapshot | | **Availability** | Number of regions where the snapshot is available. Click to see region name, status, access policy, and shared users. | | **Status** | Current snapshot status (see above) | | **Size (GiB)** | Snapshot size in GiB | | **Snapshot Time** | Exact date and time the snapshot was captured | The **Manual Snapshots** view lists all manually triggered snapshots. The **Automatic Snapshots** view lists snapshots taken per the RPO policy. Use the **Search** bar to find a snapshot by name; use the **Status** filter to narrow by state. > **Note:** Tessell does not automatically delete manual snapshots. You must delete them manually from this tab. ### How do I take a manual snapshot? 1. Click **+ Take Snapshot** (top right of the Snapshots tab). 2. Enter a **Snapshot Name**. 3. Click **Submit**. ### How do I star or unstar a snapshot? Automatic snapshots, automatic sanitized snapshots, and automatic native backups are deleted after their retention period. **Starring** an automatic entry prevents automatic deletion indefinitely. > **Note:** Manual snapshots, manual sanitized snapshots, and manual native backups are never automatically deleted — they do not need to be starred. **To star:** 1. In the **Automatic Snapshots** view of the Snapshots, Sanitization, or Native Backups tab, click the ellipsis icon on the entry → **Star**. 2. Review the notice (additional storage costs may apply) → click **Star** to confirm. A star icon appears next to the entry. The entry is retained until you unstar it. **To unstar:** 1. Click the ellipsis icon on the starred entry → **Unstar**. 2. Review the notice (the entry resumes its original retention schedule) → click **Unstar** to confirm. > **Note:** If the original retention period has already elapsed, the entry is queued for deletion immediately after unstarring. Starred snapshots and backups can be independently retained during service deletion. See [Delete the service](/tessell/database-engines/tessell-for-oracle/db-services/my-services/managing-services.md#how-do-i-delete-a-database-service). *** ## Sanitization Tessell sanitization creates a masked copy of production data before it is used in lower environments (testing, development, training). You provide a SQL masking script; Tessell applies it by: 1. Creating a temporary clone VM from the source snapshot. 2. Running the masking SQL script on the clone VM. 3. Capturing a new snapshot from the masked clone — this is the sanitized snapshot. Sanitized snapshots can be shared or used for cloning, just like regular snapshots. > **Prerequisite:** Upload your SQL masking script to the [Script Library](/tessell/database-engines/tessell-for-oracle/db-services/script-library.md) under **DB Services** before sanitizing. ### Sanitized snapshot table columns | Column | Description | | ----------------------- | ------------------------------------------------------------------------------------------------------------ | | **Snapshot Name** | Name of the sanitized snapshot | | **Status** | Available, Queued, Creating, or Failed | | **Schedule Name** | Name of the automated sanitization schedule that created this snapshot (empty for manual) | | **Size (GiB)** | Size of the sanitized snapshot in GiB | | **Script Name/Version** | Name and version of the SQL masking script applied | | **Availability** | Regions where the sanitized snapshot is available; click for region, status, access policy, and shared users | | **Snapshot Time** | Exact date and time the sanitized snapshot was captured | Filter sanitized snapshots using the **Status** filter or the **Script** filter. Use the **Search** bar to find by name. > **Note:** Sanitized snapshots can be starred to prevent automatic deletion. See [How do I star or unstar a snapshot?](#how-do-i-star-or-unstar-a-snapshot) ### How do I create a sanitized snapshot? 1. Click **+ Sanitize Snapshot**. 2. Enter a **Sanitized snapshot name**. 3. Choose a **Source snapshot** (manual or automatic) from the dropdown. 4. Choose a **Data masking script** from the dropdown. 5. Choose the **Script version**. 6. Click **Submit**. Use the **Code** button (bottom left of the dialog) to generate API calls in Shell, Python, Go, Java, JavaScript, or PowerShell. ### How do I create a sanitization schedule? Automated schedules sanitize snapshots at a configured frequency without manual intervention. 1. Click **+ Create Schedule**. 2. Fill in the schedule details: | Field | Description | | -------------------------- | ---------------------------------------------------------- | | **Schedule Name** | Name for this sanitization schedule | | **Description** | Optional description | | **Frequency** | Daily (every day) or Weekly (select specific days) | | **Keep each snapshot for** | Retention period for sanitized snapshots (days or weeks) | | **Snapshot name prefix** | Prefix for sanitized snapshot names (default: "Sanitized") | | **Script** | SQL masking script to apply | | **Script version** | Version of the selected script | 3. Click **Save**. Click **Show Schedules** to list all existing sanitization schedules. Each schedule entry shows: **Schedule Name**, **Script info** (name and version), **Retention**, **Snapshot Name Prefix**, and **Create on** (timestamp). *** ## Native Backups Native backups use Oracle RMAN to create full and incremental backups at the CDB or PDB level. Backups are stored in the object storage of your cloud subscription (your data plane account), not in Tessell-managed storage. Tessell supports two backup sources: * **From the source database**: backup runs directly on the source VM. * **From a snapshot**: a temporary clone VM is created from the selected snapshot; RMAN runs on the clone, removing load from the source database. > **Best practice:** If multiple database services share a VM, stagger native backup times across services to avoid I/O contention. ### Native backup table columns | Column | Description | | ---------------- | ----------------------------------------------------------------------------------------------------- | | **Backup Name** | Name assigned at creation | | **Status** | Available, Queued, Creating, or Failed | | **Size** | Backup size in GiB | | **Type** | Full or Incremental | | **Source** | Whether the backup was taken from CDB, PDB, or Snapshot | | **Availability** | Regions where the backup is available; click for region name, status, access policy, and shared users | | **Created on** | Date and time the backup was taken | | **Shared With** | Users with access to this backup | Use the **Search** bar to find a backup by name. Use the ellipsis icon on a row to **Delete** a backup. > **Note:** Native backups can be starred to prevent automatic deletion. See [How do I star or unstar a snapshot?](#how-do-i-star-or-unstar-a-snapshot) ### How do I create a manual native backup? 1. Click **+ Create Backup**. 2. Enter a **Backup Name**. 3. Choose the backup source: * **CDB** — full CDB backup from the source VM. * **PDB** — select the specific PDB from the dropdown. * **Snapshot** — select a source snapshot (manual or automatic) from the dropdown. A temporary clone VM is used; the source DB is not affected. 4. Click **Create**. Use the **Code** button to generate API calls in Shell, Python, Go, Java, JavaScript, or PowerShell. *** ## RPO Policies The RPO Policies tab displays all backup schedules configured for the CDB and its PDBs, for both snapshot-based and native backup-based schedules. You can also view and edit the **Transaction Logs** status (enabled or disabled) using the edit icon next to the status. ### RPO Policies table columns | Column | Description | | ---------------------- | --------------------------------------------------------- | | **Source** | Database name and type (CDB or PDB) the policy applies to | | **RPO Policy Details** | Policy configuration (e.g., Standard, 7 days) | | **Policy For** | Snapshot or Native Backup | | **Created On** | Date the policy was created | Use the ellipsis icon on a policy row to **Update** (modify the policy) or **Delete** (remove it). ### How do I add an RPO policy for PDB-level backups? 1. Click **Configure RPO Policy** (top right of the RPO Policies tab). 2. Under **Select Entity to Schedule**, select **PDB Level Backups**. 3. From **Select PDB to set Policy**, choose the PDB. 4. Select a configuration type: **Standard** or **Custom**. * **Standard**: set retention days (7–35), Full backup day, Full backup time, Incremental backup time. * **Custom**: choose an RPO policy from the dropdown → set Full backup day, Full backup time, Incremental backup time → review the RPO Policy Details panel (description, type, PITR status). 5. Under **Backup frequency**, set: | Field | Description | | -------------------- | ----------------------------------------------------------------------------------- | | **Policy Frequency** | PITR, Daily, Weekly, Monthly, and/or Yearly Backups | | **Every** | Frequency for weekly/monthly/yearly. Daily shows scheduled time. Disabled for PITR. | | **Keep for** | Retention period (days) per the selected RPO policy | 6. Click **Save**. *** ## Access Policies (DAP) A Data Access Policy (DAP) defines **what** data is shared, **with whom**, **where** (same or cross-region, same or cross-subscription), and **how** (as-is, sanitized, or native backup). DAPs enable data owners to make snapshots or logs available for secondary use cases — DR, testing, staging, archiving, migration — without copying data manually. ### DAP cross-region and cross-subscription support | DAP type | Same subscription, any region | Cross-subscription, same region | Cross-subscription, cross-region | | ------------------ | ----------------------------- | ------------------------------- | -------------------------------- | | **Snapshot-only** | Supported | Supported | Supported | | **PITR** | Supported | Supported | Not supported | | **Native Backups** | Supported | Supported | Supported | ### DAP table columns | Column | Description | | --------------------- | -------------------------------------------------------------- | | **Policy Name** | Name of the access policy | | **Status** | Active or Inactive | | **Shared Across** | Number of subscriptions the data is shared to | | **Content Type** | As-is, sanitized, or backups — and whether automated or manual | | **Available Content** | Frequency and retention period for the shared content | Use the **Search** bar to find a policy by name. Use the ellipsis icon on a policy row for **Manage Access**, **Update**, or **Delete Policy**. ### How do I create a Data Access Policy? 1. Click **+ Create Policy**. 2. In **Policy Name**, enter a name for the policy. 3. In **Target subscription**, configure the destination: * Choose a **subscription** from the dropdown. * Choose a **target region** for replication. * Choose an **encryption key**. * Add more regions or subscriptions if needed. * In **Add users to grant access**, select the users who can access the replicated data. 4. Select the **data access mode**: **As-Is Data** — share source snapshots and/or PITR logs without processing. * Choose **Automated** or **Manual** snapshots. * For automated: set frequency (PITR or Daily) and retention period. Default: 1 day for PITR, 7 days for daily. * For manual: select from the available manual snapshot list. **Sanitized Data** — share post-processed (masked) snapshots. * Choose **Automated** or **Manual** sanitized snapshots. * For automated: choose a sanitization schedule from the dropdown. If none exists, click **Click here** to create one. * Set frequency (Daily) and retention period (default: 7 days). * **Note:** PITR is only available in As-Is mode. **Backups** — share native RMAN backup access. * Choose **Automated** or **Manual** backups. * For automated: set frequency and retention period. * For manual: select from the available manual backups list. 5. Click **Submit**. Use the **Code** button (top right of the window) to generate API calls in Shell, Python, Go, Java, JavaScript, or PowerShell. ### How do I manage an existing access policy? Click the ellipsis icon on a policy row: **Manage Access** — add or remove users from an existing policy. 1. Select **Manage Access**. 2. Add or remove usernames. 3. Click **Update Access**. **Update** — modify the policy name, target subscription, or content settings. **Delete Policy** — permanently remove the policy. 1. Select **Delete Policy**. 2. Check the **Remove the access policy** confirmation checkbox. 3. Click **Remove**. > Deleting a policy revokes all user access granted through it and removes replicated cloud snapshots from the target regions. *** ## Clones The Clones tab lists all database clones created from this AM. Clones are full database services provisioned from a snapshot or PITR recovery point. They can be configured with an automatic refresh schedule to stay current with the source. ### Clones table columns | Column | Description | | ------------------ | --------------------------------------------------------------- | | **Name** | Cloned service name | | **Status** | Creating, Ready, Stopped, or Deleted | | **Cloud/Region** | Cloud provider and region of the cloned service | | **Source** | Source snapshot name, timestamp, and content type (e.g., as-is) | | **Infrastructure** | Compute shape of the cloned service | | **Created** | Date and time the clone was requested | Filter by owner using the **Owner** field next to the search bar. ### How do I create a clone? 1. Click **+ Create Clone**. This opens the Dataflix application with a list of available snapshots (timestamp, size, and regions). 2. Select a snapshot to review details (creation timestamp, size, databases, cloud details). 3. Click **Clone** to open the clone creation form. 4. Configure the clone: | Setting | Notes | | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | **Service name, description, tags** | Identify the clone | | **Cloud provider settings** | Region, VPC/VNet, subnet | | **Compute shape** | Parent database server configuration is shown; storage cannot be changed for a clone | | **Database instance** | Master credentials and connection settings | | **Refresh schedule** | **No schedule** or **Automatic refresh** (choose day, time, and mode: Snapshot or PITR) | | **Custom Scripts for Refresh** | Select pre- and post-scripts from the [Script Library](/tessell/database-engines/tessell-for-oracle/db-services/script-library.md) | | **Maintenance window** | Maintenance schedule for the cloned service | | **Performance Insights** | Enable/disable for the clone | | **Availability Machine** | AM configuration for the clone | > **Refresh mode notes:** > > * **Snapshot mode**: refreshes to the snapshot available at the configured time on the configured day(s). If no snapshot is available, the refresh is skipped. > * **PITR mode**: refreshes to the latest data available at the configured time on the configured day(s). If no data is available, the refresh is skipped. 5. Click **+ Clone Service** to submit. Tessell automatically: 1. Submits the clone request. 2. Creates the compute instance(s). 3. Configures the database. 4. Sets up the Availability Machine. 5. Triggers the first snapshot. Use the **Code** button to generate API calls in Shell, Python, Go, Java, JavaScript, or PowerShell. *** ## Sharing The Sharing tab allows you to share the Availability Machine with other Tessell users, granting them access to AM data (snapshots, backups, policies, and clones). ### How do I share the Availability Machine? 1. Click **Share** (top right of the Sharing tab). 2. Choose a **Role**: Co-owner or Read-only. 3. Search for users using the **Search** bar. 4. Move users from the **Choices** column to the **Chosen** column to grant access. > Only users with **Data Owner** roles appear in the Choices column. Manage users and roles in the [IAM application](/tessell/app-families/governance/iam.md) under Governance. 5. Click **Save**. ### How do I change a user's role or remove their access? The Sharing tab lists all users the AM is shared with and their roles. Click the ellipsis icon on a user row: **Change Role** 1. Select **Change Role**. 2. Choose **Co-owner** or **Read-only** from the dropdown. 3. Click **Update**. **Remove User** 1. Select **Remove User**. 2. Confirm the removal → click **Remove**. *** ## Glossary | Term | Definition | | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Clone** | A duplicate of an existing database provisioned from a snapshot or backup. Used for testing, development, or troubleshooting without affecting the production database. | | **Data Access Policy (DAP)** | Defines rules for sharing AM data — who can access it, what they can access, in which region, and under what schedule. | | **Native Backup** | A backup created using Oracle RMAN. Supports full and incremental backups for restoration. Stored in your cloud subscription's object storage. | | **Recovery Point Objective (RPO) Policy** | Defines the maximum acceptable data loss, measured in time. Controls how frequently snapshots, backups, and transaction log captures occur. | | **Snapshot** | A cloud-native, application-consistent, point-in-time copy of the database storage. Used to restore the database to a specific state or to create clones. | | **Sanitization** | The process of masking sensitive production data (PII, payment data, etc.) using a SQL script before creating a copy for lower environments. Sanitized snapshots can be safely shared for development, testing, or analytics. | | **Transaction Logs** | Sequential records of all database transactions (Oracle archive logs). Used for PITR and to maintain consistency after unexpected failures. Archived every 5 minutes by Tessell. | --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.tessell.com/tessell/database-engines/tessell-for-oracle/db-services/availability-machines.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.