Getting Started with Exadata Cloud Infrastructure Deployment

After completing the preparation tasks in Preparing for Exadata Cloud Infrastructure, get started with deploying your Exadata Cloud Infrastructure system following these procedures.

Tagging Oracle Exadata Database Service on Dedicated Infrastructure Resources

Tagging is a powerful foundational service for Oracle Cloud Infrastructure (OCI) that enables users to search, control access, and do bulk actions on a set of resources based on the tag.

Importance of Tagging

Using the Oracle Cloud Infrastructure (OCI) tagging system, you can tag resources per your organizational scheme allowing you to group resources, manage costs, and give insights into usage. Tags also help you build a governance model around security and Maximum Availability Architecture (MAA). As your organization expands its cloud footprint, it can become challenging to keep track of the deployment architectures, security best practices, MAA, application tier, and so on. Using metadata tags to identify workload attributes can help keep up with the security and availability of your tenancy without cost overruns.

To enable customers to manage OCI resources securely and cost-effectively, Oracle provides a set of pre-defined tags in line with best practices for tagging resources. These tags are grouped into two namespaces, the oracleStandard namespace, and the OracleApplicationName namespace. You can think of a tag namespace as a container for your tag keys.

Consider a scenario where your organization has multiple cloud resources such as Consider a scenario where your organization has multiple cloud resources such as Exadata Infrastructure, VM Cluster, DB Home, Oracle Database and VM Cluster Networks across multiple compartments in your tenancy. Suppose you wish to track these cloud resources for specific purposes, report on them, or take bulk actions. In that case, you will need a system that lets you group these resources based on different criteria such as environment, criticality, target users, application, etc. You can achieve this by applying appropriate tags to these resources.

For example, you may tag all resources in your development stack with Oracle-Standard.Environment=Dev or for a business-critical application stack set Oracle-Standard.Criticality=High or Extreme. In the event of service disruptions due to various reasons, you would then be able to quickly identify all OCI resources associated with an application or business function or be able to separate critical and non-critical workloads.

Tagging can also help you deploy optimized configurations based on workload attributes identified via tags. For example, database deployments for the PeopleSoft application require a specific configuration. Setting the ApplicationName and AppMajorVersion tags while deploying an Oracle Database can ensure that the database is configured and ready for the particular application, for example, PeopleSoft out of the box.

Moreover, integration with the Cloud Advisor OCI service can provide you with direct, deep insight into how well your cloud services adhere to the corporate guidelines and help your management govern with a vision. See Cloud Advisor Overview for more details.

Adding Tags

You can tag resources using the Oracle Cloud Infrastructure (OCI) console, command-line interface, or SDK.

There are many cloud resources that can be tagged in an Oracle Exadata Database Service on Dedicated Infrastructure deployment. Exadata Infrastructure, VM Cluster, DB Home, Oracle Database, Autonomous Exadata VM Cluster, Autonomous Container Database, Autonomous Database, and VM Cluster Networks are some of them. Tags can either be applied while creating the resources or modified later. For example, you can apply tags to an Autonomous Container Database (ACD) while provisioning the ACD or add them later from its Details page.

See How Tagging Works for more details on using tags. Tagging integrates with Oracle Cloud Infrastructure authorization system. You can use IAM policy controls to enable delegation or restriction of tag manipulation. See Authentication and Authorization to learn about the permissions required to work with defined and free-form tags. (Required) Enter introductory text here, including the definition and purpose of the concept.


For a "try it out" tutorial that demonstrates implementing tags in Oracle Autonomous Database, refer to Lab 14: Oracle Standard Tags in Oracle Autonomous Database Dedicated for Fleet Administrators Workshop on Oracle LiveLabs.

Your tenancies come with a library of standard tags that would apply to most resources. These tags are currently available as a set of Tag Namespaces that your governance administrators can deploy. OCI best practices recommend applying these tags to all resources a standard tag can be applied to. Besides reporting and governance, OCI service automation can deliver workload-specific optimizations based on standard tag values.

