> 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/faq/engines/oracle.md). # Oracle Common questions about Oracle Database on Tessell, covering editions, licensing, high availability, patching, and supported features. *** ### Q: Does Tessell support Oracle DB Links? **A:** Yes. Tessell for Oracle supports creating and using **database links (DB Links)** to connect to remote Oracle databases using standard Oracle SQL syntax. Key requirements: * The remote Oracle database must be network-accessible from your Tessell instance. * You must have `CREATE DATABASE LINK` privileges on both the Tessell instance and the remote database. * Use the standard `CREATE DATABASE LINK` syntax — no Tessell-specific changes needed. **Performance note:** DB Links involving large data transfers can add latency. Test and monitor query performance before using in production. *** ### Q: How does Tessell handle Oracle support issues? **A:** Tessell provides a tri-layer support model for Oracle: * **Infrastructure issues** (AWS, Azure, GCP): Tessell works directly with the cloud vendor on your behalf to triage and resolve. * **Tessell Management Service issues**: Handled entirely by Tessell support. * **Oracle engine issues**: Tessell works with you to document and explain the issue to **Oracle Support** (which you are entitled to via your existing Oracle license and support contract), and helps expedite resolution. *** ### Q: What are typical RPO and RTO numbers for Oracle on Tessell? **A:** For **Oracle HA Service** (using Data Guard): * **RPO**: Near-zero (sub-second) with synchronous Data Guard replication. * **RTO**: Typically under 60 seconds for automatic failover. For **DR** configurations across regions, RTO depends on network latency between regions and application reconnection time. *** ### Q: Does Tessell provide Oracle licenses, or do I need to bring my own (BYOL)? **A:** Tessell supports only **Bring Your Own License (BYOL)**. Tessell does not bundle or sell Oracle database licenses. You must supply your own Oracle Database license before running Oracle on Tessell. Key points: * If you have an **Unlimited License Agreement (ULA)** with Oracle that includes Oracle Database, you can apply that license to your Tessell-hosted instances. * You must ensure compliance with Oracle's licensing rules for cloud environments. Refer to Oracle's guide: [Licensing Oracle Software in the Cloud Computing Environment](https://www.oracle.com/assets/cloud-licensing-070579.pdf). * You must separately license any Oracle options or features (e.g., Oracle Advanced Security, Partitioning, RAC) that you use beyond what your base license covers. *** ### Q: Which Oracle Database editions does Tessell support? **A:** Tessell supports the following Oracle Database editions: | Edition | Notes | | ---------------------------- | --------------------------------------------------------------------------------- | | **Enterprise Edition (EE)** | Full feature set; supports Data Guard HA, multi-AZ, DR, and all EE options. | | **Standard Edition 2 (SE2)** | Cost-effective; supported for single-instance and HA topologies on select clouds. | The license for all editions is owned by the customer. Tessell supports the complete feature set offered by the respective edition. *** ### Q: Can I change the Oracle edition I'm running for a DB service (e.g., from SE2 to EE)? **A:** Yes, but only in the upgrade direction. Under the [BYOL model](#q-does-tessell-provide-oracle-licenses-or-do-i-need-to-bring-my-own-byol), you can move from **Standard Edition 2 to Enterprise Edition** as long as you hold an unused Oracle license appropriate for the target edition and compute class. **Downgrading from Enterprise Edition to another edition is not supported.** Tessell does not convert a running DB service's edition in place. To change edition: 1. Take a **snapshot** of the running DB service. 2. Create a **new DB service** of the desired edition from that snapshot. 3. Validate the new service, then delete the old one — or keep both running if you have sufficient licenses for each. *** ### Q: How does the license option impact Oracle version upgrades? **A:** Patching and version upgrades require an active **Software Update License & Support** entitlement from Oracle, in addition to your base Oracle Database license. Tessell's patching automation (see [How does Oracle database patching work in Tessell?](#q-how-does-oracle-database-patching-work-in-tessell)) validates and applies Oracle-released patches, but this depends on your Oracle support contract remaining current — Tessell cannot apply a patch your license doesn't entitle you to. *** ### Q: How does the license option impact DB service scaling? **A:** You can resize (scale up or down) an Oracle DB service's compute shape at any time, but the change must stay compliant with your Oracle licensing terms. Oracle license fees are typically driven by: * The **number of vCPUs** assigned to the DB service, and * The **deployment model** — a Multi-AZ deployment requires licensing both the primary and standby nodes (see [Will I need additional Oracle licenses for Multi-AZ deployments?](#q-will-i-need-additional-oracle-licenses-for-multi-az-deployments)). Before scaling to a larger compute shape, confirm you hold sufficient licensed capacity for the target vCPU count. Licensing compliance is the customer's responsibility. *** ### Q: Which Oracle Database versions and patch sets does Tessell support? **A:** Tessell stays current with Oracle's own support lifecycle. Tessell supports all Oracle DB versions and patch sets that **Oracle currently supports**. When Oracle announces end-of-support for a version, Tessell's support policy for that version is updated accordingly. For the current list of supported versions, minor releases, OS versions, and cloud regions, see the [Oracle Support Matrix](/tessell/database-engines/tessell-for-oracle/oracle-support-matrix.md). *** ### Q: What is Azure Tessell for Oracle? **A:** **Azure Tessell for Oracle** is a Database-as-a-Service (DBaaS) offering that provides Oracle self-service and Oracle DevOps integration on Microsoft Azure — without requiring customers to deploy or manage underlying infrastructure. Key capabilities: * **Self-service provisioning**: Deploy Oracle databases in minutes through the Tessell console or API. * **High performance**: Durable data infrastructure with high IOPS architecture across multiple attached disks. * **Cross-region replication**: Built-in support for disaster recovery across Azure regions. * **Enterprise governance and security**: Role-based access, encryption, audit logging, and compliance controls. * **DevOps integration**: Clone, refresh, and branch databases as part of CI/CD pipelines. Tessell manages the infrastructure and Oracle lifecycle operations behind the scenes, freeing developers and DBAs to focus on the database itself. *** ### Q: Is Azure Tessell for Oracle certified by Oracle? **A:** Yes. Tessell uses Oracle-certified Azure infrastructure. Tessell installs and configures Oracle databases on Azure VMs and manages them on the customer's behalf. Tessell supports the following licensed Oracle functionality on Azure: | Feature | Description | | ------------------------------------- | -------------------------------------------------- | | **Container Databases (CDB/PDB)** | Multi-tenant database architecture | | **Native RMAN backups** | Oracle's Recovery Manager for physical backups | | **Flashback** | Point-in-time recovery and table flashback | | **Automatic Storage Manager (ASM)** | Oracle's volume manager for database storage | | **Clone Refresh** | Automated refresh of clone databases from a source | | **Oracle Label Security** | Row-level access control | | **Transparent Data Encryption (TDE)** | Encryption at rest | | **Oracle Data Guard** | HA and DR replication | | **Oracle Enterprise Manager (OEM)** | Monitoring and management integration | *** ### Q: How can I implement Oracle Maximum Availability Architecture (MAA) with Tessell? **A:** Tessell natively supports Oracle MAA principles through its multi-AZ and cross-region architecture, on any cloud Tessell supports: **High Availability (within a region):** * Tessell deploys **active standby Oracle database configurations** spanning availability zones — for example, across **Azure Availability Zones** — using **Oracle Data Guard**. * Both the active and standby instances have **independent storage** and independently running Oracle database instances (shared-nothing architecture). * A **database proxy** provides connection pooling so that, in the event of a primary failure, client connections **transparently fail over** to the standby instance without application-side changes. **Disaster Recovery (cross-region):** * Availability can be further enhanced by replicating data across regions — for example, across **Azure regions** — to a **DR instance**. * If an entire region fails due to a natural or man-made event, a **global IP failover** redirects traffic to the DR instance automatically. | Tier | Mechanism | Scope | | ---- | -------------------------------- | ------------------------ | | HA | Oracle Data Guard (synchronous) | Cross-AZ within a region | | DR | Oracle Data Guard (asynchronous) | Cross-region | This architecture maps directly to Oracle's Gold or Platinum MAA tiers. For RPO and RTO specifics, see the [RPO/RTO question above](#q-what-are-typical-rpo-and-rto-numbers-for-oracle-on-tessell). *** ### Q: How can I perform cross-region snapshots and point-in-time restore (PITR) for Oracle disaster recovery? **A:** Tessell supports **cross-region automated snapshots** for Oracle using the **Availability Machine**. When this feature is enabled: * Snapshots and archived log backups captured in the source region (where your primary instance runs) are automatically replicated to a second region. * The Availability Machine maintains snapshots and archived logs according to your chosen backup retention period. * This enables **PITR** and **cloning** capabilities in the destination region. This gives you full time-travel recovery with maximum recoverability across regions. *** ### Q: Does Tessell for Oracle support Database Access Monitoring (DAM) and Oracle Enterprise Manager (OEM)? **A:** Yes. Tessell provides **controlled access** to external security and management services: * **Database Access Monitoring (DAM)**: Supported as an external integration. DAM tools can connect to Tessell-managed Oracle instances to monitor and audit database activity. * **Oracle Enterprise Manager (OEM)**: Supported as an external management integration. Both integrations require the external tool to be network-accessible from your Tessell instance and configured separately on the tool's side. *** ### Q: Does Tessell support memory-optimized or high-memory compute instances for Oracle? **A:** Yes. Tessell for Oracle supports all major compute instances offered by AWS and Azure, including memory-optimized and NVMe-based options: | Cloud | Example instance families | | --------- | --------------------------------------------------------------------------------- | | **AWS** | NVMe-based `i3en`, `i4i`, `r` series (memory-optimized), `x` series (high-memory) | | **Azure** | `L` series (NVMe storage), `M` series (memory-optimized) | This means you can choose instances with a **larger memory footprint relative to vCPU count** — useful for Oracle workloads with large buffer caches or in-memory processing requirements. *** ### Q: Which character sets are supported for Oracle Database on Tessell? **A:** Tessell supports **all character sets in the Oracle ASCII Character Sets list**. You can specify your desired character set when creating a new database service. * **Default character set**: `AL32UTF8` (Unicode, recommended for most deployments) * Character set selection is optional — if you don't specify one, `AL32UTF8` is used automatically. * The character set is set at database creation time and **cannot be changed afterward** without rebuilding the database. *** ### Q: Is Oracle RAC supported on Tessell? **A:** **No. Oracle RAC is not currently supported** on Tessell for AWS, Azure, or GCP. **Why:** Oracle RAC requires **shared block storage** simultaneously visible to all cluster nodes, plus a dedicated cluster stack — Oracle Grid Infrastructure, network interconnect, OCR (Oracle Cluster Registry), and voting disks. While AWS (EBS Multi-Attach), Azure (shared disks), and GCP (multi-writer PD) do offer shared block storage primitives, Tessell does not currently support the RAC cluster orchestration layer required to provision and manage RAC instances on any cloud. **Alternative for high availability:** Tessell implements HA for Oracle using **Oracle Data Guard** in a Multi-AZ topology, which provides automatic failover with synchronous replication and near-zero RPO. See [How does Tessell use Oracle Data Guard for Multi-AZ deployments?](#q-does-tessell-use-oracle-data-guard-for-multi-az-deployments) *** ### Q: Will I need additional Oracle licenses for Multi-AZ deployments? **A:** Yes. For Multi-AZ Oracle deployments, you should expect to license **twice as many processor cores** compared to a Single-AZ deployment, to account for the standby DB service instance. * Each node in a Multi-AZ cluster (primary + standby) runs a full Oracle instance and must be licensed. * Review your **Oracle Software Licensing Agreement** to verify the exact terms that apply to your situation. * Tessell recommends consulting with your Oracle licensing representative before deploying Multi-AZ production workloads. Licensing compliance is the customer's responsibility. *** ### Q: Does Tessell use Oracle Data Guard for Multi-AZ deployments? **A:** Yes. Tessell uses **Oracle Data Guard** combined with Tessell automation to provide automatic failover for Oracle HA deployments: | Topology | Replication mode | | ------------------------------------- | --------------------------------------------------------------------- | | **Multi-AZ** (within a single region) | **Synchronous** replication — zero data loss on failover | | **Multi-Region** (cross-region DR) | **Asynchronous** replication — small lag depending on network latency | Tessell's automation layer manages the Data Guard configuration, standby instance provisioning, and failover orchestration — so you get the Oracle-native HA mechanism without manually configuring Data Guard. Requires **Oracle Enterprise Edition**. *** ### Q: What are parameter profiles and option profiles for Oracle on Tessell? **A:** **Parameter profiles** act as containers for Oracle database engine configuration values applied to one or more database instances. Tessell provides: * **Default parameter profile**: Pre-set with Oracle engine defaults and Tessell's recommended defaults for your engine version, compute class, and allocated storage. You cannot modify a default profile. * **Custom parameter profiles**: Create and manage your own parameter profiles via the **Database Governance app** in the Tessell console. Apply them to individual instances or Multi-AZ clusters. **Static vs. Dynamic parameters:** | Type | When change takes effect | | ----------- | ---------------------------------------------- | | **Static** | After a manual reboot of the database instance | | **Dynamic** | Immediately, without a reboot | **Option profiles** are also available for Oracle and can be customized from the DB Governance app. The following options can be configured: | Option | Description | | ----------------------------- | ----------------------------------------------------------------------- | | **Locator** | Oracle Locator for internet/wireless service and partner GIS solutions | | **Native Network Encryption** | Oracle native data network encryption and integrity for data in transit | | **TDE** | Transparent Data Encryption — encrypts data at rest | | **UTL Mail** | Email utility supporting attachments, CC, and BCC | *** ### Q: How does Oracle database patching work in Tessell? **A:** Tessell handles Oracle minor version patching as a managed, self-service operation: **Patch lifecycle:** 1. Oracle releases a minor version patch. 2. Tessell's Oracle SME team validates the patch for security and compliance. 3. Validated patches are published as **public AMIs** and made available in the Tessell control plane. 4. Customers see available patches against all candidate database instances and can apply, discard, or schedule. **For HA database clusters**, Tessell uses the **standby-first methodology**: * Standby instances (DR and read replicas) are patched first. * Then the primary instance is patched. * Required switchover is **automatically handled** by Tessell DBaaS. **Automated steps during patching:** * A new volume with the patch AMI is created in the data plane. * A new Oracle Home is installed with updated binaries. * Data is moved to the new volume. * Tessell validates the applied patch. * Oracle **Datapatch** is applied for post-patch SQL actions. * Notification is sent on successful completion. Tessell supports all Oracle database versions and patch sets that Oracle itself supports. When Oracle announces end-of-support for a version, Tessell's support policy adjusts accordingly. *** ### Q: Does Tessell support Oracle GoldenGate replication? **A:** Yes. **Tessell supports Oracle GoldenGate** for replicating data from an Oracle database to a Tessell-managed Oracle instance. **Setup requirements:** * Install GoldenGate on a **target instance** that can communicate with the Tessell for Oracle instance over the network. * Configure GoldenGate to replicate from the source Oracle database to the Tessell Oracle instance. * Some GoldenGate features may require **manual configuration** on the target GoldenGate instance. GoldenGate is commonly used for zero-downtime migrations, real-time data distribution, and heterogeneous replication scenarios. *** ### Q: What is AWS Tessell for Oracle? **A:** **AWS Tessell for Oracle** is Tessell's Database-as-a-Service (DBaaS) offering for running Oracle databases on **Amazon Web Services** infrastructure. It provides: * **Oracle self-service**: Provision, scale, clone, and manage Oracle database instances without deploying or managing the underlying EC2 infrastructure. * **Oracle DevOps integration**: Integrate database lifecycle management into CI/CD pipelines. * **Enterprise governance and security**: Role-based access control, audit logging, and compliance-ready configurations. * **Cross-region replication**: High-performance, durable data infrastructure with built-in DR capabilities. AWS Tessell for Oracle is the AWS-specific variant of the same platform available on Azure. Both offer the same core capabilities and management experience. *** ### Q: Is AWS Tessell for Oracle certified by Oracle? **A:** Yes. **Tessell uses Oracle-certified AWS infrastructure**. Tessell installs and configures Oracle databases on **Amazon EC2** and manages them on your behalf. Supported Oracle-certified features on AWS include: | Feature | Supported | | --------------------------------- | --------- | | Container Databases (CDB/PDB) | ✅ | | Native RMAN backups | ✅ | | Flashback | ✅ | | Automatic Storage Manager (ASM) | ✅ | | Clone Refresh | ✅ | | Oracle Label Security | ✅ | | Transparent Data Encryption (TDE) | ✅ | | Oracle Data Guard | ✅ | | Oracle Enterprise Manager (OEM) | ✅ | Because Tessell runs Oracle on certified AWS infrastructure and uses standard Oracle installation procedures, your Oracle workloads are supported by Oracle in the same way as any Oracle deployment on EC2. *** ### Q: If I have a ULA or PULA with Oracle, how can I use it with Tessell? **A:** An **Oracle ULA** (Unlimited License Agreement) provides unlimited access to specific Oracle products for a **fixed term**. A **PULA** (Perpetual Unlimited License Agreement) provides the same unlimited access for an **indefinite term**. To use your ULA/PULA with Tessell: 1. **Verify version support**: Confirm that Tessell supports the Oracle database version you licensed under your ULA. 2. **Create a database service**: Provision an Oracle database service in Tessell using the licensed version. 3. **Select licensed options**: During service creation, choose any Oracle options or features covered under your ULA (e.g., Advanced Compression, Diagnostics Pack, TDE, etc.). 4. **Migrate your data**: Use your preferred migration method to move data to the Tessell instance. 5. **Connect your application**: Update your application connection strings to point to the Tessell endpoint. **Important:** Tessell provides the managed infrastructure, but it is **your responsibility** to configure your database instances to ensure ULA compliance. Consult your Oracle licensing team to confirm that cloud deployments on Tessell infrastructure are permitted under your ULA terms. *** ### Q: How do I configure .NET applications to work with Tessell Oracle High Availability? **A:** Tessell's High Availability (HA) implementation for Oracle uses Data Guard with Fast-Start Failover. An HA event will cause the IP address of the Primary database to change. Applications using connection pools need to be able to handle the state change event, recycle the pool, and connect to the new IP address with little to no disruption to the application. **Failover configuration** First, it is important to understand how .NET handles connection pools underlying your own applications and the Oracle Data Provider ([ODP.NET](https://docs.oracle.com/en/database/oracle/oracle-database/21/odpnt/index.html) driver) code. According to Microsoft documentation in MSDN: > If MinPoolSize is either not specified in the connection string or is specified as zero, the connections in the pool will be closed after a period of inactivity. However, if the specified MinPoolSize is greater than zero, the connection pool is not destroyed until the AppDomain is unloaded and the process ends. Maintenance of inactive or empty pools involves minimal system overhead. To summarize, with default settings an application will never recycle a connection pool unless the application process is restarted. This is done to minimize the use of resources unless the user explicitly defines different connection pool strategies. Second, it is important to understand how the ODP driver handles HA events. Under normal conditions Oracle Data Guard will signal that an HA event has happened. However, the ODP configuration has to be explicitly activated to respect the signal. Oracle states: > ODP applications can enable FCF through the High Availability Events, "HA Events", connection string attribute. When HA Events are enabled: > > * ODP connection pool proactively removes connections from the pool when a node, or database goes down. > * ODP proactively forces threads waiting for responses from the downed database to exit out from the existing call to avoid any hangs. When such a connection is then returned to the pool, any resource associated with that connection is freed. > * ODP establishes connections to existing Oracle instances if the removal of severed connections brings the total number of connections below the "min pool size", upon the next connection request. > > By default this feature is disabled. To enable HA events, include "HA Events=true" in the connection string. Thus, a basic connect string to enable this feature would look like: ``` data source=myServiceName; User Id=myuser; Password=mypassword; HA events=true; ``` However, there may be other cases where the HA events flag may not be enough to survive a disaster. You need to ensure you have other methods to time out and recycle connections. The pool will never close all connections until they time out, which by default could take a very long time and in some cases could be persistent. You can tune for this in the connection string by adding configurations such as: ``` data source=myServiceName; User Id=myuser; Password=mypassword; HA events=true; Min Pool Size=0; Max Pool Size=200; Connection Lifetime=60; Connection Timeout=30; Incr Pool Size=20; Decr Pool Size=5; ``` > **Note:** There is also an attribute to validate connections, but this has not been tested in the scope of this document. You can add the below config to your connection string if needed. > > The `Validate Connection` attribute validates connections coming out of the pool. This attribute should be used only when absolutely necessary, because it causes a round-trip to the database to validate each connection immediately before it is provided to the application. If invalid connections are uncommon, developers can create their own event handler to retrieve and validate a new connection, rather than using the `Validate Connection` attribute. This generally provides better performance. > > ``` > Validate Connection=true; > ``` The following configuration settings are typically used to manage connection pooling behavior: ``` Connection Lifetime = Connection Timeout = Decr Pool Size = # how many connections to close at a time HA Events = # Respect HA dataguard events Incr Pool Size = # how many connections to add at a time Max Pool Size = Min Pool Size = Pooling = # this disables it completely Validate Connection = ``` Please note that configurations can also be placed in .NET configuration files. As a sanity check you should make sure the .NET `machine.config` file in `C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config` (or similar version directory) does not have any hard-coded connection strings or settings. You will find a `` section in the file. You can also check if any settings have been placed to control the ODP behavior in the `` section. `machine.config` applies global settings, but this is not the only .NET config file where configurations can be defined — config files in the applications themselves could also contain hardcoded settings. If you are troubleshooting connection pooling issues you can turn on tracing for ODP in the .NET `machine.config` on the server. In the `machine.config` place the example below within the `` section and after ``: ```xml ``` After applying configurations to the connect string, `machine.config`, etc., you may need to restart the application to recycle the connection pools and inherit the new configuration. The following links provide additional reference and reading: * [Developer's Guide](https://docs.oracle.com/en/database/oracle/oracle-database/21/odpnt/release_changes.html#GUID-EC011023-E5AD-4D47-8521-4B64F8875CA6) * [Client Failover Best Practices (PDF)](https://www.oracle.com/technetwork/database/availability/client-failover-2280805.pdf) *** ### Q: How do I create a custom password verify function for Oracle on Tessell? **A:** You can create custom verification logic and avoid storing your function in the `SYS` schema by using the procedure `tesselladmin.database_password_policy.create_passthrough_function`. This procedure creates a wrapper function in the `SYS` schema for your custom password verification function. The `create_passthrough_function` procedure has the following parameters: | Parameter name | Description | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `p_function_name` | The name for your custom verification function. This is a wrapper function that is created for you in the SYS schema, and it doesn't contain any verification logic. You assign this function to user profiles. | | `p_target_schema` | The schema owner for your custom verification function. | | `p_target_function_name` | The name of your existing custom function that contains the verification logic. Your custom function must return a boolean. Your function should return true if the password is valid and false if the password is invalid. | *All parameters are required and have `VARCHAR2` as data type.* ```sql BEGIN tesselladmin.database_password_policy.create_passthrough_function( p_function_name => 'CUSTOM_PASSWORD_FUNCTION_IN_SYS', p_target_schema => 'MASTER', p_target_function_name => 'CUSTOM_PASSWORD_LOGIC_FUNCTION_IN_MASTER'); END; / ``` *** ### Q: How do I migrate my on-premises Oracle database to Tessell? **A:** The migration approach depends on your Oracle edition, database size, and acceptable downtime window: | Edition | Method | How it works | | ---------------------- | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Standard Edition** | RMAN backup + restore | Tessell uses the native RMAN utility to take a full backup of the on-premises database and restore it on the Tessell platform. Incremental logs are then applied to bring the database in sync before cutover. For smaller databases, Data Pump export/import can be used instead. | | **Enterprise Edition** | Oracle Data Guard | Tessell configures Oracle Data Guard between the on-premises database and the Tessell DB service to enable live replication. Once the databases are in sync, a planned switchover is performed to promote the Tessell service as primary. | *** ### Q: Does Tessell provide tooling or migration assistance? **A:** Yes. The **Tessell Customer Success team** owns the migration strategy end-to-end. They work with you to finalize the best approach based on your database size, expected downtime tolerance, and whether you need a lift-and-shift, upgrade, or refactoring. For upgrade and refactoring scenarios, Tessell also works with certified partners on your chosen cloud — for example, Azure Certified Partners. *** ### Q: What is the process for migrating to Tessell Oracle HA Service specifically? **A:** The Oracle HA Service migration follows three phases — see the [step-by-step guide](#migration-phases) below. *** ### Q: Can I roll back if the cutover doesn't go as expected? **A:** Yes. During the cutover window, the on-premises database remains part of the Data Guard configuration as a standby. If the new Tessell environment does not perform as expected after switchover, you can perform a **failback** — switching the on-premises database back to primary and restoring the original connection string in your applications. *** ### Q: How long does each migration phase take? **A:** Phase 1 (preparation and initial sync) duration depends on database size and network bandwidth. Phase 2 (cutover) is designed to be brief — downtime begins when applications are shut down on the source side and ends once applications are validated against the Tessell service. Phase 3 (decommissioning the on-premises node) is recommended 10–15 days after Phase 2, once applications are confirmed stable. *** ## Migration phases This guide covers migrating an Oracle database from on-premises to **Tessell Oracle HA Service** (2 DB Nodes + 1 Observer Node) using Oracle Data Guard. ### Phase 1 — Prepare **On the source side (on-premises / MMC):** 1. Enable the on-premises database for Data Guard (DG) configuration. 2. Take a full backup of the database including the spfile and control files. 3. Upload the backup to cloud object storage (e.g., Azure Blob Storage) or a jumpbox server in your cloud environment. **On the Tessell side:** 1. Provision a Tessell Oracle HA Service with 2 DB Nodes + 1 Observer Node, sized to match the on-premises compute and storage requirements. 2. Disable the Observer and disable the DG configuration between the two Tessell nodes. 3. Restore the backup provided from the source side on both Tessell nodes. 4. Configure Oracle Data Guard to set up the two Tessell nodes as DR replicas of the on-premises database.

