Your search did not match any results.
We suggest you try the following to help find what you're looking for:
Oracle Database Cloud Service lets you easily build, scale, and secure Oracle databases in the cloud. You create databases on DB Systems, which are either bare metal servers (with local NVMe flash or SSD storage) or virtual machines with block volumes, both of which provide high performance and cost-efficient pricing. The service also enables support for 'cloud-first' Oracle RAC implementation on virtual machine servers at the virtual cloud network layer.
You can manage your databases using simplified tools like patching, Data Guard or backup/recovery, all of which can be accessed using the Oracle Cloud Infrastructure REST APIs or console. Alternatively, you can access your database host and use your existing tools to manage your databases in the cloud, the same way you manage them on-premises.
Oracle Database Cloud Service provisions a DB System with the requested number of cores on a high performance bare metal server or virtual machine, deploys Oracle Database software with the edition of your choice, and creates the DB System in a virtual cloud network (VCN). The VCN is a private network with user-configured security lists which protects the DB System from unauthorized access.
Oracle Database Cloud Service also provides manageability features like database service patching, configuring high availability using Oracle Data Guard and backup/restore which simplifies day-to-day tasks required to run your Oracle databases.
Bare metal servers and virtual machines support Oracle's Universal Credit Model (UCM) with 'license included' and 'bring your own license' pricing. Pricing is flexible, with pay-as-you-go (PAYG) and annual flex UCM options available. Pricing depends on the selected database edition, database shape. and number of cores you choose.
You can consume Oracle Database Cloud Service database instances by creating an account at shop.oracle.com. Alternatively, existing customers can contact their sales representative to create an account and enable an existing pool of credits, or purchase a new pool, to consume Oracle Cloud Infrastructure resources. Refer to pricing for Bare Metal servers and pricing for Virtual Machines section for more details.
Existing Metered/Non-Metered tenancies will be billed under their existing plan until converted to a Universal Credit Model tenancy.
Currently, Oracle Database Cloud Service supports Oracle database versions 220.127.116.11, 18.104.22.168, 19c, and 21c.
The following Oracle Database license-included software editions are supported and optimized for the cloud.
You can also bring your own license (BYOL).
All editions include Oracle Database Transparent Data Encryption, Machine Learning, and Spatial and Graph.
A DB System is a bare metal server or a virtual machine that has Oracle Database software deployed and configured with a user-specified number of cores, software edition, and database version.
Virtual machine DB Systems only contain one database. Bare metal DB Systems can have multiple DB homes, which can contain multiple databases. All the databases within a DB home will have the same version, but each DB home can have a different version. For example, an Enterprise Edition DB System might contain DB_home19, which contains only Enterprise Edition 19c databases, and DB_home12, which contains only Enterprise Edition 22.214.171.124 databases.
No. The edition can't be changed. However, you can easily terminate the DB System and launch another with the preferred edition.
When you launch a DB System, the initial database created on the system uses the default character sets AL32UTF8 and AL16UTF16. However, you can easily pick a character set of your choice during launch in Database Advanced Options.
Yes, you can bring your own license. Oracle Database Cloud Service supports both license-included and BYOL pricing models.
The Oracle Cloud Infrastructure (OCI) console, REST APIs, SDK, or CLI can be used to perform common database lifecycle management tasks such as patching, Oracle Data Guard, and backup/recovery.
Refer to the Service Limits documentation for the default limits for each instance type and instructions on how to request a service limit increase. We are happy to increase the limits for your account as needed.
To meet the extreme performance demands of critical enterprise applications, Oracle Database Cloud Service supports three bare metal shapes that can achieve greater than 200,000 TPS or IOPS for a single database. Bare metal DB Systems use locally attached NVMe or SSD storage to ensure maximum performance. The amount of storage is determined by the shape specified when the DB System is launched.
|Bare Metal Shape||Cores/OCPUs||Memory||Storage Type||Raw Storage||Storage (2-Way Mirroring)||Storage (3-Way Mirroring)|
|BM.HighIO1.36*||2 – 36||512 GB||NVMe||12.8 TB||3.5 TB||2.3 TB|
|BM.DenseIO1.36||2 – 36||512 GB||NVMe||28.8 TB||9.4 TB||5.4 TB|
|BM.DenseIO2.52||2 – 52||768 GB||NVMe||51.2 TB||16 TB||9 TB|
(consists of two physical nodes)
|2 – 36 per node||512 GB per node||SSD||64 TB||22.1 TB||14 TB|
Note that when using Standard Edition with High IO & Dense IO shapes, the maximum allowed OCPUs is 8 OCPUs per instance.
*BM.HighIO1.36 and BM.RACLocalStorage1.72* shapes are no longer available, but continue to be supported for existing customers.
Virtual Machine shapes
Oracle Database Cloud Service supports a variety of virtual machines based on standard VM compute shapes. The choice of VM shapes provides cost efficiency and flexibility to select one to 24 cores and 256-GB to 40-TB of scalable and durable remote storage.
|VM Shape||Cores/OCPUs||Memory||Storage (Block Only)||Network Bandwidth|
|VM.Standard.1.1||1||7 GB||256 GB - 40 TB||Up to 600 Mbps|
|VM.Standard.1.2||2||14 GB||256 GB - 40 TB||Up to 1.2 Gbps|
|VM.Standard.1.4||4||28 GB||256 GB - 40 TB||1.2 Gbps|
|VM.Standard.1.8||8||56 GB||256 GB - 40 TB||2.4 Gbps|
|VM.Standard.1.16||16||112 GB||256 GB - 40 TB||4.8 Gbps|
|VM.Standard.2.1||1||15 GB||256 GB - 40 TB||1 Gbe|
|VM.Standard.2.2||2||30 GB||256 GB - 40 TB||2 Gbe|
|VM.Standard.2.4||4||60 GB||256 GB - 40 TB||4 Gbe|
|VM.Standard.2.8||8||120 GB||256 GB - 40 TB||8 Gbe|
|VM.Standard.2.16||16||240 GB||256 GB - 40 TB||16 Gbe|
|VM.Standard.2.24||24||320 GB||256 GB - 40 TB||25 Gbe|
Note: For any shape greater than 2 cores, you can specify Total Number of nodes=2 to get RAC configuration. When using Standard Edition, the maximum allowed shape is VM.Standard1.8.
The following Oracle Database Cloud Service bare metal "X5" based Dense IO and Bring Your Own License options are no longer available, but continue to be supported for existing customers:
|SKU||Compute Instance Shape||Recommended Alternatives|
|Bare Metal – "X5" Dense I/O – Standard Edition||Bare Metal "X5" Dense/IO
||Bare Metal "X7" – Dense I/O
|Bare Metal – "X5" Dense I/O – Enterprise Editions (Enterprise Edition, High Performance, Extreme Performance)||Bare Metal "X5" Dense/IO
||Bare Metal "X7" – Dense I/O
|Bare Metal – "X5" Dense I/O – BYOL||Bare Metal "X5" Dense/IO
||Bare Metal "X7" – Dense I/O
|Virtual Machine Standard – "X5" – all editions (Standard, Enterprise, High Performance, Extreme Performance, BYOL)||VM.Standard1.1
||"X7" Based VM.Standard2.1
|Virtual Machine Standard – "X5" – all editions (Standard, Enterprise, High Performance, Extreme Performance, BYOL)||VM.Standard1.2
||"X7" Based VM.Standard2.2
|Virtual Machine Standard – "X5" – all editions (Standard, Enterprise, High Performance, Extreme Performance, BYOL)||VM.Standard1.4
||"X7" Based VM.Standard2.4
||"X7" Based VM.Standard2.8
||"X7" Based VM.Standard2.16
Performance, storage capacity, cost, among other criteria will drive your shape selection within the database cloud service. Keep your database size growth expectation in mind as you select the shape.
Oracle provides customers a choice of cloud and on-premises manageability and monitoring options. These include Enterprise Manager, Management Cloud Service, and External Database Service.
Yes. With root access to the DB System, you can review and audit all the operations for the databases on the DB System.
Yes. Oracle Database Cloud Service supports a 'cloud-first' Oracle RAC on virtual machines within a virtual cloud network.
Oracle RAC on virtual machines is configurable by setting the "Total Number of Nodes" as 2 during the DB System launch.
Oracle Database Cloud Service on VMs is a database service offering that enables customers to build, scale, and manage full featured Oracle databases on virtual machines. The key benefits of running databases on VMs are cost effectiveness, ease of getting started, durable and scalable storage, and the ability to run Real Application Clusters (RAC) to improve availability.
RAC databases will run in a single Availability Domain (AD), while ensuring each node is on a separate physical rack ensuring high availability. Oracle Database Cloud Service on VMs is built on the same high performance, highly available cloud infrastructure used by all Oracle Cloud Infrastructure services.
Oracle RAC databases are supported with Enterprise Edition Extreme Performance on Oracle Database Cloud Service in VMs but are limited to a 2-node RAC configuration. 2-node RAC is enabled by selecting node=2 during provisioning and requires a minimum of two cores per VM.
Yes, you can scale the number of OCPUs up and down as required. Changing the shape will result in a database outage.
Yes. Changing the shape in a 2-node RAC VM shape will be done in a rolling manner to avoid downtime.
No. Each VM can only contain one database.
Yes. Oracle Database Cloud Service in a VM uses remote block storage, so you can configure available storage anywhere from 256 GB to 40 TB. You can scale up the storage capacity without downtime.
Yes, you can clone a VM DB System that uses either Logical Volume Manager (LVM) or Grid Infrastructure/ASM for storage management software. Cloning a VM DB System creates a copy of the source database at the time of the cloning operation, including software and database volumes.
Oracle Database Cloud Service on bare metal is a database service offering that enables customers to deploy and manage full-featured Oracle databases on bare metal servers. Bare metal offers proven and predictable performance with local NVMe storage on dedicated servers that provide high IOPS with extremely low latency.
Bare metal servers in Oracle Database Cloud Service can have multiple DB homes, which can contain multiple databases. All the databases within a database home will have the same version, but each database home can have a different version. For example, an Enterprise Edition DB System might contain DB_home19, which contains only Enterprise Edition 19c databases, and DB_home12, which contains only Enterprise Edition 126.96.36.199 databases.
Oracle RAC databases are only supported with Oracle Database Cloud Service on virtual machines (VMs).
Yes, you can scale the number of OCPUs up and down online as required without database downtime.
No. Oracle Database Cloud Service on bare metal servers uses local NVMe storage. There is a fixed storage capacity associated with the server shape.
No, you cannot attach block storage volumes to a bare metal servers.
Oracle Database Cloud Service supports Oracle’s Universal Credit purchase model, which offers simple and flexible pricing models:
Pay-as-you-go (PAYG) pricing lets customers quickly provision services with no upfront commitment, no minimum service period and pay only for what they use which will be billed monthly in arrears. To get started, customer can create an account at shop.oracle.com.
Annual Universals Credits enables customers to use any eligible Oracle Cloud Infrastructure and platform services at any time, in any region. Annual Universal Credits are billed in advance and offer significant savings across cloud services, combining cost reduction and a predictable monthly spend with a ramp-up period as you onboard your workloads.
Oracle Database Cloud Service supports both license included and bring your own license (BYOL) licensing models and is charged based on the following usage elements:
Yes, you change the licensing model from license include to BYOL and vice versa.
Setting up Data Guard across two DB Systems deployed in separate Availability Domains or Regions configures high availability or disaster recovery for your databases. You will be billed for both DB Systems. Refer to the Cloud Price List sections for pricing details.
Yes. Oracle Database Cloud Service supports stop billing on virtual machines. To take advantage of this capability, go to the virtual machine DB System and select the desired node to stop. The database remains intact while the node is stopped. You are not billed for hours the node is not running.
Stop billing is not applicable for Oracle Database Cloud Service on bare metal servers and billing continues after stopping the server, since you continue hold on to the entire hosted environment. To reduce costs, you can make use of the online CPU scaling capability of the database shape and reduce the OCPUs to 2 for unused and minor used environments.
A VCN is a customizable private network in Oracle Cloud Infrastructure. Just like a traditional data center network, a VCN provides you with complete control over your network environment. This includes assigning your own private IP address space, creating subnets, creating routing tables and configuring stateful firewalls. A single tenant can have multiple VCNs, thereby providing grouping and isolation of related resources.
By deploying into a VCN by default, you get the security and flexibility of:
We highly recommend that you create separate subnets in each Availability Domain and place your DB Systems in those subnets. This allows you to precisely define inbound/outbound security lists for the subnet and control network access.
DB Systems are configured with TDE by default during provisioning. You have the flexibility to log in and control other security policies on the DB System. You can follow the standard database security best practices (PDF).
With Oracle Cloud Infrastructure Identity and Access Management (IAM), you can configure your cloud environment to support your security and compliance requirements. From a database perspective, you configure IAM policies that allow you to restrict access to bare metal and virtual machine DB Systems only to a select set of users (DBAs) from a management perspective. Please refer to our technical documentation on how to use Oracle IAM with Oracle Database Cloud Service.
Yes. With full root access to the DB System you can configure auditing for all operations on the DB System. Oracle Database Cloud Service provides robust audit support in all editions of the database. Audit records include information about the operation that was audited, the user performing the operation, and the date and time of the operation. Audit records can be stored in the database audit trail or in files on the operating system. Standard auditing includes operations on privileges, schemas, objects, and statements.
In addition, you can use Oracle Cloud Infrastructure Audit to audit all the API management calls that were made on your tenancy.
Yes. All Oracle Database security options are supported.
Oracle Data Safe is a cloud native service that provides security features such as assessments, auditing, and data masking and is free for Oracle Database Cloud Service.
The Oracle Database Cloud Service patching feature simplifies the steps required to patch your DB Systems and databases. You can use the Oracle Cloud Infrastructure console and APIs to view applicable patches for your DB System or database home and submit a patching request. The Oracle Database Cloud Service will then run the end-to-end patching steps for you while displaying the status.
You can view all patches that have been applied, and if required, reapply a patch. In addition, you can use Oracle Identity and Access Management (IAM) controls to manage access to patching features.
You can use the Oracle Cloud Infrastructure console and Rest APIs to access the feature.
Your DB System's cloud network (VCN) must be able to access patches stored in Oracle Object Storage. You can do this by configuring a service gateway, which enables cloud resources without public IP addresses to privately access Oracle services such as Oracle Object Storage.
You can use the feature to patch all Oracle Database Cloud Service shapes, including bare metal, 1-node, and 2-node RAC virtual machine DB Systems.
Oracle Database Cloud Service-specific patches for DB Systems and database homes can be applied. Only the latest patch is available for DB Systems while database homes supports both latest and older patches. You can find the list of currently available DB System and database home patches in the Oracle Cloud Infrastructure technical documentation.
Yes. Patches are available for all supported database versions.
Use custom database software images to apply interim patches or one-offs. We recommend that you do not apply on-premises quarterly bundle patches using the OPatch utility. These patches may not work without applying additional cloud specific patches. Instead, you should apply cloud-customized quarterly patches that are available through the Oracle Cloud Infrastructure Database Cloud Service console and REST APIs.
Yes. Custom database software images can be used.
Yes. There will be downtime for 1-node DB Systems. 2-node RAC virtual machine DB System patching is rolling, 1-node at a time. You can also configure Oracle Data Guard to minimize downtime. Follow the Maximum Availability Architecture (MAA) best practices.
Your DB System or database home will be in the ”Available” state if the patch fails. The patch history can indicate the reason the operation failed. To debug the root cause of failure, you can access detailed patching-related logs by accessing your host. If the log information is not helpful in debugging the issue, you can file a request with Oracle Support to help determine the root cause.
Yes, your DB System should be on the same or higher version than your database home. To avoid version conflicts, you should apply DB System patches first, followed by database home patches. If you do not follow this order, you will get an error message while applying the patch.
Yes, you can precheck a patch before applying. Rollback is also available for bare metal, 1-node, and 2-node RAC virtual machine DB Systems.
Yes, you can use Oracle Identity and Access Management (IAM) service to restrict access at a user and group level.
Yes. Oracle database bundle patches and Oracle Database Cloud Service database patches are different. Oracle Database Cloud Service database patches are a superset containing Oracle Database bundle patches, Oracle Cloud Infrastructure-specific MLRs (Merge Label Requests), and other patches.
Yes. DB System patches are available for DB Systems using Grid Infrastructure/ASM storage management. DB System patches don’t include the OS updates.
No. OS patching is currently not supported. You must access the host directly to manually patch the OS through the command line. Refer to Bare Metal and Virtual Machine DB System OS Updates.
Yes. Database patches are cumulative. New Oracle Database Cloud Service patches contain patches from previous DB System or DB home patches of the same version.
Oracle Cloud Infrastructure will send email notification informing you about a critical security patch. Depending on the criticality of the patch, we will set a time window for you to apply the security patch.
This depends on the type of patch. A DB System or database home state will change to ”Available” once a patch has been applied.
The database backup and restore feature enables you to use the Oracle Cloud Infrastructure Console, CLI and REST APIs to create and manage backups of your databases. You can also restore your existing database from a backup or create a new database from a backup.
Backing up your database is a key aspect of any Oracle database environment. There are multiple options available for storing and recovering your backups. You can use the backup and restore feature either within the Oracle Cloud Infrastructure Console, CLI or REST APIs, or manually set up and manage backups using dbcli or RMAN. You can read about all the options in the technical documentation.
The backup and restore feature provides Console, CLI and Rest APIs to create and manage backups. When you use the Console, you can create full backups or set up automatic incremental backups with a few clicks. Similarly, you can view your backups and restore your database using the last known good state, a point-in-time, or SCN (System Change Number). You can also create a new database from your backup in an existing or a new DB System.
Your backups are stored in Oracle Cloud Infrastructure Object Storage and the service fees apply for storing your backups. Learn more about Object Storage pricing. There are no additional charges for using the feature.
The backup and restore feature supports all bare metal and virtual machine DB System shapes, license-included editions, and database versions.
On-demand full backups and automatic incremental backups are currently supported.
The retention period for automatic incremental backups is 7, 15, 30, 45, or 60 days. You select your desired retention period when the automatic backups are enabled.
No, you cannot control these settings using the backup and restore feature.
When you enable automatic backups for a database, Oracle Database Cloud Service will create the first level 0 backup. After the first backup, level 1 backups will run every day until the next weekend. Every weekend, a new level 0 backup will be created. Automatic backups enabled for the first time after November 20, 2018 on any database will run between 00:00 AM and 06:00 AM in the time zone of the DB System's region. If you have enabled automatic backups on a database before this date, the backup window for the database will continue to be between 00:00 AM and 06:00 AM UTC.
Yes. All your backups are encrypted with the same master key used for TDE encryption.
Your backups are stored in Oracle Cloud Infrastructure Object Storage. Oracle Object Storage was designed from the ground up to be highly durable. Data is stored redundantly across multiple storage servers and across multiple Availability Domains. Data integrity is actively monitored using checksums, and corrupt data is detected and auto-repaired. Any loss in data redundancy is automatically detected and self-healed, without any customer impact.
If you are using the backup and restore feature, your backup operations can fail if the database or DB System is not in an ”Available” state. Actions like patching, SSH key addition, and Data Guard operations can change the DB System or database state. To avoid backup failure, ensure that these actions are not performed during the backup window (00:00 - 06:00 UTC). If an automatic incremental backup fails, the Oracle Database Cloud Service retries the backup operation during the next day’s backup window. For a failed on-demand backup, you must manually retry the operation when both DB System and database is available.
If you are using the backup and restore feature, you can restore your database to the latest state, a point-in-time state, or to a committed state of database defined by System Change Number (SCN). However, you can use dbcli or RMAN option for more restore options.
You can find the SCN number either by accessing your database or accessing any online or archived logs.
Yes, you can create a new database from a backup in an existing or new DB System. This provides options for point-in-time-recovery when creating the database from backup.
Yes, you can choose any existing DB System, or create a new DB System in any compartment. However, the new or the existing DB System should be in the same Availability Domain where your backup is hosted. If you create a new DB System, the Oracle Database software edition you specify must be an equal or greater edition than that of the backed up database. Also, the shape you specify must be the same type as the database from which the backup was taken. For example, if you are using a backup of a 1-node database, then the DB System you select as your target must also be a 1-node DB System.
No. Automatic incremental backups are not enabled by default. You can enable the option during database creation or at any time after the database is provisioned.
Automatic backups are deleted when a DB System is terminated. On-demand full backups remain in Oracle Object Storage as standalone backups when a DB System is terminated. You can later restore standalone backups to a new database on a DB System.
Oracle offers a wide range of Oracle Database Cloud Migration solutions.
2-node RAC VM DB Systems provide server high availability to protect against unplanned downtime due to server or database instance failure or planned downtime due to maintenance. You can also launch DB Systems in different Availability Domains or regions and configure Data Guard between them. Oracle Data Guard ensures high availability, data protection, and disaster recovery.
You can review Data Guard for High Availability and Maximum Availability Architecture (MAA) best practices for more information about setting up a zero data loss, highly available configuration for Oracle databases.
An Availability Domain (AD) is the subcomponent of a region designed to be independent and highly reliable. Each AD is built with fully independent infrastructure such as building(s), power generators, cooling equipment, and network connectivity. In the event of extremely uncommon disasters such as fires or flooding, only one AD is affected. In addition, the ADs within the same region are connected with high speed, low latency network, allowing customers to build and run highly reliable applications and workloads with minimum impact to the application latency and performance.
These fault-independent ADs enable customers to build highly available applications in the cloud without sacrificing performance. We highly recommend you place the primary and standby databases in different ADs to ensure they are protected from the common failures illustrated above.
All Enterprise database editions support Data Guard. Enterprise Extreme Performance edition supports Active Data Guard.
Oracle Database Cloud Service provides Data Guard configuration using the Oracle Cloud Infrastructure console and REST APIs.
In a few clicks, you can enable Data Guard and perform switchover, failover, and reinstate actions. You can also set up granular access control for the feature using Oracle Identity and Access Management Service. There is no cost associated with using this feature.
All bare metal, 1-node, and 2-node RAC virtual machine DB System shapes support the Data Guard feature.
Switchover, Failover, and Reinstate features are currently supported. However, you can manually set up Data Guard by logging on to you host and accessing Data Guard command-line interface (DGMGRL). Learn more about DGMGRL.
Maximum Performance protection mode with ASYNC transport type and Maximum Availability with SYNC transport type are supported.
To set up Data Guard, both primary and secondary DB Systems should be in the same VCN, and port 1521 should be open on both DB Systems. DB Systems can be in different subnets.
Yes, you can set up Data Guard in the same or different Availability Domains in a region. However, Oracle recommends that you set up your Data Guard configuration across Availability Domains.
Yes, you can set up Data Guard across regions with the Data Guard feature.
No. Cross-compartment Data Guard set up is currently not supported on Oracle Database Cloud Service.
Yes. The primary and standby DB Systems must be the same shape type (both must be bare metal, 1-node or 2-node RAC virtual machine DB Systems) and the primary and standby databases must be the same database version.
The standby database is created with the same database version as that of the primary.
To remove the Data Guard association using the Data Guard feature, you must first delete the standby database. Once you delete the standby database, the Data Guard association will be removed automatically.
Using the Data Guard feature, you will need to first delete your standby database before you can delete your primary database. Alternatively, you can initiate a switchover operation so the primary is now a standby, and then you can terminate the standby.
No, you can only create a single physical standby database using the Data Guard feature. However, you can manually create multiple standby databases by logging on to your DB System and accessing DGMGRL. Learn more about DGMGRL.
Yes, you can configure Data Guard between an on-premises database and an Oracle Database Cloud Service database. You can manually set up Data Guard between your on-premises database and an Oracle Database Cloud Service database using DGMGRL. Learn more about DGMGRL.
Yes, you can control access to Data Guard features using Oracle Identity and Access Management. Learn more about Oracle Identity and Access Management.
You can patch databases in primary and standby Data Guard setup. You should patch the standby first, switch over to your standby, and then patch your primary.
You can use the Oracle Cloud Infrastructure Database backup and restore feature to back up and restore your primary databases. If you want to enable backup for a standby, you can do so by accessing your standby database host and using RMAN (Recovery Manager).
Using the Data Guard feature, once you fail over your primary database, it assumes a “Disabled Standby” state. After you fix the issue with this disabled standby, you can reinstate it to a functioning Standby role. Then, you can switch over this standby database back to the primary role.
Yes. With Active Data Guard set up, you can use the standby instances for read only operations. Write operations are not enabled on a standby.
Our recommendation is to use Enterprise Manager for monitoring your DB Systems managed by Oracle Database Cloud Service. If you enable audit log operations on the instance, you can also view the logs to understand when the primary failed over.
No, you cannot setup FISO with the Data Guard feature. However, it can be configured manually. You should deploy it in a virtual machine in a separate Availability Domain if possible.
For 2-node RAC configurations, the failover should be in tens of seconds. However, if the failover is between two instances that are in different ADs with Data Guard, the failover should be less than two minutes.
No. The virtual machines for 2-node RAC are deployed on separate servers and racks within the same Availability Domain. Storage is shared across both database instances. This set up protects against server failures and rack power failures. For higher availability, it is recommended that you enable Data Guard with a standby 2-node RAC DB System in a separate Availability Domain.