For example, database deployments for the PeopleSoft application require a specific configuration. By setting the appropriate application tag key in the Oracle-ApplicationName tag namespace while deploying an Autonomous Database, can ensure that the database is configured ready for the particular application, for example, PeopleSoft out of the box.

Figure 4-1 Tagging Example

Setting an appropriate application tag key in the Oracle-ApplicationName tag namespace.

Oracle Standard Tags

Your tenancy governance administrators can deploy the standard tags at the tenancy level and may also mark certain tags as required, thereby enforcing tags on resources in those compartments. The following are the standard tags defined in the namespace called OracleStandard. For more information about importing standard tags, see To import standard tags under the Managing Tag Namespaces section.

Table 4-1 Oracle Standard Tags

Tag Key Tag Value Options Description


  • Extreme
  • High
  • Medium
  • Low

Enables tiering of resources in line with corporate application classification standards. Customer governance can use this tag for reporting and ensuring resources are configured as per the guideline for the tier they belong to.

For example, a database resource with OracleStandard.Criticality set to Extreme or High may require the highest availability SLA and may need to be configured with Autonomous Data Guard.


  • Dev
  • Test
  • Prod
  • Pre-Prod
  • Staging
  • Trial
  • Sandbox
  • User Testing

Denotes a resource lifecycle. In the case of databases, it helps determine consolidation density, database distribution across containers, set maintenance plans, and manage clones.


  • Public
  • Internal
  • Sensitive
  • Highly Sensitive
  • Extremely Sensitive

An application or database classification tag. OracleStandard.Sensitivity set to Highly Sensitive may indicate that an access control list or certain Network Security Group (NSG) enforcement is mandatory to restrict access.


Refer to List of Compliance Regulations for values.

Denotes one or more compliance regulations that a resource must adhere to.

Tag administrators may add values to the list from the OCI Governance and Administration console. Refer to Using Predefined Values for more details.


  • Public
  • Customers
  • Partners
  • Company
  • Division
  • Department
  • Workgroup

Denotes the end users of a resource. Another form of resource classification that helps determine target users and allows governance teams to set corporate standards based on user or application type.


  • 1
  • 10
  • 100
  • 1000
  • 10000
  • 100000
  • 1000000
  • 1000000
  • 10000000

An approximate count of end-users. This tag helps determine the number of users impacted or the blast radius during an availability or security event. This also helps prioritize recovery efforts in the event of major outages affecting a large number of cloud resources.


Free form tag. For example or

Denotes the email address of the resource owner.


  • HR
  • Finance
  • Marketing
  • Sales
  • Legal
  • R&D
  • Customer Suppport
  • Internal Support
  • Manufacturing

Identifies the customer's line of business or department that owns or uses the resource. This may help with cost aggregation reports and determining usage across business units.Tag administrators may add relevant values to the list from the OCI Governance and Administration console. Refer to Using Predefined Values for more details.


  • 12345
  • WebMarketing

Freeform field for cost center.



Time in minutes. Denotes the maximum time within which the resource is required to recover from a failure.



Time in minutes. Maximum data loss tolerance for a data store resource such as a database or a storage device.

List of Compliance Regulations

Table 4-2 List of Compliance Regulations

Regulation Description


Payment Card Industry Data Security Standard


Health Insurance Portability and Accountability Act


International Standards Organization


System and Organization Controls 1


System and Organization Controls 2


Federal Risk and Authorization Management Program


Gramm–Leach–Bliley Act


California Consumer Privacy Act


Sarbanes Oxley


National Institute of Standards and Technology - Cyber Security


Federal Information Security Management


Health Information Technology for Economic and Clinical Health Act


Family Educational Rights and Privacy Act ( Student privacy)


Fair and Accurate Credit Transaction Act

Texas HB300

Texas Medical Records Privacy Act


Center for Internet Security


Criminal Justice Information Services Security Policy


Customs-Trade Partnership Against Terrorism


Children's Online Privacy Protection Act


Personal Information Protection and Electronic Documents Act


General Data Protection Regulation


Personal Information Protection Law