Figure 1 — Phase 1

*** ### Phase 2 — Cutover primary to Tessell This phase can begin once the Data Guard lag between the on-premises database and the Tessell nodes is near zero. 1. Shut down applications on the source (on-premises / MMC) side. 2. Confirm the replication lag between on-premises and Tessell HA nodes is **0**. 3. Perform a **switchover** to promote one of the Tessell nodes as the new primary. 4. Update application connection strings to use the **Tessell service connection string**. 5. Convert replication between the two Tessell nodes to **Sync mode** (`MAX_AVAILABILITY`). 6. Configure the Observer on the Tessell side to perform automatic failover only between the two Tessell nodes. 7. Validate that the on-premises database can receive data from the Tessell Oracle HA service (it is now the standby). 8. Validate applications against the new primary. 9. **Downtime ends.**

Figure 2 — Phase 2

> **Rollback:** If the new environment does not perform as expected, failback to the on-premises database as primary and restore the original application connection strings. *** ### Phase 3 — Remove on-premises from DG config *Perform this phase 10–15 days after Phase 2, once applications are confirmed stable.* 1. Remove the on-premises database from the Data Guard configuration. 2. Optionally, decommission (delete) the on-premises database.

Figure 3 — Phase 3

--- # 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/faq/engines/oracle.md?ask=&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.