Oracle Application Name Tags

Table 4-3 Oracle Application Name Tags

Tag Key Tag Value Options Description


  • 11.2
  • 11.1

Denotes the version of the Hyperion application.

JD Edwards

  • 9.2
  • 9.1
  • 9.0

Denotes the version of the JD Edwards application.


  • 12.2
  • 12.1
  • 12.1
  • 11i

Denotes the version of the Oracle E-Business Suite application.


  • 9.2
  • 9.1

Denotes the version of the PeopleSoft application.


  • 8.2
  • 8.1

Denotes the version of the Siebel application.


Free form tag in string format.

Can be used to denote any application other than those listed above. You can enter the application name as a string value.

Configure Oracle-Managed Infrastructure Maintenance

In addition to the maintenance tasks you perform, Oracle manages the patching and updating of all other infrastructure components, including the physical compute nodes (Dom0), the Exadata storage servers, and the Exadata network switches. This is referred to as infrastructure maintenance.

Oracle performs regular maintenance updates the underlying infrastructure hosting the Exadata Cloud Infrastructure virtual servers. This infrastructure includes the physical host servers, the Exadata storage servers, the fabric switches in the Exadata Secure RDMA Fabric, and any control plane components. Maintenance updates may require a restart of the customer-managed guest virtual servers. The frequency of the updates depends on the region type, as follows:

  • Commercial regions: Oracle performs quarterly infrastructure maintenance updates.
  • Government regions: Oracle performs monthly infrastructure maintenance updates.

To minimize disruption to your applications, you can use the OCI Console to specify the maintenance window during which the quarterly infrastructure updates take place.

Oracle releases critical security updates for Exadata on a monthly schedule. If updates for severe vulnerabilities to the infrastructure software are available, Oracle will attempt to apply those critical updates within 21 days of their availability. In most cases, critical security updates are performed while your Exadata system is online, and have no impact on the database servers running database workloads. Critical storage server security updates are applied in a rolling manner, and are not expected to affect database availability. Critical security updates are applied automatically, and cannot be deferred or scheduled. If a monthly critical security update will affect a running database server, Oracle will notify you prior to applying the update.

Overview of the Infrastructure Patching Process

Infrastructure maintenance begins with patching of the Exadata compute nodes.

By default, infrastructure compute nodes are updated in a rolling fashion, where a single node is shut down, patched, and then brought back online while other nodes remain operational. This process continues until all nodes are patched.

Optionally, for any scheduled infrastructure maintenance, you can configure the patching to take place in a non-rolling fashion. For the non-rolling option, all nodes are shut down at the same time and patched. Non-rolling patching reduces the total amount of time that infrastructure maintenance takes, but does involve system down time. Non-rolling patching must be set for each individual maintenance event, and cannot be set as the default patching method. See To set the node patching order for a scheduled infrastructure maintenance run for instructions.

After compute node patching completes, Oracle patches the storage nodes. Storage server patching does not impact compute node availability.

Oracle recommends reviewing the documentation on Workload Management with Dynamic Database Services, and Continuous Availability client failover best practices to reduce the potential for an outage with your applications. By following the guidelines in the documentation, the impact of infrastructure patching will be only minor service degradation due to connection loss as compute nodes are sequentially patched.

Oracle recommends that you follow the Maximum Availability Architecture (MAA) best practices and use Oracle Data Guard to ensure the highest availability for your critical applications. For databases with Oracle Data Guard enabled, Oracle recommends that you separate the patching windows for the infrastructure instances running the primary and standby databases, and perform a switchover prior to the maintenance operations for the infrastructure instance hosting the primary database, to avoid any impact to your primary database during infrastructure patching.


Regardless of the maintenance method (rolling or non-rolling), the automated maintenance verifies the Oracle Clusterware is running but does not verify that all database services and pluggable databases (PDBs) are available after a node is brought back online. The availability of database services and PDBs after maintenance can depend on the application service definition. For example, a database service, configured with certain preferred and available nodes, may be relocated during the maintenance and wouldn't automatically be relocated back to its original node after the maintenance completes. Oracle recommends reviewing the documentation on Achieving Continuous Availability for Your Applications on Exadata Cloud Systems to reduce the potential for impact to your applications. By following the documentation's guidelines, the impact of infrastructure maintenance will be only minor service degradation as database servers are sequentially updated

Table 4-4 Approximate Times for Exadata Infrastructure Patching

Exadata Shape Configuration Rolling Patching Method (Approximate Time) Non-Rolling Patching Method (Approximate Time)
Quarter rack 5-6 hours 4 hours
Half rack 10 hours 4 hours
Full rack 20 hours 4 hours
Flexible shapes (X8M and higher) 1.5 hours per compute node + 1 hour per storage node 4 hours

Do not perform major maintenance operations on your databases or applications during the patching window, as these operations could be impacted by the rolling patch operations.

Scheduling Oracle-Managed Infrastructure Updates

Exadata Cloud Infrastructure updates are released on a quarterly basis for commercial regions, and monthly for government regions. You can set a maintenance window to determine the time your infrastructure maintenance will begin.

You can also view scheduled maintenance runs, view the maintenance history of your Exadata Cloud Infrastructure instance, and manage maintenance contacts in the Oracle Cloud Infrastructure Console on the Exadata Infrastructure Details page.

Oracle may update your system apart from the these regular updates to apply time-sensitive changes such as security updates. While you cannot opt out of these infrastructure updates, Oracle alerts you in advance through the Cloud Notification Portal if there will be any impact to your system availability.

To set the automatic maintenance schedule for Exadata Cloud Infrastructure
To view or edit the time of the next scheduled maintenance for Exadata Cloud Infrastructure
To view the maintenance history of an Exadata Cloud Infrastructure resource

Receive Notifications about Your Infrastructure Maintenance Updates

There are two ways to receive notifications. One is through email to infrastructure maintenance contacts and the other one is to subscribe to the maintenance events and get notified.

Oracle schedules maintenance run of your infrastructure based on your scheduling preferences and sends email notifications to all your infrastructure maintenance contacts. You can login to the console and view details of the schedule maintenance run. Appropriate maintenance related events will be generated as Oracle prepares for your scheduled maintenance run, for example, precheck, patching started, patching end, and so on. For more information about all maintenance related events, see Oracle Cloud Exadata Infrastructure Events. In case, if there are any failures, then Oracle reschedules your maintenance run, generates related notification, and notifies your infrastructure maintenance contacts.

For more information about Oracle Cloud Infrastructure Events, see Overview of Events. To receive additional notifications other than the ones sent to infrastructure maintenance contacts, you can subscribe to infrastructure maintenance events and get notified using the Oracle Notification service, see Notifications Overview.

Managing Infrastructure Maintenance Contacts

Learn to manage your Exadata infrastructure maintenance contacts.

To manage maintenance contacts in an Exadata Cloud Infrastructure

Manage contacts for Exadata infrastructure maintenance notifications using the Console.

To prevent an Exadata infrastructure administrator from being overwhelmed by system update notifications, you can specify up to 10 email addresses of people to whom maintenance notifications are sent.

  1. Open the navigation menu. Click Oracle Database, then click Bare Metal, VM, and Exadata.
  2. In the Exadata at Oracle Cloud section, click Exadata Infrastructure to display a list of Exadata infrastructures in the default compartment. You can select a different compartment from the Compartment drop-down located in the List Scope section.
  3. In the list of Exadata infrastructure resources, find the infrastructure you want to access and click its highlighted name to view its details page.
  4. In the Maintenance section, click Manage in the Customer Contacts field to display the Manage Contacts dialog.
  5. Click the Add Contacts button to display a field in which to enter a valid email address. You can have up to 10 maintenance contacts for each Exadata infrastructure.
  6. To edit an email address, in the Manage Contacts dialog, select the box preceding the email address you want to edit and click the Edit button.
  7. To remove an email address from the list, in the Manage Contacts dialog, select the box preceding the email address you want to remove and click the Remove button.