Oracle® Exadata

Exadata Cloud@Customer Configuration and

Administration Guide

F40579-04
May 2021
Oracle Exadata Exadata Cloud@Customer Configuration and Administration Guide,

F40579-04

Copyright © 2008, 2021, Oracle and/or its affiliates.

Primary Author: Nirmal Kumar

Contributors: Mark Bauer, Rhonda Day, Douglas Williams, Michael Fitch, Peter Fusek, Neil Hebert,
Terence Buencamino, Raj Ojha, Behkam Aminzadeh, Ashutosh Chetal, Robert Greene, Kris Bhanushali,
Alexander Prince Mathew, Bob Thome, Tushar Pandit, Manish Shah, Vira Goorah, Somnath Lahiri, Pablo
Sainz Albanez, Saravanan Sabapathy, Charan Chaudary Lekkalapudi, Lakshmi Sneha Kandukuri, Nayana
Vishwa, Namratha Mandya Subramanya, Kishore Sridhar, Boming Zhang, Vedika Joshi, Abhilash Gudasi,
Santosh Uttam Bobade, Ankit Mahale, Nithin Kovoor, Ranganath Srirangapatna Ramachandra, Manini
Chattopadhyay, Sheila Ray

This software and related documentation are provided under a license agreement containing restrictions on
use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your
license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license,
transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse
engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is
prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If
you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on
behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software,
any programs embedded, installed or activated on delivered hardware, and modifications of such programs)
and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government
end users are "commercial computer software" or "commercial computer software documentation" pursuant
to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such,
the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works,
and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs
embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle
computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the
license contained in the applicable contract. The terms governing the U.S. Government’s use of Oracle cloud
services are defined by the applicable contract for such services. No other rights are granted to the U.S.
Government.

This software or hardware is developed for general use in a variety of information management applications.
It is not developed or intended for use in any inherently dangerous applications, including applications that
may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you
shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its
safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this
software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of
their respective owners.

Intel and Intel Inside are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are
used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Epyc,
and the AMD logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered
trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products,
and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly
disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise
set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not
be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content,
products, or services, except as set forth in an applicable agreement between you and Oracle.
Contents
What’s New in Oracle Exadata Cloud@Customer Gen2
What’s New in Oracle Exadata Cloud@Customer xviii
What’s New in ADB-D on Oracle Exadata Cloud@Customer xxi

1 Introduction to Oracle Exadata Cloud@Customer

About Oracle Exadata Cloud@Customer 1-1
Exadata Cloud Management Interfaces 1-2
Introduction to Exadata Cloud Management Interfaces 1-2
OCI Control Plane Interfaces 1-3
Local VM Command-Line Interfaces 1-4
Per-Second Billing for OCPU Usage 1-5
System Configuration Options for Oracle Exadata Cloud@Customer 1-5
Oracle Exadata X8M-2 System Model Specifications 1-6
Oracle Exadata X8-2 System Model Specifications 1-6
Oracle Exadata X7-2 System Model Specifications 1-7
Moving to Oracle Cloud Using Zero Downtime Migration 1-7

2 Preparing for Exadata Cloud@Customer

Site Requirements for Oracle Exadata Cloud@Customer 2-1
Space Requirements for Oracle Exadata Cloud@Customer 2-2
Weight of Oracle Exadata Cloud X8 Racks 2-2
Receiving, Unpacking, and Access for Oracle Exadata Cloud@Customer Racks 2-2
Flooring for Oracle Exadata Cloud@Customer Racks 2-3
Electrical Power for Oracle Exadata Cloud@Customer Racks 2-3
Temperature and Humidity Ranges for Oracle Exadata Cloud@Customer 2-6
Ventilation for Oracle Exadata Cloud@Customer Racks 2-7
Network Requirements for Oracle Exadata Cloud@Customer 2-7
Network Requirements for Oracle Exadata Cloud@Customer 2-7
Data Center Network Services for Exadata Cloud@Customer 2-11
IP Addresses and Subnets for Exadata Cloud@Customer 2-12
Uplinks for Exadata Cloud@Customer 2-13

iii
 Network Cabling for Exadata Cloud@Customer 2-14
Exadata Cloud@Customer Gen2 Oracle Cloud Infrastructure FastConnect 2-14
Plan Your Configuration Settings on Storage 2-16
About Storage Configuration for Oracle Exadata Cloud@Customer 2-16
Allocation of Storage Space Options on Oracle Exadata Storage Servers 2-17
Allocation Proportions for DATA, RECO and SPARSE Disk Groups 2-17
Checklists for Exadata Cloud@Customer Deployments 2-18
System Components Checklist for Exadata Cloud@Customer 2-19
Data Center Room Checklist for Exadata Cloud@Customer 2-19
Data Center Environment Checklist for Oracle Exadata Cloud@Customer 2-19
Access Route Checklist for Oracle Exadata Cloud@Customer 2-20
Facility Power Checklist for Oracle Exadata Cloud@Customer 2-20
Safety Checklist for Oracle Exadata Cloud@Customer 2-21
Logistics Checklist for Exadata Cloud@Customer 2-21
Network Configuration Checklist for Oracle Exadata Cloud@Customer 2-22
Reracking Checklist for Oracle Exadata Cloud@Customer 2-23

3 Provisioning Exadata Cloud@Customer Systems

About Provisioning Oracle Exadata Cloud@Customer Systems 3-1
Required IAM Policy for Provisioning Servers 3-2
Prerequisites for Provisioning Oracle Exadata Cloud@Customer Servers 3-3
Using the Console to Provision Oracle Exadata Cloud@Customer 3-3
Using the Console to Create Infrastructure 3-4
Using the Console to Edit Oracle Exadata Cloud@Customer Infrastructure 3-8
Using the Console to Download a File Containing Configuration Data 3-10
Using the Console to Activate Exadata Cloud@Customer Infrastructure 3-10
Using the Console to Check the Status of Exadata Cloud@Customer
Infrastructure 3-11
Using the Console to Move Exadata Cloud@Customer Infrastructure 3-12
Using the Console to Delete Exadata Cloud@Customer Infrastructure 3-12
Using the Console to Manage Tags for Your Exadata Cloud@Customer
Resources 3-13
Managing Infrastructure Maintenance Contacts 3-13
View Primary Maintenance Contact 3-14
Add Secondary Contacts 3-14
Edit Maintenance Contacts 3-15
Promote a Secondary Contact to Primary 3-15
Remove a Secondary Contact 3-15
Oracle Exadata Cloud@Customer Deployment Assistant 3-16
Using Oracle Exadata Cloud@Customer Deployment Assistant 3-16
Accessing Oracle Exadata Cloud@Customer Deployment Assistant 3-17

iv
 Step 1: Pre-Installation 3-17
Step 2: Onsite Installation 3-18
Step 3: Post-Installation 3-18
Using the API to Manage Exadata Cloud@Customer Infrastructure 3-18

4 Managing VM Clusters on Exadata Cloud@Customer

About Managing VM Clusters on Exadata Cloud@Customer 4-1
Required IAM Policy for Managing VM Clusters 4-2
Prerequisites for VM Clusters on Exadata Cloud@Customer 4-2
Using the Console for VM Clusters on Exadata Cloud@Customer 4-3
Using the Console to Create a VM Cluster Network 4-4
Using the Console to Edit a VM Cluster Network 4-6
Using the Console to Download a File Containing the VM Cluster Network
Configuration Details 4-8
Using the Console to Validate a VM Cluster Network 4-8
Using the Console to Terminate a VM Cluster Network 4-9
Using the Console to Create a VM Cluster 4-9
Using the Console to Add SSH Keys After Creating a VM Cluster 4-12
Using the Console to Scale the Resources on a VM Cluster 4-13
Using the Console to Stop, Start, or Reboot a VM Cluster Compute Node 4-15
Using the Console to Check the Status of a VM Cluster Compute Node 4-15
Using the Console to Update the License Type on a VM Cluster 4-16
Using the Console to Move a VM Cluster to Another Compartment 4-16
Using the Console to Terminate a VM cluster 4-17
Using the API to Manage Exadata Cloud@Customer VM Clusters 4-17
Introduction to Scale Up or Scale Down Operations 4-18
Scaling Up or Scaling Down the VM Cluster Resources 4-18
Calculating the Minimum Required Memory 4-19
Calculating the ASM Storage 4-20
Estimating How Much Local Storage You Can Provision to Your VMs 4-21
Scaling Local Storage Down 4-23

5 Managing Backup Destinations for Exadata Cloud@Customer

About Managing Backup Destinations for Exadata Cloud@Customer 5-1
Required IAM Policy for Backup Destinations 5-2
Prerequisites for Backup Destinations for Exadata Cloud@Customer 5-3
Using the Console for Backup Destinations for Exadata Cloud@Customer 5-3
Using the Console to Create a Backup Destination 5-4
Using the Console to Edit a Backup Destination 5-5
Using the Console to Move a Backup Destination to Another Compartment 5-6

v
 Using the Console to Terminate a Backup Destination 5-7
Using the API to Manage Exadata Cloud@Customer Backup Destinations 5-7

6 Oracle Database Software Images

Creation and Storage of Database Software Images 6-2
Using a Database Software Image with an Exadata Cloud@Customer System 6-2
Using the Console to Create a Database Software Image 6-3
Using the OPatch lsinventory Command to Verify the Patches Applied to an Oracle
Home 6-4
Using the Console to Delete a Database Software Image 6-4
Using the Console to View the Patch Information of a Database Software Image 6-5
Using the Console to Move Database Software Image to a Different Compartment 6-5
Using the API for Managing Oracle Database Software Images 6-6

7 Creating Oracle Database Homes on an Exadata Cloud@Customer

System
About Creating Oracle Database Homes on an Exadata Cloud@Customer System 7-1
Required IAM Policy for Creating Oracle Database Homes 7-2
Using the Console to Create Oracle Database Home on Exadata Cloud@Customer 7-2
Using the API to Create Oracle Database Home on Exadata Cloud@Customer 7-4

8 Managing Oracle Database Homes on Exadata Cloud@Customer

Systems
About Managing Oracle Database Homes on Exadata Cloud@Customer Systems 8-1
Required IAM Policy for Managing Oracle Database Homes 8-2
Using the Console for Oracle Database Home on Exadata Cloud@Customer 8-2
Using the Console to View Information About an Oracle Database Home 8-3
Using the Console to Delete an Oracle Database Home 8-3
Differences Between Managing Resources with dbaascli and the Database API 8-4
Using the API to Manage Oracle Database Home on Exadata Cloud@Customer 8-4

9 Managing Oracle Databases on Oracle Exadata Cloud@Customer

Prerequisites and Limitations for Creating and Managing Oracle Databases on
Oracle Exadata Cloud@Customer 9-1
Oracle Database Releases Supported by Oracle Exadata Cloud@Customer 9-2
About Provisioning and Configuring Oracle Databases on Oracle Exadata
Cloud@Customer 9-2
Required IAM Policy for Managing Oracle Databases on Oracle Exadata
Cloud@Customer 9-3

vi
 Using the Console to Manage Databases on Oracle Exadata Cloud@Customer 9-4
Using the Console to Create a Database 9-4
Using the Console to Move a Database to Another Database Home 9-7
Using the Console to Terminate a Database 9-8
Using the API to Manage Oracle Database Components 9-8
Changing the Database Passwords 9-10

10 Using Oracle Data Guard with Exadata Cloud@Customer

About Using Oracle Data Guard with Exadata Cloud@Customer 10-1
Required IAM Policy for Managing Oracle Data Guard Associations on Oracle
Exadata Cloud@Customer 10-2
Prerequisites for Using Oracle Data Guard with Exadata Cloud@Customer 10-3
Compute Nodes 10-3
Password 10-3
Working with Data Guard 10-3
Switchover 10-4
Failover 10-4
Reinstate 10-4
Using the Console to Manage Oracle Data Guard Associations 10-4
Using the Console to Enable Data Guard on an Exadata Cloud@Customer
System 10-5
Using the Console To Perform a Database Switchover 10-6
Using the Console To Perform a Database Failover 10-7
Using the Console To Reinstate a Database 10-7
Using the Console To Terminate a Data Guard Association on an Exadata
Cloud@Customer System 10-8
Using the API to Manage Data Guard Associations on an Exadata
Cloud@Customer System 10-8

11 Managing Database Backup and Recovery on Oracle Exadata

Cloud@Customer
About Managing Backup Destinations for Oracle Exadata Cloud@Customer 11-1
Required IAM Policy for Backup and Recovery 11-3
Using the Console to Manage Backup and Recovery 11-4
Viewing a List of Available Backups with the Console 11-4
Editing Backup Settings with the Console 11-5
Restoring a Database with the Console 11-7
Using the API to Manage Database Backup and Recovery 11-7
Customizing the Automatic Backup Configuration 11-8
Customizing Backup Settings by Using a Generated Configuration File 11-8

vii
 Customizing Which System Files Are Backed Up 11-11
Customizing Which Database Configuration Files Are Backed Up 11-12
Creating an On-Demand Backup by Using the bkup_api Utility 11-13
Recovering a Database Using Oracle Recovery Manager (RMAN) 11-15

12 Connecting to an Exadata Cloud@Customer System

Connecting to a Compute Node with SSH 12-1
Prerequisites for Connecting to an Exadata Cloud@Customer System 12-1
Connecting to a Compute Node from a Microsoft Windows System Using PuTTY 12-2
Connecting from a Unix-Style System 12-3
Accessing a Database After You Connect to the Compute Node 12-3
Connecting to a Database with Oracle Net Services 12-5
Using Oracle Net Services to Connect to a Database 12-5
Prerequisites for Connecting to a Database with Oracle Net Services 12-6
Connecting to a Database Using SCAN 12-6
Connecting to a Database Using a Connect Descriptor that References All
of the SCAN VIPs 12-6
Connecting to a Database Use a Connect Descriptor that References a
Custom SCAN Name 12-7
Connecting to a Database Using a Node Listener 12-8

13 Maintaining an Exadata Cloud@Customer System

User-Managed Maintenance Updates 13-1
Oracle Managed Exadata Cloud@Customer Infrastructure Maintenance Updates 13-1
Managing VM Clusters on Exadata Cloud@Customer 13-2
Overview of the Infrastructure Patching Process 13-2
Scheduling Oracle-Managed Infrastructure Updates 13-3
Set the Automatic Maintenance Schedule for Exadata Cloud@Customer
Infrastructure 13-3
View or Edit the Time of the Next Scheduled Maintenance for Exadata
Cloud@Customer Infrastructure 13-4
View the Maintenance History of Exadata Cloud@Customer Infrastructure 13-5
Monitoring Patching Operations Using Lifecycle State Information 13-5
Receive Notifications about Your Infrastructure Maintenance Updates 13-6
Infrastructure Maintenance Contacts 13-6

14 Patching an Exadata Cloud@Customer System

Required IAM Policy for Patching an Exadata Cloud@Customer System 14-1
About Patching VM Clusters and Database Homes 14-2
Prerequisites for Patching an Exadata Cloud@Customer System 14-3

viii
 Using the Console for Patching an Exadata Cloud@Customer System 14-3
Using the Console to Perform a Patch Operation on a VM Cluster 14-3
Using the Console to Perform a Patch Operation on a Database Home 14-4
Using the Console to View Patch History 14-5
Using the Console to View the Patch History of a VM Cluster 14-5
Using the Console to View the Patch History of a Database Home 14-6
Using the Console to Move a Database to Another Home 14-6
Using the API to Patch an Exadata Cloud@Customer System 14-7

15 Patching and Updating an Exadata Cloud@Customer System

Manually
Administering Software Images 15-1
Viewing Information About Downloaded Software Images 15-3
Viewing Information About Available Software Images 15-3
Downloading a Software Image 15-4
Activating a Software Image 15-5
Deleting a Software Image 15-6
Managing Oracle Database and Oracle Grid Infrastructure Patches 15-7
About the dbaascli Utility 15-7
List Available Patches 15-8
Check Prerequisites Before Applying a Patch 15-8
Apply a Patch 15-10
List Applied Patches 15-12
Roll Back a Patch 15-12
Manually Patching Oracle Database and Oracle Grid Infrastructure Software 15-14
Updating the Guest VM Operating System 15-15
Preparing for an Operating System Update 15-15
Updating the Operating System on All Compute Nodes of an Oracle Exadata
Cloud@Customer System 15-16
Installing Additional Operating System Packages 15-23
Cloud Tooling Updates 15-24
Checking the Installed Cloud Tooling Release for Updates 15-24
Updating the Cloud Tooling Release 15-25

16 Managing Exadata Resources with Oracle Enterprise Manager

Cloud Control
Overview of Oracle Enterprise Manager Cloud Control 16-1
Features of Enterprise Manager Cloud Control 16-2

ix
17 Exadata Cloud@Customer Gen1 to Out-of-Place Cloud Upgrade to
Exadata Cloud@Customer Gen2 Infrastructure
Overview of Exadata Cloud@Customer Gen1 to Out-of-Place Cloud Upgrade to
Exadata Cloud@Customer Gen2 Infrastructure 17-1
Scope for Exadata Cloud@Customer Gen1 to Gen2 Out-of-Place Cloud Upgrade 17-2
Hardware and Software Required for Out-of-Place Cloud Upgrade to New Exadata
Cloud@Customer X8M Gen2 Infrastructure 17-3
Using Oracle Zero Downtime Migration (ZDM) to Migrate Oracle Databases 17-4
During Out-of-Place Cloud Upgrade to New Exadata Cloud@Customer X8M Gen2
Infrastructure 17-9
Post Out-of-Place Cloud Upgrade to New Exadata Cloud@Customer X8M Gen2
Infrastructure 17-10
Best Practices for Out-of-Place Cloud Upgrade to New Exadata Cloud@Customer
X8M Gen2 Infrastructure 17-10
Out-of-Place Cloud Upgrade to New Exadata Cloud@Customer X8M Gen2
Infrastructure Known Issues 17-12

18 Using the dbaascli Utility on Exadata Cloud@Customer

About Using the dbaascli Utility on Exadata Cloud@Customer 18-3
dbaascli cpuscale get_status 18-4
dbaascli cpuscale update 18-4
dbaascli cswlib download 18-5
dbaascli cswlib list 18-6
dbaascli database bounce 18-6
dbaascli database changepassword 18-7
dbaascli database move 18-8
dbaascli database start 18-8
dbaascli database status 18-8
dbaascli database stop 18-9
dbaascli database update 18-9
dbaascli dbhome info 18-10
dbaascli dbhome purge 18-11
dbaascli dbimage list 18-11
dbaascli listener bounce 18-12
dbaascli listener start 18-12
dbaascli listener status 18-12
dbaascli listener stop 18-13
dbaascli patch db apply 18-13
dbaascli patch db list 18-15
dbaascli patch db prereq 18-15
dbaascli patch db switchback 18-16

x
 dbaascli patch tools apply 18-17
dbaascli patch tools list 18-17
dbaascli pdb checkdb 18-18
dbaascli pdb checknode 18-18
dbaascli pdb checkpdb 18-19
dbaascli pdb close 18-19
dbaascli pdb connect_info 18-20
dbaascli pdb connect_string 18-20
dbaascli pdb create 18-21
dbaascli pdb delete 18-21
dbaascli pdb info 18-22
dbaascli pdb local_clone 18-22
dbaascli pdb open 18-23
dbaascli pdb remote_clone 18-23
dbaascli pdb rename 18-24
dbaascli pdb resize 18-24
dbaascli tde rotate masterkey 18-25
dbaascli tde status 18-25

19 Monitoring and Managing Exadata Storage Servers with ExaCLI

About the ExaCLI Command 19-1
Exadata Storage Server Username and Password 19-1
ExaCLI Command 19-2
Connecting to a Storage Server with ExaCLI 19-8

20 Policy Details for Exadata Cloud@Customer

About Resource-Types 20-1
Resource-Types for Exadata Cloud@Customer 20-2
Supported Variables 20-2
Details for Verb + Resource-Type Combinations 20-2
Database-Family Resource Types 20-4
exadata-infrastructures 20-4
vmcluster-networks 20-5
vmclusters 20-6
backup-destinations 20-7
db-nodes 20-8
db-homes 20-9
databases 20-9
backups 20-10

xi
 autonomous-vmclusters 20-11
autonomous-container-databases 20-12
autonomous-databases 20-13
data-guard-association 20-13
key-stores 20-14
autonomousContainerDatabaseDataguardAssociations 20-15
AutonomousDatabaseDataguardAssociation 20-16
Permissions Required for Each API Operation 20-17

21 Oracle Exadata Cloud@Customer Events

Exadata Infrastructure Event Types 21-1
VM Cluster Network Event Types 21-4
VM Cluster Event Types 21-5
Backup Destination Event Types 21-7
Database Node Event Types (Cloud@Customer) 21-8
Database Home Event Types (Cloud@Customer) 21-9
Database Event Types (Cloud@Customer) 21-10
Database and Grid Infrastructure Patching Event Types 21-11
Autonomous VM Cluster Event Types 21-14
Autonomous Container Database Event Types 21-18
Autonomous Database Event Types 21-19
Data Guard Event Types 21-20
Autonomous Database Autonomous Data Guard Event Types 21-23
Key Store Event Types 21-27
Exadata Cloud@Customer Infrastructure Patching Event Types 21-28

22 Troubleshooting Exadata Cloud@Customer Systems

Patching Failures on Exadata Cloud@Customer Systems 22-1
Determining the Problem 22-1
Troubleshooting and Diagnosis 22-2
Host Issues 22-2
Oracle Grid Infrastructure Issues 22-3
Oracle Databases Issues 22-5
Oracle Cloud Tooling Issues 22-7
Failed Patch Modifies the Home Name in oraInventory with the Suffix "_PIP" 22-7
Patching Primary and Standby Databases Configured with Oracle Data Guard
Fails 22-7
Obtaining Further Assistance 22-8
Collecting Cloud Tooling Logs 22-8
Collecting Configuration Tools Logs 22-9

xii
 Collecting Oracle Diagnostics 22-9
Database is Down While Performing Downgrade to Release 11.2 or 12.1 22-10
After Database Upgrade, the Standby Database Remains in Mounted State in
Oracle Data Guard Configurations 22-10
Primary Database Fails to Downgrade to 18c in Oracle Data Guard Configurations 22-11
Deleting a Database Does Not Delete the Associated Oracle Home 22-12

23 Introduction to Autonomous Database on Exadata

Cloud@Customer
Database System Architecture Overview 23-1
Resource Types 23-1
Deployment Order 23-2
User Roles 23-2
Available Exadata Infrastructure Hardware Shapes 23-3
Oracle Exadata Cloud@Customer X8M-2 System Specifications 23-4
Access Control Lists (ACLs) for Autonomous Databases on Exadata
Cloud@Customer 23-4

24 Managing Autonomous Exadata VM Clusters

Create an Autonomous Exadata VM Cluster 24-1
View a List of Autonomous Exadata VM Clusters 24-2
View Details of an Autonomous Exadata VM Cluster 24-2
Change the License Type on an Autonomous VM Cluster 24-3
Move an Autonomous Exadata VM Cluster to Another Compartment 24-3
Terminate an Autonomous Exadata VM Cluster 24-3
Using the API to Manage Autonomous Exadata VM Clusters 24-4

25 Managing Encryption Keys on External Devices

About Oracle Key Vault 25-1
Overview of Key Store 25-2
Required IAM Policy for Managing OKV on Oracle Exadata Cloud@Customer 25-2
Tagging Resources 25-3
Moving Resources to a Different Compartment 25-3
Setting Up Your Exadata Cloud@Customer to Work With Oracle Key Vault 25-3
Step 1: Create a Vault in OCI Vault Service and Add a Secret to the Vault to
Store OKV REST Administrator Password 25-4
Step 2: Create a Dynamic Group and a Policy Statement for Key Store to
Access Secret in OCI Vault 25-4
Step 3: Create a Dynamic Group and a Policy Statement for Exadata
Infrastructure to Key Store 25-5

xiii
 Step 4: Create a Policy Statement for Database Service to Use Secret from OCI
Vault Service 25-6
Step 5: Create Key Store 25-6
Managing Your Key Store 25-7
View Key Store Details 25-7
Edit Key Store Details 25-8
Move a Key Store to Another Compartment 25-8
Delete a Key Store 25-8
View Key Store Associated Autonomous Container Database Details 25-9
Using the API to Manage Key Store 25-9

26 Managing Autonomous Container Databases

Create an Autonomous Container Database 26-1
View a List of Autonomous Container Databases 26-3
View the List of Autonomous Container Databases in an Autonomous Exadata
VM Cluster 26-3
View the List of Autonomous Container Databases in a Compartment 26-4
View Details of an Autonomous Container Database 26-4
Rotate CDB Encryption Key 26-4
Change the Backup Retention Policy of an Autonomous Container Database 26-5
Change the Maintenance Schedule of an Autonomous Container Database 26-6
Restart an Autonomous Container Database 26-6
Move an Autonomous Container Database to Another Compartment 26-7
Terminate an Autonomous Container Database 26-7
Using the API to Manage Autonomous Container Databases 26-8

27 Managing Autonomous Databases

Create an Autonomous Database 27-1
Manage Access Control List of an Autonomous Database 27-3
View a List of Autonomous Databases 27-4
View Details of an Autonomous Database 27-5
Rotate ADB Encryption Key 27-5
Set the Password of an Autonomous Database's ADMIN User 27-6
Scale the CPU Core Count or Storage of an Autonomous Database 27-6
Enable or Disable Auto Scaling for an Autonomous Database 27-7
Move an Autonomous Database to Another Compartment 27-7
Stop or Start an Autonomous Database 27-8
Restart an Autonomous Database 27-9
Back Up an Autonomous Database Manually 27-9
Restore an Autonomous Database 27-10

xiv
 Restore from a Backup 27-10
Restore to a Point in Time 27-10
Clone an Autonomous Database 27-11
Terminate an Autonomous Database 27-13
Using the API to Manage Autonomous Databases 27-13
Monitor Performance with Autonomous Database Metrics 27-14
View Top Six Metrics for an Autonomous Database 27-14
View Aggregated Metrics for Autonomous Databases in a Compartment 27-15
Autonomous Database Metrics and Dimensions 27-16

28 Connecting to Autonomous Databases

Download the Wallet for an Autonomous Database 28-1
Get the APEX and SQL Developer Web URLs for an Autonomous Database 28-3

29 Patching ADB on Exadata Cloud@Customer Infrastructure

Overview of ADB on Exadata Cloud@Customer Infrastructure Patching 29-1
Specifying When Maintenance Can Occur 29-1
Specifying What Kind of Patches to Apply 29-2

30 Using Autonomous Data Guard with Autonomous Database on

Exadata Cloud@Customer
Enabling Autonomous Data Guard on an Autonomous Container Database 30-1
Create an Autonomous Data Guard Enabled Autonomous Container Database 30-2
View Details of a Data Guard Enabled Primary or Standby Autonomous
Container Database 30-4
Perform a Failover to Standby Autonomous Container Database 30-5
Perform a Switchover to Standby or Primary Autonomous Container Database 30-5
Reinstate Data Guard Enabled Standby Autonomous Container Database 30-6
Terminate a Data Guard Enabled Primary Autonomous Container Database 30-6
Terminate a Data Guard Enabled Standby Autonomous Container Database 30-7
Operations Performed Using the APIs 30-7
Enabling Autonomous Data Guard on an Autonomous Database 30-8
View Autonomous Data Guard Enablement 30-9
Create an Autonomous Data Guard Enabled Autonomous Database 30-9
View Details of a Data Guard Enabled Primary or Standby Autonomous
Database 30-11
Maintenance Scheduling and Patching Data Guard Enabled Autonomous Container
Database 30-11

xv
 Configure Automatic Maintenance Schedule for a Data Guard Enabled
Autonomous Container Database 30-12
View the Next Scheduled Maintenance Run of a Data Guard Enabled
Autonomous Container Database 30-13
View the Maintenance History of a Data Guard Enabled Autonomous Container
Database 30-13
Immediately Patch a Data Guard Enabled Autonomous Container Database 30-14
Reschedule or Skip scheduled Maintenance for Data Guard Enabled
Autonomous Container Database 30-14

31 Using Performance Hub to Analyze Database Performance

Performance Hub Features 31-1
Time Range Selector 31-2
Time Zone Selector 31-3
ASH Analytics Tab 31-3
SQL Monitoring Tab 31-3
Blocking Sessions Tab 31-4
Using the Oracle Cloud Infrastructure Console 31-4
Navigate to Performance Hub in the Oracle Cloud Infrastructure Console
Interface of an Autonomous Database 31-4
View the Average Active Sessions Data by a Selected Dimension 31-5
Filter Average Active sessions Data 31-6
View the SQL Monitoring Report 31-6
View the Blocking and Waiting Sessions 31-7
Setting the Minimum Wait Time 31-8
Killing a Session 31-8
Displaying Lock Details 31-8
Displaying Wait Event Information 31-9
Displaying Session Details 31-9
Displaying SQL Details 31-9

32 Security Guide for Exadata Cloud@Customer Systems

Security Configurations and Default Enabled Features 32-1
Responsibilities 32-1
Guiding Principles Followed for Security Configuration Defaults 32-2
Security Features 32-3
Guest VM Default Fixed Users 32-4
Guest VM Default Security Settings 32-6
Guest VM Default Processes 32-7
Guest VM Network Security 32-8
Additional Procedures for Updating Security Posture 32-10

xvi
 Customer Responsibilities 32-10
Enabling Additional Security Capabilities 32-10

Index

xvii
 What’s New in Oracle Exadata Cloud@Customer Gen2

What’s New in Oracle Exadata

Cloud@Customer Gen2
Oracle is constantly adding new capabilities to Oracle Exadata Cloud@Customer and
ADB-D on Oracle Exadata Cloud@Customer. This preface provides a brief overview
of all new features as they are released.
• What’s New in Oracle Exadata Cloud@Customer
• What’s New in ADB-D on Oracle Exadata Cloud@Customer

What’s New in Oracle Exadata Cloud@Customer

• Oracle Database Software Images
• Exadata Cloud@Customer Infrastructure Patching Automation
• Customer Maintenance Contacts
• X8M-2 System Support
• Enable and Manage Data Guard Associations
• Oracle Exadata Cloud@Customer Deployment Assistant
• Oracle Grid Infrastructure and Oracle Database Patching
• Per-Second Billing for OCPU Usage
• Shared Database Home Resource Tags
• Create and Manage Multiple Virtual Machines per Exadata System (MultiVM)
• Scale OCPUs Without Cloud Connectivity
• Configure Oracle Database Character Set and National Character Set
• Specify a Time Zone While Provisioning Oracle Exadata Cloud@Customer
Infrastructure
• Shared Database Homes for Oracle Exadata Cloud@Customer
• X7-2 System Support

Oracle Database Software Images

• Services: Database
• Release Date: April 08, 2021
Use Database Software Image resource type to create databases and Oracle
Database Homes, and to patch databases. For more information, see:

xviii
 What’s New in Oracle Exadata Cloud@Customer Gen2

• Oracle Database Software Images

• Using the Console to Create Oracle Database Home on Exadata
Cloud@Customer
• Using the Console to Perform a Patch Operation on a Database Home
Related Topics
• Oracle Database Software Images
Learn about Database Software Image resource type and how you can use it to
create Oracle Databases and Oracle Database Homes and to patch databases.
• Using the Console to Create Oracle Database Home on Exadata
Cloud@Customer
To create an Oracle Database home in an existing VM cluster with the Console, be
prepared to provide values for the fields required.
• Using the Console to Perform a Patch Operation on a Database Home
Learn to apply patches on a Database Home.

Exadata Cloud@Customer Infrastructure Patching Automation

• Services: Database
• Release Date: December 08, 2020
You can now schedule a maintenance window for Oracle-managed Exadata
Cloud@Customer infrastructure patching. For more information, see Maintaining an
Exadata Cloud@Customer System.
Related Topics
• Maintaining an Exadata Cloud@Customer System
Learn how to perform patching operations on Exadata Cloud@Customer
infrastructure.

Customer Maintenance Contacts

• Services: Database
• Release Date: September 22, 2020
• Release Notes: Exadata Cloud@Customer: Customer Maintenance Contacts

X8M-2 System Support

• Services: Database
• Release Date: August 18, 2020
• Release Notes: Exadata Cloud@Customer: X8M-2 System Support

Enable and Manage Data Guard Associations

• Services: Database
• Release Date: August 18, 2020

xix
 What’s New in Oracle Exadata Cloud@Customer Gen2

• Release Notes: Exadata Cloud@Customer: Enable and Manage Data Guard

Associations

Oracle Exadata Cloud@Customer Deployment Assistant

• Services: Database
• Release Date: August 08, 2020
• Release Notes: Exadata Cloud@Customer: Deployment Assistant

Oracle Grid Infrastructure and Oracle Database Patching

• Services: Database
• Release Date: July 28, 2020
• Release Notes: Exadata Cloud@Customer: Oracle Grid Infrastructure and Oracle
Database Patching

Per-Second Billing for OCPU Usage

• Services: Database
• Release Date: July 14, 2020
• Release Notes: Exadata Cloud@Customer: Per-Second Billing for OCPU Usage

Shared Database Home Resource Tags

• Services: Database
• Release Date: June 23, 2020
• Release Notes: Exadata Cloud@Customer: Shared Database Home Resource
Tags

Create and Manage Multiple Virtual Machines per Exadata System

(MultiVM)
• Services: Database
• Release Date: June 13, 2020
• Release Notes: Exadata Cloud@Customer: Create and Manage Multiple Virtual
Machines per Exadata System (MultiVM)

Scale OCPUs Without Cloud Connectivity

• Services: Database
• Release Date: June 13, 2020

xx
 What’s New in Oracle Exadata Cloud@Customer Gen2

• Release Notes: Exadata Cloud@Customer: Scale OCPUs Without Cloud

Connectivity

Configure Oracle Database Character Set and National Character Set

• Services: Database
• Release Date: May 7, 2020
• Release Notes: Exadata Cloud@Customer: Configure Oracle Database
Character Set and National Character Set

Specify a Time Zone While Provisioning Oracle Exadata

Cloud@Customer Infrastructure
• Services: Database
• Release Date: May 7, 2020
• Release Notes: Exadata Cloud@Customer: Specify a Time Zone While
Provisioning Oracle Exadata Cloud@Customer Infrastructure

Shared Database Homes for Oracle Exadata Cloud@Customer

• Services: Database
• Release Date: March 31, 2020
• Release Notes: Exadata Cloud@Customer: Shared Database Homes

X7-2 System Support

• Services: Database
• Release Date: March 19, 2020
• Release Notes: Exadata Cloud@Customer: X7-2 System Support

What’s New in ADB-D on Oracle Exadata Cloud@Customer

• Infrastructure Patching
• Access Control List (ACL) to Restrict Access to Autonomous Data Guard Enabled
Autonomous Databases
• ADB-D on Exadata Cloud@Customer: Monitor Performance with Autonomous
Database Metrics
• ADB-D on Exadata Cloud@Customer: Autonomous Data Guard
• Access Control List (ACL) to Restrict Access to Autonomous Databases
• Oracle Key Vault (OKV) Integration
• X8M-2 System Support

xxi
 What’s New in Oracle Exadata Cloud@Customer Gen2

• Per-Second Billing for Autonomous Database OCPU Usage

• Oracle Autonomous Database on Oracle Exadata Cloud@Customer

Infrastructure Patching
• Services: Database
• Release Date: May 04, 2021
ADB-Dedicated maintenance involves patching Exadata Infrastructure(EI)
Autonomous VM Cluster, and Autonomous Container Database (ACD).
Related Topics
• Patching ADB on Exadata Cloud@Customer Infrastructure

Access Control List (ACL) to Restrict Access to Autonomous Data

Guard Enabled Autonomous Databases
• Services: Database
• Release Date: January 26, 2021
An access control list (ACL) provides additional protection to your database by
allowing only the clients with specific IP addresses to connect to the database. You
can add IP addresses individually, or in CIDR blocks.
Related Topics
• Create an Autonomous Data Guard Enabled Autonomous Database
• Manage Access Control List of an Autonomous Database

ADB-D on Exadata Cloud@Customer: Monitor Performance with

Autonomous Database Metrics
• Services: Database
• Release Date: December 15, 2020
You can monitor the health, capacity, and performance of your Autonomous
Databases with metrics, alarms, and notifications. You can use Oracle Cloud
Infrastructure console or Monitoring APIs to view metrics.
Related Topics
• Monitor Performance with Autonomous Database Metrics

ADB-D on Exadata Cloud@Customer: Autonomous Data Guard

• Services: Database
• Release Date: November 17, 2020

xxii
 What’s New in Oracle Exadata Cloud@Customer Gen2

Enabling Autonomous Data Guard on an Autonomous Container Database on

dedicated Exadata infrastructure creates a standby (peer) Autonomous Container
Database that provides data protection, high availability, and facilitates disaster
recovery for the primary database.
Related Topics
• Using Autonomous Data Guard with Autonomous Database on Exadata
Cloud@Customer
Learn how to enable a Data Guard association between databases, change the
role of a database in a Data Guard association using either a switchover or a
failover operation, and reinstate a failed database.

Access Control List (ACL) to Restrict Access to Autonomous

Databases
• Services: Database
• Release Date: November 10, 2020
An access control list (ACL) provides additional protection to your database by
allowing only the clients with specific IP addresses to connect to the database. You
can add IP addresses individually, or in CIDR blocks.
Related Topics
• Access Control Lists (ACLs) for Autonomous Databases on Exadata
Cloud@Customer
• Create an Autonomous Database
• Manage Access Control List of an Autonomous Database
• Clone an Autonomous Database

Oracle Key Vault (OKV) Integration

• Services: Database
• Release Date: October 27, 2020
Integrate your on-premises Oracle Key Vault (OKV) with Autonomous Database on
Exadata Cloud@Customer to secure your critical data on-premises.
Oracle Key Vault integration enables you to take complete control of your encryption
keys and store them securely on an external, centralized key management device.
Related Topics
• Managing Encryption Keys on External Devices

X8M-2 System Support

• Services: Database
• Release Date: September 25, 2020
• Release Notes: ADB-D on Exadata Cloud@Customer: X8M-2 System Support

xxiii
 What’s New in Oracle Exadata Cloud@Customer Gen2

Per-Second Billing for Autonomous Database OCPU Usage

• Services: Database
• Release Date: July 21, 2020
• Release Notes: Exadata Cloud@Customer: Per-Second Billing for Autonomous
Database OCPU Usage

Oracle Autonomous Database on Oracle Exadata Cloud@Customer

• Services: Database
• Release Date: June 23, 2020
• Release Notes: Exadata Cloud@Customer: Oracle Autonomous Database

xxiv
1
Introduction to Oracle Exadata
Cloud@Customer
Learn how you can leverage the combined capabilities of Oracle Exadata and Oracle
Cloud Infrastructure with Oracle Exadata Cloud@Customer
• About Oracle Exadata Cloud@Customer
With Oracle Exadata Cloud@Customer, you can maintain absolute control over
your data while leveraging the combined capabilities of Oracle Exadata and Oracle
Cloud Infrastructure managed by Oracle.
• Exadata Cloud Management Interfaces
Exadata Cloud@Customer provides a variety of management interfaces to fit your
use case and automation needs.
• Per-Second Billing for OCPU Usage
• System Configuration Options for Oracle Exadata Cloud@Customer
To meet the needs of your enterprise, you can select from one of the three Oracle
Exadata X8M-2, X8-2, or X7-2 System Models.
• Oracle Exadata X8M-2 System Model Specifications
Review the technical specifications of available Exadata System Shapes.
• Oracle Exadata X8-2 System Model Specifications
Review the technical specifications of available Exadata System Shapes.
• Oracle Exadata X7-2 System Model Specifications
Review the technical specifications of available Exadata System Shapes.
• Moving to Oracle Cloud Using Zero Downtime Migration

About Oracle Exadata Cloud@Customer

With Oracle Exadata Cloud@Customer, you can maintain absolute control over your
data while leveraging the combined capabilities of Oracle Exadata and Oracle Cloud
Infrastructure managed by Oracle.
Oracle Exadata Cloud@Customer enables you to apply the combined power of Oracle
Exadata and Oracle Cloud Infrastructure inside your own data center. You have full
access to the features and capabilities of Oracle Database along with the intelligent
performance and scalability of Oracle Exadata, but with Oracle owning and managing
the Exadata infrastructure. You can use the Oracle Cloud Infrastructure console and
APIs to manage Oracle Exadata Cloud@Customer just as with any other cloud
resource, while maintaining absolute sovereignty over your data.
Each Oracle Exadata Cloud@Customer system configuration contains compute nodes
(database servers) and Oracle Exadata Storage Servers that are interconnected using
a high-speed, low-latency InfiniBand network, and intelligent Oracle Exadata software.
Each configuration is equipped with a fixed amount of memory, storage, and network
resources.

1-1
 Chapter 1
Exadata Cloud Management Interfaces

Oracle Exadata Cloud@Customer uses virtual machine (VM) technology to separate

the customer-managed and components managed by Oracle on each compute node.
You have root privilege for the Oracle Exadata compute node VMs, so you can
manage the Oracle Database, Oracle Grid Infrastructure, and Oracle Exadata system
software. However, you do not have administrative access to the physical compute
node hardware, which Oracle administers.
Oracle Exadata Cloud@Customer uses Oracle Exadata Storage Servers for database
storage. The storage is allocated to disk groups managed by Oracle Automatic
Storage Management (Oracle ASM). You have full administrative access to the
Oracle ASM disk groups, but Oracle administers the Oracle Exadata Storage Server
hardware and software.
In addition to the compute node hardware and Oracle Exadata Storage Servers,
Oracle also manages other Oracle Exadata Cloud@Customer infrastructure
components, including the network switches, power distribution units (PDUs), and
integrated lights-out management (ILOM) interfaces.
Subscription to Oracle Exadata Cloud@Customer can include all of the required
Oracle Database software licenses, or you can choose to bring Oracle Database
software licenses that you already own to Oracle Exadata Cloud@Customer. If
you choose to include Oracle Database software licenses in your Oracle Exadata
Cloud@Customer subscription, then the included licenses contain all of the features of
Oracle Database Enterprise Edition, plus all of the database enterprise management
packs, and all of the Enterprise Edition options, such as Oracle Database In-Memory
and Oracle Real Application Clusters (Oracle RAC). Exadata Cloud@Customer also
comes with cloud-specific software tools that assist with administration tasks, such as
backup, recovery, and patching.
On each Oracle Exadata Cloud@Customer system, you can create one or more
databases. Apart from the inherent storage and processing capacity of your Oracle
Exadata system, there is no set maximum for the number of databases that you can
create.

Exadata Cloud Management Interfaces

Exadata Cloud@Customer provides a variety of management interfaces to fit your use
case and automation needs.
• Introduction to Exadata Cloud Management Interfaces
• OCI Control Plane Interfaces
• Local VM Command-Line Interfaces

Introduction to Exadata Cloud Management Interfaces

The Exadata Cloud Service resources on Oracle Cloud Infrastructure (OCI) and Gen2
Cloud@Customer are created and managed through a variety of interfaces provided to
fit your different management use cases including:
• OCI Console graphical interface and automation tools
• Application Programming Interfaces (APIs)
• Command-Line Interfaces (CLIs)
The management interfaces are grouped into two primary categories:

1-2
 Chapter 1
Exadata Cloud Management Interfaces

• OCI Control Plane Interfaces

• Local Exadata Cloud VM CLIs

Note:
For more information and best practices on how these interfaces align for
various Exadata Cloud database management use cases, refer to My Oracle
Support note: Exadata Cloud API/CLI Alignment Matrix (Doc ID 2768569.1).

Related Topics
• https://support.oracle.com/epmos/faces/DocContentDisplay?id=2768569.1

OCI Control Plane Interfaces

The OCI APIs are typical REST APIs that use HTTPS requests and responses. The
OCI Console, an intuitive, graphical interface for creating and managing your Exadata
Cloud and other OCI resources, is one of the interfaces to the OCI APIs. When
looking to develop automation utilizing the OCI APIs, a number of additional interfaces
including: kits, tools and plug-ins, are provided to facilitate development and simplify
the management of of OCI resources. A subset of these APIs apply to Exadata Cloud
resources and its infrastructure. Each of these interfaces can be used to accomplish
the same functionality, all calling the OCI APIs, and are provided to enable flexibility
and choice depending on preference and use case.
• Command Line Interface (CLI): The OCI CLI is a small footprint tool that you can
use on its own or with the Console to complete Exadata Cloud resource and other
OCI tasks. The CLI provides the same core functionality as the Console, plus
additional commands. Some of these, such as the ability to run scripts, extend the
Console's functionality.
• Software Development Kits (SDK): OCI provides SDKs to enable the developing
custom solutions for your Exadata Cloud and other OCI based services and
applications.
• DevOps Tools and Plug-ins: These tools can simplify provisioning and managing
infrastructure, enable automated processes and facilitate development. Tools
include the OCI Terraform Provider used with Resource Manager and OCI Ansible
Collection.
• Cloud Shell: Cloud Shell is a free-to-use, browser-based terminal, accessible
from the OCI Console, that provides access to a Linux shell with pre-authenticated
OCI CLI and other useful developer tools. You can use the shell to interact with
Exadata Cloud and other OCI resources, follow labs and tutorials, and quickly run
OCI CLI commands.
• Appendix and Reference: This general reference shows how to configure the
SDKs and other developer tools to integrate with Oracle Cloud Infrastructure
services.
• REST APIs: This complete reference provides details on the Oracle Cloud
Infrastructure REST APIs, including descriptions, syntax, endpoints, errors, and
signatures. Exadata Cloud at Customer specific OCI REST APIs can be found
throughout the documentation in the Using the API sections:

1-3
 Chapter 1
Exadata Cloud Management Interfaces

– Using the API to Manage Exadata Cloud@Customer Infrastructure

– Using the API to Manage Exadata Cloud@Customer Backup Destinations
– Using the API to Manage Exadata Cloud@Customer VM Clusters
– Using the API to Create Oracle Database Home on Exadata
Cloud@Customer
– Using the API to Manage Oracle Database Home on Exadata
Cloud@Customer
– Using the API to Manage Oracle Database Components
– Using the API to Manage Data Guard Associations on an Exadata
Cloud@Customer System
– Using the API to Manage Database Backup and Recovery
– Using the API to Patch an Exadata Cloud@Customer System
Related Topics
• Command Line Interface (CLI)
• Software Development Kits
• DevOps Tools and Plug-ins
• Terraform Provider
• Resource Manager
• Ansible Collection
• Cloud Shell
• Appendix and Reference
• REST APIs
• Using the API to Manage Exadata Cloud@Customer Infrastructure
• Using the API to Manage Exadata Cloud@Customer Backup Destinations
• Using the API to Manage Exadata Cloud@Customer VM Clusters
• Using the API to Create Oracle Database Home on Exadata Cloud@Customer
• Using the API to Manage Oracle Database Home on Exadata Cloud@Customer
• Using the API to Manage Oracle Database Components
• Using the API to Manage Data Guard Associations on an Exadata
Cloud@Customer System
• Using the API to Manage Database Backup and Recovery
• Using the API to Patch an Exadata Cloud@Customer System

Local VM Command-Line Interfaces

In addition to the OCI REST-based APIs, CLI utilities located on the VM guests,
provisioned as part of the VM clusters on the Exadata Cloud Infrastructure, are
available to perform various lifecycle and administration operations.
The best practice is to use these utilities when a corresponding OCI API is not
available or the Exadata Cloud@Customer is in a disconnected mode.

1-4
 Chapter 1
Per-Second Billing for OCPU Usage

The utilities include:

• dbaascli: Use the dbaascli utility to perform various database lifecycle and
administration operations on the Exadata Cloud Service such as
– changing the password of a database user
– starting a database
– managing pluggable databases (PDBs)
– scaling the CPU core count in disconnected mode
• bkup_api: Use the bkup_api utility to perform various backup and recovery
operations on the Exadata Cloud Service such as creating an on-demand
backup of a complete database or an individual pluggable database (PDB), or
to customize backup settings used by the automatic backup configuration
• ExaCLI: Use the ExaCLI command-line utility to perform monitoring and
management functions on Exadata storage servers in the Exadata Cloud Service.
These utilities are provided in addition to, and separate from, the OCI API-based
interfaces listed above. To use the local VM command-line utilities, you must be
connected to a VM guest compute node in an Exadata Cloud VM cluster and use
the VM operating system user security, not the OCI user security, for execution.
The utilities can be used to perform operations if the Exadata Cloud@Customer is
disconnected from the OCI Control Plane. Most operations executed by these utilities
sync their changes back to the OCI Control Plane using a process called DB Sync.
However, there can be operations not synced with the Control Plane.
Related Topics
• dbaascli
• bkup_api
• customize backup settings
• ExaCLI

Per-Second Billing for OCPU Usage

Exadata Cloud@Customer Gen2 uses per-second billing for OCPUs. This means that
OCPU usage is billed by the second, with a minimum usage period of 1 minute.

System Configuration Options for Oracle Exadata

Cloud@Customer
To meet the needs of your enterprise, you can select from one of the three Oracle
Exadata X8M-2, X8-2, or X7-2 System Models.
Exadata Cloud@Customer is offered in the following Exadata System Shapes:
• Base System: Contains two compute nodes and three Oracle Exadata Storage
Servers. A Base System is an entry-level configuration. Compared to other
configurations, a Base System contains Oracle Exadata Storage Servers with
significantly less storage capacity, and compute nodes with significantly less
memory and processing power.

1-5
 Chapter 1
Oracle Exadata X8M-2 System Model Specifications

• Quarter Rack: Contains two compute nodes and three Oracle Exadata Storage
Servers.
• Half Rack: Contains four compute nodes and six Oracle Exadata Storage
Servers.
• Full Rack: Contains eight compute nodes and 12 Oracle Exadata Storage
Servers.
Each Exadata System Shape is equipped with a fixed amount of memory, storage, and
network resources. All Shapes are based on Oracle Exadata X8M-2, X8-2, or X7-2
System Models.

Oracle Exadata X8M-2 System Model Specifications

Review the technical specifications of available Exadata System Shapes.

Table 1-1 Oracle Exadata X8M-2 System Model Specifications

Property Base Rack Quarter Rack Half Rack Full Rack

Number of 2 2 4 8
Compute Nodes
Total Maximum 48 100 200 400
Number of
Enabled CPU
Cores
Total RAM 656 GB 2780 GB 5560 GB 11120 GB
Capacity
Persistent 0 4.6 TB 9.2 TB 18.4 TB
Memory
Number of 3 3 6 12
Exadata Storage
Servers
Total Raw Flash 38.4 TB 76.8 TB 153.6 TB 307.2 TB
Storage Capacity
Total Usable 74 TB 149 TB 299 TB 598 TB
Storage
Capacity**
Maximum 4 8 8 8
Number of VMs

** TB=1024^4

Oracle Exadata X8-2 System Model Specifications

Review the technical specifications of available Exadata System Shapes.

Table 1-2 Oracle Exadata X8-2 System Model Specifications

Property Base System Quarter Rack Half Rack Full Rack

Number of 2 2 4 8
Compute Nodes

1-6
 Chapter 1
Oracle Exadata X7-2 System Model Specifications

Table 1-2 (Cont.) Oracle Exadata X8-2 System Model Specifications

Property Base System Quarter Rack Half Rack Full Rack

Total Maximum 48 100 200 400
Number of
Enabled CPU
Cores
Total RAM 720 GB 1440 GB 2880 GB 5760 GB
Capacity
Number of 3 3 6 12
Exadata Storage
Servers
Total Raw Flash 38.4 TB 76.8 TB 153.6 TB 307.2 TB
Storage Capacity
Total Raw Disk 252 TB 504 TB 1008 TB 2016 TB
Storage Capacity
Total Usable 74.8 TB 149.7 TB 299.4 TB 598.7 TB
Storage Capacity
Maximum 5 5 5 5
Number of VMs

Oracle Exadata X7-2 System Model Specifications

Review the technical specifications of available Exadata System Shapes.

Table 1-3 Oracle Exadata X7-2 System Model Specifications

Property Base System Quarter Rack Half Rack Full Rack

Number of 2 2 4 8
Compute Nodes
Total Maximum 44 92 184 368
Number of
Enabled CPU
Cores
Total RAM 480 GB 1440 GB 2880 GB 5760 GB
Capacity
Number of 3 3 6 12
Exadata Storage
Servers
Total Raw Flash 19.2 TB 76.8 TB 153.6 TB 307.2 TB
Storage Capacity
Total Raw Disk 144 TB 360 TB 720 TB 1440 TB
Storage Capacity
Total Usable 42.7 TB 106.9 TB 213.8 TB 427.6 TB
Storage Capacity
Maximum 6 6 6 6
Number of VMs

Moving to Oracle Cloud Using Zero Downtime Migration

1-7
 Chapter 1
Moving to Oracle Cloud Using Zero Downtime Migration

Oracle now offers the Zero Downtime Migration service, a quick and easy way to move
on-premises databases to Oracle Cloud Infrastructure.
Zero Downtime Migration leverages Oracle Active Data Guard to create a standby
instance of your database in an Oracle Cloud Infrastructure system. You switch over
only when you are ready, and your source database remains available as a standby.
Use the Zero Downtime Migration service to migrate databases individually or at
the fleet level. See Move to Oracle Cloud Using Zero Downtime Migration for more
information.
Related Topics
• Move to Oracle Cloud Using Zero Downtime Migration

1-8
2
Preparing for Exadata Cloud@Customer
Review the site and network requirements, and the checklists to prepare and deploy
Exadata Cloud@Customer in a customer data center.
• Site Requirements for Oracle Exadata Cloud@Customer
Review the requirements for provisioning Oracle Exadata Cloud@Customer at
your site.
• Network Requirements for Oracle Exadata Cloud@Customer
Review the network requirements for provisioning Oracle Exadata
Cloud@Customer at your site.
• IP Addresses and Subnets for Exadata Cloud@Customer
You must allocate a range of IP addresses to the administration network, and
another range of IP addresses to the InfiniBand network.
• Uplinks for Exadata Cloud@Customer
Ensure that your Exadata Cloud@Customer system meets control plane server
and compute node uplink requirements.
• Network Cabling for Exadata Cloud@Customer
You can choose to use the supplied network equipment, or you can build your own
SFP network.
• Exadata Cloud@Customer Gen2 Oracle Cloud Infrastructure FastConnect
Oracle Cloud Infrastructure FastConnect enables a private high bandwidth
connection between your on-premises data center and Oracle Cloud Infrastructure
Region.
• Plan Your Configuration Settings on Storage
The proportions that you select for your DATA, RECO, and SPARSE disk groups
profoundly affect your storage space. Review the best options for your enterprise
needs.
• Checklists for Exadata Cloud@Customer Deployments
To determine your readiness for an Exadata Cloud@Customer deployment, review
the deployment checklists.

Site Requirements for Oracle Exadata Cloud@Customer

Review the requirements for provisioning Oracle Exadata Cloud@Customer at your
site.

• Space Requirements for Oracle Exadata Cloud@Customer

Review the space requirements for each Exadata Cloud@Customer X8 rack.
• Weight of Oracle Exadata Cloud X8 Racks
Review and prepare to manage the weight of each Exadata Cloud@Customer X8
rack.

2-1
 Chapter 2
Site Requirements for Oracle Exadata Cloud@Customer

• Receiving, Unpacking, and Access for Oracle Exadata Cloud@Customer Racks

Review and prepare the receiving area that is large enough for the Exadata Rack
package.
• Flooring for Oracle Exadata Cloud@Customer Racks
Ensure that the Exadata Cloud@Customer system is installed on raised flooring
that is capable of supporting the Exadata Rack.
• Electrical Power for Oracle Exadata Cloud@Customer Racks
Exadata Cloud@Customer can operate effectively over a wide range of voltages
and frequencies.
• Temperature and Humidity Ranges for Oracle Exadata Cloud@Customer
Excessive internal temperatures can result in full or partial shutdown of Exadata
Cloud@Customer system components.
• Ventilation for Oracle Exadata Cloud@Customer Racks
Always provide adequate space in front and behind the rack for proper ventilation.

Space Requirements for Oracle Exadata Cloud@Customer

Review the space requirements for each Exadata Cloud@Customer X8 rack.

Table 2-1 Space Requirements for Oracle Exadata

Description Millimeters (mm) Inches (”)

Height 2000 mm 78.74”
Width 600 mm 23.62”
Depth 1237 mm with doors attached, 48.7”
from handle to handle

Weight of Oracle Exadata Cloud X8 Racks

Review and prepare to manage the weight of each Exadata Cloud@Customer X8
rack.

Model (X8) Kilograms (kg) Pounds (lbs)

Base System 435.9 kg 961.1 lbs
Quarter Rack 449.0 kg 989.8 lbs
Half Rack 591.5 kg 1304.1 lbs
Full Rack 883.9 kg 1948.7 lbs

Receiving, Unpacking, and Access for Oracle Exadata

Cloud@Customer Racks
Review and prepare the receiving area that is large enough for the Exadata Rack
package.

Description Millimeters (mm) Inches (”)

Shipping Height 2159 mm 85 inches
Shipping Width 1219 mm 48 inches

2-2
 Chapter 2
Site Requirements for Oracle Exadata Cloud@Customer

Description Millimeters (mm) Inches (”)

Shipping Depth 1575 mm 62 inches

If your loading dock meets the height and ramp requirements for a standard freight
carrier truck, then you can use a pallet jack to unload the rack. If the loading dock does
not meet the requirements, then you must provide a standard forklift, or other means
to unload the rack. You can also request that the rack is shipped in a truck with a lift
gate.
Use a conditioned space to remove the packaging material to reduce particles before
entering the data center. Allow enough space for unpacking it from its shipping
cartons.
Use the information in the following table to ensure that there is a clear pathway
for moving the Exadata Cloud@Customer rack. Also, the entire access route to the
installation site should be free of raised-pattern flooring that can cause vibration.

Access Route Item With Shipping Pallet Without Shipping Pallet

Minimum door height 2184 mm (86 inches) 2040 mm (80.32 inches)
Minimum door width 1270 (50 inches) 640 mm (25.19 inches)
Minimum elevator depth 1625.6 mm (64 inches) 1240 mm (48.82 inches)
Maximum incline 6 degrees 6 degrees
Minimum elevator, pallet jack, 1134 kg (2500 lbs) 1134 kg (2500 lbs)
and floor loading capacity

Flooring for Oracle Exadata Cloud@Customer Racks

Ensure that the Exadata Cloud@Customer system is installed on raised flooring that is
capable of supporting the Exadata Rack.
The site floor and the raised flooring must be able to support the total weight of
the Exadata Cloud@Customer rack that you have selected. Review specifications
accordingly.

Electrical Power for Oracle Exadata Cloud@Customer Racks

Exadata Cloud@Customer can operate effectively over a wide range of voltages and
frequencies.

Reliability of Power Sources

Each rack must have a reliable power source. Damage can occur if the voltage ranges
are exceeded. Electrical disturbances such as the following can damage Exadata
Cloud@Customer:
• Fluctuations caused by brownouts
• Wide and rapid variations in input voltage levels or in input power frequency
• Electrical storms
• Faults in the distribution system, such as defective wiring

2-3
 Chapter 2
Site Requirements for Oracle Exadata Cloud@Customer

To protect Exadata Cloud@Customer from such disturbances, you should have a

dedicated power distribution system, power-conditioning equipment, and lightning
arresters or power cables to protect from electrical storms.

Power Distribution Unit Specifications

Each rack has two pre-installed power distribution units (PDUs). The PDUs accept
different power sources. You must choose the type of PDU that is correct for your data
center and the Exadata Cloud@Customer rack.

Model (X8) Minimum PDU Rating (kVA)

Base System 15 kVA
Quarter Rack 15 kVA
Half Rack 15 kVA
Full Rack 22 kVA

The following list outlines the available PDUs for Exadata Cloud@Customer,
depending on your region. Follow each of the links to access detailed specifications for
each PDU type:
• Americas, Japan, and Taiwan
– Low-Voltage 15 kVA Single-Phase
– Low-Voltage 15 kVA Three-Phase
– Low-Voltage 22 kVA Single-Phase
– Low-Voltage 24 kVA Three-Phase
• Europe, the Middle East and Africa (EMEA), and Asia Pacific (APAC), except for
Japan and Taiwan
– High-Voltage 15 kVA Three-Phase
– High-Voltage 22 kVA Single-Phase
– High-Voltage 24 kVA Three-Phase

Facility Power Requirements

To prevent catastrophic failures, design the input power sources to ensure that
adequate power is provided to the PDUs.
Use dedicated AC breaker panels for all power circuits that supply power to the PDU.
When planning for power distribution requirements, balance the power load between
available AC supply branch circuits. In the United States of America and Canada,
ensure that the overall system AC input current load does not exceed 80 percent of
the branch circuit AC current rating.

2-4
 Chapter 2
Site Requirements for Oracle Exadata Cloud@Customer

Note:
Electrical work and installations must comply with applicable local, state, or
national electrical codes.
PDU power cords are 4 meters (13.12 feet) long, and 1–1.5 meters (3.3–4.9
feet) of the cord is routed within the rack cabinet. The installation site AC
power receptacle must be within 2 meters (6.6 feet) of the rack.

Circuit Breaker Requirements

If computer equipment is subjected to repeated power interruptions and fluctuations,
then it is susceptible to a higher rate of component failure.
You are responsible for supplying the circuit breakers. One circuit breaker is required
for each power cord. In addition to circuit breakers, provide a stable power source,
such as an uninterruptible power supply (UPS) to reduce the possibility of component
failures.
Use dedicated AC breaker panels for all power circuits that supply power to the server.
Servers require grounded electrical circuits.

Note:
Electrical work and installations must comply with applicable local, state, or
national electrical codes.

Electrical Grounding Guidelines

The cabinets for Oracle Exadata Rack are shipped with grounding-type power cords.
• Always connect the cords to grounded power outlets.
• Check the grounding type, because different grounding methods can be used,
depending on your location.
• Refer to documentation such as IEC documents for the correct grounding method.
• Ensure that the facility administrator or qualified electrical engineer verifies the
grounding method for the building, and performs the grounding work.

2-5
 Chapter 2
Site Requirements for Oracle Exadata Cloud@Customer

Temperature and Humidity Ranges for Oracle Exadata

Cloud@Customer
Excessive internal temperatures can result in full or partial shutdown of Exadata
Cloud@Customer system components.

Temperature and Humidity Ranges

Note:
Studies have shown that temperature increases of 10 degrees Celsius (15
degrees Fahrenheit) above 20 degrees Celsius (70 degrees Fahrenheit)
reduce long-term electronics reliability by 50 percent.

Condition Operating Non-operating Optimal

Requirement Requirement Requirement
Temperature 5–32 degrees Celsius -40–70 degrees 21–23 degrees
(59–89.6 degrees Celsius (-40–158 Celsius (70–74
Fahrenheit) degrees Fahrenheit) degrees Fahrenheit)
Relative Humidity 10–90 percent Up to 93 percent 45–50 percent, non-
relative humidity, non- relative humidity condensing
condensing
Altitude 3048 meters (10000 12,000 meters (40000 Maximum ambient
feet) maximum feet) maximum temperature is
reduced by 1 degree
Celsius for every 300
meters of altitude over
900 meters above sea
level.

Temperature and Humidity Guidelines

To minimize the chance of downtime because of component failure, set
conditions to the optimal temperature and humidity ranges. Maintaining an Exadata
Cloud@Customer system for extended periods at or near the operating limits can
significantly increase the potential for hardware component failure.
The ambient temperature range of 21–23 degrees Celsius (70–74 degrees Fahrenheit)
is optimal for server reliability and operator comfort. Most computer equipment
can operate in a wide temperature range, but near 22 degrees Celsius (72
degrees Fahrenheit) is desirable because it is easier to maintain safe humidity
levels. Operating in this temperature range provides a safety buffer in case the air
conditioning system fails for some time.
The ambient relative humidity range of 45–50 percent is suitable for safe data
processing operations. Most computer equipment can operate in a wide range (20–80
percent), but the range of 45–50 percent is recommended for the following reasons:
• The optimal range helps protect computer systems from corrosion problems
associated with high humidity levels..

2-6
 Chapter 2
Network Requirements for Oracle Exadata Cloud@Customer

• The optimal range provides the greatest operating time buffer in case the air
conditioning system fails for some time.
• The optimal range avoids failures or temporary malfunctions caused by
interference from static discharges that can occur when relative humidity is too
low. Electrostatic discharge (ESD) is easily generated, and hard to dissipate in
areas of low relative humidity, such as below 35 percent. ESD becomes critical
when humidity drops below 30 percent

Ventilation for Oracle Exadata Cloud@Customer Racks

Always provide adequate space in front and behind the rack for proper ventilation.
Do not obstruct the front or rear of the rack with equipment or objects that might
prevent air from flowing through the rack. Each Exadata Cloud@Customer rack draws
cool air in through the front of the rack, and discharges warm air out the rear of
the rack. There is no air flow requirement for the left and right sides, because of
front-to-back cooling.
Each Exadata Cloud@Customer rack is designed to function while installed in a
natural convection air flow. To ensure adequate air flow, allow a minimum clearance of
1219.2 mm (48 inches) at the front of the server, and 914 mm (36 inches) at the rear of
the server for ventilation.
Use perforated tiles, approximately 400 CFM/tile, in front of the rack for cold air intake.
The tiles can be arranged in any order in front of the rack, as long as cold air from
the tiles can flow into the rack. Inadequate cold air flow could result in a higher inlet
temperature in the servers because of exhaust air recirculation. The following is the
recommended number of floor tiles:
• Four floor tiles for an Exadata Cloud@Customer Full Rack.
• Three floor tiles for an Exadata Cloud@Customer Half Rack.
• One floor tile for an Exadata Cloud@Customer Quarter Rack or Base System.

Network Requirements for Oracle Exadata

Cloud@Customer
Review the network requirements for provisioning Oracle Exadata Cloud@Customer
at your site.
• Network Requirements for Oracle Exadata Cloud@Customer
To provide secure and reliable network connectivity for different application and
management functions, Exadata Cloud@Customer uses different networks.
• Data Center Network Services for Exadata Cloud@Customer
Before you deploy Exadata Cloud@Customer, ensure that your data center
network meets requirements.

Network Requirements for Oracle Exadata Cloud@Customer

To provide secure and reliable network connectivity for different application and
management functions, Exadata Cloud@Customer uses different networks.

2-7
 Chapter 2
Network Requirements for Oracle Exadata Cloud@Customer

The following list outlines the minimum network requirements to install an Exadata
Cloud@Customer system:
• Exadata Cloud@Customer Service Network: These network will be set up to
Oracle specifications and should not be modified by customer without Oracle
agreement.
– Control Plane Network
This virtual private network (VPN) connects the two control plane servers
that are located in the Exadata Cloud@Customer rack to Oracle Cloud
Infrastructure. The VPN facilitates secure customer-initiated operations
using the Oracle Cloud Infrastructure Console and APIs. It also facilitates
secure monitoring and administration of the Oracle-managed infrastructure
components in Exadata Cloud@Customer.
* Control Plane Connectivity Considerations
In order for the control plane to function, the control plane server must
be able to connect to certain Oracle Cloud Infrastructure (OCI) addresses.
You must enable TCP port 443 outbound access to 5 endpoints in a
specific OCI region as follows:

Table 2-2 Ports to Open for Control Plane Connectivity

Description / Purpose Open Port Location

Outgoing Tunnel Service 443 outbound Use this URL format,
for Cloud Automation replacing oci_region
delivery with your region:

https://
wss.exacc.oci_regi
on.oci.oraclecloud
.com

Secure Tunnel Service for 443 outbound Use these URL formats,
remote Oracle operator replacing oci_region
access with your region:

https://
mgmthe1.exacc.oci_
region.oci.oraclec
loud.com

https://
mgmthe2.exacc.oci_
region.oci.oraclec
loud.com

Object Storage Service to 443 outbound For more information, see

retrieve system updates Object Storage Service
API

2-8
 Chapter 2
Network Requirements for Oracle Exadata Cloud@Customer

Table 2-2 (Cont.) Ports to Open for Control Plane Connectivity

Description / Purpose Open Port Location

Monitoring Service to 443 outbound For more information, see
record and process Monitoring API
Infrastructure Monitoring
Metrics (IMM)
Identity Service for name 443 outbound For more information,
resolution of Oracle see Identity and Access
operators Management Service API
Outgoing Tunnel Service 443 outbound Use this URL format,
for Cloud Automation replacingoci_region
delivery with your region:

https://
wsshe.adbd-
exacc.region.oci.o
raclecloud.com

Note that the Control Plane Server must be able to establish TCP Port
443 outbound access only. While outbound connections on Port 443 must
be allowed, TCP Port 443 inbound access is not required, and it may
be desirable from a security standpoint to block inbound connections.
(Functionally, bi-directional traffic is still possible over the connection once
the secure outbound connection is established.)
The Control Plane Server requires customer DNS and NTP services to be
functional. Minimum bandwidth requirements for the control plane server
internet connection to OCI are 50/10 mbs download/upload.
Some customers have security policies requiring the use of proxies for
all internet connections to IT infrastructure. Customer HTTP proxy, for
example, passive/corporate proxy supported for the Control Plane Server
connection to OCI. Customer HTTPS, challenge proxy, and traffic inspection
are not supported.
– Administration Network
This network connects Exadata Cloud@Customer servers and switches
to the two control plane servers that are located in the Exadata
Cloud@Customer rack. It facilitates customer-initiated operations using the
Oracle Cloud Infrastructure Console and APIs. It also facilitates monitoring
and administration of the Oracle-managed infrastructure components in
Exadata Cloud@Customer.
This network is fully contained within the Exadata Cloud@Customer rack,
and does not connect to your corporate network. However, the Exadata
infrastructure is indirectly connected to your corporate network through
the control plane servers. This connection is required to provide Domain
Name System (DNS) and Network Time Protocol (NTP) services to the
Exadata infrastructure. Therefore, the IP addresses that are allocated to the
administration network must not exist elsewhere in your corporate network.
Each Oracle Database server and Exadata Storage Server has two
network interfaces connected to the administration network. One provides
management access to the server through one of the embedded Ethernet

2-9
 Chapter 2
Network Requirements for Oracle Exadata Cloud@Customer

ports (NET0). The other provides access to the Integrated Lights-Out

Management (ILOM) subsystem through a dedicated ILOM Ethernet port.
Exadata Cloud@Customer is delivered with the ILOM and NET0 ports
connected to the Ethernet switch in the rack. Cabling or configuration changes
to these interfaces are not permitted.
– InfiniBand or RDMA Over Converged Ethernet (ROCE) Network
This network connects the database servers, Exadata Storage Servers, and
control plane servers using the InfiniBand or ROCE switches on the rack.
Each server contains two InfiniBand network interfaces (IB0 and IB1) or
ROCE interface (re0 and re1) that are connected to separate InfiniBand or
ROCE switches in the rack. Primarily, Oracle Database uses this network for
Oracle RAC cluster interconnect traffic, and for accessing data on Exadata
Storage Servers.
This non-routable network is fully contained within the Exadata
Cloud@Customer rack, and does not connect to your corporate network.
However, because the control plane servers are connected to the InfiniBand
or ROCE network and to your corporate network, the IP addresses that are
allocated to the InfiniBand or ROCE network must not exist elsewhere in your
corporate network.
• Customer Network: Customer-owned and managed networks required for the
Exadata Cloud@Customer data plane to access related systems.
– Client Network
This network connects the Exadata Cloud@Customer database servers to
your existing client network and is used for client access to the database
servers. Applications access databases on Exadata Cloud@Customer through
this network using Single Client Access Name (SCAN) and Oracle Real
Application Clusters (Oracle RAC) Virtual IP (VIP) interfaces.
The client access network uses a pair of network interfaces on each database
server, which are connected to the customer network.

Note:
When you enable Data Guard, replication of data happens only over
the client network.

– Backup Network
This network is similar to the client access network, as it connects the Exadata
Cloud@Customer Oracle Database servers to your existing network. It can
be used for access to the database servers for various purposes, including
backups and bulk data transfers.
Like the client network, the backup network uses a pair of network interfaces
on each database server, which are connected to the customer network.
If the customer's on-premises storage (NFS or ZDLRA) is to be used
exclusively as a backup destination for databases, then no external
connectivity is required for the backup network.
Exadata Cloud@Customer also offers an Oracle-managed cloud object
storage backup destination. If Oracle's Object Storage Service is to be
leveraged as a backup destination for database backups, then ensure that
the backup network can reach the Object Storage Service through external

2-10
 Chapter 2
Network Requirements for Oracle Exadata Cloud@Customer

connection. You must enable TCP port 443 outbound access for the backup
network as follows:

Table 2-3 Ports to Open for Backup Network

Description / Purpose Open Port Location

Object Storage Service 443 outbound https://

for cloud-based database objectstorage.region
backups (Optional) .oraclecloud.com

https://
swiftobjectstorage.r
egion.oraclecloud.co
m

Related Topics
• Object Storage Service API
• Monitoring API
• Identity and Access Management Service API

Data Center Network Services for Exadata Cloud@Customer

Before you deploy Exadata Cloud@Customer, ensure that your data center network
meets requirements.

Domain Name System (DNS) Requirements

As part of the deployment process, you must decide on the host names and IP
addresses to be used for various Exadata Cloud@Customer network interfaces.
Oracle requires that you register the host names and IP addresses for the Exadata
Cloud@Customer client and backup network interfaces in your corporate DNS. At
least one reliable DNS server is required, which must be accessible to the control
plane servers and to all of the servers on the client network. Up to three DNS servers
can be registered in Exadata Cloud@Customer to ensure coverage in case a server is
unavailable.

Network Time Protocol (NTP) Services Requirements

Exadata Cloud@Customer uses NTP to ensure that all system components are
synchronized to the same time. At least one reliable NTP server is required, which
must be accessible to the control plane servers and to all of the servers on the client
network. Up to three NTP servers can be registered in Exadata Cloud@Customer to
ensure coverage in case a server is unavailable.

2-11
 Chapter 2
IP Addresses and Subnets for Exadata Cloud@Customer

IP Addresses and Subnets for Exadata Cloud@Customer

You must allocate a range of IP addresses to the administration network, and another
range of IP addresses to the InfiniBand network.

InfiniBand Requirements for Oracle Cloud@Customer

No overlap is permitted between the address ranges for the administration network
and the InfiniBand network, and all IP addresses should be unique within your
corporate network. You must also allocate IP addresses from your corporate network
to the control plane servers. These network configuration details are specified when
you create the Exadata infrastructure.
When you create the Exadata infrastructure, the console pre-populates default values
for the administration network CIDR block and the InifinBand network CIDR block. You
can use the suggested CIDR blocks if there is no overlap with existing IP addresses in
your corporate network.
Review IP address requirements for each of these networks. The table specifies the
maximum and minimum CIDR block prefix length that are allowed for each network.
The maximum CIDR block prefix length defines the smallest block of IP addresses
that are required for the network. To allow for possible future expansion within Exadata
Cloud@Customer, you can choose a smaller CIDR block prefix length, within the
allowable range, which reserves more IP addresses for the network.

Network Type IP Address Requirements

Administration network Maximum CIDR block prefix length:

/23

Minimum CIDR block prefix length:

/16

InifinBand network Maximum CIDR block prefix length:

/22

Minimum CIDR block prefix length:

/19

Control plane network 2 IP addresses, 1 for each control plane server

Host Name and IP Address Requirements for Oracle Cloud@Customer

To connect to your corporate network, Exadata Cloud@Customer requires several
host names and IP addresses for network interfaces on the client network and the
backup network. The precise number of IP addresses depends on the Exadata system
shape. These network configuration details, including host names and IP addresses,
are specified when you create a VM cluster network. All IP addresses must be

2-12
 Chapter 2
Uplinks for Exadata Cloud@Customer

statically assigned IP addresses, not dynamically assigned (DHCP) addresses. The

client network and the backup network require separate subnets.
The following table outlines the IP address requirements for the client and backup
networks. The table specifies the maximum and recommended CIDR block prefix
length for each network. The maximum CIDR block prefix length defines the smallest
block of IP addresses that are required for the network. To allow for possible future
expansion within Exadata Cloud@Customer, a smaller CIDR block prefix length is
recommended, which reserves more IP addresses for the network.

Network Type IP Address Requirements IP Address Requirements

for Base System, Quarter for Full Rack
Rack, or Half Rack
Client network Maximum CIDR block prefix Maximum CIDR block prefix
length: length:

/28 /27

Recommended CIDR block Recommended CIDR block

prefix length: prefix length:

/27 /26

Backup network Maximum CIDR block prefix Maximum CIDR block prefix
length: length:

/29 /28

Recommended CIDR block Recommended CIDR block

prefix length: prefix length:

/28 /27

Uplinks for Exadata Cloud@Customer

Ensure that your Exadata Cloud@Customer system meets control plane server and
compute node uplink requirements.

Control Plane Servers

Four uplinks (2 per server) are required to connect the control plane servers to your
corporate network and the control plane virtual private network (VPN).

Compute Node Connections

Typically, four uplinks are required for each compute node to connect to your corporate
network. Using this configuration, two uplinks support the client network and the other
two uplinks support the backup network.
On Quarter Rack, Half Rack, or Full Rack systems, you can choose to use 10 Gbps
RJ45 copper, 10 Gbps SFP+ fiber, or 25Gbps SFP28 fiber network connections to
your corporate network. However, you cannot mix copper and fiber networks on the

2-13
 Chapter 2
Network Cabling for Exadata Cloud@Customer

same physical server. For example, you cannot use fiber for the client network and
copper for the backup network.
On Base System configurations, the options are more limited because of the physical
network interfaces that are available on each compute node. On Base Systems, you
can choose to use copper or fiber network connections only for the client network,
while the backup network uses a fiber connection.
You can also use shared network interfaces on the Base System for the client
network and the backup network, which reduces the uplink requirement to two uplinks
for each compute node. Using shared network interfaces also enables you to use
copper network connections to support both the client and backup networks on Base
System configurations. However, in general, Oracle recommends that you do not use
shared network interfaces, because sharing networks compromises the bandwidth and
availability of both networks. Shared network interfaces are not supported for Quarter,
Half, and Full Rack configurations.

Network Cabling for Exadata Cloud@Customer

You can choose to use the supplied network equipment, or you can build your own
SFP network.

Supplied Network Equipment Option

Every Exadata Cloud@Customer rack is shipped with all of the network equipment
and cables that are required to interconnect all hardware in the Exadata
Cloud@Customer rack.

Small Form-Factory Pluggable Network Option

Oracle supplies small form-factor pluggable (SFP) network interfaces to enable
connectivity to your corporate network. However, if you choose to configure an SFP
network, then you are responsible to provide the required cabling to connect the
Exadata compute nodes and control plane servers to your corporate network.

Exadata Cloud@Customer Gen2 Oracle Cloud

Infrastructure FastConnect
Oracle Cloud Infrastructure FastConnect enables a private high bandwidth connection
between your on-premises data center and Oracle Cloud Infrastructure Region.
For more information, see Oracle Cloud Infrastructure FastConnect.
Oracle Exadata Cloud@Customer service supports the public peering connectivity
model of FastConnect.

2-14
 Chapter 2
Exadata Cloud@Customer Gen2 Oracle Cloud Infrastructure FastConnect

Figure 2-1 Exadata Cloud@Customer FastConnect connectivity to OCI through

public peering

Customer Data Oracle Cloud

Center Infrastructure Region

ExaC@C Service
Endpoints

Customer CPE
SW/Router Object
Storage

Public Virtual Circuit

FastConnect
Your Oracle
CPS Edge Edge OCI Telemetry
Egress Monitoring

Identity
Service

ExaC@C Customer Internet Facing

NTP Customer DNS Logging
Service

As shown in the figure, the Exadata Cloud@Customer Control Plane network

egresses to FastConnect provider and to Oracle edge. Customers who may
already have existing FastConnect connectivity can use it to connect Exadata
Cloud@Customer to the OCI region using public peering.

Configuring FastConnect for Exadata Cloud@Customer

Note:
You can set up and configure Oracle Cloud Infrastructure FastConnect either
before or after deploying Exadata Cloud@Customer.

For post-Exadata Cloud@Customer deployments, if you want to switch to

FastConnect, then file a MOS SR with the title, "Configure FastConnect for already
deployed Exadata Cloud@Customer service" and Oracle will work you on any
changes to Exadata Cloud@Customer setup.
Exadata Cloud@Customer rack egress network configuration for FastConnect
• As shown in the figure, it is important to set the Exadata Cloud@Customer Control
Plane Server network egress rules to forward traffic over FastConnect, and also
have a route to an internet-facing customer DNS. This "Customer DNS" is used by
Exadata Cloud@Customer infrastructure to resolve OCI public endpoints.

2-15
 Chapter 2
Plan Your Configuration Settings on Storage

• Corporate HTTP proxy between Exadata Cloud@Customer Control Plane Servers

and OCI region is not recommended with FastConnect as it is already a dedicated
network. If a corporate proxy is highly desired, then the proxy needs to have
additional routing to ensure that Exadata Cloud@Customer network traffic is sent
over FastConnect.
Related Topics
• Oracle Cloud Infrastructure FastConnect

Plan Your Configuration Settings on Storage

The proportions that you select for your DATA, RECO, and SPARSE disk groups profoundly
affect your storage space. Review the best options for your enterprise needs.
• About Storage Configuration for Oracle Exadata Cloud@Customer
As part of configuring each Exadata Cloud@Customer VM cluster, the storage
space inside the Exadata Storage Servers is configured for use by Oracle
Automatic Storage Management (ASM).
• Allocation of Storage Space Options on Oracle Exadata Storage Servers
Select the storage option that best meets your planned use case on your Oracle
Exadata Storage Servers.
• Allocation Proportions for DATA, RECO and SPARSE Disk Groups
Determine the storage allocation between the DATA, RECO, and SPARSE disk groups
for Oracle Exadata Storage Servers.

About Storage Configuration for Oracle Exadata Cloud@Customer

As part of configuring each Exadata Cloud@Customer VM cluster, the storage space
inside the Exadata Storage Servers is configured for use by Oracle Automatic Storage
Management (ASM).
By default, the following ASM disk groups are created:
• The DATA disk group is primarily intended for the storage of Oracle Database
data files. Also, a small amount of space is allocated from the DATA disk group
to support the shared file systems that are used to store software binaries (and
patches) and files associated with the cloud-specific tooling. You should not store
your own data, including Oracle Database data files, backups, trace files, and so
on, inside the system-related ACFS file systems.
• The RECO disk group is primarily used for storing the Fast Recovery Area (FRA),
which can be used to provide a local store for files related to backup and recovery.
By default, the FRA is used to store archived redo log files and the backup control
file. If you configure your VM cluster with the option to allocate storage for local
backups, then you can use the FRA as a database backup destination. Finally, if
you enable flashback features on a database, then the FRA is used to store the
flashback logs.
In addition, you can choose to create the SPARSE disk group. The SPARSE disk group is
required to support Exadata snapshot functionality. Exadata snapshots enable space-
efficient clones of Oracle databases that can be created and destroyed very quickly
and easily. Snapshot clones are often used for development, testing, or other purposes
that require a transient database. For more information about Exadata snapshot

2-16
 Chapter 2
Plan Your Configuration Settings on Storage

functionality, see "Setting Up Oracle Exadata Storage Snapshots" in Oracle Exadata

System Software User's Guide.
Related Topics
• Setting Up Oracle Exadata Storage Snapshots

Allocation of Storage Space Options on Oracle Exadata Storage

Servers
Select the storage option that best meets your planned use case on your Oracle
Exadata Storage Servers.
As an input to the virtual machine (VM) cluster creation process, you must choose
options that determine how storage space in the Oracle Exadata Storage Servers is
allocated to the Oracle ASM disk groups. Your choices profoundly affect how storage
space in the Exadata Storage Servers is allocated to the ASM disk groups. Consider
which option best meets your needs:
• Allocate Storage for Exadata Snapshots
If you select this option, then the SPARSE disk group is created, and less space
is allocated to the DATA and RECO disk groups. If you do not select this option,
then the SPARSE disk group is not created, and you cannot use Exadata snapshot
functionality.
• Allocate Storage for Local Backups
If you select this option, then more space is allocated to the RECO disk group to
accommodate local backups to Oracle Exadata storage. If you do not select this
option, then more space is allocated to the DATA disk group, but you cannot use
local Oracle Exadata storage as a backup destination for any databases in the VM
cluster.

Allocation Proportions for DATA, RECO and SPARSE Disk Groups

Determine the storage allocation between the DATA, RECO, and SPARSE disk groups for
Oracle Exadata Storage Servers.

Exadata Storage Server Configuration Allocation With No Exadata Snapshot

Storage or Local Backup
When you select Allocate Storage for Exadata Snapshots: No and Enable
Backups on Local Exadata Storage: No, then storage allocation is as follows:
• DATA Disk Group: 80%
• RECO Disk Group: 20%
• SPARSE Disk Group 0% (The SPARSE disk group is not created.)

Exadata Storage Server Configuration Allocation With No Exadata Snapshot

Storage and Local Backup Enabled
When you select Allocate Storage for Exadata Snapshots: No and Enable
Backups on Local Exadata Storage: Yes, so that backups are enabled on local
storage, then storage allocation is as follows:

2-17
 Chapter 2
Checklists for Exadata Cloud@Customer Deployments

• DATA Disk Group: 40%

• RECO Disk Group: 60%
• SPARSE Disk Group 0% (The SPARSE disk group is not created.)

Exadata Storage Server Configuration Allocation With Exadata Snapshot

Storage and No Local Backup
When you select Allocate Storage for Exadata Snapshots: Yes and Enable
Backups on Local Exadata Storage: No, so that storage is allocated for Exadata
snapshots, then storage allocation is as follows:
• DATA Disk Group: 60%
• RECO Disk Group: 20%
• SPARSE Disk Group 20%

Exadata Storage Server Configuration Allocation With Both Exadata Snapshot

Storage and Local Backup Enabled
When you select Allocate Storage for Exadata Snapshots: Yes and Enable
Backups on Local Exadata Storage: Yes, so that storage is allocated for Exadata
snapshots, and storage is allocated for local backups, then storage allocation is as
follows:
• DATA Disk Group: 35%
• RECO Disk Group: 50%
• SPARSE Disk Group 15%

Checklists for Exadata Cloud@Customer Deployments

To determine your readiness for an Exadata Cloud@Customer deployment, review the
deployment checklists.

• System Components Checklist for Exadata Cloud@Customer

Use this checklist to ensure that the system component considerations are
addressed.
• Data Center Room Checklist for Exadata Cloud@Customer
Use this checklist to ensure that the data center room requirements are
addressed.
• Data Center Environment Checklist for Oracle Exadata Cloud@Customer
Use this checklist to ensure that the data center environment requirements are
addressed.
• Access Route Checklist for Oracle Exadata Cloud@Customer
Use this checklist to ensure that the access route requirements are addressed.
• Facility Power Checklist for Oracle Exadata Cloud@Customer
Use this checklist to ensure that the facility power requirements are addressed.
• Safety Checklist for Oracle Exadata Cloud@Customer
Use this checklist to ensure that safety requirements are addressed.
• Logistics Checklist for Exadata Cloud@Customer
Use this checklist to ensure that the logistics requirements are addressed.

2-18
 Chapter 2
Checklists for Exadata Cloud@Customer Deployments

• Network Configuration Checklist for Oracle Exadata Cloud@Customer

Use this checklist to ensure that the network configuration requirements are
addressed.
• Reracking Checklist for Oracle Exadata Cloud@Customer
Use this checklist to determine your readiness for reracking.

System Components Checklist for Exadata Cloud@Customer

Use this checklist to ensure that the system component considerations are addressed.
• How many racks do you plan to install?
• Will additional equipment be attached to or installed in the rack?
If additional equipment is attached, then ensure that the additional equipment
meets Oracle guidelines, and there is sufficient power and cooling.

Data Center Room Checklist for Exadata Cloud@Customer

Use this checklist to ensure that the data center room requirements are addressed.
Answer yes, no, not applicable, or add your comments. Or let the site survey team fill
in the requested information.
• Has the rack location been allocated and is it vacant?
• Does the floor layout meet the equipment maintenance access requirements?
• Will the rack be positioned so that the exhaust air of one rack does not enter the
air inlet of another rack?
• Have cabinet stabilization measures been considered?
• If the data center has a raised floor:
– Does the raised floor satisfy the weight requirements for the rack?
– Is permission required to remove floor tiles for cabling and servicing below the
floor?
• Will the rack location require any non-standard cable lengths?
• Is the floor-to-ceiling height a minimum of 2914 mm (114.72 inches)?
• Is the depth of the raised floor a minimum of 46 cm (18 inches)?

Data Center Environment Checklist for Oracle Exadata

Cloud@Customer
Use this checklist to ensure that the data center environment requirements are
addressed.
Answer yes, no, not applicable, or add your comments. Or, let the site survey team fill
in the requested information.
• Does the computer room air conditioning meet temperature and humidity
requirements?
• Does the installation floor layout satisfy the ventilation requirements?
• If the room cooling is from a raised floor:

2-19
 Chapter 2
Checklists for Exadata Cloud@Customer Deployments

– Are the perforated floor tiles each rated at 400 CFM or greater?
– Can additional perforated floor tiles be obtained if required for additional
cooling?
• Does the data center air conditioning provide sufficient front-to-back airflow?
• Is airflow adequate to prevent hot spots?
• Can the data center continuously satisfy the environmental requirements?

Access Route Checklist for Oracle Exadata Cloud@Customer

Use this checklist to ensure that the access route requirements are addressed.
Answer yes, no, not applicable, or add your comments. Or, let the site survey team fill
in the requested information.
• Has the access route been checked for clearance of the rack, including the
minimum width and height requirements for all doors on the route?
• Are there any stairs, ramps, or thresholds that are of concern?
If yes, then provide details.
• Are all access route incline angles within the permitted range (under 6 degrees)?
• Are all the surfaces acceptable for rolling the new unpacked and packed
equipment?
• If a pallet jack is to be used:
– Can the pallet jack support the weight of the rack?
– Are the pallet jack tines compatible with the shipping pallet?
• If there are stairs, is a loading elevator available for the equipment?
• If an elevator is to be used:
– Does the elevator car meet the height, width, and depth requirements for
carrying the rack?
– Do the elevator doors meet the height and width requirements for moving the
rack?
– Does the elevator meet the weight requirements for transporting the rack?
• Can the complete access route support the weight of the rack?
• Is the access route onto the raised floor rated for dynamic loading of the rack?

Facility Power Checklist for Oracle Exadata Cloud@Customer

Use this checklist to ensure that the facility power requirements are addressed.
Answer yes, no, not applicable, or add your comments. Or, let the site survey team fill
in the requested information.
• Have the operating voltage and electric current requirements been reviewed?
• What type of power supply will be used?
– Single-phase or 3-phase.
– Low-voltage or High-voltage.

2-20
 Chapter 2
Checklists for Exadata Cloud@Customer Deployments

• Are enough power outlets provided within 2 meters for each rack?
• Do the power outlets have appropriate socket receptacles for the planned Power
Distribution Units (PDUs)?
• Will optional ground cables be attached to the rack?
• Are the electrical circuits suitable in terms of voltage and current-carrying
capacities?
• Does the power frequency meet the equipment specifications?
• Are power outlets available for the new equipment at the designated location?
• Will system power be delivered from two separate grids?
• Is there a UPS to power the equipment?
• Are the minimum required power sources available to support the power load (kW
or kVA) for the new hardware?

Safety Checklist for Oracle Exadata Cloud@Customer

Use this checklist to ensure that safety requirements are addressed.
Answer yes, no, not applicable, or add your comments. Or, let the site survey team fill
in the requested information.
• Is there an emergency power shut off?
• Is there a fire protection system in the data center room?
• Is the computer room adequately equipped to extinguish a fire?
• Is antistatic flooring installed?
• Is the area below the raised floor free of obstacles and blockages?

Logistics Checklist for Exadata Cloud@Customer

Use this checklist to ensure that the logistics requirements are addressed.
Answer yes, no, not applicable, or add your comments. Or, let the site survey team fill
in the requested information.
• Is contact information for the data center personnel available?
• Is there security or access control for the data center?
• Are there any security background checks or security clearances required for
Oracle personnel to access the data center?
If yes, then provide the process for Oracle to follow.
• How many days in advance must background checks be completed?
• Are there any additional security access issues?
• Is computer room access available for installation personnel?
• Are laptops allowed in the data center?
• Are cell phones allowed in the data center?
• Are cameras allowed in the data center?
• Does the building have a delivery dock?

2-21
 Chapter 2
Checklists for Exadata Cloud@Customer Deployments

• Is there a delivery / unpacking / staging area?

• Is inside delivery planned (direct to the final rack location in the data center room)?
• If the delivery is not inside, then is the site prepared for uncrating?
• Is the delivery / unpacking / staging area protected from the elements?
• Does the building have adequate receiving space?
• Is the unpacking area air-conditioned to avoid thermal shock for various hardware
components?
• Will sufficient moving personnel be available to transport the rack?
• Is union labor required for any part of the delivery or installation?
• Is the site prepared for uncrating and packaging removal?
Package removal should take place outside the data center room.
• Is uncrating of cabinet and packaging removal required?
• Are there any restrictions on delivery truck length, width, or height?
• Is there storage space (cabinet) for the ride along spares?
If not, does the customer allow cardboard boxes and other packing material in the
computer room, since the spares are packed in cardboard boxes?
• Is there a time constraint on dock access?
If yes, provide time constraints.
• Is a tail or side lift required on the delivery carrier to unload the equipment at the
delivery dock?
• Will any special equipment be required to place the rack in the data center room?
For example:
– Stair walkers
– Lifters
– Ramps
– Steel plates
– Floor covers
• Does the delivery carrier require any special equipment, such as non-floor
damaging rollers, transport dollies, pallet jacks, or fork lifts?

Network Configuration Checklist for Oracle Exadata Cloud@Customer

Use this checklist to ensure that the network configuration requirements are
addressed.
Answer yes, no, not applicable, or add your comments. Or, let the site survey team fill
in the requested information.
• Will the required network cables be laid from the network equipment to the location
where the Oracle Exadata Rack will be installed?
• Will the network cables that will connect to the Oracle Exadata Rack be labeled?
• Will the 10 GbE or 25 GbE interfaces be used for the client access network?
If so, has the customer ordered the appropriate cables to their switch?
• Will the Cisco Ethernet switch have IP routing disabled (recommended)?

2-22
 Chapter 2
Checklists for Exadata Cloud@Customer Deployments

Reracking Checklist for Oracle Exadata Cloud@Customer

Use this checklist to determine your readiness for reracking.
Use this checklist to ensure that the reracking requirements are addressed.

Note:

• Reracking requires prior approval. The checklist below provides high

level guidance on re-racking requirements. Oracle maintains a detailed
internal checklist that must be approved prior to performing reracking.
• You must purchase the Oracle Reracking service.
• Oracle does not provide technical support for customer-supplied
equipment.

Answer yes, no, not applicable, or add your comments. Or, let the site survey team to
fill in the requested information.
• Have you purchased the Oracle Reracking Service?
• Is there a cart capable of carrying the weight of the servers to move the
components and associated cabling from the supplied rack to the rack that you
supply?
• Is the target rack empty?
• Attach pictures of the target rack (inside and outside).
• Does the target rack meet the following requirements?
– Height: 42 RU
– Width: 600 mm (23.62 inches)
– Depth: 1112 mm (43.78 inches) without front and rear doors
If the rack is less than 42 RU tall, then the rack must be at least 30 RU tall, and
you must provide compatible PDUs to install in the target rack.
• Is the distance between the front and rear mounting planes between the minimum
of 610 mm and the maximum 915 mm (24–36 inches)?
• Is the clearance depth in the front of the front mounting plane (distance to the front
cabinet door) at least 25.4 mm (1 inch)?
• Does the target rack meet the following minimum load capacity?
– 19 kg (41.89 lb) per RU
– 785 kg (1730.63 lb) total
• Is the rack a four-post rack (mounting at both front and rear)?

2-23
 Chapter 2
Checklists for Exadata Cloud@Customer Deployments

Note:
Two-post racks are not compatible.

• Does the target rack's horizontal opening and unit vertical pitch conform to
ANSI/EIA 310-D-1992 or IEC 60297 standards?
• Does the target rack have RETMA rail support?

Note:
Oracle Exadata rack requires 19 inches (483 mm) for RETMA rail
spacing width. The minimum rack width of 600 mm (23.63 inches) is
recommended to accommodate the PDU and cable harnesses on the
side. If the rack is less than 600 mm wide, then it must have additional
depth to accommodate mounting behind the server cable management
arms.

• Does the target rack support Oracle cable management arms?

• Does the target rack support installation of Oracle vented and solid filler panels?
• Can the target rack provide tie-downs along the left rear side of the rack (as
viewed from the front of the rack) to support the lnfiniBand cables?
• Can the target rack provide tie-downs for the Ethernet wiring harness?
• Is there sufficient space for the cable harnesses and the PDUs in the target rack?
• Can a label with the Oracle Exadata Rack serial number be printed and attached
to the target rack?
• Does the target rack support installation of standard Oracle PDUs?
If not, then complete the following checklist items:
– Can you provide provide an equivalent pair of PDUs?
– Can you provide provide two PDUs, each with a capacity of 10 kVA?
– Can you provide provide at least 17 x lOA C13 plugs per PDU?
– Can you provide a single PDU and its circuits to support the Oracle Exadata
Rack power requirements in case one PDU fails?
– Can you ensure that power loads are evenly distributed across all circuits of a
single PDU?
– Can you provide appropriate power drops for the PDUs?

2-24
3
Provisioning Exadata Cloud@Customer
Systems
Learn how to provision an Exadata Cloud@Customer system.

• About Provisioning Oracle Exadata Cloud@Customer Systems

To provision an Oracle Exadata Cloud@Customer system, you must work with
Oracle to set up and configure the system.
• Required IAM Policy for Provisioning Servers
Review the identity access management (IAM) policy for provisioning Oracle
Exadata Cloud@Customer systems.
• Prerequisites for Provisioning Oracle Exadata Cloud@Customer Servers
Before you provision your X8M-2, X8-2, and X7-2 servers, you must set up
tenancy, and your network and other infrastructure must meet requirements.
• Using the Console to Provision Oracle Exadata Cloud@Customer
Learn how to use the console to create your infrastructure, and to edit, download
a configuration file, activate, and check the status of your infrastructure for Oracle
Exadata Cloud@Customer.
• Oracle Exadata Cloud@Customer Deployment Assistant
Oracle Exadata Cloud@Customer Deployment Assistant is an automated
installation and configuration tool that enables you to set up your Oracle Exadata
Cloud@Customer machine and create an Oracle Database instance with minimal
effort.
• Using the API to Manage Exadata Cloud@Customer Infrastructure
Oracle Exadata Cloud@Customer uses the same API as Oracle Cloud
Infrastructure.

About Provisioning Oracle Exadata Cloud@Customer

Systems
To provision an Oracle Exadata Cloud@Customer system, you must work with Oracle
to set up and configure the system.
Provisioning an Oracle Exadata Cloud@Customer system is a collaborative process.
The process is performed in the following sequence:
1. You create the Oracle Exadata Cloud@Customer infrastructure.
2. You generate a file containing the infrastructure configuration details, and provide
it to Oracle.
3. The Oracle Exadata Cloud@Customer system is physically installed in your data
center.
4. Oracle uses the infrastructure configuration file to perform initial system
configuration. At the end of this task, Oracle supplies you with an activation file.

3-1
 Chapter 3
Required IAM Policy for Provisioning Servers

5. You activate the Exadata Cloud@Customer infrastructure by using the supplied

activation file.
When the provisioning process is complete, the Oracle Exadata Cloud@Customer
system is ready for you to use. You can then create a virtual machine (VM) cluster, and
later create some databases.

Caution:

Avoid entering confidential information when assigning descriptions, tags, or friendly

names to your cloud resources through the Oracle Cloud Infrastructure Console, the
APIs, or the command-line interface.

Required IAM Policy for Provisioning Servers

Review the identity access management (IAM) policy for provisioning Oracle Exadata
Cloud@Customer systems.
A policy is an IAM document that specifies who has what type of access to your
resources. It is used in different ways:
• An individual statement written in the policy language
• A collection of statements in a single, named "policy" document, which has an
Oracle Cloud ID (OCID) assigned to it
• The overall body of policies your organization uses to control access to resources
A compartment is a collection of related resources that can be accessed only
by certain groups that have been given permission by an administrator in your
organization.
To use Oracle Cloud Infrastructure, you must be given the required type of access in
a policy written by an administrator, whether you're using the Console, or the REST
API with a software development kit (SDK), a command-line interface (CLI), or some
other tool. If you try to perform an action, and receive a message that you don’t
have permission, or are unauthorized, then confirm with your administrator the type of
access you've been granted, and which compartment you should work in.
For administrators: The policy in "Let database admins manage DB systems" lets the
specified group do everything with databases, and related database resources.
If you're new to policies, then see "Getting Started with Policies" and "Common
Policies". If you want to dig deeper into writing policies for databases, then see "Details
for the Database Service".
Related Topics
• Let database admins manage DB systems
• Getting Started with Policies
• Common Policies
• Details for the Database Service

3-2
 Chapter 3
Prerequisites for Provisioning Oracle Exadata Cloud@Customer Servers

Prerequisites for Provisioning Oracle Exadata

Cloud@Customer Servers
Before you provision your X8M-2, X8-2, and X7-2 servers, you must set up tenancy,
and your network and other infrastructure must meet requirements.
• Before you can provision Exadata Cloud@Customer infrastructure, your
Oracle Cloud Infrastructure tenancy must be enabled to use Oracle Exadata
Cloud@Customer. Review the information in this publication, and contact Oracle
for further details.
• In preparation for the provisioning process, ensure that your corporate data center
and network infrastructure meet the requirements described in this publication.

Using the Console to Provision Oracle Exadata

Cloud@Customer
Learn how to use the console to create your infrastructure, and to edit, download
a configuration file, activate, and check the status of your infrastructure for Oracle
Exadata Cloud@Customer.

• Using the Console to Create Infrastructure

To create your Oracle Exadata Cloud@Customer infrastructure, be prepared to
provide values for the fields required for configuring the infrastructure.
• Using the Console to Edit Oracle Exadata Cloud@Customer Infrastructure
To edit your Oracle Exadata Cloud@Customer infrastructure, be prepared to
provide values for the infrastructure configuration.
• Using the Console to Download a File Containing Configuration Data
To download an Oracle Exadata Cloud@Customer configuration file, complete this
procedure.
• Using the Console to Activate Exadata Cloud@Customer Infrastructure
To activate Oracle Exadata Cloud@Customer infrastructure, ensure that you meet
the prerequisites, and complete this procedure.
• Using the Console to Check the Status of Exadata Cloud@Customer
Infrastructure
To find the status of your Oracle Exadata Cloud@Customer infrastructure, use this
procedure to check the Infrastructure Details page.
• Using the Console to Move Exadata Cloud@Customer Infrastructure
To relocate Oracle Exadata Cloud@Customer infrastructure to another
compartment, use this procedure.
• Using the Console to Delete Exadata Cloud@Customer Infrastructure
To delete Oracle Exadata Cloud@Customer infrastructure, complete the
prerequisites, and then complete this procedure.
• Using the Console to Manage Tags for Your Exadata Cloud@Customer Resources
• Managing Infrastructure Maintenance Contacts
Learn to manage your Exadata infrastructure maintenance contacts.

3-3
 Chapter 3
Using the Console to Provision Oracle Exadata Cloud@Customer

Using the Console to Create Infrastructure

To create your Oracle Exadata Cloud@Customer infrastructure, be prepared to
provide values for the fields required for configuring the infrastructure.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Under Region, select the region that you want to associate with the Oracle
Exadata infrastructure.
The region that is associated with your Oracle Exadata infrastructure cannot be
changed after the Oracle Exadata infrastructure is created. Therefore, ensure
that you select the most appropriate region for your infrastructure. Consider the
following factors:
• Consider any business policies or regulations that preclude the use of a
particular region. For example, you can be required to maintain all operations
within national boundaries.
• Consider the physical proximity of the region to your data center.
Needless extra physical separation adds unnecessary latency to network
communications between Oracle Cloud Infrastructure and your corporate data
center.
3. Click Exadata Infrastructure.
4. Click Create Exadata Infrastructure.
5. In the Create Exadata Infrastructure page, provide the requested information:
• Oracle Cloud Infrastructure region: The region that is associated with your
Oracle Exadata infrastructure cannot be changed after the Oracle Exadata
infrastructure is created. Therefore, check the displayed region to ensure that
you are using the most appropriate region for your infrastructure.
See step 2 (earlier in this procedure) for further considerations. To switch
regions now, use the Region menu at the top of the console.
• Choose a compartment: From the list of available compartments, choose the
compartment that you want to contain the Oracle Exadata infrastructure.
See also Understanding Compartments.
• Provide the display name: The display name is a user-friendly name that
you can use to identify the Exadata infrastructure. The name doesn't need to
be unique, because an Oracle Cloud Identifier (OCID) uniquely identifies the
Oracle Exadata infrastructure.
• Select the Exadata system model: From the list, choose the model of the
Oracle Exadata hardware that is being used.
The Oracle Exadata system model and system shape combine to define the
amount of CPU, memory, and storage resources that are available in the
Exadata infrastructure. For more details, see "System Configuration".
• Select an Exadata system shape: Together with the Oracle Exadata system
model, the Oracle Exadata system shape defines the amount of CPU,
memory, and storage resources that are available in the Oracle Exadata
infrastructure.

3-4
 Chapter 3
Using the Console to Provision Oracle Exadata Cloud@Customer

– Base System: includes two compute nodes and three Oracle Exadata
Storage Servers. A Base System is an entry-level configuration.
Compared to other configurations, a Base System contains Oracle
Exadata Storage Servers with significantly less storage capacity, and
compute nodes with significantly less memory and processing power.
– Quarter Rack: includes two compute nodes and three Oracle Exadata
Storage Servers.
– Half Rack: includes four compute nodes and six Oracle Exadata Storage
Servers.
– Full Rack: includes eight compute nodes and 12 Oracle Exadata Storage
Servers.
• Configure the cloud control plane network
Each Oracle Exadata Cloud@Customer system contains two control plane
servers, which enable connectivity to Oracle Cloud Infrastructure. The control
plane servers are connected to the control plane network, which is a subnet on
your corporate network. The following settings define the network parameters:
– Control Plane Server 1 IP Address: Provide the IP address for the first
control plane server. This IP address is for the network interface that
connects the first control plane server to your corporate network using the
control plane network.
– Control Plane Server 2 IP Address: Provide the IP address for the
second control plane server. This IP is address for the network interface
that connects the second control plane server to your corporate network
using the control plane network.
– Netmask: Specify the IP netmask for the control plane network.
– Gateway: Specify the IP address of the control plane network gateway.
– HTTP Proxy: (Optional) You can choose to use this field to specify your
corporate HTTP proxy. The expected format is as follows, where server
is the server name, domain is the domain name, and port is the assigned
port:

http://server.domain:port

For example:

http://proxy.example.com:80

For enhanced security, when possible, Oracle recommends that you use
an HTTP proxy.
• Configure the Oracle Exadata system networks
Each Oracle Exadata Cloud@Customer system contains two system
networks, which are not connected to your corporate network. The following
settings define IP address allocations for these networks:
– Administration Network CIDR Block: Specifies the IP address range
for the administration network using CIDR notation. The administration
network provides connectivity that enables Oracle to administer the
Exadata system components, such as the Exadata compute servers,

3-5
 Chapter 3
Using the Console to Provision Oracle Exadata Cloud@Customer

storage servers, network switches, and power distribution units. You can
accept the suggested default, or specify a custom value.
The maximum CIDR block prefix length is /23, which defines the smallest
block of IP addresses that are required for the network. To allow for
possible future expansion within Exadata Cloud@Customer, a smaller
CIDR block prefix length is recommended, which reserves more IP
addresses for the network. The minimum CIDR block prefix length is /16.
Ensure that the IP address range does not conflict with other hosts your
corporate network, and does not overlap with the InfiniBand network CIDR
block.
• InfiniBand Network CIDR Block: Specifies the IP address range for the
Exadata InfiniBand network using CIDR notation. The Exadata InfiniBand
network provides the high-speed low-latency interconnect used by Exadata
software for internal communications between various system components.
You can accept the suggested default, or specify a custom value.
The maximum CIDR block prefix length is /22, which defines the smallest
block of IP addresses that are required for the network. To allow for possible
future expansion within Exadata Cloud@Customer, a smaller CIDR block
prefix length is recommended, which reserves more IP addresses for the
network. The minimum CIDR block prefix length is /19.
Ensure that the IP address range does not conflict with other hosts your
corporate network, and does not overlap with the administration network CIDR
block.
• Configure DNS and NTP services
Each Exadata Cloud@Customer system requires access to Domain Names
System (DNS) and Network Time Protocol (NTP) services. The following
settings specify the servers that provide these services to the Exadata
infrastructure:
– DNS Servers: Provide the IP address of a DNS server that is accessible
using the control plane network. You may specify up to three DNS servers.
– NTP Servers: Provide the IP address of an NTP server that is accessible
using the control plane network. You may specify up to three NTP servers.
– Time Zone: The default time zone for the Exadata Infrastructure is UTC,
but you can specify a different time zone. The time zone options are those
supported in both the Java.util.TimeZone class and the Oracle Linux
operating system.

Note:
If you want to set a time zone other than UTC or the browser-
detected time zone, then select the Select another time
zone option, select a Region or country, and then select the
corresponding Time zone.
If you do not see the region or country you want, then select
Miscellaneous, and then select an appropriate Time zone.

• Provide maintenance details

3-6
 Chapter 3
Using the Console to Provision Oracle Exadata Cloud@Customer

– Configure automatic maintenance

Click Modify Maintenance.
In the Edit Automatic Maintenance dialog that opens, configure
automatic maintenance schedule.
No preference: The system assigns a date and start time for
infrastructure maintenance.
Specify a schedule: Choose your preferred month, week, weekday, start
time, and lead time for infrastructure maintenance.
Lead Time: Specify the minimum number of weeks ahead of the
maintenance event you would like to receive a notification message.
– Provide maintenance contacts
Maintenance contacts are required for service request based
communications for hardware replacement and other maintenance events.
You can skip adding maintenance contacts while creating your
infrastructure. However, you must add a primary contact prior to activating
your infrastructure. Ensure that you provide the details of the contact
that you used while registering the Customer Support Identifier (CSI)
associated with this infrastructure, as a primary contact.
Optionally, you can add a maximum of nine secondary contacts. Both the
primary and secondary contacts receive all notifications about hardware
replacement, network issues, and software maintenance runs. Note that
you can promote any secondary contacts as the primary anytime you
want. When you promote a secondary contact to primary, the current
primary contact will be demoted automatically to secondary.
• Show Advanced Options
You have the option to configure advanced options.
– Tags: (Optional) You can choose to apply tags. If you have permissions to
create a resource, then you also have permissions to apply free-form tags
to that resource. To apply a defined tag, you must have permissions to use
the tag namespace. For more information about tagging, see "Resource
Tags". If you are not sure if you should apply tags, then skip this option
(you can apply tags later) or ask your administrator.
6. Click Create Exadata Infrastructure.
If all of your inputs are valid, then the Infrastructure Details page appears. The
page outlines the next steps in the provisioning process. Initially after creation, the
state of the Oracle Exadata infrastructure is Requires-Activation.
Related Topics
• Understanding Compartments
• System Configuration Options for Oracle Exadata Cloud@Customer
• Resource Tags

3-7
 Chapter 3
Using the Console to Provision Oracle Exadata Cloud@Customer

Using the Console to Edit Oracle Exadata Cloud@Customer

Infrastructure
To edit your Oracle Exadata Cloud@Customer infrastructure, be prepared to provide
values for the infrastructure configuration.
You can only edit Oracle Exadata Cloud@Customer infrastructure networking if the
current state of the Oracle Exadata infrastructure is Requires Activation. Also,
ensure that you do not edit the Exadata infrastructure after you download the
configuration file and provide it to Oracle.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Select Region and Compartment, and provide the region and the compartment
where the Oracle Exadata infrastructure you want to edit is located.
3. Click Exadata Infrastructure.
4. Click the name of the Exadata infrastructure that you want to edit.
The Infrastructure Details page displays information about the selected Oracle
Exadata infrastructure.
5. Click Edit Infrastructure Networking.
6. Use the Edit Infrastructure Networking dialog to edit the Oracle Exadata
infrastructure networking:
a. Configure the cloud control plane network
Each Oracle Exadata Cloud@Customer system contains two control plane
servers, which enable connectivity to Oracle Cloud Infrastructure. The control
plane servers are connected to the control plane network, which is a subnet on
your corporate network. The following settings define the network parameters:
• Control Plane Server 1 IP Address: Provide the IP address for the first
control plane server. This IP address is for the network interface that
connects the first control plane server to your corporate network using the
control plane network.
• Control Plane Server 2 IP Address: Provide the IP address for the
second control plane server. This IP address is for the network interface
that connects the second control plane server to your corporate network
using the control plane network.
• Netmask: Specify the IP netmask for the control plane network.
• Gateway: Specify the IP address of the control plane network gateway.
• HTTP Proxy: (Optional) You can use this field to specify your corporate
HTTP proxy. The expected format is as follows, where server is the
server name, domain is the domain name, and port is the assigned port:

http://server.domain:port

For example:

http://proxy.example.com:80

3-8
 Chapter 3
Using the Console to Provision Oracle Exadata Cloud@Customer

For enhanced security, when possible, Oracle recommends that you use
an HTTP proxy.
b. Configure the Exadata system networks
Each Oracle Exadata Cloud@Customer system contains two system
networks, which are not connected to your corporate network. The following
settings define IP address allocations for these networks:
• Administration Network CIDR Block: Specifies the IP address range
for the administration network using CIDR notation. The administration
network provides connectivity that enables Oracle to administer the
Exadata system components, such as the Exadata compute servers,
storage servers, network switches, and power distribution units.
The maximum CIDR block prefix length is /23, which defines the smallest
block of IP addresses that are required for the network. To allow for
possible future expansion within Oracle Exadata Cloud@Customer, a
smaller CIDR block prefix length is recommended, which reserves more IP
addresses for the network. The minimum CIDR block prefix length is /16.
Ensure that the IP address range does not conflict with other hosts your
corporate network, and does not overlap with the InfiniBand network CIDR
block.
• InfiniBand Network CIDR Block: Specifies the IP address range for
the Exadata InfiniBand network using CIDR notation. The Exadata
InfiniBand network provides the high-speed low-latency interconnect used
by Exadata software for internal communications between various system
components.
The maximum CIDR block prefix length is /22, which defines the smallest
block of IP addresses that are required for the network. To allow for
possible future expansion within Oracle Exadata Cloud@Customer, a
smaller CIDR block prefix length is recommended, which reserves more IP
addresses for the network. The minimum CIDR block prefix length is /19.
Ensure that the IP address range does not conflict with other hosts your
corporate network, and does not overlap with the administration network
CIDR block.
c. Configure DNS and NTP services
Each Oracle Exadata Cloud@Customer system requires access to Domain
Names System (DNS) and Network Time Protocol (NTP) services. The
following settings specify the servers that provide these services to the
Exadata infrastructure:
• DNS Servers: Provide the IP address of a DNS server that is accessible
using the control plane network. You can specify up to three DNS servers.
• NTP Servers: Provide the IP address of an NTP server that is accessible
using the control plane network. You may specify up to three NTP servers.
• Time zone: The default time zone for the Exadata Infrastructure is UTC,
but you can specify a different time zone. The time zone options are those
supported in both the Java.util.TimeZone class and the Oracle Linux
operating system.

3-9
 Chapter 3
Using the Console to Provision Oracle Exadata Cloud@Customer

Note:
If you want to set a time zone other than UTC or the browser-
detected time zone, then select the Select another time
zone option, select a Region or country, and then select the
corresponding Time zone.
If you do not see the region or country you want, then select
Miscellaneous, and then select an appropriate Time zone.

7. Click Save Changes.

Using the Console to Download a File Containing Configuration Data

To download an Oracle Exadata Cloud@Customer configuration file, complete this
procedure.
You can download the configuration file only if the current state of the Oracle Exadata
infrastructure is Requires Activation.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that contains the Oracle Exadata
infrastructure for which you want to download a file containing the infrastructure
configuration details.
3. Click Exadata Infrastructure.
4. Click the name of the Oracle Exadata infrastructure for which you want to
download a file containing the infrastructure configuration details.
The Infrastructure Details page displays information about the selected Oracle
Exadata infrastructure.
5. Click Download Configuration.
Your browser downloads a file containing the infrastructure configuration details.
When you provide the generated infrastructure configuration file to Oracle, ensure that
it has not been altered in any way. Also, ensure that you do not edit the Oracle
Exadata infrastructure after you download the configuration file and provide it to
Oracle.

Using the Console to Activate Exadata Cloud@Customer

Infrastructure
To activate Oracle Exadata Cloud@Customer infrastructure, ensure that you meet the
prerequisites, and complete this procedure.
• Ensure that you have added a primary contact. You cannot activate your
infrastructure without adding a primary maintenance contact.
• Locate the activation file. This file is supplied to you by Oracle after installation and
initial configuration of your Oracle Exadata Cloud@Customer system.
• Ensure that your infrastructure current state is Requires Activation. You can only
activate Oracle Exadata if its state is Requires Activation.

3-10
 Chapter 3
Using the Console to Provision Oracle Exadata Cloud@Customer

1. Download the activation file.

2. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
3. Choose Region and Compartment, and select the region and compartment that
contains the Oracle Exadata infrastructure that you want to activate.
4. Click Exadata Infrastructure.
5. Click the name of the Oracle Exadata infrastructure that you want to activate.
The Infrastructure Details page displays information about the selected Oracle
Exadata infrastructure.
6. Click Activate.
The Activate button is only available if the Oracle Exadata infrastructure requires
activation. You cannot activate Oracle Exadata infrastructure multiple times.
7. Use the Activate dialog to upload the activation file, and then click Activate Now.
After activation, the state of the Oracle Exadata infrastructure changes to Active.

Using the Console to Check the Status of Exadata Cloud@Customer

Infrastructure
To find the status of your Oracle Exadata Cloud@Customer infrastructure, use this
procedure to check the Infrastructure Details page.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that contains the Oracle Exadata
infrastructure that you are interested in.
3. Click Exadata Infrastructure.
4. Click the name of the Oracle Exadata infrastructure that you are interested in.
The Infrastructure Details page displays information about the selected Oracle
Exadata infrastructure.
5. Check the icon on the Infrastructure Details page. The color of the icon and the
text below it indicates the status of the Oracle Exadata infrastructure.
• Creating: Yellow icon. The Oracle Exadata infrastructure definition is being
created in the control plane.
• Requires Activation: Yellow icon. The Oracle Exadata infrastructure is
defined in the control plane, but it must be provisioned and activated before it
can be used.
• Active: Green icon. The Oracle Exadata infrastructure is successfully
provisioned and activated.
• Deleting: Gray icon. The Oracle Exadata infrastructure is being deleted by
using the Console or API.
• Deleted: Gray icon. The Oracle Exadata infrastructure is deleted, and is no
longer available. This state is transitory. It is displayed for a short time, after
which the Oracle Exadata infrastructure is no longer displayed.

3-11
 Chapter 3
Using the Console to Provision Oracle Exadata Cloud@Customer

• Activation Failed: Red icon. An error condition currently prevents the

activation of the Oracle Exadata infrastructure. Typically, this state is auto-
correcting, and does not require user intervention.

Using the Console to Move Exadata Cloud@Customer Infrastructure

To relocate Oracle Exadata Cloud@Customer infrastructure to another compartment,
use this procedure.
You can change the compartment that contains your Exadata Cloud@Customer
infrastructure by moving it.
When you move Exadata infrastructure, the compartment change is also applied to the
associated VM cluster networks. However, the compartment change does not affect
any other associated resources, such as the VM clusters, which remain in their current
compartment.
To move Oracle Exadata Cloud@Customer infrastructure:
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Select Region and Compartment, and provide the region and compartment that
contains the Oracle Exadata infrastructure that you want to move.
3. Click Exadata Infrastructure.
4. Click the name of the Exadata infrastructure that you want to move.
The Infrastructure Details page displays information about the selected Oracle
Exadata infrastructure.
5. Click Move Resource.
6. In the resulting dialog, choose the new compartment for the Oracle Exadata
infrastructure, and click Move Resource.

Using the Console to Delete Exadata Cloud@Customer Infrastructure

To delete Oracle Exadata Cloud@Customer infrastructure, complete the prerequisites,
and then complete this procedure.
Deleting Exadata Cloud@Customer infrastructure removes it from the Cloud Control
Plane.
If you are deleting Oracle Exadata infrastructure before activation, then if required, you
can create replacement Oracle Exadata infrastructure without any input from Oracle.
In you are deleting active Oracle Exadata infrastructure, then to create replacement
Oracle Exadata infrastructure, you must repeat the full provisioning process, including
the tasks that Oracle performs.
Before you can delete active Exadata infrastructure, you must:
• Terminate all of the resources that it contains, including the databases, VM cluster,
and VM cluster network.
• Lodge a service request (SR) with Oracle indicating your intention to delete the
Oracle Exadata infrastructure. In response to the SR, Oracle flags the Oracle
Exadata infrastructure as ready for deletion.

3-12
 Chapter 3
Using the Console to Provision Oracle Exadata Cloud@Customer

After Oracle has flagged the Oracle Exadata infrastructure, delete the Exadata
infrastructure by using the following process:
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Select Region and Compartment, and provide the region and compartment that
contains the Oracle Exadata infrastructure that you want to delete.
3. Click Exadata Infrastructure.
4. Click the name of the Oracle Exadata infrastructure that you want to delete.
The Infrastructure Details page displays information about the selected Oracle
Exadata infrastructure.
5. Click Delete.
6. In the resulting dialog, enter the Oracle Exadata infrastructure name and click
Delete Exadata Infrastructure to confirm the action.

Using the Console to Manage Tags for Your Exadata

Cloud@Customer Resources
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose your Compartment.
3. Find the Exadata Infrastructure, VM Cluster Network, VM Cluster, Backup
Destination, Database Home, or Database resource you're interested in, and click
the name.
4. Click the Tags tab to view or edit the existing tags. Or, click More Actions and
then Apply Tags to add new ones.
Related Topics
• Resource Tags

Managing Infrastructure Maintenance Contacts

Learn to manage your Exadata infrastructure maintenance contacts.
• View Primary Maintenance Contact
You must associate primary contact with the Customer Support Identifier (CSI).
• Add Secondary Contacts
You can add up to nine secondary contacts.
• Edit Maintenance Contacts
Edit maintenance contacts to update details.
• Promote a Secondary Contact to Primary
You can promote a secondary contact to primary. The current primary is
automatically demoted to secondary.
• Remove a Secondary Contact
You can remove a secondary contact anytime you want to.

3-13
 Chapter 3
Using the Console to Provision Oracle Exadata Cloud@Customer

View Primary Maintenance Contact

You must associate primary contact with the Customer Support Identifier (CSI).
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Select Region and Compartment, and provide the region and compartment that
contains the Oracle Exadata infrastructure for which you want to view contact
details.
3. Click Exadata Infrastructure.
4. Click the name of the Oracle Exadata infrastructure for which you want to view
contact details.
The Infrastructure Details page displays information about the selected Oracle
Exadata infrastructure.
5. Find the CSI and the primary contact under Maintenance.
The operations team sets the infrastructure maintenance Service Level Objective
(SLO) to Degraded:
• If the primary contact CSI verification has failed.
• If the primary contact is missing.
• If the primary contact is verified and unresponsive.
Also, a warning message is displayed on the Console as follows:
"Ensure that the primary contact associated with your Customer Support
Identifier (CSI) is available for Oracle support to coordinate maintenance-
related activities.
The infrastructure maintenance Service Level Objective (SLO) is set to
degraded status without proper primary contact."

Add a primary contact before you activate the infrastructure.

Add Secondary Contacts

You can add up to nine secondary contacts.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Select Region and Compartment, and provide the region and compartment that
contains the Oracle Exadata infrastructure for which you want to add secondary
contacts.
3. Click Exadata Infrastructure.
4. Click the name of the Oracle Exadata infrastructure for which you want to add
secondary contacts.
The Infrastructure Details page displays information about the selected Oracle
Exadata infrastructure.
5. Click Manage Contacts.
6. In the Manage Exadata Infrastructure Contacts window, click Add Contact.
7. In the Add Contacts window, add contact details.
8. Click Add Contacts.

3-14
 Chapter 3
Using the Console to Provision Oracle Exadata Cloud@Customer

Edit Maintenance Contacts

Edit maintenance contacts to update details.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Select Region and Compartment, and provide the region and compartment that
contains the Oracle Exadata infrastructure for which you want to edit maintenance
contact details.
3. Click Exadata Infrastructure.
4. Click the name of the Oracle Exadata infrastructure for which you want to edit
maintenance contact details.
The Infrastructure Details page displays information about the selected Oracle
Exadata infrastructure.
5. Click Manage Contacts.
6. In the Manage Exadata Infrastructure Contacts window, click the actions button,
and then select Edit Contact.
7. In the Edit Contacts window, edit the details.
8. Click Save.

Promote a Secondary Contact to Primary

You can promote a secondary contact to primary. The current primary is automatically
demoted to secondary.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Select Region and Compartment, and provide the region and compartment
that contains the Oracle Exadata infrastructure for which you want to promote
a secondary contact to primary.
3. Click Exadata Infrastructure.
4. Click the name of the Oracle Exadata infrastructure for which you want to promote
a secondary contact to primary.
The Infrastructure Details page displays information about the selected Oracle
Exadata infrastructure.
5. Click Manage Contacts.
6. In the Manage Exadata Infrastructure Contacts window, click the actions button,
and then select Make Primary.
7. In the Promote to Primary Contact dialog, click Promote.

Remove a Secondary Contact

You can remove a secondary contact anytime you want to.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.

3-15
 Chapter 3
Oracle Exadata Cloud@Customer Deployment Assistant

2. Select Region and Compartment, and provide the region and compartment
that contains the Oracle Exadata infrastructure for which you want to remove a
secondary contact.
3. Click Exadata Infrastructure.
4. Click the name of the Oracle Exadata infrastructure for which you want to remove
a secondary contact.
The Infrastructure Details page displays information about the selected Oracle
Exadata infrastructure.
5. Click Manage Contacts.
6. In the Manage Exadata Infrastructure Contacts window, click the actions button,
and then select Remove.
7. In the Remove Infrastructure Contact dialog, click Remove.

Oracle Exadata Cloud@Customer Deployment Assistant

Oracle Exadata Cloud@Customer Deployment Assistant is an automated installation
and configuration tool that enables you to set up your Oracle Exadata
Cloud@Customer machine and create an Oracle Database instance with minimal
effort.
• Using Oracle Exadata Cloud@Customer Deployment Assistant
Oracle Exadata Cloud@Customer Deployment Assistant gathers your
configuration details and creates the Oracle Exadata Cloud@Customer
infrastructure configuration file. The configuration file drives the automated
installation and configuration processes for Oracle Exadata Cloud@Customer
infrastructure.
• Accessing Oracle Exadata Cloud@Customer Deployment Assistant
Follow these steps to run the Deployment Assistant.
• Step 1: Pre-Installation
Create Exadata Cloud@Customer infrastructure, VM cluster network, and
download the infrastructure configuration file before your engineered system
arrives at your premises.
• Step 2: Onsite Installation
Ensure that you activate the Exadata Cloud@Customer infrastructure and validate
the VM cluster network.
• Step 3: Post-Installation
Create a VM cluster, install Oracle Database, and validate your installation before
performing any administrative tasks.

Using Oracle Exadata Cloud@Customer Deployment Assistant

Oracle Exadata Cloud@Customer Deployment Assistant gathers your configuration
details and creates the Oracle Exadata Cloud@Customer infrastructure configuration
file. The configuration file drives the automated installation and configuration
processes for Oracle Exadata Cloud@Customer infrastructure.
Before your engineered system arrives, do the following:
• Work with your network and database administrators to evaluate the current
network settings, such as current IP address use and network configuration.

3-16
 Chapter 3
Oracle Exadata Cloud@Customer Deployment Assistant

• Define the settings for the rack, such as network configuration and backup
method.
• Download the Oracle Exadata Cloud@Customer infrastructure configuration file.
During deployment, if you find any discrepancies at any stage, then click Close and
complete later to exit Oracle Exadata Cloud@Customer Deployment Assistant. You
will lose all of your settings and you will have to start afresh the next time.

Accessing Oracle Exadata Cloud@Customer Deployment Assistant

Follow these steps to run the Deployment Assistant.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Exadata Infrastructure.
3. Click Deployment Assistant.
4. Choose a deployment type.
• New Deployment: Creates an Exadata Cloud@Customer infrastructure and
all the resources needed to create your first Oracle Database.
Select a Compartment, and then click Continue.
• Existing Deployment: Uses an existing Exadata Cloud@Customer
infrastructure and guides you through completing the deployment.
a. Select a Compartment.
b. Select an Exadata Cloud@Customer infrastructure.
c. Select a VM Cluster Network or create one.
d. Click Continue.
5. If you have created an Exadata Cloud@Customer infrastructure and if it is in
Active state, then do the following:
a. Go the Exadata Cloud@Customer infrastructure details page.
b. Click Deployment Assistant.
6. If you have created an Exadata Cloud@Customer infrastructure and if it is in
Requires Activation state, then do the following:
a. Go the Exadata Cloud@Customer infrastructure details page.
b. Click More Actions and then select Deployment Assistant.

Step 1: Pre-Installation
Create Exadata Cloud@Customer infrastructure, VM cluster network, and download
the infrastructure configuration file before your engineered system arrives at your
premises.
1. Create Oracle Exadata Cloud@Customer infrastructure.
For more information and instructions, see Using the Console to Create
Infrastructure.
2. Create VM cluster network.

3-17
 Chapter 3
Using the API to Manage Exadata Cloud@Customer Infrastructure

For more information and instructions, see Using the Console to Create a VM
Cluster Network.
3. Download the Oracle Exadata Cloud@Customer configuration file.
For more information and instructions, see Using the Console to Download a File
Containing Configuration Data.

Step 2: Onsite Installation

Ensure that you activate the Exadata Cloud@Customer infrastructure and validate the
VM cluster network.
1. Add Infrastructure Contacts.
Maintenance contacts are required for service request based communications for
hardware replacement and other maintenance events.
You must add a primary contact to activate your infrastructure. Ensure that you
provide the details of the contact that you used while registering the Customer
Support Identifier (CSI) associated with this infrastructure, as a primary contact.
For more information and instructions, see Managing Infrastructure Maintenance
Contacts
2. Activate Oracle Exadata Cloud@Customer infrastructure.
For more information and instructions, see Using the Console to Activate Exadata
Cloud@Customer Infrastructure.
3. Validate the VM cluster network.
You can only validate a VM cluster network if its current state is Requires
Validation and if the underlying Exadata infrastructure is activated.
For more information and instructions, see Using the Console to Validate a VM
Cluster Network.

Step 3: Post-Installation
Create a VM cluster, install Oracle Database, and validate your installation before
performing any administrative tasks.
1. Create VM cluster.
For more information and instructions, see Using the Console to Create a VM
Cluster.
2. Create Oracle Database.
For more information and instructions, see Using the Console to Create a
Database.

Using the API to Manage Exadata Cloud@Customer

Infrastructure
Oracle Exadata Cloud@Customer uses the same API as Oracle Cloud Infrastructure.

3-18
 Chapter 3
Using the API to Manage Exadata Cloud@Customer Infrastructure

For information about using the API and signing requests, see "REST APIs" and
"Security Credentials". For information about SDKs, see "Software Development Kits
and Command Line Interface".
Use these API operations to manage Exadata Cloud@Customer infrastructure:
• ActivateExadataInfrastructure
• CreateExadataInfrastructure
• DeleteExadataInfrastructure
• DownloadExadataInfrastructureConfigFile
• GenerateRecommendedVmClusterNetwork
• GetExadataInfrastructure
• ListExadataInfrastructure
• UpdateExadataInfrastructure

Related Topics
• REST APIs
• Security Credentials
• Software Development Kits and Command Line Interface
• ActivateExadataInfrastructure
• CreateExadataInfrastructure
• DeleteExadataInfrastructure
• DownloadExadataInfrastructureConfigFile
• GenerateRecommendedVmClusterNetwork
• GetExadataInfrastructure
• ListExadataInfrastructure
• UpdateExadataInfrastructure

3-19
4
Managing VM Clusters on Exadata
Cloud@Customer
Learn to manage virtual machine (VM) clusters on Exadata Cloud@Customer.
• About Managing VM Clusters on Exadata Cloud@Customer
The VM cluster provides a link between your Exadata Cloud@Customer
infrastructure and Oracle Database.
• Required IAM Policy for Managing VM Clusters
Review the identity access management (IAM) policy for managing virtual machine
(VM) clusters on Oracle Exadata Cloud@Customer Systems.
• Prerequisites for VM Clusters on Exadata Cloud@Customer
To connect to the VM cluster compute node, you use an SSH public key.
• Using the Console for VM Clusters on Exadata Cloud@Customer
Learn how to use the console to create, edit, download a configuration
file, validate, and terminate your infrastructure network, and manage your
infrastructure for Oracle Exadata Cloud@Customer.
• Using the API to Manage Exadata Cloud@Customer VM Clusters
Review the list of API calls to manage your Exadata Cloud@Customer VM cluster
networks and VM clusters.
• Introduction to Scale Up or Scale Down Operations
With the Multiple VMs per Exadata system (MultiVM) feature release, you can
scale up or scale down your VM cluster resources.

About Managing VM Clusters on Exadata Cloud@Customer

The VM cluster provides a link between your Exadata Cloud@Customer infrastructure
and Oracle Database.
Before you can create any databases on your Exadata Cloud@Customer
infrastructure, you must create a VM cluster network, and you must associate it with
a VM cluster. Each Exadata Cloud@Customer infrastructure deployment can support
four VM cluster networks and associated VM clusters.
The VM cluster network specifies network resources, such as IP addresses and
host names, that reside in your corporate data center and are allocated to Exadata
Cloud@Customer. The VM cluster network includes definitions for the Exadata client
network and the Exadata backup network. The client network and backup network
contain the network interfaces that you use to connect to the VM cluster compute
nodes, and ultimately the databases that reside on those compute nodes.
The VM cluster provides a link between your Exadata Cloud@Customer infrastructure
Oracle Databases you deploy. The VM cluster contains an installation of Oracle
Clusterware, which supports databases in the cluster. In the VM cluster definition, you
also specify the number of enabled CPU cores, which determines the amount of CPU
resources that are available to your databases.

4-1
 Chapter 4
Required IAM Policy for Managing VM Clusters

Note:
Avoid entering confidential information when assigning descriptions, tags,
or friendly names to your cloud resources through the Oracle Cloud
Infrastructure Console, API, or CLI.

Required IAM Policy for Managing VM Clusters

Review the identity access management (IAM) policy for managing virtual machine
(VM) clusters on Oracle Exadata Cloud@Customer Systems.
A policy is an IAM document that specifies who has what type of access to your
resources. It is used in different ways:
• An individual statement written in the policy language
• A collection of statements in a single, named "policy" document, which has an
Oracle Cloud ID (OCID) assigned to it
• The overall body of policies your organization uses to control access to resources
A compartment is a collection of related resources that can be accessed only
by certain groups that have been given permission by an administrator in your
organization.
To use Oracle Cloud Infrastructure, you must be given the required type of access in
a policy written by an administrator, whether you're using the Console, or the REST
API with a software development kit (SDK), a command-line interface (CLI), or some
other tool. If you try to perform an action, and receive a message that you don’t
have permission, or are unauthorized, then confirm with your administrator the type of
access you've been granted, and which compartment you should work in.
For administrators: The policy in "Let database admins manage DB systems" lets the
specified group do everything with databases, and related database resources.
If you're new to policies, then see "Getting Started with Policies" and "Common
Policies". If you want to dig deeper into writing policies for databases, then see "Details
for the Database Service".
Related Topics
• Let database admins manage DB systems
• Getting Started with Policies
• Common Policies
• Details for the Database Service

Prerequisites for VM Clusters on Exadata Cloud@Customer

To connect to the VM cluster compute node, you use an SSH public key.

4-2
 Chapter 4
Using the Console for VM Clusters on Exadata Cloud@Customer

The public key is in OpenSSH format, from the key pair that you plan to use for
connecting to the VM cluster compute nodes through SSH. The following shows an
example of a public key, which is abbreviated for readability.

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAA....lo/gKMLVM2xzc1xJr/
Hc26biw3TXWGEakrK1OQ== rsa-key-20160304

Related Topics
• Managing Key Pairs on Linux Instances

Using the Console for VM Clusters on Exadata

Cloud@Customer
Learn how to use the console to create, edit, download a configuration file, validate,
and terminate your infrastructure network, and manage your infrastructure for Oracle
Exadata Cloud@Customer.
• Using the Console to Create a VM Cluster Network
To create your VM cluster network with the Console, be prepared to provide values
for the fields required for configuring the infrastructure.
• Using the Console to Edit a VM Cluster Network
You can only edit a VM cluster network that is not associated with a VM cluster.
• Using the Console to Download a File Containing the VM Cluster Network
Configuration Details
To provide VM cluster network information to your network administrator, you can
download and supply a file containing the network configuration.
• Using the Console to Validate a VM Cluster Network
You can only validate a VM cluster network if its current state is Requires
Validation, and if the underlying Exadata infrastructure is activated.
• Using the Console to Terminate a VM Cluster Network
Before you can terminate a VM cluster network, you must first terminate the
associated VM cluster, if one exists, and all the databases it contains.
• Using the Console to Create a VM Cluster
To create your VM cluster, be prepared to provide values for the fields required for
configuring the infrastructure.
• Using the Console to Add SSH Keys After Creating a VM Cluster
• Using the Console to Scale the Resources on a VM Cluster
Starting in Exadata Cloud@Customer Gen2, you can scale up or down multiple
resources at the same time. You can also scale up or down resources one at a
time.
• Using the Console to Stop, Start, or Reboot a VM Cluster Compute Node
Use the console or API calls to stop, start, or reboot a compute node.
• Using the Console to Check the Status of a VM Cluster Compute Node
Review the health status of a VM cluster compute node.
• Using the Console to Update the License Type on a VM Cluster
To modify licensing, be prepared to provide values for the fields required for
modifying the licensing information.

4-3
 Chapter 4
Using the Console for VM Clusters on Exadata Cloud@Customer

• Using the Console to Move a VM Cluster to Another Compartment

To change the compartment that contains your VM cluster on Exadata
Cloud@Customer, use this procedure.
• Using the Console to Terminate a VM cluster
Before you can terminate a VM cluster, you must first terminate the databases that
it contains.

Using the Console to Create a VM Cluster Network

To create your VM cluster network with the Console, be prepared to provide values for
the fields required for configuring the infrastructure.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that contains the Exadata infrastructure
for which you want to create a VM cluster network.
3. Click Exadata Infrastructure.
4. Click the name of the Exadata infrastructure for which you want to create a VM
cluster network.
The Infrastructure Details page displays information about the selected Exadata
infrastructure.
5. Click Create VM Cluster Network.
6. Provide the requested information in the Data Center Network Details page:
a. Provide the display name.
The display name is a user-friendly name that you can use to identify the
VM cluster network. The name doesn't need to be unique because an Oracle
Cloud Identifier (OCID) uniquely identifies the VM cluster network.
b. Provide client network details.
The client network is the primary channel for application connectivity to
Exadata Cloud@Customer resources. The following settings define the
required network parameters:
• VLAN ID: Provide a virtual LAN identifier (VLAN ID) for the client network
between 1 and 4094, inclusive. To specify no VLAN tagging, enter "1".
(This is equivalent to a "NULL" VLAN ID tag value.)

Note:
The values "0" and "4095" are reserved and cannot be entered.

• CIDR Block: Using CIDR notation, provide the IP address range for the
client network.
The following table specifies the maximum and recommended CIDR block
prefix lengths for each Exadata system shape. The maximum CIDR block
prefix length defines the smallest block of IP addresses that are required
for the network. To allow for possible future expansion within Exadata
Cloud@Customer, a smaller CIDR block prefix length is recommended,
which reserves more IP addresses for the network.

4-4
 Chapter 4
Using the Console for VM Clusters on Exadata Cloud@Customer

Exadata System Shape Base System, Quarter Full Rack

Rack, or Half Rack
Maximum CIDR block /28 /27
prefix length
Recommended CIDR /27 /26
block prefix length

• Netmask: Specify the IP netmask for the client network.

• Gateway: Specify the IP address of the client network gateway.
• Hostname Prefix: Specify the prefix that is used to generate the
hostnames in the client network.
• Domain Name: Specify the domain name for the client network.
c. Provide backup network details.
The backup network is the secondary channel for connectivity to Exadata
Cloud@Customer resources. It is typically used to segregate application
connections on the client network from other network traffic. The following
settings define the required network parameters:
• VLAN ID: Provide a virtual LAN identifier (VLAN ID) for the backup
network between 1 and 4094, inclusive. To specify no VLAN tagging, enter
"1". (This is equivalent to a "NULL" VLAN ID tag value.)

Note:
The values "0" and "4095" are reserved, and cannot be entered.

• CIDR Block: Using CIDR notation, provide the IP address range for the
backup network.
The following table specifies the maximum and recommended CIDR block
prefix lengths for each Exadata system shape. The maximum CIDR block
prefix length defines the smallest block of IP addresses that are required
for the network. To allow for possible future expansion within Exadata
Cloud@Customer, a smaller CIDR block prefix length is recommended,
which reserves more IP addresses for the network.

Exadata System Shape Base System, Quarter Full Rack

Rack, or Half Rack
Maximum CIDR block /29 /28
prefix length
Recommended CIDR /28 /27
block prefix length

• Netmask: Specify the IP netmask for the backup network.

• Gateway: Specify the IP address of the backup network gateway.
• Hostname Prefix: Specify the prefix that is used to generate the
hostnames in the backup network.
• Domain Name: Specify the domain name for the backup network.
d. Provide DNS and NTP server details.

4-5
 Chapter 4
Using the Console for VM Clusters on Exadata Cloud@Customer

The VM cluster network requires access to Domain Names System (DNS)

and Network Time Protocol (NTP) services. The following settings specify the
servers that provide these services:
• DNS Servers: Provide the IP address of a DNS server that is accessible
using the client network. You may specify up to three DNS servers.
• NTP Servers: Provide the IP address of an NTP server that is accessible
using the client network. You may specify up to three NTP servers.
e. Configure Advanced Options.
Tags: (Optional) You can choose to apply tags. If you have permissions to
create a resource, then you also have permissions to apply free-form tags to
that resource. To apply a defined tag, you must have permissions to use the
tag namespace. For more information about tagging, refer to information about
resource tags. If you are not sure if you should apply tags, then skip this option
(you can apply tags later) or ask your administrator.
7. Click Review Configuration.
The Review Configuration page displays detailed information about the VM cluster
network, including the hostname and IP address allocations. These allocations are
initially system-generated, and are based on your inputs to the Specify Parameters
page.
8. (Optional) You can choose to adjust the system-generated network definitions on
the Review Configuration page.
a. Click Edit IP Allocation.
b. Use the Edit dialog to adjust the system-generated network definitions to meet
your requirements.
c. Click Save Changes.
9. Click Create VM Cluster Network.
The VM Cluster Network Details page is now displayed. Initially after creation, the
state of the VM cluster network is Requires Validation.
Related Topics
• Resource Tags

Using the Console to Edit a VM Cluster Network

You can only edit a VM cluster network that is not associated with a VM cluster.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that contains the Exadata infrastructure
that is associated with the VM cluster network that you want to edit.
3. Click Exadata Infrastructure.
4. Click the name of the Exadata infrastructure that is associated with the VM cluster
network that you are interested in.
The Infrastructure Details page displays information about the selected Exadata
infrastructure.
5. Click the name of the VM cluster network that you want to edit.

4-6
 Chapter 4
Using the Console for VM Clusters on Exadata Cloud@Customer

The VM Cluster Network Details page displays information about the selected VM
cluster network.
6. Click Edit VM Cluster Network.
7. Use the Edit dialog to edit the VM cluster network attributes:
a. Client Network
The client network is the primary channel for application connectivity to
Exadata Cloud@Customer resources. You can edit the following client
network settings:
• VLAN ID: Provide a virtual LAN identifier (VLAN ID) for the client network
between 1 and 4094, inclusive. To specify no VLAN tagging, enter "1".
(This is equivalent to a "NULL" VLAN ID tag value.)

Note:
The values "0" and "4095" are reserved and cannot be entered.

• Netmask: Specify the IP netmask for the client network.

• Gateway: Specify the IP address of the client network gateway.
• Hostname: Specify the hostname for each address in the client network.
• IP Address: Specify the IP address for each address in the client network.
b. Backup Network
The backup network is the secondary channel for connectivity to Exadata
Cloud@Customer resources. It is typically used to segregate application
connections on the client network from other network traffic. You can edit the
following backup network settings:
• VLAN ID: Provide a virtual LAN identifier (VLAN ID) for the backup
network between 1 and 4094, inclusive. To specify no VLAN tagging, enter
"1". (This is equivalent to a "NULL" VLAN ID tag value.)

Note:
The values "0" and "4095" are reserved and cannot be entered.

• Hostname: Specify the hostname for each address in the backup

network.
• IP Address: Specify the IP address for each address in the backup
network.
c. Configure DNS and NTP Servers
The VM cluster network requires access to Domain Names System (DNS) and
Network Time Protocol (NTP) services. You can edit the following settings:
• DNS Servers: Provide the IP address of a DNS server that is accessible
using the client network. You may specify up to three DNS servers.
• NTP Servers: Provide the IP address of an NTP server that is accessible
using the client network. You may specify up to three NTP servers.

4-7
 Chapter 4
Using the Console for VM Clusters on Exadata Cloud@Customer

8. Click Save Changes.

After editing, the state of the VM cluster network is Requires Validation.

Using the Console to Download a File Containing the VM Cluster

Network Configuration Details
To provide VM cluster network information to your network administrator, you can
download and supply a file containing the network configuration.
Use this procedure to download a configuration file that you can supply to
your network administrator. The file contains the information needed to configure
your corporate DNS and other network devices to work along with Exadata
Cloud@Customer.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that contains the Exadata infrastructure
that is associated with the VM cluster network that you are interested in.
3. Click Exadata Infrastructure.
4. Click the name of the Exadata infrastructure that is associated with the VM cluster
network that you are interested in.
The Infrastructure Details page displays information about the selected Exadata
infrastructure.
5. Click the name of the VM cluster network for which you want to download a file
containing the VM cluster network configuration details.
The VM Cluster Network Details page displays information about the selected VM
cluster network.
6. Click Download Network Configuration.
Your browser downloads a file containing the VM cluster network configuration
details.

Using the Console to Validate a VM Cluster Network

You can only validate a VM cluster network if its current state is Requires Validation,
and if the underlying Exadata infrastructure is activated.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that contains the Exadata infrastructure
that is associated with the VM cluster network that you want to validate.
3. Click Exadata Infrastructure.
4. Click the name of the Exadata infrastructure that is associated with the VM cluster
network that you are interested in.
The Infrastructure Details page displays information about the selected Exadata
infrastructure.
5. Click the name of the VM cluster network that you want to validate.

4-8
 Chapter 4
Using the Console for VM Clusters on Exadata Cloud@Customer

The VM Cluster Network Details page displays information about the selected VM
cluster network.
6. Click Validate VM Cluster Network.
Validation performs a series of automated checks on the VM cluster network. The
Validate VM Cluster Network button is only available if the VM cluster network
requires validation.
7. In the resulting dialog, click Validate to confirm the action.
After successful validation, the state of the VM cluster network changes to
Validated and the VM cluster network is ready to use. If validation fails for
any reason, examine the error message and resolve the issue before repeating
validation.

Using the Console to Terminate a VM Cluster Network

Before you can terminate a VM cluster network, you must first terminate the
associated VM cluster, if one exists, and all the databases it contains.
Terminating a VM cluster network removes it from the Cloud Control Plane.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that contains the Exadata infrastructure
that is associated with the VM cluster network that you want to terminate.
3. Click Exadata Infrastructure.
4. Click the name of the Exadata infrastructure that is associated with the VM cluster
network that you are interested in.
The Infrastructure Details page displays information about the selected Exadata
infrastructure.
5. Click the name of the VM cluster network that you want to terminate.
The VM Cluster Network Details page displays information about the selected VM
cluster network.
6. Click Terminate.
7. In the resulting dialog, enter the name of the VM cluster network, and click
Terminate VM Cluster Network to confirm the action.

Using the Console to Create a VM Cluster

To create your VM cluster, be prepared to provide values for the fields required for
configuring the infrastructure.
To create a VM cluster, ensure that you that have:
• Active Exadata infrastructure available to host the VM cluster.
• A validated VM cluster network available for the VM cluster to use.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region that contains your Exadata infrastructure.

4-9
 Chapter 4
Using the Console for VM Clusters on Exadata Cloud@Customer

3. Click VM Clusters.
4. Click Create VM Cluster.
5. Provide the requested information in the Create VM Cluster page:
a. Choose a compartment: From the list of available compartments, choose the
compartment that you want to contain the VM cluster.
b. Provide the display name: The display name is a user-friendly name that
you can use to identify the VM cluster. The name doesn't need to be unique
because an Oracle Cloud Identifier (OCID) uniquely identifies the VM cluster.
c. Select Exadata Cloud@Customer Infrastructure: From the list, choose the
Exadata infrastructure to host the VM cluster. You are not able to create a VM
cluster without available and active Exadata infrastructure.
d. Select a VM Cluster Network: From the list, choose a VM cluster network
definition to use for the VM cluster. You must have an available and validated
VM cluster network before you can create a VM cluster.
e. Choose the Oracle Grid Infrastructure version:From the list, choose the of
Oracle Grid Infrastructure release that you want to install on the VM cluster.
The Oracle Grid Infrastructure release determines the Oracle Database
releases that can be supported on the VM cluster. You cannot run an Oracle
Database release that is later than the Oracle Grid Infrastructure software
release.
f. Specify the OCPU count per VM: Specify the OCPU count for each
individual VM. The minimum value is 2 OCPUs per VM (for a live VM
condition), unless you are specifying zero OCPUs (for a shut down VM
condition).
If you specify a value of zero, then the VM cluster compute nodes are all
shut down at the end of the cluster creation process. In this case, you can
later start the compute nodes by scaling the OCPU resources. See Using the
Console to Scale the Resources on a VM Cluster.
The value for OCPU count for the whole VM Cluster will be calculated
automatically based upon the per VM OCPU count you have specified and
the number of physical Database Servers configured for the system. There is
one VM created on each physical Database Server available.
OCPU: An Oracle Compute Unit (OCPU) provides CPU capacity equivalent of
one physical core of an Intel Xeon processor with hyper threading enabled.
Each OCPU corresponds to two hardware execution threads, known as
vCPUs.
See, Oracle Platform as a Service and Infrastructure as a Service – Public
Cloud Service DescriptionsMetered & Non-Metered.
g. Requested OCPU count for the VM Cluster: Displays the total number of
CPU cores allocated to the VM cluster based on the value you specified in the
Specify the OCPU count per VM field.
h. Specify the memory per VM (GB): Specify the memory for each individual
VM. The value must be a multiple of 1 GB and is limited by the available
memory on the Exadata infrastructure.
i. Requested memory for the VM Cluster (GB): Displays the total amount of
memory allocated to the VM cluster based on the value you specified in the
Specify the memory per VM (GB) field.

4-10
 Chapter 4
Using the Console for VM Clusters on Exadata Cloud@Customer

j. Specify the local file system size per VM (GB): Specify the size for each
individual VM. The value must be a multiple of 1 GB and is limited by the
available size of the file system on the X8-2 and X7-2 infrastructures.
Note that the minimum size of local system storage must be 60 GB. Each
time when you create a new VM cluster, the space remaining out of the total
available space is utilized for the new VM cluster.
For more information and instructions to specify the size for each individual
VM, see Introduction to Scale Up or Scale Down Operations.
k. Reserved local storage per VM (GB): Displays the size reserved internally
for root file systems, Oracle Grid Infrastructure Homes, and diagnostic logs.
l. Configure the Exadata Storage: The following settings define how the
Exadata storage is configured for use with the VM cluster. These settings
cannot be changed after creating the VM cluster. See also Storage
Configuration.
• Specify Usable Exadata Storage: Specify the size for each individual
VM. The minimum recommended size is 2 TB.
• Allocate Storage for Exadata Snapshots: Check this option to create
a sparse disk group, which is required to support Exadata snapshot
functionality. Exadata snapshots enable space-efficient clones of Oracle
databases that can be created and destroyed very quickly and easily.
• Allocate Storage for Local Backups: Check this option to configure
the Exadata storage to enable local database backups. If you select this
option, more space is allocated to the RECO disk group to accommodate
the backups. If you do not select this option, you cannot use local Exadata
storage as a backup destination for any databases in the VM cluster.
m. Add SSH Key: Specify the public key portion of an SSH key pair that you
want to use to access the VM cluster compute nodes. You can upload a file
containing the key, or paste the SSH key string.
To provide multiple keys, upload multiple key files or paste each key into
a separate field. For pasted keys, ensure that each key is on a single,
continuous line. The length of the combined keys cannot exceed 10,000
characters.
n. Choose a license type:
• Bring Your Own License (BYOL): Select this option if your organization
already owns Oracle Database software licenses that you want to use on
the VM cluster.
• License Included: Select this option to subscribe to Oracle Database
software licenses as part of Exadata Cloud@Customer.
o. Show Advanced Options:
• Time zone: The default time zone for the Exadata Infrastructure is UTC,
but you can specify a different time zone. The time zone options are those
supported in both the Java.util.TimeZone class and the Oracle Linux
operating system.

4-11
 Chapter 4
Using the Console for VM Clusters on Exadata Cloud@Customer

Note:
If you want to set a time zone other than UTC or the browser-
detected time zone, then select the Select another time
zone option, select a Region or country, and then select the
corresponding Time zone.
If you do not see the region or country you want, then select
Miscellaneous, and then select an appropriate Time zone.

• Tags: Optionally, you can apply tags. If you have permissions to create
a resource, you also have permissions to apply free-form tags to that
resource. To apply a defined tag, you must have permissions to use the
tag namespace. For more information about tagging, see Resource Tags.
If you are not sure if you should apply tags, skip this option (you can apply
tags later) or ask your administrator.
6. Click Create VM Cluster.
The VM Cluster Details page is now displayed. While the creation process is
running, the state of the VM cluster is Pending. When the VM cluster creation
process completes, the state of the VM cluster changes to Available.
Related Topics
• Plan Your Configuration Settings on Storage
• Using the Console to Scale the Resources on a VM Cluster
Starting in Exadata Cloud@Customer Gen2, you can scale up or down multiple
resources at the same time. You can also scale up or down resources one at a
time.
• Resource Tags
• Oracle PaaS/IaaS Cloud Service Description documents
• Oracle Platform as a Service and Infrastructure as a Service – Public Cloud
Service DescriptionsMetered & Non-Metered

Using the Console to Add SSH Keys After Creating a VM Cluster

1. Open the navigation menu. Under Database, click Exadata Cloud at Customer.
2. Choose the Region that contains your Exadata infrastructure.
3. Click VM Clusters.
4. Click the name of the VM cluster that you want to add SSH key(s).
5. In the VM Cluster Details page, click Add SSH Keys.
6. In the ADD SSH Keys dialog, choose any one of the methods:
• Generate SSH key pair: Select this option if you want the Control Plane to
generate public/private key pairs for you.
Click Save Private Key and Save Public Key to download and save SSH Key
pair.
• Upload SSH key files: Select this option to upload the file that contains SSH
Key pair.

4-12
 Chapter 4
Using the Console for VM Clusters on Exadata Cloud@Customer

• Paste SSH keys: Select this option to paste the SSH key string.
To provide multiple keys, click Another SSH Key. For pasted keys, ensure
that each key is on a single, continuous line. The length of the combined keys
cannot exceed 10,000 characters.
7. Click Save Changes.
Related Topics
• Managing Key Pairs on Linux Instances

Using the Console to Scale the Resources on a VM Cluster

Starting in Exadata Cloud@Customer Gen2, you can scale up or down multiple
resources at the same time. You can also scale up or down resources one at a time.
Scale down resources under the following circumstances:
• Use Case 1: If you have allocated all of the resources to one virtual machine,
and if you want to create multiple virtual machines, then there wouldn't be any
resources available to allocate to the new virtual machine. Therefore, scale down
the resources as needed before you can create any additional virtual machines.
• Use Case 2: If you want to allocate different resources based on the workload,
then scale down or scale up accordingly. For example, you may want to run nightly
batch jobs for reporting/ETL and scale down the VM once the job is over.
You can scale down the following resources in any combinations:
• OCPU
• Memory
• Local storage
• Exadata storage
Each scale down operation can take approximately 15 minutes to complete. If you run
multiple scale down operations, then all the operations are performed in a series. For
example, if you scale down memory and local storage from the Console, then scaling
down happens one after the other. Scaling down local storage and memory takes
more time than the time taken to scale down OCPU and Exadata storage.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that contains the VM cluster for which you
want to scale the CPU resources.
3. Click VM Clusters.
4. Click the name of the VM cluster for which you want to scale the CPU resources.
The VM Cluster Details page displays information about the selected VM cluster.
5. Click Scale Up/Down.
6. In the dialog box, adjust any or all of the following:
• OCPU Count:
The OCPU Count value must be a multiple of the number of compute nodes
so that every compute node has the same number of CPU cores enabled.

4-13
 Chapter 4
Using the Console for VM Clusters on Exadata Cloud@Customer

If you set the OCPU Count to zero, then the VM cluster compute nodes are
all shut down. If you change from a zero setting, then the VM cluster compute
nodes are all started. Otherwise, modifying the number of enabled CPU cores
is an online operation, and compute nodes are not rebooted because of this
operation. See also System Configuration.

Note:
If you have explicitly set the CPU_COUNT database initialization
parameter, that setting is not affected by modifying the number of
CPU cores that are allocated to the VM cluster. Therefore, if you
have enabled the Oracle Database instance caging feature, the
database instance does not use extra CPU cores until you alter
the CPU_COUNT setting. If CPU_COUNT is set to 0 (the default setting),
then Oracle Database continuously monitors the number of CPUs
reported by the operating system and uses the current count.

• Memory:
Specify the memory for each individual VM. The value must be a multiple of 1
GB and is limited by the available memory on the Exadata infrastructure.
When you scale up or down the memory, the associated compute nodes are
rebooted in a rolling manner one compute node at a time to minimize the
impact on the VM cluster.
• Local file system size:
Specify the size for each individual VM. The value must be a multiple of 1
GB and is limited by the available size of the file system on the Exadata
infrastructure.
When you scale up or down the local file system size, the associated compute
nodes are rebooted in a rolling manner one compute node at a time to
minimize the impact on the VM cluster.
Reserved local storage per VM (GB): Displays the size reserved internally
for root file systems, Oracle Grid Infrastructure Homes, and diagnostic logs.
• Usable Exadata storage size:
Specify the total amount of Exadata storage that is allocated to the VM cluster.
This storage is allocated evenly from all of the Exadata Storage Servers. The
minimum recommended size is 2 TB.
You may reduce the Exadata storage allocation for a VM cluster. However, you
must ensure that the new amount covers the existing contents, and you should
also allow for anticipated data growth.

Note:
When you downsize, the new size must be at least 15% more than
the currently used size.

Modifying the Exadata storage allocated to the VM cluster is an online

operation. Compute nodes are not rebooted because of this operation.
7. . Click Save Changes.

4-14
 Chapter 4
Using the Console for VM Clusters on Exadata Cloud@Customer

Related Topics
• System Configuration Options for Oracle Exadata Cloud@Customer

Using the Console to Stop, Start, or Reboot a VM Cluster Compute

Node
Use the console or API calls to stop, start, or reboot a compute node.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that is associated with the VM cluster that
contains the compute node that you want to stop, start, or reboot.
3. Click VM Clusters.
4. Click the name of the VM cluster that contains the compute node that you want to
stop, start, or reboot.
The VM Cluster Details page displays information about the selected VM cluster.
5. In the Resources list, click Virtual Machines.
The list of compute nodes is displayed.
6. In the list of nodes, click the Actions icon (three dots) for a node, and then click
one of the following actions:
a. Start: Restarts a stopped node. After the node is restarted, the Stop action is
enabled.
b. Stop: Shuts down the node. After the node is stopped, the Start action is
enabled.
c. Reboot: Shuts down the node, and then restarts it.

Using the Console to Check the Status of a VM Cluster Compute

Node
Review the health status of a VM cluster compute node.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that is associated with the VM cluster that
contains the compute node that you are interested in.
3. Click VM Clusters.
4. Click the name of the VM cluster that contains the compute node that you are
interested in.
The VM Cluster Details page displays information about the selected VM cluster.
5. In the Resources list, click Virtual Machines.
The list of compute nodes displays. For each compute node in the VM cluster, the
name, state, and client IP address are displayed.
6. In the node list, find the compute node that you are interested in and check its
state.

4-15
 Chapter 4
Using the Console for VM Clusters on Exadata Cloud@Customer

The color of the icon and the associated text it indicates its status.
• Available: Green icon. The node is operational.
• Starting: Yellow icon. The node is starting because of a start or reboot action
in the Console or API.
• Stopping: Yellow icon. The node is stopping because of a stop or reboot
action in the Console or API.
• Stopped: Yellow icon. The node is stopped.
• Failed: Red icon. An error condition prevents the continued operation of the
compute node.

Using the Console to Update the License Type on a VM Cluster

To modify licensing, be prepared to provide values for the fields required for modifying
the licensing information.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that contains the VM cluster for which you
want to update the license type.
3. Click VM Clusters.
4. Click the name of the VM cluster for which you want to update the license type.
The VM Cluster Details page displays information about the selected VM cluster.
5. Click Update License Type.
6. In the dialog box, choose one of the following license types and then click Save
Changes.
• Bring Your Own License (BYOL): Select this option if your organization
already owns Oracle Database software licenses that you want to use on the
VM cluster.
• License Included: Select this option to subscribe to Oracle Database
software licenses as part of Exadata Cloud@Customer.
Updating the license type does not change the functionality or interrupt the
operation of the VM cluster.

Using the Console to Move a VM Cluster to Another Compartment

To change the compartment that contains your VM cluster on Exadata
Cloud@Customer, use this procedure.
When you move a VM cluster, the compartment change is also applied to the
compute nodes and databases that are associated with the VM cluster. However,
the compartment change does not affect any other associated resources, such as the
Exadata infrastructure, which remains in its current compartment.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that contains the VM cluster that you want
to move.

4-16
 Chapter 4
Using the API to Manage Exadata Cloud@Customer VM Clusters

3. Click VM Clusters.
4. Click the name of the VM cluster that you want to move.
The VM Cluster Details page displays information about the selected VM cluster.
5. Click Move Resource.
6. In the resulting dialog, choose the new compartment for the VM cluster, and click
Move Resource.

Using the Console to Terminate a VM cluster

Before you can terminate a VM cluster, you must first terminate the databases that it
contains.
Terminating a VM cluster removes it from the Cloud Control Plane. In the process, the
compute node VMs and their contents are destroyed.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that contains the VM cluster that you want
to terminate.
3. Click VM Clusters.
4. Click the name of the VM cluster that you want to terminate.
The VM Cluster Details page displays information about the selected VM cluster.
5. Click Terminate.
6. In the resulting dialog, enter the name of the VM cluster, and click Terminate VM
Cluster to confirm the action.

Using the API to Manage Exadata Cloud@Customer VM

Clusters
Review the list of API calls to manage your Exadata Cloud@Customer VM cluster
networks and VM clusters.
For information about using the API and signing requests, see "REST APIs" and
"Security Credentials". For information about SDKs, see "Software Development Kits
and Command Line Interface".
Use these API operations to manage Exadata Cloud@Customer VM cluster networks
and VM clusters:
VM cluster networks:
• GenerateRecommendedVmClusterNetwork
• CreateVmClusterNetwork
• DeleteVmClusterNetwork
• GetVmClusterNetwork
• ListVmClusterNetworks
• UpdateVmClusterNetwork

4-17
 Chapter 4
Introduction to Scale Up or Scale Down Operations

• ValidateVmClusterNetwork

VM clusters:
• CreateVmCluster
• DeleteVmCluster
• GetVmCluster
• ListVmCluster
• UpdateVmCluster

For the complete list of APIs, see "Database Service API".

Related Topics
• REST APIs
• Security Credentials
• Software Development Kits and Command Line Interface
• GenerateRecommendedVmClusterNetwork
• CreateVmClusterNetwork
• DeleteVmClusterNetwork
• GetVmClusterNetwork
• ListVmClusterNetworks
• UpdateVmClusterNetwork
• ValidateVmClusterNetwork
• CreateVmCluster
• DeleteVmCluster
• GetVmCluster
• ListVmCluster
• UpdateVmCluster
• Database Service API

Introduction to Scale Up or Scale Down Operations

With the Multiple VMs per Exadata system (MultiVM) feature release, you can scale up
or scale down your VM cluster resources.
• Scaling Up or Scaling Down the VM Cluster Resources
• Calculating the Minimum Required Memory
• Calculating the ASM Storage
• Estimating How Much Local Storage You Can Provision to Your VMs
• Scaling Local Storage Down

Scaling Up or Scaling Down the VM Cluster Resources

4-18
 Chapter 4
Introduction to Scale Up or Scale Down Operations

You can scale up or scale down the memory, local disk size (/u02), ASM Storage,
and CPUs. Scaling up or down of these resources requires thorough auditing of
existing usage and capacity management by the customer DB administrator. Review
the existing usage to avoid failures during or after a scale down operation. While
scaling up, consider how much of these resources are left for the next VM cluster you
are planning to create. Exadata Cloud@Customer Cloud tooling calculates the current
usage of memory, local disk, and ASM storage in the VM cluster, adds headroom to
it, and arrives at a "minimum" value below which you cannot scale down, and expects
that you specify the value below this minimum value.

Note:
For memory and /u02 scale up or scale down operations, if the difference
between the current value and the new value is less than 2%, then no
change will be made to that VM. This is because memory change involves
rebooting the VM, and /u02 change involves bringing down the Oracle Grid
Infrastructure stack and un-mounting /u02. Productions customers will not
resize for such a small increase or decrease, and hence such requests are a
no-op.

Calculating the Minimum Required Memory

Cloud tooling provides dbaasapi to identify the minimum required memory. As root
user, you have to run dbaasapi and pass a JSON file with sample content as follows.
The only parameter that you need to update in the input.json is new_mem_size,
which is the new memory to which you want the VM cluster to be re-sized.

cat input.json
{
"object": "db",
"action": "get",
"operation": "precheck_memory_resize",
"params": {
"dbname": "grid",
"new_mem_size" : "30 gb",
"infofile": "/tmp/result.json"
},
"outputfile": "/tmp/info.out",
"FLAGS": ""
}

dbaasapi -i input.json

cat /tmp/result.json
{
"is_new_mem_sz_allowed" : 0,
"min_req_mem" : 167
}

4-19
 Chapter 4
Introduction to Scale Up or Scale Down Operations

The result indicates that 30 GB is not sufficient and the minimum required memory
is 167 GB, and that is the maximum you can reshape down to. On a safer side, you
must choose a value greater than 167 GB, as there could be fluctuations of that order
between this calculation and the next reshape attempt.

Calculating the ASM Storage

Use the following formula to calculate the minimum required ASM storage:
• For each disk group, for example, DATA, RECO, note the total size and free size by
running the asmcmd lsdg command on any Guest VM of the VM cluster.
• Calculate the used size as (Total size - Free size) / 3 for each disk group. The /3 is
used because the disk groups are triple mirrored.
• DATA:RECO ratio is:
80:20 if Local Backups option was NOT selected in the user interface.
40:60 if Local Backups option was selected in the user interface.
• Ensure that the new total size as given in the user interface passes the following
conditions:
Used size for DATA * 1.15 <= (New Total size * DATA % )
Used size for RECO * 1.15 <= (New Total size * RECO % )
Example 4-1 Calculating the ASM Storage
1. Run the asmcmd lsdg command in the Guest VM:
• Without SPARSE:

/u01/app/19.0.0.0/grid/bin/asmcmd lsdg
ASMCMD>
State Type Rebal Sector Logical_Sector Block AU Total_MB
Free_MB Req_mir_free_MB Usable_file_MB Offline_disks
Voting_files Name
MOUNTED HIGH N 512 512 4096 4194304
12591936 10426224 1399104 3009040
0 Y DATAC5/
MOUNTED HIGH N 512 512 4096 4194304
3135456 3036336 348384 895984
0 N RECOC5/
ASMCMD>

• With SPARSE:

/u01/app/19.0.0.0/grid/bin/asmcmd lsdg
ASMCMD>
State Type Rebal Sector Logical_Sector Block AU
Total_MB Free_MB Req_mir_free_MB Usable_file_MB
Offline_disks Voting_files Name
MOUNTED HIGH N 512 512 4096 4194304
12591936 10426224 1399104 3009040
0 Y DATAC5/
MOUNTED HIGH N 512 512 4096 4194304
3135456 3036336 348384 895984

4-20
 Chapter 4
Introduction to Scale Up or Scale Down Operations

0 N RECOC5/
MOUNTED HIGH N 512 512 4096 4194304
31354560 31354500 3483840 8959840
0 N SPRC5/
ASMCMD>

Note:
The listed values of all attributes for SPARSE diskgroup
(SPRC5) present the virtual size. In Exadata DB Systems
and Exadata Cloud@Customer, we use the ratio of 1:10 for
physicalSize:virtualSize. Hence, for all purposes of our calculation
we must use 1/10th of the values displayed above in case of SPARSE
for those attributes.

2. Used size for a disk group = (Total_MB - Free_MB) /3

• Without SPARSE:
Used size for DATAC5 = (12591936 - 10426224 ) / 3 = 704.98 GB
Used size for RECO5 = (3135456 - 3036336 ) / 3 = 32.26 GB
• With SPARSE:
Used size for DATAC5 = (12591936 - 10426224 ) / 3 ~= 704.98 GB
Used size for RECO5 = (3135456 - 3036336 ) /3 ~= 32.26 GB
Used size for SPC5 = (1/10 * (31354560 - 31354500)) / 3 ~= 0 GB
3. Storage distribution among diskgroups
• Without SPARSE:
DATA:RECO ratio is 80:20 in this example.
• With SPARSE:
DATA RECO: SPARSE ratio is 60:20:20 in this example.
4. New requested size should pass the following conditions:
• Without SPARSE: (For example, 5 TB in user interface.)
5 TB = 5120 GB ; 5120 *.8 = 4096 GB; 5120 *.2 = 1024 GB
For DATA: (704.98 * 1.15 ) <= 4096 GB
For RECO: (32.36 * 1.15) <= 1024 GB
• With SPARSE: (For example, 8 TB in the user interface.)
8 TB = 8192 GB; 8192 *.6 = 4915 GB; 8192 *.2 = 1638 GB; 8192 *.2 = 1638
GB
For DATA: (704.98 * 1.15 ) <= 4915 GB
For RECO: (32.36 * 1.15) <= 1638 GB
For SPR: (0 * 1.15) <= 1638 GB
Above resize will go through. If above conditions are not met by the new size, then
resize will fail the precheck.

Estimating How Much Local Storage You Can Provision to Your VMs

4-21
 Chapter 4
Introduction to Scale Up or Scale Down Operations

X8-2 and X7-2 Systems

You specify how much space is provisioned from local storage to each VM. This space
is mounted at location /u02, and is used primarily for Oracle Database homes. The
amount of local storage available will vary with the number of virtual machines running
on each physical node, as each VM requires a fixed amount of storage (137 GB) for
the root file systems, GI homes, and diagnostic log space. Refer to the table below
to see the maximum amount of space available to provision to local storage (/u02)
across all VMs.
Total space available to all VMs on an ExaCC X7 node is 1237 GB. Total space
available to all VMs on a ExaCC X8 database node is 1037 GB.

Table 4-1 Space allocated to VMs

#VMs Space Consumed by X8-2 Space for X7-2 Space for

VM Image or GI ALL /u02 (GB) ALL /u02 (GB)
1 137 900 1100
2 274 763 963
3 411 626 826
4 548 489 689
5 685 352 552
6 822 N/A 415

For an X8-2, to get the max space available for the nth VM, take the number in the
table above and subtract anything previously allocated for /u02 to the other VMs. So if
you allocated 60 GB to VM1, 70 GB to VM2, 80 GB to VM3, 60 GB to VM4 (total 270
GB) in an X8-2, the maximum available for VM 5 would be 352 - 270 = 82 GB.
In ExaCC Gen 2, we require a minimum of 60 GB per /u02, so with that minimum size
there is a maximum of 5 VMs in X8-2 and 6 VMs in X7-2.
X8M-2 Systems
The maximum number of VMs for an X8M-2 will be 8, regardless of whether there is
local disk space or other resources available.
For an X8M-2 system, the fixed consumption per VM is 160 GB.
Total space available to all VMs on an ExaCC X8M databases node is 2500 GB.
Although there is 2500 GB per database node, with a single VM, you can allocate a
maximum of 900 GB local storage. Similarly, for the second VM, there is 1800 GB local
storage available given the max limit of 900 GB per VM. With the third VM, the amount
of space available is 2500 - (160Gb * 3) = 2020 GB. And so on for 4 and more VMs.

Table 4-2 Space allocated to VMs

#VMs Space Consumed by VM X8M-2 Quarter/Half/Full

Image or GI Rack Space for All /u02
(GB)*
1 160 900
2 320 1800
3 480 2020

4-22
 Chapter 4
Introduction to Scale Up or Scale Down Operations

Table 4-2 (Cont.) Space allocated to VMs

#VMs Space Consumed by VM X8M-2 Quarter/Half/Full

Image or GI Rack Space for All /u02
(GB)*
4 640 1860
5 800 1700
6 960 1540
7 1120 1380
8 1280 1220

*Max 900 GB per VM

For an X8M-2, to get the max space available for the nth VM, take the number in the
table above and subtract anything previously allocated for /u02 to the other VMs. So,
for a quarter and larger rack, if you allocated 60 GB to VM1, 70 GB to VM2, 80 GB
to VM3, 60 GB to VM4 (total 270 GB) in an X8M-2, the maximum available for VM 5
would be 1700 - 270 = 1430 GB. However, the per VM maximum is 900 GB, so that
would take precedent and limits VM5 to 900 GB.

Scaling Local Storage Down

Scale Down Local Space Operation Guidelines
Scale down operation expects you to input local space value that you want each node
to scale down to.
• Resource Limit Based On Recommended Minimums
Scale down operation must meet 60 GB recommended minimum size requirement
for local storage.
• Resource Limit Based On Current Utilization
The scale down operation must leave 15% buffer on top of highest local space
utilization across all nodes in the cluster.
The lowest local space per node allowed is higher of the above two limits.
Run df –kh command on each node to find out the node with the highest local
storage.
You can also use the utility like cssh to issue the same command from all hosts in a
cluster by typing it just once.
Lowest value of local storage each node can be scaled down to would be = 1.15x
(highest value of local space used among all nodes).

4-23
5
Managing Backup Destinations for Exadata
Cloud@Customer
Learn to manage backup destinations for Exadata Cloud@Customer on Oracle Zero
Data Loss Recovery Appliance or Network File System (NFS).
• About Managing Backup Destinations for Exadata Cloud@Customer
For backups, you can either use the Exadata Cloud@Customer backup facility, or
you can configure a backup location on a location you manage.
• Required IAM Policy for Backup Destinations
Review the identity access management (IAM) policy for backup destinations for
Oracle Exadata Cloud@Customer Systems.
• Prerequisites for Backup Destinations for Exadata Cloud@Customer
To configure backup destinations on a Zero Data Loss Recovery Appliance
location, or an NFS backup location, review the prerequisites.
• Using the Console for Backup Destinations for Exadata Cloud@Customer
Learn how to use the console to create, edit, move, and terminate a backup
destination for your infrastructure for Oracle Exadata Cloud@Customer.
• Using the API to Manage Exadata Cloud@Customer Backup Destinations
Review the list of API calls to manage your Exadata Cloud@Customer backup
destinations.

About Managing Backup Destinations for Exadata

Cloud@Customer
For backups, you can either use the Exadata Cloud@Customer backup facility, or you
can configure a backup location on a location you manage.
Exadata Cloud@Customer provides a backup facility, which you can configure
individually on each database. See: "Managing Databases on Exadata
Cloud@Customer" and "Managing Database Backup and Recovery on Exadata
Cloud@Customer".
If you want to store backups on a Recovery Appliance, or on a network file storage
(NFS) location that you manage, then you must first create a backup destination. Each
backup destination defines the properties that are required to connect to the Recovery
Appliance or NFS location, and each backup destination must be accessible in your
data center from the VM cluster nodes.
The Exadata Cloud@Customer backup facility can also store backups on Oracle
Cloud Infrastructure object storage, or on local Exadata storage on your Exadata
Cloud@Customer system. However, you do not need to create a backup destination
for any of these other locations. Instead, applicable options for backup to cloud object
storage or local Exadata storage are available directly when you create a database.

5-1
 Chapter 5
Required IAM Policy for Backup Destinations

Note:
Avoid entering confidential information when assigning descriptions, tags,
or friendly names to your cloud resources through the Oracle Cloud
Infrastructure Console, API, or CLI.

Related Topics
• Zero Data Loss Recovery Appliance
• Managing Oracle Databases on Oracle Exadata Cloud@Customer
• Managing Database Backup and Recovery on Oracle Exadata Cloud@Customer

Required IAM Policy for Backup Destinations

Review the identity access management (IAM) policy for backup destinations for
Oracle Exadata Cloud@Customer Systems.
A policy is an IAM document that specifies who has what type of access to your
resources. It is used in different ways:
• An individual statement written in the policy language
• A collection of statements in a single, named "policy" document, which has an
Oracle Cloud ID (OCID) assigned to it
• The overall body of policies your organization uses to control access to resources
A compartment is a collection of related resources that can be accessed only
by certain groups that have been given permission by an administrator in your
organization.
To use Oracle Cloud Infrastructure, you must be given the required type of access in
a policy written by an administrator, whether you're using the Console, or the REST
API with a software development kit (SDK), a command-line interface (CLI), or some
other tool. If you try to perform an action, and receive a message that you don’t
have permission, or are unauthorized, then confirm with your administrator the type of
access you've been granted, and which compartment you should work in.
For administrators: The policy in "Let database admins manage DB systems" lets the
specified group do everything with databases, and related database resources.
If you're new to policies, then see "Getting Started with Policies" and "Common
Policies". If you want to dig deeper into writing policies for databases, then see "Details
for the Database Service".
Related Topics
• Let database admins manage DB systems
• Getting Started with Policies
• Common Policies
• Details for the Database Service

5-2
 Chapter 5
Prerequisites for Backup Destinations for Exadata Cloud@Customer

Prerequisites for Backup Destinations for Exadata

Cloud@Customer
To configure backup destinations on a Zero Data Loss Recovery Appliance location, or
an NFS backup location, review the prerequisites.
• For a Zero Data Loss Recovery Appliance backup destination:
– The appliance must be configured with a virtual private catalog (VPC) user,
which is used for taking the backups.
– The appliance must be configured with the unique database name of the
database being backed up, and a mapping to the VPC user.
– The appliance must be accessible from the Exadata Cloud@Customer system
using the Oracle Net Services connection string, which is provided by the Zero
Data Loss Recovery Appliance administrator.
• For an NFS backup destination:
– Exadata Cloud@Customer non-autonomous databases:
* You must mount the NFS server location to a local mount point directory
on each node in the VM cluster.
* The local mount point directory and the NFS server must be identical
across all nodes in the cluster.
* You must ensure that the NFS mount is maintained continuously on all of
the VM cluster nodes.
* The NFS-mounted file system must be readable and writable by the
oracle operating system user on all of the VM cluster nodes.
– Exadata Cloud@Customer Autonomous Databases:
* To ensure that the Autonomous VM cluster can access the NFS server
over the Backup Network, enter valid Backup Network IP addresses while
configuring VM Cluster Network.
* The NFS-mounted file system must be readable and writable by the
oracle operating system user on all of the VM cluster nodes.
* If permissions are being controlled at the user level, then the uid:gid of the
oracle user for the Autonomous VM cluster is 1001:1001.

Using the Console for Backup Destinations for Exadata

Cloud@Customer
Learn how to use the console to create, edit, move, and terminate a backup
destination for your infrastructure for Oracle Exadata Cloud@Customer.
• Using the Console to Create a Backup Destination
To create a backup destination, be prepared to provide values for the backup
destination configuration.

5-3
 Chapter 5
Using the Console for Backup Destinations for Exadata Cloud@Customer

• Using the Console to Edit a Backup Destination

To edit a backup destination, be prepared to provide values for the backup
destination configuration.
• Using the Console to Move a Backup Destination to Another Compartment
To move a backup destination, be prepared to provide values for the backup
destination configuration.
• Using the Console to Terminate a Backup Destination
To terminate a backup destination, be prepared to provide values for the backup
destination configuration.

Using the Console to Create a Backup Destination

To create a backup destination, be prepared to provide values for the backup
destination configuration.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region that contains your Exadata infrastructure.
3. Click Backup Destinations.
4. Click Create Backup Destination.
5. Provide the requested information in the Create Backup Destination page:
a. Choose a compartment.
From the list of available compartments, choose the compartment that you
want to contain the backup destination.
b. Name your backup destination.
Specify a user-friendly name that you can use to identify the backup
destination. The name doesn't need to be unique because an Oracle Cloud
Identifier (OCID) uniquely identifies the backup destination.
c. Choose either a Zero Data Loss Recovery Appliance or a network file system
(NFS) backup destination.

Note:
You can also set OCI Object Store as a backup destination.
However, you cannot set it from this screen. You can configure OCI
Object Store as a backup destination when creating a database. For
more information, see Backup Destination Type in Using the Console
to Create a Database.

Select Recovery Appliance or Network Storage (NFS).

• If you select Recovery Appliance, then you must also specify the
following for Zero Data Loss Recovery Appliance:
– Provide the Recovery Appliance connection string: Specify the
Oracle Net Services connection string that connects to the appliance.
This information is typically provided by the Zero Data Loss Recovery
Appliance administrator.

5-4
 Chapter 5
Using the Console for Backup Destinations for Exadata Cloud@Customer

– Provide the Virtual Private Catalog (VPC) Users: Provide a VPC

user name for connecting to the Zero Data Loss Recovery Appliance.
You can specify multiple VPC user names in case you want to use
the appliance as a backup destination for multiple databases. This
information is typically provided by the Zero Data Loss Recovery
Appliance administrator.
• If you select Network Storage (NFS), then you must also specify the
following:
– Self-mount for non-autonomous databases:
Provide the local NFS mount point path: Specify the local directory
path on each VM cluster node where the NFS server location is
mounted. The local directory path and the NFS server location must
each be the same across all of the VM cluster nodes.
– Auto-mount for Autonomous Databases:
Use this destination for Autonomous Databases:
* NFS server: Specify the IP address of the NFS server. Optionally,
you can specify up to four IP addresses.
* NFS export share: Specify the directory path where the exported
file system is mounted.
d. Configure Advanced Options.
• Tags: (Optional) You can choose to apply tags. If you have permissions
to create a resource, then you also have permissions to apply free-form
tags to that resource. To apply a defined tag, you must have permissions
to use the tag namespace. For more information about tagging, refer
to information about resource tags. If you are not sure if you should
apply tags, then skip this option (you can apply tags later), or ask your
administrator.
6. Click Create Backup Destination.
The Backup Destination Details page displays the newly created backup
destination.
Related Topics
• Using the Console to Create a Database
To create an Oracle Database with the console, use this procedure.
• Resource Tags

Using the Console to Edit a Backup Destination

To edit a backup destination, be prepared to provide values for the backup destination
configuration.
You can only edit a backup destination if it is not currently associated with database.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that contains the backup destination that
you want to edit.
3. Click Backup Destinations.

5-5
 Chapter 5
Using the Console for Backup Destinations for Exadata Cloud@Customer

4. Click the name of the backup destination that you want to edit.
The Backup Destination Details page displays information about the selected
backup destination.
5. Click Edit.
6. Use the Edit Backup Destination dialog to edit the backup destination attributes:

Note:
You cannot edit a Backup Destination if there is already a database
attached to it.

• If you are editing a Zero Data Loss Recovery Appliance backup destination:
– Provide the Recovery Appliance connection string: Specify the Oracle
Net Services connection string that connects to the Recovery Appliance.
This information is typically provided by the Recovery Appliance
administrator.
– Provide the Virtual Private Catalog (VPC) Users: Provide a VPC user
name for connecting to the Recovery Appliance. You can specify multiple
VPC user names in case you want to use the Recovery Appliance as
a backup destination for multiple databases. This information is typically
provided by the Recovery Appliance administrator.
• If you are editing an NFS backup destination:
– Self-mount for non-autonomous databases:
Provide the local NFS mount point path: Specify the local directory path
on each VM cluster node where the NFS server location is mounted. The
local directory path and the NFS server location must each be the same
across all of the VM cluster nodes.
– Auto-mount for Autonomous Databases:
Use this destination for Autonomous Databases:
* NFS server: Specify the IP address of the NFS server. Optionally, you
can specify up to four IP addresses.
* NFS export share: Specify the directory path where the exported file
system is mounted.
7. Click Save Changes.

Using the Console to Move a Backup Destination to Another

Compartment
To move a backup destination, be prepared to provide values for the backup
destination configuration.
You can change the compartment that contains your backup destination by moving it.

5-6
 Chapter 5
Using the API to Manage Exadata Cloud@Customer Backup Destinations

When you move a backup destination, the compartment change does not affect other
associated resources. These other resources, such as the associated databases,
remain in their current compartment.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that contains the backup destination that
you want to move.
3. Click Backup Destinations.
4. Click the name of the backup destination that you want to move.
The Backup Destination Details page displays information about the selected
backup destination.
5. Click Move Resource.
6. In the resulting dialog, choose the new compartment for the backup destination
and click Move Resource.

Using the Console to Terminate a Backup Destination

To terminate a backup destination, be prepared to provide values for the backup
destination configuration.
Terminating a backup destination removes it from the Cloud Control Plane. Before you
can terminate a backup destination, you must ensure that it is not associated with any
databases.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that contains the backup destination that
you want to terminate.
3. Click Backup Destinations.
4. Click the name of the backup destination that you want to terminate.
The Backup Destination Details page displays information about the selected
backup destination.
5. Click Terminate.
6. In the resulting dialog, enter the backup destination name and click Terminate
Backup Destination to confirm the action.

Using the API to Manage Exadata Cloud@Customer

Backup Destinations
Review the list of API calls to manage your Exadata Cloud@Customer backup
destinations.
For information about using the API and signing requests, see "REST APIs" and
"Security Credentials". For information about SDKs, see "Software Development Kits
and Command Line Interface".
Use these API operations to manage Exadata Cloud@Customer backup destinations:

5-7
 Chapter 5
Using the API to Manage Exadata Cloud@Customer Backup Destinations

• CreateBackupDestination
• DeleteBackupDestination
• GetBackupDestination
• ListBackupDestination
• UpdateBackupDestination
• ChangeBackupDestinationCompartment

For the complete list of APIs, see "Database Service API".

Related Topics
• REST APIs
• Security Credentials
• Software Development Kits and Command Line Interface
• CreateBackupDestination
• DeleteBackupDestination
• GetBackupDestination
• ListBackupDestination
• UpdateBackupDestination
• ChangeBackupDestinationCompartment
• Database Service API

5-8
6
Oracle Database Software Images
Learn about Database Software Image resource type and how you can use it to create
Oracle Databases and Oracle Database Homes and to patch databases.
Database Software Images enable you to create a customized Oracle Database
software configuration that includes your chosen updates (PSU, RU or RUR), and
optionally, a list of one-off (or interim) patches or an Oracle Home inventory file. This
reduces the time required to provision and configure your databases, and makes it
easy for your organization to create an approved "gold image" for developers and
database administrators.
• Creation and Storage of Database Software Images
Database software images are resources within your tenancy that you create prior
to provisioning or patching an Exadata Cloud@Customer instance, a Database
Home, or a database.
• Using a Database Software Image with an Exadata Cloud@Customer System
Create, save, and reuse an Oracle Database Software Image.
• Using the Console to Create a Database Software Image
To create an Oracle Database Software Image with the console, use this
procedure.
• Using the OPatch lsinventory Command to Verify the Patches Applied to an Oracle
Home
OPatch utility enables you to apply the interim patches to Oracle Database
software. You can find opatch utility in the $ORACLE_HOME/Opatch directory.
• Using the Console to Delete a Database Software Image
• Using the Console to View the Patch Information of a Database Software Image
To view the Oracle Database version, update information (PSU/BP/RU level), and
included one-off (interim) patches of a database software image, use the following
instructions:
• Using the Console to Move Database Software Image to a Different Compartment
Follow these steps to move a Database Software Image to a different
compartment of your choice:
• Using the API for Managing Oracle Database Software Images
Review the list of API calls to manage Oracle Database Software Image.
Related Topics
• Using the Console to Create Oracle Database Home on Exadata
Cloud@Customer
To create an Oracle Database home in an existing VM cluster with the Console, be
prepared to provide values for the fields required.
• Using the Console to Perform a Patch Operation on a Database Home
Learn to apply patches on a Database Home.

6-1
 Chapter 6
Creation and Storage of Database Software Images

Creation and Storage of Database Software Images

Database software images are resources within your tenancy that you create prior to
provisioning or patching an Exadata Cloud@Customer instance, a Database Home, or
a database.
There is no limit on the number of database software images you can create in your
tenancy, and you can create your images with any Oracle Database software version
and update supported in Oracle Cloud Infrastructure.
Database software images are automatically stored in Oracle-managed Object
Storage and can be viewed and managed in the Oracle Cloud Infrastructure
Console. Note that database software images incur Object Storage usage costs.
Database software image are regional-level resources and can be accessed from any
availability domain within their region.
For information on creating an image, see Using the Console to Create a Database
Software Image.
Related Topics
• About Regions and Availability Domains
• Using the Console to Create a Database Software Image
To create an Oracle Database Software Image with the console, use this
procedure.

Using a Database Software Image with an Exadata

Cloud@Customer System
Create, save, and reuse an Oracle Database Software Image.
Creating an Oracle Database Software Image enables you to:
• Create custom Database Home images based on Database Software Images, RU/
RUR, and one-off patches.
• Save a custom image automatically to Object Storage as a resource.
• Use a Database Software Image to create Database Homes.
• Patch the Database Home created using the Database Software Image.
• Clone Database Software Image to another service in the Data Guard creation
process.
Provisioning: After you create a database software image, you can use it to create
an Oracle Database Home in an Exadata Cloud@Customer system. For more
information, see Using the Console to Create Oracle Database Home on Exadata
Cloud@Customer.
Patching: To patch a database in an Exadata Cloud@Customer system using a
custom database software image, create the Database Home using the image, and
then move the database to that Database Home. For more information, see Patching
an Exadata Cloud at Customer System.
Setting up Data Guard: When creating an Oracle Data Guard association, the custom
Database Software Image associated with the primary database will be used to

6-2
 Chapter 6
Using the Console to Create a Database Software Image

create a Database Home for the new standby. If the Database Software Image used
by the primary database is no longer available, then enable Data Guard operation
will not proceed. For more information, see Using Oracle Data Guard with Exadata
Cloud@Customer.

Note:
The Database Software Images are created and managed by the customer
and they are available for use until explicitly deleted.

Related Topics
• Using the Console to Create Oracle Database Home on Exadata
Cloud@Customer
To create an Oracle Database home in an existing VM cluster with the Console, be
prepared to provide values for the fields required.
• Patching an Exadata Cloud@Customer System
Learn how to perform patching operations on Exadata database compute nodes
and Database Homes by using the Console, API, or the CLI.
• Using Oracle Data Guard with Exadata Cloud@Customer
Learn to configure and manage Data Guard associations in your VM cluster.

Using the Console to Create a Database Software Image

To create an Oracle Database Software Image with the console, use this procedure.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Under Resources, click Database Software Images.
3. Click Create Database Software Image.
4. In the Display name field, provide a display name for your image. Avoid entering
confidential information.
5. Choose your Compartment.
6. Choose the Database version for your image.
7. Choose the patch set update, proactive bundle patch, or release update.
For information on Oracle Database patching models, see Release Update
Introduction and FAQ (Doc ID 2285040.1).
8. Optionally, you can enter a comma-delimited list of one-off (interim) patch
numbers.
9. Optionally, you can upload an Oracle Home inventory file from an existing Oracle
Database. For more information, see Using the OPatch lsinventory Command to
Verify the Patches Applied to an Oracle Home.
10. Click Show Advanced Options to add tags to your database software image.
To apply a defined tag, you must have permission to use the tag namespace.
For more information about tagging, see Resource Tags. If you are not sure if
you should apply tags, skip this option (you can apply tags later) or ask your
administrator.

6-3
 Chapter 6
Using the OPatch lsinventory Command to Verify the Patches Applied to an Oracle Home

11. Click Create Database Software Image.

Related Topics
• Release Update Introduction and FAQ (Doc ID 2285040.1)
• Using the OPatch lsinventory Command to Verify the Patches Applied to an Oracle
Home
OPatch utility enables you to apply the interim patches to Oracle Database
software. You can find opatch utility in the $ORACLE_HOME/Opatch directory.
• Resource Tags

Using the OPatch lsinventory Command to Verify the

Patches Applied to an Oracle Home
OPatch utility enables you to apply the interim patches to Oracle Database software.
You can find opatch utility in the $ORACLE_HOME/Opatch directory.

1. Run the opatch lsinventory command to get the list of interim patches applied.

$ORACLE_HOME/OPatch/opatch lsinventory
Oracle Interim Patch Installer version 12.2.0.1.21
Copyright (c) 2021, Oracle Corporation. All rights reserved.

Oracle Home : /u02/app/oracle/product/19.0.0.0/dbhome_2

Central Inventory : /u01/app/oraInventory
from : /u02/app/oracle/product/19.0.0.0/dbhome_2/oraInst.loc
OPatch version : 12.2.0.1.21
OUI version : 12.2.0.7.0
Log file location : /u02/app/oracle/product/19.0.0.0/dbhome_2/
cfgtoollogs/opatch/opatch2021-01-21_09-22-45AM_1.log

Lsinventory Output
file location : /u02/app/oracle/product/19.0.0.0/dbhome_2/
cfgtoollogs/opatch/lsinv/lsinventory2021-01-21_09-22-45AM.txt

2. Use the lsinventory output file to extract the additional One Off Patches applied
to a specific Oracle Home.

Using the Console to Delete a Database Software Image

1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Under Resources, click Database Software Images.
3. In the list of database software images, find the image you want to delete and click
the action icon (three dots) at the end of the row.
4. Click Delete.
5. Enter the Database Software Image name to confirm the deletion and click Delete
Database Software Image.

6-4
 Chapter 6
Using the Console to View the Patch Information of a Database Software Image

Using the Console to View the Patch Information of a

Database Software Image
To view the Oracle Database version, update information (PSU/BP/RU level), and
included one-off (interim) patches of a database software image, use the following
instructions:
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Under Resources, click Database Software Images.
3. In the list of database software images, find the image you want to view and click
on the display name of the image.
4. On the Database Software Image Details page for your selected image, details
about the image are displayed:
• The Oracle Database version is displayed in the General Information section.
For example: 19.0.0.0
• The PSU/BP/RU field of the Patch Information section displays the update
level for the image. For example: 19.5.0.0
• The One-Off Patches field displays the number of one-off patches included in
the image if any. The count includes all patches specified when creating the
image (excluding patches listed in lsinventory). To view the included patches
(if any are included), click the Copy All link and paste the list of included
patches into a text editor. The copied list of patch numbers is comma-delimited
and can be used to create additional Database Software Images.

Using the Console to Move Database Software Image to a

Different Compartment
Follow these steps to move a Database Software Image to a different compartment of
your choice:
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Under Resources, click Database Software Images.
3. In the list of database software images, find the image you want to delete and click
the action icon (three dots) at the end of the row.
4. Click Move Resource.
5. Choose a new compartment in the Move Resource to a Different Compartment
dialog.
6. Click Move Resource.

6-5
 Chapter 6
Using the API for Managing Oracle Database Software Images

Using the API for Managing Oracle Database Software

Images
Review the list of API calls to manage Oracle Database Software Image.
For information about using the API and signing requests, see "REST APIs" and
"Security Credentials". For information about SDKs, see "Software Development Kits
and Command Line Interface".
Use these API operations to manage Database Software Images:
• CreateDatabaseSoftwareImage
• ListDatabaseSoftwareImages
• GetDatabaseSoftwareImage
• DeleteDatabaseSoftwareImage
• ChangeDatabaseSoftwareImageCompartment

For the complete list of APIs, see "Database Service API".

Related Topics
• REST APIs
• Security Credentials
• Software Development Kits and Command Line Interface
• CreateDatabaseSoftwareImage
• ListDatabaseSoftwareImages
• GetDatabaseSoftwareImage
• DeleteDatabaseSoftwareImage
• ChangeDatabaseSoftwareImageCompartment
• Database Service API

6-6
7
Creating Oracle Database Homes on an
Exadata Cloud@Customer System
Learn to create Oracle Database Homes on Exadata Cloud@Customer.
• About Creating Oracle Database Homes on an Exadata Cloud@Customer System
You can add Oracle Database homes (referred to as Database Homes in
Oracle Cloud Infrastructure) to an existing VM cluster by using the Oracle Cloud
Infrastructure Console, the API, or the CLI.
• Required IAM Policy for Creating Oracle Database Homes
Review the identity access management (IAM) policy for creating Oracle Database
homes on Oracle Exadata Cloud@Customer Systems.
• Using the Console to Create Oracle Database Home on Exadata
Cloud@Customer
To create an Oracle Database home in an existing VM cluster with the Console, be
prepared to provide values for the fields required.
• Using the API to Create Oracle Database Home on Exadata Cloud@Customer
To create an Oracle Database home, review the list of API calls.

About Creating Oracle Database Homes on an Exadata

Cloud@Customer System
You can add Oracle Database homes (referred to as Database Homes in Oracle
Cloud Infrastructure) to an existing VM cluster by using the Oracle Cloud Infrastructure
Console, the API, or the CLI.
A Database Home is a directory location on the Exadata database compute nodes that
contains Oracle Database software binary files.

Note:
Avoid entering confidential information when assigning descriptions, tags,
or friendly names to your cloud resources through the Oracle Cloud
Infrastructure Console, API, or CLI.

You can also add and remove Database homes, and perform other management tasks
on a Database home by using the dbaascli utility.

Related Topics
• Using the dbaascli Utility on Exadata Cloud@Customer
Learn to use the dbaascli utility on Exadata Cloud@Customer.

7-1
 Chapter 7
Required IAM Policy for Creating Oracle Database Homes

Required IAM Policy for Creating Oracle Database Homes

Review the identity access management (IAM) policy for creating Oracle Database
homes on Oracle Exadata Cloud@Customer Systems.
A policy is an IAM document that specifies who has what type of access to your
resources. It is used in different ways:
• An individual statement written in the policy language
• A collection of statements in a single, named "policy" document, which has an
Oracle Cloud ID (OCID) assigned to it
• The overall body of policies your organization uses to control access to resources
A compartment is a collection of related resources that can be accessed only
by certain groups that have been given permission by an administrator in your
organization.
To use Oracle Cloud Infrastructure, you must be given the required type of access in
a policy written by an administrator, whether you're using the Console, or the REST
API with a software development kit (SDK), a command-line interface (CLI), or some
other tool. If you try to perform an action, and receive a message that you don’t
have permission, or are unauthorized, then confirm with your administrator the type of
access you've been granted, and which compartment you should work in.
For administrators: The policy in "Let database admins manage DB systems" lets the
specified group do everything with databases, and related database resources.
If you're new to policies, then see "Getting Started with Policies" and "Common
Policies". If you want to dig deeper into writing policies for databases, then see "Details
for the Database Service".
Related Topics
• Let database admins manage DB systems
• Getting Started with Policies
• Common Policies
• Details for the Database Service

Using the Console to Create Oracle Database Home on

Exadata Cloud@Customer
To create an Oracle Database home in an existing VM cluster with the Console, be
prepared to provide values for the fields required.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
VM Clusters is selected by default.
2. Choose your Compartment.
A list of VM Clusters is displayed for the chosen Compartment.

7-2
 Chapter 7
Using the Console to Create Oracle Database Home on Exadata Cloud@Customer

3. In the list of VM clusters, click the VM cluster on which you want to create the
Database Home.
4. Under Resources, click Database Homes.
5. Click Create Database Home.
6. In the Create Database Home dialog, enter the following:
• Database Home display name: The display name for the Database Home.
• Database image: Determines what Oracle Database version is used for the
database. You can mix database versions on the Exadata VM Cluster., but not
editions. By default, the latest Oracle-published database software image is
selected.
Click Change Database Image to use an older Oracle-published image or
a custom Database Software Image that you have created in advance, then
select an Image Type.
Oracle Provided Database Software Images: These images contain
generally available versions of Oracle Database software.
Custom Database Software Images: These images are created by your
organization and contain customized configurations of software updates and
patches. Use the Select a compartment and Select a Database version
selectors to limit the list of custom Database Software Images to a specific
compartment or Oracle Database software major release version.
After choosing a software image, click Select to return to the Create Database
Home dialog.

Note:
Oracle recommends using a custom Database Software Image not
older than N-3 from the latest.

A Database Software Image will not be available for Database Home creation
if:
– The Database Software Images was created using EXADATA_SHAPE/
VM_BM_SHAPE. Such images will not be available for Database Home
provisioning for Exadata Cloud@Customer.
– The Database Software Image is not in Available state, that is, Deleted
or is being Updated.
• Show Advanced Options
You have the option to configure advanced options.
– Tags: (Optional) You can choose to apply tags. If you have permissions to
create a resource, then you also have permissions to apply free-form tags
to that resource. To apply a defined tag, you must have permissions to use
the tag namespace. For more information about tagging, see "Resource
Tags". If you are not sure if you should apply tags, then skip this option
(you can apply tags later) or ask your administrator.
Note that after Home install, patch to the latest if the latest patch is available.
7. Click Create.

7-3
 Chapter 7
Using the API to Create Oracle Database Home on Exadata Cloud@Customer

When the Database Home creation is complete, the status changes from
Provisioning to Available.

Related Topics
• Resource Tags

Using the API to Create Oracle Database Home on Exadata

Cloud@Customer
To create an Oracle Database home, review the list of API calls.
For information about using the API and signing requests, see "REST APIs" and
"Security Credentials". For information about SDKs, see "Software Development Kits
and Command Line Interface".
To create Database Homes in Exadata Cloud@Customer, use the API operation
CreateDbHome.

For the complete list of APIs, see "Database Service API".

Related Topics
• REST APIs
• Security Credentials
• Software Development Kits and Command Line Interface
• CreateDbHome
• Database Service API

7-4
8
Managing Oracle Database Homes on
Exadata Cloud@Customer Systems
Learn to manage Oracle Database homes on Exadata Cloud@Customer.
• About Managing Oracle Database Homes on Exadata Cloud@Customer Systems
You can delete or view information about Oracle Database Homes (referred to
as Database Homes in Oracle Cloud Infrastructure) by using the Oracle Cloud
Infrastructure Console, the API, or the CLI.
• Required IAM Policy for Managing Oracle Database Homes
Review the identity access management (IAM) policy for managing Oracle
Database homes on Oracle Exadata Cloud@Customer Systems.
• Using the Console for Oracle Database Home on Exadata Cloud@Customer
Learn how to use the Console to manage Oracle Database homes.
• Differences Between Managing Resources with dbaascli and the Database API
Learn how Oracle Cloud@Customer automatically synchronizes dbaascli utility
parameters and Database Service API properties of Oracle Database instance
and Oracle Database Home.
• Using the API to Manage Oracle Database Home on Exadata Cloud@Customer
Review the list of API calls to manage Oracle Database home.

About Managing Oracle Database Homes on Exadata

Cloud@Customer Systems
You can delete or view information about Oracle Database Homes (referred to
as Database Homes in Oracle Cloud Infrastructure) by using the Oracle Cloud
Infrastructure Console, the API, or the CLI.
To find out how to delete or view information about Database Homes manually, See
"Using the dbaascli Utility on Exadata Cloud@Customer."

Note:
Avoid entering confidential information when assigning descriptions, tags,
or friendly names to your cloud resources through the Oracle Cloud
Infrastructure Console, API, or CLI.

Related Topics
• Using the dbaascli Utility on Exadata Cloud@Customer
Learn to use the dbaascli utility on Exadata Cloud@Customer.

8-1
 Chapter 8
Required IAM Policy for Managing Oracle Database Homes

Required IAM Policy for Managing Oracle Database Homes

Review the identity access management (IAM) policy for managing Oracle Database
homes on Oracle Exadata Cloud@Customer Systems.
A policy is an IAM document that specifies who has what type of access to your
resources. It is used in different ways:
• An individual statement written in the policy language
• A collection of statements in a single, named "policy" document, which has an
Oracle Cloud ID (OCID) assigned to it
• The overall body of policies your organization uses to control access to resources
A compartment is a collection of related resources that can be accessed only
by certain groups that have been given permission by an administrator in your
organization.
To use Oracle Cloud Infrastructure, you must be given the required type of access in
a policy written by an administrator, whether you're using the Console, or the REST
API with a software development kit (SDK), a command-line interface (CLI), or some
other tool. If you try to perform an action, and receive a message that you don’t
have permission, or are unauthorized, then confirm with your administrator the type of
access you've been granted, and which compartment you should work in.
For administrators: The policy in "Let database admins manage DB systems" lets the
specified group do everything with databases, and related database resources.
If you're new to policies, then see "Getting Started with Policies" and "Common
Policies". If you want to dig deeper into writing policies for databases, then see "Details
for the Database Service".
Related Topics
• Let database admins manage DB systems
• Getting Started with Policies
• Common Policies
• Details for the Database Service

Using the Console for Oracle Database Home on Exadata

Cloud@Customer
Learn how to use the Console to manage Oracle Database homes.

• Using the Console to View Information About an Oracle Database Home

To view the configuration details of an Oracle Database home, use this procedure.
• Using the Console to Delete an Oracle Database Home
To delete an Oracle Database home with the Console, use this procedure.

8-2
 Chapter 8
Using the Console for Oracle Database Home on Exadata Cloud@Customer

Using the Console to View Information About an Oracle Database

Home
To view the configuration details of an Oracle Database home, use this procedure.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
VM Clusters is selected by default.
2. Click Compartment, and select your compartment.
A list of VM Clusters is displayed for the compartment you selected.
3. In the list of VM clusters, click the VM cluster that contains the Database Home in
which you are interested.
4. Under Resources, click Database Homes.
5. In the list of Database Homes, find the Database Home you want to view, and then
click the Database Home name to display details about it.

Using the Console to Delete an Oracle Database Home

To delete an Oracle Database home with the Console, use this procedure.
You cannot delete an Oracle Database home that contains databases. Before you can
delete an Oracle Database home, you must first terminate the databases to empty
the Database Home. When you use dbaascli in the backend to move databases, the
backend is synced on the Kubernetes Control Plane side by a Sync WF running every
10 minutes continuously. You can also terminate a database by using the Console.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
VM Clusters is selected by default.
2. Select Compartment, and choose the Compartment that you want to view.
A list of VM Clusters is displayed for the chosen Compartment.
3. In the list of VM clusters, click the VM cluster that contains the Database Home
that you want to delete.
4. Under Resources, click Database Homes.
5. In the list of Database Homes, find the Database Home that you want to delete,
and click thje Database Home name to display details about it.
6. On the Database Home Details page, click Delete.
Related Topics
• Using the Console to Terminate a Database
You can terminate a database and thereby remove the terminated database from
the Cloud Control Plane.

8-3
 Chapter 8
Differences Between Managing Resources with dbaascli and the Database API

Differences Between Managing Resources with dbaascli

and the Database API
Learn how Oracle Cloud@Customer automatically synchronizes dbaascli utility
parameters and Database Service API properties of Oracle Database instance and
Oracle Database Home.
You can manage resources using host tooling such as dbaascli or dbaasapi, or
tools based on the Database service API (including the Oracle Cloud Infrastructure
Console, SDKs, and the API itself). For the management operations discussed in this
topic, if you perform them using dbaascli or dbaasapi, then the updates are not visible
in tools based on the Database Service API until the next synchronization operation,
which happens every 10 minutes.
The following table lists operations that you perform using dbaascli or dbaasapi, and
maps these operations to the related Database Service API parameters:

Operation Host Tooling Parameters Database Service API

(dbaascli / dbaasapi) Parameters
Creating Database Home name, DatabaseVersion, displayName, dbVersion,
dbHomeLocation, dbHomeLocation,
createTime timeCreated
Updating Database Home DatabaseVersion, dbVersion,
dbHomeLocation dbHomeLocation
Creating Database dbName, dbUniqueName, dbName, dbUniqueName,
pdbName, characterSet, pdbName, characterSet,
NlsCharacterSet, dbClass, ncharacterSet, dbType,
createTime timeCreated
Updating Database dbHomeId, dbUniqueName, dbHomeId, dbUniqueName,
dbClass dbType

If you terminate a Database Home using the dbaascli or dbaasapi, the status of the
Database Home is displayed as Terminated in the Database Service REST API based
tools. If you terminate a database, the status of the database is displayed as Failed.

Using the API to Manage Oracle Database Home on

Exadata Cloud@Customer
Review the list of API calls to manage Oracle Database home.
For information about using the API and signing requests, see "REST APIs" and
"Security Credentials". For information about SDKs, see "Software Development Kits
and Command Line Interface".
Use these API operations to manage Database Homes:
• ListDbHomes
• GetDbHome
• DeleteDbHome

8-4
 Chapter 8
Using the API to Manage Oracle Database Home on Exadata Cloud@Customer

For the complete list of APIs, see "Database Service API".

Related Topics
• REST APIs
• Security Credentials
• Software Development Kits and Command Line Interface
• ListDbHomes
• GetDbHome
• DeleteDbHome
• Database Service API

8-5
9
Managing Oracle Databases on Oracle
Exadata Cloud@Customer
Learn about the prerequisites, supported versions, creating and configuring Oracle
Database for use in Oracle Exadata Cloud@Customer, and other database-related
administrative tasks.

• Prerequisites and Limitations for Creating and Managing Oracle Databases on

Oracle Exadata Cloud@Customer
Review the prerequisites for creating and managing Oracle Databases on Oracle
Exadata Cloud@Customer.
• Oracle Database Releases Supported by Oracle Exadata Cloud@Customer
Learn about the versions of Oracle Database that Oracle Exadata
Cloud@Customer supports.
• About Provisioning and Configuring Oracle Databases on Oracle Exadata
Cloud@Customer
Learn about provisioning and configuring Oracle Database on Oracle Exadata
Cloud@Customer
• Required IAM Policy for Managing Oracle Databases on Oracle Exadata
Cloud@Customer
Review the identity access management (IAM) policy for managing Oracle
Database on Oracle Exadata Cloud@Customer Systems.
• Using the Console to Manage Databases on Oracle Exadata Cloud@Customer
To create or terminate a database, complete procedures using the Oracle Exadata
console.
• Using the API to Manage Oracle Database Components
Use various API features to help manage your databases on Oracle Exadata
Cloud@Customer.
• Changing the Database Passwords
To change the SYS password, or to change the TDE wallet password, use this
procedure.

Prerequisites and Limitations for Creating and Managing

Oracle Databases on Oracle Exadata Cloud@Customer
Review the prerequisites for creating and managing Oracle Databases on Oracle
Exadata Cloud@Customer.
Before you can create and use an Oracle Database on Exadata Cloud@Customer,
you must:
• Provision Exadata Cloud@Customer infrastructure
• Configure a VM cluster

9-1
 Chapter 9
Oracle Database Releases Supported by Oracle Exadata Cloud@Customer

• Create any required backup destinations

You can create one or more databases on each Oracle Exadata Cloud@Customer
system. Other than the storage and processing limits of your Oracle Exadata system,
there is no maximum for the number of databases that you can create. By default,
databases on Exadata Cloud@Customer use Oracle Database Enterprise Edition
- Extreme Performance. This edition provides all the features of Oracle Database
Enterprise Edition, plus all of the database enterprise management packs, and all of
the Enterprise Edition options, such as Oracle Database In-Memory, and Oracle Real
Application Clusters (Oracle RAC). If you use your own Oracle Database licenses,
then your ability to use various features is limited by your license holdings.

Oracle Database Releases Supported by Oracle Exadata

Cloud@Customer
Learn about the versions of Oracle Database that Oracle Exadata Cloud@Customer
supports.
Exadata Cloud@Customer supports the following Oracle Database software releases:
• Oracle Database 19c
• Oracle Database 18c
• Oracle Database 12c Release 2
• Oracle Database 12c Release 1
• Oracle Database 11g Release 2
For Oracle Database release and software support timelines, see Release Schedule of
Current Database Releases (Doc ID 742060.1) in the My Oracle Support portal.
Related Topics
• https://support.oracle.com/epmos/faces/DocContentDisplay?id=742060.1

About Provisioning and Configuring Oracle Databases on

Oracle Exadata Cloud@Customer
Learn about provisioning and configuring Oracle Database on Oracle Exadata
Cloud@Customer
Each Oracle Database is configured as follows:
• When you provision a database, you can associate it with a backup destination,
and enable automatic backups.
• When a database is provisioned an archivelog maintenance job is added to the
crontab for the database.
– If the database is not enabled for backups, then the archivelog job will
maintain FRA space by deleting Archive Redo Logs older than 24 hours.
– If the database is enabled for backups, then the archivelog job will backup
archivelogs that have not been backed up. Once an archived log is backed up,
it will be purged when older than 24 hours.

9-2
 Chapter 9
Required IAM Policy for Managing Oracle Databases on Oracle Exadata Cloud@Customer

• Each database is configured with Oracle Real Application Clusters (Oracle RAC)
database instances running on every node in the virtual machine (VM) cluster.
• Each database uses a separate set of Oracle binaries in a separate Oracle home
location.
• Each database is configured with default instance parameter settings. While the
defaults are reasonable for many cases, you should review the instance parameter
settings to ensure that they meet your specific application needs.
In particular, review the Oracle Database system global area (SGA) and program
global area (PGA) instance parameter settings, especially if your VM cluster
supports multiple databases. Also, ensure that the sum of all Oracle Database
memory allocations never exceeds the available physical memory on each
compute node.
• Each database using Oracle Database 12c Release 1 or a later release is
configured as a container database (CDB). One pluggable database (PDB) is
created inside the CDB. By default:
– The first PDB is configured with a local PDB administration user account,
named PDBADMIN.
– The PDBADMIN user account is initially configured with the same administration
password as the CDB SYS and SYSTEM users.
– The PDBADMIN user account is initially configured with basic privileges
assigned through two roles; CONNECT and PDB_DBA. However, for most practical
administrative purposes you must assign extra privileges to the PDBADMIN user
account, or to the PDB_DBA role.
You can use native Oracle Database facilities to create extra PDBs, and to
manage all of your PDBs. The dbaascli utility also provides a range of convenient
PDB management functions.

Note:
Avoid entering confidential information when assigning descriptions, tags,
or friendly names to your cloud resources through the Oracle Cloud
Infrastructure Console, API, or CLI.

Required IAM Policy for Managing Oracle Databases on

Oracle Exadata Cloud@Customer
Review the identity access management (IAM) policy for managing Oracle Database
on Oracle Exadata Cloud@Customer Systems.
A policy is an IAM document that specifies who has what type of access to your
resources. It is used in different ways:
• An individual statement written in the policy language
• A collection of statements in a single, named "policy" document, which has an
Oracle Cloud ID (OCID) assigned to it
• The overall body of policies your organization uses to control access to resources

9-3
 Chapter 9
Using the Console to Manage Databases on Oracle Exadata Cloud@Customer

A compartment is a collection of related resources that can be accessed only

by certain groups that have been given permission by an administrator in your
organization.
To use Oracle Cloud Infrastructure, you must be given the required type of access in
a policy written by an administrator, whether you're using the Console, or the REST
API with a software development kit (SDK), a command-line interface (CLI), or some
other tool. If you try to perform an action, and receive a message that you don’t
have permission, or are unauthorized, then confirm with your administrator the type of
access you've been granted, and which compartment you should work in.
For administrators: The policy in "Let database admins manage DB systems" lets the
specified group do everything with databases, and related database resources.
If you're new to policies, then see "Getting Started with Policies" and "Common
Policies". If you want to dig deeper into writing policies for databases, then see "Details
for the Database Service".
Related Topics
• Let database admins manage DB systems
• Getting Started with Policies
• Common Policies
• Details for the Database Service

Using the Console to Manage Databases on Oracle Exadata

Cloud@Customer
To create or terminate a database, complete procedures using the Oracle Exadata
console.

• Using the Console to Create a Database

To create an Oracle Database with the console, use this procedure.
• Using the Console to Move a Database to Another Database Home
Learn to move a database to another Database Home.
• Using the Console to Terminate a Database
You can terminate a database and thereby remove the terminated database from
the Cloud Control Plane.

Using the Console to Create a Database

To create an Oracle Database with the console, use this procedure.
1. Open the navigation menu Under Oracle Databases, and click Exadata
Cloud@Customer.
VM Clusters is selected by default.
2. Choose your Compartment.
A list of VM Clusters is displayed for the chosen Compartment.
3. Click the name of a VM cluster where you want to create the database.
In the VM Cluster Details page, under Resources, Databases is selected by
default.

9-4
 Chapter 9
Using the Console to Manage Databases on Oracle Exadata Cloud@Customer

4. Click Create Database.

(or)
• Open the navigation menu. Under Database, click Exadata
Cloud@Customer.
VM Clusters is selected by default.
• Choose your Compartment.
A list of VM Clusters is displayed for the chosen Compartment.
• Click the name of a VM cluster where you want to create the database.
In the VM Cluster Details page, under Resources, Databases is selected by
default.
• Click Database Homes.
• Click the name of the Database Home where you want to create the database.
• Click Create Database.
5. Provide the requested information in the Create Database page:
• Provide the database name: Specify a user-friendly name that you can use
to identify the database. The name doesn't need to be unique because an
Oracle Cloud Identifier (OCID) uniquely identifies the database.
• Provide a unique name for the database: Optionally specify a unique name
for the database. This attribute defines the value of the DB_UNIQUE_NAME
database parameter. The value is case insensitive, it can be up to 30
characters in length, and include alphanumeric characters, underscore (_),
number sign (#), and dollar sign ($).
If you plan to configure the database for backup to a Recovery Appliance
backup destination, then the unique database name must match the name that
is configured in the Recovery Appliance.
• Select a database version: From the list, choose the Oracle Database
software release that you want to deploy.
• Database Home: Select an existing Database Home or create one as
applicable. Note that this field is not available when you create a Database
from the Database Home details page.
– Select an existing Database Home: If one or more Database Homes
already exist for the database version you have selected, then this option
is selected by default. And, you will be presented with a list of Database
Homes. Select a Database Home from the list.
– Create a new Database Home: If no Database Homes exist for the
database version you have selected, then this option is selected by
default.
• Provide the name of the first PDB: (Optional) Specify the name for the first
PDB. A PDB is created with the database.
To avoid potential service name collisions when using Oracle Net Services to
connect to the PDB, ensure that the PDB name is unique across the entire
VM cluster. If you do not provide the name of the first PDB, then a system-
generated name is used.
• Provide the administration password: Provide and confirm the Oracle
Database administration password. This password is used for administration
accounts and functions in the database, including:

9-5
 Chapter 9
Using the Console to Manage Databases on Oracle Exadata Cloud@Customer

– The password for the Oracle Database SYS and SYSTEMusers.

– The Transparent Data Encryption (TDE) keystore password.
For Oracle Database 12c Release 1 or later releases, the password for
the PDB administration user in the first PDB (PDBADMIN).must be nine to 30
characters, and contain at least two uppercase, two lowercase, two numeric,
and two special characters. The special characters must be _, #, or -. In
addition, the password must not contain the name of the tenancy or any
reserved words, such as Oracle or Table, regardless of casing.
• Choose the database workload type: Select the workload type that best
suits your application from one of the following options:
– Transactional Processing: Select this option to configure the database
for a transactional workload, with a bias toward high volumes of random
data access.
– Data Warehouse: Select this option to configure the database for a
decision support or data warehouse workload, with a bias toward large
data scanning operations.
• Backup Destination Type: Select a backup destination for the database.
From the list, choose an option:
– None: Select to not define a backup configuration for the database.
– Local: Select to store backups locally in the Oracle Exadata Storage
Servers on your Oracle Exadata Cloud@Customer system.
This option is available only if you enabled backups on local Oracle
Exadata storage in the VM cluster that you want to host the database.
– Object Storage: Select to store backups in an Oracle-managed object
storage container on Oracle Cloud Infrastructure.
To use this option, your Oracle Exadata Cloud@Customer system must
have egress connectivity to Oracle Cloud Infrastructure Object Storage.
– NFS: Select to store backups in one of your previously defined backup
destinations that uses Network File System (NFS) storage. For more
information, refer to the information about backup destinations in this
publication.
If you select this option, then you must also choose from the list of NFS
Backup Destinations.
– Recovery Appliance: Select to store backups in one of your previously
defined backup destinations that uses Oracle Zero Data Loss Recovery
Appliance. Refer to the information about backup destination options in
this document.
If you select Oracle Zero Data Loss Recovery Appliance as your backup
option, then you must also:
* Choose from the list of appliance Backup Destinations.
* Choose from the VPC User list, which contains the list of virtual
private catalog (VPC) user names that are defined in the Oracle Zero
Data Loss Recovery Appliance backup destination.
* Provide the Password for the VPC user.

9-6
 Chapter 9
Using the Console to Manage Databases on Oracle Exadata Cloud@Customer

Note:
If you select a backup destination, then you cannot change a
backup location after the database is created. However, if you
select None now, then you can select a backup destination after
the database is created.

– Enable automatic backups: Select this option to enable daily backups

using the policy for automatic backups.
This option is only enabled when you select a Backup Destination Type
other than None. You can change this setting after database creation.
• (Optional) Select Show Advanced Options. From this window, you can select
the following options:
– Backup retention period: From the list, you can choose the length of
time that you want automatic backups to be retained.
For backups to local Exadata storage, you can choose a retention period
of 7 days or 14 days. The default retention period is 7 days.
For backups to Oracle Cloud Infrastructure Object Storage, or to an NFS
backup destination, you can choose one of the following preset retention
periods: 7 days, 14 days, 30 days, 45 days, or 60 days. The default
retention period is 30 days.
This option does not apply to Oracle Zero Data Loss Recovery Appliance
backup destinations. For backups to Oracle Zero Data Loss Recovery
Appliance, the retention policy that is implemented in the appliance
controls the retention period.
– Character set: The character set for the database. The default is
AL32UTF8.
– National character set: The national character set for the database. The
default is AL16UTF16.
– Tags: (Optional) You can choose to apply tags. If you have permissions
to create a resource, you also have permissions to apply free-form tags
to that resource. To apply a defined tag, you must have permissions
to use the tag namespace. For more information about tagging, refer
to information about resource tags.If you are not sure if you should
apply tags, then skip this option (you can apply tags later), or ask your
administrator.
6. Click Create Database.
Related Topics
• Resource Tags
• Managing Backup Destinations for Exadata Cloud@Customer
Learn to manage backup destinations for Exadata Cloud@Customer on Oracle
Zero Data Loss Recovery Appliance or Network File System (NFS).

Using the Console to Move a Database to Another Database Home

Learn to move a database to another Database Home.

9-7
 Chapter 9
Using the API to Manage Oracle Database Components

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
VM Clusters is selected by default.
2. Choose your Compartment that contains the VM cluster that hosts the database
that you want to terminate.
3. Click the name of the VM cluster that contains the database that you want to
terminate.
4. In the Resources list of the VM Cluster Details page, click Databases.
5. Click the name of the database that you want to terminate.
The Database Details page displays information about the selected database.
6. Click Move Database.
7. In the resulting dialog, select the target Database Home.
8. Click Move Database.
The database will be stopped in the current home and then restarted in the destination
home. While the database is being moved, the Database Home status displays as
Moving Database. When the operation completes, Database Home is updated with
the current home. If the operation is unsuccessful, the status of the database displays
as Failed, and the Database Home field provides information about the reason for the
failure.

Using the Console to Terminate a Database

You can terminate a database and thereby remove the terminated database from the
Cloud Control Plane.
Terminating a database removes it from the Cloud Control Plane. In the process, all of
the associated data files and backups are destroyed.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
VM Clusters is selected by default.
2. Choose your Compartment that contains the VM cluster that hosts the database
that you want to terminate.
3. Click the name of the VM cluster that contains the database that you want to
terminate.
4. In the Resources list of the VM Cluster Details page, click Databases.
5. Click the name of the database that you want to terminate.
The Database Details page displays information about the selected database.
6. Click Terminate.
7. In the resulting dialog, enter the name of the database, and then click Terminate
Database to confirm the action.

Using the API to Manage Oracle Database Components

Use various API features to help manage your databases on Oracle Exadata
Cloud@Customer.

9-8
 Chapter 9
Using the API to Manage Oracle Database Components

For information about using the API and signing requests, see "REST APIs" and
"Security Credentials". For information about SDKs, see "Software Development Kits
and Command Line Interface".
Use the following API operations to manage various database components.
Database homes:
• CreateDbHome
• DeleteDbHome
• GetDbHome
• ListDbHomes
Databases:
• CreateDatabase
• GetDatabase
• ListDatabases
• UpdateDatabase
• UpdateDatabaseDetails
Nodes:
• GetDbNode
• List DbNodes
Use UpdateDatabase to move a database to a different Database Home, thereby
updating the database to the same version as the target Database Home.
For the complete list of APIs, see "Database Service API".
Related Topics
• REST APIs
• Security Credentials
• Software Development Kits and Command Line Interface
• CreateDbHome
• DeleteDbHome
• GetDbHome
• ListDbHomes
• CreateDatabase
• GetDatabase
• ListDatabases
• UpdateDatabase
• UpdateDatabaseDetails
• GetDbNode
• List DbNodes
• Database Service API

9-9
 Chapter 9
Changing the Database Passwords

Changing the Database Passwords

To change the SYS password, or to change the TDE wallet password, use this
procedure.
The password that you specify in the Database Admin Password field when you
create a new Exadata Cloud@Customer instance or database is set as the password
for the SYS, SYSTEM, TDE wallet, and PDB administrator credentials. Use the
following procedures if you need to change passwords for an existing database.

Note:
if you are enabling Data Guard for a database, then the SYS password and
the TDE wallet password of the primary and standby databases must all be
the same.

Note:
Using the dbaascli to change the SYS password will ensure the backup/
restore automation can parallelize channels across all nodes in the cluster.

To change the SYS password for an Exadata Cloud@Customer Service database

1. Log onto the cloud VM cluster or DB system host as opc.
2. Run the following command:

sudo dbaascli database changepassword --dbname database_name

To change the TDE wallet password for an Exadata Cloud@Customer Service

database
1. Log onto the cloud VM cluster or DB system host as opc.
2. Run the following command:

sudo dbaascli tde changepassword --dbname database_name

9-10
10
Using Oracle Data Guard with Exadata
Cloud@Customer
Learn to configure and manage Data Guard associations in your VM cluster.
• About Using Oracle Data Guard with Exadata Cloud@Customer
This topic explains how to use the Console or the API to manage Data Guard
associations in your VM cluster.
• Required IAM Policy for Managing Oracle Data Guard Associations on Oracle
Exadata Cloud@Customer
Review the identity access management (IAM) policy for managing Oracle Data
Guard associations on Oracle Exadata Cloud@Customer Systems.
• Prerequisites for Using Oracle Data Guard with Exadata Cloud@Customer
Review the list of prerequisites for using Data Guard with Exadata
Cloud@Customer.
• Working with Data Guard
Oracle Data Guard ensures high availability, data protection, and disaster recovery
for enterprise data.
• Using the Console to Manage Oracle Data Guard Associations
Learn how to enable a Data Guard association between databases, change the
role of a database in a Data Guard association using either a switchover or a
failover operation, and reinstate a failed database.
• Using the API to Manage Data Guard Associations on an Exadata
Cloud@Customer System
Learn how to use the API to manage Data Guard associations on an Exadata
Cloud@Customer system.

About Using Oracle Data Guard with Exadata

Cloud@Customer
This topic explains how to use the Console or the API to manage Data Guard
associations in your VM cluster.
When you use the Console or the API to enable Data Guard for an Exadata database
compute node database:
• The standby database is a physical standby.
• The peer databases (primary and standby) are in the same compartment and the
database versions are identical.
• You are limited to one standby database for each primary database.
• The standby database is deployed as an open, read-only database (Active Data
Guard).

10-1
 Chapter 10
Required IAM Policy for Managing Oracle Data Guard Associations on Oracle Exadata Cloud@Customer

To configure a Data Guard system across regions or between on-premises and

Exadata database compute nodes, or to configure your database with multiple
standbys, you must access the database host directly and set up Data Guard
manually.
For complete information on Oracle Data Guard, see the Data Guard Concepts and
Administration documentation on the Oracle Document Portal.
Related Topics
• Data Guard Concepts and Administration
• Oracle Document Portal

Required IAM Policy for Managing Oracle Data Guard

Associations on Oracle Exadata Cloud@Customer
Review the identity access management (IAM) policy for managing Oracle Data Guard
associations on Oracle Exadata Cloud@Customer Systems.
A policy is an IAM document that specifies who has what type of access to your
resources. It is used in different ways:
• An individual statement written in the policy language
• A collection of statements in a single, named "policy" document, which has an
Oracle Cloud ID (OCID) assigned to it
• The overall body of policies your organization uses to control access to resources
A compartment is a collection of related resources that can be accessed only
by certain groups that have been given permission by an administrator in your
organization.
To use Oracle Cloud Infrastructure, you must be given the required type of access in
a policy written by an administrator, whether you're using the Console, or the REST
API with a software development kit (SDK), a command-line interface (CLI), or some
other tool. If you try to perform an action, and receive a message that you don’t
have permission, or are unauthorized, then confirm with your administrator the type of
access you've been granted, and which compartment you should work in.
For administrators: The policy in "Let database admins manage DB systems" lets the
specified group do everything with databases, and related database resources.
If you're new to policies, then see "Getting Started with Policies" and "Common
Policies". If you want to dig deeper into writing policies for databases, then see "Details
for the Database Service".
Related Topics
• Let database admins manage DB systems
• Getting Started with Policies
• Common Policies
• Details for the Database Service

10-2
 Chapter 10
Prerequisites for Using Oracle Data Guard with Exadata Cloud@Customer

Prerequisites for Using Oracle Data Guard with Exadata

Cloud@Customer
Review the list of prerequisites for using Data Guard with Exadata Cloud@Customer.
• Compute Nodes
A VM cluster Data Guard implementation requires two Exadata database compute
nodes, one containing the primary database and one containing the standby
database.
• Password
For Data Guard operations to work, the SYS password and the TDE wallet
password of the primary and standby databases must all be the same.

Compute Nodes
A VM cluster Data Guard implementation requires two Exadata database compute
nodes, one containing the primary database and one containing the standby database.
When you enable Data Guard for an Exadata database compute node database, the
Exadata database compute node with the database to be used as the standby must
already exist before you enable Data Guard.

Password
For Data Guard operations to work, the SYS password and the TDE wallet password of
the primary and standby databases must all be the same.
If you change any one of these passwords, you must update the rest of the passwords
to match.
If you make any change to the TDE wallet (such as adding a master key for a new
PDB or changing the wallet password), you must copy the wallet from the primary
to the standby so that Data Guard can continue to operate. For Oracle Database
versions earlier than 12.2, if you change the SYS password on one of the peers, you
need to manually sync the password file between the DB systems.

Working with Data Guard

Oracle Data Guard ensures high availability, data protection, and disaster recovery for
enterprise data.
The Data Guard implementation requires two databases, one in a primary role and
one in a standby role. The two databases compose a Data Guard association.
Most of your applications access the primary database. The standby database is a
transactionally consistent copy of the primary database.
Data Guard maintains the standby database by transmitting and applying redo data
from the primary database. If the primary database becomes unavailable, you can use
Data Guard to switch or fail over the standby database to the primary role.
• Switchover
A switchover reverses the primary and standby database roles.

10-3
 Chapter 10
Using the Console to Manage Oracle Data Guard Associations

• Failover
A failover transitions the standby database into the primary role after the existing
primary database fails or becomes unreachable.
• Reinstate
Reinstates a database into the standby role in a Data Guard association.

Switchover
A switchover reverses the primary and standby database roles.
Each database continues to participate in the Data Guard association in its new role.
A switchover ensures no data loss. You can use a switchover before you perform
planned maintenance on the primary database. Performing planned maintenance on
a Exadata database compute node with a Data Guard association is typically done by
switching the primary to the standby role, performing maintenance on the standby, and
then switching it back to the primary role.

Failover
A failover transitions the standby database into the primary role after the existing
primary database fails or becomes unreachable.
A failover might result in some data loss when you use Maximum Performance
protection mode.

Reinstate
Reinstates a database into the standby role in a Data Guard association.
You can use the reinstate command to return a failed database into service after
correcting the cause of failure.

Note:
You can't terminate a primary database that has a Data Guard association
with a peer (standby) database. Delete the standby database first.
Alternatively, you can switch over the primary database to the standby role,
and then terminate it.
You can't terminate a VM cluster that includes Data Guard enabled
databases. You must first remove the Data Guard association by terminating
the standby database.

Using the Console to Manage Oracle Data Guard

Associations
Learn how to enable a Data Guard association between databases, change the role
of a database in a Data Guard association using either a switchover or a failover
operation, and reinstate a failed database.

10-4
 Chapter 10
Using the Console to Manage Oracle Data Guard Associations

When you enable Data Guard, a separate Data Guard association is created for the
primary and the standby database.
• Using the Console to Enable Data Guard on an Exadata Cloud@Customer
System
Learn to enable Data Guard association between databases.
• Using the Console To Perform a Database Switchover
You initiate a switchover operation by using the Data Guard association of the
primary database.
• Using the Console To Perform a Database Failover
You initiate a failover operation by using the Data Guard association of the standby
database.
• Using the Console To Reinstate a Database
After you fail over a primary database to its standby, the standby assumes the
primary role and the old primary is identified as a disabled standby.
• Using the Console To Terminate a Data Guard Association on an Exadata
Cloud@Customer System
On a VM cluster, you remove a Data Guard association by terminating the standby
database.

Using the Console to Enable Data Guard on an Exadata

Cloud@Customer System
Learn to enable Data Guard association between databases.

Note:
When you enable Data Guard, replication of data happens only over the
client network.

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
VM Clusters is selected by default.
2. Choose your Compartment.
A list of VM Clusters is displayed for the chosen Compartment.
3. In the list of VM clusters, click the VM cluster that contains the database for which
you want to assume the primary role, and then click the name of that database.
4. Under Resources, click Data Guard Associations.
5. Click Enable Data Guard.
6. On the Enable Data Guard page, configure your Data Guard association.
• Data Guard association details:
– Protection mode: The protection mode used for this Data Guard
association.
Maximum Performance provides the highest level of data protection that is
possible without affecting the performance of a primary database.

10-5
 Chapter 10
Using the Console to Manage Oracle Data Guard Associations

Maximum Availability provides highest level of protection of data without

compromising availability of database.
– Transport type: The redo transport type used for this Data Guard
association.
The redo transport type used for this Data Guard association.
Async - Asynchronous transport mode used with Maximum Performance
protection mode.
Sync - Synchronous transport mode used with Maximum Performance
and Maximum Availability protection mode.
• Select peer VM cluster: Specify the following values for the standby:
– Peer Region: Currently, the peer region is auto-populated and you cannot
change it. The primary and secondary databases could be running on
two different VM clusters on a shared Exadata Cloud@Customer system,
or on two geographically separated Exadata Cloud@Customer systems
managed from a single Oracle Cloud Infrastructure region.
– Peer Exadata: Select the Exadata Cloud@Customer infrastructure where
the standby database is located. Click the CHANGE COMPARTMENT
hyperlink to choose a compartment.
– Peer VM Cluster: Select the Exadata database compute node that
contains the standby database. Click the CHANGE COMPARTMENT
hyperlink to choose a compartment.
• Configure standby database: Enter the database admin password of the
primary database in the Database password field. This same database admin
password will be used for the standby database.
The admin password and the TDE password must be the same. If they are
not, follow the instructions in Changing the Database Passwords to align them.
7. Click Enable Data Guard.
When the association is created, the details for a database and its peer display their
respective roles as Primary or Standby.
Related Topics
• Network Requirements for Oracle Exadata Cloud@Customer
To provide secure and reliable network connectivity for different application and
management functions, Exadata Cloud@Customer uses different networks.

Using the Console To Perform a Database Switchover

You initiate a switchover operation by using the Data Guard association of the primary
database.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
VM Clusters is selected by default.
2. Choose your Compartment.
A list of VM Clusters is displayed for the chosen Compartment.
3. In the list of VM clusters, click the VM cluster that contains the primary database
you want to switch over.

10-6
 Chapter 10
Using the Console to Manage Oracle Data Guard Associations

4. Click the name of the primary database.

5. Under Resources, click Data Guard Associations.
6. For the Data Guard association on which you want to perform a switchover, click
the Actions icon (three dots), and then click Switchover.
7. In the Switchover Database dialog box, enter the database admin password, and
then click OK.
This database should now assume the role of the standby, and the standby should
assume the role of the primary in the Data Guard association.

Using the Console To Perform a Database Failover

You initiate a failover operation by using the Data Guard association of the standby
database.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
VM Clusters is selected by default.
2. Choose your Compartment.
A list of VM Clusters is displayed for the chosen Compartment.
3. In the list of VM clusters, click the VM cluster that contains the primary database's
peer standby you want to fail over to.
4. Click the name of the standby database.
5. Under Resources, click Data Guard Associations.
6. For the Data Guard association on which you want to perform a failover, click the
Actions icon (three dots), and then click Failover.
7. In the Failover Database dialog box, enter the database admin password, and
then click OK.
This database should now assume the role of the primary, and the old primary's role
should display as Disabled Standby.

Using the Console To Reinstate a Database

After you fail over a primary database to its standby, the standby assumes the primary
role and the old primary is identified as a disabled standby.
After you correct the cause of failure, you can reinstate the failed database as a
functioning standby for the current primary by using its Data Guard association.
Before you can reinstate a version 12.2 or later database, you must perform some
steps on the database host to stop the database or start it in MOUNT mode.

Set your ORACLE_UNQNAME environment variable to the value of the Database Unique
Name, and then run these commands:

srvctl stop database -d db-unique-name -o abort

srvctl start database -d db-unique-name -o mount

10-7
 Chapter 10
Using the API to Manage Data Guard Associations on an Exadata Cloud@Customer System

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
VM Clusters is selected by default.
2. Choose your Compartment.
A list of VM Clusters is displayed for the chosen Compartment.
3. In the list of VM clusters, click the VM cluster that contains the primary database.
4. Click the name of the primary database.
5. Under Resources, click Data Guard Associations.
You will see the database you want to reinstate listed.
6. Click the Actions icon (three dots), and then click Reinstate.
7. In the Reinstate Database dialog box, enter the database admin password, and
then click OK.
This database should now be reinstated as the standby in the Data Guard association.

Using the Console To Terminate a Data Guard Association on an

Exadata Cloud@Customer System
On a VM cluster, you remove a Data Guard association by terminating the standby
database.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
VM Clusters is selected by default.
2. Choose your Compartment.
A list of VM Clusters is displayed for the chosen Compartment.
3. In the list of VM clusters, click the VM cluster that contains the standby database
you want to terminate.
4. Click the name of the standby database.
5. For the standby database you want to terminate, click the Actions icon (three
dots), and then click Terminate.
6. In the Terminate Database dialog box, enter the name of the database, and then
click OK.

Using the API to Manage Data Guard Associations on an

Exadata Cloud@Customer System
Learn how to use the API to manage Data Guard associations on an Exadata
Cloud@Customer system.
For information about using the API and signing requests, see REST APIs and
Security Credentials. For information about SDKs, see Software Development Kits and
Command Line Interface.
The following table lists the REST API endpoints to manage Data Guard associations.

10-8
 Chapter 10
Using the API to Manage Data Guard Associations on an Exadata Cloud@Customer System

Operation REST API Endpoint

Create a Data Guard association. CreateDataGuardAssociation
View details of the specified Data Guard GetDataGuardAssociation
association's configuration information.
View the list of all Data Guard associations for ListDataGuardAssociations
the specified database.
Perform a switchover to transition a primary SwitchoverDataGuardAssociation
database of a Data Guard association into
standby role.
Perform a failover to transition a standby FailoverDataGuardAssociation
database identified by the databaseId
parameter into the specified Data Guard
association's primary role after the existing
primary database fails or becomes
unreachable.
Reinstate a database identified by the ReinstateDataGuardAssociation
databaseId parameter into standby role in a For more information, see Using the Console
Data Guard association. To Reinstate a Database.
Delete a standby database. DeleteDatabase

For the complete list of APIs, see Database Service API.

10-9
11
Managing Database Backup and Recovery
on Oracle Exadata Cloud@Customer
Learn how to work with the backup and recovery facilities provided by Oracle Exadata
Cloud@Customer.

• About Managing Backup Destinations for Oracle Exadata Cloud@Customer

Learn how configure backup when creating the database on Oracle Exadata
Cloud@Customer.
• Required IAM Policy for Backup and Recovery
Review the identity access management (IAM) policy for backup and recovery on
Oracle Exadata Cloud@Customer Systems.
• Using the Console to Manage Backup and Recovery
Learn how to use the console to view a list of available backups, edit backup
settings, and restore a database for Oracle Exadata Cloud@Customer.
• Using the API to Manage Database Backup and Recovery
Learn how to use the API to manage database backup and recovery with Oracle
Exadata Cloud@Customer.
• Customizing the Automatic Backup Configuration
You can customize many of the characteristics of the automatic backup
configuration.
• Creating an On-Demand Backup by Using the bkup_api Utility
You can use the bkup_api utility to create an on-demand backup of a complete
database or an individual pluggable database (PDB):
• Recovering a Database Using Oracle Recovery Manager (RMAN)

About Managing Backup Destinations for Oracle Exadata

Cloud@Customer
Learn how configure backup when creating the database on Oracle Exadata
Cloud@Customer.
Oracle Exadata Cloud@Customer provides automatic database backup facilities
that use Oracle Recovery Manager (RMAN). When you create a database on
Oracle Exadata Cloud@Customer, you can specify a backup destination and enable
automatic backups. For more information, refer to the information in this publication
about managing backup destinations for Oracle Exadata Cloud@Customer.
After database creation, you can also:
• View a list of available backups.
• Enable or disable automatic backups.
• Edit backup settings.

11-1
 Chapter 11
About Managing Backup Destinations for Oracle Exadata Cloud@Customer

• Restore a database.
You can perform these operations by using either the Console, or the API.
Automatic database backups are configured as follows:
• Automatic backups are scheduled daily. The automatic backup process can run at
any time within the daily backup window, which is between midnight and 6:00 AM
in the time zone of the virtual machine (VM) cluster that hosts the database.
• Automatic backups use a combination of full (RMAN level 0) and incremental
(RMAN level 1) database backups:
– For backups to a Zero Data Loss Recovery Appliance, after an initial full
backup is performed, Zero Data Loss Recovery Appliance creates and
validates virtual full backups from each daily incremental backup.
– For backups to NFS, or OSS, the default interval between level 0 backups is
seven days. The default level 0 day is Sunday.
– For backups to Local Exadata Storage:
The retention period option for Local Exadata Storage is 7 or 14 days.
Regardless of the retention window selected for backups to Local Exadata
Storage, incremental level 1 backups are always performed after the initial
level 0 image copy is taken. Also, the incremental level 1 backups are merged
into the level 0 image copy backup when they become older than the retention
period.
For example: A 14 day for Local retention window includes one "merged" level
0 , 14 incremental level 1's plus archivelogs for the 14 days.
• The retention period defines the period for which automatic backups are
maintained:
– For backups to Zero Data Loss Recovery Appliance, the retention policy that is
implemented in the appliance controls the retention period.
– For backups to local Exadata storage, you can choose a retention period of 7
days, or 14 days. The default retention period is 7 days.
– For backups to Oracle Cloud Infrastructure Object Storage, or to an NFS
backup destination, you can choose one of the following preset retention
periods: 7 days, 14 days, 30 days, 45 days, or 60 days. The default retention
period is 30 days.
• By default, Oracle Database runs in ARCHIVELOG mode, and archived redo log files
are backed up every 30 minutes. .
• Regardless of the backup destination, backups of user data are encrypted by
default.
While a backup is in progress, Oracle recommends that you avoid performing actions
that could interfere with availability, such as restarting compute nodes, or applying
patches. If an automatic backup operation fails, then the backup is deferred until the
next day’s backup window.
When required, you can restore Oracle Database to:
• The latest available restore point.
• A specific point in time by providing a time stamp.
• An Oracle Database System Change Number (SCN).

11-2
 Chapter 11
Required IAM Policy for Backup and Recovery

Note:
The backup and recovery facilities described in this topic cater only for
database backup and recovery, which includes Oracle Database data files,
log files, control files, and the server parameter (SP) file. You are responsible
for backing up other files on your compute nodes. In particular, Oracle
strongly recommends that you back up the Transparent Data Encryption
(TDE) keystore (wallet). Without the TDE keystore, the Oracle Database
backups are effectively useless, because you cannot read the data contained
in the backup.

Note:
If TAG based recovery fails with error ORA-01152, then use Recovery
Manager (RMAN) directly to complete the recovery.
If the server parameter file (SPFILE) recovery fails for local configuration
using dbaascli, then use Recovery Manager (RMAN) directly to complete
the recovery.

Required IAM Policy for Backup and Recovery

Review the identity access management (IAM) policy for backup and recovery on
Oracle Exadata Cloud@Customer Systems.
A policy is an IAM document that specifies who has what type of access to your
resources. It is used in different ways:
• An individual statement written in the policy language
• A collection of statements in a single, named "policy" document, which has an
Oracle Cloud ID (OCID) assigned to it
• The overall body of policies your organization uses to control access to resources
A compartment is a collection of related resources that can be accessed only
by certain groups that have been given permission by an administrator in your
organization.
To use Oracle Cloud Infrastructure, you must be given the required type of access in
a policy written by an administrator, whether you're using the Console, or the REST
API with a software development kit (SDK), a command-line interface (CLI), or some
other tool. If you try to perform an action, and receive a message that you don’t
have permission, or are unauthorized, then confirm with your administrator the type of
access you've been granted, and which compartment you should work in.
For administrators: The policy in "Let database admins manage DB systems" lets the
specified group do everything with databases, and related database resources.
If you're new to policies, then see "Getting Started with Policies" and "Common
Policies". If you want to dig deeper into writing policies for databases, then see "Details
for the Database Service".

11-3
 Chapter 11
Using the Console to Manage Backup and Recovery

Related Topics
• Getting Started with Policies
• Common Policies

Using the Console to Manage Backup and Recovery

Learn how to use the console to view a list of available backups, edit backup settings,
and restore a database for Oracle Exadata Cloud@Customer.

• Viewing a List of Available Backups with the Console

To view a list of available backups with Oracle Exadata Cloud@Customer,
complete this procedure.
• Editing Backup Settings with the Console
To edit backup destinations, change backup schedules and other backup
administration, you can use with the Oracle Exadata Cloud@Customer console.
• Restoring a Database with the Console
To restore a database to a point in time, to a system change number (SCN), or to
the latest backup, use the Exadata Cloud@Customer Console.

Viewing a List of Available Backups with the Console

To view a list of available backups with Oracle Exadata Cloud@Customer, complete
this procedure.

Note:
Only the managed backups are synced to the Console. If you configure
backups directly in the backend, then they are not synced to the Console.
This is an expected behavior and Oracle has no plans to change this
behavior.

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
2. Choose the Region and Compartment that contains the VM cluster that hosts the
database in which you are interested.
3. Click VM Clusters.
4. Click the name of the VM cluster that hosts the database in which you are
interested.
5. In the Resources list of the VM Cluster Details page, click Databases.
6. Click the name of the database in which you are interested.
The Database Details page displays information about the selected database,
which includes a list of the available backups.

11-4
 Chapter 11
Using the Console to Manage Backup and Recovery

Editing Backup Settings with the Console

To edit backup destinations, change backup schedules and other backup
administration, you can use with the Oracle Exadata Cloud@Customer console.
Use this procedure to change the available backup settings:
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that contains the VM cluster that hosts the
database for which you want to edit backup settings.
3. Click VM Clusters.
4. Click the name of the VM cluster that hosts the database for which you want to
edit backup settings.
5. In the Resources list of the VM Cluster Details page, click Databases.
6. Click the name of the database for which you want to edit backup settings.
The Database Details page displays information about the selected database.
7. Click Edit Backup Settings.
8. Your current backup configuration determines the changes that you can make in
the Backup Settings dialog, as follows:
• If automatic backups are not configured (Backup Destination Type is set
to None), then you can use the following settings to define the backup
configuration for the database:
– Backup Destination Type: From the list, choose an option.
* None Select if you do not define a backup configuration for the
database.
* Local Select to store backups locally in the Exadata Storage Servers
on your Exadata Cloud@Customer system.
This option is available only if you enabled backups on local Exadata
storage in the VM cluster that you want to host the database.
* Object Storage Select to store backups in an object storage container
managed by Oracle on Oracle Cloud Infrastructure.
To use this option, your Exadata Cloud@Customer system must have
egress connectivity to Oracle Cloud Infrastructure Object Storage.
* NFS Select to store backups in one of your previously defined
backup destinations that uses Network File System (NFS) storage.
See "Managing Backup Destinations for Exadata Cloud@Customer".
If you select this option, then you must also choose from the list of
NFS Backup Destinations.
* Recovery Appliance Select to store backups in one of your
previously defined backup destinations that uses Oracle Zero Data
Loss Recovery Appliance. See "Managing Backup Destinations for
Exadata Cloud@Customer".
If you select this option, then you must also provide the following
information:

11-5
 Chapter 11
Using the Console to Manage Backup and Recovery

* Choose Backup Destinations from the list of Recovery

Appliance .
* Choose from the VPU User list, which contains the list of
virtual private catalog (VPC) user names that are defined in the
Recovery Appliance backup destination.
* Provide the Password for the VPC user.

Note:
If you select a backup destination (other than None), then
you cannot change it later.

– Enable automatic backups: Select this option to enable daily backups

using the policy for automatic backups.
This option is only enabled when you select a Backup Destination Type
other than None. You can change this setting later.
– Backup retention period: Select this option to choose one of the options
for the length of time that automatic backups are retained.
For backups to local Exadata storage, you can choose a retention period
of 7 days, or 14 days. The default retention period is 7 days.
For backups to Oracle Cloud Infrastructure Object Storage or to an NFS
backup destination, you can choose one of the following preset retention
periods: 7 days, 14 days, 30 days, 45 days, or 60 days. The default
retention period is 30 days.
This option does not apply to Recovery Appliance backup destinations.
For backups to Oracle Zero Data Loss Recovery Appliance, the retention
policy that is implemented in the appliance controls the retention period.
• If automatic backups were previously configured, then you can make the
following changes:
– For Oracle Zero Data Loss Recovery Appliance backup destinations, you
can update the Password for the virtual private catalog (VPC) user that is
used to access the appliance.
– For backup destinations that do not use Oracle Zero Data Loss Recovery
Appliance, you can update the Backup retention period for automatic
backups:
* For backups to local Exadata storage, you can choose a retention
period of 7 days or 14 days. The default retention period is 7 days.
* For backups to Oracle Cloud Infrastructure Object Storage, or to an
NFS backup destination, you can choose one of the following preset
retention periods: 7 days, 14 days, 30 days, 45 days, or 60 days. The
default retention period is 30 days.
* For backups to Oracle Zero Data Loss Recovery Appliance, the
retention policy that is implemented in the appliance controls the
retention period.

11-6
 Chapter 11
Using the API to Manage Database Backup and Recovery

– You can set the option to Enable automatic backups. Select this option
to enable automatic database backups. Deselect this option to suspend
automatic database backups.
9. Click Save Changes.
Related Topics
• Managing Backup Destinations for Exadata Cloud@Customer

Restoring a Database with the Console

To restore a database to a point in time, to a system change number (SCN), or to the
latest backup, use the Exadata Cloud@Customer Console.
Use the following procedure to restore a database:
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose the Region and Compartment that contains the VM cluster that hosts the
database that you want to restore.
3. Click VM Clusters.
4. Click the name of the VM cluster that hosts the database that you want to restore.
5. In the Resources list of the VM Cluster Details page, click Databases.
6. Click the name of the database that you want to restore.
The Database Details page displays information about the selected database.
7. Click Restore Database.
8. In the resulting dialog box, select one of the following options, and click Restore
Database:
• Restore to latest: The database is restored and recovered with zero, or least
possible, data loss.
• Restore to a timestamp: The database is restored and recovered to the
specified timestamp.
• Restore to SCN: The database is restored and recovered to the specified
Oracle Database System Change Number (SCN). The specified SCN must be
valid otherwise the operation fails.

Note:
Backup fails after a point in time restore to a timestamp or SCN on NFS
storage. Wait for 10 minutes or so before proceeding with the backup.

Using the API to Manage Database Backup and Recovery

Learn how to use the API to manage database backup and recovery with Oracle
Exadata Cloud@Customer.

11-7
 Chapter 11
Customizing the Automatic Backup Configuration

For information about using the API and signing requests, see "REST APIs" and
"Security Credentials". For information about SDKs, see "Software Development Kits
and Command Line Interface".
Use these API operations to manage database backup and recovery:
• GetBackup
• ListBackups
• RestoreDatabase
• UpdateDatabase - To enable and disable automatic backups.
For the complete list of APIs, see "Database Service API".
Related Topics
• REST APIs
• Security Credentials
• Software Development Kits and Command Line Interface
• GetBackup
• ListBackups
• RestoreDatabase
• UpdateDatabase
• Database Service API

Customizing the Automatic Backup Configuration

You can customize many of the characteristics of the automatic backup configuration.
• Customizing Backup Settings by Using a Generated Configuration File
You can customize backup settings for a database deployment by generating a file
containing the current customizable settings, editing the file, and then using the file
to update the backup settings.
• Customizing Which System Files Are Backed Up
If your backup configuration includes bkup_cfg_files=yes, then each backup
includes system configuration files and directories specified in the oscfg.spec
file.
• Customizing Which Database Configuration Files Are Backed Up
If your backup configuration includes bkup_cfg_files=yes, then each backup
includes database configuration files and directories specified in the dbcfg.spec
file.

Customizing Backup Settings by Using a Generated Configuration File

You can customize backup settings for a database deployment by generating a file
containing the current customizable settings, editing the file, and then using the file to
update the backup settings.
To generate a configuration file with the current backup settings and use it to update
the settings:
1. Connect as the opc user to a compute node.

11-8
 Chapter 11
Customizing the Automatic Backup Configuration

For detailed instructions, see Connecting to a Compute Node Through Secure

Shell (SSH).
2. Start a root-user command shell:

# sudo -s
#

3. Use the bkup_api get config command to generate a file containing the current
backup settings for the database deployment:

# /var/opt/oracle/bkup_api/bkup_api get config [--file=filename] --

dbname=dbname

Where:
filename is an optional parameter used to specify a name for the file that is
generated
dbname is the database name for the database that you want to act on
4. Edit the parameter values in the generated file to change any settings you want to
customize in the backup configuration.
The following parameters can be modified to customize the backup configuration:

Table 11-1 Backup Configuration Parameters

Parameter Description
bkup_cron_entry Enables the automatic backup configuration.
Valid values are yes and no.
bkup_cfg_files Enables backup of system and database
configuration files. Valid values are yes and
no.
bkup_daily_time Start time of the automatic daily backup
expressed in 24-hour time as hh:mm.
bkup_archlog_frequency Interval in minutes between automatic
backups of archived database log files. Valid
values are 15, 20, 30, 60, and 120. Default
value is 60.
bkup_disk Enables backups to local Exadata storage.
Valid values are yes and no.
bkup_disk_recovery_window Retention period for backups on local
Exadata storage, expressed as a number
of days up to 14. Only applicable when
bkup_disk is set to yes. Default value is
7.
bkup_oss Enables backups to cloud storage. Valid
values are yes and no.
bkup_oss_recovery_window Retention period for backups to cloud
storage, expressed as a number of days up
to 90. Only applicable when bkup_oss is set
to yes. Default value is 30.

11-9
 Chapter 11
Customizing the Automatic Backup Configuration

Table 11-1 (Cont.) Backup Configuration Parameters

Parameter Description
bkup_oss_url Location of the storage container that is
used for backup to cloud storage. Only
applicable when bkup_oss is set to yes.
bkup_oss_user User name of the Oracle Cloud user
having write privileges on the cloud storage
container specified in bkup_oss_url. Only
applicable when bkup_oss is set to yes.
bkup_oss_passwd Password of the Oracle Cloud user having
write privileges on the cloud storage
container specified in bkup_oss_url. Only
applicable when bkup_oss is set to yes.
bkup_oss_l0_day Day of the week when a level 0 backup is
taken and stored on cloud storage. Valid
values are mon, tue, wed, thu, fri, sat,
sun. Only applicable when bkup_oss is set
to yes. Default value is sun.
bkup_zdlra Enables backups to a Recovery Appliance.
Valid values are yes and no.
bkup_zdlra_url Location of the Recovery Appliance that
is being used for backups. Only applicable
when bkup_zdlra is set to yes.
bkup_zdlra_user The virtual private catalog (VPC) user name
for the Recovery Appliance specified in
bkup_zdlra_url. Only applicable when
bkup_zdlra is set to yes.
bkup_zdlra_passwd Password of the Recovery Appliance
user specified in bkup_zdlra_url. Only
applicable when bkup_zdlra is set to yes.
bkup_rman_compression Level of compression applied to automatic
backups. Valid values are basic, low,
medium, and high. Default value is low.
bkup_set_section_size Enables the use of the RMAN multisection
backup feature. Valid values are yes and no.
bkup_section_size RMAN section size that is used
for automatic backups. Default value
is 64G. Only applicable when
bkup_set_section_size is set to yes.
bkup_channels_node Number of RMAN channels that are used
for automatic backups. Valid values are
between 1 and 32. Default value is 4.
bkup_use_rcat Enables the use of an existing RMAN
recovery catalog. Valid values are yes and
no.
bkup_rcat_user Recovery catalog user name. Only
applicable when bkup_use_rcat is set to
yes.

11-10
 Chapter 11
Customizing the Automatic Backup Configuration

Table 11-1 (Cont.) Backup Configuration Parameters

Parameter Description
bkup_rcat_passwd Password for recovery catalog user specified
in bkup_rcat_user. Only applicable when
bkup_use_rcat is set to yes.
bkup_rcat_conn Connection string for the RMAN
recovery catalog. Only applicable when
bkup_use_rcat is set to yes.

5. Use the bkup_api set config command to update the backup settings using the
file containing your updated backup settings:

# /var/opt/oracle/bkup_api/bkup_api set config --file=filename --

dbname=dbname

Where:
filename is used to specify the name of the file that contains the updated backup
settings
dbname is the database name for the database that you are acting on
6. You can use the bkup_api configure_status command to check the status of the
configuration update:

# /var/opt/oracle/bkup_api/bkup_api configure_status

7. Exit the root-user command shell:

# exit
#

Note that any changes you make by using the bkup_api command are not
reflected in the Oracle Database Exadata Cloud at Customer console.
Related Topics
• Connecting to a Compute Node with SSH
You can connect to the compute nodes in an Exadata Cloud@Customer system
by using a Secure Shell (SSH) connection.

Customizing Which System Files Are Backed Up

If your backup configuration includes bkup_cfg_files=yes, then each backup includes
system configuration files and directories specified in the oscfg.spec file.

To change which system files and directories are backed up:

1. Connect as the opc user to a compute node.
For detailed instructions, see Connecting to a Compute Node Through Secure
Shell (SSH).
2. Edit the contents of the oscfg.spec file.

11-11
 Chapter 11
Customizing the Automatic Backup Configuration

This file is located under /var/opt/oracle/dbaas_acfs/bkup/dbname, where

dbname is the name of the database that is associated with the backup
configuration.
Following is an example of the default contents of the oscfg.spec file:

## OS Configuration Files
#
# Doc Spec
oscfg.spec
#
# Directories
/etc/rc.d
/home/oracle/bkup
#
# Single files
/home/oracle/.bashrc
/etc/crontab
/etc/sysctl.conf
/etc/passwd
/etc/group
/etc/oraInst.loc
/etc/oratab
/etc/fstab

Related Topics
• Connecting to a Compute Node with SSH
You can connect to the compute nodes in an Exadata Cloud@Customer system
by using a Secure Shell (SSH) connection.

Customizing Which Database Configuration Files Are Backed Up

If your backup configuration includes bkup_cfg_files=yes, then each backup includes
database configuration files and directories specified in the dbcfg.spec file.

To change which database configuration files are backed up:

1. Connect as the oracle user to a compute node.
For detailed instructions, see Connecting to a Compute Node Through Secure
Shell (SSH).
2. Edit the contents of the dbcfg.spec file.
This file is located under /var/opt/oracle/dbaas_acfs/bkup/dbname, where
dbname is the name of the database that is associated with the backup
configuration.
Following is an example of the contents of the dbcfg.spec file:

### Oracle_Home configuration files.

#
# Doc Spec
dbcfg.spec
# DB id
dbid

11-12
 Chapter 11
Creating an On-Demand Backup by Using the bkup_api Utility

#
# Directories
/u02/app/oracle/product/dbversion/dbhome_n/admin/dbname/xdb_wallet
/u02/app/oracle/admin/dbname/xdb_wallet
/u02/app/oracle/admin/dbname/db_wallet
# Note: tde_wallet must be backed up in a different location than
DATA bkup.
/u02/app/oracle/admin/dbname/tde_wallet
/u02/app/oracle/admin/dbname/cat_wallet
#/u01/app/oraInventory
#
# Single files
/var/opt/oracle/dbaas_acfs/dbname/opc/opcdbname.ora
/u02/app/oracle/product/dbversion/dbhome_n/dbs/opcdbname.ora
/u02/app/oracle/product/dbversion/dbhome_n/dbs/orapwinstancename
/u02/app/oracle/product/dbversion/dbhome_n/network/admin/
listener.ora
/u02/app/oracle/product/dbversion/dbhome_n/network/admin/sqlnet.ora
/u02/app/oracle/product/dbversion/dbhome_n/network/admin/
tnsnames.ora
/u02/app/oracle/product/dbversion/dbhome_n/rdbms/lib/env_rdbms.mk
/u02/app/oracle/product/dbversion/dbhome_n/rdbms/lib/ins_rdbms.mk
#
# Creg
/var/opt/oracle/creg/instancename.ini
#

Related Topics
• Connecting to a Compute Node with SSH
You can connect to the compute nodes in an Exadata Cloud@Customer system
by using a Secure Shell (SSH) connection.

Creating an On-Demand Backup by Using the bkup_api

Utility
You can use the bkup_api utility to create an on-demand backup of a complete
database or an individual pluggable database (PDB):
To change which database configuration files are backed up:
1. Connect as the oracle user to a compute node.
For detailed instructions, see Connecting to a Compute Node Through Secure
Shell (SSH).
2. Start a root-user command shell:

# sudo -s
#

3. Enter the bkup_api command:

11-13
 Chapter 11
Creating an On-Demand Backup by Using the bkup_api Utility

• To create a backup that follows the current retention policy, use the following
bkup_api command:

# /var/opt/oracle/bkup_api/bkup_api bkup_start --dbname=dbname

where dbname is the database name for the database that you want to back
up.
• To create an on-demand backup of a specific PDB, use the following bkup_api
command:

# /var/opt/oracle/bkup_api/bkup_api bkup_start --dbname=dbname --

pdb=pdbname

• To create a long-term backup of the complete database that persists until you
delete it, use the following bkup_api command:

# /var/opt/oracle/bkup_api/bkup_api bkup_start --keep --

dbname=dbname

By default, the long-term backup is given a timestamp-based tag. To specify a

custom backup tag, add the --tag option to the bkup_api command.
For example, to create a long-term backup with the tag monthly, use the
following command:

# /var/opt/oracle/bkup_api/bkup_api bkup_start --keep --

tag=monthly --dbname=dbname

• To create an on-demand RMAN level 0 backup, use the following bkup_api

command:

# /var/opt/oracle/bkup_api/bkup_api bkup_start --level0 --

dbname=dbname

You can use this option to manually perform an RMAN level 0 (full) backup
if the scheduled weekly level 0 backup fails or following a major structural
change in the database, such as adding a new data file or tablespace. This
option is only valid for backup configurations that use cloud storage only.
• To create an on-demand backup that includes an image copy of the database
data files, use the following bkup_api command:

# /var/opt/oracle/bkup_api/bkup_api bkup_start --datafiles --

dbname=dbname

You can use this option to manually perform a full image backup to cloud
storage if the scheduled weekly full backup fails or following a major structural
change in the database, such as adding a new data file or tablespace. This
option is only valid for backup configurations that use cloud storage and local
Exadata storage.

11-14
 Chapter 11
Recovering a Database Using Oracle Recovery Manager (RMAN)

4. After you start an on-demand backup, the backup process runs in the background.
To check the progress of the backup process, run the following bkup_api
command on the same compute node where the backup is running:

# /var/opt/oracle/bkup_api/bkup_api bkup_status --dbname=dbname

5. Exit the root-user command shell and disconnect from the compute node:

# exit
# exit

Related Topics
• Connecting to a Compute Node with SSH
You can connect to the compute nodes in an Exadata Cloud@Customer system
by using a Secure Shell (SSH) connection.

Recovering a Database Using Oracle Recovery Manager

(RMAN)
If you backed up your database using bkup_api, then you can manually restore
that database backup by using the Oracle Recovery Manager (RMAN) utility. For
information about using RMAN, see the Oracle Database Backup and Recovery User's
Guide for Release 19.
Related Topics
• Oracle Database Backup and Recovery User's Guide for Release 19

11-15
12
Connecting to an Exadata
Cloud@Customer System
Learn how to connect to an Exadata Cloud@Customer system using SSH, and how
to connect to an Exadata Cloud@Customer database using Oracle Net Services
(SQL*Net).
• Connecting to a Compute Node with SSH
You can connect to the compute nodes in an Exadata Cloud@Customer system
by using a Secure Shell (SSH) connection.
• Connecting to a Database with Oracle Net Services
You can connect to the compute nodes in an Exadata Cloud@Customer system
using Oracle Net Services.

Connecting to a Compute Node with SSH

You can connect to the compute nodes in an Exadata Cloud@Customer system by
using a Secure Shell (SSH) connection.
Most Unix-style systems (including Linux, Oracle Solaris, and macOS) include an SSH
client. For Microsoft Windows systems, you can download a free SSH client called
PuTTY from the following site: "http://www.putty.org".
• Prerequisites for Connecting to an Exadata Cloud@Customer System
To access a compute node in an Exadata Cloud@Customer system using SSH,
be prepared to provide the host name or IP address of the compute node.
• Connecting to a Compute Node from a Microsoft Windows System Using PuTTY
Learn to access a compute node from a Microsoft Windows system using PuTTY.
• Connecting from a Unix-Style System
To access a compute node on an Oracle Cloud@Customer system from a Unix-
style system using SSH, use this procedure.
• Accessing a Database After You Connect to the Compute Node
After you connect to a compute node, you can use the following series of
commands to identify a database and connect to it.
Related Topics
• http://www.putty.org/

Prerequisites for Connecting to an Exadata Cloud@Customer System

To access a compute node in an Exadata Cloud@Customer system using SSH, be
prepared to provide the host name or IP address of the compute node.
• An SSH private key file that corresponds to a public key that is registered in the
system.
When you create a VM cluster on your Exadata Cloud@Customer system, you
must specify the public key portion of one or more SSH key pairs. You can

12-1
 Chapter 12
Connecting to a Compute Node with SSH

also register extra keys separately after you create the VM cluster. The public
keys are stored in the authorized_keys file at ~/.ssh/authorized_keys. Separate
authorized_keys files are located under the home directories of the oracle and
opc operating system users.
• The host name or IP address for the compute node that you want to access.
See, Using the Console to Check the Status of a VM Cluster Compute Node.
Related Topics
• Using the Console to Check the Status of a VM Cluster Compute Node
• Managing VM Clusters on Exadata Cloud@Customer
Learn to manage virtual machine (VM) clusters on Exadata Cloud@Customer.

Connecting to a Compute Node from a Microsoft Windows System

Using PuTTY
Learn to access a compute node from a Microsoft Windows system using PuTTY.
1. Run the PuTTY program (putty.exe).
The PuTTY Configuration window is displayed, showing the Session panel.
2. In the Host Name (or IP address) field, enter the host name or IP address of the
compute node that you want to access.
3. Confirm that the Connection type option is set to SSH.
4. In the Category tree, expand Connection if necessary and then click Data.
The Data panel is displayed.
5. In the Auto-login username field, enter the operating system user you want to
connect as:

• Connect as opc to perform operations that require root access to the compute
node, such as patching. This user can use the sudo -s command to gain root
user access to the compute node.
6. Confirm that the When username is not specified option is set to Prompt.
7. In the Category tree, expand SSH and then click Auth.
The Auth panel is displayed.
8. Click the Browse button next to the Private key file for authentication field.
Then, navigate to and open the private key file that corresponds to a public key
that is registered in the system.
9. In the Category tree, click Session.
The Session panel is displayed.
10. In the Saved Sessions field, enter a name for the connection configuration. Then,
click Save.
11. Click Open to open the connection.

The PuTTY Configuration window closes and the PuTTY terminal window
displays.

12-2
 Chapter 12
Connecting to a Compute Node with SSH

Connecting from a Unix-Style System

To access a compute node on an Oracle Cloud@Customer system from a Unix-style
system using SSH, use this procedure.
• Enter the following SSH command to access the compute node:

ssh –i private-keyuser@node

In the preceding syntax:

– private-key is the full path and name of the file that contains the SSH private
key that corresponds to a public key that is registered in the system.
– user is the operating system user that you want to use to connect:
* To perform operations as the Oracle Database software owner, connect as
oracle. This user does not have root user access to the compute node.
* To perform operations that require root access to the compute node, such
as patching, connect as opc. The opc user can use the sudo -s command
to gain root access to the compute node.
– node is the host name or IP address for the compute node that you want to
access.

Accessing a Database After You Connect to the Compute Node

After you connect to a compute node, you can use the following series of commands
to identify a database and connect to it.
1. SSH in as the oracle user.
2. sudo su oracle
3. Use the srvctl utility located under the Oracle Grid Infrastructure home directory
to list the databases on the system. For example:

/u01/app/12.2.0.1/grid/bin/srvctl config database -v

nc122 /u02/app/oracle/product/12.2.0/dbhome_6 12.2.0.1.0
s12c /u02/app/oracle/product/12.2.0/dbhome_2 12.2.0.1.0

4. Identify the database instances for the database that you want to access. For
example:

/u01/app/12.2.0.1/grid/bin/srvctl status database -d s12c

Instance s12c1 is running on node node01
Instance s12c2 is running on node node02

12-3
 Chapter 12
Connecting to a Compute Node with SSH

5. Configure the environment settings for the database that you want to access. For
example:

. oraenv
ORACLE_SID = [oracle] ? s12c
The Oracle base has been set to /u02/app/oracle

export ORACLE_SID=s12c1

6. You can use the svrctl command to display more detailed information about the
database. For example:

srvctl config database -d s12c

Database unique name: s12c
Database name:
Oracle home: /u02/app/oracle/product/12.2.0/dbhome_2
Oracle user: oracle
Spfile: +DATAC4/s12c/spfiles12c.ora
Password file: +DATAC4/s12c/PASSWORD/passwd
Domain: example.com
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools:
Disk Groups: DATAC4
Mount point paths:
Services:
Type: RAC
Start concurrency:
Stop concurrency:
OSDBA group: dba
OSOPER group: racoper
Database instances: s12c1,s12c2
Configured nodes: node01,node02
CSS critical: no
CPU count: 0
Memory target: 0
Maximum memory: 0
Default network number for database services:
Database is administrator managed

7. You can access the database by using SQL*Plus. For example:

sqlplus / as sysdba

SQL*Plus: Release 12.2.0.1.0 Production ...

Copyright (c) 1982, 2016, Oracle. All rights reserved.

Connected to:
Oracle Database 12c EE Extreme Perf Release 12.2.0.1.0 - 64bit
Production

12-4
 Chapter 12
Connecting to a Database with Oracle Net Services

Connecting to a Database with Oracle Net Services

You can connect to the compute nodes in an Exadata Cloud@Customer system using
Oracle Net Services.
• Using Oracle Net Services to Connect to a Database
Oracle Database Exadata Cloud@Customer supports remote database access by
using Oracle Net Services.
• Prerequisites for Connecting to a Database with Oracle Net Services
Review the prerequisites to connect to an Oracle Database instance on Oracle
Cloud@Customer using Oracle Net Services.
• Connecting to a Database Using SCAN
To create an Oracle Net Services connection by using the SCAN listeners, you can
choose between two approaches.
• Connecting to a Database Using a Node Listener
To connect to an Oracle Database instance on Exadata Cloud@Customer with a
connect descriptor that bypasses the SCAN listeners, use this procedure to route
your connection directly to a node listener.

Using Oracle Net Services to Connect to a Database

Oracle Database Exadata Cloud@Customer supports remote database access by
using Oracle Net Services.
Because Exadata Cloud@Customer uses Oracle Grid Infrastructure, you can make
Oracle Net Services connections by using Single Client Access Name (SCAN)
connections. SCAN is a feature that provides a consistent mechanism for clients to
access the Oracle Database instances running in a cluster.
By default, the SCAN is associated with three virtual IP addresses (VIPs). Each SCAN
VIP is also associated with a SCAN listener that provides a connection endpoint for
Oracle Database connections using Oracle Net Services. To maximize availability,
Oracle Grid Infrastructure distributes the SCAN VIPs and SCAN listeners across the
available cluster nodes. In addition, if there is a node shutdown or failure, then the
SCAN VIPs and SCAN listeners are automatically migrated to a surviving node. By
using SCAN connections, you enhance the ability of Oracle Database clients to have a
reliable set of connection endpoints that can service all of the databases running in the
cluster.
The SCAN listeners are in addition to the Oracle Net Listeners that run on every
node in the cluster, which are also known as the node listeners. When an Oracle Net
Services connection comes through a SCAN connection, the SCAN listener routes the
connection to one of the node listeners, and plays no further part in the connection. A
combination of factors, including listener availability, database instance placement, and
workload distribution, determines which node listener receives each connection.

Note:
This documnentation provides basic requirements for connecting to your
Exadata Cloud@Customer databases by using Oracle Net Services.

12-5
 Chapter 12
Connecting to a Database with Oracle Net Services

Prerequisites for Connecting to a Database with Oracle Net Services

Review the prerequisites to connect to an Oracle Database instance on Oracle
Cloud@Customer using Oracle Net Services.
To connect to an Oracle Database on Exadata Cloud@Customer with Oracle Net
Services, you need the following:
• The IP addresses for your SCAN VIPs, or the hostname or IP address for a
compute node that hosts the database that you want to access.
• The database identifier: Either the database system identifier (SID), or a service
name.

Connecting to a Database Using SCAN

To create an Oracle Net Services connection by using the SCAN listeners, you can
choose between two approaches.
• Connecting to a Database Using a Connect Descriptor that References All of the
SCAN VIPs
You can set up a connect descriptor for Oracle Exadata Cloud@Customer System
using multiple SCAN listeners.
• Connecting to a Database Use a Connect Descriptor that References a Custom
SCAN Name
You can set up a connect descriptor for Oracle Exadata Cloud@Customer System
using a custom SCAN name.

Connecting to a Database Using a Connect Descriptor that References All of

the SCAN VIPs
You can set up a connect descriptor for Oracle Exadata Cloud@Customer System
using multiple SCAN listeners.
This approach requires you to supply all of the single client access name (SCAN)
virtual IP (VIP) addresses, and enables Oracle Net Services to connect to an available
SCAN listener.

• Use the following template to define a Net Services alias, which is typically used to
provide a convenient name for the connect descriptor:

alias-name = (DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=SCAN-VIP-1)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=SCAN-VIP-2)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=SCAN-VIP-3)(PORT=1521)))
(CONNECT_DATA=(sid-or-service-entry)))

Where:
alias-name is the name you use to identify the alias.
SCAN-VIP-[1–3] are the IP addresses for the SCAN VIPs.

12-6
 Chapter 12
Connecting to a Database with Oracle Net Services

sid-or-service-entry identifies the database SID or service name using one of

the following formats:
• SID=sid-name. For example: SID=S12C1.
• SERVICE_NAME=service-name. For example:
SERVICE_NAME=PDB1.example.yourcloud.com.

Note:
By default, Oracle Net Services randomly selects one of the addresses
in the address list to balance the load between the SCAN listeners.

Connecting to a Database Use a Connect Descriptor that References a Custom

SCAN Name
You can set up a connect descriptor for Oracle Exadata Cloud@Customer System
using a custom SCAN name.
Using this approach, you define a custom single client access name (SCAN) name
in your domain name server (DNS), which resolves to the three SCAN virtual IP
addresses (VIPs).

• Use the following template to define a Net Services alias that references the
custom SCAN name:

alias-name = (DESCRIPTION=
(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=scan-name)(PORT=1521)))
(CONNECT_DATA=(sid-or-service-entry)))

Where:
alias-name is the name you use to identify the alias.
scan-name is the custom SCAN name.
sid-or-service-entry identifies the database SID or service name using one of
the following formats:
• SID=sid-name. For example: SID=S12C1.
• SERVICE_NAME=service-name. For example:
SERVICE_NAME=PDB1.example.yourcloud.com.
Alternatively, you can use the easy connect method to specify a connect descriptor
with the following format:

scan-name:1521/sid-or-service-entry

For example:

exa1scan.example.com:1521/S12C1

12-7
 Chapter 12
Connecting to a Database with Oracle Net Services

Or

exa1scan.example.com:1521/PDB1.example.yourcloud.com

Connecting to a Database Using a Node Listener

To connect to an Oracle Database instance on Exadata Cloud@Customer with a
connect descriptor that bypasses the SCAN listeners, use this procedure to route your
connection directly to a node listener.
By using this method, you give up the high-availability and load-balancing provided
by SCAN. However, this method may be desirable if you want to direct connections
to a specific node or network interface. For example, you might want to ensure that
connections from a program that performs bulk data loading use the backup network.
Using this approach, you direct your connection using the hostname or IP address of
the node.
Example 12-1 Defining a Net Service Alias That Directly References the Node

alias-name = (DESCRIPTION=
(CONNECT_TIMEOUT=timeout)
(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=node)(PORT=1521)))
(CONNECT_DATA=(sid-or-service-entry)))

Where:
alias-name is the name you use to identify the alias.

timeout specifies a timeout period (in seconds), which enables you to

terminate a connection attempt without having to wait for a TCP timeout. The
(CONNECT_TIMEOUT=timeout) parameter is optional.

node is the hostname or IP address for the compute node that you want to use.

sid-or-service-entry identifies the database SID or service name using one of the
following formats:
• SID=sid-name. For example, SID=S12C1.
• SERVICE_NAME=service-name. For example,
SERVICE_NAME=PDB1.example.oraclecloudatcust.com.

Alternatively, you can use the easy connect method to specify a connect descriptor
with the following format:

node:1521/sid-or-service-entry

For example:

exa1node01.example.com:1521/S12C1

Or

exa1node01.example.com:1521/PDB1.example.oraclecloudatcust.com

12-8
13
Maintaining an Exadata Cloud@Customer
System
Learn how to perform patching operations on Exadata Cloud@Customer
infrastructure.
• User-Managed Maintenance Updates
• Oracle Managed Exadata Cloud@Customer Infrastructure Maintenance Updates

User-Managed Maintenance Updates

Maintaining a secure Exadata Cloud@Customer system in the best working order
requires you to perform the following tasks regularly:
• Patching the Oracle Grid Infrastructure and Oracle Database software on
the Exadata compute nodes. See Patching and Updating an Exadata
Cloud@Customer System Manually and Oracle Clusterware Configuration and
Administration for information and instructions.
• Updating the operating system and the tooling on the compute nodes. See
Patching and Updating an Exadata Cloud@Customer System Manually for
information and instructions.

Oracle Managed Exadata Cloud@Customer Infrastructure

Maintenance Updates
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), Exadata storage servers, Exadata InfiniBand switches, ROCE switches, and
Control Plane servers. This is referred to as Exadata Cloud@Customer infrastructure
maintenance.
• Managing VM Clusters on Exadata Cloud@Customer
Oracle performs patches and updates to all of the Oracle-managed system
components on Exadata Cloud@Customer.
• Overview of the Infrastructure Patching Process
• Scheduling Oracle-Managed Infrastructure Updates
• Monitoring Patching Operations Using Lifecycle State Information
• Receive Notifications about Your Infrastructure Maintenance Updates

13-1
 Chapter 13
Oracle Managed Exadata Cloud@Customer Infrastructure Maintenance Updates

Managing VM Clusters on Exadata Cloud@Customer

Oracle performs patches and updates to all of the Oracle-managed system
components on Exadata Cloud@Customer.
Oracle patches and updates include the physical compute nodes (Dom0), network
switches, power distribution units (PDUs), integrated lights-out management (ILOM)
interfaces, and the Exadata Storage Servers.
In all but rare exceptional circumstances, you receive advance communication about
these updates to help you plan for them. If there are corresponding recommended
updates for your compute node virtual machines (VMs), then Oracle provides
notification about them.
Wherever possible, scheduled updates are performed in a manner that preserves
service availability throughout the update process. However, there can be some
noticeable impact on performance and throughput while individual system components
are unavailable during the update process.
For example, Dom0 patching typically requires a reboot. In such cases, wherever
possible, the compute nodes are restarted in a rolling manner, one at a time, to
ensure that the service remains available throughout the process. However, each
compute node is unavailable for a short time while it restarts, and the overall service
capacity diminishes accordingly. If your applications cannot tolerate the restarts, then
take mitigating action as needed. For example, shut down an application while Dom0
patching occurs.

Overview of the Infrastructure Patching Process

Infrastructure maintenance begins with patching of the Exadata compute nodes.
Compute nodes are updated in a rolling fashion, with a single node being shut
down, patched, and then brought back online while other nodes remain operational.
This process continues until all nodes are patched. After compute node patching
completes, Oracle patches the storage nodes. Storage server patching does not
impact VM cluster nodes availability.
Note that while databases are expected to be available during the patching process,
Oracle does not verify that all database services and pluggable databases are
available after a node is brought back online, as these can depend on the application
service definition. Oracle recommends reviewing the documentation on workload
management, application continuity, and client failover best practices to reduce the
potential for an outage with your applications. By following the documentation's
guidelines, 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 Data Guard to ensure the highest availability for your critical
applications. For databases with 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. This allows you to avoid any
impact to your primary database during infrastructure patching.
Based on the shape of the rack, maintenance can take up to 32 hours from the
schedule start time.

13-2
 Chapter 13
Oracle Managed Exadata Cloud@Customer Infrastructure Maintenance Updates

• Maintenance window will start with performing prechecks on all the ExaC@C
infrastructure components. This will take approximately 2 hours to complete.
• Each Dom0 takes 90 minutes on an average
• Each storage cell takes 60 minutes on an average
• InfiniBand or RoCE switches take 60 minutes on an average
• Control Plane Server takes 240 minutes on an average
The approximate computed time for infrastructure patching operations is as follows:
• Base and Quarter Rack (2 Dom0/3 Storage Cells): Approximately 13 hours
• Half Rack (4 Dom0/6 Storage Cells): Approximately 19 hours
• Full Rack (8 Dom0/12 Storage Cells): Approximately 31 hours

Scheduling Oracle-Managed Infrastructure Updates

Exadata Cloud Service updates are released on a quarterly basis. You can set a
maintenance window to determine the time your quarterly infrastructure maintenance
will begin. You can also view scheduled maintenance runs and the maintenance
history of your Exadata Cloud@Customer in the Oracle Cloud Infrastructure Console.
For more information, see the following:
• Set the Automatic Maintenance Schedule for Exadata Cloud@Customer
Infrastructure
• View or Edit the Time of the Next Scheduled Maintenance for Exadata
Cloud@Customer Infrastructure
• View the Maintenance History of Exadata Cloud@Customer Infrastructure
In exceptional cases, Oracle might need to update your system apart from the regular
quarterly 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 to help you plan for them.
• Set the Automatic Maintenance Schedule for Exadata Cloud@Customer
Infrastructure
Learn how to set the maintenance schedule for an Exadata Cloud@Customer
infrastructure.
• View or Edit the Time of the Next Scheduled Maintenance for Exadata
Cloud@Customer Infrastructure
Learn how to view and edit the time of the next scheduled maintenance.
• View the Maintenance History of Exadata Cloud@Customer Infrastructure
Learn how to view the maintenance history for an Exadata Cloud@Customer
Infrastructure.

Set the Automatic Maintenance Schedule for Exadata Cloud@Customer

Infrastructure
Learn how to set the maintenance schedule for an Exadata Cloud@Customer
infrastructure.

13-3
 Chapter 13
Oracle Managed Exadata Cloud@Customer Infrastructure Maintenance Updates

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
2. Choose your Compartment.
3. Click Exadata Infrastructure.
4. In the list of Exadata Infrastructures, find the infrastructure you want to set the
maintenance window for and click its highlighted name.
5. On the infrastructure details page, under Maintenance, click the edit link in the
Maintenance Details field.
6. In the Edit Automatic Maintenance page, select Specify a schedule.
7. Under Maintenance months, specify at least one month for each quarter during
which Exadata infrastructure maintenance will take place. You can select more
than one month per quarter. If you specify a long lead time for advanced
notification (for example, 4 weeks), you may wish to specify 2 or 3 months per
quarter during which maintenance runs can occur. This will ensure that your
maintenance updates are applied in a timely manner after accounting for your
required lead time. Lead time is discussed in the following steps.
8. Optional. Under Week of the month, specify which week of the month
maintenance will take place. Weeks start on the 1st, 8th, 15th, and 22nd days of
the month, and have a duration of 7 days. Weeks start and end based on calendar
dates, not days of the week. Maintenance cannot be scheduled for the fifth week
of months that contain more than 28 days. If you do not specify a week of the
month, Oracle will run the maintenance update in a week to minimize disruption.
9. Optional. Under Day of the week, specify the day of the week on which the
maintenance will occur. If you do not specify a day of the week, Oracle will run the
maintenance update on a weekend day to minimize disruption.
10. Optional. Under Start hour, specify the hour during which the maintenance run
will begin. If you do not specify a start hour, Oracle will pick the least disruptive
time to run the maintenance update.
11. Under Lead Time, specify the minimum number of weeks ahead of the
maintenance event you would like to receive a notification message. Your lead
time ensures that a newly released maintenance update is scheduled to account
for your required minimum period of advanced notification.
12. Click Save Changes.

View or Edit the Time of the Next Scheduled Maintenance for Exadata
Cloud@Customer Infrastructure
Learn how to view and edit the time of the next scheduled maintenance.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose your Compartment.
3. Click Exadata Infrastructure.
4. In the list of Exadata Infrastructures, find the infrastructure you want to set the
maintenance window for and click its highlighted name.

13-4
 Chapter 13
Oracle Managed Exadata Cloud@Customer Infrastructure Maintenance Updates

5. On the infrastructure details page, under Maintenance, click the view link in the
Next Maintenance field.
6. On the Maintenance page, scheduled maintenance events are listed.
7. Optional. To change the time of the next scheduled maintenance, click the Edit
link in the Scheduled Start Time field.
8. In the Edit Infrastructure Maintenance Scheduled Start Time page, enter a
date and time in the Scheduled Start time field.
The following restrictions apply:
• Infrastructure maintenance cannot be rescheduled to occur more than six
months after the announcement of the maintenance update's availability. If
a new patch is announced prior to your rescheduled maintenance run, the
newer patch will be applied on your specified date. You can reschedule your
maintenance to take place earlier than it is currently scheduled. You cannot
reschedule start time less than two hours from the current time.
• Oracle reserves certain dates each quarter for internal maintenance
operations, and you cannot schedule your maintenance on these dates.

View the Maintenance History of Exadata Cloud@Customer Infrastructure

Learn how to view the maintenance history for an Exadata Cloud@Customer
Infrastructure.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose your Compartment.
3. Click Exadata Infrastructure.
4. In the list of Exadata Infrastructures, find the infrastructure you want to set the
maintenance window for and click its highlighted name.
5. On the infrastructure details page, under Maintenance, click the view link in the
Next Maintenance field.
6. Click Maintenance History to see a list of past maintenance events including
details on their completion state.

Monitoring Patching Operations Using Lifecycle State Information

The lifecycle state of your infrastructure resource (either the cloud Exadata
infrastructure or the DB system resource) enables you to monitor when the patching
of your infrastructure resource begins and ends. In the Oracle Cloud Infrastructure
Console, you can see lifecycle state details messages on the Exadata Infrastructure
Details or DB System Details page when a tool tip is displayed beside the Status field.
You can also access these messages using the ListExadataInfrastructures API, and
using tools based on the API, including SDKs and the OCI CLI.
During patching operations, you can expect the following:
• If you specify a maintenance window, then patching begins at your specified start
time. The patching process starts with a series of prerequisite checks to ensure
that your system can be successfully patched. These checks take approximately

13-5
 Chapter 13
Oracle Managed Exadata Cloud@Customer Infrastructure Maintenance Updates

2 hours to complete. While the system is performing the checks, the infrastructure
resource's lifecycle state remains "Available," and there is no lifecycle state
message.
For example, if you specify that patching should begin at 8:00 a.m., then Oracle
begins patching operations at 8:00, but the infrastructure resource's lifecycle state
does not change from "Available" to "Maintenance in Progress" until approximately
8:30 a.m.
• When Exadata compute node patching starts, the infrastructure resource's
lifecycle state is "Maintenance in Progress", and the associated lifecycle state
message is "The underlying infrastructure of this system (dbnodes) is being
updated."
• When cell storage patching starts, the infrastructure resource's lifecycle state is
"Maintenance in Progress", and the associated lifecycle state message is "The
underlying infrastructure of this system (cell storage) is being updated and this will
not impact Database availability."
• After cell patching is complete, the networking switches are patched one at a time,
in a rolling fashion.
• When patching is complete, the infrastructure resource's lifecycle state is
"Available", and the Console and API-based tools do not provide a lifecycle state
message.

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
Exadata Cloud@Customer Infrastructure Patching Event Types. 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.
• Infrastructure Maintenance Contacts

Infrastructure Maintenance Contacts

Maintenance contacts are required for service request based communications for
hardware replacement and other maintenance events.
Add a primary maintenance contact and optionally add a maximum of nine secondary
contacts. Both the primary and secondary contacts receive all notifications about
hardware replacement, network issues, and software maintenance runs.

13-6
 Chapter 13
Oracle Managed Exadata Cloud@Customer Infrastructure Maintenance Updates

You can promote any secondary contacts as the primary anytime you want. When you
promote a secondary contact to primary, the current primary contact will be demoted
automatically to secondary.
For more information, see: Using the Console to Create Infrastructure and Managing
Infrastructure Maintenance Contacts.
Related Topics
• Using the Console to Create Infrastructure
To create your Oracle Exadata Cloud@Customer infrastructure, be prepared to
provide values for the fields required for configuring the infrastructure.
• Managing Infrastructure Maintenance Contacts
Learn to manage your Exadata infrastructure maintenance contacts.

13-7
14
Patching an Exadata Cloud@Customer
System
Learn how to perform patching operations on Exadata database compute nodes and
Database Homes by using the Console, API, or the CLI.
For information and instructions on patching the system by using the dbaascli utility,
see "Patching and Updating an Exadata Cloud@Customer System Manually".
For more information and examples for applying database quarterly patches on
Exadata Cloud@Customer refer to My Oracle Support note: How to Apply Database
Quarterly Patch on Exadata Cloud Service and Exadata Cloud at Customer Gen 2
(Doc ID 2701789.1).
For more guidance on achieving continuous service during patching operations, see
the Application Checklist for Continuous Service for MAA Solutions white paper.
• Required IAM Policy for Patching an Exadata Cloud@Customer System
Review the identity access management (IAM) policy for Patching an Exadata
Cloud@Customer System
• About Patching VM Clusters and Database Homes
• Prerequisites for Patching an Exadata Cloud@Customer System
Check and apply the latest Cloud patches that are dowloaded and made available
by Oracle on the CPS host.
• Using the Console for Patching an Exadata Cloud@Customer System
Learn how to use the console to view the history of patch operations on VM cluster
and Database Homes, apply patches, and monitor the status of patch operations.
• Using the API to Patch an Exadata Cloud@Customer System
Use various API features to help manage patching an Oracle Exadata
Cloud@Customer system.
Related Topics
• Patching and Updating an Exadata Cloud@Customer System Manually
• https://support.oracle.com/epmos/faces/DocContentDisplay?id=2701789.1
• Application Checklist for Continuous Service for MAA Solutions

Required IAM Policy for Patching an Exadata

Cloud@Customer System
Review the identity access management (IAM) policy for Patching an Exadata
Cloud@Customer System
A policy is an IAM document that specifies who has what type of access to your
resources. It is used in different ways:
• An individual statement written in the policy language

14-1
 Chapter 14
About Patching VM Clusters and Database Homes

• A collection of statements in a single, named "policy" document, which has an

Oracle Cloud ID (OCID) assigned to it
• The overall body of policies your organization uses to control access to resources
A compartment is a collection of related resources that can be accessed only
by certain groups that have been given permission by an administrator in your
organization.
To use Oracle Cloud Infrastructure, you must be given the required type of access in
a policy written by an administrator, whether you're using the Console, or the REST
API with a software development kit (SDK), a command-line interface (CLI), or some
other tool. If you try to perform an action, and receive a message that you don’t
have permission, or are unauthorized, then confirm with your administrator the type of
access you've been granted, and which compartment you should work in.
For administrators: The policy in "Let database admins manage DB systems" lets the
specified group do everything with databases, and related database resources.
If you're new to policies, then see "Getting Started with Policies" and "Common
Policies". If you want to dig deeper into writing policies for databases, then see "Details
for the Database Service".
Related Topics
• Let database admins manage DB systems
• Getting Started with Policies
• Common Policies
• Details for the Database Service

About Patching VM Clusters and Database Homes

Patching a VM cluster updates components on each of the VM guests in the VM
cluster. VM cluster patching updates the grid infrastructure (GI) and Database Home
patching updates the Oracle Database software shared by the databases in that
home.
For more information on available patches, see My Oracle Support note https://
support.oracle.com/epmos/faces/DocContentDisplay?id=2333222.1.
Consider the following best practices:
• Because patching a system requires a reboot, plan to run the operations at a time
when they will have minimal impact on users.
• Oracle recommends that you back up your databases before you apply any
patches. For information about backing up the databases, see Managing
Database Backup and Recovery on Exadata Cloud@Customer.
• Your Oracle Grid Infrastructure must be at or higher version than the database
version you want to patch to. This may require you to first patch a VM cluster
before you patch the Databases Homes within that system.
• To patch a database to a version other than the database version of the current
home, move the database to a Database Home running the target version. See
Using the Console to Move a Database to Another Home.

14-2
 Chapter 14
Prerequisites for Patching an Exadata Cloud@Customer System

Related Topics
• Managing Database Backup and Recovery on Oracle Exadata Cloud@Customer
Learn how to work with the backup and recovery facilities provided by Oracle
Exadata Cloud@Customer.
• Using the Console to Move a Database to Another Home
You can update the version of a VM cluster database by moving it to a Database
Home that is running the version of Oracle Database you are interested in.

Prerequisites for Patching an Exadata Cloud@Customer

System
Check and apply the latest Cloud patches that are dowloaded and made available by
Oracle on the CPS host.
Ensure that the following conditions are met to avoid patching failures:
• The /u01 directory on the database host file system has at least 15 GB of free
space for the execution of patching processes.
• The Oracle Clusterware is up and running on the VM cluster.
• All nodes of the VM cluster are up and running.

Using the Console for Patching an Exadata

Cloud@Customer System
Learn how to use the console to view the history of patch operations on VM cluster
and Database Homes, apply patches, and monitor the status of patch operations.
Oracle recommends that you use the precheck action to ensure your VM cluster or
Database Home has met the requirements for the patch you want to apply.
• Using the Console to Perform a Patch Operation on a VM Cluster
Learn to apply patches on a VM cluster.
• Using the Console to Perform a Patch Operation on a Database Home
Learn to apply patches on a Database Home.
• Using the Console to View Patch History
Each patch history entry represents an attempted patch operation and indicates
whether the operation was successful or failed. You can retry a failed patch
operation. Repeating an operation results in a new patch history entry.
• Using the Console to Move a Database to Another Home
You can update the version of a VM cluster database by moving it to a Database
Home that is running the version of Oracle Database you are interested in.

Using the Console to Perform a Patch Operation on a VM Cluster

Learn to apply patches on a VM cluster.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
VM Clusters is selected by default.

14-3
 Chapter 14
Using the Console for Patching an Exadata Cloud@Customer System

2. Choose your Compartment.

A list of VM Clusters is displayed for the chosen Compartment.
3. In the list of VM clusters, click the VM cluster on which you want to perform a
patch operation.
4. Under Oracle Grid Infrastructure Version, click View Patches.
5. Review the scope:
• VM Cluster: Automatically set to the context from which you have launched
this page.
• Database Home: Automatically set to the context from which you have
launched this page. If you have not set the context, then select the Database
Home first.
6. Review the list of available patches for the VM cluster.
7. Click the Actions icon (three dots) for the patch you are interested in, and then
click one of the following actions:
• Run Precheck: Check for any prerequisites to make sure that the patch can
be successfully applied. Oracle highly recommends that you run this operation
before you apply a patch. Precheck does not cause any availability impact to
the cluster, everything remains operational.
• Apply Patch: Applies the selected patch.
8. Confirm when prompted.
The patch list displays the status of the operation. While the precheck is running,
the patch's status shows Checking. While a patch is being applied, the patch's
status shows Applying and the VM cluster's status shows Updating. During patching,
lifecycle operations on the VM cluster and its resources are temporarily unavailable.
If patching completes successfully, the patch's status changes to Applied and the VM
cluster's status changes to Available. You can view more details about an individual
patch operation by clicking Patch History. Grid Infrastructure patching is done in a
rolling fashion, node by node, and the cluster resources will be stopped and restarted
on each node.

Using the Console to Perform a Patch Operation on a Database Home

Learn to apply patches on a Database Home.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
VM Clusters is selected by default.
2. Choose your Compartment.
A list of VM Clusters is displayed for the chosen Compartment.
3. In the list of VM clusters, click the VM cluster where the Database Home is
located.
4. Under Resources, click Database Homes.
5. In the list of Database Homes, click the Database Home on which you want to
perform a patch operation.
6. Under Database Software Version, click View Patches.

14-4
 Chapter 14
Using the Console for Patching an Exadata Cloud@Customer System

7. Review the scope:

• Database Home: Automatically set to the context from which you have
launched this page.
8. Review the list of available patches for the Database Home.
The Oracle Provided Database Software Images tab displays generally-
available Oracle Database software images that you can use to patch your
database. Oracle images that can be used for patching have the update Type
of "Patch".
The Custom Database Software Images tab allows you to select a database
software image that you have created in advance. Use the Select a
Compartment selector to specify the compartment that contains the database
software image. Custom images that can be used for patching have the update
Type of "Patch".
9. Click the Actions icon (three dots) for the patch you are interested in, and then
click one of the following actions:
• Run Precheck: Check for any prerequisites to make sure that the patch can
be successfully applied. Oracle highly recommends that you run this operation
before you apply a patch. The Precheck does not cause any availability impact
to the cluster, everything remains operational.
• Apply Patch: Applies the selected patch.
10. Confirm when prompted.

The patch list displays the status of the operation. While the precheck is running,
the patch's status shows Checking. While a patch is being applied, the patch's status
shows Applying, the status of the Database Home and the databases in it display as
Updating, and lifecycle operations on the VM cluster and its resources are temporarily
unavailable. Patches are applied to the Database Home in a rolling fashion, node by
node, and each database in the home is stopped and then restarted. This may result
in temporary service disruption. If patching completes successfully, the patch's status
changes to Applied and the Database Home's status changes to Available. You can
view more details about an individual patch operation by clicking Patch History.

Using the Console to View Patch History

Each patch history entry represents an attempted patch operation and indicates
whether the operation was successful or failed. You can retry a failed patch operation.
Repeating an operation results in a new patch history entry.
Patch history views in the Console do not show patches that were applied by using
command line tools such as dbaascli.

• Using the Console to View the Patch History of a VM Cluster

Learn how to view the history of patches applied on a VM cluster.
• Using the Console to View the Patch History of a Database Home
Learn how to view the history of patches applied on a Database Home.

Using the Console to View the Patch History of a VM Cluster

Learn how to view the history of patches applied on a VM cluster.

14-5
 Chapter 14
Using the Console for Patching an Exadata Cloud@Customer System

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
VM Clusters is selected by default.
2. Choose your Compartment.
A list of VM Clusters is displayed for the chosen Compartment.
3. In the list of VM clusters, click the VM cluster you are interested in.
4. Under Oracle Grid Infrastructure Version, click View Patches.
5. Click Patch History.
The history of patch operations for that VM cluster is displayed, along with the history
of patch operations on its Database Homes.

Using the Console to View the Patch History of a Database Home

Learn how to view the history of patches applied on a Database Home.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
VM Clusters is selected by default.
2. Choose your Compartment.
A list of VM Clusters is displayed for the chosen Compartment.
3. In the list of VM clusters, click the VM cluster where the Database Home is
located.
4. Under Resources, click Database Homes.
A list of Database Homes is displayed.
5. In the list of Database Homes, click the Database Home you are interested in.
6. Under Database Software Version, click View Patches.
7. Click Patch History.
The history of patch operations for that Database Home is displayed, along with the
history of patch operations on the VM cluster to which it belongs.

Using the Console to Move a Database to Another Home

You can update the version of a VM cluster database by moving it to a Database
Home that is running the version of Oracle Database you are interested in.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
VM Clusters is selected by default.
2. Choose your Compartment.
A list of VM Clusters is displayed for the chosen Compartment.
3. In the list of VM clusters, click the VM cluster where the database you want to
move is located.
4. Under Resources, click Database Homes.

14-6
 Chapter 14
Using the API to Patch an Exadata Cloud@Customer System

5. In the list of Database Homes, click the Database Home you are interested in.
A list of databases is displayed.
6. In the list of databases, click the database you are interested in.
7. Click Move Database.
8. Select the target Database Home.
9. Click Move Database.
The database will be stopped in the current home and then restarted in the
destination home.
10. Confirm the move operation.

The database will be stopped in the current home and then restarted in the destination
home. While the database is being moved, the Database Home and Database
statuses display as Updating. The Database Home location, shown under Database
Version, displays as Moving Database. When the operation completes, Database
Home is updated with the current home. If the operation is unsuccessful, then the
status of the database displays as Failed, and the Database Home field provides
information about the reason for the failure.

Using the API to Patch an Exadata Cloud@Customer

System
Use various API features to help manage patching an Oracle Exadata
Cloud@Customer system.
For information about using the API and signing requests, see "REST APIs" and
"Security Credentials". For information about SDKs, see "Software Development Kits
and Command Line Interface".
Use these API operations to manage patching VM clusters, Database Homes and
Databases.
VM cluster:
• UpdateVmCluster
Database Homes:
• CreateDbHome
• UpdateDbHome
• DeleteDbHome
Database:
• CreateDatabase
• UpdateDatabase
• DeleteDatabase
Use UpdateVMCluster to patch the Oracle Grid Infrastructure on the VM Cluster.
Use UpdateDbHome to patch the Database Software of the Database Home. Use
UpdateDatabase to move a database to a different Database Home, thereby updating
the database to the same version as the target Database Home.

14-7
 Chapter 14
Using the API to Patch an Exadata Cloud@Customer System

For the complete list of APIs for the Database service, see "Database Service API".
Related Topics
• REST APIs
• Security Credentials
• Software Development Kits and Command Line Interface
• UpdateVmCluster
• CreateDbHome
• UpdateDbHome
• DeleteDbHome
• CreateDatabase
• UpdateDatabase
• DeleteDatabase
• Database Service API

14-8
15
Patching and Updating an Exadata
Cloud@Customer System Manually
This topic describes the responsibilities and procedures for patching and updating
various components in Exadata Cloud@Customer.

Note:
For more guidance on achieving continuous service during patching
operations, see the Application Checklist for Continuous Service for MAA
Solutions white paper.

• Administering Software Images

Oracle maintains a library of cloud software images and provides capabilities
to view the library and download images to your Oracle Database Exadata
Cloud@Customer Guest VM. Using these facilities, you can control the version
of Oracle binaries that is used when a new Oracle Home is created.
• Managing Oracle Database and Oracle Grid Infrastructure Patches
You are responsible for routine patching of Oracle Database and Oracle Grid
Infrastructure software.
• Manually Patching Oracle Database and Oracle Grid Infrastructure Software
For Oracle Java VM, daylight savings time, and some routine or one-off patches, it
can be necessary for you to patch software manually.
• Updating the Guest VM Operating System
Learn about standard Exadata tools and techniques you can use to update the
operating system components on the Exadata Cloud@Customer Guest VMs.
• Cloud Tooling Updates
You are responsible for updating the cloud-specific tooling included on the Exadata
Cloud@Customer Guest VMs.
Related Topics
• Application Checklist for Continuous Service for MAA Solutions

Administering Software Images

Oracle maintains a library of cloud software images and provides capabilities to view
the library and download images to your Oracle Database Exadata Cloud@Customer
Guest VM. Using these facilities, you can control the version of Oracle binaries that is
used when a new Oracle Home is created.
When you create a new database deployment with a new Oracle Home, the Oracle
Database binaries are sourced from a software image that is stored and set as a
default in your Exadata Cloud@Customer Guest VM ACFS volume. Over time, the
software images in your Exadata Cloud@Customer instance will become old if they

15-1
 Chapter 15
Administering Software Images

are not maintained. Using an old software image means that you need to apply
patches to newly installed binaries to bring them up to date, which is unnecessarily
laborious and possibly prone to error.
Software image administration uses the dbaascli utility, which is part of the
cloud-specific tooling included in Exadata Cloud@Customer. To use the latest
enhancements, you should update to the latest version of the cloud tools. See Cloud
Tooling Update.

Note:
If you create a new database deployment in an existing Oracle Home
directory location, and if the default software image version is higher or
lower than the Oracle Home version, a check is made to know if the images
required for creating the database exist on Guest VM. If the image does not
exist, an internal command is issued by the cloud automation software to
download and use the required image from control plane server to Guest VM
to create the database.
When you create a new Oracle Home, it will be created with the RU that
is set as the default image for that Database version. If you want to create
a new Oracle Home with the RU that is higher or lower than the default
image, you first need to change the default image to match with the RU that
you want to create a new Oracle Home with by using Activating a Software
image.

• Viewing Information About Downloaded Software Images

You can view information about Oracle Database software images that are
downloaded to your Exadata Cloud@Customer environment by using the dbimage
list subcommand of the dbaascli utility.
• Viewing Information About Available Software Images
You can view information about Oracle Database software images that are
available to download to your Exadata Cloud@Customer environment by using
the cswlib list subcommand of the dbaascli utility.
• Downloading a Software Image
You can download available software images and make them available in
your Exadata Cloud@Customer environment by using the cswlib download
subcommand of the dbaascli utility.
• Activating a Software Image
You can use the following procedure to activate a specific software image, making
it the default software image for the corresponding software release in your
Exadata Cloud@Customer environment.
• Deleting a Software Image
You can use the following procedure to delete a software image from your Exadata
Cloud@Customer environment.
Related Topics
• Cloud Tooling Update

15-2
 Chapter 15
Administering Software Images

Viewing Information About Downloaded Software Images

You can view information about Oracle Database software images that are
downloaded to your Exadata Cloud@Customer environment by using the dbimage
list subcommand of the dbaascli utility.

1. Connect to a compute node as the opc user.

For detailed instructions, see Connecting to a Compute Node Through Secure
Shell (SSH).
2. Start a root-user command shell:

sudo -s

3. Run the dbaascli command with the dbimage list option:

dbaascli dbimage list

The command displays a list of software images that are downloaded to your
Exadata Cloud@Customer environment, including version and bundle patch
information.
4. Exit the root-user command shell:

exit

Related Topics
• Connecting to a Compute Node Through Secure Shell (SSH)

Viewing Information About Available Software Images

You can view information about Oracle Database software images that are available to
download to your Exadata Cloud@Customer environment by using the cswlib list
subcommand of the dbaascli utility.

1. Connect to a compute node as the opc user.

For detailed instructions, see Connecting to a Compute Node Through Secure
Shell (SSH).
2. Start a root-user command shell:

sudo -s

3. Run the dbaascli command with the cswlib list option:

dbaascli cswlib list

The command displays a list of available software images, including version and
bundle patch information that you can use to download the software image.

15-3
 Chapter 15
Administering Software Images

For more information about viewing available Oracle Database software images,
see dbaascli cswlib list in chapter Using the dbaascli Utility on Exadata
Cloud@Customer.
4. Exit the root-user command shell:

exit

Related Topics
• Connecting to a Compute Node Through Secure Shell (SSH)
• dbaascli cswlib list
To view information about Oracle Database software images that are available
to download to your Exadata Cloud@Customer environment, use the command
dbaascli cswlib list.

Downloading a Software Image

You can download available software images and make them available in your
Exadata Cloud@Customer environment by using the cswlib download subcommand
of the dbaascli utility.

1. Connect to a compute node as the opc user.

For detailed instructions, see Connecting to a Compute Node Through Secure
Shell (SSH).
2. Start a root-user command shell:

sudo -s

3. Run the dbaascli command with the cswlib download option:

dbaascli cswlib download --version software_version --bp

software_bp [--bp_update ( yes | no )] [--cdb ( yes | no )] [--
oss_uri download_location]

In the preceding command:

• software_version — specifies an Oracle Database software version. For
example, 11204, 12102, 12201, 18000, 19000.
• software_bp — identifies a bundle patch release. For example, APR2018,
JAN2019, OCT2019, and so on.
• --bp_update — optionally indicates whether the downloaded software image
becomes the current default software image. Default is no.
• --cdb — optionally specifies whether the downloaded software image
supports the Oracle multitenant architecture. Default is yes. If you specify --
cdb no, then a separate software image is downloaded that contains binaries
to support non-container databases (non-CDB).
4. Exit the root-user command shell:

exit

15-4
 Chapter 15
Administering Software Images

Related Topics
• Connecting to a Compute Node Through Secure Shell (SSH)

Activating a Software Image

You can use the following procedure to activate a specific software image, making
it the default software image for the corresponding software release in your Exadata
Cloud@Customer environment.
1. Connect to a compute node as the opc user.
For detailed instructions, see Connecting to a Compute Node Through Secure
Shell (SSH).
2. Start a root-user command shell:

sudo -s

3. Run the dbaascli command with the dbimage activateBP option:

dbaascli dbimage activateBP --version software_version --bp

software_bp [--cdb ( yes | no )]

In the preceding command:

• software_version — specifies the Oracle Database software version. For
example, 11204, 12102, 12201, 18000, 19000.
• software_bp — identifies the bundle patch release. For example, APR2018,
JAN2019, OCT2019, and so on.
• --cdb — optionally specifies whether to activate a software image that
supports the Oracle multitenant architecture. Default is yes. If you specify
--cdb no, then the command acts on the software image that contains
binaries to support non-container databases (non-CDB). Please note that Gen
2 ExaCC only supports non-CDB for 12.1 and 19c.
The command fails and outputs an error message if the specified software image
is not already downloaded to your Exadata Cloud@Customer environment.
4. Exit the root-user command shell:

exit

Related Topics
• Connecting to a Compute Node Through Secure Shell (SSH)

15-5
 Chapter 15
Administering Software Images

Deleting a Software Image

You can use the following procedure to delete a software image from your Exadata
Cloud@Customer environment.

WARNING:
If you delete an image that is not available on the Control Plane Server, you
may not be able to get it back. To check if the image you are planning to see
is available on the Control Plane Servers, use the dbaascli cswlib list
command. If the version you are purging is available on the Control Plane
Server, then you can use the dbaascli cswlib download command at a
later point in time to get the deleted image back.

1. Connect to a compute node as the opc user.

For detailed instructions, see Connecting to a Compute Node Through Secure
Shell (SSH).
2. Start a root-user command shell:

sudo -s

3. Run the dbaascli command with the dbimage purge option:

dbaascli dbimage purge --version software_version --bp software_bp

[--cdb ( yes | no )]

In the preceding command:

• software_version — specifies the Oracle Database software version. For
example, 11204, 12102, 12201, 18000, 19000.
• software_bp — identifies the bundle patch release. For example, APR2018,
JAN2019, OCT2019, and so on.
• --cdb — optionally specifies whether to remove the software image that
supports the Oracle multitenant architecture. Default is yes. If you specify
--cdb no, then the software image that contains binaries to support non-
container databases (non-CDB) is removed.
If the command will remove a software image that is not currently available in
the software image library, and therefore cannot be downloaded again, then the
command pauses and prompts for confirmation.
You cannot remove the current default software image for any software version. To
avoid this restriction, you must make another software image the current default
using the instructions in Activating a Software Image.
4. Exit the root-user command shell:

exit

15-6
 Chapter 15
Managing Oracle Database and Oracle Grid Infrastructure Patches

Related Topics
• Connecting to a Compute Node Through Secure Shell (SSH)
• Activating a Software Image
You can use the following procedure to activate a specific software image, making
it the default software image for the corresponding software release in your
Exadata Cloud@Customer environment.

Managing Oracle Database and Oracle Grid Infrastructure

Patches
You are responsible for routine patching of Oracle Database and Oracle Grid
Infrastructure software.
• About the dbaascli Utility
On Exadata Cloud@Customer, routine patching of the Oracle Database and
Oracle Grid Infrastructure software is facilitated by using the dbaascli utility.
• List Available Patches
To produce a list of available patches for Oracle Exadata Cloud@Customer, you
can use the dbaascli command.
• Check Prerequisites Before Applying a Patch
To list the prerequisites before applying a patch for Oracle Exadata
Cloud@Customer, run this procedure.
• Apply a Patch
To apply patches for Oracle Exadata Cloud@Customer., use the dbaascli
command.
• List Applied Patches
To list the applied patches for Oracle Exadata Cloud@Customer, use this
procedure.
• Roll Back a Patch
To roll back patches for Oracle Exadata Cloud@Customer, complete this
procedure.

About the dbaascli Utility

On Exadata Cloud@Customer, routine patching of the Oracle Database and Oracle
Grid Infrastructure software is facilitated by using the dbaascli utility.

The dbaascli utility provides a simple means for applying routine patches, which
Oracle periodically loads on to the Cloud Control Plane servers.
The dbaascli utility is part of the cloud-specific tooling bundle that is included with
Exadata Cloud@Customer. Therefore, before performing the following procedures,
ensure that you have the latest version of the cloud-specific tooling on all of the
compute nodes in the VM cluster by following the instructions in Cloud Tooling
Updates.
Related Topics
• Cloud Tooling Updates
You are responsible for updating the cloud-specific tooling included on the Exadata
Cloud@Customer Guest VMs.

15-7
 Chapter 15
Managing Oracle Database and Oracle Grid Infrastructure Patches

List Available Patches

To produce a list of available patches for Oracle Exadata Cloud@Customer, you can
use the dbaascli command.

1. Connect to a compute node as the opc user.

For detailed instructions, see Connecting to a Compute Node Through Secure
Shell (SSH).
2. Start a root user command shell:

sudo -s

3. Run the dbaascli patch db list command:

dbaascli patch db list --oh hostname:oracle_home

In the preceding command, --oh specifies a compute node and Oracle home
directory for which you want to list the available patches. In this context, an Oracle
home directory can be an Oracle Database home directory or the Oracle Grid
Infrastructure home directory.
For example:

dbaascli patch db list --oh hostname1:/u02/app/oracle/product/

12.1.0.2/dbhome_1

Note:
The list of available patches is determined by interrogating the database
to establish the patches that have already been applied. When a patch
is applied, the corresponding database entry is made as part of the
SQL patching operation, which is run at the end of the patch workflow.
Therefore, the list of available patches can include partially applied
patches along with patches that are currently being applied.

Related Topics
• Connecting to a Compute Node Through Secure Shell (SSH)

Check Prerequisites Before Applying a Patch

To list the prerequisites before applying a patch for Oracle Exadata Cloud@Customer,
run this procedure.
You can perform the prerequisites-checking operation using the dbaascli command
as follows:
1. Connect to a compute node as the opc user.
For detailed instructions, see Connecting to a Compute Node Through Secure
Shell (SSH).

15-8
 Chapter 15
Managing Oracle Database and Oracle Grid Infrastructure Patches

2. Start a root user command shell:

sudo -s

3. Run the dbaascli patch db prereq command:

• On a specific instance:

dbaascli patch db prereq --patchid patchid --instance1

hostname:oracle_home [--dbnames dbname[,dbname2 ...]]

• By specifying only database names:

dbaascli patch db prereq --patchid patchid --dbnames

dbname[,dbname2 ...] [-alldbs]

In the preceding commands:

– patchid identifies the patch to be pre-checked. .
– --instance1 specifies a compute node and Oracle Home directory that
is subject to the pre-check operation. In this context, an Oracle Home
directory may be an Oracle Database home directory or the Oracle Grid
Infrastructure home directory.
– --dbnames specifies the database names for the databases that are the
target of the pre-check operation.
– -alldbs specifies that you want to pre-check all of the databases that
share the same Oracle Database binaries (Oracle Home) as the specified
databases.
For example:

dbaascli patch db list --oh hostname1:/u02/app/oracle/product/

12.1.0.2/dbhome_1

Related Topics
• Connecting to a Compute Node Through Secure Shell (SSH)

15-9
 Chapter 15
Managing Oracle Database and Oracle Grid Infrastructure Patches

Apply a Patch
To apply patches for Oracle Exadata Cloud@Customer., use the dbaascli command.

Tip:
The default SSH configuration will close the terminal session after a few
minutes of inactivity, but some of the dbaascli patching commands (in
particular the patch db apply command) may take longer than the SSH
timeout. As a result, the terminal session where the patch db apply
command is running may be killed before the patching operation is complete
on all nodes.
To avoid this situation, use a utility like nohup or screen to avoid killing the
patching operation if the terminal connection is lost for any reason.
For example:

nohup dbaascli patch db apply 23456789 --

instance1 hostname1:/u02/app/oracle/product/12.1.0.2/dbhome_1
--run_datasql 1 >apply_23456789.out 2>&1 &

This example invokes the dbaascli command through the nohup wrapper
in the background, and redirects standard output and standard error to the
file apply_23456789.out. The command will keep running even if the
terminal gets killed. In that case, reconnect to the system and continue
monitoring apply_23456789.out for completion.

The dbaascli patching operation:

• Can be used to patch some or all of your compute nodes using one command.
• Coordinates multi-node patching in a rolling manner.
• Can run patch-related SQL after patching all the compute nodes in the cluster.
1. Connect to a compute node as the opc user.
For detailed instructions, see Connecting to a Compute Node Through Secure
Shell (SSH).
2. Start a root user command shell:

sudo -s

3. Run the command dbaascli patch db apply:

For example, on a specific instance, use this syntax:

dbaascli patch db apply --patchid patchid --instance1

hostname:oracle_home --dbnames dbname[,dbname2 ...]] [--run_datasql
1]

15-10
 Chapter 15
Managing Oracle Database and Oracle Grid Infrastructure Patches

By specifying only database names:

dbaascli patch db apply --patchid patchid --dbnames

dbname[,dbname2 ...] [--run_datasql 1] [-alldbs]

In the preceding commands:

• patchid identifies the patch to be applied.
• --instance1 specifies a compute node and Oracle home directory that is
subject to the patching operation. In this context, an Oracle home directory
can be an Oracle Database home directory or the Oracle Grid Infrastructure
home directory.
If you use this argument to specify a shared Oracle home directory, and you
do not specify the --dbnames argument, then all of the databases that share
the specified Oracle home are patched. After the operation, the Oracle home
directory location remains unchanged; however, the patch level information
embedded in the Oracle home name is adjusted to reflect the patching
operation.
• --dbnames specifies the database names for the databases that are the target
of the patching operation.
If you use this argument to patch a database that uses a shared Oracle
home, and you do not specify the -alldbs option, then a new Oracle home
containing the patched Oracle Database binaries is created and the database
is moved to the new Oracle home.
• -alldbs patches all of the databases that share the same Oracle Database
binaries (Oracle home as the databases specified in the --dbnames argument.
After the operation, the Oracle home directory location remains unchanged;
however, the patch level information embedded in the Oracle home name is
adjusted to reflect the patching operation.
• --run_datasql 1 instructs the command to run patch-related SQL commands.
– Only run patch-related SQL after all of the compute nodes are patched.
Take care not to specify this argument if you are patching a node, and
further nodes remain to be patched.
– This argument can only be specified with a patching operation on a
compute node. If you have patched all of your nodes, and you did not
specify this argument, then you must manually run the SQL commands
associated with the patch. Typically, running the SQL commands manually
involves running the catbundle.sql script for Oracle Database 11g, or the
datapatch utility for Oracle Database 12c, or later releases. Refer to the
patch documentation for full details.
For example:

dbaascli patch db apply 23456789 --instance1 hostname1:/u02/app/

oracle/product/12.1.0.2/dbhome_1 --run_datasql 1

Related Topics
• Connecting to a Compute Node Through Secure Shell (SSH)

15-11
 Chapter 15
Managing Oracle Database and Oracle Grid Infrastructure Patches

List Applied Patches

To list the applied patches for Oracle Exadata Cloud@Customer, use this procedure.
You can use the opatch utility to list the patches that have been applied to an Oracle
Database or Grid Infrastructure installation.
To produce a list of applied patches for an Oracle Database installation:
1. Connect to a compute node as the oracle user.
For detailed instructions, see Connecting to a Compute Node Through Secure
Shell (SSH).
2. Set the ORACLE_HOME variable to the location of the Oracle Database installation
you want to examine. For example:

export ORACLE_HOME=/u02/app/oracle/product/12.1.0.2/dbhome_1

3. Execute the opatch command with the lspatches option:

$ORACLE_HOME/OPatch/opatch lspatches

To produce a list of applied patches for Oracle Grid Infrastructure:

1. Connect to a compute node as the opc user.
For detailed instructions, see Connecting to a Compute Node Through Secure
Shell (SSH).
2. Start a root user command shell:

sudo -s

3. Become the grid user:

su - grid

4. Run the opatch command with the lspatches option:

$ORACLE_HOME/OPatch/opatch lspatches

Related Topics
• Connecting to a Compute Node Through Secure Shell (SSH)

Roll Back a Patch

To roll back patches for Oracle Exadata Cloud@Customer, complete this procedure.
To roll back a patch or a failed patch attempt, use the dbaascli command.

Rollback patch operations:

• Can be used to roll back a patch on some or all of your compute nodes using one
command.
• Coordinate multi-node operations in a rolling manner.

15-12
 Chapter 15
Managing Oracle Database and Oracle Grid Infrastructure Patches

• Can run rollback-related SQL after rolling back the patch on all the compute nodes
in the cluster.
1. Connect to a compute node as the opc user.
For detailed instructions, see Connecting to a Compute Node Through Secure
Shell (SSH).
2. Start a root user command shell:

sudo -s

3. Run the dbaascli command with the -rollback_async option:

• On specific instances:

dbaascli patch db switchback --patchid patchid --

instance1 hostname:oracle_home [--dbnames dbname[,dbname2 ...]]
[--run_datasql 1]

• By specifying only database names:

dbaascli patch db switchback --patchid patchid --dbnames

dbname[,dbname2 ...] [--run_datasql 1] [-alldbs]

In the preceding commands:

• --patchid identifies the patch that you want to roll back.
• --instance1 specifies the compute node host name and Oracle home
directory that is subject to the rollback operation. In this context, an Oracle
home directory can be either an Oracle Database home directory (Oracle
home), or the Oracle Grid Infrastructure (Grid home) directory.
If you use this argument to specify a shared Oracle home directory, and you
do not specify the --dbnames argument, then all of the databases that share
the specified Oracle home are rolled back.
• --dbnames specifies the database names for the databases that are the target
of the rollback operation.
• -alldbs specifies that you want to roll back all of the databases that share the
same Oracle Database binaries (Oracle home) as the databases specified in
the --dbnames argument.
• --run_datasql 1 instructs the command to run rollback-related SQL
commands.

15-13
 Chapter 15
Manually Patching Oracle Database and Oracle Grid Infrastructure Software

Note:

– Only run rollback-related SQL after all of the compute nodes are
rolled back. If you are rolling back a node, and further nodes
remain to be rolled back, then do not specify this argument.
– You can only specify this argument as part of a rollback
operation on a compute node. If you have rolled back all of your
nodes, and you did not specify this argument, then you must
run the SQL commands associated with the rollback operation
manually. Refer to the patch documentation for full details.

For example:

dbaascli patch db switchback 34567890 --instance1

hostname1:/u02/app/oracle/product/12.1.0.2/dbhome_1 --run_datasql 1

Related Topics
• Connecting to a Compute Node Through Secure Shell (SSH)

Manually Patching Oracle Database and Oracle Grid

Infrastructure Software
For Oracle Java VM, daylight savings time, and some routine or one-off patches, it can
be necessary for you to patch software manually.
To perform routine patching of Oracle Database and Oracle Grid Infrastructure
software, Oracle recommends that you use the facilities provided by Oracle Exadata
Cloud@Customer. However, under some circumstances, it can be necessary for you
to patch the Oracle Database or Oracle Grid Infrastructure software manually:
• Oracle Java Virtual Machine (OJVM) Patching: Because they cannot be applied
in a rolling fashion, patches for the Oracle Database OJVM component are not
included in the routine patch sets for Exadata Cloud@Customer. If you need to
apply patches to the OJVM component of Oracle Database, then you must do so
manually. See My Oracle Support Doc ID 1929745.1.
• Daylight Savings Time (DST) Patching: Because they cannot be applied in a
rolling fashion, patches for the Oracle Database DST definitions are not included
in the routine patch sets for Exadata Cloud@Customer. If you need to apply
patches to the Oracle Database DST definitions, you must do so manually. See
My Oracle Support Doc ID 412160.1.
• Non-routine or One-off Patching: If you encounter a problem that requires a
patch which is not included in any routine patch set, then work with Oracle Support
Services to identify and apply the appropriate patch.
For general information about patching Oracle Database, refer to information about
patch set updates and requirements in Oracle Database Upgrade Guide for your
release.

15-14
 Chapter 15
Updating the Guest VM Operating System

Related Topics
• https://support.oracle.com/epmos/faces/DocumentDisplay?
cmd=show&type=NOT&id=1929745.1
• https://support.oracle.com/epmos/faces/DocumentDisplay?
cmd=show&type=NOT&id=412160.1

Updating the Guest VM Operating System

Learn about standard Exadata tools and techniques you can use to update the
operating system components on the Exadata Cloud@Customer Guest VMs.
You are responsible for managing patches and updates to the operating system
environment on the compute node VMs. For further information, read about
updating Exadata Database Machine servers in Oracle Exadata Database Machine
Maintenance Guide.
• Preparing for an Operating System Update
To prepare for an operating system update for Oracle Exadata Cloud@Customer,
review this checklist of tasks.
• Updating the Operating System on All Compute Nodes of an Oracle Exadata
Cloud@Customer System
To update the operating system on the compute node virtual machines, use the
patchmgr tool.
• Installing Additional Operating System Packages
Review these guidelines before you install additional operating system packages
for Oracle Exadata Cloud@Customer.
Related Topics
• Updating Oracle Exadata Database Machine Database Servers

Preparing for an Operating System Update

To prepare for an operating system update for Oracle Exadata Cloud@Customer,
review this checklist of tasks.
Before you update your operating system, do each of these preparation tasks:
Determine the latest software update. Before you begin an update, to determine the
latest software to use, review Exadata Cloud Service Software Versions in My Oracle
Support note 2333222.1.
Related Topics
• https://support.oracle.com/epmos/faces/DocumentDisplay?
cmd=show&type=NOT&id=2333222.1

15-15
 Chapter 15
Updating the Guest VM Operating System

Updating the Operating System on All Compute Nodes of an Oracle

Exadata Cloud@Customer System
To update the operating system on the compute node virtual machines, use the
patchmgr tool.

Note:
Customers who do not have My Oracle Support patch download privilege
may obtain the Exadata patchmgr update utility and recent Exadata
System Software releases using the Exadata Cloud@Customer Gen 2 utility
exadata_updates.sh. For more information, see My Oracle Support Doc
2730739.1.

The patchmgr utility manages the entire update of one or more compute nodes
remotely, including the pre-restart, restart, and post-restart steps of an Oracle Exadata
Cloud@Customer system.
You can run the utility either from one of your Oracle Exadata Cloud@Customer
compute nodes, or from another server running Oracle Linux. The server on which you
run the utility is known as the driving system. You cannot use the driving system to
update itself. Therefore, if the driving system is one of the compute nodes in a VM
cluster that you are updating, then you must run the patchmgr utility more than once.
The following scenarios describe typical ways of performing the updates:
• Non-Exadata Driving System
The simplest way to run the update the system is to use a separate Oracle Linux
server to update all compute nodes in one operation.
• Exadata Compute Node Driving System
You can use one compute node to drive the updates for the rest of the compute
nodes in the VM cluster. Then, you can use one of the updated nodes to drive the
update on the original driving system. For example, consider updating a half rack
system with four compute nodes; node1, node2, node3, and node4. You could first
use node1 to drive the updates of node2, node3, and node4. Then, you could use
node2 to drive the update of node1.
The driving system requires root user SSH access to each compute node being
updated.
The following procedure is based on an example that assumes the following:
• The system has two compute nodes, node1 and node2.
• The target Exadata software version is 18.1.4.0.0.180125.3.
• Each node is used as the driving system to update the other node.
1. Gather the environment details.
a. Using SSH, connect to node1 as root and run the following command to
determine the current Exadata software version:

imageinfo -ver 12.2.1.1.4.171128

15-16
 Chapter 15
Updating the Guest VM Operating System

b. Switch to the grid user, and identify all nodes in the cluster.

su - grid

olsnodes
node1
node2

2. Configure the driving system.

a. Switch back to the root user on node1 and check whether an SSH key pair
(id_rsa and id_rsa.pub) exists. If not, then generate it.

ls /root/.ssh/id_rsa*
ls: cannot access /root/.ssh/id_rsa*: No such file or directory

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
93:47:b0:83:75:f2:3e:e6:23:b3:0a:06:ed:00:20:a5
[email protected]
The key's randomart image is:
+--[ RSA 2048]----+
|o.. + . |
|o. o * |
|E . o o |
| . . = |
| o . S = |
| + = . |
| + o o |
| . . + . |
| ... |
+-----------------+

b. Distribute the public key to the target nodes, and verify this step. In the
example, the only target node is node2.

scp -i ~root/.ssh/id_rsa.pub opc@node2:/tmp/id_rsa.node1.pub

ls -al /tmp/id_rsa.node1.pub
-rw-r--r-- 1 opc opc 442 Feb 28 03:33 /tmp/id_rsa.node1.pub

date
Wed Feb 28 03:33:45 UTC 2018

15-17
 Chapter 15
Updating the Guest VM Operating System

c. On the target node (node2 in the example), add the root public key of node1 to
the root authorized_keys file.

cat /tmp/id_rsa.node1.pub >> ~root/.ssh/authorized_keys

d. Download patchmgr into /root/patch on the driving system (node1 in this

example).
You can download the patchmgr bundle from Oracle Support by using My
Oracle Support Patch ID 21634633. Always obtain the latest available Exadata
patchmgr update utility to install any Exadata System Software release.
For further information, see also dbnodeupdate.sh and dbserver.patch.zip:
Updating Exadata Database Server Software using the DBNodeUpdate Utility
and patchmgr: My Oracle Support Doc ID 1553103.1.
e. Unzip the patchmgr bundle.
Depending on the version that you downloaded, the name of your ZIP file can
differ.

cd /root/patch/18.1.4.0.0.180125.3
unzip dbserver.patch.zip
Archive: p21634633_181400_Linux-x86-64.zip creating:
dbserver_patch_5.180228.2/
creating: dbserver_patch_5.180228.2/ibdiagtools/
inflating: dbserver_patch_5.180228.2/ibdiagtools/cable_check.pl
inflating: dbserver_patch_5.180228.2/ibdiagtools/setup-ssh
inflating: dbserver_patch_5.180228.2/ibdiagtools/VERSION_FILE
extracting: dbserver_patch_5.180228.2/ibdiagtools/xmonib.sh
inflating: dbserver_patch_5.180228.2/ibdiagtools/monitord
inflating: dbserver_patch_5.180228.2/ibdiagtools/checkbadlinks.pl
creating: dbserver_patch_5.180228.2/ibdiagtools/topologies/
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/
VerifyTopologyUtility.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/
verifylib.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/
Node.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/
Rack.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/
Group.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/
Switch.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topology-zfs
inflating: dbserver_patch_5.180228.2/ibdiagtools/dcli
creating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
remoteScriptGenerator.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
CommonUtils.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
SolarisAdapter.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
LinuxAdapter.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/

15-18
 Chapter 15
Updating the Guest VM Operating System

remoteLauncher.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
remoteConfig.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
spawnProc.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
runDiagnostics.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
OSAdapter.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/
SampleOutputs.txt
inflating: dbserver_patch_5.180228.2/ibdiagtools/infinicheck
inflating: dbserver_patch_5.180228.2/ibdiagtools/ibping_test
inflating: dbserver_patch_5.180228.2/ibdiagtools/tar_ibdiagtools
inflating: dbserver_patch_5.180228.2/ibdiagtools/verify-topology
inflating: dbserver_patch_5.180228.2/installfw_exadata_ssh
creating: dbserver_patch_5.180228.2/linux.db.rpms/
inflating: dbserver_patch_5.180228.2/md5sum_files.lst
inflating: dbserver_patch_5.180228.2/patchmgr
inflating: dbserver_patch_5.180228.2/xcp
inflating: dbserver_patch_5.180228.2/ExadataSendNotification.pm
inflating: dbserver_patch_5.180228.2/ExadataImageNotification.pl
inflating: dbserver_patch_5.180228.2/kernelupgrade_oldbios.sh
inflating: dbserver_patch_5.180228.2/cellboot_usb_pci_path
inflating: dbserver_patch_5.180228.2/exadata.img.env
inflating: dbserver_patch_5.180228.2/README.txt
inflating: dbserver_patch_5.180228.2/exadataLogger.pm
inflating: dbserver_patch_5.180228.2/patch_bug_26678971
inflating: dbserver_patch_5.180228.2/dcli
inflating: dbserver_patch_5.180228.2/patchReport.py
extracting: dbserver_patch_5.180228.2/dbnodeupdate.zip
creating: dbserver_patch_5.180228.2/plugins/
inflating: dbserver_patch_5.180228.2/plugins/010-
check_17854520.sh
inflating: dbserver_patch_5.180228.2/plugins/020-
check_22468216.sh
inflating: dbserver_patch_5.180228.2/plugins/040-
check_22896791.sh
inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_bash
inflating: dbserver_patch_5.180228.2/plugins/050-
check_22651315.sh
inflating: dbserver_patch_5.180228.2/plugins/005-
check_22909764.sh
inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_perl
inflating: dbserver_patch_5.180228.2/plugins/030-
check_24625612.sh
inflating: dbserver_patch_5.180228.2/patchmgr_functions
inflating: dbserver_patch_5.180228.2/exadata.img.hw
inflating: dbserver_patch_5.180228.2/libxcp.so.1
inflating: dbserver_patch_5.180228.2/imageLogger
inflating: dbserver_patch_5.180228.2/ExaXMLNode.pm
inflating: dbserver_patch_5.180228.2/fwverify

f. In the directory that contains the patchmgr utility, create the dbs_group file,
which contains the list of compute nodes to update. Include the nodes listed

15-19
 Chapter 15
Updating the Guest VM Operating System

after running the olsnodes command in step 1, except for the driving system.
In this example, dbs_group only contains node2.

cd /root/patch/18.1.4.0.0.180125.3/dbserver_patch_5.180228
cat dbs_group
node2

3. Run a patching precheck operation.

./patchmgr -dbnodes dbs_group -precheck -iso_repo zipped_iso_file

-target_version target-version -nomodify_at_prereq

Note:
Run the precheck operation with the -nomodify_at_prereq option to
prevent any changes to the system that could impact the backup you
take in the next step. Otherwise, the backup might not be able to roll the
system back to its original state, should it be necessary.

The output should look similar to the following example:

./patchmgr -dbnodes dbs_group -precheck -iso_repo /root/patch/

18.1.4.0.0.180125.3/exadata_ol6_18.1.4.0.0.180125.3_Linux-
x86-64.zip -target_version 18.1.4.0.0.180125.3 -nomodify_at_prereq

********************************************************************
****************************************
NOTE patchmgr release: 5.180228 (always check MOS 1553103.1 for
the latest release of dbserver.patch.zip)
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter
them.
********************************************************************
****************************************
2018-02-28 21:22:45 +0000 :Working: DO: Initiate precheck on
1 node(s)
2018-02-28 21:24:57 +0000 :Working: DO: Check free space and
verify SSH equivalence for the root user to node2
2018-02-28 21:26:15 +0000 :SUCCESS: DONE: Check free space
and verify SSH equivalence for the root user to node2
2018-02-28 21:26:47 +0000 :Working: DO: dbnodeupdate.sh
running a precheck on node(s).
2018-02-28 21:28:23 +0000 :SUCCESS: DONE: Initiate precheck
on node(s).

15-20
 Chapter 15
Updating the Guest VM Operating System

4. Back up the current system.

./patchmgr -dbnodes dbs_group -backup -iso_repo zipped_iso_file -

target_version target-version -allow_active_network_mounts

Note:
Ensure that you take the backup at this point, before any modifications
are made to the system.

The output should look similar to the following example:

./patchmgr -dbnodes dbs_group -backup -iso_repo /root/patch/

18.1.4.0.0.180125.3/exadata_ol6_18.1.4.0.0.180125.3_Linux-
x86-64.zip -target_version 18.1.4.0.0.180125.3 -
allow_active_network_mounts

********************************************************************
****************************************
NOTE patchmgr release: 5.180228 (always check MOS 1553103.1 for
the latest release of dbserver.patch.zip)
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter
them.
********************************************************************
****************************************
2018-02-28 21:29:00 +0000 :Working: DO: Initiate backup on 1
node(s).
2018-02-28 21:29:00 +0000 :Working: DO: Initiate backup on
node(s)
2018-02-28 21:29:01 +0000 :Working: DO: Check free space and
verify SSH equivalence for the root user to node2
2018-02-28 21:30:18 +0000 :SUCCESS: DONE: Check free space
and verify SSH equivalence for the root user to node2
2018-02-28 21:30:51 +0000 :Working: DO: dbnodeupdate.sh
running a backup on node(s).
2018-02-28 21:35:50 +0000 :SUCCESS: DONE: Initiate backup on
node(s).
2018-02-28 21:35:50 +0000 :SUCCESS: DONE: Initiate backup on
1 node(s).

5. Remove all custom RPMs from the target compute nodes. Custom RPMs are
reported in precheck results. They include RPMs that were manually installed after
the system was provisioned.
• If you are updating the system from version 12.1.2.3.4.170111, and the
precheck results include krb5-workstation-1.10.3-57.el6.x86_64, then
remove it. This item is considered a custom RPM for this version.

15-21
 Chapter 15
Updating the Guest VM Operating System

• Do not remove exadata-sun-vm-computenode-exact or oracle-ofed-

release-guest. These two RPMs are handled automatically during the update
process.
6. Perform the update. To ensure that the update process in not interrupted, use the
command nohup. For example:

nohup ./patchmgr -dbnodes dbs_group -upgrade -nobackup

-iso_repo zipped_iso_file -target_version target-version -
allow_active_network_mounts &

The output should look similar to the following example:

nohup ./patchmgr -dbnodes dbs_group -upgrade -nobackup -iso_repo /

root/patch/18.1.4.0.0.180125.3/
exadata_ol6_18.1.4.0.0.180125.3_Linux-x86-64.zip -target_version
18.1.4.0.0.180125.3 -allow_active_network_mounts &

********************************************************************
****************************************
NOTE patchmgr release: 5.180228 (always check MOS 1553103.1 for
the latest release of dbserver.patch.zip)
NOTE
NOTE Database nodes will reboot during the update process.
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter
them.
********************************************************************
*************************************
2018-02-28 21:36:26 +0000 :Working: DO: Initiate prepare
steps on node(s).
2018-02-28 21:36:26 +0000 :Working: DO: Check free space and
verify SSH equivalence for the root user to node2
2018-02-28 21:37:44 +0000 :SUCCESS: DONE: Check free space
and verify SSH equivalence for the root user to node2
2018-02-28 21:38:43 +0000 :SUCCESS: DONE: Initiate prepare
steps on node(s).
2018-02-28 21:38:43 +0000 :Working: DO: Initiate update on 1
node(s).
2018-02-28 21:38:43 +0000 :Working: DO: Initiate update on
node(s)
2018-02-28 21:38:49 +0000 :Working: DO: Get information
about any required OS upgrades from node(s).
2018-02-28 21:38:59 +0000 :SUCCESS: DONE: Get information
about any required OS upgrades from node(s).
2018-02-28 21:38:59 +0000 :Working: DO: dbnodeupdate.sh
running an update step on all nodes.
2018-02-28 21:48:41 +0000 :INFO : node2 is ready to reboot.
2018-02-28 21:48:41 +0000 :SUCCESS: DONE: dbnodeupdate.sh
running an update step on all nodes.
2018-02-28 21:48:41 +0000 :Working: DO: Initiate reboot on
node(s)

15-22
 Chapter 15
Updating the Guest VM Operating System

2018-02-28 21:48:57 +0000 :SUCCESS: DONE: Initiate reboot on

node(s)
2018-02-28 21:48:57 +0000 :Working: DO: Waiting to ensure
node2 is down before reboot.
2018-02-28 21:56:18 +0000 :Working: DO: Initiate prepare
steps on node(s).
2018-02-28 21:56:19 +0000 :Working: DO: Check free space and
verify SSH equivalence for the root user to node2
2018-02-28 21:57:37 +0000 :SUCCESS: DONE: Check free space
and verify SSH equivalence for the root user to node2
2018-02-28 21:57:42 +0000 :SEEMS ALREADY UP TO DATE: node2
2018-02-28 21:57:43 +0000 :SUCCESS: DONE: Initiate update on
node(s)

7. After the update operation completes, verify the version of the Exadata software
on the compute node that was updated.

imageinfo -ver
18.1.4.0.0.180125.3

8. Repeat steps 2 through 7 of this procedure using the updated compute node as
the driving system to update the remaining compute node. In this example update,
you would now use node2 to update node1.
9. As root On each compute node, run the uptrack-install command to install the
available ksplice updates.

uptrack-install --all -y

uptrack-install --all -y

Related Topics
• https://support.oracle.com/epmos/faces/DocumentDisplay?
cmd=show&type=NOT&id=2730739.1
• https://support.oracle.com/epmos/faces/DocumentDisplay?
cmd=show&type=NOT&id=1553103.1
• https://support.oracle.com/epmos/faces/DocumentDisplay?
cmd=show&type=NOT&id=21634633

Installing Additional Operating System Packages

Review these guidelines before you install additional operating system packages for
Oracle Exadata Cloud@Customer.
You are permitted to install and update operating system packages on Oracle
Exadata Cloud@Customer as long as you do not modify the kernel or InfiniBand-
specific packages. However, Oracle technical support, including installation, testing,
certification and error resolution, does not apply to any non-Oracle software that you
install.
Also be aware that if you add or update packages separate from an Oracle
Exadata software update, then these package additions or updates can introduce
problems when you apply an Oracle Exadata software update. Problems can occur

15-23
 Chapter 15
Cloud Tooling Updates

because additional software packages add new dependencies that can interrupt an
Oracle Exadata update. For this reason, Oracle recommends that you minimize
customization.
If you install additional packages, then Oracle recommends that you have scripts to
automate the removal and reinstallation of those packages. After an Oracle Exadata
update, if you install additional packages, then verify that the additional packages are
still compatible, and that you still need these packages.
For more information, refer to Oracle Exadata Database Machine Maintenance Guide.
Related Topics
• Installing, Updating and Managing Non-Oracle Software

Cloud Tooling Updates

You are responsible for updating the cloud-specific tooling included on the Exadata
Cloud@Customer Guest VMs.

Note:
You can update the cloud-specific tooling by downloading and applying a
software package containing the updated tools.

• Checking the Installed Cloud Tooling Release for Updates

To check the installed cloud tooling release for Oracle Exadata Cloud@Customer,
complete this procedure.
• Updating the Cloud Tooling Release
To update the cloud tooling release for Oracle Exadata Cloud@Customer,
complete this procedure.

Checking the Installed Cloud Tooling Release for Updates

To check the installed cloud tooling release for Oracle Exadata Cloud@Customer,
complete this procedure.
To check the installed cloud tooling release for updates:
1. Connect to a compute node as the opc user.
For detailed instructions, see Connecting to a Compute Node Through Secure
Shell (SSH).
2. Start a root user command shell:

sudo -s

3. Run the following command to display information about the installed cloud
tooling, and to list the available updates:

dbaascli patch tools list

The command output displays:

15-24
 Chapter 15
Cloud Tooling Updates

• The version of the cloud tooling that is installed on the compute node.
• The list of available updates.
• Notification of the cloud tooling version that is installed on the other compute
nodes in the VM cluster.
Related Topics
• Connecting to a Compute Node Through Secure Shell (SSH)

Updating the Cloud Tooling Release

To update the cloud tooling release for Oracle Exadata Cloud@Customer, complete
this procedure.
To update the cloud tooling release:
1. Connect to a compute node as the opc user.
For detailed instructions, see Connecting to a Compute Node Through Secure
Shell (SSH).
2. Start a root user command shell:

sudo -s

3. Download and apply the cloud tooling update:

• To update to the latest available cloud tooling release, run the following
command:

dbaascli patch tools apply --patchid LATEST

• To update to a specific cloud tooling release, run the following command:

dbaascli patch tools apply --patchid patchid

In the preceding command, patchid is a cloud tooling patch identifier, as

reported in the output of the dbaascli patch tools list command.
The cloud tooling update is applied to all nodes in the VM cluster.
Related Topics
• Connecting to a Compute Node Through Secure Shell (SSH)

15-25
16
Managing Exadata Resources with Oracle
Enterprise Manager Cloud Control
To manage and monitor Exadata Cloud and Exadata Cloud@Customer resources, use
Oracle Enterprise Manager Cloud Control.
For complete documentation and Oracle By Example tutorials, see the following
documentation resources: Oracle Enterprise Manager Cloud Control for Oracle
Exadata Cloud and Setting Up Oracle Enterprise Manager 13.4 on Oracle Cloud
Infrastructure.
• Overview of Oracle Enterprise Manager Cloud Control
Oracle Enterprise Manager Cloud Control provides a complete lifecycle
management solution for Oracle Cloud Infrastructure's Exadata Cloud and
Exadata Cloud@Customer services.
• Features of Enterprise Manager Cloud Control
Familiarize yourself with the features of Enterprise Manager Cloud Control to
manage and monitor Exadata Cloud and Exadata Cloud@Customer resources.
Related Topics
• Oracle Enterprise Manager Cloud Control for Oracle Exadata Cloud
• Setting Up Oracle Enterprise Manager 13.4 on Oracle Cloud Infrastructure

Overview of Oracle Enterprise Manager Cloud Control

Oracle Enterprise Manager Cloud Control provides a complete lifecycle
management solution for Oracle Cloud Infrastructure's Exadata Cloud and Exadata
Cloud@Customer services.
Enterprise Manager Cloud Control discovers Exadata Cloud and Exadata
Cloud@Customer services as a single target and automatically identifies and
organizes all dependent components. Using Enterprise Manager Cloud Control you
can then:
• Monitor and manage all Exadata, Exadata Cloud and Exadata Cloud@Customer
systems, along with any other targets, from a single interface
• Visualize storage and compute data
• View performance metrics of your Exadata components

16-1
 Chapter 16
Features of Enterprise Manager Cloud Control

Features of Enterprise Manager Cloud Control

Familiarize yourself with the features of Enterprise Manager Cloud Control to manage
and monitor Exadata Cloud and Exadata Cloud@Customer resources.

Enterprise Manager Target for Exadata Cloud

The target for Oracle Cloud Infrastructure Exadata resources, which covers both
Exadata Cloud and Exadata Cloud@Customer does the following:
• Automatically identifies and organizes related targets.
• Provides a high-level integration point for Enterprise Manager framework features
such as incident rules, groups, notifications, and monitoring templates.

Improved Performance Monitoring

Enterprise Manager Cloud Control enhances performance monitoring in the following
ways:
• Adds Exadata Storage Server and Exadata Storage Grid targets.
• Offers visualization of storage and compute performance for your Exadata Cloud
and Exadata Cloud@Customer resources.
• Enables use of the same Maximum Availability Architecture (MAA) key
performance indicators (KPI) developed for Oracle Exadata Database Machine.

Scripted CLI-based Discovery

Enterprise Manager Cloud Control uses scripts to discover Oracle Cloud Infrastructure
Exadata resources. Scripts comb the existing hosts, clusters, ASM, databases and
related targets, as well as adding the storage server targets.

"Single Pane of Glass" View of On-Premises and Oracle Cloud Infrastructure

Exadata Resources
Enterprise Manager Cloud Control 's use of a single Exadata target type provides a
consistent Enterprise Manager experience across on-premises, Exadata Cloud, and
Exadata Cloud@Customer resources. The common Exadata target menu allows you
to easily navigate to, monitor and manage all of your Exadata systems.

Visualization
Enterprise Manager Cloud Control allows you to visualize the database and related
targets associated with each Exadata Cloud and Exadata Cloud@Customer system.

16-2
17
Exadata Cloud@Customer Gen1 to Out-
of-Place Cloud Upgrade to Exadata
Cloud@Customer Gen2 Infrastructure

• Overview of Exadata Cloud@Customer Gen1 to Out-of-Place Cloud Upgrade to

Exadata Cloud@Customer Gen2 Infrastructure
• Scope for Exadata Cloud@Customer Gen1 to Gen2 Out-of-Place Cloud Upgrade
• Hardware and Software Required for Out-of-Place Cloud Upgrade to New Exadata
Cloud@Customer X8M Gen2 Infrastructure
Review this checklist to prepare for the out-of-place cloud upgrade to new Gen2
infrastructure:
• Using Oracle Zero Downtime Migration (ZDM) to Migrate Oracle Databases
Use ZDM to migrate Oracle databases from Exadata Cloud@Customer Gen1 to
Exadata Cloud@Customer Gen2 infrastructure.
• During Out-of-Place Cloud Upgrade to New Exadata Cloud@Customer X8M Gen2
Infrastructure
• Post Out-of-Place Cloud Upgrade to New Exadata Cloud@Customer X8M Gen2
Infrastructure
The upgrade will move your resources into Exadata Cloud@Customer Gen 2
Cloud Control Plane and onto the new generation hardware.
• Best Practices for Out-of-Place Cloud Upgrade to New Exadata Cloud@Customer
X8M Gen2 Infrastructure
For the purpose of the upgrade, the recommended tool to use is Oracle Zero
Downtime Migration (ZDM).
• Out-of-Place Cloud Upgrade to New Exadata Cloud@Customer X8M Gen2
Infrastructure Known Issues
Understand the known issues when performing Exadata Cloud@Customer Gen1
to out-of-place cloud upgrade to new Exadata Cloud@Customer X8M Gen2
infrastructure.

Overview of Exadata Cloud@Customer Gen1 to Out-of-

Place Cloud Upgrade to Exadata Cloud@Customer Gen2
Infrastructure
Gen1 is the first generation of Exadata Cloud@Customer, which is deployed in
conjunction with Gen1 Oracle Cloud At Customer (OCC) as Control Plane deployed in
the customer data center. Exadata Cloud@Customer Gen2 is managed from Oracle
Cloud Infrastructure (OCI) Control Plane, which runs in OCI public cloud.

17-1
 Chapter 17
Scope for Exadata Cloud@Customer Gen1 to Gen2 Out-of-Place Cloud Upgrade

Out-of-Place Cloud Upgrade to Exadata Cloud@Customer Gen2 Infrastructure:

If you are running Exadata Cloud@Customer Gen1 on X6 or X7 infrastructure,
with this offering Oracle will replace Gen1 X6 or X7 infrastructure with new
Gen2 Exadata Cloud@Customer X8M infrastructure, and provide instructions to
use Oracle Zero Downtime Migration (ZDM) to migrate your databases to Exadata
Cloud@Customer Gen2 platform. Replacing your Exadata Cloud@Customer Gen1 X6
or X7 infrastructure and migrating your databases to the Exadata Cloud@Customer
Gen2 platform is called an out-of-place cloud upgrade. This document explores the
requirements and outlines the procedure to perform an out-of-place cloud upgrade to
the new Gen2 Exadata Cloud@Customer X8M infrastructure.

Scope for Exadata Cloud@Customer Gen1 to Gen2 Out-of-

Place Cloud Upgrade
• Exadata Cloud@Customer X6 and X7 System Shapes are eligible for the out-of-
place upgrade.
• Databases on Exadata Cloud@Customer Gen1 which participate in a Data Guard
configuration are supported by migration. In this case, the primary should be
migrated to Exadata Cloud@Customer Gen2 using the regular procedure. Once
migration is done, the Data Guard configuration should be set up on the Exadata
Cloud@Customer Gen2 side using the regular Gen2 procedure.
• Upgrade from Exadata Cloud@Customer Gen1 to Gen2 is done only when the
software versions are compatible on the source and target systems.
– Oracle Database software: The source and target must be at the same major
version. For example, both the source and target must be at version 19c.
However, the target can have a higher patch level than the source. For
example, the patch versions can be 19.3 for the source and 19.8 for the target.
The corresponding equivalence for 12.2 is, both source and the target must
be at Oracle Database software version 12.2.0.1, but the patch levels can be
2019JulyRU on the source and 2020OctRU on the target.
– Non-Container Database (CDB) to non-CDB.
– Multitenant deployment (CDB/PDB) to Multitenant deployment (CDB/PDB).
– Single-instance Oracle Database: After migration, single-instance database
source will be converted to Oracle Real Application Clusters (Oracle RAC)
database on the target.
• Permitted differences in software versions include:
– Oracle Grid Infrastructure
– Exadata software
– Guest VM operating system
– DBaaS tools
• Oracle Databases created on Exadata Cloud@Customer Gen1 using backend
tools, dbaasapi and dbaascli, are supported as well besides Oracle Databases
created using the Gen1 Console.
• All supported versions of Oracle Database on Exadata Cloud@Customer Gen1
are supported and will be migrated to the same major version on the target.
The Gen2 environment will be on the latest supported version of Exadata

17-2
 Chapter 17
Hardware and Software Required for Out-of-Place Cloud Upgrade to New Exadata Cloud@Customer X8M Gen2 Infrastructure

Cloud@Customer gen2 for the Guest VM operating system and Oracle Grid
Infrastructure.
Note that the following are not in scope for the out-of-place cloud upgrade to new gen2
hardware:
• Exadata Cloud@Customer Gen1 deployment using Exadata Cloud@Customer
Gen1 features not yet available on Gen2 are not expected to use the upgrade
procedures until the relevant feature or equivalent is available on Gen2.
• Only Exadata Cloud@Customer upgrade is in scope as part of the procedure
here. Upgrade or migration of OCC itself is not in the scope.
• You can reverse the upgrade until both the primary and secondary hardware is
at your site. Loss of data is possible depending on the application usage and
cutover time. Once the Exadata Cloud@Customer Gen1 hardware is shipped back
to Oracle, you cannot reverse the upgrade and you cannot revert to Exadata
Cloud@Customer Gen1 as well.

Hardware and Software Required for Out-of-Place Cloud

Upgrade to New Exadata Cloud@Customer X8M Gen2
Infrastructure
Review this checklist to prepare for the out-of-place cloud upgrade to new Gen2
infrastructure:
• Setup Exadata Cloud@Customer Gen2 Environment
A functioning base Exadata Cloud@Customer Gen2 deployment is a prerequisite
for starting any Exadata Cloud@Customer Gen1 to Gen2 out-of-place cloud
upgrade.
For more information to setup your Gen2 Exadata Cloud@Customer, see
Preparing for Exadata Cloud@Customer.
• Setup Hardware to Migrate Oracle Databases using ZDM
For more information, see:
– Prepare a Host for Zero Downtime Migration Software Installation
– NFS Storage guidelines in Best Practices. It's your responsibility to provide
NAS storage with free space up to a minimum of one database backup
required for the chosen ZDM migration strategy.
• Configure network
– Provide network access path from the Exadata Cloud@Customer Gen1
servers and the Gen2 servers to the ZDM and NFS servers used for the
upgrade.
– Provide network access and SSH access from the ZDM server to the
respective Exadata Cloud@Customer infrastructure.
– For any client access to the target databases, ensure that a network path
is available from the client host to the new Exadata Cloud@Customer Gen2
deployed databases.
• Software

17-3
 Chapter 17
Using Oracle Zero Downtime Migration (ZDM) to Migrate Oracle Databases

– The upgrade will require minimum versions of the software stack so prior to
the upgrade, install the appropriate version of Oracle Grid Infrastructure on the
target Exadata Cloud@Customer Gen2 infrastructure.
– Oracle Database versions supported on Exadata Cloud@Customer Gen1 will
continue to be supported. On the target Gen2 infrastructure, install appropriate
versions of the Oracle Database software and the one-off patches that exist in
the source database.
– Complete all requirements for ZDM servers in terms of installation,
configuration, network access, and SSH access.
• Security
– Exadata Cloud@Customer Gen2 does not use Oracle Advanced Support
Gateway Security (OASG) so cannot request OASG logs.
• Ensure that automatic backup is not configured on the Gen2 target prior to
migration.
Related Topics
• Preparing for Exadata Cloud@Customer
• Prepare a Host for Zero Downtime Migration Software Installation
• Best Practices for Out-of-Place Cloud Upgrade to New Exadata Cloud@Customer
X8M Gen2 Infrastructure
For the purpose of the upgrade, the recommended tool to use is Oracle Zero
Downtime Migration (ZDM).

Using Oracle Zero Downtime Migration (ZDM) to Migrate

Oracle Databases
Use ZDM to migrate Oracle databases from Exadata Cloud@Customer Gen1 to
Exadata Cloud@Customer Gen2 infrastructure.
To familiarize yourself with the features of ZDM, see Setting Up Zero Downtime
Migration Software. As the first step, download, install and configure ZDM on the host
identified for the ZDM server.
Offline Migration: In Offline migration, RMAN backup/restore is used as the primary
means of migration. It is necessary that the source database be quiesced (no updates)
during the final incremental backup/restore phase of the migration so as to not lose
any changes to the data during the migration. Once migration is completed, the
target database should be enabled for updates and all database clients must now
be connecting to the Gen2 target database. Offline migration does NOT need direct
sqlnet network connectivity between the source and target databases.

Online Migration: In Online migration, ZDM uses RMAN to complete a full backup/
restore of the database to the target, and then automatically sets up a Data Guard
configuration between the source and target databases. The customer can pause
the migration in a "live" manner, that is, pause the ZDM operation while the source
as Primary and target as Standby are in continuous sync. At the desired time, the
customer can resume the migration to allow a switchover between the source and
the target so that the target database becomes the Primary and the source database
becomes a Standby. Online migration requires that there be direct or indirect (through
bastion) sqlnet connectivity between the source and target databases.

17-4
 Chapter 17
Using Oracle Zero Downtime Migration (ZDM) to Migrate Oracle Databases

For more information, see:

• Introduction to Zero Downtime Migration
• Setting Up Zero Downtime Migration Software
• Preparing for Database Migration
• Migrating Your Database with Zero Downtime Migration
Example 17-1 Offline Migration

zdmcli migrate database -sourcedb z18tgt1 \

-sourcenode scaqae08dv0706 -srcauth zdmauth \

-srcarg1 user:opc \
-srcarg2 identity_file:/home/giusr/.ssh/id_gen1vm \
-srcarg3 sudo_location:/usr/bin/sudo \

-targetnode mvm1 -tgtauth zdmauth \

-tgtarg1 user:opc \
-tgtarg2 identity_file:/home/giusr/.ssh/racteam_rsa \
-tgtarg3 sudo_location:/usr/bin/sudo \

-rsp /home/giusr/zdm_offline_18c.rsp \

-schedule NOW -tdekeystorepasswd -pauseAfter ZDM_BACKUP_DIFFERENTIAL_SRC

ZDM_GET_SRC_INFO ............... COMPLETED

ZDM_GET_TGT_INFO ............... COMPLETED
ZDM_SETUP_SRC .................. COMPLETED
ZDM_SETUP_TGT .................. COMPLETED
ZDM_PREUSERACTIONS ............. COMPLETED
ZDM_PREUSERACTIONS_TGT ......... COMPLETED
ZDM_VALIDATE_SRC ............... COMPLETED
ZDM_VALIDATE_TGT ............... COMPLETED
ZDM_BACKUP_FULL_SRC ............ COMPLETED
ZDM_BACKUP_INCREMENTAL_SRC ..... COMPLETED
ZDM_DISCOVER_SRC ............... COMPLETED
ZDM_COPYFILES .................. COMPLETED
ZDM_PREPARE_TGT ................ COMPLETED
ZDM_SETUP_TDE_TGT .............. COMPLETED
ZDM_OSS_RESTORE_TGT ............ COMPLETED
ZDM_BACKUP_DIFFERENTIAL_SRC .... COMPLETED
ZDM_OSS_RECOVER_TGT ............ COMPLETED
ZDM_FINALIZE_TGT ............... COMPLETED
ZDM_POST_DATABASE_OPEN_TGT ..... COMPLETED
ZDM_DATAPATCH_TGT .............. COMPLETED
ZDM_MANIFEST_TO_CLOUD .......... COMPLETED
ZDM_POSTUSERACTIONS ............ COMPLETED
ZDM_POSTUSERACTIONS_TGT ........ COMPLETED
ZDM_CLEANUP_SRC ................ COMPLETED
ZDM_CLEANUP_TGT ................ STARTED

17-5
 Chapter 17
Using Oracle Zero Downtime Migration (ZDM) to Migrate Oracle Databases

Example 17-2 Offline Migration Response File

TGT_DB_UNIQUE_NAME=z19tgt1_uniq
MIGRATION_METHOD=BACKUP_RESTORE_NFS
PLATFORM_TYPE=EXACC
SRC_HTTP_PROXY_URL=
SRC_HTTP_PROXY_PORT=
SRC_CONFIG_LOCATION=
SRC_BASTION_HOST_IP=
SRC_BASTION_PORT=
SRC_BASTION_USER=
SRC_BASTION_IDENTITY_FILE=
SRC_TIMEZONE=
SRC_OSS_PROXY_HOST=
SRC_OSS_PROXY_PORT=
SRC_SSH_RETRY_TIMEOUT=
TGT_HTTP_PROXY_URL=
TGT_HTTP_PROXY_PORT=
TGT_CONFIG_LOCATION=
TGT_BASTION_HOST_IP=
TGT_BASTION_PORT=
TGT_BASTION_USER=
TGT_BASTION_IDENTITY_FILE=
TGT_HOST_IP=
TGT_SSH_TUNNEL_PORT=
TGT_SSH_RETRY_TIMEOUT=
TGT_OSS_PROXY_HOST=
TGT_OSS_PROXY_PORT=
TGT_DATADG=+DATAC2
TGT_REDODG=+RECOC2
TGT_RECODG=+RECOC2
TGT_DATAACFS=
TGT_REDOACFS=
TGT_RECOACFS=
BACKUP_PATH=/zdmnfs/
HOST=
OPC_CONTAINER=
SRC_ZDLRA_WALLET_LOC=
TGT_ZDLRA_WALLET_LOC=
ZDLRA_CRED_ALIAS=
SKIP_FALLBACK=TRUE
TGT_RETAIN_DB_UNIQUE_NAME=
TGT_SKIP_DATAPATCH=FALSE
MAX_DATAPATCH_DURATION_MINS=
DATAPATCH_WITH_ONE_INSTANCE_RUNNING=
SHUTDOWN_SRC=
SKIP_SRC_SERVICE_RETENTION=
SRC_RMAN_CHANNELS=6
TGT_RMAN_CHANNELS=16
ZDM_LOG_OSS_PAR_URL=
ZDM_BACKUP_FULL_SRC_MONITORING_INTERVAL=10
ZDM_BACKUP_INCREMENTAL_SRC_MONITORING_INTERVAL=10
ZDM_BACKUP_DIFFERENTIAL_SRC_MONITORING_INTERVAL=10
ZDM_CLONE_TGT_MONITORING_INTERVAL=10
ZDM_OSS_RESTORE_TGT_MONITORING_INTERVAL=10

17-6
 Chapter 17
Using Oracle Zero Downtime Migration (ZDM) to Migrate Oracle Databases

ZDM_OSS_RECOVER_TGT_MONITORING_INTERVAL=10
ZDM_BACKUP_RETENTION_WINDOW=
ZDM_OPC_RETRY_WAIT_TIME=
ZDM_OPC_RETRY_COUNT=
ZDM_SRC_TNS_ADMIN=
ZDM_CURL_LOCATION=
ZDM_USE_EXISTING_UNDO_SIZE=
ZDM_SKIP_DG_CONFIG_CLEANUP=
ZDM_RMAN_COMPRESSION_ALGORITHM=LOW

Example 17-3 Online Migration

Note:
To control and manage the migration steps, we strongly recommend
pausing the migration job. To add the pause, include the parameter -
pauseafter in your ZDM migration command zdmcli migrate database
-pauseafter ZDM_CONFIGURE_DG_SRC. For more information, see https://
support.oracle.com/epmos/faces/DocContentDisplay?id=2562063.1.

zdmcli migrate database -sourcedb z18tgt1 \

-sourcenode scaqae08dv0706 -srcauth zdmauth \

-srcarg1 user:opc \
-srcarg2 identity_file:/home/giusr/.ssh/id_gen1vm \
-srcarg3 sudo_location:/usr/bin/sudo \

-targetnode mvm1 -tgtauth zdmauth \

-tgtarg1 user:opc \
-tgtarg2 identity_file:/home/giusr/.ssh/racteam_rsa \
-tgtarg3 sudo_location:/usr/bin/sudo

-rsp /home/giusr/zdm_online_18c.rsp \

-schedule NOW -sourcesyswallet /scratch/app/zdm/bin/sysWallet

-tdekeystorewallet /scratch/app/zdm/bin/tdeWallet -pauseAfter
ZDM_BACKUP_DIFFERENTIAL_SRC

Scheduled job execution start time: 2021-02-01T03:12:09Z. Equivalent

local time: 2021-02-01 03:12:09
Current status: SUCCEEDED
Result file path: "/scratch/app/base/chkbase/scheduled/
job-11-2021-02-01-03:12:19.log"
Job execution start time: 2021-02-01 03:12:19
Job execution end time: 2021-02-01 05:51:42
Job execution elapsed time: 2 hours 39 minutes 23 seconds
ZDM_GET_SRC_INFO .............. COMPLETED
ZDM_GET_TGT_INFO .............. COMPLETED
ZDM_SETUP_SRC ................. COMPLETED
ZDM_SETUP_TGT ................. COMPLETED
ZDM_PREUSERACTIONS ............ COMPLETED
ZDM_PREUSERACTIONS_TGT ........ COMPLETED

17-7
 Chapter 17
Using Oracle Zero Downtime Migration (ZDM) to Migrate Oracle Databases

ZDM_VALIDATE_SRC .............. COMPLETED

ZDM_VALIDATE_TGT .............. COMPLETED
ZDM_BACKUP_FULL_SRC ........... COMPLETED
ZDM_BACKUP_INCREMENTAL_SRC .... COMPLETED
ZDM_DISCOVER_SRC .............. COMPLETED
ZDM_COPYFILES ................. COMPLETED
ZDM_PREPARE_TGT ............... COMPLETED
ZDM_SETUP_TDE_TGT ............. COMPLETED
ZDM_CLONE_TGT ................. COMPLETED
ZDM_FINALIZE_TGT .............. COMPLETED
ZDM_CONFIGURE_DG_SRC .......... COMPLETED
ZDM_SWITCHOVER_SRC ............ COMPLETED
ZDM_SWITCHOVER_TGT ............ COMPLETED
ZDM_POST_DATABASE_OPEN_TGT .... COMPLETED
ZDM_DATAPATCH_TGT ............. COMPLETED
ZDM_MANIFEST_TO_CLOUD ......... COMPLETED
ZDM_POSTUSERACTIONS ........... COMPLETED
ZDM_POSTUSERACTIONS_TGT ....... COMPLETED
ZDM_CLEANUP_SRC ............... COMPLETED
ZDM_CLEANUP_TGT ............... COMPLETED

Example 17-4 Online Migration Response File

TGT_DB_UNIQUE_NAME=z19tgt1_uniq
MIGRATION_METHOD=DG_STORAGEPATH
PLATFORM_TYPE=EXACC
SRC_HTTP_PROXY_URL=
SRC_HTTP_PROXY_PORT=
SRC_CONFIG_LOCATION=
SRC_BASTION_HOST_IP=
SRC_BASTION_PORT=
SRC_BASTION_USER=
SRC_BASTION_IDENTITY_FILE=
SRC_TIMEZONE=
SRC_OSS_PROXY_HOST=
SRC_OSS_PROXY_PORT=
SRC_SSH_RETRY_TIMEOUT=
TGT_HTTP_PROXY_URL=
TGT_HTTP_PROXY_PORT=
TGT_CONFIG_LOCATION=
TGT_BASTION_HOST_IP=
TGT_BASTION_PORT=
TGT_BASTION_USER=
TGT_BASTION_IDENTITY_FILE=
TGT_HOST_IP=
TGT_SSH_TUNNEL_PORT=
TGT_SSH_RETRY_TIMEOUT=
TGT_OSS_PROXY_HOST=
TGT_OSS_PROXY_PORT=
TGT_DATADG=+DATAC2
TGT_REDODG=+RECOC2
TGT_RECODG=+RECOC2
TGT_DATAACFS=
TGT_REDOACFS=

17-8
 Chapter 17
During Out-of-Place Cloud Upgrade to New Exadata Cloud@Customer X8M Gen2 Infrastructure

TGT_RECOACFS=
BACKUP_PATH=/zdmnfs/
HOST=
OPC_CONTAINER=
SRC_ZDLRA_WALLET_LOC=
TGT_ZDLRA_WALLET_LOC=
ZDLRA_CRED_ALIAS=
SKIP_FALLBACK=TRUE
TGT_RETAIN_DB_UNIQUE_NAME=
TGT_SKIP_DATAPATCH=FALSE
MAX_DATAPATCH_DURATION_MINS=
DATAPATCH_WITH_ONE_INSTANCE_RUNNING=
SHUTDOWN_SRC=
SKIP_SRC_SERVICE_RETENTION=
SRC_RMAN_CHANNELS=6
TGT_RMAN_CHANNELS=16
ZDM_LOG_OSS_PAR_URL=
ZDM_BACKUP_FULL_SRC_MONITORING_INTERVAL=10
ZDM_BACKUP_INCREMENTAL_SRC_MONITORING_INTERVAL=10
ZDM_BACKUP_DIFFERENTIAL_SRC_MONITORING_INTERVAL=10
ZDM_CLONE_TGT_MONITORING_INTERVAL=10
ZDM_OSS_RESTORE_TGT_MONITORING_INTERVAL=10
ZDM_OSS_RECOVER_TGT_MONITORING_INTERVAL=10
ZDM_BACKUP_RETENTION_WINDOW=
ZDM_OPC_RETRY_WAIT_TIME=
ZDM_OPC_RETRY_COUNT=
ZDM_SRC_TNS_ADMIN=
ZDM_CURL_LOCATION=
ZDM_USE_EXISTING_UNDO_SIZE=
ZDM_SKIP_DG_CONFIG_CLEANUP=
ZDM_RMAN_COMPRESSION_ALGORITHM=LOW

Related Topics
• https://support.oracle.com/epmos/faces/DocContentDisplay?id=2562063.1
• Introduction to Zero Downtime Migration
• Setting Up Zero Downtime Migration Software
• Preparing for Database Migration
• Migrating Your Database with Zero Downtime Migration

During Out-of-Place Cloud Upgrade to New Exadata

Cloud@Customer X8M Gen2 Infrastructure
Monitoring: Oracle will monitor the Exadata Cloud@Customer Gen2 installation from
the beginning of the installation just like a regular Gen2 install.
Backups: Backups are done from the Exadata Cloud@Customer Gen1 VM cluster
and they will continue to work during the upgrade. Post-migration to Exadata
Cloud@Customer Gen2, backups to the Gen1 Oracle Cloud At Customer (OCC)
Object Storage Service (OSS) is not allowed and you must use supported backup
methods for Exadata Cloud@Customer Gen2.

17-9
 Chapter 17
Post Out-of-Place Cloud Upgrade to New Exadata Cloud@Customer X8M Gen2 Infrastructure

Post Out-of-Place Cloud Upgrade to New Exadata

Cloud@Customer X8M Gen2 Infrastructure
The upgrade will move your resources into Exadata Cloud@Customer Gen 2 Cloud
Control Plane and onto the new generation hardware.
Use the Gen2 OCI Console to manage your Exadata Cloud@Customer Gen2
infrastructure, clusters, databases, and users/groups.
The software stack is upgraded to newer versions, for example, as follows:
• Exadata software: 19.x or later
• Oracle Grid Infrastructure: 19C
• Guest VM operating system: Oracle Linux 7
• DBaaS Tools: 20.x
• CSI: You will have a new CSI for your Cloud account.

Note:
The software stack will be upgraded to the latest versions at that point in time
when you perform Out-of-Place Cloud Upgrade to New Gen2 Hardware.

Patching: The infrastructure patching process and notification are different in Gen2.
For more information, see Maintaining an Exadata Cloud@Customer System.

Note:
Post-migration to Exadata Cloud@Customer Gen2, Oracle recommends
using supported backup methods for Exadata Cloud@Customer Gen2. It's
your responsibility to manually manage any backups to the Gen1 Oracle
Cloud At Customer (OCC) Object Storage Service (OSS), and Oracle does
not offer it through the OCI Console, API, or CLI.

Related Topics
• Maintaining an Exadata Cloud@Customer System

Best Practices for Out-of-Place Cloud Upgrade to New

Exadata Cloud@Customer X8M Gen2 Infrastructure
For the purpose of the upgrade, the recommended tool to use is Oracle Zero
Downtime Migration (ZDM).
Some recommended best practices in the context of ZDM's usage for the Gen1 to
Gen2 upgrade are:
• Use one of the following migration methods:

17-10
 Chapter 17
Best Practices for Out-of-Place Cloud Upgrade to New Exadata Cloud@Customer X8M Gen2 Infrastructure

– Offline using an NFS storage or Zero Data Loss Recovery Appliance (ZDLRA)
– Or, online using Data Guard with an NFS storage or ZDLRA

Note:
It is not recommended to use either Gen1 Oracle Cloud At Customer
OSS or OCI Object Storage for this migration.

This maps to setting MIGRATION_METHOD as either DG_STORAGEPATH or

BACKUP_RESTORE_NFS for the purpose of this upgrade. For more information, see
MIGRATION_METHOD.
• For the offline migration, before starting the ZDM_BACKUP_DIFFERENTIAL_SRC phase,
stop database transactions. The target database will sync with the source up
to the start of the backup during that phase. For more information, see Zero
Downtime Migration Process Phases.
• NFS Storage guidelines:
– An NFS storage to store the transient database backup files is required for the
purpose of migration. It is recommended to host one database at a time to
limit the upgrade load on the source and target Exadata Cloud@Customer
and the NFS storage used should be sized to store the backups for the
largest database being migrated. This includes a full database backup, all the
incremental backups used, and the archive logs created during the migration.
If multiple concurrent databases are being migrated, the NFS storage should
be sized to store the full backup and incremental backup of all the databases
being migrated concurrently.
– To avoid possible failures interrupting the migration, it is recommended to
contain the migration time to as small duration as possible.
– For online migration, pause after ZDM_CONFIGURE_DG_SRC. Pausing after
ZDM_CONFIGURE_DG_SRC will not affect the storage needed for the backup.
– Purge the backups related to a migrated database or any failed migrations to
ensure enough space is available for ongoing and planned migrations.
• Set ZDM_RMAN_COMPRESSION_ALGORITHM to LOW.
• The target database Oracle Home must be at the same patch level or at a higher
patch level as the source.
• The target database Oracle Home must have all the one-off patches as the source
Oracle Home.
• Perform a validation run before the actual run.
• For a CDB source database, it is required to have all the PDBs on the source to be
online.
Related Topics
• MIGRATION_METHOD
• Zero Downtime Migration Process Phases

17-11
 Chapter 17
Out-of-Place Cloud Upgrade to New Exadata Cloud@Customer X8M Gen2 Infrastructure Known Issues

Out-of-Place Cloud Upgrade to New Exadata

Cloud@Customer X8M Gen2 Infrastructure Known Issues
Understand the known issues when performing Exadata Cloud@Customer Gen1
to out-of-place cloud upgrade to new Exadata Cloud@Customer X8M Gen2
infrastructure.
• In some scenarios, it is possible that the ZDM server spawns a large number
of unclaimed threads as a result of the migration. If this is observed, then it
is recommended to restart the ZDM server. Ensure that there are no jobs in
EXECUTING status before a restart to avoid disruption to any ongoing migration.
Run the following command to check if any jobs are running:

zdmcli query job -statusonly | grep EXECUTING

• For Oracle Database 11.2.0.4, high CPU utilization is observed on a single

channel even though multiple channels are allocated.
• Migrating Oracle Database release 19.10 from Gen1 to Gen2 is not supported.

17-12
18
Using the dbaascli Utility on Exadata
Cloud@Customer
Learn to use the dbaascli utility on Exadata Cloud@Customer.

• About Using the dbaascli Utility on Exadata Cloud@Customer

You can use the dbaascli utility to perform various database lifecycle and
administration operations on Exadata Cloud@Customer such as changing the
password of a database user, starting a database, managing pluggable databases
(PDBs), scaling the CPU core count in disconnected mode, and more.
• dbaascli cpuscale get_status
To check the status of current or last scale request performed, use the command
dbaascli cpuscale get_status.
• dbaascli cpuscale update
To scale up or down the CPU core count for a virtual machine in a VM cluster in
disconnected mode, use the command dbaascli cpuscale update.
• dbaascli cswlib download
To download available software images and makes them available in your Exadata
Cloud@Customer environment, use the command dbaascli cswlib download.
• dbaascli cswlib list
To view information about Oracle Database software images that are available
to download to your Exadata Cloud@Customer environment, use the command
dbaascli cswlib list.
• dbaascli database bounce
To shut down and restart a specified Exadata Cloud@Customer database, use the
command dbaascli database bounce.
• dbaascli database changepassword
To change the password of a database user, use the command dbaascli
database changepassword.
• dbaascli database move
To move a database to another Oracle Home directory location, use the command
dbaascli database move.
• dbaascli database start
To start the specified database, use the command dbaascli database start.
• dbaascli database status
To check the status of the specified database, use the command dbaascli
database status.
• dbaascli database stop
To stop the specified database, use the command dbaascli database stop.
• dbaascli database update
To modify the globally unique database name or to reconfigure online redo log
files, use dbaascli database update.

18-1
 Chapter 18

• dbaascli dbhome info

Use the dbaascli dbhome info command to view information about Oracle Home
directory locations.
• dbaascli dbhome purge
Use the command dbaascli dbhome purge to delete unused Oracle home
directory locations.
• dbaascli dbimage list
To display information about Oracle Database software images that are
downloaded to your Exadata Cloud@Customer environment, use the command
dbaascli dbimage list.
• dbaascli listener bounce
To stop and restart the Oracle Net listener that is associated with the specified
database, run the command dbaascli listener bounce.
• dbaascli listener start
To start an Oracle Net listener that is associated with the specified database, run
the command dbaascli listener start.
• dbaascli listener status
To obtain the status of the Oracle Net listener that is associated with the specified
database, use the command dbaascli listener status.
• dbaascli listener stop
To stop the Oracle Net listener that is associated with the specified database, use
the command dbaascli listener stop.
• dbaascli patch db apply
To apply an Oracle Database or Oracle Grid Infrastructure patch, use the
command dbaascli patch db apply.
• dbaascli patch db list
To check whether Oracle Database or Oracle Grid Infrastructure patches are
available, run the command dbaascli patch db list.
• dbaascli patch db prereq
To check the prerequisites for an Oracle Database or Oracle Grid Infrastructure
patch, use the command dbaascli patch db prereq.
• dbaascli patch db switchback
To roll back an Oracle Database or Oracle Grid Infrastructure patch, use the
command dbaascli patch db switchback.
• dbaascli patch tools apply
To download and apply a cloud tooling update, run the command dbaascli patch
tools apply.
• dbaascli patch tools list
To display information about your installed cloud tools and to list the available
updates, use the command dbaascli patch tools list.
• dbaascli pdb checkdb
To display information about a container database (CDB), run the command
dbaascli pdb checkdb --dbname.
• dbaascli pdb checknode
To display information about pluggable databases (PDBs) that are associated
with a specific container database (CDB) and a specific compute node run the
command dbaascli pdb checknode.

18-2
 Chapter 18
About Using the dbaascli Utility on Exadata Cloud@Customer

• dbaascli pdb checkpdb

To display information about a pluggable database (PDB) run the command
dbaascli pdb checkpdb.
• dbaascli pdb close
To close a pluggable database (PDB) run the command dbaascli pdb close.
• dbaascli pdb connect_info
To retrieve network connection information for a pluggable database (PDB) run the
command dbaascli pdb connect_info.
• dbaascli pdb connect_string
To display Oracle Net connect string information for a pluggable database (PDB)
run the command dbaascli pdb connect_string.
• dbaascli pdb create
To create a new pluggable database (PDB) run the command dbaascli pdb
create.
• dbaascli pdb delete
To delete a pluggable database (PDB) run the command dbaascli pdb delete.
• dbaascli pdb info
To display more detailed information about a pluggable database (PDB) use the
command dbaascli pdb info.
• dbaascli pdb local_clone
To create a new pluggable database (PDB) as a clone of an existing PDB in the
same container database (CDB) run the command dbaascli pdb local_clone.
• dbaascli pdb open
To open a pluggable database (PDB) run the command dbaascli pdb open.
• dbaascli pdb remote_clone
• dbaascli pdb rename
To change the name of a pluggable database (PDB) use the command dbaascli
pdb rename.
• dbaascli pdb resize
To modify the size limits for a pluggable database (PDB) use the commad
dbaascli pdb resize.
• dbaascli tde rotate masterkey
To change or rotate the master encryption key for the specified database, run the
command dbaascli tde rotate masterkey.
• dbaascli tde status
To display information about the keystore for the specified database run the
command dbaascli tde status.

About Using the dbaascli Utility on Exadata

Cloud@Customer
You can use the dbaascli utility to perform various database lifecycle and
administration operations on Exadata Cloud@Customer such as changing the
password of a database user, starting a database, managing pluggable databases
(PDBs), scaling the CPU core count in disconnected mode, and more.

18-3
 Chapter 18
dbaascli cpuscale get_status

You must use DBaaS console or command-line interface to scale resources. The
capabilities of the dbaascli utility are in addition to, and separate from, the Oracle
Cloud Infrastructure Console, API, or command-line interface (CLI).
To use the utility, you must be connected to an Exadata Cloud@Customer compute
node. See "Connecting to a Compute Node with SSH".
Many dbaascli commands can be run as the oracle user. However, some commands
require root administrator privileges.

To scale OCPUs up or down in a VM cluster in disconnected mode, run the dbaascli

cpuscale update and dbaascli cpuscale get_status commands from any node
inside a VM cluster to change the CPU core count for that cluster. If you have more
than one VM cluster, then run a separate command from any node inside each VM
cluster you want to scale up or down. These commands are designed to not work if
issued during the normal connected mode and will time out 600 seconds (10 minutes).
Related Topics
• Connecting to a Compute Node with SSH

dbaascli cpuscale get_status

To check the status of current or last scale request performed, use the command
dbaascli cpuscale get_status.

Prerequisites
Run the command as the root user.

See "Connecting to a Compute Node with SSH".

Syntax
Displays various command execution states as it progresses from scheduled,
running, and finally to success or failure.

dbaascli cpuscale get_status

dbaascli cpuscale update

To scale up or down the CPU core count for a virtual machine in a VM cluster in
disconnected mode, use the command dbaascli cpuscale update.

Prerequisites
Run the command as the root user.

See "Connecting to a Compute Node with SSH".

18-4
 Chapter 18
dbaascli cswlib download

Syntax
Exadata Cloud@Customer is considered to be in a "Disconnected" mode when there
is a loss of connectivity with the DBaaS control plane running on Oracle Cloud
Infrastructure (OCI).

dbaascli cpuscale update --coreCount coreCount --message message

In the command, coreCount specifies the number of CPUs that you want to scale up or
down per VM in a cluster. Optionally, you can include a message for your reference.

dbaascli cswlib download

To download available software images and makes them available in your Exadata
Cloud@Customer environment, use the command dbaascli cswlib download.

Prerequisites
Run the command as the root user.

See "Connecting to a Compute Node with SSH".

Syntax

dbaascli cswlib download --version software_version --bp software_bp

[--bp_update ( yes | no )] [--cdb ( yes | no )] [--oss_uri
download_location]

In the command:
• software_version specifies an Oracle Database software version. For example,
11204, 12102, 12201, 18000, 19000.
• software_bp identifies a bundle patch release. For example, APR2018, JAN2019,
OCT2019, and so on.
• --bp_update optionally indicates whether the downloaded software image
becomes the current default software image. Default is no.
• --cdb optionally specifies whether the downloaded software image supports the
Oracle multitenant architecture. Default is yes. If you specify --cdb no, then
a separate software image is downloaded that contains binaries to support non-
container databases (non-CDB).
• download_location optionally specifies the location of the software image library.
The location is specified as a uniform resource identifier (URI) to a cloud storage
container that contains available software images.
Normally, the --oss_uri option is not required because the location of the
software image library is automatically derived from configuration information
in the Exadata Cloud@Customer environment. However, if you experience any
difficulties with the automatic location, you can lodge a service request (SR) with
Oracle Support and they may instruct you to use this option to specify an alternate
location.

18-5
 Chapter 18
dbaascli cswlib list

Related Topics
• Connecting to a Compute Node with SSH

dbaascli cswlib list

To view information about Oracle Database software images that are available
to download to your Exadata Cloud@Customer environment, use the command
dbaascli cswlib list.

Prerequisites
Run the command as the root user.

See "Connecting to a Compute Node with SSH".

Syntax

dbaascli cswlib list [ --oss_uri download_location ]

The command displays a list of available software images, including version and
bundle patch information that you can use to download the software image.
The --oss_uri option can be used to specify the location of the software image
library. Normally, the --oss_uri option is not required because the location of the
software image library is automatically derived from configuration information in the
Exadata Cloud@Customer environment. However, if you experience any difficulties
with the automatic location, you can lodge a service request (SR) with Oracle Support
and they may instruct you to use this option to specify an alternate location. The
download_location is specified as a uniform resource identifier (URI) to a cloud
storage container that contains available software images.
Related Topics
• Connecting to a Compute Node with SSH

dbaascli database bounce

To shut down and restart a specified Exadata Cloud@Customer database, use the
command dbaascli database bounce.

Prerequisites
Run the command as the oracle user.
To use the utility, you must be connected to an Exadata Cloud@Customer compute
node.
See "Connecting to a Compute Node with SSH".

Syntax

dbaascli database bounce --dbname dbname

In the command, dbname specifies the name of the database that you want to act on.

18-6
 Chapter 18
dbaascli database changepassword

Options
The dbname option of database bounce specifies the name of the database that you
want to shut down and restart. The dbname option is prefixed with two minus signs (--).

Usage Notes
The command performs a database shutdown in immediate mode. The database is
then restarted and opened. In Oracle Database 12c or later, all of the PDBs are also
opened.
Example 18-1 Shut Down and Restart the Database
In the following command, you shut down and restart the database sales1

dbaascli database bounce --dbname sales1

Related Topics
• Connecting to a Compute Node with SSH

dbaascli database changepassword

To change the password of a database user, use the command dbaascli database
changepassword.

Prerequisites
Run the command as the root user.

Syntax

dbaascli database changepassword --dbname dbname

In the command, dbname specifies the name of the database that you want to act on.

Options
The dbname option of database changepassword specifies the name of the database
that you want to shut down and restart. The dbname option is prefixed with two minus
signs (--).

Usage Notes
Enter the database user name and new password when prompted.

18-7
 Chapter 18
dbaascli database move

dbaascli database move

To move a database to another Oracle Home directory location, use the command
dbaascli database move.

Prerequisites
• Before performing a move operation, ensure that all of the database instances
associated with the database are up and running.
• Run the command as the root user.

Syntax

dbaascli database move --dbname dbname --ohome oraclehome

In the command:
• dbname specifies the name of the database that you want to move.
• oraclehome specifies the path to an existing Oracle Home directory location, which
you want the specified database to use.

dbaascli database start

To start the specified database, use the command dbaascli database start.

Prerequisites
Run the command as the Oracle user.

Syntax

dbaascli database start --dbname dbname

In the command, dbname specifies the name of the database that you want to start.

Usage Notes
The command starts and opens the database. In Oracle Database 12c or later, all of
the PDBs are also opened.

dbaascli database status

To check the status of the specified database, use the command dbaascli database
status.

Prerequisites
Run the command as the Oracle user.

18-8
 Chapter 18
dbaascli database stop

Syntax

dbaascli database status --dbname dbname

In the command, dbname specifies the name of the database for which you want to
check the status.

Usage Notes
Output from the command includes the open mode of the database, the software
release and edition of the database, and release version of other software
components.

dbaascli database stop

To stop the specified database, use the command dbaascli database stop.

Prerequisites
Run the command as the Oracle user.

Syntax

dbaascli database stop --dbname dbname

In the command, dbname specifies the name of the database that you want to stop.

Usage Notes
The command performs a database shutdown in immediate mode. No new
connections or new transactions are permitted. Active transactions are rolled back,
and all connected users are disconnected.

dbaascli database update

To modify the globally unique database name or to reconfigure online redo log files,
use dbaascli database update.

Prerequisites
For all options, run the command as the root user.

Modifying the Globally Unique Database Name

Note:
Modifying the db_unique_name for databases with Data Guard associations,
primary or standby, is not supported.

18-9
 Chapter 18
dbaascli dbhome info

Run the following command to modify a globally unique database name:

dbaascli database update --dbname dbname --db_unique_name

dbname_uniquename [--precheck]

In the command, dbname specifies the name of the database that you want to update
and dbname_uniquename specifies the user configurable portion of the new globally
unique database name.
The command modifies the DB_UNIQUE_NAME database parameter and related
configuration entries that reference it, including entries in the Oracle Cluster Registry
(OCR) and database server parameter file (SPFILE). File locations that reference the
globally unique database name are also updated, including the location of the data
files and keystore.
The value for the --db_unique_name option must begin with the dbname value, followed
by an underscore character. If you do not use this convention, then the command fails
with an error .
To ensure that the update can proceed before you perform the update operation, you
can use the option --precheck to run a series of prerequisite checks. No changes are
made when using the --precheck option.

Reconfiguring Online Redo Logs

dbaascli database update --dbname dbname --redosize redosize [--groups

numgroups] [--precheck]

Run the following command to reconfigure online redo logs:

In the command, the variable dbname specifies the name of the database that you
want to move and the variable redosize specifies the size of each online redo log
file in megabytes. The valid range is for redosize is between 1000m and 16000m, and
the value that you enter for the variable numgroups optionally specifies the number of
online redo log groups to create. The default value for the variable numgroups is 4.

Before performing the update operation, you can use the --precheck option to run a
series of prerequisite checks to ensure that the update can proceed. No changes are
made when you use the --precheck option.

dbaascli dbhome info

Use the dbaascli dbhome info command to view information about Oracle Home
directory locations.

Prerequisites
Run the command as root user.

Syntax

dbaascli dbhome info

When prompted:

18-10
 Chapter 18
dbaascli dbhome purge

• Press Enter to view information about all of the Oracle homes that are registered
in the VM cluster.
• To view information about a particular Oracle home, specify an Oracle home
name.

dbaascli dbhome purge

Use the command dbaascli dbhome purge to delete unused Oracle home directory
locations.

Prerequisite
Run the command as the root user.

Syntax

dbaascli dbhome purge

Options
When prompted, enter:
• 1 to specify the Oracle home name for the location being purged.
• 2 to specify the Oracle home directory path for the location being purged.
When next prompted, enter the Oracle home name or directory path for the location
being purged. If your entries are valid, and the Oracle home is not associated with
a database, then the Oracle binaries are removed from the Oracle home directory
location. The associated metadata is also removed from the system.

dbaascli dbimage list

To display information about Oracle Database software images that are downloaded
to your Exadata Cloud@Customer environment, use the command dbaascli dbimage
list.

Prerequisites
Run the command as the root user.

Syntax

dbaascli dbimage list

Usage Notes
The command displays a list of software images that are downloaded to your Exadata
Cloud@Customer environment, including version and bundle patch information.

18-11
 Chapter 18
dbaascli listener bounce

dbaascli listener bounce

To stop and restart the Oracle Net listener that is associated with the specified
database, run the command dbaascli listener bounce.

Prerequisites
Run the dbaascli listener bounce command as the oracle user.

Syntax

dbaascli listener bounce --dbname dbname

In the preceeding command dbname specifies the name of the database that you want
to stop and restart.

dbaascli listener start

To start an Oracle Net listener that is associated with the specified database, run the
command dbaascli listener start.

Prerequisites
Run the dbaascli listener start command as the oracle user:

Syntax

dbaascli listener start --dbname dbname

In the preceeding command dbname specifies the name of the database that you want
to move.

dbaascli listener status

To obtain the status of the Oracle Net listener that is associated with the specified
database, use the command dbaascli listener status.

Prerequisites
Run the command as the oracle user.

Syntax

dbaascli listener stop --dbname dbname

In the command, dbname specifies the name of the database whose listener you want
to stop.

18-12
 Chapter 18
dbaascli listener stop

dbaascli listener stop

To stop the Oracle Net listener that is associated with the specified database, use the
command dbaascli listener stop.

Prerequisites
Run the command as the oracle user.

Syntax

dbaascli listener stop --dbname dbname

In the command, dbname specifies the name of the database whose listener you want
to stop.

dbaascli patch db apply

To apply an Oracle Database or Oracle Grid Infrastructure patch, use the command
dbaascli patch db apply.

Prerequisites
Run the command as the root user.

Syntax
You can use this command to apply an Oracle Database or Oracle Grid Infrastructure
patch.
To apply a patch to a specific instance, use the following command:

dbaascli patch db apply --patchid patchid --instance1

hostname:oracle_home [--dbnames dbname[,dbname2 ...]] [--run_datasql 1]

To apply a patch by specifying only database names, use the following command:

dbaascli patch db apply --patchid patchid --dbnames dbname[,dbname2

...] [--run_datasql 1] [-alldbs]

To apply a patch to Oracle Grid Infrastructure, use the following command:

dbaascli patch db apply --patchid patchid --dbnames grid

To run the command in the background, append an ampersand (&):

dbaascli patch db apply --patchid 29708703 --dbnames DB18 &

18-13
 Chapter 18
dbaascli patch db apply

To learn more about the patch db apply command options, use the following
command:

dbaascli patch db apply ?

In the preceding commands:

• patchid identifies the patch that you want to apply.
• --instance1 specifies a compute node and Oracle home directory that is subject
to the patching operation. In this context, an Oracle home directory can be
either an Oracle Database home directory, or the Oracle Grid Infrastructure home
directory.
If you use this argument to specify a shared Oracle home directory and you do not
specify the --dbnames argument, then all of the databases that share the specified
Oracle Home are patched. After the operation, the Oracle home directory location
remains unchanged; however, the patch level information embedded in the Oracle
home name is adjusted to reflect the patching operation.
• --dbnames specifies the database names for the databases that are the target of
the patching operation.
If you use this argument to patch a database that uses a shared Oracle home,
and you do not specify the -alldbs option, then a new Oracle home containing the
patched Oracle Database binaries is created, and the database is moved to the
new Oracle home.
• -alldbs patches all of the databases that share the same Oracle Database
binaries (Oracle home) as the databases specified in the --dbnames argument.
After the operation, the Oracle home directory location remains unchanged;
however, the patch level information embedded in the Oracle home name is
adjusted to reflect the patching operation.
• --run_datasql 1 instructs the command to execute patch-related SQL
commands.

Usage Notes
• Patch-related SQL should only be run after all of the compute nodes are patched.
Take care not to specify this argument if you are patching a node and further
nodes remain to be patched.
• This argument can only be specified along with a patching operation on a compute
node. If you have patched all of your nodes and you did not specify this argument,
you need to manually execute the SQL commands associated with the patch,
which typically involves running the catbundle.sql script for Oracle Database
11g or the datapatch utility for Oracle Database 12c, or later. Refer to the patch
documentation for full details.

18-14
 Chapter 18
dbaascli patch db list

dbaascli patch db list

To check whether Oracle Database or Oracle Grid Infrastructure patches are available,
run the command dbaascli patch db list.

Prerequisites
Run the command as the root user.

Syntax

dbaascli patch db list --oh hostname:oracle_home

In the preceding command, --oh hostname: specifies a compute node, and

oracle_home specifies the Oracle home directory for which you want to list the
available patches. In this context, an Oracle home directory may be an Oracle
Database home directory or the Oracle Grid Infrastructure home directory

Usage Notes
The list of available patches is determined by interrogating the database to
establish the patches that have already been applied. When a patch is applied, the
corresponding database entry is made as part of the SQL patching operation, which
is run at the end of the patch workflow. Therefore, the list of available patches may
include partially applied patches along with patches that are currently being applied.

dbaascli patch db prereq

To check the prerequisites for an Oracle Database or Oracle Grid Infrastructure patch,
use the command dbaascli patch db prereq.

Prerequisites
You must run the command as the root user.

Syntax
To check patch prerequisites on a specific instance, use the following command:
dbaascli patch db prereq --patchid patchid --instance1
hostname:oracle_home [--dbnames dbname[,dbname2 ...]]
To check patch prerequisites by specifying only database names, use the following
command:
dbaascli patch db prereq --patchid patchid --dbnames dbname[,dbname2 ...]
[-alldbs]
In the preceding commands:
• patchid identifies the patch identifier for which you want prerequisites to be
checked before installing the patch.
• --instance1 specifies a compute node and Oracle home directory on which you
want the prerequisite checks to be performed. In this context, an Oracle home

18-15
 Chapter 18
dbaascli patch db switchback

directory can be an Oracle Database home directory, or it can be the Oracle Grid
Infrastructure home directory.
• --dbnames specifies the database names for the databases on which you want
prerequisite checks to be performed.
• -alldbs specifies that you want to check all of the databases that share the same
Oracle home (the same Oracle Database binaries) as the specified databases.

dbaascli patch db switchback

To roll back an Oracle Database or Oracle Grid Infrastructure patch, use the command
dbaascli patch db switchback.

Prerequisites
You must run the command as the root user.

Syntax
To roll back a patch on specific instances, use the following command syntax:

dbaascli patch db switchback --patchid patchid --instance1

hostname:oracle_home [--dbnames dbname[,dbname2 ...]] [--run_datasql 1]

To roll back a patch by specifying only database names, use the following command:
dbaascli patch db switchback --patchid patchid --dbnames
dbname[,dbname2 ...] [--run_datasql 1] [-alldbs]
In the preceding commands:
• patchid identifies the patch to be rolled back.
• --instance1 specifies a compute node and Oracle Home directory that is subject
to the rollback operation. In this context, an Oracle home directory can be an
Oracle Database home directory or the Oracle Grid Infrastructure home directory.
If you use this argument to specify a shared Oracle home directory, and you do not
specify the --dbnames argument, then all of the databases that share the specified
Oracle home are rolled back.
• --dbnames specifies the database names for the databases that are the target of
the rollback operation.
• -alldbs specifies that you want to roll back all of the databases that share the
same Oracle Database binaries (Oracle home) as the databases specified in the
--dbnames argument.
• --run_datasql 1 instructs the command to run rollback-related SQL commands.

Usage Notes
• You can only run rollback-related SQL after all of the compute nodes are rolled
back. Take care not to specify this argument if you are rolling back a node, and
further nodes remain to be rolled back.
• You can only specify this argument with a rollback operation on a compute node.
Therefore, if you have rolled back all of your nodes, and you did not specify this

18-16
 Chapter 18
dbaascli patch tools apply

argument, then you must manually run the SQL commands associated with the
rollback operation. Refer to the patch documentation for full details.

dbaascli patch tools apply

To download and apply a cloud tooling update, run the command dbaascli patch
tools apply.

Prerequisite
Run the command as the root user.

Syntax
• To update to the latest available cloud tooling, use the command:

dbaascli patch tools apply --patchid LATEST

• To update to a specific cloud tooling release, use the following command:

dbaascli patch tools apply --patchid patchid

In the preceding command, patchid is a cloud tooling patch identifier, as reported in

the output of the dbaascli patch db list command.

Usage Notes
The cloud tooling update is applied to all nodes in the VM cluster.

dbaascli patch tools list

To display information about your installed cloud tools and to list the available updates,
use the command dbaascli patch tools list.

Prerequisites
Run the command as the root user.

Syntax

dbaascli patch tools list

Usage Notes
The command output displays:.
• The version of the cloud tooling that is installed on the compute node.
• The list of available updates.
• Notification of the cloud tooling version that is installed on the other compute
nodes in the VM cluster.

18-17
 Chapter 18
dbaascli pdb checkdb

dbaascli pdb checkdb

To display information about a container database (CDB), run the command dbaascli
pdb checkdb --dbname.

Prerequisites
Run the command as the oracle user.

Syntax

dbaascli pdb checkdb --dbname dbname

Options
In the command, dbname specifies the name of the CDB for which you want to display
information.

Usage Notes
The information returned by this command includes the number of instances, and the
CPU count that is associated with the CDB.

dbaascli pdb checknode

To display information about pluggable databases (PDBs) that are associated with a
specific container database (CDB) and a specific compute node run the command
dbaascli pdb checknode.

Prerequisites
Run the command as the oracle user.

Syntax

dbaascli pdb checknode --node nodenum --dbname dbname

Options
In the command:
• nodenum specifies the node number for a compute node in the Exadata
Cloud@Customer environment. You can display a list of compute nodes and
corresponding node numbers by using the olsnodes command.
• dbname specifies the name of the container database that hosts the PDB.

Usage Notes
The command displays statuses for all PDBs that are associated with the specified
compute node and CDB, including the open mode for each PDB.

18-18
 Chapter 18
dbaascli pdb checkpdb

dbaascli pdb checkpdb

To display information about a pluggable database (PDB) run the command dbaascli
pdb checkpdb.

Prerequisites
Run the command as the oracle user.

Syntax

dbaascli pdb checkpdb --pdbname pdbname --dbname dbname

Options
In the command:
• pdbname specifies the name of the PDB that you want to check.
• dbname specifies the name of the container database that hosts the PDB.

Usage Notes
The command displays the status for the specified PDB, including the open mode and
restricted status.

dbaascli pdb close

To close a pluggable database (PDB) run the command dbaascli pdb close.

Prerequisite
Run the command as the oracle user.

Syntax

dbaascli pdb close --pdbname pdbname --dbname dbname

Options
In the command:
• pdbname specifies the name of the PDB that you want to close.
• dbname specifies the name of the container database that hosts the PDB.

Usage Notes
Upon successful completion of running this command, the PDB is closed on all of the
container database instances.

18-19
 Chapter 18
dbaascli pdb connect_info

dbaascli pdb connect_info

To retrieve network connection information for a pluggable database (PDB) run the
command dbaascli pdb connect_info.

Prerequisite
Run the command as the oracle user.

Syntax

dbaascli pdb connect_info --pdbname pdbname --dbname dbname

Options
In the command:
• pdbname specifies the name of the PDB for which you want to retrieve connection
information
• dbname specifies the name of the container database that hosts the PDB

Usage Notes
The command outputs a zip file that contains tnsnames.ora, sqlnet.ora, and ojdbcs
properties for the PDB.

dbaascli pdb connect_string

To display Oracle Net connect string information for a pluggable database (PDB) run
the command dbaascli pdb connect_string.

Prerequisite
Run the command as the oracle user.

Syntax

dbaascli pdb connect_string --pdbname pdbname --dbname dbname

Options
In the command:
• pdbname specifies the name of the PDB for which you want to display connect
string information
• dbname specifies the name of the container database that hosts the PDB

18-20
 Chapter 18
dbaascli pdb create

dbaascli pdb create

To create a new pluggable database (PDB) run the command dbaascli pdb create.

Prerequisite
Run the command as the oracle user.

Syntax

dbaascli pdb create --pdbname pdbname --dbname dbname [--maxsize

maxsize] [--maxcpu maxcpu]

Options
In the command:
• pdbname specifies the name of the new PDB that you want to create.
• dbname specifies the name of the container database that hosts the new PDB.
• maxsize optionally specifies the maximum total size of data files and temporary
files for tablespaces belonging to the PDB. Setting this option is effectively
the same as setting the MAXSIZE PDB storage clause in the CREATE PLUGGABLE
DATABASE SQL command. You can impose a limit by specifying an integer followed
by a size unit (K, M, G, or T), or you can specify UNLIMITED to explicitly enforce no
limit.
• maxcpu optionally specifies the maximum number of CPUs that are available to
the PDB. Setting this option is effectively the same as setting the CPU_COUNT
parameter in the PDB.

Usage Notes
During the PDB creation process, you are prompted to specify the administration
password for the new PDB.

dbaascli pdb delete

To delete a pluggable database (PDB) run the command dbaascli pdb delete.

Prerequisite
Run the command as the oracle user.

Syntax

dbaascli pdb delete --pdbname pdbname --dbname dbname

Options
In the command:
• pdbname specifies the name of the PDB that you want to delete

18-21
 Chapter 18
dbaascli pdb info

• dbname specifies the name of the container database that hosts the PDB

dbaascli pdb info

To display more detailed information about a pluggable database (PDB) use the
command dbaascli pdb info.

Prerequisite
Run the command as the oracle user.

Syntax

dbaascli pdb info [--pdbname pdbname] --dbname dbname [--detailed]

Options
In the command:
• pdbname optionally specifies the name of the PDB for which you want to display
information. If this you do not specify this option, then the command displays
information about all of the PDBs in the specified container database.
• dbname specifies the name of the container database that hosts the PDB.

Usage Notes
The command displays information such as the CPU count and storage usage that
is associated with a PDB. You can add the optional --detailed argument to display
extra information, including the list of compute nodes where a PDB is open in read/
write mode.

dbaascli pdb local_clone

To create a new pluggable database (PDB) as a clone of an existing PDB in the same
container database (CDB) run the command dbaascli pdb local_clone.

Prerequisite
Run the command as the oracle user.

Syntax

dbaascli pdb local_clone --pdbname sourcepdbname --target_pdbname

targetpdbname --dbname dbname

Options
In the command:
• sourcepdbname specifies the name of the PDB that you want to clone
• targetpdbname specifies the name of the new PDB that you want to create
• dbname specifies the name of the container database that hosts the PDBs

18-22
 Chapter 18
dbaascli pdb open

Usage Notes
The newly cloned PDB inherits administration passwords from the source PDB.

dbaascli pdb open

To open a pluggable database (PDB) run the command dbaascli pdb open.

Prerequisite
Run the command as the oracle user.

Syntax

dbaascli pdb open --pdbname pdbname --dbname dbname

Options
In the command:
• pdbname specifies the name of the PDB that you want to open
• dbname specifies the name of the container database that hosts the PDB.

Usage Notes
Upon successful completion, the PDB is opened on all of the container database
instances.

dbaascli pdb remote_clone

To create a new pluggable database (PDB) as a clone of an existing PDB in another
container database (CDB), run the command dbaascli pdb remote_clone.

Prerequisite
Run the command as the oracle user.

Syntax

dbaascli pdb remote_clone --pdbname sourcepdbname --source_db

sourcedbname --source_db_scan sourcedbscan --dbname dbname

Options
In the command:
• pdbname specifies the name of the source PDB that you want to clone.
• sourcedbname specifies the name (DB_UNIQUE_NAME) of the CDB that hosts the
source PDB.
• sourcedbscan specifies the Single Client Access Name (SCAN) that is used to
connect to the source database.
• dbname specifies the name (DB_NAME) of the CDB that hosts the newly cloned PDB.

18-23
 Chapter 18
dbaascli pdb rename

Usage Notes
When promoted, you must supply the SYS user password for the source PDB.
The newly cloned PDB inherits administration passwords from the source PDB. The
cloned PDB is named using the following format: dbname_sourcepdbname

This command is supported only for databases that are not in a Data Guard
configuration and use Oracle Database version 12.2.0.1, or later.

dbaascli pdb rename

To change the name of a pluggable database (PDB) use the command dbaascli pdb
rename.

Prerequisite
Run the command as the oracle user.

Syntax

dbaascli pdb rename --pdbname oldname --newname newname --dbname dbname

Options
In the command:
• oldname specifies the old name of the PDB that you want to rename
• newname specifies the new name of the PDB that you want to rename
• dbname specifies the name of the container database that hosts the PDB

dbaascli pdb resize

To modify the size limits for a pluggable database (PDB) use the commad dbaascli
pdb resize.

Prerequisite
Run the command as the oracle user.

Syntax

dbaascli pdb resize --pdbname pdbname --dbname dbname [--maxsize

maxsize] [--maxcpu maxcpu]

Options
In the command:
• pdbname specifies the name of the new PDB that you want to modify
• dbname specifies the name of the container database that hosts the PDB

18-24
 Chapter 18
dbaascli tde rotate masterkey

• maxsize optionally specifies the maximum total size of data files and temporary
files for tablespaces belonging to the PDB. Setting this option is effectively the
same as setting the MAXSIZE PDB storage clause in the CREATE PLUGGABLE
DATABASE SQL command. You can impose a limit by specifying an integer followed
by a size unit (K, M, G, or T), or you can specify UNLIMITED to explicitly enforce no
limit
• maxcpu optionally specifies the maximum number of CPUs that are available to
the PDB. Setting this option is effectively the same as setting the CPU_COUNT
parameter in the PDB.

Usage Notes
When you run the command, you must specify at least one of optional attributes,
--maxsize or --maxcpu. You can specify both optional attributes in one command.

dbaascli tde rotate masterkey

To change or rotate the master encryption key for the specified database, run the
command dbaascli tde rotate masterkey.

Prerequisite
Run the command as the oracle user.

Syntax

dbaascli tde rotate masterkey --dbname dbname

Options
--dbname dbname specifies the name of the database that you want to act on.

Usage Notes
Enter the keystore password when prompted. The keystore password is initially set to
the administration password that you specified when you created the database.

dbaascli tde status

To display information about the keystore for the specified database run the command
dbaascli tde status.

Prerequisite
Run the command as the oracle user.

Syntax

$ dbaascli tde status --dbname dbname

Options
In the command, dbname specifies the name of the database that you want to check.

18-25
 Chapter 18
dbaascli tde status

Usage Notes
Output from the command includes the type of keystore, and the status of the
keystore.

18-26
19
Monitoring and Managing Exadata Storage
Servers with ExaCLI
Learn to use the ExaCLI command-line utility to perform monitoring and management
functions on Exadata storage servers in the Exadata Cloud Service.
• About the ExaCLI Command
The ExaCLI command provides a subset of the commands found in the on-
premises Exadata command line utility.
• Exadata Storage Server Username and Password
You need a username and password to connect to the Exadata Storage Server.
• ExaCLI Command
Use ExaCLI (exacli) to configure cell, database node configuration, and objects
in the remote node environment, and to monitor your Exadata Cloud@Customer
services and objects.
• Connecting to a Storage Server with ExaCLI
To use ExaCLI on storage servers, you will need to know your target storage
server's IP address.

About the ExaCLI Command

The ExaCLI command provides a subset of the commands found in the on-premises
Exadata command line utility.
ExaCLI offers a subset of the commands found in the on-premises Exadata command
line utility. The utility runs on the database compute nodes in the Exadata Cloud
Service.
Related Topics
• Using the CellCLI Utility

Exadata Storage Server Username and Password

You need a username and password to connect to the Exadata Storage Server.
On Exadata Cloud@Customer, the preconfigured user for Exadata Storage Server is
cloud_user_clustername, where clustername is the name of the virtual machine (VM)
cluster that is being used.
You can determine the name of the VM cluster by running the following crsctl
command as the grid user on any cluster node:

crsctl get cluster name

19-1
 Chapter 19
ExaCLI Command

The password for cloud_user_clustername is initially set to a random value, which

you can view by running the following command as the opc user on any cluster node:

/opt/exacloud/get_cs_data.py --data_file /opt/exacloud/cs_data.enc

ExaCLI Command
Use ExaCLI (exacli) to configure cell, database node configuration, and objects in
the remote node environment, and to monitor your Exadata Cloud@Customer services
and objects.

Purpose
ExaCLI (exacli) enables you configure your Exadata Cloud@Customer system,
and to obtain real-time information about your Exadata Cloud Service. To obtain
information about the services and options on your system, run ExaCLI using the
monitoring command parameter that you require.
To obtain a list of the system monitoring parameters you can use with ExaCLI, run the
LIST parameter.

Syntax

exacli -c [username@]remotehost[:port]
[-l username]
[--xml]
[--cookie-jar filename]
[-e {command | 'command; command' | @batchfile}]

Options

Option Description
-c [username@]remotehost or --connect Specifies the remote node to which you want
[username@]remotehost[:port] to connect. ExaCLI prompts for the user name
if not specified.
-l username or --login-name username Specifies the user name to log into the
remote node. The preconfigured user is
cloud_user_clustername.
--xml Displays the output in XML format.
--cookie-jar [filename] Specifies the filename of the cookie jar to use.
If you do not specify a filename, then the
cookie is stored in a default cookie jar located
at HOME/.exacli/cookiejar, where HOME is
the home directory of the operating system
user running the exacli command.
The presence of a valid cookie allows
the ExaCLI user to run commands without
requiring the user to log in during subsequent
ExaCLI sessions.

19-2
 Chapter 19
ExaCLI Command

Option Description
-e command or -e 'command[; command]' Specifies either the ExaCLI commands to run,
or -e @batchFile or a batch file. After running the commands,
ExaCLI quits.
If you are specifying multiple commands to
run, then enclose the commands in single
quotes to prevent the shell from interpreting
the semicolon.
To start an interactive ExaCLI session, omit
this command.
--cert-proxy proxy[:port] Specifies the proxy server that you want to
use when downloading certificates. If port is
omitted, then port 80 is used by default.
-n or --no-prompt Suppresses prompting for user input.

Command Parameters
To obtain information about objects and services on your system, use these ExaCLI
command parameters.

Table 19-1 Command

Command Parameter Description

ACTIVEREQUEST Lists all active requests that are currently
being served by the storage servers.
ALERTDEFINITION Lists all possible alerts and their sources for
storage servers.
ALERTHISTORY Lists all alerts that have been issues for the
storage servers.
CELL Used to list the details of a specific attribute
of the storage servers or storage cells. The
syntax is as follows: LIST CELL ATTRIBUTES
A,B,C, with A, B, and C being attributes. To
see all cell attributes, use the LIST CELL
ATTRIBUTES ALL command.
CELLDISK Lists the attributes of the cell disks in the
storage servers. Use the following syntax to
list the cell disk details: LIST CELLDISK
cell_disk_name DETAIL.
DATABASE Lists details of the databases. Uses the regular
LIST command syntax: LIST DATABASE and
LIST DATABASE DETAIL. You can also use
this command to show an individual attribute
with the following syntax: LIST DATABASE
ATTRIBUTES NAME.
FLASHCACHE Lists the details of the Exadata system's
flash cache. For this object, you can use the
following syntax patterns: LIST FLASHCACHE
DETAIL or LIST FLASHCACHE ATTRIBUTES
attribute_name.

19-3
 Chapter 19
ExaCLI Command

Table 19-1 (Cont.) Command

Command Parameter Description

FLASHCACHECONTENT Lists the details of all objects in the flash
cache, or the details of a specified object ID.
To list all the details of all objects, use LIST
FLASHCACHECONTENT DETAIL.
To list details for a specific object, use a where
clause as follows: LIST FLASHCACHECONTENT
WHERE objectNumber=12345 DETAIL.
Example query: finding the object_id value
of an object

select object_name,
data_object_id from user_objects
where object_name = 'BIG_CENSUS';
OBJECT_NAME
DATA_OBJECT_ID
----------------------------------
------
BIG_CENSUS 29152

FLASHLOG Lists the attributes for the Oracle Exadata

Smart Flash Log.
GRIDDISK Lists the details of a particular grid disk.
The syntax is similar to the CELLDISK
command syntax. To view all attributes: LIST
GRIDDISK grid_disk_name DETAIL. To
view specified attributes of the grid disk: LIST
GRIDDISK grid_disk_name ATTRIBUTES
size, name.
IBPORT Lists details of the InfiniBand ports. Syntax is
LIST IBPORT DETAIL.
IORMPLAN Use the ExaCLI CREATE, ALTER, DROP, and
LIST commands with IORMPLAN. To see the
details of all IORM plans, use LIST IORMPLAN
DETAIL. You can also use the command to
create and alter IORM plans, and to apply
plans to storage servers.
IORMPROFILE Lists any IORM profiles that have been set on
the storage servers. You can also refer back to
the profile attribute on the DATABASE object if a
database has an IORM profile on it. Syntax is
LIST IORMPROFILE.
LIST Lists the command parameter options
available with ExaCLI for the Exadata
Cloud@Customer services and objects.

19-4
 Chapter 19
ExaCLI Command

Table 19-1 (Cont.) Command

Command Parameter Description

LUN The LUN (logical unit number) object returns
the number and the detail of the physical disks
in the storage servers. List the LUNs of the
disks with LIST LUN. List the details of each
LUN with LIST LUN lun_number DETAIL.
METRICCURRRENT Lists the current metrics for a particular object
type. Syntax is LIST METRICCURRENT WHERE
objectType = 'CELLDISK'.
This command also allows for sorting and
results limits as seen in the following example:

LIST METRICCURRENT attributes

name, metricObjectName ORDER BY
metricObjectName asc, name desc
LIMIT 5

METRICDEFINITION Lists metric definitions for the object that

you can then get details for. With the
command LIST metricDefinition WHERE
objectType=cell, you can get all the metrics
for that object type. You can then use the
metric definition object again to get details for
one of those specific metrics just listed:

LIST metricDefinition WHERE name=

IORM_MODE DETAIL

METRICHISTORY List metrics over a specified period of

time. For example, with the command LIST
METRICHISTORY WHERE ageInMinutes <
30, you can list all the metrics collected over
the past 30 minutes. You can also use the
predicate collectionTime to set a range
from a specific time.
Use collectionTime as shown
in the follow example: LIST
METRICHISTORY WHERE collectionTime
> '2018-04-01T21:12:00-10:00'. The
metric history object can also be used to
see a specific metric using the object’s
name (for example, LIST METRICHISTORY
CT_FD_IO_RQ_SM) or with a "where" clause
to get objects with similar attributes like name
(for example, LIST METRICHISTORY WHERE
name like 'CT_.*').

19-5
 Chapter 19
ExaCLI Command

Table 19-1 (Cont.) Command

Command Parameter Description

OFFLOADGROUP Lists the attributes for the offload group
that are running on your storage servers.
You can list all details for all groups with
LIST OFFLOADGROUP DETAIL, or list the
attributes for a specific group, as shown in
the following example: LIST OFFLOADGROUP
offloadgroup4. List specific attributes with
LIST OFFLOADGROUP ATTRIBUTES name.
PHYSICALDISK Lists all physical disks. Use the results of LIST
PHYSICALDISK to identify a specific disk for
further investigation, then list the details of
that disk using the command as follows: LIST
PHYSICALDISK 20:10 DETAIL. To list the
details of flash disks, use the command as
follows: LIST PHYSICALDISK FLASH_1_0
DETAIL).
PLUGGABLEDATABASE Lists all PDBs. View the details of a
specific PDB with LIST PLUGGABLEDATABASE
pdb_name.
QUARANTINE Lists all SQL statements that you prevented
from using Smart Scans. The syntax is LIST
QUARANTINE DETAIL. You can also use
a "where" clause on any of the available
attributes.
DIAGPACK Use the ExaCLI CREATE, ALTER, DROP, and
LIST commands with DIAGPACK to list
the diagnostic packages and their status
in your Exadata system. The syntax is
LIST DIAGPACK [DETAIL], with DETAIL
being an optional attribute. Use CREATE
DIAGPACK with the packStartTime attribute
to gather logs and trace files into a single
compressed file for downloading, as in
the following example: CREATE DIAGPACK
packStartTime=2019_12_15T00_00_00.
You can also use the value now
with packStartTime: CREATE DIAGPACK
packStartTime=now.
To download a diagnostic package, use
DOWNLOAD DIAGPACK package_name
local_directory. For example, the following
command downloads a diagnostic package to
the /tmp directory: DOWNLOAD DIAGPACK
cfclcx2647_diag_2018_06_03T00_44_24_
1 /tmp.

Usage Notes
• Notes for the --cookie-jar option:

19-6
 Chapter 19
ExaCLI Command

– The user name and password are sent to the remote node for authentication.
On successful authentication, the remote node issues a cookie (the login
credentials) that is stored in the specified filename on the database node. If
filename is not specified, the cookie is stored in a default cookie jar located at
HOME/.exacli/cookiejar, where HOME is the home directory of the operating
system user running the ExaCLI command. For the opc user, the home is /
home/opc.
– The operating system user running the ExaCLI command is the owner of the
cookie jar file.
– A cookie jar can contain multiple cookies from multiple users on multiple
nodes in parallel sessions.
– Cookies are invalidated after 24 hours.
– If the cookie is not found or is no longer valid, ExaCLI prompts for the
password. The new cookie is stored in the cookie jar identified by filename, or
the default cookie jar if filename is not specified.
– Even without the --cookie-jar option, ExaCLI still checks for cookies from
the default cookie jar. However, if the cookie does not exist or is no longer
valid, the new cookie will not be stored in the default cookie jar if the --
cookie-jar option is not specified.
• Notes for the -e option:
– ExaCLI exits after running the commands.
– If specifying multiple commands to run, be sure to enclose the commands in
single quotes to prevent the shell from interpreting the semi-colon.
– The batch file is a text file that contains one or more ExaCLI commands to run.
• Notes for the -n (--no-prompt) option:
– If ExaCLI needs additional information from the user, for example, if ExaCLI
needs to prompt the user for a password (possibly because there were no
valid cookies in the cookie-jar) or to prompt the user to confirm the remote
node’s identity, then ExaCLI prints an error message and exits.

Examples
Example 19-1 Starting an Interactive ExaCLI Session on a Storage Server
This example shows the user on an Exadata compute node issuing the command to
log in to ExaCLI start an interactive ExaCLI session on a storage server:

exacli -l cloud_user_clustername -c 192.168.136.7

See "Finding the IP addresses of storage cells using the cellip.ora file" for information
about how to determine your storage server IP address.
After you are logged in, run additional commands as follows:

exacli [email protected]> LIST DATABASE

ASM
HRCDB

19-7
 Chapter 19
Connecting to a Storage Server with ExaCLI

Example 19-2 Issuing a Single Command on a Compute Node

This example shows a single command issued on a compute node that does the
following:
• Connects to a storage server
• Performs a LIST action
• Exits the session (specified with the -e option)

exacli -l cloud_user_clustername -c 192.168.136.7 --xml --cookie-jar -e

list griddisk detail

Related Topics
• Finding the IP addresses of storage cells using the cellip.ora file

Connecting to a Storage Server with ExaCLI

To use ExaCLI on storage servers, you will need to know your target storage server's
IP address.
If you do not know the IP address of the node you want to connect to, you can find it
by viewing the contents of the cellip.ora file.

The following example illustrates how to do so on the UNIX command line for a quarter
rack system. (Note that a quarter rack has three storage cells, and each cell has two
connections, so a total of six IP addresses are shown.)

cat /etc/oracle/cell/
network-config/cellip.oracle
cell="192.168.136.5;cell="192.168.136.6"
cell="192.168.136.7;cell="192.168.136.8"
cell="192.168.136.9;cell="192.168.136.10"

If you are connecting to a storage cell for the first time using ExaCLI, you may be
prompted to accept an SSL certificate. The ExaCLI output in this case will look like the
following:

exacli -l cloud_user_clustername -c 192.168.136.7 --cookie-jar

No cookies found for [email protected]
Password: *********
EXA-30016: This connection is not secure. You have asked ExaCLI to
connect to cell 192.168.136.7 securely. The identity of 192.168.136.7
cannot be verified.
Got certificate from server:
C=US,ST=California,L=Redwood City,O=Oracle Corporation,OU=Oracle
Exadata,CN=ed1cl03clu01-priv2.usdc2.oraclecloud.com
Do you want to accept and store this certificate? (Press y/n)

Accept the self-signed Oracle certificate by pressing "y" to continue using ExaCLI.

19-8
20
Policy Details for Exadata
Cloud@Customer
Learn to write policies to control access to Exadata Cloud@Customer resources.

Note:
For more information on Policies, see "How Policies Work".
For a sample policy, see "Let database admins manage Exadata
Cloud@Customer instances".

• About Resource-Types
Learn about resource-types you can use in your policies.
• Resource-Types for Exadata Cloud@Customer
Review the list of resource-types specific to Exadata Cloud@Customer.
• Supported Variables
Use variables when adding conditions to a policy.
• Details for Verb + Resource-Type Combinations
Review the list of permissions and API operations covered by each verb.
• Permissions Required for Each API Operation
Review the list of API operations for Exadata Cloud@Customer resources in a
logical order, grouped by resource type.
Related Topics
• How Policies Work
• Let database admins manage Exadata Cloud@Customer instances

About Resource-Types
Learn about resource-types you can use in your policies.
An aggregate resource-type covers the list of individual resource-types that directly
follow. For example, writing one policy to allow a group to have access to the
database-family is equivalent to writing eight separate policies for the group
that would grant access to the exadata-infrastructures, vmcluster-networks,
vmclusters, backups-destinations, db-nodes, and the rest of the individual resource-
types. For more information, see Resource-Types.

20-1
 Chapter 20
Resource-Types for Exadata Cloud@Customer

Resource-Types for Exadata Cloud@Customer

Review the list of resource-types specific to Exadata Cloud@Customer.

Aggregate Resource-Type

database-family

Individual Resource-Types

exadata-infrastructures

vmcluster-networks

vmclusters

backups-destinations

db-nodes

db-homes

databases

backups

Supported Variables
Use variables when adding conditions to a policy.
Exadata Cloud@Customer supports only the general variables. For more information,
see "General Variables for All Requests".
Related Topics
• General Variables for All Requests

Details for Verb + Resource-Type Combinations

Review the list of permissions and API operations covered by each verb.
For more information, see "Permissions", "Verbs", and "Resource-Types".
• Database-Family Resource Types
Understand the level of access of each verb.

20-2
 Chapter 20
Details for Verb + Resource-Type Combinations

• exadata-infrastructures
Review the list of permissions and API operations for exadata-infrastructures
resource-type.
• vmcluster-networks
Review the list of permissions and API operations for vmcluster-networks
resource-type.
• vmclusters
Review the list of permissions and API operations for vmclusters resource-type.
• backup-destinations
Review the list of permissions and API operations for backup-destinations
resource-type.
• db-nodes
Review the list of permissions and API operations for db-nodes resource-type.
• db-homes
Review the list of permissions and API operations for db-homes resource-type.
• databases
Review the list of permissions and API operations for databases resource-type.
• backups
Review the list of permissions and API operations for backups resource-type.
• autonomous-vmclusters
Review the list of permissions and API operations for autonomous-vmclusters
resource-type.
• autonomous-container-databases
Review the list of permissions and API operations for autonomous-container-
databases resource-type.
• autonomous-databases
Review the list of permissions and API operations for autonomous-container-
databases resource-type.
• data-guard-association
Review the list of permissions and API operations for data-guard-association
resource-type.
• key-stores
Review the list of permissions and API operations for key-store resource-type.
• autonomousContainerDatabaseDataguardAssociations
Review the list of permissions and API operations for
autonomousContainerDatabaseDataguardAssociations resource-type.
• AutonomousDatabaseDataguardAssociation
Review the list of permissions and API operations for
AutonomousDatabaseDataguardAssociation resource-type.
Related Topics
• Permissions
• Verbs
• Resource-Types

20-3
 Chapter 20
Details for Verb + Resource-Type Combinations

Database-Family Resource Types

Understand the level of access of each verb.
The level of access is cumulative as you go from inspect > read > use > manage. A
plus sign (+) in a table cell indicates incremental access compared to the cell directly
above it, whereas "no extra" indicates no incremental access.
For example, the read verb for the vmclusters resource-type covers no extra
permissions or API operations compared to the inspect verb. However, the use verb
includes one more permission, fully covers one more operation, and partially covers
another additional operation.

exadata-infrastructures
Review the list of permissions and API operations for exadata-infrastructures
resource-type.
Granting permissions on exadata-infrastructure resources grants permissions on
associated vmcluster-network resources.

Table 20-1 INSPECT

Permission APIs Fully Covered APIs Partially Covered

EXADATA_INFRASTRUCTURE_ ListExadataInfrastructu ChangeExadataInfrastruc
INSPECT res tureCompartment
GetExadataInfrastructur
e
GenerateRecommendedNetw
orkDetails

Table 20-2 READ

Permissions APIs Fully Covered APIs Partially Covered

INSPECT + DownloadExadataInfrastr none
EXADATA_INFRASTRUCTURE_ uctureConfigFile
CONTENT_READ

Table 20-3 USE

Permissions APIs Fully Covered APIs Partially Covered

READ + ActivateExadataInfrastr CreateVmCluster (also
EXADATA_INFRASTRUCTURE_ ucture needs manage vmclusters)
UPDATE UpdateExadataInfrastruc UpdateVmCluster (also
ture needs use vmclusters)
ChangeExadataInfrastruc ChangeExadataInfrastruc
tureCompartment tureCompartment

20-4
 Chapter 20
Details for Verb + Resource-Type Combinations

Table 20-4 MANAGE

Permissions APIs Fully Covered APIs Partially Covered

USE + CreateExadataInfrastruc none
EXADATA_INFRASTRUCTURE_ ture
CREATE DeleteExadataInfrastruc
EXADATA_INFRASTRUCTURE_ ture
DELETE downloadExadataInfrastr
uctureConfigFile

vmcluster-networks
Review the list of permissions and API operations for vmcluster-networks resource-
type.
vmcluster-network resources inherit permissions from the exadata-infrastructure
resources with which they are associated. You cannot grant permissions to
vmcluster-network resources explicitly.

Table 20-5 INSPECT

Permission APIs Fully Covered APIs Partially Covered

EXADATA_INFRASTRUCTURE_ ListVmClusterNetworks none
INSPECT GetVmClusterNetwork
ValidateVmClusterNetwor
k

Table 20-6 READ

Permissions APIs Fully Covered APIs Partially Covered

INSPECT + DownloadVmClusterNetwor none
EXADATA_INFRASTRUCTURE_ kConfigFile
CONTENT_READ

Table 20-7 USE

Permissions APIs Fully Covered APIs Partially Covered

READ + CreateVmClusterNetwork none
EXADATA_INFRASTRUCTURE_ UpdateVmClusterNetwork
UPDATE DeleteVmClusterNetwork

20-5
 Chapter 20
Details for Verb + Resource-Type Combinations

Table 20-8 MANAGE

Permissions APIs Fully Covered APIs Partially Covered

USE + none none
EXADATA_INFRASTRUCTURE_
CREATE
EXADATA_INFRASTRUCTURE_
DELETE

vmclusters
Review the list of permissions and API operations for vmclusters resource-type.

Table 20-9 INSPECT

Permission APIs Fully Covered APIs Partially Covered

VM_CLUSTER_INSPECT ListVmClusters none
GetVmCluster
ListVmClusterPatches
ListVmClusterPatchHisto
ryEntries
GetVmClusterPatch
GetVmClusterPatchHistor
yEntry

Table 20-10 READ

Permissions APIs Fully Covered APIs Partially Covered

No extra No extra none

20-6
 Chapter 20
Details for Verb + Resource-Type Combinations

Table 20-11 USE

Permissions APIs Fully Covered APIs Partially Covered

READ + ChangeVmClusterCompartm UpdateVmCluster (also
VM_CLUSTER_UPDATE ent needs use exadata-
infrastructures)
CreateDbHome, (also needs
manage db-homes and
manage databases). If
automatic backups are
enabled on the default
database, also needs manage
backups
DeleteDbHome, (also needs
manage db-homes and
manage databases. If
automatic backups are
enabled on the default
database, also needs manage
backups

Table 20-12 MANAGE

Permissions APIs Fully Covered APIs Partially Covered

USE + No extra CreateVmCluster (also
VM_CLUSTER_CREATE needs use exadata-
infrastructures)
VM_CLUSTER_DELETE
DeleteVmCluster (also
needs use exadata-
infrastructures)

backup-destinations
Review the list of permissions and API operations for backup-destinations resource-
type.

Table 20-13 INSPECT

Permissions APIs Fully Covered APIs Partially Covered

BACKUP_DESTINATION_INSP ListBackupDestinations none
ECT GetBackupDestination

Table 20-14 READ

Permissions APIs Fully Covered APIs Partially Covered

no extra no extra none

20-7
 Chapter 20
Details for Verb + Resource-Type Combinations

Table 20-15 USE

Permissions APIs Fully Covered APIs Partially Covered

READ + UpdateBackupDestination none
BACKUP_DESTINATION_UPDA ChangeBackupDestination
TE Compartment

Table 20-16 MANAGE

Permissions APIs Fully Covered APIs Partially Covered

USE + CreateBackupDestination none
BACKUP_DESTINATION_CREA DeleteBackupDestination
TE
BACKUP_DESTINATION_DELE
TE

db-nodes
Review the list of permissions and API operations for db-nodes resource-type.

Table 20-17 INSPECT

Permissions APIs Fully Covered APIs Partially Covered

DB_NODE_INSPECT GetDbNode none
DB_NODE_QUERY

Table 20-18 READ

Permissions APIs Fully Covered APIs Partially Covered

No extra No extra none

Table 20-19 USE

Permissions APIs Fully Covered APIs Partially Covered

No extra No extra none

Table 20-20 MANAGE

Permissions APIs Fully Covered APIs Partially Covered

USE + DbNodeAction none
DB_NODE_POWER_ACTIONS

20-8
 Chapter 20
Details for Verb + Resource-Type Combinations

db-homes
Review the list of permissions and API operations for db-homes resource-type.

Table 20-21 INSPECT

Permissions APIs Fully Covered APIs Partially Covered

DB_HOME_INSPECT ListDBHome none
GetDBHome
ListDbHomePatches
ListDbHomePatchHistoryE
ntries
GetDbHomePatch
GetDbHomePatchHistoryEn
try

Table 20-22 READ

Permissions APIs Fully Covered APIs Partially Covered

No extra No extra none

Table 20-23 USE

Permissions APIs Fully Covered APIs Partially Covered

DB_HOME_UPDATE UpdateDBHome none

Table 20-24 MANAGE

Permissions APIs Fully Covered APIs Partially Covered

USE + No extra CreateDbHome, (also needs
DB_HOME_CREATE use vmclusters and
manage databases). If
DB_HOME_DELETE
automatic backups are
enabled on the default
database, also needs manage
backups
DeleteDbHome, (also needs
use vmclusters and
manage databases). If
automatic backups are
enabled on the default
database, also needs manage
backups.

databases
Review the list of permissions and API operations for databases resource-type.

20-9
 Chapter 20
Details for Verb + Resource-Type Combinations

Table 20-25 INSPECT

Permissions APIs Fully Covered APIs Partially Covered

DATABASE_INSPECT ListDatabases none
GetDatabase

Table 20-26 READ

Permissions APIs Fully Covered APIs Partially Covered

No extra No extra none

Table 20-27 USE

Permissions APIs Fully Covered APIs Partially Covered

READ + UpdateDatabase If enabling automatic backups,
DATABASE_UPDATE also needs manage backups.

Table 20-28 MANAGE

Permissions APIs Fully Covered APIs Partially Covered

USE + No extra CreateDbHome, (also needs
DATABASE_CREATE use vmclusters and
manage db-homes). If
DATABASE_DELETE
automatic backups are
enabled on the default
database, also needs manage
backups
DeleteDbHome, (also needs
use vmclusters and
manage db-homes). If
automatic backups are
enabled on the default
database, also needs manage
backups

backups
Review the list of permissions and API operations for backups resource-type.

Table 20-29 INSPECT

Permissions APIs Fully Covered APIs Partially Covered

DB_BACKUP_INSPECT GetBackup none
ListBackups

20-10
 Chapter 20
Details for Verb + Resource-Type Combinations

Table 20-30 READ

Permissions APIs Fully Covered APIs Partially Covered

INSPECT + none RestoreDatabase (also
DB_BACKUP_CONTENT_READ needs use databases)

Table 20-31 USE

Permissions APIs Fully Covered APIs Partially Covered

no extra no extra none

Table 20-32 MANAGE

Permissions APIs Fully Covered APIs Partially Covered

USE + no extra none
DB_BACKUP_CREATE
DB_BACKUP_DELETE

autonomous-vmclusters
Review the list of permissions and API operations for autonomous-vmclusters
resource-type.

Table 20-33 INSPECT

Permissions APIs Fully Covered APIs Partially Covered

AUTONOMOUS_VM_CLUSTER_I ListAutonomousVmCluster ChangeAutonomousVmClust
NSPECT s erCompartment
GetAutonomousVmCluster

Table 20-34 READ

Permissions APIs Fully Covered APIs Partially Covered

No extra No extra none

Table 20-35 USE

Permissions APIs Fully Covered APIs Partially Covered

READ + ChangeAutonomousVmClust UpdateAutonomousVmClust
AUTONOMOUS_VM_CLUSTER_U erCompartment er
PDATE CreateAutonomousContain
erDatabase
TerminateAutonomousCont
ainerDatabase

20-11
 Chapter 20
Details for Verb + Resource-Type Combinations

Table 20-36 MANAGE

Permissions APIs Fully Covered APIs Partially Covered

USE + DeleteAutonomousVmClust CreateAutonomousVmClust
AUTONOMOUS_VM_CLUSTER_C er er
REATE +
AUTONOMOUS_VM_CLUSTER_D
ELETE

autonomous-container-databases
Review the list of permissions and API operations for autonomous-container-
databases resource-type.

Table 20-37 INSPECT

Permissions APIs Fully Covered APIs Partially Covered

AUTONOMOUS_CONTAINER_DA ListAutonomousContainer none
TABASE_INSPECT Databases,
GetAutonomousContainerD
atabase

Table 20-38 READ

Permissions APIs Fully Covered APIs Partially Covered

No extra No extra none

Table 20-39 USE

Permissions APIs Fully Covered APIs Partially Covered

AUTONOMOUS_CONTAINER_DA UpdateAutonomousContain CreateAutonomousDatabas
TABASE_UPDATE erDatabase e (also needs manage
ChangeAutonomousContain autonomous-databases)
erDatabaseCompartment

Table 20-40 MANAGE

Permissions APIs Fully Covered APIs Partially Covered

USE + No extra CreateAutonomousContain
AUTONOMOUS_CONTAINER_DA erDatabase,
TABASE_CREATE TerminateAutonomousCont
ainerDatabase (both also
AUTONOMOUS_CONTAINER_DA
need use autonomous-
TABASE_DELETE
VmCluster)

20-12
 Chapter 20
Details for Verb + Resource-Type Combinations

autonomous-databases
Review the list of permissions and API operations for autonomous-container-
databases resource-type.

Table 20-41 INSPECT

Permissions APIs Fully Covered APIs Partially Covered

AUTONOMOUS_DATABASE_INS GetAutonomousDatabase, no extra
PECT ListAutonomousDatabases

Table 20-42 READ

Permissions APIs Fully Covered APIs Partially Covered

INSPECT + no extra CreateAutonomousDatabas
AUTONOMOUS_DATABASE_CON eBackup (also needs manage
TENT_READ autonomous-backups)

Table 20-43 USE

Permissions APIs Fully Covered APIs Partially Covered

READ + UpdateAutonomousDatabas RestoreAutonomousDataba
AUTONOMOUS_DATABASE_CON e se (also needs read
TENT_WRITE + autonomous-backups)
AUTONOMOUS_DATABASE_UPD ChangeAutonomousDatabas
ATE eCompartment (also needs
read autonomous-backups)

Table 20-44 MANAGE

Permissions APIs Fully Covered APIs Partially Covered

USE + CreateAutonomousDatabas none
AUTONOMOUS_DATABASE_CRE e
ATE
AUTONOMOUS_DATABASE_DEL
ETE

data-guard-association
Review the list of permissions and API operations for data-guard-association
resource-type.

20-13
 Chapter 20
Details for Verb + Resource-Type Combinations

Table 20-45 INSPECT

Permissions APIs Fully Covered APIs Partially Covered

DATABASE_INSPECT ListDataGuardAssociatio CreateDataGuardAssociat
ns, ion
GetDataGuardAssociation

Table 20-46 READ

Permissions APIs Fully Covered APIs Partially Covered

no extra no extra no extra

Table 20-47 USE

Permissions APIs Fully Covered APIs Partially Covered

READ + VM_CLUSTER_UPDATE DeleteDatabase CreateDataGuardAssociat
+ DB_HOME_UPDATE SwitchoverDataGuardAsso ion
DATABASE_UPDATE ciation,FailoverDataGua
rdAssociation,
ReinstateDataGuardAssoc
iation

Table 20-48 MANAGE

Permissions APIs Fully Covered APIs Partially Covered

USE + DeleteDatabase none
DATABASE_DELETE

key-stores
Review the list of permissions and API operations for key-store resource-type.

Table 20-49 INSPECT

Permissions APIs Fully Covered APIs Partially Covered

KEY_STORE_INPSECT GetKeyStore ChangeKeyStoreCompartme
AUTONOMOUS_CONTAINER_DA GetAutonomousContainerD nt
TABASE_INSPECT atabase RotateAutonomousContain
AUTONOMOUS_DATABASE_INS GetAutonomousDatabase erDatabaseKey
PECT GetAutonomousDatabaseBa
AUTONOMOUS_DB_BACKUP_IN ckup
SPECT

20-14
 Chapter 20
Details for Verb + Resource-Type Combinations

Table 20-50 READ

Permissions APIs Fully Covered APIs Partially Covered

no extra no extra no extra

Table 20-51 USE

Permissions APIs Fully Covered APIs Partially Covered

READ + KEY_STORE_UPDATE UpdateKeyStore ChangeKeyStoreCompartme
+ none nt
AUTONOMOUS_VM_CLUSTER_U none CreateAutonomousContain
PDATE + erDatabase
none
AUTONOMOUS_CONTAINER_DA RotateAutonomousDatabas RotateAutonomousContain
TABASE_UPDATE eKey erDatabaseKey
AUTONOMOUS_DATABASE_UPD none
ATE

Table 20-52 MANAGE

Permissions APIs Fully Covered APIs Partially Covered

USE + KEY_STORE_CREATE + CreateKeyStore none
KEY_STORE_DELETE + DeleteKeyStore none
AUTONOMOUS_CONTAINER_DA CreateAutonomousContain none
TABASE_CREATE erDatabase

autonomousContainerDatabaseDataguardAssociations
Review the list of permissions and API operations for
autonomousContainerDatabaseDataguardAssociations resource-type.

Table 20-53 INSPECT

Permissions APIs Fully Covered APIs Partially Covered

AUTONOMOUS_VM_CLUSTER_I none CreateAutonomousContain
NSPECT GetAutonomousContainerD erDatabase
AUTONOMOUS_CONTAINER_DA atabase FailoverAutonomousConta
TABASE_INSPECT ListAutonomousContainer inerDatabaseDataguardAs
DatabaseDataguardAssoci sociation
ations SwitchoverAutonomousCon
GetAutonomousContainerD tainerDatabaseDataguard
atabaseDataguardAssocia Association
tion ReinstateAutonomousCont
ainerDatabaseDataguardA
ssociation

20-15
 Chapter 20
Details for Verb + Resource-Type Combinations

Table 20-54 READ

Permissions APIs Fully Covered APIs Partially Covered

no extra no extra no extra

Table 20-55 USE

Permissions APIs Fully Covered APIs Partially Covered

READ + none CreateAutonomousContain
AUTONOMOUS_VM_CLUSTER_U none erDatabase
PDATE + deleteAutonomouContaine
AUTONOMOUS_CONTAINER_DA rDatabase
TABASE_UPDATE FailoverAutonomousConta
inerDatabaseDataguardAs
sociation
SwitchoverAutonomousCon
tainerDatabaseDataguard
Association
ReinstateAutonomousCont
ainerDatabaseDataguardA
ssociation

Table 20-56 MANAGE

Permissions APIs Fully Covered APIs Partially Covered

USE + none CreateAutonomousContain
AUTONOMOUS_CONTAINER_DA none erDatabase
TABASE_CREATE + deleteAutonomouContaine
AUTONOMOUS_CONTAINER_DA rDatabase
TABASE_DELETE

AutonomousDatabaseDataguardAssociation
Review the list of permissions and API operations for
AutonomousDatabaseDataguardAssociation resource-type.

Table 20-57 INSPECT

Permissions APIs Fully Covered APIs Partially Covered

AUTONOMOUS_DATABASE_INS GetAutonomousDatabase none
PECT

Table 20-58 READ

Permissions APIs Fully Covered APIs Partially Covered

no extra no extra no extra

20-16
 Chapter 20
Permissions Required for Each API Operation

Table 20-59 USE

Permissions APIs Fully Covered APIs Partially Covered

READ + no extra no extra no extra

Table 20-60 MANAGE

Permissions APIs Fully Covered APIs Partially Covered

USE + no extra no extra no extra

Permissions Required for Each API Operation

Review the list of API operations for Exadata Cloud@Customer resources in a logical
order, grouped by resource type.
For information about permissions, see Permissions.

Table 20-61 Database API Operations

API Operation Permissions Required to Use the

Operation
ListExadataInfrastructures EXADATA_INFRASTRUCTURE_INSPECT
GetExadataInfrastructure EXADATA_INFRASTRUCTURE_INSPECT
CreateExadataInfrastructure EXADATA_INFRASTRUCTURE_CREATE
UpdateExadataInfrastructure EXADATA_INFRASTRUCTURE_UPDATE
ChangeExadataInfrastructureCompartme EXADATA_INFRASTRUCTURE_INSPECT and
nt EXADATA_INFRASTRUCTURE_UPDATE
DeleteExadataInfrastructure EXADATA_INFRASTRUCTURE_DELETE
DownloadExadataInfrastructureConfigF EXADATA_INFRASTRUCTURE_CONTENT_READ
ile
DownloadExadataInfrastructureConfigF EXADATA_INFRASTRUCTURE_CONTENT_READ
ile
ActivateExadataInfrastructure EXADATA_INFRASTRUCTURE_UPDATE
GenerateRecommendedNetworkDetails EXADATA_INFRASTRUCTURE_INSPECT
ListVmClusterNetworks EXADATA_INFRASTRUCTURE_INSPECT
GetVmClusterNetwork EXADATA_INFRASTRUCTURE_INSPECT
CreateVmClusterNetwork EXADATA_INFRASTRUCTURE_INSPECT and
EXADATA_INFRASTRUCTURE_UPDATE
UpdateVmClusterNetwork EXADATA_INFRASTRUCTURE_INSPECT and
EXADATA_INFRASTRUCTURE_UPDATE
DeleteVmClusterNetwork EXADATA_INFRASTRUCTURE_UPDATE
DownloadVmClusterNetworkConfigFile EXADATA_INFRASTRUCTURE_INSPECT and
EXADATA_INFRASTRUCTURE_CONTENT_READ
ValidateVmClusterNetwork EXADATA_INFRASTRUCTURE_INSPECT

20-17
 Chapter 20
Permissions Required for Each API Operation

Table 20-61 (Cont.) Database API Operations

API Operation Permissions Required to Use the

Operation
ListVmClusters VM_CLUSTER_INSPECT
GetVmCluster VM_CLUSTER_INSPECT
CreateVmCluster EXADATA_INFRASTRUCTURE_INSPECT and
EXADATA_INFRASTRUCTURE_UPDATE and
VM_CLUSTER_CREATE
UpdateVmCluster EXADATA_INFRASTRUCTURE_INSPECT and
EXADATA_INFRASTRUCTURE_UPDATE and
VM_CLUSTER_UPDATE
ChangeVmClusterCompartment VM_CLUSTER_INSPECT and
VM_CLUSTER_UPDATE
DeleteVmCluster VM_CLUSTER_DELETE
ListVmClusterPatches VM_CLUSTER_INSPECT
ListVmClusterPatchHistoryEntries VM_CLUSTER_INSPECT
GetVmClusterPatch VM_CLUSTER_INSPECT
GetVmClusterPatchHistoryEntry VM_CLUSTER_INSPECT
ListBackupDestinations BACKUP_DESTINATION_INSPECT
GetBackupDestination BACKUP_DESTINATION_INSPECT
CreateBackupDestination BACKUP_DESTINATION_CREATE
UpdateBackupDestination BACKUP_DESTINATION_UPDATE
DeleteBackupDestination BACKUP_DESTINATION_DELETE
ChangeBackupDestinationCompartment BACKUP_DESTINATION_INSPECT and
BACKUP_DESTINATION_UPDATE
GetDbNode DB_NODE_INSPECT
DbNodeAction DB_NODE_POWER_ACTIONS
ListDbHomes DB_HOME_INSPECT
GetDbHome DB_HOME_INSPECT
CreateDbHome VM_CLUSTER_INSPECT and
VM_CLUSTER_UPDATE and DB_HOME_CREATE
and DATABASE_CREATE
To enable automatic backups for the
database, also need DB_BACKUP_CREATE and
DATABASE_CONTENT_READ.
UpdateDbHome DB_HOME_UPDATE
DeleteDbHome VM_CLUSTER_UPDATE and DB_HOME_UPDATE
and DATABASE_DELETE
ListDbHomePatches DB_HOME_INSPECT
ListDbHomePatchHistoryEntries DB_HOME_INSPECT
GetDbHomePatch DB_HOME_INSPECT
GetDbHomePatchHistoryEntry DB_HOME_INSPECT

20-18
 Chapter 20
Permissions Required for Each API Operation

Table 20-61 (Cont.) Database API Operations

API Operation Permissions Required to Use the

Operation
CreateDatabase VM_CLUSTER_INSPECT,
VM_CLUSTER_UPDATE, DB_HOME_INSPECT,
DB_HOME_UPDATE, DATABASE_CREATE
DB_BACKUP_CREATE and
DATABASE_CONTENT_READ
DB_BACKUP_INSPECT,
DB_BACKUP_CONTENT_READ
ListDatabases DATABASE_INSPECT
GetDatabase DATABASE_INSPECT
UpdateDatabase DATABASE_UPDATE
To enable automatic backups,
also need DB_BACKUP_CREATE and
DATABASE_CONTENT_READ
DeleteDatabase VM_CLUSTER_UPDATE, DB_HOME_UPDATE,
DATABASE_DELETE
DB_BACKUP_INSPECT, DB_BACKUP_DELETE
DB_BACKUP_CREATE and
DATABASE_CONTENT_READ
ListDbVersions (no permissions required; available to anyone)
GetBackup DB_BACKUP_INSPECT
ListBackups DB_BACKUP_INSPECT
CreateBackup DB_BACKUP_CREATE and
DATABASE_CONTENT_READ
DeleteBackup DB_BACKUP_DELETE and
DB_BACKUP_INSPECT
RestoreDatabase DB_BACKUP_INSPECT and
DB_BACKUP_CONTENT_READ and
DATABASE_CONTENT_WRITE
CreateAutonomousVmCluster AUTONOMOUS_VM_CLUSTER_CREATE and
EXADATA_INFRASTRUCTURE_INSPECT and
EXADATA_INFRASTRUCTURE_UPDATE
ListAutonomousVmClusters AUTONOMOUS_VM_CLUSTER_INSPECT
GetAutonomousVmCluster AUTONOMOUS_VM_CLUSTER_INSPECT
UpdateAutonomousVmCluster AUTONOMOUS_VM_CLUSTER_UPDATE and
EXADATA_INFRASTRUCTURE_INSPECT and
EXADATA_INFRASTRUCTURE_UPDATE
ChangeAutonomousVmClusterCompartment AUTONOMOUS_VM_CLUSTER_INSPECT and
AUTONOMOUS_VM_CLUSTER_UPDATE
DeleteAutonomousVmCluster AUTONOMOUS_VM_CLUSTER_DELETE
ListAutonomousContainerDatabases AUTONOMOUS_CONTAINER_DATABASE_INSPEC
T

20-19
 Chapter 20
Permissions Required for Each API Operation

Table 20-61 (Cont.) Database API Operations

API Operation Permissions Required to Use the

Operation
GetAutonomousContainerDatabase AUTONOMOUS_CONTAINER_DATABASE_INSPEC
T
CreateAutonomousContainerDatabase AUTONOMOUS_VM_CLUSTER_UPDATE and
AUTONOMOUS_CONTAINER_DATABASE_CREATE
TerminateAutonomousContainerDatabase AUTONOMOUS_VM_CLUSTER_UPDATE and
AUTONOMOUS_CONTAINER_DATABASE_DELETE
UpdateAutonomousContainerDatabase AUTONOMOUS_CONTAINER_DATABASE_UPDATE
ChangeAutonomousContainerDatabaseCom AUTONOMOUS_CONTAINER_DATABASE_INSPEC
partment T and
AUTONOMOUS_CONTAINER_DATABASE_UPDATE
GetAutonomousDatabase AUTONOMOUS_DATABASE_INSPECT
ListAutonomousDatabases AUTONOMOUS_DATABASE_INSPECT
CreateAutonomousDatabase AUTONOMOUS_DATABASE_CREATE and
AUTONOMOUS_CONTAINER_DATABASE_INSPEC
T
UpdateAutonomousDatabase AUTONOMOUS_DATABASE_UPDATE
ChangeAutonomousDatabaseCompartment AUTONOMOUS_DATABASE_UPDATE and
AUTONOMOUS_DB_BACKUP_INSPECT and
AUTONOMOUS_DB_BACKUP_CONTENT_READ
and
AUTONOMOUS_DATABASE_CONTENT_WRITE
and AUTONOMOUS_DB_BACKUP_CREATE
DeleteAutonomousDatabase AUTONOMOUS_DATABASE_DELETE
StartAutonomousDatabase AUTONOMOUS_DATABASE_UPDATE
StopAutonomousDatabase AUTONOMOUS_DATABASE_UPDATE
RestoreAutonomousDatabase AUTONOMOUS_DB_BACKUP_CONTENT_READ
and
AUTONOMOUS_DATABASE_CONTENT_WRITE
CreateAutonomousDatabaseBackup AUTONOMOUS_DB_BACKUP_CREATE and
AUTONOMOUS_DATABASE_CONTENT_READ
DeleteAutonomousDatabaseBackup AUTONOMOUS_DB_BACKUP_DELETE
ListAutonomousDatabaseBackups AUTONOMOUS_DB_BACKUP_DELETE
GetAutonomousDatabaseBackup AUTONOMOUS_DB_BACKUP_DELETE
CreateDataGuardAssociation VM_CLUSTER_INSPECT and
DATABASE_INSPECT and DATABASE_UPDATE
GetDataGuardAssociation DATABASE_INSPECT
ListDataGuardAssociations DATABASE_INSPECT
SwitchoverDataGuardAssociation DATABASE_UPDATE
FailoverDataGuardAssociation DATABASE_UPDATE
ReinstateDataGuardAssociation DATABASE_UPDATE

20-20
 Chapter 20
Permissions Required for Each API Operation

Table 20-61 (Cont.) Database API Operations

API Operation Permissions Required to Use the

Operation
DeleteDatabase VM_CLUSTER_UPDATE and DB_HOME_UPDATE
and DATABASE_DELETE
CreateKeyStore KEY_STORE_CREATE
GetKeyStore KEY_STORE_INSPECT
UpdateKeyStore KEY_STORE_UPDATE
DeleteKeyStore KEY_STORE_DELETE
ChangeKeyStoreCompartment KEY_STORE_INPSECT and
KEY_STORE_UPDATE
CreateAutonomousContainerDatabase AUTONOMOUS_VM_CLUSTER_UPDATE and
AUTONOMOUS_CONTAINER_DATABASE_CREATE
GetAutonomousContainerDatabase AUTONOMOUS_CONTAINER_DATABASE_INSPEC
T
RotateAutonomousContainerDatabaseKey AUTONOMOUS_CONTAINER_DATABASE_UPDATE
and
AUTONOMOUS_CONTAINER_DATABASE_INSPEC
T
GetAutonomousDatabase AUTONOMOUS_DATABASE_INSPECT
RotateAutonomousDatabaseKey AUTONOMOUS_DATABASE_UPDATE
GetAutonomousDatabaseBackup AUTONOMOUS_DB_BACKUP_INSPECT
CreateAutonomousContainerDatabase No changes for Primary.
AUTONOMOUS_VM_CLUSTER_INSPECT,
AUTONOMOUS_VM_CLUSTER_UPDATE and
AUTONOMOUS_CONTAINER_DATABASE_CREATE
Standby:
AUTONOMOUS_CONTAINER_DATABASE_CREATE
GetAutonomousContainerDatabase AUTONOMOUS_CONTAINER_DATABASE_INSPEC
T
deleteAutonomouContainerDatabase AUTONOMOUS_VM_CLUSTER_UPDATE and
AUTONOMOUS_CONTAINER_DATABASE_DELETE
ListAutonomousContainerDatabaseDatag AUTONOMOUS_CONTAINER_DATABASE_INSPEC
uardAssociations T
GetAutonomousContainerDatabaseDatagu AUTONOMOUS_CONTAINER_DATABASE_INSPEC
ardAssociation T
FailoverAutonomousContainerDatabaseD AUTONOMOUS_CONTAINER_DATABASE_INSPEC
ataguardAssociation T and
AUTONOMOUS_CONTAINER_DATABASE_UPDATE
SwitchoverAutonomousContainerDatabas AUTONOMOUS_CONTAINER_DATABASE_INSPEC
eDataguardAssociation T and
AUTONOMOUS_CONTAINER_DATABASE_UPDATE
ReinstateAutonomousContainerDatabase AUTONOMOUS_CONTAINER_DATABASE_INSPEC
DataguardAssociation T and
AUTONOMOUS_CONTAINER_DATABASE_UPDATE

20-21
 Chapter 20
Permissions Required for Each API Operation

Table 20-61 (Cont.) Database API Operations

API Operation Permissions Required to Use the

Operation
ListAutonomousDatabaseDataguardAssoc AUTONOMOUS_CONTAINER_DATABASE_INSPEC
iations T
GetAutonomousDatabaseDataguardAssoci AUTONOMOUS_CONTAINER_DATABASE_INSPEC
ation T
GetAutonomousDatabase AUTONOMOUS_DATABASE_INSPECT

20-22
21
Oracle Exadata Cloud@Customer Events
The Oracle Database resources emit events, which are structured messages that
indicate changes in resources.
• Exadata Infrastructure Event Types
Review the list of event types that Exadata Infrastructure instances emit.
• VM Cluster Network Event Types
Review the list of event types that VM cluster networks emit.
• VM Cluster Event Types
Review the list of event types that VM clusters emit.
• Backup Destination Event Types
Review the list of event types that backup destinations emit.
• Database Node Event Types (Cloud@Customer)
Review the list of event types that database nodes emit.
• Database Home Event Types (Cloud@Customer)
Review the list of event types that Database Homes emit.
• Database Event Types (Cloud@Customer)
Review the list of event types that databases emit.
• Database and Grid Infrastructure Patching Event Types
Review the list of event types that Database and Grid Infrastructure Patching emit.
• Autonomous VM Cluster Event Types
Review the list of event types that Autonomous VM clusters emit.
• Autonomous Container Database Event Types
Review the list of event types that Autonomous Container Database emit.
• Autonomous Database Event Types
Review the list of event types that Autonomous Database emit.
• Data Guard Event Types
Review the list of event types that Data Guard associations emit.
• Autonomous Database Autonomous Data Guard Event Types
Review the list of event types that Autnomous Data Guard associations emit.
• Key Store Event Types
Review the list of event types that Key Store emits.
• Exadata Cloud@Customer Infrastructure Patching Event Types
Review the list of event types that Exadata Cloud@Customer Infrastructure
patching emits.

Exadata Infrastructure Event Types

Review the list of event types that Exadata Infrastructure instances emit.

21-1
 Chapter 21
Exadata Infrastructure Event Types

Table 21-1 Exadata Infrastructure Event Types

Friendly Name Event Type

Activate Begin com.oraclecloud.databaseservice.acti
vateexadatainfrastructure.begin
Activate End com.oraclecloud.databaseservice.acti
vateexadatainfrastructure.end
Change Compartment com.oraclecloud.databaseservice.chan
geexadatainfrastructurecompartment
Configuration File Download com.oraclecloud.databaseservice.down
loadexadatainfrastructureconfigfile
Create Begin com.oraclecloud.databaseservice.crea
teexadatainfrastructure.begin
Create End com.oraclecloud.databaseservice.crea
teexadatainfrastructure.end
Delete Begin com.oraclecloud.databaseservice.dele
teexadatainfrastructure.begin
Delete End com.oraclecloud.databaseservice.dele
teexadatainfrastructure.end
Update Begin com.oraclecloud.databaseservice.upda
teexadatainfrastructure.begin
Update End com.oraclecloud.databaseservice.upda
teexadatainfrastructure.end
Exadata Infrastructure - com.oraclecloud.databaseservice.exad
Connectivity Status atainfrastructureconnectstatus

Example 21-1 Exadata Infrastructure Example

This is a reference event for Exadata Infrastructure instances:

{
"cloudEventsVersion": "0.1",
"eventID": "60600c06-d6a7-4e85-b56a-1de3e6042f57",
"eventType":
"com.oraclecloud.databaseservice.createexadatainfrastructure.begin",
"source": "databaseservice",
"eventTypeVersion": "version",
"eventTime": "2019-08-29T21:16:04Z",
"contentType": "application/json",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_ID"
},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",
"compartmentName": "example_name",
"resourceName": "my_exadata_infra",
"resourceId": "ExadataInfra-unique_ID",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},

21-2
 Chapter 21
Exadata Infrastructure Event Types

"additionalDetails": {
"id": "ocid1.id..oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-08-29T12:00:00.000Z",
"timeUpdated": "2019-08-29T12:30:00.000Z",
"lifecycleDetails": "detail message",
"shape": "ExadataCC.Base3.48",
"timeZone": "US/Pacific",
"displayName": "testDisplayName"
}
}
}

This is a reference event for Exadata Infrastructure - Connectivity Status:

{
"eventType" :
"com.oraclecloud.databaseservice.exadatainfrastructureconnectstatus",
"cloudEventsVersion" : "0.1",
"eventTypeVersion" : "2.0",
"source" : "DatabaseService",
"eventTime" : "2020-06-02T06:07:40.141Z",
"contentType" : "application/json",
"data" : {
"compartmentId" :
"ocid1.compartment.oc1..aaaaaaaayrygl4guhplo5rtiumx3eh4mk7grrkrqspzaltmv
bxecnbvhkrga",
"compartmentName" : "DBaaSInteg20160918ExaccTest",
"resourceName" : "MVM_HR",
"resourceId" : "ocid1.exadatainfrastructure.oc1.ap-
hyderabad-1.abuhsljrp2vzzenmqmctqciwro6euhhsmlrewiiemiktov5xyfsu5hiufjsq
",
"availabilityDomain" : "",
"additionalDetails" : {
"timeCreated" : "2020-05-28T00:23:18Z",
"timeUpdated" : "2020-06-02T06:07:40Z",
"lifecycleState" : "DISCONNECTED",
"lifecycleDetails" : "Exadata Infrastructure is not reachable.
Please lodge a Service Request (SR) with Oracle Support and provide
Infrastructure-id: ocid1.exadatainfrastructure.oc1.ap-
hyderabad-1.abuhsljrp2vzzenmqmctqciwro6euhhsmlrewiiemiktov5xyfsu5hiufjsq
.",
"shape" : "ExadataCC.Half3.200",
"timeZone" : "UTC"
},
"definedTags" : {
"Oracle-Tags" : {
"CreatedBy" : "[email protected]",
"CreatedOn" : "2020-05-28T00:23:18.291Z"
}
}
},
"eventID" : "cde92d45-a06b-4b69-a125-6005dd8c2f0c",
"extensions" : {

21-3
 Chapter 21
VM Cluster Network Event Types

"compartmentId" :
"ocid1.compartment.oc1..aaaaaaaayrygl4guhplo5rtiumx3eh4mk7grrkrqspzaltmv
bxecnbvhkrga"
}
}

VM Cluster Network Event Types

Review the list of event types that VM cluster networks emit.

Table 21-2 VM Cluster Network Event Types

Friendly Name Event Type

Create Begin com.oraclecloud.databaseservice.crea
tevmclusternetwork.begin
Create End com.oraclecloud.databaseservice.crea
tevmclusternetwork.end
Network Validation File Download com.oraclecloud.databaseservice.down
loadvmclusternetworkconfigfile
Terminate Begin com.oraclecloud.databaseservice.dele
tevmclusternetwork.begin
Terminate End com.oraclecloud.databaseservice.dele
tevmclusternetwork.end
Update Begin com.oraclecloud.databaseservice.crea
tevmclusternetwork.begin
Update End com.oraclecloud.databaseservice.crea
tevmclusternetwork.end
Validate Begin com.oraclecloud.databaseservice.vali
datevmclusternetwork.begin
Validate End com.oraclecloud.databaseservice.vali
datevmclusternetwork.end

Example 21-2 VM Cluster Network Example

This is a reference event for VM cluster networks:

{
"cloudEventsVersion": "0.1",
"eventID": "60600c06-d6a7-4e85-b56a-1de3e6042f57",
"eventType":
"com.oraclecloud.databaseservice.createvmclusternetwork.begin",
"source": "databaseservice",
"eventTypeVersion": "version",
"eventTime": "2019-08-29T21:16:04Z",
"contentType": "application/json",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_ID"
},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",

21-4
 Chapter 21
VM Cluster Event Types

"compartmentName": "example_name",
"resourceName": "my_vmcluster_network",
"resourceId": "VmClusterNetwork-unique_ID",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.id..oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-08-29T12:00:00.000Z",
"timeUpdated": "2019-08-29T12:30:00.000Z",
"lifecycleDetails": "detail message",
"exadataInfrastructureId": "ExadataInfra-unique_ID",
"displayName": "testDisplayName"
}
}
}

VM Cluster Event Types

Review the list of event types that VM clusters emit.

Table 21-3 VM Cluster Event Types

Friendly Name Event Type

Change Compartment com.oraclecloud.databaseservice.chan
gevmclustercompartment
Create Begin com.oraclecloud.databaseservice.crea
tevmcluster.begin
Create End com.oraclecloud.databaseservice.crea
tevmcluster.end
Terminate Begin com.oraclecloud.databaseservice.dele
tevmcluster.begin
Terminate End com.oraclecloud.databaseservice.dele
tevmcluster.end
Update Begin com.oraclecloud.databaseservice.upda
tevmcluster.begin
Update End com.oraclecloud.databaseservice.upda
tevmcluster.end

Example 21-3 VM Cluster Example

This is a reference event for VM clusters:

{
"cloudEventsVersion": "0.1",
"eventID": "60600c06-d6a7-4e85-b56a-1de3e6042f57",
"eventType":
"com.oraclecloud.databaseservice.createvmclusternetwork.begin",
"source": "databaseservice",
"eventTypeVersion": "version",

21-5
 Chapter 21
VM Cluster Event Types

"eventTime": "2019-08-29T21:16:04Z",
"contentType": "application/json",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_ID"
},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",
"compartmentName": "example_name",
"resourceName": "my_vmcluster_network",
"resourceId": "VmClusterNetwork-unique_ID",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.id..oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-08-29T12:00:00.000Z",
"timeUpdated": "2019-08-29T12:30:00.000Z",
"lifecycleDetails": "detail message",
"exadataInfrastructureId": "ExadataInfra-unique_ID",
"displayName": "testDisplayName"
}
}
}

This is a reference event for VM Cluster Create Begin:

{
"cloudEventsVersion": "0.1",
"eventId": "60600c06-d6a7-4e85-b56a-1de3e6042f57",
"eventType": "com.oraclecloud.databaseservice.createvmcluster.begin",
"source": "databaseservice",
"eventTypeVersion": "1.0",
"eventTime": "2019-06-27T21:16:04.000Z",
"contentType": "application/json",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_ID"
},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",
"compartmentName": "example_name",
"resourceName": "my_database",
"resourceId": "Vmcluster-unique_ID",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.id..oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-09-03T12:00:00.000Z",
"timeUpdated": "2019-09-03T12:30:00.000Z",
"displayName": "testDisplayName",
"lifecycleDetails": "detail message",
"exadataInfrastructureId": "ExatraInfra-unique_ID",

21-6
 Chapter 21
Backup Destination Event Types

"vmClusterNetworkId": "VmCluster-unique_ID",
"cpuCoreCount": 2,
"dataStorageSizeInTBs": 4,
"dbVersion": "19.0.0.0",
"licenseType": "BRING_YOUR_OWN_LICENSE",
"giVersion": "19.0.0.0",
"dbNodeIds": "[ocid1.dbnode.1, ocid1.dbnode.2,...]",
"timeZone": "US/Pacific"
}
}
}

Backup Destination Event Types

Review the list of event types that backup destinations emit.

Table 21-4 Backup Destination Event Types

Friendly Name Event Type

Change Compartment com.oraclecloud.databaseservice.chan
gebackupdestinationcompartment
Create com.oraclecloud.databaseservice.crea
tebackupdestination
Terminate com.oraclecloud.databaseservice.dele
tebackupdestination
Update com.oraclecloud.databaseservice.upda
tebackupdestination

Example 21-4 Backup Destination Example

This is a reference event for backup destinations:

{
"cloudEventsVersion": "0.1",
"eventID": "60600c06-d6a7-4e85-b56a-1de3e6042f57",
"eventType":
"com.oraclecloud.databaseservice.createbackupdestination",
"source": "databaseservice",
"eventTypeVersion": "version",
"eventTime": "2019-08-29T21:16:04Z",
"contentType": "application/json",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_ID"
},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",
"compartmentName": "example_name",
"resourceName": "my_backupdestination",
"resourceId": "BackupDestination-unique_ID",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {}

21-7
 Chapter 21
Database Node Event Types (Cloud@Customer)

}
}

Database Node Event Types (Cloud@Customer)

Review the list of event types that database nodes emit.

Table 21-5 Database Node Event Types

Friendly Name Event Type

Update Begin com.oraclecloud.databaseservice.dbno
deaction.begin
Update End com.oraclecloud.databaseservice.dbno
deaction.end

Example 21-5 Database Node Example

This is a reference event for database nodes:

{
"cloudEventsVersion": "0.1",
"eventID": "60600c06-d6a7-4e85-b56a-1de3e6042f57",
"eventType": "com.oraclecloud.databaseservice.dbnodeaction.begin",
"source": "databaseservice",
"eventTypeVersion": "version",
"eventTime": "2019-06-27T21:16:04Z",
"contentType": "application/json",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_ID"
},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",
"compartmentName": "example_name",
"resourceName": "my_dbnode",
"resourceId": "DbNode-unique_ID",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.id..oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-08-26T12:00:00.000Z",
"timeUpdated": "2019-08-26T12:30:00.000Z",
"dbSystemId": "ocid1.dbsystem.oc1.phx.unique_ID",
"lifecycleDetails": "detail message",
"vmClusterId": "VmCluster-unique_ID",
"dbHostId": "dbHost-unique_ID",
"nodeNumber": 2,
"powerAction": "HardReset",
"hostName": "testHostName"
}

21-8
 Chapter 21
Database Home Event Types (Cloud@Customer)

}
}

Database Home Event Types (Cloud@Customer)

Review the list of event types that Database Homes emit.

Table 21-6 Database Home Event Types

Friendly Name Event Type

Create Begin com.oraclecloud.databaseservice.crea
tedbhome.begin
Create End com.oraclecloud.databaseservice.crea
tedbhome.end
Terminate Begin com.oraclecloud.databaseservice.dele
tedbhome.begin
Terminate End com.oraclecloud.databaseservice.dele
tedbhome.end
Update Begin com.oraclecloud.databaseservice.upda
tedbhome.begin
Update End com.oraclecloud.databaseservice.upda
tedbhome.end

Example 21-6 Database Home Example

This is a reference event for Database Homes:

{
"cloudEventsVersion": "0.1",
"eventID": "60600c06-d6a7-4e85-b56a-1de3e6042f57",
"eventType": "com.oraclecloud.databaseservice.createdbhome.begin",
"source": "databaseservice",
"eventTypeVersion": "version",
"eventTime": "2019-08-29T21:16:04Z",
"contentType": "application/json",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_ID"
},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",
"compartmentName": "example_name",
"resourceName": "my_dbhome",
"resourceId": "DbHome-unique_ID",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.id..oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-08-29T12:00:00.000Z",
"timeUpdated": "2019-08-29T12:30:00.000Z",

21-9
 Chapter 21
Database Event Types (Cloud@Customer)

"lifecycleDetails": "detail message",

"dbSystemId": "DbSystem-unique_ID",
"dbVersion": "19.0.0.0",
"recordVersion": 4,
"displayName": "testDisplayName"
}
}
}

Database Event Types (Cloud@Customer)

Review the list of event types that databases emit.

Table 21-7 Database Event Types

Friendly Name Event Type

Create Begin com.oraclecloud.databaseservice.crea
tedatabase.begin
Create End com.oraclecloud.databaseservice.crea
tedatabase.end
Delete Backup Begin com.oraclecloud.databaseservice.dele
tebackup.begin
Delete Backup End com.oraclecloud.databaseservice.dele
tebackup.end
Restore Begin com.oraclecloud.databaseservice.rest
oredatabase.begin
Restore End com.oraclecloud.databaseservice.rest
oredatabase.end
Terminate Begin com.oraclecloud.databaseservice.dele
tedatabase.begin
Terminate End com.oraclecloud.databaseservice.dele
tedatabase.end
Update Begin com.oraclecloud.databaseservice.upda
tedatabase.begin
Update End com.oraclecloud.databaseservice.upda
tedatabase.end

Example 21-7 Database Example

This is a reference event for databases:

{
"cloudEventsVersion": "0.1",
"eventID": "60600c06-d6a7-4e85-b56a-1de3e6042f57",
"eventType": "com.oraclecloud.databaseservice.restoredatabase.begin",
"source": "databaseservice",
"eventTypeVersion": "version",
"eventTime": "2019-06-27T21:16:04Z",
"contentType": "application/json",
"extensions": {

21-10
 Chapter 21
Database and Grid Infrastructure Patching Event Types

"compartmentId": "ocid1.compartment.oc1..unique_ID"
},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",
"compartmentName": "example_name",
"resourceName": "my_database",
"resourceId": "Database-unique_ID",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.id..oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-08-26T12:00:00.000Z",
"timeUpdated": "2019-08-26T12:30:00.000Z",
"dbSystemId": "dbSystem-unique_ID",
"displayName": "testDisplayName",
"lifecycleDetails": "detail message",
"vmClusterId": "VmCluster-unique_ID",
"backupType": "FULL",
"dbHomeId": "dbHome-unique_ID",
"dbVersion": "19.0.0.0",
"databaseEdition": "ENTERPRISE_EDITION_EXTREME",
"autoBackupsEnabled": "true",
"recoveryWindow": 30,
"backupDestinationId": "backupDestination-unique_ID",
"backupDestinationType": "OBJECT_STORAGE",
"backupDestinationName": "my_backup_destination_name",
"exadataInfrastructureId": "ExadataInfrastructure-unique_ID",
"dbUniqueName": "akv_tgh_unqna"
}
}
}

Database and Grid Infrastructure Patching Event Types

Review the list of event types that Database and Grid Infrastructure Patching emit.

Table 21-8 Database and Grid Infrastructure Patching Events

Friendly Name Event Type

VM Cluster - Patch Begin com.oraclecloud.databaseservice.patc
hvmcluster.begin
VM Cluster - Patch End com.oraclecloud.databaseservice.patc
hvmcluster.end
DB Home - Patch Begin com.oraclecloud.databaseservice.patc
hdbhome.begin
DB Home - Patch End com.oraclecloud.databaseservice.patc
hdbhome.end
Database - Move Begin com.oraclecloud.databaseservice.move
database.end

21-11
 Chapter 21
Database and Grid Infrastructure Patching Event Types

Table 21-8 (Cont.) Database and Grid Infrastructure Patching Events

Friendly Name Event Type

Database - Move End com.oraclecloud.databaseservice.move
database.end

Example 21-8 Database Example

This is a reference event for VM Cluster - Patch Begin:

{
"cloudEventsVersion": "0.1",
"eventId": "60600c06-d6a7-4e85-b56a-1de3e6042f57",
"eventType": "com.oraclecloud.databaseservice.patchvmcluster.begin",
"source": "databaseservice",
"eventTypeVersion": "1.0",
"eventTime": "2019-06-27T21:16:04.000Z",
"contentType": "application/json",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_ID"
},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",
"compartmentName": "example_name",
"resourceName": "my_database",
"resourceId": "Vmcluster-unique_ID",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.id..oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-09-03T12:00:00.000Z",
"timeUpdated": "2019-09-03T12:30:00.000Z",
"displayName": "testDisplayName",
"lifecycleDetails": "detail message",
"exadataInfrastructureId": "ExatraInfra-unique_ID",
"vmClusterNetworkId": "VmCluster-unique_ID",
"cpuCoreCount": 2,
"dataStorageSizeInTBs": 4,
"dbVersion": "19.0.0.0",
"licenseType": "BRING_YOUR_OWN_LICENSE",
"giVersion": "19.0.0.0",
"dbNodeIds": "[ocid1.dbnode.1, ocid1.dbnode.2,...]",
"timeZone": "US/Pacific"
}
}
}

21-12
 Chapter 21
Database and Grid Infrastructure Patching Event Types

This is a reference event for DB Home - Patch Begin:

{
"cloudEventsVersion": "0.1",
"eventId": "60600c06-d6a7-4e85-b56a-1de3e6042f57",
"eventType": "com.oraclecloud.databaseservice.patchdbhome.begin",
"source": "databaseservice",
"eventTypeVersion": "1.0",
"eventTime": "2019-08-29T21:16:04.000Z",
"contentType": "application/json",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_ID"
},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",
"compartmentName": "example_name",
"resourceName": "my_dbhome",
"resourceId": "DbHome-unique_ID",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.id..oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-08-29T12:00:00.000Z",
"timeUpdated": "2019-08-29T12:30:00.000Z",
"lifecycleDetails": "detail message",
"dbSystemId": "DbSystem-unique_ID",
"dbVersion": "19.0.0.0",
"recordVersion": 4,
"displayName": "testDisplayName"
}
}
}

This is a reference event for Database - Move Begin:

{
"cloudEventsVersion": "0.1",
"eventId": "60600c06-d6a7-4e85-b56a-1de3e6042f57",
"eventType": "com.oraclecloud.databaseservice.movedatabase.begin",
"source": "databaseservice",
"eventTypeVersion": "1.0",
"eventTime": "2019-06-27T21:16:04.000Z",
"contentType": "application/json",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_ID"
},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",
"compartmentName": "example_name",
"resourceName": "my_database",
"resourceId": "Database-unique_ID",
"availabilityDomain": "all",

21-13
 Chapter 21
Autonomous VM Cluster Event Types

"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.id..oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-08-26T12:00:00.000Z",
"timeUpdated": "2019-08-26T12:30:00.000Z",
"dbSystemId": "ocid1.dbsystem.oc1.phx.unique_ID",
"displayName": "testDisplayName",
"lifecycleDetails": "detail message",
"vmClusterId": "VmCluster-unique_ID",
"dbSystemId": "dbSystem-unique_ID",
"backupType": "FULL",
"dbHomeId": "dbHome-unique_ID",
"dbVersion": "19.0.0.0",
"databaseEdition": "ENTERPRISE_EDITION_EXTREME",
"autoBackupsEnabled": "true",
"recoveryWindow": 30,
"backupDestinationId": "backupDestination-unique_ID",
"backupDestinationType": "OBJECT_STORAGE",
"backupDestinationName": "my_backup_destination_name",
"exadataInfrastructureId": "ExadataInfrastructure-unique-ID",
"dbUniqueName": "akv_tgh_unqna"
}
}
}

Autonomous VM Cluster Event Types

Review the list of event types that Autonomous VM clusters emit.

Table 21-9 Autonomous VM Cluster Events

Friendly Name Event Type

Autonomous VM Cluster - Change com.oraclecloud.databaseservice.chan
Compartment geautonomousvmclustercompartment
Autonomous VM Cluster - Create Begin com.oraclecloud.databaseservice.crea
teautonomousvmcluster.begin
Autonomous VM Cluster - Create End com.oraclecloud.databaseservice.crea
teautonomousvmcluster.end
Autonomous VM Cluster - Terminate com.oraclecloud.databaseservice.dele
Begin teautonomousvmcluster.begin
Autonomous VM Cluster - Terminate com.oraclecloud.databaseservice.dele
End teautonomousvmcluster.end
Autonomous VM Cluster - Update Begin com.oraclecloud.databaseservice.upda
teautonomousvmcluster.begin
Autonomous VM Cluster - Update End com.oraclecloud.databaseservice.upda
teautonomousvmcluster.end

21-14
 Chapter 21
Autonomous VM Cluster Event Types

Example 21-9 Autonomous VM Cluster Examples

This is a reference event for Autonomous VM Cluster - Change Compartment:

{
"cloudEventsVersion": "0.1",
"eventID": "60600c06-d6a7-4e85-b56a-1de3e6042f57",
"eventType":
"com.oraclecloud.databaseservice.changeautonomousvmclustercompartment",
"source": "databaseservice",
"eventTypeVersion": "1.0",
"eventTime": "2019-06-27T21:16:04Z",
"contentType": "application/json",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_ID"
},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",
"compartmentName": "example_name",
"resourceName": "my_database",
"resourceId": "AutonomousVmCluster-unique_ID",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.id..oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-09-03T12:00:00.000Z",
"timeUpdated": "2019-09-03T12:30:00.000Z",
"displayName": "testDisplayName",
"lifecycleDetails": "detail message",
"exadataInfrastructureId": "ExatraInfra-unique_ID",
"vmClusterNetworkId": "VmClusterNetwork-unique_ID",
"cpuCoreCount": "2",
"availableCpus": "1",
"dataStorageSizeInTBs": "4",
"availableDataStorageSizeInTBs": "1",
"licenseType": "BRING_YOUR_OWN_LICENSE",
"timeZone": "US/Pacific"
}
}
}

This is a reference event for Autonomous VM Cluster - Create Begin

{
"cloudEventsVersion": "0.1",
"eventID": "60600c06-d6a7-4e85-b56a-1de3e6042f57",
"eventType":
"com.oraclecloud.databaseservice.createautonomousvmcluster.begin",
"source": "databaseservice",
"eventTypeVersion": "1.0",
"eventTime": "2019-06-27T21:16:04Z",
"contentType": "application/json",
"extensions": {

21-15
 Chapter 21
Autonomous VM Cluster Event Types

"compartmentId": "ocid1.compartment.oc1..unique_ID"
},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",
"compartmentName": "example_name",
"resourceName": "my_database",
"resourceId": "AutonomousVmCluster-unique_ID",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.id..oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-09-03T12:00:00.000Z",
"timeUpdated": "2019-09-03T12:30:00.000Z",
"displayName": "testDisplayName",
"lifecycleDetails": "detail message",
"exadataInfrastructureId": "ExatraInfra-unique_ID",
"vmClusterNetworkId": "VmClusterNetwork-unique_ID",
"cpuCoreCount": "2",
"availableCpus": "1",
"dataStorageSizeInTBs": "4",
"availableDataStorageSizeInTBs": "1",
"licenseType": "BRING_YOUR_OWN_LICENSE",
"timeZone": "US/Pacific"
}
}
}

This is a reference event for Autonomous VM Cluster - Terminate Begin

{
"cloudEventsVersion": "0.1",
"eventID": "60600c06-d6a7-4e85-b56a-1de3e6042f57",
"eventType":
"com.oraclecloud.databaseservice.deleteautonomousvmcluster.begin",
"source": "databaseservice",
"eventTypeVersion": "1.0",
"eventTime": "2019-06-27T21:16:04Z",
"contentType": "application/json",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_ID"
},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",
"compartmentName": "example_name",
"resourceName": "my_database",
"resourceId": "AutonomousVmCluster-unique_ID",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.id..oc1...unique_ID",
"lifecycleState": "AVAILABLE",

21-16
 Chapter 21
Autonomous VM Cluster Event Types

"timeCreated": "2019-09-03T12:00:00.000Z",
"timeUpdated": "2019-09-03T12:30:00.000Z",
"displayName": "testDisplayName",
"lifecycleDetails": "detail message",
"exadataInfrastructureId": "ExatraInfra-unique_ID",
"vmClusterNetworkId": "VmClusterNetwork-unique_ID",
"cpuCoreCount": "2",
"availableCpus": "1",
"dataStorageSizeInTBs": "4",
"availableDataStorageSizeInTBs": "1",
"licenseType": "BRING_YOUR_OWN_LICENSE",
"timeZone": "US/Pacific"
}
}
}

This is a reference event for Autonomous VM Cluster - Update Begin

{
"cloudEventsVersion": "0.1",
"eventID": "60600c06-d6a7-4e85-b56a-1de3e6042f57",
"eventType":
"com.oraclecloud.databaseservice.updateautonomousvmcluster.begin",
"source": "databaseservice",
"eventTypeVersion": "1.0",
"eventTime": "2019-06-27T21:16:04Z",
"contentType": "application/json",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_ID"
},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",
"compartmentName": "example_name",
"resourceName": "my_database",
"resourceId": "AutonomousVmCluster-unique_ID",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.id..oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-09-03T12:00:00.000Z",
"timeUpdated": "2019-09-03T12:30:00.000Z",
"displayName": "testDisplayName",
"lifecycleDetails": "detail message",
"exadataInfrastructureId": "ExatraInfra-unique_ID",
"vmClusterNetworkId": "VmClusterNetwork-unique_ID",
"cpuCoreCount": "2",
"availableCpus": "1",
"dataStorageSizeInTBs": "4",
"availableDataStorageSizeInTBs": "1",
"licenseType": "BRING_YOUR_OWN_LICENSE",
"timeZone": "US/Pacific"
}

21-17
 Chapter 21
Autonomous Container Database Event Types

}
}

Autonomous Container Database Event Types

Review the list of event types that Autonomous Container Database emit.

Table 21-10 Autonomous Container Database Events

Friendly Name Event Type

Change Compartment com.oraclecloud.databaseservice.chan
geautonomouscontainerdatabasecompart
ment
Create Backup Begin com.oraclecloud.databaseservice.auto
nomous.container.database.backup.beg
in
Create Backup End com.oraclecloud.databaseservice.auto
nomous.container.database.backup.end
Create Begin com.oraclecloud.databaseservice.auto
nomous.container.database.instance.c
reate.begin
Create End com.oraclecloud.databaseservice.auto
nomous.container.database.instance.c
reate.end
Maintenance Begin com.oraclecloud.databaseservice.auto
nomous.container.database.maintenanc
e.begin
Maintenance End com.oraclecloud.databaseservice.auto
nomous.container.database.maintenanc
e.end
Maintenance Reminder com.oraclecloud.databaseservice.auto
nomous.container.database.maintenanc
e.reminder
Maintenance Scheduled com.oraclecloud.databaseservice.auto
nomous.container.database.maintenanc
e.scheduled
Restart Begin com.oraclecloud.databaseservice.rest
artautonomouscontainerdatabase.begin
Restart End com.oraclecloud.databaseservice.rest
artautonomouscontainerdatabase.end
Restore Begin com.oraclecloud.databaseservice.auto
nomous.container.database.restore.be
gin
Restore End com.oraclecloud.databaseservice.auto
nomous.container.database.restore.en
d
Terminate Begin com.oraclecloud.databaseservice.term
inateautonomouscontainerdatabase.beg
in

21-18
 Chapter 21
Autonomous Database Event Types

Table 21-10 (Cont.) Autonomous Container Database Events

Friendly Name Event Type

Terminate End com.oraclecloud.databaseservice.term
inateautonomouscontainerdatabase.end
Update Begin com.oraclecloud.databaseservice.auto
nomous.container.database.instance.u
pdate.begin
Update End com.oraclecloud.databaseservice.auto
nomous.container.database.instance.u
pdate.begin

Example 21-10 Autonomous Container Database Examples

This is a reference event for create Autonomous Container Database:

{lifecycleState=AVAILABLE,
autonomousVmClusterId=ocid1.autonomousvmcluster.oc1.sea.abzwkljrevsjcfus
kw7mgi6ulzfg2epjjxhbnhwj63q7q3kzvuwg3djqnd2a,
displayName=CDB2-NFS,
dbName=wqxtzzfn,
dbUniqueName=wqxtzzfn_sea1td,
freeTags={},
autonomousContainerDatabaseId=ocid1.autonomouscontainerdatabase.oc1.sea.
abzwkljrxkuruqe3qzgw432adr5ug7ridmwi4ifvjlsahcdqdhbhzbf543xa,
compartmentId=ocid1.compartment.region1..aaaaaaaass5x4witduxzgrs7qmzqk3m
5kmoguve7urwploqef6763w3o42ta,
timeUpdated=2020-06-15 21:52:24.085,
tenantId=ocid1.tenancy.region1..aaaaaaaagyw5okosjg54csr3u5qgaxvtjufz5553
7h44mjy2umiqur4z5w3a,
timeCreated=2020-06-15 19:08:03.797,
id=ocid1.autonomouscontainerdatabase.oc1.sea.abzwkljrxkuruqe3qzgw432adr5
ug7ridmwi4ifvjlsahcdqdhbhzbf543xa,
definedTags={}}

Autonomous Database Event Types

Review the list of event types that Autonomous Database emit.

Table 21-11 Autonomous Database Events

Friendly Name Event Type

Change Compartment Begin com.oraclecloud.databaseservice.chan
geautonomousdatabasecompartment.begi
n
Change Compartment End com.oraclecloud.databaseservice.chan
geautonomousdatabasecompartment.end
Create Backup Begin com.oraclecloud.databaseservice.auto
nomous.database.backup.begin

21-19
 Chapter 21
Data Guard Event Types

Table 21-11 (Cont.) Autonomous Database Events

Friendly Name Event Type

Create Backup End com.oraclecloud.databaseservice.auto
nomous.database.backup.end
Create Begin com.oraclecloud.databaseservice.auto
nomous.database.instance.create.begi
n
Create End com.oraclecloud.databaseservice.auto
nomous.database.instance.create.end
Restore Begin com.oraclecloud.databaseservice.auto
nomous.database.restore.begin
Restore End com.oraclecloud.databaseservice.auto
nomous.database.restore.end
Start Begin com.oraclecloud.databaseservice.star
tautonomousdatabase.begin
Start End com.oraclecloud.databaseservice.star
tautonomousdatabase.end
Stop Begin com.oraclecloud.databaseservice.stop
autonomousdatabase.begin
Stop End com.oraclecloud.databaseservice.stop
autonomousdatabase.end
Terminate Begin com.oraclecloud.databaseservice.dele
teautonomousdatabase.begin
Terminate End com.oraclecloud.databaseservice.dele
teautonomousdatabase.end
Update Begin com.oraclecloud.databaseservice.upda
teautonomousdatabase.begin
Update End com.oraclecloud.databaseservice.upda
teautonomousdatabase.end

Data Guard Event Types

Review the list of event types that Data Guard associations emit.

Table 21-12 Data Guard Association Events

Friendly Name Event Type

Data Guard Association - Create com.oraclecloud.databaseservice.crea
Begin tedataguardassociation.begin
Data Guard Association - Create End com.oraclecloud.databaseservice.crea
tedataguardassociation.end
Switchover Begin com.oraclecloud.databaseservice.swit
choverdataguardassociation.begin
Switchover End com.oraclecloud.databaseservice.swit
choverdataguardassociation.end

21-20
 Chapter 21
Data Guard Event Types

Table 21-12 (Cont.) Data Guard Association Events

Friendly Name Event Type

Failover Begin com.oraclecloud.databaseservice.fail
overdataguardassociation.begin
Failover End com.oraclecloud.databaseservice.fail
overdataguardassociation.end
Reinstate Begin com.oraclecloud.databaseservice.rein
statedataguardassociation.begin
Reinstate End com.oraclecloud.databaseservice.rein
statedataguardassociation.end

Example 21-11 Data Guard Associations Examples

This is a reference event for Data Guard Association - Create Begin:

{
"eventId": "022a63a4-ff77-11e9-a0af-f45c89b1cb17",
"eventTime": "2019-11-05T02:50:21.000Z",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_id"
},
"eventType":
"com.oraclecloud.databaseservice.createdataguardassociation.begin",
"eventTypeVersion": "2.0",
"cloudEventsVersion": "0.1",
"source": "databaseservice",
"contentType": "application/json",
"definedTags": {},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_id",
"compartmentName": "example_name",
"resourceName": "my_container_database",
"resourceId": "ocid1.dataguard.oc1.phx.unique_id",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.dataguard.oc1.phx.unique_id",
"timeCreated": "2019-06-27T21:15:59.000Z",
"timeUpdated": "2019-06-27T21:16:04.389Z",
"lifecycleState": "ACTIVE",
"lifecycleMessage": "",
"dbSystemId": "ocid1.vmcluster.oc1.phx.unique_id",
"DatabaseId": "ocid1.database.oc1.phx.unique_id",
"DbHomeId": "ocid1.dbhome.oc1.phx.unique_id",
"DGConfigId": "022a67c8-ff77-11e9-af6e-f45c89b1cb17",
"DGConfigState": "SUCCESS",
"LastSyncedTime": "2019-06-27T21:16:04.389Z",
"ApplyLag": "2 hours",
"SyncState": "SYNCED",
"dcsDgUpdateTimestamp": "2019-06-27T21:16:04.389Z",

21-21
 Chapter 21
Data Guard Event Types

"lastUpdatedIdentifier": "022a6912-ff77-11e9-9e77-f45c89b1cb17",
"displayName": "Data Guard Association - Create Begin",
"licenseType": "BRING_YOUR_OWN_LICENSE",
"workloadType": "Transaction Processing"
}
}
}

This is a reference event for Data Guard Association - Create End:

{
"eventId": "022aa7cc-ff77-11e9-90cd-f45c89b1cb17",
"eventTime": "2019-11-05T02:50:21.000Z",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_id"
},
"eventType":
"com.oraclecloud.databaseservice.createdataguardassociation.end",
"eventTypeVersion": "2.0",
"cloudEventsVersion": "0.1",
"source": "databaseservice",
"contentType": "application/json",
"definedTags": {},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_id",
"compartmentName": "example_name",
"resourceName": "my_container_database",
"resourceId": "ocid1.dataguard.oc1.phx.unique_id",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.dataguard.oc1.phx.unique_id",
"timeCreated": "2019-06-27T21:15:59.000Z",
"timeUpdated": "2019-06-27T21:16:04.389Z",
"lifecycleState": "ACTIVE",
"lifecycleMessage": "",
"dbSystemId": "ocid1.vmcluster.oc1.phx.unique_id",
"DatabaseId": "ocid1.database.oc1.phx.unique_id",
"DbHomeId": "ocid1.dbhome.oc1.phx.unique_id",
"DGConfigId": "022aab34-ff77-11e9-b89c-f45c89b1cb17",
"DGConfigState": "SUCCESS",
"LastSyncedTime": "2019-06-27T21:16:04.389Z",
"ApplyLag": "2 hours",
"SyncState": "SYNCED",
"dcsDgUpdateTimestamp": "2019-06-27T21:16:04.389Z",
"lastUpdatedIdentifier": "022aac10-ff77-11e9-8041-f45c89b1cb17",
"displayName": "Data Guard Association - Create End",
"licenseType": "BRING_YOUR_OWN_LICENSE",
"workloadType": "Transaction Processing"
}
}
}

21-22
 Chapter 21
Autonomous Database Autonomous Data Guard Event Types

Autonomous Database Autonomous Data Guard Event

Types
Review the list of event types that Autnomous Data Guard associations emit.

Table 21-13 Autonomous Data Guard Association Events

Friendly Name Event Type

Autonomous Container Database - com.oraclecloud.DatabaseService.Crea
Create Autonomous Data Guard Begin teAutonomousDataGuardAssociation.beg
in
Autonomous Container Database - com.oraclecloud.DatabaseService.Crea
Create Autonomous Data Guard End teAutonomousDataGuardAssociation.end
Autonomous Container Database - com.oraclecloud.DatabaseService.Swit
Switchover Begin choverAutonomousDataguardAssociation
.begin
Autonomous Container Database - com.oraclecloud.DatabaseService.Swit
Switchover End choverAutonomousDataguardAssociation
.end
Autonomous Container Database - com.oraclecloud.DatabaseService.Fail
Failover Begin overAutonomousDataguardAssociation.b
egin
Autonomous Container Database - com.oraclecloud.DatabaseService.Fail
Failover End overAutonomousDataguardAssociation.e
nd
Autonomous Container Database - com.oraclecloud.DatabaseService.Rein
Reinstate Begin stateAutonomousDataGuardAssociation.
begin
Autonomous Container Database - com.oraclecloud.DatabaseService.Rein
Reinstate End stateAutonomousDataGuardAssociation.
end

Example 21-12 Autonomous Data Guard Associations Examples

This is a reference event for Autonomous Container Database - Create Autonomous
Data Guard Begin:

{
"cloudEventsVersion": "0.1",
"eventID": "<unique_ID>",
"eventType":
"com.oraclecloud.DatabaseService.CreateAutonomousDataGuardAssociation.be
gin",
"source": "databaseservice",
"eventTypeVersion": "2.0",
"eventTime": "2019-06-27T21:16:04Z",
"contentType": "application/json",
"data": {
"eventGroupingId": "<unique_ID>",

21-23
 Chapter 21
Autonomous Database Autonomous Data Guard Event Types

"eventName"="CreateAutonomousDataGuardAssociation"
"compartmentId": "ocid1.compartment.oc1..<unique_ID>",
"compartmentName": "example_name",
"resourceVersion":null,
"resourceName": "my_container_database",
"resourceId": "<unique_ID>",
"availabilityDomain": "all",
"tagSlug": "<slug_ID>",
"definedTags": {},
"additionalDetails": {
"lifecycleState": "PROVISIONING",
"DGConfigId"="91f298da-b890-42ce-935b-9b841e908756",
"ApplyLag"=null,
"LastRoleChangeTime"=null,
"TransportLag"=null,

"autonomousContainerDatabaseId"="ocid1.autonomouscontainerdatabase.oc1.s
ea.<unique_ID>",
"DGConfigState"=null,
"lifeCycleMessage"=null,
"lastUpdatedIdentifier"=null,
"SyncState"=null,

"autonomousExadataInfrastructureId"="ocid1.autonomousvmcluster.oc1.sea.<
unique_ID>",
"timeUpdated"="2020-10-18 23:02:34.864",
"timeCreated"="2020-10-18 23:02:34.864",
"dbHomeId"="ocid1.autonomouspodhome.oc1.sea.<unique_ID>",
"LastSyncedTime"=null,
"dcsDgUpdateTimestamp"=null,
}
}
}

This is a reference event for Autonomous Container Database - Switchover Begin:

{
"cloudEventsVersion": "0.1",
"eventID": "<unique_ID>",
"eventType":
"com.oraclecloud.DatabaseService.CreateAutonomousDataGuardAssociation.be
gin",
"source": "databaseservice",
"eventTypeVersion": "2.0",
"eventTime": "2019-06-27T21:16:04Z",
"contentType": "application/json",
"data": {
"eventGroupingId": "<unique_ID>",
"eventName"="SwitchoverAutonomousDataguardAssociation"
"compartmentId": "ocid1.compartment.oc1..<unique_ID>",
"compartmentName": "example_name",
"resourceVersion":null,
"resourceName": "my_container_database",
"resourceId": "ocid1.autonomousdgassociation.oc1.sea.<unique_ID>",

21-24
 Chapter 21
Autonomous Database Autonomous Data Guard Event Types

"availabilityDomain": "all",
"tagSlug": "<slug_ID>",
"definedTags": {},
"stateChange": {
"previous"=null,
"current: {
"lifecycleState"="ROLE_CHANGE_IN_PROGRESS
}
}
"additionalDetails": {
"lifecycleState": "ROLE_CHANGE_IN_PROGRESS",
"DGConfigId"="<unique_ID>",
"ApplyLag"="0 seconds computed 2 seconds ago",
"LastRoleChangeTime"=null,
"TransportLag"="0 seconds computed 2 seconds ago",

"autonomousContainerDatabaseId"="ocid1.autonomouscontainerdatabase.oc1.s
ea.<unique_ID>",
"DGConfigState"="SUCCESS",
"lifeCycleMessage"=null,
"lastUpdatedIdentifier"=null,
"SyncState"="SYNCED",

"autonomousExadataInfrastructureId"="ocid1.autonomousvmcluster.oc1.sea.<
unique_ID>",
"timeUpdated"="2020-10-18 23:02:34.864",
"timeCreated"="2020-10-18 23:02:34.864",
"dbHomeId"="ocid1.autonomouspodhome.oc1.sea.<unique_ID>",
"LastSyncedTime"=null,
"dcsDgUpdateTimestamp"=null,
}
}
}

This is a reference event for Autonomous Container Database - Failover Begin:

{
"cloudEventsVersion": "0.1",
"eventID": "<unique_ID>",
"eventType":
"com.oraclecloud.DatabaseService.CreateAutonomousDataGuardAssociation.be
gin",
"source": "databaseservice",
"eventTypeVersion": "2.0",
"eventTime": "2019-06-27T21:16:04Z",
"contentType": "application/json",
"data": {
"eventGroupingId": "<unique_ID>",
"eventName"="FailoverAutonomousDataguardAssociation"
"compartmentId": "ocid1.compartment.oc1..<unique_ID>",
"compartmentName": "example_name",
"resourceVersion":null,
"resourceName": "my_container_database",
"resourceId": "ocid1.autonomousdgassociation.oc1.sea.<unique_ID>",

21-25
 Chapter 21
Autonomous Database Autonomous Data Guard Event Types

"availabilityDomain": "all",
"tagSlug": "<slug_ID>",
"definedTags": {},
"stateChange": {
"previous"=null,
"current: {
"lifecycleState"="ROLE_CHANGE_IN_PROGRESS
}
}
"additionalDetails": {
"lifecycleState": "ROLE_CHANGE_IN_PROGRESS",
"DGConfigId"="<unique_ID>",
"ApplyLag"="0 seconds computed 2 seconds ago",
"LastRoleChangeTime"=null,
"TransportLag"="0 seconds computed 2 seconds ago",

"autonomousContainerDatabaseId"="ocid1.autonomouscontainerdatabase.oc1.s
ea.<unique_ID>",
"DGConfigState"="SUCCESS",
"lifeCycleMessage"=null,
"lastUpdatedIdentifier"=null,
"SyncState"="SYNCED",

"autonomousExadataInfrastructureId"="ocid1.autonomousvmcluster.oc1.sea.<
unique_ID>",
"timeUpdated"="2020-10-18 23:02:34.864",
"timeCreated"="2020-10-18 23:02:34.864",
"dbHomeId"="ocid1.autonomouspodhome.oc1.sea.<unique_ID>",
"LastSyncedTime"=null,
"dcsDgUpdateTimestamp"=null,
}
}
}

This is a reference event for Autonomous Container Database - Reinstate Begin:

{
"cloudEventsVersion": "0.1",
"eventID": "<unique_ID>",
"eventType":
"com.oraclecloud.DatabaseService.CreateAutonomousDataGuardAssociation.be
gin",
"source": "databaseservice",
"eventTypeVersion": "2.0",
"eventTime": "2019-06-27T21:16:04Z",
"contentType": "application/json",
"data": {
"eventGroupingId": "<unique_ID>",
"eventName"="ReinstateAutonomousDataGuardAssociation"
"compartmentId": "ocid1.compartment.oc1..<unique_ID>",
"compartmentName": "example_name",
"resourceVersion":null,
"resourceName": "my_container_database",
"resourceId": "ocid1.autonomousdgassociation.oc1.sea.<unique_ID>",

21-26
 Chapter 21
Key Store Event Types

"availabilityDomain": "all",
"tagSlug": "<slug_ID>",
"definedTags": {},
"stateChange": {
"previous"=null,
"current: {
"lifecycleState"="ROLE_CHANGE_IN_PROGRESS
}
}
"additionalDetails": {
"lifecycleState": "ROLE_CHANGE_IN_PROGRESS",
"DGConfigId"="<unique_ID>",
"ApplyLag"="0 seconds computed 2 seconds ago",
"LastRoleChangeTime"=null,
"TransportLag"="0 seconds computed 2 seconds ago",

"autonomousContainerDatabaseId"="ocid1.autonomouscontainerdatabase.oc1.s
ea.<unique_ID>",
"DGConfigState"="SUCCESS",
"lifeCycleMessage"=null,
"lastUpdatedIdentifier"=null,
"SyncState"="SYNCED",

"autonomousExadataInfrastructureId"="ocid1.autonomousvmcluster.oc1.sea.<
unique_ID>",
"timeUpdated"="2020-10-18 23:02:34.864",
"timeCreated"="2020-10-18 23:02:34.864",
"dbHomeId"="ocid1.autonomouspodhome.oc1.sea.<unique_ID>",
"LastSyncedTime"=null,
"dcsDgUpdateTimestamp"=null,
}
}
}

Key Store Event Types

Review the list of event types that Key Store emits.

Table 21-14 Key Store Events

Friendly Name Event Type

Key Store - Create com.oraclecloud.databaseservice.crea
tekeystore
Key Store - Update com.oraclecloud.databaseservice.upda
tekeystore
Key Store - Terminate com.oraclecloud.databaseservice.dele
tekeystore
Key Store - Change Compartment com.oraclecloud.databaseservice.chan
gekeystorecompartment

21-27
 Chapter 21
Exadata Cloud@Customer Infrastructure Patching Event Types

Table 21-14 (Cont.) Key Store Events

Friendly Name Event Type

Autonomous Container Database - com.oraclecloud.databaseservice.rota
Rotate Key Begin tekeyautonomouscontainerdatabase.beg
in
Autonomous Container Database - com.oraclecloud.databaseservice.rota
Rotate Key End tekeyautonomouscontainerdatabase.end
Autonomous Database - Rotate Key com.oraclecloud.databaseservice.rota
Begin tekeyautonomousdatabase.begin
Autonomous Database - Rotate Key End com.oraclecloud.databaseservice.rota
tekeyautonomousdatabase.end

Example 21-13 Key Store Example

This is a reference event for Create Key Store:

{
"cloudEventsVersion": "0.1",
"eventID": "60600c06-d6a7-4e85-b56a-1de3e6042f57",
"eventType": "com.oraclecloud.databaseservice.createkeystore",
"source": "databaseservice",
"eventTypeVersion": "version",
"eventTime": "2020-10-27T21:16:04Z",
"contentType": "application/json",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_ID"
},
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",
"compartmentName": "example_name",
"resourceName": "my_keystore",
"resourceId": "KeyStore-unique_ID",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"timeUpdated"="2020-10-27 21:16:34.864",
"timeCreated"="2020-10-27 21:16:34.864",
"keyStoreType": "all",
"connectionIps": "ip1,ip2",
"adminUsername": "username",
}
}
}

Exadata Cloud@Customer Infrastructure Patching Event

Types
Review the list of event types that Exadata Cloud@Customer Infrastructure patching
emits.

21-28
 Chapter 21
Exadata Cloud@Customer Infrastructure Patching Event Types

Table 21-15 Exadata Cloud@Customer Infrastructure Patching Events

Friendly Name Event Type Event Message

Exadata Infrastructure com.oraclecloud.databas This is an Oracle Cloud
- Virtual Machines eservice.exaccinfrastru Operations notice regarding
Maintenance Begin cturemaintenancevm.begi the quarterly maintenance
n update of Virtual Machines
component of your ExaCC
Infrastructure instance %s,
ocid %s has started. A follow-
up notice will be sent when
Virtual Machines maintenance
operation has completed.
Exadata Infrastructure com.oraclecloud.databas This is an Oracle
- Virtual Machines eservice.exaccinfrastru Cloud Operations notice
Maintenance End cturemaintenancevm.end that quarterly maintenance
update of Virtual Machines
component of your ExaCC
Infrastructure instance %s,
ocid %s has completed.
Exadata Infrastructure com.oraclecloud.databas Oracle Cloud Operations is
- Maintenance Scheduled eservice.exaccinfrastru announcing the availability
cturemaintenanceschedul of a new quarterly
ed maintenance update for
ExaCC Infrastructure. Oracle
has scheduled the installation
of this new update on your
service instance %s, ocid %s
on %s.
Exadata Infrastructure com.oraclecloud.databas This is an Oracle Cloud
- Maintenance Reminder eservice.exaccinfrastru Operations reminder notice.
cturemaintenancereminde Oracle has scheduled
r a quarterly maintenance
update installation for ExaCC
Infrastructure instance %s,
ocid %s in approximately %d
weeks on %s.
Exadata Infrastructure com.oraclecloud.databas This is an Oracle Cloud
- Maintenance Begin eservice.exaccinfrastru Operations notice regarding
cturemaintenance.begin the quarterly maintenance
update installation for your
ExaCC Infrastructure instance
%s, ocid %s. The update
installation for the service
started at %s. A follow-up
notice will be sent when the
maintenance update operation
has completed.

21-29
 Chapter 21
Exadata Cloud@Customer Infrastructure Patching Event Types

Table 21-15 (Cont.) Exadata Cloud@Customer Infrastructure Patching Events

Friendly Name Event Type Event Message

Exadata Infrastructure com.oraclecloud.databas Success: This is an Oracle
- Maintenance End eservice.exaccinfrastru Cloud Operations notice that
cturemaintenance.end your ExaCC Infrastructure
quarterly maintenance update
installation for service instance
%s, ocid %s which started
at %s is now successfully
complete.
Failure: This is an Oracle
Cloud Operations notice that
your ExaCC Infrastructure
quarterly maintenance update
installation for service instance
%s, ocid %s which started
at %s has failed to complete
due to technical reasons and
will be rescheduled for a later
date. You will receive regular
notifications to track progress
of this maintenance.

Example 21-14 Exadata Cloud@Customer Infrastructure Maintenance Events

Examples
This is a reference event for Exadata Infrastructure - Virtual Machines Maintenance
Begin:

"exampleEvent": {
"cloudEventsVersion": "0.1",
"eventID": "b28fcda6-3d7b-4044-aa8e-7c21cde84b44",
"eventType":
"com.oraclecloud.databaseservice.exaccinfrastructuremaintenancevm.begin"
,
"source": "databaseservice",
"eventTypeVersion": "2.0",
"eventTime": "2019-06-27T21:16:04.000Z",
"contentType": "application/json",
"data": {
"eventGroupingId": "4976b940-2c2d-4380-a669-1d70d071b187",
"eventName": "ExaccInfrastructureMaintenanceVM",
"compartmentId": "ocid1.compartment.oc1.......unique_id",
"compartmentName": "example_compartment",
"resourceName": "my_exacc_infrastructure",
"resourceId": "ocid1.exadatainfrastructure.oc1.....unique_id",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.dbmaintenancerun.oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-08-29T12:00:00.000Z",
"timeScheduled": "2019-08-29T12:30:00.000Z",

21-30
 Chapter 21
Exadata Cloud@Customer Infrastructure Patching Event Types

"timeStarted": "2019-08-29T12:30:00.000Z",
"description": "ExaCC Infrastructure Maintenance
Notifications",
"message": "detailed message",
"shape": "ExadataCC.Base3.48",
"displayName": "testDisplayName"
}
}
}

This is a reference event for Exadata Infrastructure - Virtual Machines Maintenance

End:

"exampleEvent": {
"cloudEventsVersion": "0.1",
"eventID": "b28fcda6-3d7b-4044-aa8e-7c21cde84b44",
"eventType":
"com.oraclecloud.databaseservice.exaccinfrastructuremaintenancevm.end",
"source": "databaseservice",
"eventTypeVersion": "2.0",
"eventTime": "2019-06-27T21:16:04.000Z",
"contentType": "application/json",
"data": {
"eventGroupingId": "4976b940-2c2d-4380-a669-1d70d071b187",
"eventName": "ExaccInfrastructureMaintenanceVM",
"compartmentId": "ocid1.compartment.oc1.......unique_id",
"compartmentName": "example_compartment",
"resourceName": "my_exacc_infrastructure",
"resourceId": "ocid1.exadatainfrastructure.oc1.....unique_id",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.dbmaintenancerun.oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-08-29T12:00:00.000Z",
"timeScheduled": "2019-08-29T12:30:00.000Z",
"timeEnded": "2019-08-29T12:30:00.000Z",
"description": "ExaCC Infrastructure Maintenance
Notifications",
"message": "detailed message",
"shape": "ExadataCC.Base3.48",
"displayName": "testDisplayName"
}
}
}

This is a reference event for Exadata Infrastructure - Maintenance Scheduled:

"exampleEvent": {
"cloudEventsVersion": "0.1",
"eventID": "b28fcda6-3d7b-4044-aa8e-7c21cde84b44",
"eventType":
"com.oraclecloud.databaseservice.exaccinfrastructuremaintenancescheduled

21-31
 Chapter 21
Exadata Cloud@Customer Infrastructure Patching Event Types

",
"source": "databaseservice",
"eventTypeVersion": "2.0",
"eventTime": "2019-06-27T21:16:04.000Z",
"contentType": "application/json",
"data": {
"eventGroupingId": "4976b940-2c2d-4380-a669-1d70d071b187",
"eventName": "ExaccInfrastructureMaintenanceScheduled",
"compartmentId": "ocid1.compartment.oc1.......unique_id",
"compartmentName": "example_compartment",
"resourceName": "my_exacc_infrastructure",
"resourceId": "ocid1.exadatainfrastructure.oc1.....unique_id",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.dbmaintenancerun.oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-08-29T12:00:00.000Z",
"timeScheduled": "2019-08-29T12:30:00.000Z",
"description": "ExaCC Infrastructure Maintenance
Notifications",
"message": "detailed message",
"shape": "ExadataCC.Base3.48",
"displayName": "testDisplayName"
}
}
}

This is a reference event for Exadata Infrastructure - Maintenance Reminder:

"exampleEvent": {
"cloudEventsVersion": "0.1",
"eventID": "b28fcda6-3d7b-4044-aa8e-7c21cde84b44",
"eventType":
"com.oraclecloud.databaseservice.exaccinfrastructuremaintenancereminder"
,
"source": "databaseservice",
"eventTypeVersion": "2.0",
"eventTime": "2019-06-27T21:16:04.000Z",
"contentType": "application/json",
"data": {
"eventGroupingId": "4976b940-2c2d-4380-a669-1d70d071b187",
"eventName": "ExaccInfrastructureMaintenanceReminder",
"compartmentId": "ocid1.compartment.oc1.......unique_id",
"compartmentName": "example_compartment",
"resourceName": "my_exacc_infrastructure",
"resourceId": "ocid1.exadatainfrastructure.oc1.....unique_id",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.dbmaintenancerun.oc1...unique_ID",
"lifecycleState": "AVAILABLE",

21-32
 Chapter 21
Exadata Cloud@Customer Infrastructure Patching Event Types

"timeCreated": "2019-08-29T12:00:00.000Z",
"timeScheduled": "2019-08-29T12:30:00.000Z",
"description": "ExaCC Infrastructure Maintenance
Notifications",
"message": "detailed message",
"shape": "ExadataCC.Base3.48",
"displayName": "testDisplayName"
}
}
}

This is a reference event for Exadata Infrastructure - Maintenance Begin:

"exampleEvent": {
"cloudEventsVersion": "0.1",
"eventID": "b28fcda6-3d7b-4044-aa8e-7c21cde84b44",
"eventType":
"com.oraclecloud.databaseservice.exaccinfrastructuremaintenance.begin",
"source": "databaseservice",
"eventTypeVersion": "2.0",
"eventTime": "2019-06-27T21:16:04.000Z",
"contentType": "application/json",
"data": {
"eventGroupingId": "4976b940-2c2d-4380-a669-1d70d071b187",
"eventName": "ExaccInfrastructureMaintenance",
"compartmentId": "ocid1.compartment.oc1.......unique_id",
"compartmentName": "example_compartment",
"resourceName": "my_exacc_infrastructure",
"resourceId": "ocid1.exadatainfrastructure.oc1.....unique_id",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.dbmaintenancerun.oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-08-29T12:00:00.000Z",
"timeScheduled": "2019-08-29T12:30:00.000Z",
"timeStarted": "2019-08-29T12:30:00.000Z",
"description": "ExaCC Infrastructure Maintenance
Notifications",
"message": "detailed message",
"shape": "ExadataCC.Base3.48",
"displayName": "testDisplayName"
}
}
}

This is a reference event for Exadata Infrastructure - Maintenance End:

"exampleEvent": {
"cloudEventsVersion": "0.1",
"eventID": "b28fcda6-3d7b-4044-aa8e-7c21cde84b44",
"eventType":
"com.oraclecloud.databaseservice.exaccinfrastructuremaintenance.end",

21-33
 Chapter 21
Exadata Cloud@Customer Infrastructure Patching Event Types

"source": "databaseservice",
"eventTypeVersion": "2.0",
"eventTime": "2019-06-27T21:16:04.000Z",
"contentType": "application/json",
"data": {
"eventGroupingId": "4976b940-2c2d-4380-a669-1d70d071b187",
"eventName": "ExaccInfrastructureMaintenance",
"compartmentId": "ocid1.compartment.oc1.......unique_id",
"compartmentName": "example_compartment",
"resourceName": "my_exacc_infrastructure",
"resourceId": "ocid1.exadatainfrastructure.oc1.....unique_id",
"availabilityDomain": "all",
"freeFormTags": {},
"definedTags": {},
"additionalDetails": {
"id": "ocid1.dbmaintenancerun.oc1...unique_ID",
"lifecycleState": "AVAILABLE",
"timeCreated": "2019-08-29T12:00:00.000Z",
"timeScheduled": "2019-08-29T12:30:00.000Z",
"timeEnded": "2019-08-29T12:30:00.000Z",
"description": "ExaCC Infrastructure Maintenance
Notifications",
"message": "detailed message",
"shape": "ExadataCC.Base3.48",
"displayName": "testDisplayName"
}
}
}

21-34
22
Troubleshooting Exadata
Cloud@Customer Systems
These topics cover some common issues you might run into and how to address them.
• Patching Failures on Exadata Cloud@Customer Systems
You can patch Oracle Database and Oracle Grid Infrastructure using the dbaascli
utility and update the Cloud Tooling on Exadata Cloud@Customer.
• Obtaining Further Assistance
If you were unable to resolve the problem using the information in this topic, follow
the procedures below to collect relevant database and diagnostic information.
After you have collected this information, contact Oracle Support.
• Database is Down While Performing Downgrade to Release 11.2 or 12.1
• After Database Upgrade, the Standby Database Remains in Mounted State in
Oracle Data Guard Configurations
• Primary Database Fails to Downgrade to 18c in Oracle Data Guard Configurations
• Deleting a Database Does Not Delete the Associated Oracle Home

Patching Failures on Exadata Cloud@Customer Systems

You can patch Oracle Database and Oracle Grid Infrastructure using the dbaascli
utility and update the Cloud Tooling on Exadata Cloud@Customer.
Patching operations can fail for various reasons. Typically, an operation fails because
a database node is down, there is insufficient space on the file system, or the
database host cannot access the object store.
• Determining the Problem
In the Console, you can identify a failed patching operation by viewing the patch
history of an Exadata Cloud@Customer system or an individual database.
• Troubleshooting and Diagnosis
Diagnose the most common issues that can occur during the patching process of
any of the Exadata Cloud@Customer components.
• Failed Patch Modifies the Home Name in oraInventory with the Suffix "_PIP"
• Patching Primary and Standby Databases Configured with Oracle Data Guard
Fails

Determining the Problem

In the Console, you can identify a failed patching operation by viewing the patch
history of an Exadata Cloud@Customer system or an individual database.
A patch that was not successfully applied displays a status of Failed and includes
a brief description of the error that caused the failure. If the error message does not

22-1
 Chapter 22
Patching Failures on Exadata Cloud@Customer Systems

contain enough information to point you to a solution, you can use the database CLI
and log files to gather more data. Then, refer to the applicable section in this topic for a
solution.

Troubleshooting and Diagnosis

Diagnose the most common issues that can occur during the patching process of any
of the Exadata Cloud@Customer components.
• Host Issues
One or more of the following conditions on the database host can cause patching
operations to fail.
• Oracle Grid Infrastructure Issues
One or more of the following conditions on Oracle Grid Infrastructure can cause
patching operations to fail.
• Oracle Databases Issues
An improper database state can lead to patching failures.
• Oracle Cloud Tooling Issues

Host Issues
One or more of the following conditions on the database host can cause patching
operations to fail.

File System is Full

Patching operations require a minimum of 25 GB for Oracle Grid Infrastructure
patching or 15 GB for Oracle Database patching. If the required Oracle home locations
do not not meet the storage requirements, then an error message like the following
can be observed during the patching pre-check operation:

[FATAL] [DBAAS-31009] - One or more Oracle patching pre-checks resulted

in error conditions that needs to be
addressed before proceeding: not enough space for s/w backups
ACTION: Verify the logs at /var/opt/oracle/log/exadbcpatch.

Use the df -h command on the host to check the available space. If the file system
has insufficient space, you can remove old log or trace files to free up space.

Nodes Connectivity Problems

Cloud tooling relies on the proper networking and connectivity configuration between
nodes of a given cluster. If the configuration is not set properly, this may incur in
failures on all the operations that require cross-node processing. One example can be
not being able to download the required files to apply a given patch. In such case and
error like the following one would be observed upon a given patch precheck or apply
request:

[FATAL] [DBAAS-31009] - One or more Oracle patching pre-checks resulted

in error conditions that needs to be
addressed before proceeding: % Total % Received % Xferd Average
Speed Time Time Time Current
Dload Upload Total Spent Left Speed0 0 0 0 0 0 0 0 --:--:--

22-2
 Chapter 22
Patching Failures on Exadata Cloud@Customer Systems

--:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0curl:

(7) Failed connect to [host address]

Given the case, you can perform the following actions:

• Verify that the node or the URL is reachable by using the following commands:

ping hostname

curl target url

• Verify that your DNS configuration is correct so that the relevant nodes addresses
are resolvable within the VM cluster.
• Refer to the relevant Cloud Tooling logs as instructed in the Obtaining Further
Assistance section and contact Oracle Support for further assistance.

Oracle Grid Infrastructure Issues

One or more of the following conditions on Oracle Grid Infrastructure can cause
patching operations to fail.

Oracle Grid Infrastructure is Down

Oracle Clusterware enables servers to communicate with each other so that they can
function as a collective unit. The cluster software program must be up and running on
the VM Cluster for patching operations to complete. Occasionally you might need to
restart the Oracle Clusterware to resolve a patching failure.
In such cases, verify the status of the Oracle Grid Infrastructure as follows:

./crsctl check cluster

CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

If Oracle Grid Infrastructure is down, then restart by running the following commands:

crsctl start cluster -all

crsctl check cluster

Oracle Grid Infrastructure Upgrade Pre-check Failures

During the pre-check operation, many failures can be reported as the requested
databases to be patched, fails in meeting the minimum requirements to perform the
patching operation. An example of the required command is shown as it follows:

dbaascli patch db prereq --patchid patch id --dbnames GRID

DBAAS CLI version 19.4.4.2.0
Executing command patch db prereq --patchid LATEST --dbnames grid

22-3
 Chapter 22
Patching Failures on Exadata Cloud@Customer Systems

INFO: DBCS patching

...

Patch ID not being recognized

If Cloud tooling fails to identify the specified patch ID to verify, then an error like the
following one will be observed:

[FATAL] [DBAAS-10002] - The provided value for the parameter patchnum

is invalid: Incorrect patchnum.
ACTION: Verify the corresponding application usage and/or logs
at /var/opt/oracle/log/exadbcpatchmulti and try again.

To verify that the specified patch ID is correct, confirm that the specified patch ID is
listed as an available patch on the Console.
If the specified patch ID is listed and if the prerequisite operation still fails to
recognize the patch ID, then refer to the relevant Cloud Tooling logs as instructed
in the Obtaining Further Assistance section and contact Oracle Support for further
assistance.
Specific Pre-check Validation Failed
Once that the pre-check validation starts, Cloud tooling will perform a series of
validations to determine whether or not the minimum requirements to perform the
requested patching operation are met. If any of this minimum requirements are not
met, then a failure of the following will be observed:

[FATAL] [DBAAS-31009] - One or more Oracle patching pre-checks resulted

in error conditions that needs to be addressed before proceeding:
<Specific Pre-check Validation Failure>

Depending on the specific failed prerequisite validation, the corresponding corrections

can be performed on the environment or the Oracle home if required. Once that those
corrections have been performed, then the operation can be reattempted.
If the failure persist, then refer to the relevant Cloud Tooling logs as instructed
in the Obtaining Further Assistance section and contact Oracle Support for further
assistance.

Oracle Grid Infrastructure Patch Apply Failures

During the actual installation of the requested patch for the corresponding Oracle
Grid Infrastructure, the procedure may fall into error or unexpected conditions as the
following example:

dbaascli patch db apply --patchid patch id --dbnames GRID

...
ERROR: Grid upgrade failed. Please check corresponding log in /var/opt/
oracle/log/exadbcpatch

If a failure is detected on a given node during the patch installation process, then do
the following:

22-4
 Chapter 22
Patching Failures on Exadata Cloud@Customer Systems

• Address the issue that originated the failure if its evident and then re-try the same
command so that the operation can be resumed from the failure point.
• If after retrying the command the issue persists or if its not possible to identify the
root cause of the failure, then refer to the relevant Cloud Tooling logs as instructed
in the Obtaining Further Assistance section and contact Oracle Support for further
assistance.

Oracle Databases Issues

An improper database state can lead to patching failures.

Oracle Database is Down

The database must be active and running on all the active nodes so the patching
operations can be completed successfully across the cluster.
Use the following command to check the state of your database, and ensure that any
problems that might have put the database in an improper state are resolved:

srvctl status database -d db_unique_name -verbose

The system returns a message including the database instance status. The instance
status must be Open for the patching operation to succeed.
If the database is not running, use the following command to start it:

srvctl start database -d db_unique_name -o open

Oracle Database Patching Pre-check Failures

During the pre-check operation, many failures can be reported as the requested
databases to be patched, fails in meeting the minimum requirements to perform the
patching operation. An example of the required command is shown as it follows:

dbaascli patch db prereq --patchid patch id --dbnames <database

1,...,database n>
DBAAS CLI version 19.4.4.2.0
Executing command patch db prereq --patchid LATEST --dbnames grid
INFO: DBCS patching
...

Patch ID not being recognized

If Cloud tooling fails to identify the specified patch ID to verify, then an error like the
following one will be observed:

[FATAL] [DBAAS-10002] - The provided value for the parameter patchnum

is invalid: Incorrect patchnum.
ACTION: Verify the corresponding application usage and/or logs
at /var/opt/oracle/log/exadbcpatchmulti and try again.

To verify that the specified patch ID is correct, confirm that the specified patch ID is
listed as an available patch on the Console.

22-5
 Chapter 22
Patching Failures on Exadata Cloud@Customer Systems

Alternatively, you can verify the installed patch level into a given home by using the
following command as well:

dbaascli dbhome info

If the specified patch ID is listed and if the prerequisite operation still fails to
recognize the patch ID, then refer to the relevant Cloud Tooling logs as instructed
in the Obtaining Further Assistance section and contact Oracle Support for further
assistance.
Specific Prereq Validation Failed
Once that the prerequisite validation starts, Cloud tooling will perform a series of
validations to determine whether or not the minimum requirements to perform the
requested patching operation are met. If any of this minimum requirements are not
met, then a failure of the following will be observed:

[FATAL] [DBAAS-31009] - One or more Oracle patching pre-checks resulted

in error conditions that needs to be addressed before proceeding:
<Specific Prereq Validation Failure>

Depending on the specific failed prereq validation, the corresponding corrections can
be performed on the environment or the Oracle home if required. Once that those
corrections have been performed, then the operation can be re-attempted.
If the failure persist, then refer to the relevant Cloud Tooling logs as instructed
in the Obtaining Further Assistance section and contact Oracle Support for further
assistance.

Oracle Database Patch Apply Failures

During the actual installation of the requested patch for the corresponding Oracle
Grid Infrastructure, the procedure may fall into error or unexpected conditions as the
following example:

dbaascli patch db apply --patchid patch id --dbnames <database

1,...,database n>
...
ERROR: Error during creation, empty dbhome patching failed. Check the
corresponding logs

If its not possible to identify the root cause of the failure and its corresponding solution,
then refer to the relevant Cloud Tooling logs as instructed in the Obtaining Further
Assistance section and contact Oracle Support for further assistance.

22-6
 Chapter 22
Patching Failures on Exadata Cloud@Customer Systems

Oracle Cloud Tooling Issues

Not Applicable Cloud Tooling Patches Available

One issue that may happen if the Cloud patch installation is tried right away is that the
operation fails because there are no applicable RPMs to install. An example of such
condition is shown as it follows:

dbaascli patch tools apply --patchid LATEST

DBAAS CLI version 19.4.4.2.0
Executing command patch tools apply --patchid LATEST
...
[FATAL] [DBAAS-33032] - An error occurred while performing the
installation of the Oracle DBAAS tools: No applicable dbaastools rpms
found.
ACTION: Verify the logs at /var/opt/oracle/log/exadbcpatch.

To confirm that indeed there are no applicable patches to be installed for Cloud tooling
you can run the following command:

dbaascli patch tools list

If the patch level for the Cloud tooling is eligible for patch application and Cloud tooling
is not able to disclose any applicable patch ID, then refer to the relevant Cloud Tooling
logs as instructed in the Obtaining Further Assistance section and contact Oracle
Support for further assistance.

Failed Patch Modifies the Home Name in oraInventory with the Suffix
"_PIP"
Description: The image-based patching process temporarily changes the name of the
Home that is being patched in the oraInventory adding the suffix '_pip' for patching in
progress. For example, changing OraDB19Home1 to OraDB19Home1_pip.
When a patch fails on node 2, the name is not reverted to the original name.
This causes subsequent Home installed on node 2 to use the Home name
OraDB19Home1.
Action: On the failing node run the following command to clear the inventory from the
corresponding _pip entrance:

/var/opt/oracle/exapatch/exadbcpatchmulti -rollback_async patch id

-instance1=hostname:ORACLE_HOME path -dbname=dbname1 -run_datasql=1

After performing the local rollback, resume applying the corresponding patching.

Patching Primary and Standby Databases Configured with Oracle

Data Guard Fails

22-7
 Chapter 22
Obtaining Further Assistance

Description: In OCI environments, patching primary or secondary nodes using the

exadbcpatchmulti tool fails if there's no SSH connectivity between the primary and
standby nodes.
Action: Depending on the node you're patching, add the -primary or -secondary
flag. You can add flags to identify the nodes only if you're patching using the
exadbcpatchmulti tool.

For example:
To patch standby nodes, use -secondary flag.

/var/opt/oracle/exapatch/exadbcpatchmulti action [patchid] dbname|

instance_num -secondary

To patch primary nodes, use -primary flag.

/var/opt/oracle/exapatch/exadbcpatchmulti action [patchid] dbname|

instance_num -primary

Note:
Always patch standby nodes first and then proceed to primary nodes.

Obtaining Further Assistance

If you were unable to resolve the problem using the information in this topic, follow the
procedures below to collect relevant database and diagnostic information. After you
have collected this information, contact Oracle Support.
• Collecting Cloud Tooling Logs
Use the relevant log files that could assist Oracle Support for further investigation
and resolution of a given issue.
• Collecting Configuration Tools Logs
• Collecting Oracle Diagnostics
Related Topics
• Oracle Support

Collecting Cloud Tooling Logs

Use the relevant log files that could assist Oracle Support for further investigation and
resolution of a given issue.

DBAASAPI Logs
These logs are applicable for actions that are performed from the Console.
/var/opt/oracle/log/dbaasapi/db/db
• Job HASH.log corresponding to the Backend API request

22-8
 Chapter 22
Obtaining Further Assistance

Note:
All the log files are timestamped records so that the issues can be traced
back to some point in the past during the DBSystem operation.

DBAASCLI Logs
/var/opt/oracle/log/dbaascli
• dbaascli.log

DBAAS ExaPatch Logs

/var/opt/oracle/log/exadbcpatchmulti:
• exadbcpatchmulti.log
• exadbcpatchmulti-cmd.log

/var/opt/oracle/log/exadbcpatchsm:
• exadbcpatchsm.log

/var/opt/oracle/log/exadbcpatch:
• exadbcpatch.log
• exadbcpatch-cmd.log
• exadbcpatch-dmp.log
• exadbcpatch-sql.log

Note:
All the log files are timestamped records so that the issues can be traced
back to some point in the past during the DBSystem operation.

Collecting Configuration Tools Logs

$GRID_BASE/cfgtoollogs
$ORACLE_BASE/cfgtoollogs

Collecting Oracle Diagnostics

To collect the relevant Oracle diagnostic information and logs, run the
dbaas_diag_tool.pl script.

/var/opt/oracle/misc/dbaas_diag_tool.pl

For more information about the usage of this utility, see My Oracle Support note
2219712.1.

22-9
 Chapter 22
Database is Down While Performing Downgrade to Release 11.2 or 12.1

Related Topics
• https://support.oracle.com/epmos/faces/DocumentDisplay?
cmd=show&type=NOT&id=2219712.1

Database is Down While Performing Downgrade to Release

11.2 or 12.1
Description: Error is thrown as follows while running the database upgrade command
with the –revert flag.
[FATAL] [DBAAS-54007] - An error occurred when
open the a121db database with resetlog options: ORA-01034: ORACLE not
available.

Action: Apply one-off patching for bug 31561819 prior to attempting the downgrade if
required for Oracle Database releases 11.2 and 12.1.
If the issue persists and impacts a given database, then, per a similar bug 31762303
filed by MAA team, Oracle recommends that you run the following commands after the
failure to complete database downgrade:

/u02/app/oracle/product/19.0.0.0/dbhome_3/bin/srvctl downgrade database

-d
<DB_UNIQUE_NAME> -o /u02/app/oracle/product/11.2.0/dbhome_2 -t 11.2.0.4

/u02/app/oracle/product/11.2.0/dbhome_2/bin/srvctl setenv database -d

<DB_UNIQUE_NAME> -T
"TNS_ADMIN=/u02/app/oracle/product/11.2.0/dbhome_2/network/admin/
<DB_NAME>"

After Database Upgrade, the Standby Database Remains in

Mounted State in Oracle Data Guard Configurations
Description: After performing the upgrade as recommended in Oracle MOS note
2628228.1, the standby database is left opened in MOUNT state.
Action: If it is required to bring the standby database back to read-only mode, then
proceed with the following steps:
Run the following query on the primary database:

SELECT
DEST_ID,THREAD#,sequence#,RESETLOGS_CHANGE#,STANDBY_DEST,ARCHIVED,APPLIE
D,status,to_char(completion_time,'DD-MM-YYYY:hh24:mi') from
v$archived_log;

Ensure that all the logs have been replicated successfully to the standby database
after the upgrade operation.

22-10
 Chapter 22
Primary Database Fails to Downgrade to 18c in Oracle Data Guard Configurations

Then on the standby database, run the following commands:

dbaascli database stop --dbname standby dbname

dbaascli database start --dbname standby dbname

Then the database should be open in read-only mode again.

Primary Database Fails to Downgrade to 18c in Oracle Data

Guard Configurations
Description: The following failure is observed while downgrading a primary Data
Guard database from 19c to 18c:
[FATAL] [DBAAS-54007]
- An error occurred when open the db163 database with resetlog options:
ORA-16649: possible failover to another database prevents this database from
being opened.

Action: Follow these steps to fix the issue:

1. Open the initdbname.ora file:

/var/opt/oracle/dbaas_acfs/upgrade_backup/dbname/initdbname.ora

2. Set the *.dg_broker_start parameters to false and save the changes:

*.dg_broker_start=FALSE

3. Bring down the local instance and open it back in mount mode:

startup mount pfile=’/var/opt/oracle/dbaas_acfs/upgrade_backup/

dbname/initdbname.ora’;

4. Then open it with the following command:

alter database open resetlogs;

5. Re-enable the Data Guard broker.

alter system set dg_broker_start=true scope=BOTH;

6. Restore the spfile.

create spfile=’DATA DISKGROUP/db_unique_name/spfiledbname.ora’

from pfile=’ /var/opt/oracle/dbaas_acfs/upgrade_backup/dbname/
initdbname.ora’

22-11
 Chapter 22
Deleting a Database Does Not Delete the Associated Oracle Home

7. Shut down the local instance.

shutdown immediate;

8. Manually downgrade the service.

19c Oracle home/bin/srvctl downgrade database –d db_unique_name -

oraclehome 18c Oracle home path -targetversion 18.0.0.0.0

9. Restore the TNS_ADMIN variable.

19c Oracle home/bin/srvctl setenv database –d db_unique_name -t

oraclehome “18c Oracle home/network/admin/dbname”

10. Bounce the database across the cluster.

18c Oracle home/bin/srvctl stop database –d db_unique_name

18c Oracle home/bin/srvctl start database –d db_unique_name

Deleting a Database Does Not Delete the Associated Oracle

Home
Description: During initial VM cluster creation, a database is created to verify/test
the ability to create a database through tooling. This database is immediately deleted.
However, the Oracle Home directory is left behind.
Action: To delete Oracle Home, run the following dbaascli commands as root.

dbaascli dbhome info: Lists all the database home and any associated databases in
the respective homes.
Identify the database home where no databases are running, and then run the
following command to delete Oracle home.

dbaascli dbhome purge --hpath path of Oracle Home to purge

You can get the path of Oracle Home to purge details from the dbaascli dbhome info
command.
Related Topics
• dbaascli dbhome info
Use the dbaascli dbhome info command to view information about Oracle Home
directory locations.
• dbaascli dbhome purge
Use the command dbaascli dbhome purge to delete unused Oracle home
directory locations.

22-12
23
Introduction to Autonomous Database on
Exadata Cloud@Customer
Oracle Autonomous Database on Oracle Exadata Cloud@Customer combines the
benefits of a self-driving, self-securing, and self-repairing database management
system and the security and control offered by having it deployed securely on premise
behind your firewall.
After purchasing Autonomous Database on Oracle Exadata Cloud@Customer
and creating, provisioning and activating its Exadata Infrastructure hardware
and Oracle Cloud resource, several additional resource types become available
in the Exadata Cloud@Customer section of the Oracle Cloud Infrastructure
console: Autonomous Exadata VM Clusters, Autonomous Container Databases and
Autonomous Databases. You use these resources to create and manage your secure,
on-premise deployment of Oracle Autonomous Database.
• Database System Architecture Overview
• User Roles
• Available Exadata Infrastructure Hardware Shapes
• Oracle Exadata Cloud@Customer X8M-2 System Specifications
Review the technical specifications for each system configuration option for ADB-
D on Oracle Exadata Cloud@Customer.
• Access Control Lists (ACLs) for Autonomous Databases on Exadata
Cloud@Customer

Database System Architecture Overview

Oracle Autonomous Database on Oracle Exadata Cloud@Customer has a four-
level database architecture model that makes use of Oracle multitenant database
architecture.
• Resource Types
• Deployment Order

Resource Types
Each level of the architecture model corresponds to one of the following resources
types:
• Oracle Exadata Cloud@Customer infrastructure: Hardware rack that includes
compute nodes and storage servers, tied together by a high-speed, low-latency
InfiniBand network and intelligent Exadata software.
Oracle Exadata Cloud@Customer infrastructure is common for both Autonomous
and Non-Autonomous resources.

23-1
 Chapter 23
User Roles

For a list of the hardware and Oracle Cloud resource characteristics of Oracle
Exadata Cloud@Customer infrastructure resources that support Autonomous
Databases, see Available Exadata Infrastructure Hardware Shapes.
– Only the Oracle Exadata Cloud@Customer Infrastructures deployed before
Oracle announced support for Autonomous Databases on Oracle Exadata
Cloud@Customer do not support Autonomous resources listed below. Please
contact your Oracle sales representative to understand the infrastructure
upgrades required for supporting Oracle Autonomous Databases.
– You can create only one Autonomous VM cluster in an Exadata Infrastructure.
– Oracle Exadata Cloud@Customer infrastructure cannot simultaneously have
both Autonomous and Exadata VM clusters.
• Autonomous VM clusters on Exadata Cloud@Customer infrastructure: VM
cluster is a set of symmetrical VMs across all Compute nodes. Autonomous
Container and Database run all the VMs across all nodes enabling high
availability. It consumes all the resources of the underlying Exadata Infrastructure.
Before you can create any Autonomous Databases on your Exadata
Cloud@Customer infrastructure, you must create an Autonomous VM cluster
network, and you must associate it with a VM cluster.
• Autonomous Container Database: Provides a container for multiple
Autonomous Databases.
• Autonomous Database: You can create multiple autonomous databases within
the same autonomous container database. You can configure Oracle Autonomous
Database for either transaction processing or data warehouse workloads.

Deployment Order
You must create the dedicated Exadata infrastructure resources in the following order:
1. Exadata Infrastructure. See Preparing for Exadata Cloud@Customer and
Provisioning Exadata Cloud@Customer Systems for more information.
2. Autonomous Exadata VM cluster. See Managing Autonomous Exadata VM
Clusters for more information.
3. Autonomous Container Database. See Managing Autonomous Container
Databases for more information.
4. Autonomous Database. See Managing Autonomous Databases for more
information.

User Roles
Your organization may choose to split the administration of the Oracle Autonomous
Database on Oracle Exadata Cloud@Customer into the following roles:
• Fleet Administrator. Fleet administrators create, monitor and manage
Autonomous Exadata Infrastructure and Autonomous Container Database
resources. They must also setup customer managed Backup Destinations, such
as Recovery Appliance and NFS to be used by Autonomous Databases. A
fleet administrator must have permissions for using the networking resources
required by the Oracle Exadata Cloud@Customer infrastructure, and permissions
to manage the infrastructure and container database resources.

23-2
 Chapter 23
Available Exadata Infrastructure Hardware Shapes

• Database Administrator. Database administrators create, monitor and manage

Autonomous Databases. They also create and manage users within the database.
Database administrators must have permissions for using container databases,
for managing autonomous databases and backups, and for using the related
networking resources. At the time of provisioning an Autonomous Database,
the administrator provides user credentials for the automatically created ADMIN
account, which provides administrative rights to the new database.
• Database User. Database users are the developers who write applications that
connect to and use an Autonomous Database to store and access the data.
Database users do not need Oracle Cloud Infrastructure accounts. They gain
network connectivity to and connection authorization information for the database
from the database administrator.

Available Exadata Infrastructure Hardware Shapes

Oracle Autonomous Database on Oracle Exadata Cloud@Customer supports the
following shapes of Exadata Infrastructure resources.
The following table lists the Exadata Infrastructure resource shapes that Oracle
Autonomous Database on Oracle Exadata Cloud@Customer supports.

Specification Exadata X8-2 Exadata X8-2 Half Exadata X8-2 Full

Quarter Rack Rack Rack
Shape Name Exadata.Quarter3.1 Exadata.Half3.200 Exadata.Full3.400
00
Number of Compute Nodes 2 4 8
Total Maximum Number of Enabled CPU Cores 100 200 400
Total RAM Capacity 1440 GB 2880 GB 5760 GB
Number of Exadata Storage Servers 3 6 12
Total Raw Flash Storage Capacity 76.8 TB 153.6 TB 307.2 TB
Total Usable Storage Capacity 149.7 TB 299.4 TB 598.7 TB
Maximum Number of Autonomous Container 12 (See note) 12 (See note) 12 (See note)
Databases
Maximum Number of Autonomous Databases 100 (See note) 200 (See note) 400 (See note)
per Autonomous Container Database

Note:
Oracle Autonomous Database does not currently support over-provisioning,
the ability for multiple autonomous databases to share a single CPU
core. Therefore, an Exadata Infrastructure resource can currently support,
across all its autonomous container databases, up to as many autonomous
databases as it has CPU cores.

23-3
 Chapter 23
Oracle Exadata Cloud@Customer X8M-2 System Specifications

Oracle Exadata Cloud@Customer X8M-2 System

Specifications
Review the technical specifications for each system configuration option for ADB-D on
Oracle Exadata Cloud@Customer.

Tip:
X8M-2 support is available only in the ashburn-1 region.

Table 23-1 Oracle Exadata Cloud@Customer X8M-2 System Specifications

Property Quarter Rack Half Rack Full Rack

Number of Compute 2 4 8
Nodes
Total Maximum 100 200 400
Number of Enabled
CPU Cores
Total RAM Capacity 2780 GB 5560 GB 11120 GB
Persistent Memory 4.6 TB 9.2 TB 18.4 TB
Number of Exadata 3 6 12
Storage Servers
Total Raw Flash 76.8 TB 153.6 TB 307.2 TB
Storage Capacity
Total Usable Storage 149 TB 299 TB 598 TB
Capacity**
Max number of VMs 8 8 8

** TB=1024^4

Access Control Lists (ACLs) for Autonomous Databases on

Exadata Cloud@Customer
An access control list (ACL) provides additional protection to your database by
allowing only the clients with specific IP addresses to connect to the database. You
can add IP addresses individually, or in CIDR blocks.
You can optionally create an ACL during database provisioning, or at any time
thereafter. You can also edit an ACL at any time. Enabling an access control list with
an empty list of IP addresses makes the database inaccessible. For more information,
see "Manage Access Control List of an Autonomous Database".
Note the following about using an ACL with your Autonomous Database:
• The Autonomous Database Service console is not subject to ACL rules.

23-4
 Chapter 23
Access Control Lists (ACLs) for Autonomous Databases on Exadata Cloud@Customer

• Oracle Application Express (APEX), RESTful services, and SQL Developer Web
are not subject to ACLs. Choosing to enable an ACL disables these features
automatically.
• Performance Hub is not subject to ACL rules.
• While creating a database, if setting ACL fails, then provisioning the database also
fails.
• Updating ACL is allowed if the database is in Available and
AvailableNeedsAttention states.
• Restoring a database does not overwrite the existing ACLs.
• Cloning a database, full and metadata, will have the same access control settings
as the source database. You can make changes as necessary.
• All CDB operations are allowed during ACL update. However, ADB operations are
not allowed during ACL update.
Related Topics
• Manage Access Control List of an Autonomous Database

23-5
24
Managing Autonomous Exadata VM
Clusters
An Autonomous Exadata VM Cluster is a set of symmetrical VMs across all Compute
nodes. Autonomous Container and Database run all the VMs across all nodes
enabling high availability. It consumes all the resources of the underlying Exadata
Infrastructure.
After you have created the Autonomous Exadata VM Cluster, you can create up to
12 Autonomous Container Database resources on it, depending on the capacity of
your Exadata Infrastructure hardware, as described in Available Exadata Infrastructure
Hardware Shapes.
• Create an Autonomous Exadata VM Cluster
• View a List of Autonomous Exadata VM Clusters
• View Details of an Autonomous Exadata VM Cluster
• Change the License Type on an Autonomous VM Cluster
• Move an Autonomous Exadata VM Cluster to Another Compartment
• Terminate an Autonomous Exadata VM Cluster
• Using the API to Manage Autonomous Exadata VM Clusters

Create an Autonomous Exadata VM Cluster

Follow these steps to create an Autonomous Exadata VM cluster on an Oracle
Exadata Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Exadata VM Clusters.
3. Click Create Autonomous Exadata VM Cluster.
4. In the Create Autonomous Exadata VM Cluster dialog, enter the following general
information:
• Compartment: Specify the compartment in which the Autonomous Exadata
VM Cluster will be created.
• Display Name: A user-friendly description or other information that helps you
easily identify the infrastructure resource. The display name does not have to
be unique. Avoid entering confidential information.
• Exadata Infrastructure: Select an Exadata Infrastructure.
• VM Cluster Network: Select a VM Cluster Network.
• Configure the Exadata Storage: Optionally, you can Allocate Storage for
Local Backups.

24-1
 Chapter 24
View a List of Autonomous Exadata VM Clusters

5. Choose the license type you wish to use.

Your choice affects metering for billing. You have the following options:
• Bring your own license: If you choose this option, make sure you have
proper entitlements to use for new service instances that you create.
• License included: With this choice, the cost of the cloud service includes a
license for the Database service.
6. The following Advanced Options are available:
• Time zone: The default time zone for the Exadata Infrastructure is UTC,
but you can specify a different time zone. The time zone options are those
supported in both the Java.util.TimeZone class and the Oracle Linux operating
system.

Note:
If you want to set a time zone other than UTC or the
browser-detected time zone, then select the Select another time
zone option, select a Region or contry, and then select the
corresponding Time zone.
If you do not see the region or country you want, then select
Miscellaneous, and then select an appropriate Time zone.

• Tags: Optionally, you can apply tags. If you have permissions to create a
resource, you also have permissions to apply free-form tags to that resource.
To apply a defined tag, you must have permissions to use the tag namespace.
For more information about tagging, see Resource Tags. If you are not sure if
you should apply tags, skip this option (you can apply tags later) or ask your
administrator. Avoid entering confidential information.
7. Click Create Autonomous Exadata VM Cluster.

View a List of Autonomous Exadata VM Clusters

Follow these steps to view a list of autonomous Exadata VM clusters on an Oracle
Exadata Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Exadata VM Clusters.

View Details of an Autonomous Exadata VM Cluster

Follow these steps to view detailed information about an autonomous Exadata VM
cluster on an Oracle Exadata Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Exadata VM Clusters.
3. In the list of Autonomous Exadata VM Clusters, click the display name of the
Exadata VM cluster you wish to view details.

24-2
 Chapter 24
Change the License Type on an Autonomous VM Cluster

Change the License Type on an Autonomous VM Cluster

Follow these steps to update the license type of an autonomous Exadata VM cluster
on an Oracle Exadata Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Exadata VM Clusters.
3. In the list of Autonomous Exadata VM Clusters, click the display name of the
Exadata VM cluster you wish to administer.
4. Click Update License Type.
5. On the Update License Type dialog box, choose one of the following license types.
• Bring Your Own License (BYOL): Select this option if your organization
already owns Oracle Database software licenses that you want to use on the
VM cluster.
• License Included: Select this option to subscribe to Oracle Database
software licenses as part of Exadata Cloud@Customer.
Updating the license type does interrupt the operation of the VM cluster.
6. Click Save Changes.

Move an Autonomous Exadata VM Cluster to Another

Compartment
Follow these steps to move an autonomous Exadata VM cluster on an Oracle Exadata
Cloud@Customer system from one compartment to another compartment.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Exadata VM Clusters.
3. In the list of Autonomous Exadata VM Clusters, click the display name of the
Exadata VM cluster you wish to administer.
4. Click Move Resource.
5. Select the new compartment.
6. Click Move Resource.

Terminate an Autonomous Exadata VM Cluster

Follow these steps to terminate an autonomous Exadata VM cluster on an Oracle
Exadata Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. In the list of Autonomous Exadata VM Clusters, click the display name of the
Exadata VM cluster you wish to administer.
3. Click Terminate.

24-3
 Chapter 24
Using the API to Manage Autonomous Exadata VM Clusters

4. Confirm that you wish to terminate your Autonomous Exadata VM Cluster in the
confirmation dialog.
5. Click Terminate VM Cluster.

Using the API to Manage Autonomous Exadata VM Clusters

For information about using the API and signing requests, see REST APIs and
Security Credentials. For information about SDKs, see Software Development Kits and
Command Line Interface.
The following table lists the REST API endpoints to manage Autonomous Exadata VM
Clusters.

Operation REST API Endpoint

Create an Autonomous Exadata VM Cluster CreateAutonomousVmCluster
View a list of Autonomous Exadata VM ListAutonomousVmClusters
Clusters
View details of an Autonomous Exadata VM GetAutonomousVmCluster
Cluster
Change the license type of an Autonomous UpdateAutonomousVmCluster
VM Cluster
Move an Autonomous Exadata VM Cluster to ChangeAutonomousVmClusterCompartment
another compartment
Terminate an Autonomous Exadata VM DeleteAutonomousVmCluster
Cluster

24-4
25
Managing Encryption Keys on External
Devices
There are two options to store and manage database encryption keys for your
autonomous databases on Exadata Cloud@Customer:
1. In the Guest VM on the Exadata Infrastructure.
2. On an external key management device. Oracle Key Vault is the currently
supported device.
• About Oracle Key Vault
Oracle Key Vault is a full-stack, security-hardened software appliance built to
centralize the management of keys and security objects within the enterprise.
• Overview of Key Store
Integrate your on-premises Oracle Key Vault (OKV) with Autonomous Database
on Exadata Cloud@Customer to secure your critical data on-premises.
• Required IAM Policy for Managing OKV on Oracle Exadata Cloud@Customer
Review the identity access management (IAM) policy for managing OKV on Oracle
Exadata Cloud@Customer Systems.
• Tagging Resources
You can apply tags to your resources to help you organize them according to your
business needs.
• Moving Resources to a Different Compartment
You can move vaults from one compartment to another.
• Setting Up Your Exadata Cloud@Customer to Work With Oracle Key Vault
• Managing Your Key Store

About Oracle Key Vault

Oracle Key Vault is a full-stack, security-hardened software appliance built to
centralize the management of keys and security objects within the enterprise.

Note:
The Oracle Key Vault is a customer-provisioned and managed system and it
is not part of Oracle Cloud Infrastructure managed services.

Related Topics
• Oracle Key Vault

25-1
 Chapter 25
Overview of Key Store

Overview of Key Store

Integrate your on-premises Oracle Key Vault (OKV) with Autonomous Database on
Exadata Cloud@Customer to secure your critical data on-premises.
Oracle Key Vault integration enables you to take complete control of your encryption
keys and store them securely on an external, centralized key management device.
OKV is optimized for Oracle wallets, Java keystores, and Oracle Advanced Security
Transparent Data Encryption (TDE) master keys. Oracle Key Vault supports the
OASIS KMIP standard. The full-stack, security-hardened software appliance uses
Oracle Linux and Oracle Database technology for security, availability, and scalability,
and can be deployed on your choice of compatible hardware.
OKV also provides a REST interface for clients to auto-enroll endpoints and setup
wallets and keys. For Autonomous Databases on Exadata Cloud@Customer to
connect to OKV REST interface, create a key store in your tenancy to store the IP
address and administrator credentials of your OKV. Exadata Cloud@Customer will not
store the admin password required to connect to the OKV appliance. Ensure that you
create a secret with Oracle's Vault Service, which will store the password required for
autonomous databases to connect to OKV for key management.
For more information, see "Oracle Key Vault".
Related Topics
• Oracle Key Vault

Required IAM Policy for Managing OKV on Oracle Exadata

Cloud@Customer
Review the identity access management (IAM) policy for managing OKV on Oracle
Exadata Cloud@Customer Systems.
A policy is an IAM document that specifies who has what type of access to your
resources. It is used in different ways: to mean an individual statement written in
the policy language; to mean a collection of statements in a single, named "policy"
document (which has an Oracle Cloud ID (OCID) assigned to it), and to mean the
overall body of policies your organization uses to control access to resources.
A compartment is a collection of related resources that can be accessed only
by certain groups that have been given permission by an administrator in your
organization.
To use Oracle Cloud Infrastructure, you must be given the required type of access in
a policy written by an administrator, whether you're using the Console, or the REST
API with a software development kit (SDK), a command-line interface (CLI), or some
other tool. If you try to perform an action, and receive a message that you don’t
have permission, or are unauthorized, then confirm with your administrator the type of
access you've been granted, and which compartment you should work in.
For administrators: The policy in "Let database admins manage DB systems" lets the
specified group do everything with databases and related database resources.

25-2
 Chapter 25
Tagging Resources

If you're new to policies, then see "Getting Started with Policies" and "Common
Policies". If you want to dig deeper into writing policies for databases, then see "Details
for the Database Service".
Related Topics
• Let database admins manage DB systems
• Getting Started with Policies
• Common Policies
• Details for the Database Service

Tagging Resources
You can apply tags to your resources to help you organize them according to your
business needs.
You can apply tags at the time you create a resource, or you can update the resource
later with the desired tags. For general information about applying tags, see "Resource
Tags".
Related Topics
• Resource Tags

Moving Resources to a Different Compartment

You can move vaults from one compartment to another.
After you move a vault to a new compartment, inherent policies apply immediately
and affect access to the vault. Moving a vault doesn't affect access to any keys or
secrets that the vault contains. You can move a key or secret from one compartment
to another independently of moving the vault it's associated with. For more information,
see "Managing Compartments".
Related Topics
• Managing Compartments

Setting Up Your Exadata Cloud@Customer to Work With

Oracle Key Vault
Prerequisites
1. Ensure OKV is setup and network accessible from the Exadata client network
2. Gather OKV administrator credentials and IP address, which is required to connect
to OKV
• Step 1: Create a Vault in OCI Vault Service and Add a Secret to the Vault to Store
OKV REST Administrator Password
• Step 2: Create a Dynamic Group and a Policy Statement for Key Store to Access
Secret in OCI Vault
• Step 3: Create a Dynamic Group and a Policy Statement for Exadata
Infrastructure to Key Store

25-3
 Chapter 25
Setting Up Your Exadata Cloud@Customer to Work With Oracle Key Vault

• Step 4: Create a Policy Statement for Database Service to Use Secret from OCI
Vault Service
• Step 5: Create Key Store

Step 1: Create a Vault in OCI Vault Service and Add a Secret to the
Vault to Store OKV REST Administrator Password
Your Exadata Cloud@Customer infrastructure communicates with OKV over REST
each time an Autonomous Container Database is provisioned to register the
Autonomous Container Database and request a wallet on OKV. Therefore, Exadata
infrastructure needs access to the REST admin credentials.
These credentials can be stored securely in the Oracle Vault Service in OCI as a
Secret and accessed by your Exadata Cloud@Customer infrastructure only when
needed. These credentials are not accessible by a human operator administering the
Exadata infrastructure.
To store OKV administrator password in OCI Vault service, create a vault by following
the instructions outlined in "Managing Vaults" and create a Secret in that vault by
following the instructions outlined in "Managing Secrets".
Related Topics
• Managing Vaults
• Managing Secrets

Step 2: Create a Dynamic Group and a Policy Statement for Key Store
to Access Secret in OCI Vault
To grant your Key Store resources permission to access Secret in OCI Vault, you
create an IAM dynamic group that identifies these resources and then create an IAM
policy that grants this dynamic group access to the Secret you created in the OCI
Vaults and Secrets.
When defining the dynamic group, you identify your Key Store resources by specifying
the OCID of the compartment containing your Key Store.
1. Copy the OCID of the compartment containing your Key Store resource.
You can find this OCID on the Compartment Details page of the compartment.
2. Create a dynamic group by following the instructions in "To create a dynamic
group" in Oracle Cloud Infrastructure Documentation. When following these
instructions, enter a matching rule of this format:

ALL {resource.compartment.id ='<compartment-ocid>'}

where <compartment-ocid> is the OCID of the compartment containing your Key

Store resource.

25-4
 Chapter 25
Setting Up Your Exadata Cloud@Customer to Work With Oracle Key Vault

3. After creating the dynamic group, navigate to (or create) an IAM policy in a
compartment higher up in your compartment hierarchy than the compartment
containing your vaults and secrets. Then, add a policy statement of this format:

allow dynamic-group <dynamic-group> to use secret-family in

compartment <vaults-and-secrets-compartment>

where <dynamic-group> is the name of the dynamic group you created and
<vaults-and-secrets-compartment> is the name of the compartment in which
you created your vaults and secrets.
Related Topics
• To create a dynamic group

Step 3: Create a Dynamic Group and a Policy Statement for Exadata

Infrastructure to Key Store
To grant your Exadata infrastructure resources permission to access Key Store, you
create an IAM dynamic group that identifies these resources and then create an IAM
policy that grants this dynamic group access to the Key Store you created.
When defining the dynamic group, you identify your Exadata infrastructure resources
by specifying the OCID of the compartment containing your Exadata infrastructure.
1. Copy the OCID of the compartment containing your Exadata infrastructure
resource.
You can find this OCID on the Compartment Details page of the compartment.
2. Create a dynamic group by following the instructions in "To create a dynamic
group" in Oracle Cloud Infrastructure Documentation. When following these
instructions, enter a matching rule of this format:

ALL {resource.compartment.id ='<compartment-ocid>'}

where <compartment-ocid> is the OCID of the compartment containing your

Exadata infrastructure resource.
3. After creating the dynamic group, navigate to (or create) an IAM policy in a
compartment higher up in your compartment hierarchy than the compartment
containing your Key Store. Then, add a policy statement of this format:

Allow dynamic-group <dynamic-group> to use keystores in compartment

<key-store-compartment>

where <dynamic-group> is the name of the dynamic group you created and
<key-store-compartment> is the name of the compartment in which you created
your Key Store.

25-5
 Chapter 25
Setting Up Your Exadata Cloud@Customer to Work With Oracle Key Vault

Step 4: Create a Policy Statement for Database Service to Use Secret

from OCI Vault Service
To grant the Autonomous Database service permission to use the secret in OCI
Vault to log in to the OKV REST interface, navigate to (or create) an IAM policy
in a compartment higher up in your compartment hierarchy than the compartment
containing your OCI Vaults and Secrets. Then, add a policy statement of this format:

allow service database to read secret-family in compartment <vaults-and-

secrets-compartment>

where <vaults-and-secrets-compartment> is the name of the compartment in which

you created your OCI Vaults and Secrets.
Once the OCI Vault is set up and the IAM configuration is in place, you are now ready
to deploy your Oracle Key Vault 'Key Store' in OCI and associate it with your Exadata
Cloud@Customer VM Cluster.

Step 5: Create Key Store

Follow these steps to create a Key Store to connect to an on-premises encryption key
appliance such as Oracle Key Vault (OKV).
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose your Compartment.
3. Click Key Stores.
Key Stores page displays the list name of key stores, the number of databases
associated with each database, and the date on which each key store was
created.
4. Click Create Key Store.
5. In the Create Key Store dialog, enter the following general information:
• Name your key store: A user-friendly description or other information that
helps you easily identify the Key Store resource. Avoid entering confidential
information.
• Oracle Key Vault connection settings
– Connection IP addresses: Enter the IP address of the OKV appliance.
You can specify a comma-delimited list of IP addresses, for example,
193.10.20.1, 193.10.20.1.
– Administrator username: Enter the user name of the OKV REST
administrator.
– Administrator Password Secret: The administrator password is stored
with the secret management service within OCI. Select the OCI Vault in
your tenancy that contains OKV REST administrator password stored as
Secret.

25-6
 Chapter 25
Managing Your Key Store

• Tags: Optionally, you can apply tags. If you have permission to create a
resource, you also have permission to apply free-form tags to that resource.
To apply a defined tag, you must have permission to use the tag namespace.
For more information about tagging, see Resource Tags. If you are not sure if
you should apply tags, skip this option (you can apply tags later) or ask your
administrator. Avoid entering confidential information.
6. Click Create Key Store.
For more information, see "Managing Vaults", "Managing Keys", and "Managing
Secrets".
Related Topics
• Managing Vaults
• Managing Keys
• Managing Secrets

Managing Your Key Store

• View Key Store Details
Follow these steps to view Key Store details that include Oracle Key Vault (OKV)
connection details and the list of associated databases.
• Edit Key Store Details
You can edit a Key Store only if it is not associated with any CDBs.
• Move a Key Store to Another Compartment
Follow these steps to move a Key Store on an Oracle Exadata Cloud@Customer
system from one compartment to another compartment.
• Delete a Key Store
You can delete a Key Store only if it is not associated with any CDBs.
• View Key Store Associated Autonomous Container Database Details
Follow these steps to view details of the Autonomous Container Database
associated with a Key Store.
• Using the API to Manage Key Store
Learn how to use the API to manage key store.

View Key Store Details

Follow these steps to view Key Store details that include Oracle Key Vault (OKV)
connection details and the list of associated databases.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose your Compartment.
3. Click Key Stores.
Key Stores page displays the list name of Key Stores, the number of databases
associated with each database, and the date on which each Key Store was
created.
4. Click the name of the Key Store or click the Actions icon (three dots), and then
click View Details.

25-7
 Chapter 25
Managing Your Key Store

5. Click the link in the Administrator Password Secret field to view secret details.

Edit Key Store Details

You can edit a Key Store only if it is not associated with any CDBs.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose your Compartment.
3. Click Key Stores.
4. Click the name of the Key Store or click the Actions icon (three dots), and then
click View Details.
5. On the Key Store Details page, click Edit.
6. On the Edit Key Store page, make changes as needed, and then click Save
Changes.

Move a Key Store to Another Compartment

Follow these steps to move a Key Store on an Oracle Exadata Cloud@Customer
system from one compartment to another compartment.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose your Compartment.
3. Click Key Stores.
4. Click the name of the Key Store or click the Actions icon (three dots), and then
click View Details.
5. On the Key Store Details page, click Move Resource.
6. On the Move Resource to a Different Compartment page, select the new
compartment.
7. Click Move Resource.

Delete a Key Store

You can delete a Key Store only if it is not associated with any CDBs.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose your Compartment.
3. Click Key Stores.
4. Click the name of the Key Store or click the Actions icon (three dots), and then
click View Details.
5. On the Key Store Details page, click Delete.
6. On the Delete Key Store dialog, click Delete.

25-8
 Chapter 25
Managing Your Key Store

View Key Store Associated Autonomous Container Database Details

Follow these steps to view details of the Autonomous Container Database associated
with a Key Store.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Choose your Compartment.
3. Click Key Stores.
Key Stores page displays the list name of Key Stores, the number of databases
associated with each database, and the date on which each Key Store was
created.
4. Click the name of the Key Store or click the Actions icon (three dots), and then
click View Details.
5. Click the name of the associated database or click the Actions icon (three dots),
and then click View Details.

Using the API to Manage Key Store

Learn how to use the API to manage key store.
For information about using the API and signing requests, see "REST APIs" and
"Security Credentials". For information about SDKs, see "Software Development Kits
and Command Line Interface".
The following table lists the REST API endpoints to manage key store.

Operation REST API Endpoint

Create OKV Key Store CreateKeyStore
View OKV Key Store GetKeyStore
Update OKV Key Store UpdateKeyStore
Delete OKV Key Store DeleteKeyStore
Change Key store compartment ChangeKeyStoreCompartment
Choose between customer-managed and CreateAutonomousContainerDatabase
Oracle-managed encryption
Get the Key Store (OKV or Oracle-managed) GetAutonomousContainerDatabase
and OKV wallet name
Rotate OKV and Oracle-managed key RotateAutonomousContainerDatabaseKey
Get the Key store (OKV or Oracle-managed) GetAutonomousDatabase
and OKV wallet name
Rotate OKV and Oracle-managed key RotateAutonomousDatabaseKey
Get the Key Store (OKV or Oracle-managed) GetAutonomousDatabaseBackup
and OKV wallet name

Related Topics
• REST APIs

25-9
 Chapter 25
Managing Your Key Store

• Security Credentials
• Software Development Kits and Command Line Interface

25-10
26
Managing Autonomous Container
Databases
Learn how you can create, view, move, change backup policies, manage maintenance
schedules, and perform other Oracle Autonomous Container Database management.
An Autonomous Container Database resource provides a container for your
Autonomous Databases. You can create multiple Autonomous Container Database
resources in a single Autonomous Exadata VM Cluster resource, but you must create
at least one before you can create any Autonomous Databases.
• Create an Autonomous Container Database
• View a List of Autonomous Container Databases
• View Details of an Autonomous Container Database
• Rotate CDB Encryption Key
• Change the Backup Retention Policy of an Autonomous Container Database
• Change the Maintenance Schedule of an Autonomous Container Database
• Restart an Autonomous Container Database
• Move an Autonomous Container Database to Another Compartment
• Terminate an Autonomous Container Database
• Using the API to Manage Autonomous Container Databases

Create an Autonomous Container Database

Follow these steps to create an autonomous container database on an Oracle Exadata
Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Container Databases.
3. Click Create Autonomous Container Database.
The Create Autonomous Container Database page is displayed.
4. Provide the following basic information:
• Compartment: Choose the compartment in which your autonomous container
database will be created.
• Display Name: Enter a user-friendly description or other information that helps
you easily identify the autonomous container database. The display name
does not have to be unique. Avoid entering confidential information.
5. Select the Autonomous Exadata VM Cluster you wish to use to create your
autonomous container database.

26-1
 Chapter 26
Create an Autonomous Container Database

6. Optionally, you can configure an automatic maintenance schedule.

a. Click Modify Maintenance.
b. To configure the maintenance schedule, select Specify a schedule.
Choose your preferred month, week, weekday, and start time for autonomous
container database maintenance.
• Under Week of the month, specify which week of the month maintenance
will take place. Weeks start on the 1st, 8th, 15th, and 22nd days of the
month, and have a duration of 7 days. Weeks start and end based on
calendar dates, not days of the week. Maintenance cannot be scheduled
for the fifth week of months that contain more than 28 days.
• Under Day of the week, specify the day of the week on which the
maintenance will occur.
• Under Start hour, specify the hour during which the maintenance run will
begin.
c. Click Save Changes.
7. Select a Backup Destination Type:
• Object Storage: Stores backups in an Oracle-managed object storage
container on Oracle Cloud Infrastructure. Optionally, you can use this field
to specify your corporate HTTP proxy. We recommend using an HTTP proxy
when possible for enhanced security.
• Network File System (NFS): Stores backups in one of your previously
defined backup destinations that uses Network File System (NFS) storage.
– Select a Backup Destination.
• Recovery Appliance: Stores backups in one of your previously defined
backup destinations that uses Oracle Zero Data Loss Recovery Appliance.
– Select a Backup Destination.
– Provide a unique name for the database.
– Provide a VPC user name and password.
8. The following Advanced Options are available:
• Backup retention period: Customize the retention period for automatic
backups. For Recovery Appliance, you cannot select the retention period.
• Encryption Key: Choose an encryption option, Encrypt using Oracle-
managed keys or Encrypt using customer-managed keys. The default
option is Oracle-managed keys.
To use customer-managed keys, select the Encrypt using customer-
managed keys option, select the compartment where you have created the
Key Store, and then select the Key Store. As part of the CDB creation, a new
wallet is created for the CDB in Oracle Key Vault (OKV). Also, a TDE Master
Key is generated for the CDB and added to the wallet in OKV.

26-2
 Chapter 26
View a List of Autonomous Container Databases

Note:

– Autonomous Container Databases and Autonomous Databases

only support 256-bit Hardware Security Module (HSM) Vault
keys.
– Validate OKV Key encryption post restart: OKV TDE Maser Key
is validated every time you start or restart your ACD. Start or
restart fails if the key is not validated. Work requests and life
cycle states indicate the reason for failure.
– View OKV keys post database restore: When you restore a
CDB, the master key associated with that backup is restored
as well.
– Enable CDB backups to capture wallet name: CDB backups
information about the wallet associated with the backup.
– OKV Wallet or TDE Master Key on CDB deletion: If you delete a
CDB, then the wallet and TDE Master Key remains in OKV and
will not be deleted.

• Tags: Optionally, you can apply tags. If you have permissions to create a
resource, you also have permissions to apply free-form tags to that resource.
To apply a defined tag, you must have permissions to use the tag namespace.
For more information about tagging, see Resource Tags. If you are not sure if
you should apply tags, skip this option (you can apply tags later) or ask your
administrator. Avoid entering confidential information.
9. Click Create Autonomous Container Database.

View a List of Autonomous Container Databases

There are two ways to view a list of autonomous container databases on an Oracle
Exadata Cloud@Customer system.
• View the List of Autonomous Container Databases in an Autonomous Exadata VM
Cluster
• View the List of Autonomous Container Databases in a Compartment

View the List of Autonomous Container Databases in an Autonomous

Exadata VM Cluster
Follow these steps to view a list of an autonomous container databases in a given
autonomous Exadata VM cluster on an Oracle Exadata Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Exadata VM Clusters.
3. Click the display name of the Autonomous Exadata VM Cluster that you interested
in.

26-3
 Chapter 26
View Details of an Autonomous Container Database

In the Autonomous Exadata VM Clusters Details page, a list of Autonomous

Container Databases is displayed under Resources.
You can also filter out to view Autonomous Container Databases in a particular
compartment. Under List Scope, select a compartment from the Compartment
drop-down list.

View the List of Autonomous Container Databases in a Compartment

Follow these steps to view a list of an autonomous container databases in a given
compartment on an Oracle Exadata Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Container Databases.
3. Under List Scope, select a compartment from the Compartment drop-down list.

View Details of an Autonomous Container Database

Follow these steps to view detailed information about an autonomous container
database on an Oracle Exadata Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Container Databases.
3. In the list of Autonomous Container Databases, click the display name of the
database you wish to view details.
On the Autonomous Container Database Details page encryption details are
displayed under Encryption.
If you have chosen customer-managed keys while creating the database, then you
will see a link to the Encryption Key Store and OKV Wallet Name.

Note:
OKV Wallet Name represents the name of the wallet in which keys for
this CDB are generated on the OKV.

Click the Key Store link to view details.

If you have chosen Oracle-managed keys while creating the database, then you
will not see the link to Encryption Key Store and OKV Wallet Name.

Rotate CDB Encryption Key

Follow these steps to rotate the TDE Master key. On key rotation, the ACD life cycle
goes through the regular updating state and returns to available.
You can rotate the TDE Master key as many times as you want. The new TDE Master
Key is stored in the same wallet in which the previous key was stored. Rotating the
TDE Master Key leads to the new key being generated in OKV and assigned to this
database. You can view all of the keys in OKV.

26-4
 Chapter 26
Change the Backup Retention Policy of an Autonomous Container Database

Note:
You can rotate both Oracle-managed and customer-managed encryption
keys.

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
2. Click Autonomous Container Databases.
3. In the list of Autonomous Container Databases, click the display name of the
database you wish to view details.
4. On the Autonomous Container Database Details page, click Rotate Encryption
Key.
5. On the Rotate Encryption Key dialog, click Rotate Encryption Key.

Change the Backup Retention Policy of an Autonomous

Container Database
Follow these steps to update the backup retention policy of an autonomous container
database on an Oracle Exadata Cloud@Customer system.

Note:
By default, database backups are retained for 30 days if you have chosen
Object Storage or NFS as a backup destination. You have the option of
retaining backups for 7, 15, 30, or 60 days. If you have chosen Local storage
as a backup destination, then by default, database backups are retained for
a maximum of 7 days. If you have chosen Recovery Appliance as a backup
destination, then you cannot update the backup retention policy.
The current backup retention policy for an Autonomous Container Database
is displayed on the Autonomous Container Database details page.

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
2. Click Autonomous Container Databases.
3. In the list of Autonomous Container Databases, click the display name of the
container database you are interested in.
4. On the Autonomous Container Database details page, under Backup, click the
Edit link in the Backup retention policy field.
5. Specify a backup retention period from the list of choices.
6. Click Update.

26-5
 Chapter 26
Change the Maintenance Schedule of an Autonomous Container Database

Change the Maintenance Schedule of an Autonomous

Container Database
Follow these steps to change the maintenance schedule of an autonomous container
database on an Oracle Exadata Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Container Databases.
3. In the list of Autonomous Container Databases, click the display name of the
container database you are interested in.
4. On the Autonomous Container Database details page, under Maintenance, click
the edit link in the Maintenance Details field.
5. In the Edit Automatic Maintenance dialog that opens, configure automatic
maintenance schedule.
• No preference: The system assigns a date and start time for container
database maintenance.
• Specify a schedule: Choose your preferred month, week, weekday, and start
time for container database maintenance.
6. Click Save Changes.

Restart an Autonomous Container Database

Follow these steps to restart an autonomous container database on an Oracle
Exadata Cloud@Customer system.
The restart of an autonomous container database occurs in a rolling fashion, first
stopping and starting one of the container database's database instances and then
stopping and starting its other database instance.

Note:
You cannot restart an autonomous container database if a backup is in
progress on any of its autonomous databases.

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
2. Click Autonomous Container Databases.
3. In the list of Autonomous Container Databases, click the display name of the
container database you are interested in.
4. On the Autonomous Container Database details page, click Restart.
5. In the confirmation dialog, type the name of the Autonomous Container Database.
6. Click Restart.

26-6
 Chapter 26
Move an Autonomous Container Database to Another Compartment

Move an Autonomous Container Database to Another

Compartment
Follow these steps to move an autonomous container database on an Oracle Exadata
Cloud@Customer system from one compartment to another compartment.

Note:

• To move an autonomous container database you must have the right to

manage it in its current compartment and in the compartment you are
moving it to.
• As soon as you move an autonomous container database to a different
compartment, the policies that govern the new compartment apply
immediately and affect access to the autonomous container database.
Therefore, both your and other Oracle Cloud users' access to it may
change, depending on the policies governing the user account's access
to resources. For example, a user may lose the ability to create
autonomous databases in the autonomous container database, given its
new compartment.

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
2. Click Autonomous Container Databases.
3. In the list of Autonomous Container Databases, click the display name of the
container database you wish to move.
4. Click Move Resource.
5. Select the new compartment.
6. Click Move Resource.

Terminate an Autonomous Container Database

Follow these steps to terminate an autonomous container database on an Oracle
Exadata Cloud@Customer system.

Note:
You must terminate all Autonomous Databases within a container database
before you can terminate the container database itself.

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
2. Click Autonomous Container Databases.

26-7
 Chapter 26
Using the API to Manage Autonomous Container Databases

3. In the list of Autonomous Container Databases, click the display name of the
infrastructure resource you are interested in.
4. Click Terminate.
5. In the confirmation dialog, type the name of the Autonomous Container Database,
and then click Terminate Autonomous Container Database.

Using the API to Manage Autonomous Container Databases

For information about using the API and signing requests, see REST APIs and
Security Credentials. For information about SDKs, see Software Development Kits and
Command Line Interface.
The following table lists the REST API endpoints to manage Autonomous Container
Databases.

Operation REST API Endpoint

Create an Autonomous Container Database CreateAutonomousContainerDatabase
View a list of Autonomous Container ListAutonomousContainerDatabases
Databases
View details of an Autonomous Container GetAutonomousContainerDatabase
Database
Change the backup retention policy of an UpdateAutonomousContainerDatabase
Autonomous Container Database
Change the maintenance schedule of an UpdateAutonomousContainerDatabase
Autonomous Container Database
Restart an Autonomous Container Database RestartAutonomousContainerDatabase
Move an Autonomous Container Database to ChangeAutonomousContainerDatabaseComp
another compartment artment
Terminate an Autonomous Container TerminateAutonomousContainerDatabase
Database

26-8
27
Managing Autonomous Databases
An Autonomous Database resource is a user database. When you create an
Autonomous Database, you choose the Autonomous Container Database for it and
you specify "Data Warehouse" or "Transaction Processing" as its workload type to
create an Autonomous Data Warehouse database or an Autonomous Transaction
Processing database.
You can create up to 400 Autonomous Databases in each Autonomous Container
Database, depending on the capacity of your Exadata Infrastructure hardware, as
described in Available Exadata Infrastructure Hardware Shapes.
• Create an Autonomous Database
• Manage Access Control List of an Autonomous Database
• View a List of Autonomous Databases
• View Details of an Autonomous Database
• Rotate ADB Encryption Key
• Set the Password of an Autonomous Database's ADMIN User
• Scale the CPU Core Count or Storage of an Autonomous Database
• Enable or Disable Auto Scaling for an Autonomous Database
• Move an Autonomous Database to Another Compartment
• Stop or Start an Autonomous Database
• Restart an Autonomous Database
• Back Up an Autonomous Database Manually
• Restore an Autonomous Database
• Clone an Autonomous Database
• Terminate an Autonomous Database
• Using the API to Manage Autonomous Databases
• Monitor Performance with Autonomous Database Metrics

Create an Autonomous Database

Follow these steps to create an autonomous database on an Oracle Exadata
Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Databases.
3. Click Create Autonomous Database.
4. In the Create Autonomous Database dialog, enter the following:

27-1
 Chapter 27
Create an Autonomous Database

Basic Database Information

• Compartment: Select the compartment of the Autonomous Database.
• Display Name: A user-friendly description or other information that helps you
easily identify the resource. The display name does not have to be unique.
Avoid entering confidential information.
• Database Name: The database name must consist of letters and numbers
only, starting with a letter. The maximum length is 14 characters. Avoid
entering confidential information.
Workload Type
Select the desired workload type. See About Autonomous Database for
information about each workload type.
Autonomous Container Database: Select an Autonomous Container Database.
Compartment: Specify the compartment containing the Autonomous Container
Database you wish to use.
Database CPU Core Count and Storage Configuration
• OCPU Count: The total number of cores available to all database within the
Autonomous Exadata Infrastructure depends on the infrastructure shape and
what is already allocated to other Autonomous Databases.
Deselect Auto Scaling to disable auto scaling. By default auto scaling is
enabled to allow the system to automatically use up to three times more CPU
and IO resources to meet workload demand.
• Storage (TB): Specify the storage you wish to make available to your
Autonomous Database, in terabytes. The available storage depends on the
infrastructure shape and what is already consumed by other Autonomous
Databases.
Administrator Credentials
Set the password for the Autonomous Database Admin user by entering a
password that meets the following criteria. You use this password when accessing
the Autonomous Database service console and when using an SQL client tool.
• Contains from 12 to 30 characters
• Contains at least one lowercase letter
• Contains at least one uppercase letter
• Contains at least one number
• Does not contain the double quotation mark (")
• Does not contain the string "admin", regardless of casing
Configure network access
You can optionally create an ACL during database provisioning, or at any time
thereafter.
Select the Enable database level access control checkbox.
Click Access Control Rule.

27-2
 Chapter 27
Manage Access Control List of an Autonomous Database

Note:
The database-level access control will be enabled without any IP
addresses in the access control list. Enabling an access control list with
an empty list of IP addresses makes the database inaccessible to all
clients

Specify the following types of addresses in your list by using the IP notation type
drop-down selector:
• IP Address allows you to specify one or more individual public IP addresses.
Use commas to separate your addresses in the input field.
• CIDR Block allows you to specify one or more ranges of public IP addresses
using CIDR notation. Use commas to separate your CIDR block entries in the
input field.
Advanced Options
Encryption Key: ADB inherits encryption settings from the parent ACD. If the
parent ACD is configured for customer-managed OKV based encryption, then the
child ADB will also have TDE Master Key generated and managed in the same
OKV wallet used to store ACD master keys. Additionally, any backups taken on
the Autonomous Database will have the OKV based key associated with it.
Tags: Optionally, you can apply tags. If you have permissions to create a resource,
you also have permissions to apply free-form tags to that resource. To apply a
defined tag, you must have permissions to use the tag namespace. For more
information about tagging, see Resource Tags. If you are not sure if you should
apply tags, skip this option (you can apply tags later) or ask your administrator.
Avoid entering confidential information.
5. Click Create Autonomous Database.

Note:
The following naming restrictions apply to Autonomous Transaction
Processing and Autonomous Data Warehouse databases:
• Names associated with databases terminated within the last 60 days
cannot be used when creating a new database.
• A database name cannot be used concurrently for both an
Autonomous Data Warehouse and an Autonomous Transaction
Processing database.

Manage Access Control List of an Autonomous Database

Enabling an access control list with an empty list of IP addresses makes the database
inaccessible.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.

27-3
 Chapter 27
View a List of Autonomous Databases

2. Choose your Compartment.

3. In the list of Autonomous Databases, click the display name of the database you
want to administer.
4. Under Network in the database details, find the Access Control List field and
click Edit to enable or disable your database-level access control and make
changes to the ACL rules.

Note:
Autonomous Data Guard enabled Automonous databases:
• You can only view ACLs for standby databases.
• You can reset ACL for both the primary and standby databases from
the primary database details page. You cannot configure ACL from
the standby database details page.

5. In the Access Control List dialog, add or modify entries, as applicable.

If you are editing an ACL, the ACL's existing entries display in the Access Control
List dialog. Do not overwrite the existing values unless you intend to replace one
or more entries. To add new ACL entries, click + Access Control Rule.
You can specify the following types of addresses in your list by using the IP
notation type drop-down selector:
• IP Address allows you to specify one or more individual public IP addresses.
Use commas to separate your addresses in the input field.
• CIDR Block allows you to specify one or more ranges of public IP addresses
using CIDR notation. Use commas to separate your CIDR block entries in the
input field.
Click + Access Control Rule to add additional access rules to your list.
To remove an access control rule, simply delete the entry from the list. Deleting all
access control rules from the ACL will render the database inaccessible because
the allow list is empty.
To disable the database-level access control configuration, clear the Enable
database level access control checkbox. Once ACL is disabled and the
configuration is saved, all the access control rules are removed from the ACL
and no longer applicable.
6. Click Save Changes.
If the Lifecycle State is Available when you click Save, the Lifecycle State
changes to Updating until the ACL update is complete. The database is still up
and accessible, there is no downtime. When the update is complete the Lifecycle
State returns to Available and the network ACL rules from the access control list
are in effect.

View a List of Autonomous Databases

Follow these steps to view a list of autonomous databases on an Oracle Exadata
Cloud@Customer system.

27-4
 Chapter 27
View Details of an Autonomous Database

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
2. Click Autonomous Databases.

View Details of an Autonomous Database

Follow these steps to view detailed information about an autonomous database on an
Oracle Exadata Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Databases, click the display name of the database you
wish to view details.
On the Autonomous Container Database Details page encryption details are
displayed under Encryption.
If you have chosen customer-managed keys while creating the database, then you
will see a link to the Encryption Key Store and OKV Wallet Name. Click the Key
Store link to view details.
If you have chosen Oracle-managed keys while creating the database, then you
will not see the link to Encryption Key Store and OKV Wallet Name.

Rotate ADB Encryption Key

Follow these steps to rotate the TDE Master key. On key rotation, the ADB life cycle
goes through the regular updating state and returns to available.
You can rotate the TDE Master key as many times as you want. The new TDE Master
Key is stored in the same wallet in which the previous key was stored. Rotating the
TDE Master Key leads to the new key being generated in OKV and assigned to this
database. You can view all of the keys in OKV.

Note:
You can rotate both Oracle-managed and customer-managed encryption
keys.

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Databases, click the display name of the database you
wish to view details.
4. On the Autonomous Database Details page, from the More Actions drop-down
list, select Rotate Encryption Key.
5. On the Rotate Encryption Key dialog, click Rotate Encryption Key.

27-5
 Chapter 27
Set the Password of an Autonomous Database's ADMIN User

Set the Password of an Autonomous Database's ADMIN

User
Follow these steps to set the ADMIN database user's password for an autonomous
database on an Oracle Exadata Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Databases, click the display name of the database you
wish to administer.
4. From the More Actions drop-down list, select Admin Password.
The Admin Password dialog opens.
5. Enter a password for the Autonomous Database.
The password must meet the following criteria:
• Contains from 12 to 30 characters
• Contains at least one lowercase letter
• Contains at least one uppercase letter
• Contains at least one number
• Does not contain the double quotation mark (")
• Does not contain the string "admin", regardless of case
• Is not one of the last four passwords used for the database
• Is not a password you previously set within the last 24 hours
6. Enter the password again in the Confirm Password field.
7. Click Update.

Scale the CPU Core Count or Storage of an Autonomous

Database
Follow these steps to scale the CPU core count or storage an autonomous database
on an Oracle Exadata Cloud@Customer system up or down.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Databases, click the display name of the database you
wish to view details.
4. Click Scale Up/Down.
5. Enter a new value for CPU Core Count or Storage between 1 and 128. The
number you enter represents the desired total (final) value for your database's
CPU core count or storage.

27-6
 Chapter 27
Enable or Disable Auto Scaling for an Autonomous Database

The maximum number of CPU Core Count or Storage depends on the

infrastructure shape and what is already consumed by other Autonomous
Databases.
6. Click Update.
Related Topics
• Service Limits

Enable or Disable Auto Scaling for an Autonomous

Database
Oracle Autonomous Database on Oracle Exadata Cloud@Customer systems provides
an auto scaling feature that automatically increases the number of cores an
automonomous database during periods of increased demand and, as demand returns
to normal, automatically decreases the number of cores down to the databases's base
number.
Note the following points regarding the auto scaling feature:
• With auto scaling enabled, the database can use up to three times more CPU and
IO resources than specified by the number of OCPUs currently shown in the Scale
Up/Down dialog.
• If auto scaling is disabled while more CPU cores are in use than the database's
currently assigned number of cores, then Autonomous Database scales the
number of CPU cores in use down to the assigned number.
• Enabling auto scaling does not change the concurrency and parallelism settings
for the predefined services.
Follow these steps to enable or disable auto scaling for an autonomous database.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Databases, click the display name of the database you
wish to view details.
4. Click Scale Up/Down.
5. Check Auto Scaling to enable the auto scaling feature, or uncheck Auto Scaling
to disable the feature.
6. Click Update.

Move an Autonomous Database to Another Compartment

Follow these steps to move an autonomous database on an Oracle Exadata
Cloud@Customer system from one compartment to another compartment.

27-7
 Chapter 27
Stop or Start an Autonomous Database

Note:

• To move an autonomous database you must have the right to manage it

in its current compartment and in the compartment you are moving it to.
• As soon as you move an autonomous database to a different
compartment, the policies that govern the new compartment apply
immediately and affect access to the autonomous database. Therefore,
both your and other Oracle Cloud users' access to it may change,
depending on the policies governing the user account's access to
resources. For example, a user may lose the ability to manage the
autonomous databae, given its new compartment.

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Databases, click the display name of the database you
wish to move.
4. From the More Actions drop-down list, select Move Resource.
5. Select the new compartment.
6. Click Move Resource.

Stop or Start an Autonomous Database

Follow these steps to stop or start an autonomous database on an Oracle Exadata
Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Databases, click the display name of the database you
wish to view details.
4. Click Stop (or Start).
When you stop your Autonomous Database, billing stops for CPU usage. Billing
for storage continues when the database is stopped.
5. Confirm that you want to stop or start your Autonomous Database in the
confirmation dialog.

Note:
Stopping your database has the following consequences:
• On-going transactions are rolled back.
• You will not be able to connect to your database using database clients
or tools.

27-8
 Chapter 27
Restart an Autonomous Database

Restart an Autonomous Database

To resolve some autonomous database issues with minimal downtime on Exadata
Cloud@Customer systems, you can restart the database.
Restarting an autonomous database on an Oracle Exadata Cloud@Customer system
is equivalent to manually stopping and then starting the database. Using restart allows
you to minimize downtime and requires only a single action.
Follow these steps to restart an autonomous database.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Databases, click the display name of the database you
wish to restart.
4. Click Restart.
5. Confirm that you want to restart your Autonomous Database in the confirmation
dialog.
The system stops and then immediately starts your database.

Back Up an Autonomous Database Manually

Oracle Autonomous Database automatically backs up autonomous databases on an
Oracle Exadata Cloud@Customer system. In addition, you can manually back up an
autonomous database should the need arise.

Note:
During the backup operation, your autonomous database remains available.
However, lifecycle management operations such as stopping it, scaling it, or
terminating it are disabled.

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Databases, click the display name of the database you
wish to back up.
4. On the Details page, under Resources, click Backups.
5. Click Create Manual Backup.
6. In the Create Manual Backup dialog, enter a name for your backup. Avoid entering
confidential information.
7. Click Update.
The backup operation begins. This operation may take several hours to complete,
depending on the size of the database.

27-9
 Chapter 27
Restore an Autonomous Database

Optionally, you can check the state of your backup in the list of backups on the
database details page. For some states, an information icon is displayed to provide
additional details regarding the state or ongoing operations like deletions. The backup
has one of the following states:
• Creating
• Active
• Deleting
• Deleted
• Failed

Restore an Autonomous Database

You can use any existing manual or automatic backup to restore and recover an
autonomous database on an Oracle Exadata Cloud@Customer system, or you can
restore and recover the database to any point in time during the retention period of its
automatic backups.

Note:
Restoring an autonomous database puts the database in the unavailable
state during the restore operation. You cannot connect to a database in this
state. The only lifecycle management operation supported in the unavailable
state is terminate.

• Restore from a Backup

• Restore to a Point in Time

Restore from a Backup

Follow these steps to restore an autonomous database on an Oracle Exadata
Cloud@Customer system from a specific backup.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Databases, click the display name of the database you
want to clone.
4. From the More Actions drop-down list, select Restore.
5. Specify the date range for a list of backups to display.
6. Select the backup.
7. Click Restore.

Restore to a Point in Time

Follow these steps to restore an autonomous database on an Oracle Exadata
Cloud@Customer system to a specific point in time.

27-10
 Chapter 27
Clone an Autonomous Database

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Databases, click the display name of the database you
want to restore.
4. From the More Actions drop-down list, select Restore.
5. Click Specify Timestamp.
6. Enter a timestamp.
Your Autonomous Database decides which backup to use for faster recovery. The
timestamp input allows you to specify precision to the seconds level (YYYY-MM-DD
HH:MM:SS GMT).
7. Click Restore.

Clone an Autonomous Database

Follow these steps to clone an autonomous database on an Oracle Exadata
Cloud@Customer system.
You can use the cloning feature to create a point-in-time copy of your Autonomous
Database for purposes such as testing, development, or analytics. To clone only the
database schema of your source database, choose the metadata clone option.
Clone Types
The clone feature offers the following two types of Autonomous Database clones:
• The full-clone option creates a database that includes the metadata and data from
the source database.
• The metadata-clone option creates a database that includes only the metadata
from the source database.
Steps
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Databases, click the display name of the database you
want to clone.
4. From the More Actions drop-down list, select Create Clone.
5. On the Clone Autonomous Database page, provide the following information:
In the Clone Type section, select the type of clone you want to create. Choose
either Full Clone or Metadata Clone.
Provide basic information for the Autonomous Database.
• Choose a compartment: Your current compartment is the default selection
but you can select a different compartment in which to create the clone from
the drop-down list.
• Source database name: The name of the source database displays in the
read-only Source database name field.

27-11
 Chapter 27
Clone an Autonomous Database

• Display name: Enter a description or other information to identify the

database clone. You can change the display name any time and it does not
have to be unique. Avoid entering confidential information.
• Database name: Enter a database name for the clone that contains only
letters and numbers, begins with a letter, and does not exceed 14 characters.
Avoid entering confidential information.
• Choose autonomous container database in compartment: You can choose
to create the database clone in the same compartment and container
database as the source database, or you can choose a different compartment
by clicking CHANGE COMPARTMENT, and a different container database by
choosing one from the drop-down list.
Configure the database.
• OCPU Count: You can enable up to the number of cores available for your
cloned Autonomous Database.
• Storage (TB): Specify the amount of storage, in terabytes, that you want
to make available to your cloned Autonomous Database, and it depends on
the storage available to use. For full clones, the size of the source database
determines the minimum amount of storage you can make available.
• Auto scaling: Enabling auto scaling allows Oracle to use upto 3 times the
number of OCPUs for processing workload if required.
Create administrator credentials.
Set the password for the Autonomous Database administrator user by entering a
password that meets the following criteria.
• Password cannot be one of the three most recently used passwords of the
source database
• Between 12 and 30 characters long
• Contains at least one lowercase letter
• Contains at least one uppercase letter
• Contains at least one number
• Does not contain the double quotation mark (")
• Does not contain the string "admin", regardless of casing
Use this password when accessing the service console and when using a SQL
client tool.
Access control list: Add or modify entries, as applicable.
Access control list will automatically initialize with the same settings configured on
the source Autonomous Database from which the clone is being created. You can
change the access control list to enable or disable database level access control
or add or modify entries to the access control list.
Advanced Options:
Encryption Key: ADB inherits encryption settings from the parent ACD. If the
parent ACD is configured for customer-managed OKV based encryption, then the
child ADB will also have TDE Master Key generated and managed in the same
OKV wallet used to store ACD master keys.
Additionally, any backups taken on the Autonomous Database will have the vault
key associated with it.

27-12
 Chapter 27
Terminate an Autonomous Database

Tags: Optionally, you can apply tags. If you have permissions to create a resource,
you also have permissions to apply free-form tags to that resource. To apply a
defined tag, you must have permissions to use the tag namespace. For more
information about tagging, see Resource Tags. If you are not sure if you should
apply tags, skip this option (you can apply tags later) or ask your administrator.
Avoid entering confidential information.
6. Click Clone Autonomous Database.
The Console displays the details page for the new clone of your database and the
service begins provisioning the Autonomous Database. Note the following:
• The new clone displays the Provisioning lifecycle state until the provisioning
process completes.
• The source database remains in the Available lifecycle state.
• Backups associated with the source database are not cloned for either the full-
clone or the metadata-clone option.

Terminate an Autonomous Database

Follow these steps to terminate an Autonomous Database on an Oracle Exadata
Cloud@Customer system.

WARNING:
Terminating an Autonomous Database permanently deletes it. The database
data will be lost when the system is terminated. However, automatic backups
are not deleted if you have chosen Recovery Appliance or NFS as a backup
destination. You can delete automatic backups directly from the Recovery
Appliance or NFS.

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Databases, click the display name of the database you
wish to terminate.
4. From the More Actions drop-down list, select Terminate.
5. Confirm that you wish to terminate your Autonomous Database in the confirmation
dialog.
6. Click Terminate Autonomous Database.

Using the API to Manage Autonomous Databases

For information about using the API and signing requests, see REST APIs and
Security Credentials. For information about SDKs, see Software Development Kits and
Command Line Interface.
The following table lists the REST API endpoints to manage Autonomous Databases.

27-13
 Chapter 27
Monitor Performance with Autonomous Database Metrics

Operation REST API Endpoint

Create an Autonomous Database CreateAutonomousDatabase
View a list of Autonomous Databases ListAutonomousDatabases
View details of an Autonomous Database GetAutonomousDatabase
Set the password of an Autonomous UpdateAutonomousDatabase
Database's ADMIN user
Scale the CPU core count or storage of an UpdateAutonomousDatabase
Autonomous Database
Enable or disable auto scaling for an UpdateAutonomousDatabase
Autonomous Database
Move an Autonomous Database to another ChangeAutonomousDatabaseCompartment
compartment
Stop or start an Autonomous Database StartAutonomousDatabase
Stop or start an Autonomous Database StopAutonomousDatabase
Restart an Autonomous Database RestartAutonomousDatabase
Back up an Autonomous Database manually CreateAutonomousDatabaseBackup
View the list of Autonomous Database ListAutonomousDatabaseBackups
backups
Restore an Autonomous Database RestoreAutonomousDatabase
Clone an Autonomous Database CreateAutonomousDatabase
Terminate an Autonomous Database DeleteAutonomousDatabase

Monitor Performance with Autonomous Database Metrics

You can monitor the health, capacity, and performance of your Autonomous
Databases with metrics, alarms, and notifications. You can use Oracle Cloud
Infrastructure console or Monitoring APIs to view metrics.
• View Top Six Metrics for an Autonomous Database
Displays the top six metrics that are available in the metrics section on the
Autonomous Database details page.
• View Aggregated Metrics for Autonomous Databases in a Compartment
Learn to view aggregated metrics for Autonomous Databases in a compartment.
• Autonomous Database Metrics and Dimensions
You can limit the instances where you see metrics with dimensions. The available
dimensions include: workload type, instance display name, region, and the
instance OCID.

View Top Six Metrics for an Autonomous Database

Displays the top six metrics that are available in the metrics section on the
Autonomous Database details page.
To view metrics you must have the required access as specified in an Oracle Cloud
Infrastructure policy (whether you're using the Console, the REST API, or other tools).
See Getting Started with Policies for information on policies.

27-14
 Chapter 27
Monitor Performance with Autonomous Database Metrics

Perform the following prerequisite steps as necessary:

• Open the Oracle Cloud Infrastructure console by clicking the hamburger menu
next to Oracle Cloud.
• From the Oracle Cloud Infrastructure left navigation list click Oracle Databases >
Exadata Cloud@Customer.
• On the Autonomous Databases page select an Autonomous Database from the
links under the Name column.
To view metrics for an Autonomous Database instance:
1. On the Autonomous Database Details page, under Resources, click Metrics.
2. There is a chart for each metric. In each chart, you can select the Interval and
Statistic or use the default values.
3. To create an alarm on a metric, click Options and select Create an Alarm on this
Query.
See Managing Alarms for information on setting and using alarms.
For more information about metrics see Database Metrics.
You can also use the Monitoring API to view metrics. See Monitoring API for more
information.

View Aggregated Metrics for Autonomous Databases in a

Compartment
Learn to view aggregated metrics for Autonomous Databases in a compartment.
To view metrics you must have the required access as specified in an Oracle Cloud
Infrastructure policy (whether you're using the Console, the REST API, or other tool).
See Getting Started with Policies for information on policies
Perform the following prerequisite steps as necessary:
• Open the Oracle Cloud Infrastructure console by clicking the hamburger menu
next to Oracle Cloud.
• From the left navigation list click Solutions and Platform > Monitoring > Service
Metrics.
To use the metrics service to view Autonomous Database metrics:
1. On the Service Metrics page, under Compartment select your compartment.
2. On the Service Metrics page, under Metric Namespace select
oci_autonomous_database.
3. If there are multiple Autonomous Databases in the compartment you can show
metrics aggregated across the Autonomous Databases by selecting Aggregate
Metric Streams.
4. If you want to limit the metrics you see, next to Dimensions click Add (click Edit if
you have already added dimensions).
a. In the Dimension Name field select a dimension.
b. In the Dimension Value field select a value.
c. Click Done.

27-15
 Chapter 27
Monitor Performance with Autonomous Database Metrics

d. In the Edit dimensions dialog click +Additional Dimension to add an additional

dimension. Click x to remove a dimension.
To create an alarm on a specific metric, click Options and select Create an Alarm on
this Query. See Managing Alarms for information on setting and using alarms.

Autonomous Database Metrics and Dimensions

You can limit the instances where you see metrics with dimensions. The available
dimensions include: workload type, instance display name, region, and the instance
OCID.
Use dimensions by selecting values in the Oracle Cloud Infrastructure Console
Service Metrics page or by setting dimension values with the API. See View
Aggregated Metrics for Autonomous Databases in a Compartment to view metrics
and to select metric dimensions.
See Database Metrics for a list of the database metrics and dimensions.

27-16
28
Connecting to Autonomous Databases
Applications and tools connect to an autonomous database using Oracle Net Services
(also known as SQL*Net). Oracle Net Services enables a network session from a
client application to an Oracle Database server.
When a network session is established, Oracle Net Services acts as the data courier
for both the client application and the database. It is responsible for establishing and
maintaining the connection between the client application and the database, as well
as exchanging messages between them. It supports a variety of connection types to
autonomous databases, including:
• Oracle Call Interface (OCI), which is used by many applications written in
C language. Examples include Oracle utilities such as Oracle SQL*Plus,
SQL*Loader, and Oracle Data Pump.
• ODBC drivers, which can be used by applications running on Microsoft Windows,
are layered over Oracle Call Interface (OCI).
• JDBC OCI, which can be used by Java language applications, is layered over
Oracle Call Interface (OCI). The Oracle SQLcl command-line interface uses JDBC
OCI.
• JDBC Thin Driver, also for Java applications, is a pure Java driver. Oracle SQL
Developer supports JDBC Thin Driver connections.
Third-party products and custom applications can use any of these connection types.
Oracle Autonomous Database provides several pairs of database services to use
when connecting to autonomous databases. In each pair, one of the pair provides
a secure TCP (TCPS) connection using the TLS protocol, and the other provides a
TCP connection. In all other respects, the two members of a pair are the same. To
ensure security of data in transit, Oracle strongly recommends that you use a secure
connection, even if the database is only available through a private network. If you are
familiar with using an Oracle Database within your own data center, you may not have
previously used these secure connections.
To provide the secure TCPS connection, certification authentication uses an encrypted
key stored in a wallet on both the client (where the application is running) and the
server (where the autonomous database is running). The key on the client must match
the key on the server to make a connection. A wallet contains a collection of files,
including the key and other information needed to connect to your database . All
communications between the client and the server are encrypted.
• Download the Wallet for an Autonomous Database
• Get the APEX and SQL Developer Web URLs for an Autonomous Database

Download the Wallet for an Autonomous Database

Follow these steps to download the wallet for an autonomous database on an Oracle
Exadata Cloud@Customer system.

28-1
 Chapter 28
Download the Wallet for an Autonomous Database

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Databases, click the display name of the database
whose wallet you wish to download.
4. Click DB Connections.
5. Select the DB Connection option.
6. In the Download Wallet dialog, enter a wallet password in the Password field and
confirm the password in the Confirm Password field.
The password must be at least 8 characters long and must include at least 1 letter
and either 1 numeric character or 1 special character.

Note:
This password protects the downloaded Client Credentials wallet. This
wallet is not the same as the Transparent Data Encryption (TDE) wallet
for the database; therefore, use a different password to protect the Client
Credentials wallet.

7. Click Download to save the client security credentials zip file.

By default the filename is Wallet_databasename.zip. You can save this file as any
filename you want.
You must protect this file to prevent unauthorized database access.
The zip file includes the following:
• tnsnames.ora and sqlnet.ora: Network configuration files storing connect
descriptors and SQL*Net client side configuration.
• cwallet.ora and ewallet.p12: Auto-open SSO wallet and PKCS12 file. PKCS12
file is protected by the wallet password provided in the UI.
• keystore.jks and truststore.jks: Java keystore and truststore files. They are
protected by the wallet password provided while downloading the wallet.
• ojdbc.properties: Contains the wallet related connection property required for
JDBC connection. This should be in the same path as tnsnames.ora.

Note:
Wallet files, along with the Database user ID and password, provide access
to data in your autonomous database. Store wallet files in a secure location.
Share wallet files only with authorized users. If wallet files are transmitted
in a way that might be accessed by unauthorized users (for example, over
public email), transmit the wallet password separately and securely.

28-2
 Chapter 28
Get the APEX and SQL Developer Web URLs for an Autonomous Database

Get the APEX and SQL Developer Web URLs for an

Autonomous Database
Follow these steps to get the URLs to use to connect to APEX (Oracle Application
Express) and Oracle SQL Developer Web in an autonomous database on an Oracle
Exadata Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Databases, click the display name of the database
whose APEX and SQL URLs you wish to get.
4. Click DB Connections.
5. Select the Application Connection option.
6. Application URLs are displayed in plain text in the Application URL field. Copy
the URL string using the Copy link.
Paste the URL into a browser running on a system with network access to your
autonomous database.

28-3
29
Patching ADB on Exadata
Cloud@Customer Infrastructure
• Overview of ADB on Exadata Cloud@Customer Infrastructure Patching
• Specifying When Maintenance Can Occur
• Specifying What Kind of Patches to Apply

Overview of ADB on Exadata Cloud@Customer

Infrastructure Patching
ADB-Dedicated maintenance involves patching Exadata Infrastructure(EI)
Autonomous VM Cluster, and Autonomous Container Database (ACD).
• Autonomous Exadata Infrastructure/Exadata Infrastructure (EI): IB Switches,
Storage cells, Dom0 operating system, and so on.
• Autonomous VM clusters (AVM): Grid Infrastructure (GI), and Guest VM
operating system patching.
• Autonomous Container Database (ACD): Oracle Database patching.
The patching is done every quarter. Although there is no order dependency between
EI/AVM/ACD, it is preferred to patch in the sequence EI, AVM, and then ACD.
Oracle schedules and performs all patching and other maintenance operations on
all dedicated Exadata infrastructure resources. You can also specify when such
maintenance operations can occur, and what kind of patching is performed.

Specifying When Maintenance Can Occur

In general, Oracle schedules and performs entire fleet maintenance spread throughout
each quarter. You can let Oracle handle maintenance scheduling, or you can set a
specific maintenance window when Oracle can begin maintenance operations. You
set this maintenance window at the Autonomous Exadata Infrastructure level, and it
applies to all Autonomous Container Databases and Autonomous Databases created
in the Autonomous Exadata Infrastructure resource as well as to the resource itself.
Additionally, you can set a maintenance window for each individual Autonomous
Container Database, thereby setting the window for all of its contained Autonomous
Databases.

29-1
 Chapter 29
Specifying What Kind of Patches to Apply

Note:
Oracle recommends that you set a maintenance window for at least Exadata
Infrastructure resources. Doing so will prevent maintenance operations from
occurring at times that would be disruptive to regular database operations.

You can set the maintenance window for an Exadata Infrastructure and Autonomous
Container Database resources when you create them or you can set or change it later.
Once a maintenance activity is scheduled based on the maintenance window you set,
you can manage the actual timing of the activity, even to the point of changing the
patch version, applying the patch immediately, or skipping the activity.
Related Topics
• Using the Console to Create Infrastructure
To create your Oracle Exadata Cloud@Customer infrastructure, be prepared to
provide values for the fields required for configuring the infrastructure.
• Maintaining an Exadata Cloud@Customer System
Learn how to perform patching operations on Exadata Cloud@Customer
infrastructure.
• Create an Autonomous Container Database
• Change the Maintenance Schedule of an Autonomous Container Database

Specifying What Kind of Patches to Apply

One standard maintenance operation is to apply database software patches to your
Autonomous Container Databases and, by extension, the Autonomous Databases
created in them. By default, Oracle applies quarterly Release Updates (RUs).
Currently, the Release Update Revision (RUR) maintenance type is not supported.
To help you decide whether to have Oracle apply RUs or RURs to a given
Autonomous Container Database, see My Oracle Support Note 2285040.1.
Related Topics
• https://support.oracle.com/epmos/faces/DocContentDisplay?id=2285040.1

29-2
30
Using Autonomous Data Guard with
Autonomous Database on Exadata
Cloud@Customer
Learn how to enable a Data Guard association between databases, change the role
of a database in a Data Guard association using either a switchover or a failover
operation, and reinstate a failed database.
• Enabling Autonomous Data Guard on an Autonomous Container Database
When you enable Data Guard, a separate Data Guard association is created for
the primary and the standby database.
• Enabling Autonomous Data Guard on an Autonomous Database
Autonomous Databases inherit Data Guard settings from the parent container
database.
• Maintenance Scheduling and Patching Data Guard Enabled Autonomous
Container Database
Follow these steps to change the maintenance schedule of a Data Guard enabled
Autonomous Container Database.

Enabling Autonomous Data Guard on an Autonomous

Container Database
When you enable Data Guard, a separate Data Guard association is created for the
primary and the standby database.

Note:
Replication of data happens only over the client network.

• Create an Autonomous Data Guard Enabled Autonomous Container Database

Follow these steps to create an Autonomous Data Guard Enabled Autonomous
Container Database on an Oracle Exadata Cloud@Customer system.
• View Details of a Data Guard Enabled Primary or Standby Autonomous Container
Database
Follow these steps to view detailed information about a primary or standby
Autonomous Container Database on an Oracle Exadata Cloud@Customer
system.
• Perform a Failover to Standby Autonomous Container Database
Initiate a failover operation by using the Data Guard association of the standby
database.

30-1
 Chapter 30
Enabling Autonomous Data Guard on an Autonomous Container Database

• Perform a Switchover to Standby or Primary Autonomous Container Database

Initiate a switchover operation by using the Data Guard association of the primary
database.
• Reinstate Data Guard Enabled Standby Autonomous Container Database
After you fail over a primary database to its standby, the standby assumes the
primary role and the old primary is identified as a disabled standby.
• Terminate a Data Guard Enabled Primary Autonomous Container Database
Follow these steps to terminate an autonomous container database on an Oracle
Exadata Cloud@Customer system.
• Terminate a Data Guard Enabled Standby Autonomous Container Database
Follow these steps to terminate an autonomous container database on an Oracle
Exadata Cloud@Customer system.
• Operations Performed Using the APIs
Learn how to use the API to manage Autonomous Data Guard Enabled
Autonomous Container Database.
Related Topics
• Network Requirements for Oracle Exadata Cloud@Customer
To provide secure and reliable network connectivity for different application and
management functions, Exadata Cloud@Customer uses different networks.

Create an Autonomous Data Guard Enabled Autonomous Container

Database
Follow these steps to create an Autonomous Data Guard Enabled Autonomous
Container Database on an Oracle Exadata Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Container Databases.
3. Click Create Autonomous Container Database.
The Create Autonomous Container Database page is displayed.
4. Provide the following basic information:
• Compartment: Choose the compartment in which your autonomous container
database will be created.
• Display Name: Enter a user-friendly description or other information that helps
you easily identify the autonomous container database. The display name
does not have to be unique. Avoid entering confidential information.
5. Select the Autonomous Exadata VM Cluster you wish to use to create your
autonomous container database.
6. Under Configure Autonomous Data Guard, select the Enable Autonomous
Data Guard checkbox and provide the following details.
• Peer Autonomous Container Database Compartment: Choose the
compartment in which your standby autonomous container database will be
created.

30-2
 Chapter 30
Enabling Autonomous Data Guard on an Autonomous Container Database

• Display Name: Enter a user-friendly description or other information that

helps you easily identify the autonomous container database. The display
name does not have to be unique. Avoid entering confidential information.
• Select peer Autonomous Exadata VM Cluster: Specify the following values
for the standby:
– Peer Region: Currently, the peer region is auto-populated and you
cannot change it. The primary and secondary databases must run on two
Autonomous Exadata VM Cluster on two separate Exadata infrastructures
even if they are in the same region.
– Peer Exadata: Select the Exadata Cloud@Customer infrastructure
where the standby database will be created. Click the CHANGE
COMPARTMENT hyperlink to choose a compartment.
– Peer Autonomous Exadata VM Cluster: Select the Autonomous VM
Cluster in which the standby ACD must be created. Click the CHANGE
COMPARTMENT hyperlink to choose a compartment.
• Data Protection Mode: Specify the protection mode used for this Data Guard
association.
– Maximum Performance: Provides the highest level of data protection that
is possible without compromising the availability of a primary database.
– Maximum Availability: Provides the highest level of data protection that
is possible without affecting the performance of a primary database. This
is the default protection mode.
See Oracle Data Guard Concepts and Administration for more information
about protection modes.
7. Optionally, you can configure an automatic maintenance schedule.
a. Click Modify Schedule.
b. Optionally, you can change the maintenance patch type. Select either
Release Update (RU) or Release Update Revision (RUR).

Note:
You can set maintenance type only for primary.

Release Update (RU): Autonomous Database installs only the most current
release update.
Release Update Revision (RUR): Autonomous Database installs the release
update plus additional fixes.
For more information, see "management operations.
c. To configure the maintenance schedule, select Specify a schedule.
Choose your preferred month, week, weekday, and start time for autonomous
container database maintenance.
• Under Week of the month, specify which week of the month maintenance
will take place. Weeks start on the 1st, 8th, 15th, and 22nd days of the
month, and have a duration of 7 days. Weeks start and end based on

30-3
 Chapter 30
Enabling Autonomous Data Guard on an Autonomous Container Database

calendar dates, not days of the week. Maintenance cannot be scheduled

for the fifth week of months that contain more than 28 days.
• Under Day of the week, specify the day of the week on which the
maintenance will occur.
• Under Start hour, specify the hour during which the maintenance run will
begin.
d. Click Save Changes.
8. Select a Backup Destination Type:
• Object Storage: Stores backups in an Oracle-managed object storage
container on Oracle Cloud Infrastructure. Optionally, you can use this field
to specify your corporate HTTP proxy. We recommend using an HTTP proxy
when possible for enhanced security.
• Network File System (NFS): Stores backups in one of your previously
defined backup destinations that uses Network File System (NFS) storage.
– Select a Backup Destination.
• Recovery Appliance: Not Supported.
9. The following Advanced Options are available:
• Backup retention period: Customize the retention period for automatic
backups.
• Encryption Key: The customer-managed encryption key is not available for
Autonomous Container Databases with Data Guard feature enabled, and
therefore ACDs use the default Oracle-managed encryption keys.
• Tags: Optionally, you can apply tags. If you have permissions to create a
resource, you also have permissions to apply free-form tags to that resource.
To apply a defined tag, you must have permissions to use the tag namespace.
For more information about tagging, see Resource Tags. If you are not sure if
you should apply tags, skip this option (you can apply tags later) or ask your
administrator. Avoid entering confidential information.
10. Click Create Autonomous Container Database.

View Details of a Data Guard Enabled Primary or Standby

Autonomous Container Database
Follow these steps to view detailed information about a primary or standby
Autonomous Container Database on an Oracle Exadata Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Container Databases.
3. In the list of Autonomous Container Databases, click the display name of the
database you wish to view details.
4. In the Autonomous Container Database Details page, check the Autonomous Data
Guard association status and peer database state.
5. Under Resources, click Autonomous Data Guard to view association details.

30-4
 Chapter 30
Enabling Autonomous Data Guard on an Autonomous Container Database

Perform a Failover to Standby Autonomous Container Database

Initiate a failover operation by using the Data Guard association of the standby
database.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Container Databases.
3. In the list of Autonomous Container Databases, click the display name of the
infrastructure resource you are interested in.
4. Click the name of the standby database.
5. Under Resources, click Data Guard Associations.
6. For the Data Guard association on which you want to perform a failover, click the
Actions icon (three dots), and then click Failover.
7. In the Confirm Manual Failover to Standby dialog box, enter the name of the
Autonomous Container Database you want to failover, and then click Failover.

Note:
After successful completion of failover, the standby ACDs role will
change to primary and the primay's role will become disabled-standby.

Perform a Switchover to Standby or Primary Autonomous Container

Database
Initiate a switchover operation by using the Data Guard association of the primary
database.
• You can perform Switchover only when both primary and standby are in available
state.
• You cannot perform switchover if patching or maintenance is in progress on
primary or standby.
• After switchover, the maintenance preference for new standby and primary will
remain same as old standby and primary.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Container Databases.
3. In the list of Autonomous Container Databases, click the display name of the
infrastructure resource you are interested in.
4. Click the name of the primary or secondary database.
5. Under Resources, click Data Guard Associations.
6. For the Data Guard association on which you want to perform a switchover, click
the Actions icon (three dots), and then click Switchover.

30-5
 Chapter 30
Enabling Autonomous Data Guard on an Autonomous Container Database

7. In the Confirm Switchover to Standby dialog box, click Swichover.

This database should now assume the role of the standby, and the standby should
assume the role of the primary in the Data Guard association.

Reinstate Data Guard Enabled Standby Autonomous Container

Database
After you fail over a primary database to its standby, the standby assumes the primary
role and the old primary is identified as a disabled standby.
After the operations team correct the cause of failure, you can reinstate the failed
database as a functioning standby for the current primary by using its Data Guard
association. you can reinstate the failed database as a functioning standby for the
current primary by using its Data Guard association.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Container Databases.
3. In the list of Autonomous Container Databases, click the display name of the
infrastructure resource you are interested in.
4. Click the name of the failed database.
5. Under Resources, click Data Guard Associations.
6. For the Data Guard association on which you want to reinstate this database, click
the Actions icon (three dots), and then click Reinstate.
7. In the Reinstate Database dialog box, click Reinstate.
This database should now be reinstated as the standby in the Data Guard
association.

Terminate a Data Guard Enabled Primary Autonomous Container

Database
Follow these steps to terminate an autonomous container database on an Oracle
Exadata Cloud@Customer system.
You must terminate all Autonomous Databases within a container database before
you can terminate the container database itself. Terminating Autonomous Container
Database will disable Autonomous Data Guard, which affects high availability and
disaster recovery of your Autonomous Databases.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Container Databases.
3. In the list of Autonomous Container Databases, click the display name of the
infrastructure resource you are interested in.
4. In the Autonomous Container Database Details page, select Terminate from the
More Actions drop-down list.
5. Click Terminate.

30-6
 Chapter 30
Enabling Autonomous Data Guard on an Autonomous Container Database

6. In the confirmation dialog, type the name of the Autonomous Container Database,
and then click Terminate Autonomous Container Database.

Terminate a Data Guard Enabled Standby Autonomous Container

Database
Follow these steps to terminate an autonomous container database on an Oracle
Exadata Cloud@Customer system.
You can terminate a standby Autonomous Container Database even if there are
standby Autonomous Databases inside it. However, you cannot terminate standby
Autonomous Databases inside a standby Autonomoous Container Database. To
terminate a standby Autonomoous Database, you must first terminate the primary
Autonomous Database. Terminating Autonomous Container Database will disable
Autonomous Data Guard, which affects high availability and disaster recovery of your
Autonomous Databases.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Container Databases.
3. In the list of Autonomous Container Databases, click the display name of the
infrastructure resource you are interested in.
4. In the Autonomous Container Database Details page, select Terminate from the
More Actions drop-down list.
5. Click Terminate.
6. In the confirmation dialog, type the name of the Autonomous Container Database,
and then click Terminate Autonomous Container Database.

Operations Performed Using the APIs

Learn how to use the API to manage Autonomous Data Guard Enabled Autonomous
Container Database.
For information about using the API and signing requests, see "REST APIs" and
"Security Credentials". For information about SDKs, see "Software Development Kits
and Command Line Interface".
The following table lists the REST API endpoints to manage Autonomous Data Guard
Enabled Autonomous Container Database.

Operation REST API Endpoint

Creates Autonomous Container Databases CreateAutonomousContainerDatabase
(update to the existing API)
View details of the specified Autonomous GetAutonomousContainerDatabase
Container Database
(update to the existing API) deleteAutonomousContainerDatabase
View a list of Autonomous Container ListAutonomousContainerDatabaseDatag
Databases with Autonomous Data Guard uardAssociations
associations

30-7
 Chapter 30
Enabling Autonomous Data Guard on an Autonomous Database

Operation REST API Endpoint

Fetch details of an Autonomous Container GetAutonomousContainerDatabaseDatagu
Database Autonomous Data Guard ardAssociation
associations
Fail over the standby Autonomous FailoverAutonomousContainerDatabaseD
Container Database identified by ataguardAssociation
the autonomousContainerDatabaseId
parameter to the primary Autonomous
Container Database after the existing primary
Autonomous Container Database fails or
becomes unreachable.
Switch over the primary Autonomous SwitchoverAutonomousContainerDatabas
Container Database of an Autonomous Data eDataguardAssociation
Guard peer association to standby role. The
standby Autonomous Container Database
associated with
autonomousContainerDatabaseDataguard
AssociationId assumes the primary
Autonomous Container Database role.
Reinstate a disabled standby Autonomous ReinstateAutonomousContainerDatabase
Container Database identified by DataguardAssociation
the autonomousContainerDatabaseId
parameter to an active standby Autonomous
Container Database.
View a list of the Autonomous Data Guard- ListAutonomousDatabaseDataguardAssoc
enabled databases associated with the iations
specified Autonomous Database.
Fetch details of an Autonomous Database GetAutonomousDatabaseDataguardAssoci
Autonomous Data Guard associations ation
Fetches details such as peer database role, GetAutonomousDatabase
lag time, transport lag, and state

Related Topics
• REST APIs
• Security Credentials
• Software Development Kits and Command Line Interface

Enabling Autonomous Data Guard on an Autonomous

Database
Autonomous Databases inherit Data Guard settings from the parent container
database.
• View Autonomous Data Guard Enablement
Autonomous Data Guard settings are configured on the Autonomous Container
Databases in which the databases are running.
• Create an Autonomous Data Guard Enabled Autonomous Database

30-8
 Chapter 30
Enabling Autonomous Data Guard on an Autonomous Database

• View Details of a Data Guard Enabled Primary or Standby Autonomous Database

Follow these steps to view detailed information about a primary or standby
Autonomous Database on an Oracle Exadata Cloud@Customer system.

View Autonomous Data Guard Enablement

Autonomous Data Guard settings are configured on the Autonomous Container
Databases in which the databases are running.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Container Databases.
This page displays if an autonomous database is Data Guard enabled or not, and
if enabled, then the role of the database in the Data Guard association.

Create an Autonomous Data Guard Enabled Autonomous Database

Follow these steps to create an autonomous database on an Oracle Exadata
Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Databases.
3. Click Create Autonomous Database.
4. In the Create Autonomous Database dialog, enter the following:
Basic Database Information
• Compartment: Select the compartment of the Autonomous Database.
• Display Name: A user-friendly description or other information that helps you
easily identify the resource. The display name does not have to be unique.
Avoid entering confidential information.
• Database Name: The database name must consist of letters and numbers
only, starting with a letter. The maximum length is 14 characters. Avoid
entering confidential information.
Workload Type
Select the desired workload type. See Autonomous Data Warehouse and
Autonomous Transaction Processing for information about each workload type.
Autonomous Container Database: Select the Autonomous Data Guard-
enabled Autonomous Container Databases checkbox, and then select an
Autonomous Container Database.
Compartment: Specify the compartment containing the Autonomous Container
Database you wish to use.
Database CPU Core Count and Storage Configuration
• OCPU Count: The total number of cores available to all databases within the
Autonomous Exadata Infrastructure depends on the infrastructure shape and
what is already allocated to other Autonomous Databases.

30-9
 Chapter 30
Enabling Autonomous Data Guard on an Autonomous Database

Deselect Auto Scaling to disable auto-scaling. By default, auto-scaling is

enabled to allow the system to automatically use up to three times more CPU
and IO resources to meet workload demand.
• Storage (TB): Specify the storage you wish to make available to your
Autonomous Database, in terabytes. The available storage depends on the
infrastructure shape and what is already consumed by other Autonomous
Databases.
Administrator Credentials
Set the password for the Autonomous Database Admin user by entering a
password that meets the following criteria. You use this password when accessing
the Autonomous Database service console and when using an SQL client tool.
• Contains from 12 to 30 characters
• Contains at least one lowercase letter
• Contains at least one uppercase letter
• Contains at least one number
• Does not contain the double quotation mark (")
• Does not contain the string "admin", regardless of casing
Configure network access
You can optionally create an ACL during database provisioning, or at any time
thereafter.
a. Cick Modify Access Control.
b. In the Edit Access Control List dialog, select the Enable database level
access control checkbox.
c. Under the Primary database access control list, specify the following types
of addresses in your list by using the IP notation type drop-down selector:
IP Address allows you to specify one or more individual public IP addresses.
Use commas to separate your addresses in the input field.
CIDR Block allows you to specify one or more ranges of public IP addresses
using CIDR notation. Use commas to separate your CIDR block entries in the
input field.
d. Under Standby database access control, do the following:
(Default) Same as primary database: Leave as is if you want the same access
control list for the secondary database.
Define standby database access control: Initialized with the same details as
primary. Add or modify entries, as applicable.
Advanced Options
Tags: Optionally, you can apply tags. If you have permission to create a resource,
then you also have permissions to apply free-form tags to that resource. To apply
a defined tag, you must have permissions to use the tag namespace. For more
information about tagging, see Resource Tags. If you are not sure if you should
apply tags, skip this option (you can apply tags later) or ask your administrator.
Avoid entering confidential information.
Encryption Key: ADB inherits encryption settings from the parent ACD.
5. Click Create Autonomous Database.

30-10
 Chapter 30
Maintenance Scheduling and Patching Data Guard Enabled Autonomous Container Database

Note:
The following naming restrictions apply to Autonomous Transaction
Processing and Autonomous Data Warehouse databases:
• Names associated with databases terminated within the last 60 days
cannot be used when creating a new database.
• A database name cannot be used concurrently for both an
Autonomous Data Warehouse and an Autonomous Transaction
Processing database.

Related Topics
• About Autonomous Database

View Details of a Data Guard Enabled Primary or Standby

Autonomous Database
Follow these steps to view detailed information about a primary or standby
Autonomous Database on an Oracle Exadata Cloud@Customer system.
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Databases, click the display name of the database you
wish to view details.
4. In the Autonomous Database Details page, check the Autonomous Data Guard
association status and peer database state.
5. Under Resources, click Autonomous Data Guard to view association details.

Maintenance Scheduling and Patching Data Guard Enabled

Autonomous Container Database
Follow these steps to change the maintenance schedule of a Data Guard enabled
Autonomous Container Database.
• Configure Automatic Maintenance Schedule for a Data Guard Enabled
Autonomous Container Database
• View the Next Scheduled Maintenance Run of a Data Guard Enabled Autonomous
Container Database
• View the Maintenance History of a Data Guard Enabled Autonomous Container
Database
• Immediately Patch a Data Guard Enabled Autonomous Container Database
• Reschedule or Skip scheduled Maintenance for Data Guard Enabled Autonomous
Container Database

30-11
 Chapter 30
Maintenance Scheduling and Patching Data Guard Enabled Autonomous Container Database

Configure Automatic Maintenance Schedule for a Data Guard Enabled

Autonomous Container Database
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Container Databases, click the display name of the
container database you are interested in.
4. On the Autonomous Container Database details page, under Maintenance, click
the edit link in the Maintenance Details field. In the Edit Automatic Maintenance
dialog that opens, you can configure both the maintenance schedule and the patch
type.

Note:
The standby database will have No preference by default. Standby
Maintenance depends on the primary maintenance schedule.

5. Optionally, you can change the maintenance patch type. To edit this setting, select
either Release Update (RU) or Release Update Revision (RUR).
Release Update (RU): Autonomous Database installs only the most current
release update.
Release Update Revision (RUR): Autonomous Database installs the release
update plus additional fixes.

Note:
Standby will be always patched before primary and the default gap
between standby and primary is 7 days. You have have an option to
change the default gap to anytime between 1 - 7 days.

6. To configure the maintenance schedule, select Specify a schedule in the Configure

the automatic maintenance schedule section. Choose your preferred month, week,
weekday, and start time for container database maintenance.
• Under Maintenance months, specify at least one month for each maintenance
quarter during which you want Autonomous Exadata Infrastructure
maintenance to occur.

Note:
Maintenance quarters begin in February, May, August, and
November, with the first maintenance quarter of the year beginning
in February.

30-12
 Chapter 30
Maintenance Scheduling and Patching Data Guard Enabled Autonomous Container Database

• Under Week of the month, specify which week of the month maintenance will
take place. Weeks start on the 1st, 8th, 15th, and 22nd days of the month,
and have a duration of 7 days. Weeks start and end based on calendar dates,
not days of the week. Maintenance cannot be scheduled for the fifth week of
months that contain more than 28 days.
• Under Day of the week, specify the day of the week on which the maintenance
will occur.
• Under Start hour, specify the hour during which the maintenance run will
begin.
• Choose the buffer period between primary and standby maintenance
execution. Buffer period is the number of days before which the standby
Autonomous Container Database Maintenance will be scheduled before
primary Autonomous Container Database Maintenance
7. Click Save Changes.

View the Next Scheduled Maintenance Run of a Data Guard Enabled

Autonomous Container Database
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Container Databases, click the display name of the
container database you are interested in.
4. On the Autonomous Container Database details page, under Maintenance, click
the View link in the Next Maintenance field.
5. On the Maintenance page, under Autonomous Database Maintenance, click
Maintenance.
In the list of maintenance events, you can the details of scheduled maintenance
runs. Maintenance event details include the following:
• The status of the scheduled maintenance run
• The type of maintenance run (quarterly software maintenance or a critical
patch)
• The OCID of the maintenance event
• The start time and date of the maintenance

View the Maintenance History of a Data Guard Enabled Autonomous

Container Database
1. Open the navigation menu. Under Oracle Databases, click Exadata
Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Container Databases, click the display name of the
container database you are interested in.
4. On the Autonomous Container Database details page, under Maintenance, click
the View link in the Next Maintenance field.

30-13
 Chapter 30
Maintenance Scheduling and Patching Data Guard Enabled Autonomous Container Database

5. On the Maintenance page, under Autonomous Database Maintenance, click

Maintenance History.
In the list of past maintenance events, you can click on an individual event title
to read the details of the maintenance that took place. Maintenance event details
include the following:
• The category of maintenance (quarterly software maintenance or a critical
patch)
• Whether the maintenance was scheduled or unplanned
• The OCID of the maintenance event
• The start time and date of the maintenance

Immediately Patch a Data Guard Enabled Autonomous Container

Database

Note:
Patching primary immediately will result in standby being patched first, if
standby is not already patched.

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.
2. Click Autonomous Databases.
3. In the list of Autonomous Container Databases, click the display name of the
Autonomous Container Database that you want to patch.
4. On the Autonomous Container Database Details page, in the Maintenance
section, click the View link in the Next Maintenance field to display the
Maintenance page for the Autonomous Container Database that you want to
patch.
5. In the Autonomous Container Database section, click Patch Now in the
Scheduled Start Time field to display the Run Maintenance dialog.
6. Click Patch Now to start the patching operation.

Reschedule or Skip scheduled Maintenance for Data Guard Enabled

Autonomous Container Database

Note:
Skipping primary will skip standby also. If standby is patched, then skipping
on primary is not allowed.

1. Open the navigation menu. Under Oracle Databases, click Exadata

Cloud@Customer.

30-14
 Chapter 30
Maintenance Scheduling and Patching Data Guard Enabled Autonomous Container Database

2. Click Autonomous Databases.

3. In the list of Autonomous Container Databases, click the display name of the
container database that you want to manage.
4. On the Autonomous Container Database details page, in the Maintenance
section, click the View link in the Next Maintenance field.
5. On the Maintenance page, any container database maintenance events planned
for the next 15 days will appear in the list of maintenance events.
To skip scheduled maintenance for a container database, click Skip.

Note:
You cannot skip scheduled maintenance more than twice, consecutively.
To reschedule maintenance, click Edit and enter a start time for the
update in the Edit Maintenance dialog. Ensure that your specified
container database maintenance window is later in the quarter than your
scheduled Exadata infrastructure maintenance.

30-15
31
Using Performance Hub to Analyze
Database Performance
Use the Performance Hub tool to analyze and tune the performance of a selected
Oracle Exadata Cloud@Customer Autonomous Database.
With this tool, you can view real-time and historical performance data. When you view
historical data in the Performance Hub, you are viewing statistics collected as part of
the hourly snapshots of your database.

Note:
Performance Hub supports only Autonomous Databases.

• Performance Hub Features

• Time Range Selector
• Time Zone Selector
• ASH Analytics Tab
• SQL Monitoring Tab
• Blocking Sessions Tab
• Using the Oracle Cloud Infrastructure Console

Performance Hub Features

The Performance Hub window consists of a graphical Time Range display that you
use to select the time period of all data to be displayed. It includes the following tabs
that display performance data:
• ASH Analytics
• SQL Monitoring
• Blocking Sessions
These tabs, described in detail below, provide information that you can use to analyze
the performance of a selected database, including the following:
• How much of the database is waiting for a resource, such as CPU or disk I/O
• Whether database performance degraded over a given time period and what could
be the likely cause.
• Which specific modules may be causing a load on the system, and where most of
database time is being spent on this module.

31-1
 Chapter 31
Time Range Selector

• Which SQL statements are the key contributors to changes in database

performance, and which executions are causing them.
• Which user sessions are causing performance bottlenecks.
• Which sessions are currently blocking and if there are outstanding requests for a
lock.

Time Range Selector

The time range selector is displayed at the top of the Performance Hub page. It
consists of a graphically displayed time field as shown in the following illustration. Note
that the selected time range applies to all charts and graphs in the Performance Hub
window.

Figure 31-1 Time Range Selector

The time range field (#1 in the above illustration) shows database activity in chart
form for the specified Time Range period. The time range is the amount of time being
monitored.
Use the Quick Select selector to set the time range. The menu includes five time
choices, Last Hour, Last 8 Hours, Last 24 Hours, Last Week, and Custom. The default
time range is Last Hour. To specify a custom time range, you can also click the Time
Range field. This opens the Custom Time Range dialog, allowing you to specify a
custom range.
The Activity graph displays the average number of active sessions broken down by
CPU, User I/O, and Wait. Maximum threads are shown as a red line above the time
field.
The sliding box (circled at right in the above illustration) on the time range chart is
known as the time slider. The time slider selects a section of the time range (#2 in the
above illustration) shown in the time range field. It shows the time being analyzed. In
the illustration, the arrows inside the time slider point to the vertical 'handle' elements
on the left and right boundaries of the slider box. The time slider works as follows:
• To change the start and end time of the analysis while keeping the same amount
of time between them, left click anywhere inside the box. Then slide the box left
or right along the time range without changing its size. The selected times are
displayed below the time graph.
• To increase or decrease the length of time being analyzed, left click either one of
the handles and drag it left or right to expand or contract the box.
• To refresh the data in Performance Hub according to the time range chosen, click
Refresh (upper right corner of the window).

31-2
 Chapter 31
Time Zone Selector

Note:
The time slider provides an extra display feature in the Workload tab. See
the description in the Workload section of this page.
Use the Quick Select menu to set the time duration. The menu includes the
following five time choices: Last Hour, Last 8 Hours, Last 24 Hours, Last
Week, and Custom. The default Time Range is Last Hour. The time slider
selects the time period of the data displayed in Performance Hub. The time
slider has a different default time period based on the selected Time Range.

Time Zone Selector

The Time Zone selector is located above the time range field, beside the Quick Select
and Time Range selectors. By default, when you open Performance Hub, the tool
displays data in UTC (Coordinated Universal Time) time. You can use the time zone
selector to change the time zone to either your local web browser time, or the time
zone setting of the database you are working with. When you change the time zone,
Performance Hub's reports display data in your specified time zone.

ASH Analytics Tab

Displayed by default, the ASH (Active Session History) Analytics tab shows ASH
analytics charts to explore ASH data. You use it to drill down into database
performance across multiple dimensions such as Consumer Group, Wait Class, SQL
ID, and User Name. In the ASH Analytics tab, you can select an Average Active
Sessions dimension and view the top activity for that dimension for the selected time
period. For more information on ASH, see Active Session History (ASH) in Oracle
Database Concepts.

SQL Monitoring Tab

The SQL Monitoring tab is not displayed by default. To view it, click SQL Monitoring
on the Performance Hub page.
SQL statements are only monitored if they have been running for at least five
seconds or if they are run in parallel. The table in this section displays monitored
SQL statement executions by dimensions including Last Active Time, CPU Time,
and Database Time. The table displays currently running SQL statements and SQL
statements that completed, failed, or were terminated. The columns in the table
provide information for monitored SQL statements including Status, Duration, and SQL
ID.
The Status column has the following icons:
• A spinning icon indicates that the SQL statement is executing.
• A green check mark icon indicates that the SQL statement completed its execution
during the specified time period.

31-3
 Chapter 31
Blocking Sessions Tab

• A red cross icon indicates that the SQL statement did not complete. The icon
displays when an error occurs because the session was terminated.
• A clock icon indicates that the SQL statement is queued.
To terminate a running or queued SQL statement, click Kill Session.
You can also click an SQL ID to go to the corresponding Real-time SQL Monitoring
page. This page provides extra details to help you tune the selected SQL statement.

Blocking Sessions Tab

The Performance Hub blocking sessions tab displays the current blocking and waiting
sessions in a hierarchical display. You can view detailed information about each
blocking session, and can view the sessions blocked by each blocking session. You
can also use the tab to inspect or drill down into the SQL involved, to determine the
cause of the blocking. You can perform several operations in the tab, including killing
one or more of the listed sessions to resolve a waiting session problem.
The hierarchical display nests waiting sessions underneath the session that they are
blocked by in an easily viewable parent-child relationship. The hierarchy can contain
any number of levels to correctly represent the structure of the sessions involved.
The sessions listed include sessions that are waiting for a resource and sessions that
hold a resource that is being waited on that creates the blocking condition.

Using the Oracle Cloud Infrastructure Console

• Navigate to Performance Hub in the Oracle Cloud Infrastructure Console Interface
of an Autonomous Database
• View the Average Active Sessions Data by a Selected Dimension
• Filter Average Active sessions Data
• View the SQL Monitoring Report
• View the Blocking and Waiting Sessions

Navigate to Performance Hub in the Oracle Cloud Infrastructure

Console Interface of an Autonomous Database
1. Open the navigation menu. Under Oracle Databases, click Exadata Cloud at
Customer.
2. Choose your Compartment.
3. Click Autonomous Databases.
4. In the list of Autonomous Databases, click the display name of the database you
want to analyze using Performance Hub reports.
5. Click Performance Hub.

31-4
 Chapter 31
Using the Oracle Cloud Infrastructure Console

View the Average Active Sessions Data by a Selected Dimension

1. Go to the Performance Hub page of the Oracle Cloud Infrastructure Console for
the database which you want to manage.
See To navigate to Performance Hub in the Oracle Cloud Infrastructure Console
interface of an Autonomous Database for more information.
• The database name is displayed at the top of the Performance Hub page.
• The time period for which information is available on the Performance Hub is
displayed in the Time Range field. The selected time period is indicated on
the time slider graph by the adjustable time slider box.
The ASH Analytics tab is displayed with the top activity for a selected dimension
in the selected time period.
2. Use the Quick Select selector to set the exact time period for which data is
displayed in the ASH Analytics tables and graphs.
By default, the last hour is selected. The time range is the total amount of time
available for analysis.
3. Use the box on the time slider to further narrow down the time period for which
performance data is displayed on the ASH Analytics tab.
4. Select a dimension in the Average Active Sessions drop-down list to display
ASH analytics by that dimension.
When the Consumer Group dimension is selected, the data is categorized by
default to the High, Medium, or Low service name that is associated with the
Autonomous Database.
Optionally, you can:
• Click the Maximum Threads check box to view the number of Max CPU
Threads. The red line on the chart shows this limit.
• Click the Total Activity check box to view a black border that denotes total
activity of all the components of the selected dimension on the chart. This
option is selected by default when you use the filtering capabilities to only
view the data for a particular component within a dimension. For information
on filtering Average Active Sessions data, see Filter Average Active Sessions
Data.
5. For the dimension selected in the Average Active Sessions drop-down list, you
can further drill down into session details by selecting dimensions in the two
sections at the bottom of the ASH Analytics tab.
By default, the following dimensions are selected:
• SQL ID by Consumer Group, which displays the SQL statements with the
top average active sessions activity for consumer groups for the selected
time period. You can right-click the bar charts to sort the SQL statements in
ascending or descending order or click the SQL ID to go the SQL Details
page.
• User Session by Consumer Group, which displays the user sessions with
the top average active sessions activity for consumer groups for the selected
time period. You can right-click the bar charts to sort the user sessions in
ascending or descending order or click the user session to go to the User
Session page.

31-5
 Chapter 31
Using the Oracle Cloud Infrastructure Console

Filter Average Active sessions Data

1. Go to the Performance Hub page of the Oracle Cloud Infrastructure Console for
the database which you want to manage.
See To navigate to Performance Hub in the Oracle Cloud Infrastructure Console
interface of an Autonomous Database for more information.
• The database name is displayed at the top of the Performance Hub page.
• The time period for which information is available on the Performance Hub is
displayed in the Time Range field. The selected time period is indicated on
the time slider graph by the adjustable time slider box.
The ASH Analytics tab is displayed with the top activity for a selected dimension
in the selected time period.
2. Use the Quick Select selector to set the exact time period for which data is
displayed in the ASH Analytics tables and graphs.
By default, the last hour is selected. The time range is the total amount of time
available for analysis.
3. Use the adjustable time slider box to further narrow down the time period for which
performance data is displayed on the ASH Analytics tab.
4. In the ASH Analytics tab, select a dimension in the Average Active Sessions by
drop-down list.
By default, Consumer Group is selected.
The chart is displayed. Each color in the chart denotes a component of the
selected dimension.For example, the Consumer Group dimension has High,
Medium, and Low, which are predefined service names assigned to your
Autonomous Database to provide different levels of concurrency and performance.
5. Click a component in the legend.
The selected component is displayed in the Applied Filters field and the chart is
updated to only display data pertaining to that component. The total activity, which
includes all the components of the dimension, is defined by a black outline and is
displayed by default when you filter data.

View the SQL Monitoring Report

1. Go to the Performance Hub page of the Oracle Cloud Infrastructure Console for
the database which you want to manage.
See To navigate to Performance Hub in the Oracle Cloud Infrastructure Console
interface of an Autonomous Database for more information.
• The database name is displayed at the top of the Performance Hub page.
• The time period for which information is available on the Performance Hub is
displayed in the Time Range field. The selected time period is indicated on
the time slider graph by the adjustable time slider box.
2. Click SQL Monitoring to display the SQL monitoring tab.
3. Optionally, you can get detailed information on a specific SQL statement by
clicking an ID number in the SQL ID column.

31-6
 Chapter 31
Using the Oracle Cloud Infrastructure Console

When you click an ID number, the Real-time SQL Monitoring page is displayed.
4. Click Download Report to download the report data for your selected SQL
statement.

View the Blocking and Waiting Sessions

1. Go to the Performance Hub page of the Oracle Cloud Infrastructure Console for
the database which you want to manage.
See To navigate to Performance Hub in the Oracle Cloud Infrastructure Console
interface of an Autonomous Database for more information.
• The database name is displayed at the top of the Performance Hub page.
• The time period for which information is available on the Performance Hub is
displayed in the Time Range field. The selected time period is indicated on
the time slider graph by the adjustable time slider box.
2. Click Blocking Sessions to display details about current blocking and waiting
sessions.
Analysis of historical sessions is not supported.
3. Click the link in each column of the table to view the details of the listed blocking
and waiting sessions, as shown in the following table.

Note:
If you see an error message that says the server failed to get
performance details for the selected session at the selected time, try the
selection again. If the same error message is displayed, try a different
time selection. If that fails, contact Oracle Support.

Table 31-1 Blocking and Waiting Sessions

Tab Column Description

User Name This is the name of the user.
Status The status indicates whether the session is
active, inactive, or expired.
Lock This is the lock type for the session.
Click the lock type to display a table with
more information about the session lock.
It lists the Lock Type, Lock Mode, Lock
Request, Object Type, Subobject Type,
Time, ID1, ID2, Lock Object Address,
and Lock Address of the selected session.
User Session The user session lists the Instance, SID,
and Serial number.
SQL ID This is the ID of the SQL associated with the
session.

31-7
 Chapter 31
Using the Oracle Cloud Infrastructure Console

Table 31-1 (Cont.) Blocking and Waiting Sessions

Tab Column Description

Wait Event This is the wait event for the session. Click
the wait event to show additional wait event
details.
Object Name This is the name of the locked database
object.
Blocking Time This is the time that a blocking session has
been blocking a session.
Wait Time This is the time that a session has been
waiting.

• Setting the Minimum Wait Time

• Killing a Session
• Displaying Lock Details
• Displaying Wait Event Information
• Displaying Session Details
• Displaying SQL Details

Setting the Minimum Wait Time

The minimum wait time works like a filter for the Blocking Sessions information. It
sets the minimum time that a session must wait before it is displayed in the tab. For
example, if the minimum wait time is set to three seconds, and a session has waited
only two seconds, it is not displayed in the table. But if you change the minimum wait
time to one second, the session that waited only two seconds is added to the display.

Note:
The minimum wait time default setting is three seconds.

Killing a Session
1. Click the check box at the left of the session User Name to select a session.
The Kill Session button is enabled.
2. Click Kill Session.
The Kill Session confirmation dialog box is displayed.
3. Click Kill Session to end the session.

Displaying Lock Details

1. In the session Lock column, click the name of the lock type (Lock or Exclusive
Lock) for the session.

31-8
 Chapter 31
Using the Oracle Cloud Infrastructure Console

The Wait Event Details message box is displayed.

2. Note the information in the table and use as needed to determine any action to
take.

Displaying Wait Event Information

1. In the session Wait Event column, click the name of the wait event for the
selected session.
The Session Lock Information table is displayed.
2. Note the information in the message box and use as needed to determine any
action to take.

Displaying Session Details

1. In the session User Session column, click the session identifier for the
session.The Performance Hub Session Details page is displayed.
2. Optionally, move the time slider to display a specific time range of the session.
3. Use the Session Details page to explore additional details about the session.

Displaying SQL Details

1. In the session SQL ID column, click the SQL ID associated with the session.
The Performance Hub SQL Details page is displayed.
2. Optionally, move the time slider to display a specific time range of the session.
3. Select one or more of the following tabs, note the information in them, and take
any action needed.
• Summary. This tab displays the SQL Overview and Source details.
• ASH Analytics. This tab displays the SQL average active sessions.
• Execution Statistics. This tab displays the SQL plans and plan details.
• SQL Monitoring. This tab displays information about monitored SQL
executions.
• SQL Text. This tab displays the SQL.

31-9
32
Security Guide for Exadata
Cloud@Customer Systems
This guide describes security for an Oracle Exadata Cloud@Customer System.
It includes information about the best practices for securing the Oracle Exadata
Cloud@Customer System.
• Security Configurations and Default Enabled Features
• Additional Procedures for Updating Security Posture

Security Configurations and Default Enabled Features

• Responsibilities
• Guiding Principles Followed for Security Configuration Defaults
• Security Features
• Guest VM Default Fixed Users
• Guest VM Default Security Settings
• Guest VM Default Processes
• Guest VM Network Security

Responsibilities
Exadata Cloud@Customer is jointly managed by the customer and Oracle.
The Exadata Cloud@Customer deployment is divided into two major areas of
responsibilities:
• Customer accessible services:
Components that the customer can access as part of their subscription to Exadata
Cloud@Customer:
– Customer accessible virtual machines (VM)
– Customer accessible database services
• Oracle-managed infrastructure:
– Power Distribution Units (PDUs)
– Out-of-band (OOB) management switches » InfiniBand switches
– Exadata Storage Servers
– Physical Exadata database servers
Customers control and monitor access to customer services, including network access
to their VMs (through layer 2 VLANs and firewalls implemented in the customer VM),
authentication to access the VM, and authentication to access databases running

32-1
 Chapter 32
Security Configurations and Default Enabled Features

in the VMs. Oracle controls and monitors access to Oracle-managed infrastructure

components. Oracle staff are not authorized to access customer services, including
customer VMs and databases.
Customers access Oracle Databases running on Exadata Cloud@Customer through a
layer 2 (tagged VLAN) connection from customer equipment to the databases running
in the customer VM using standard Oracle Database connection methods, such as
Oracle Net on port 1521. Customers access the VM running the Oracle Databases
through standard Oracle Linux methods, such as token based SSH on port 22.

Guiding Principles Followed for Security Configuration Defaults

• Defense in Depth
Exadata Cloud@Customer offers a number of controls to ensure confidentiality,
integrity, and accountability throughout the service.
First, Exadata Cloud@Customer is built from the hardened operating system
image provided by Exadata Database Machine. For more information, see
Overview of Oracle Exadata Database Machine Security. This secures the core
operating environment by restricting the installation image to only the required
software packages, disabling unnecessary services, and implementing secure
configuration parameters throughout the system.
In addition to inheriting all the strength of Exadata Database Machine's mature
platform, because Exadata Cloud@Customer provisions systems for customers,
additional secure default configuration choices are implemented in the service
instances. For example, all database tablespaces require transparent data
encryption (TDE), strong password enforcement for initial database users and
superusers, and enhanced audit and event rules.
Exadata Cloud@Customer also constitutes a complete deployment and service,
so it is subjected to industry-standard external audits such as PCI, HIPPA and
ISO27001. These external audit requirements impose additional value-added
service features such as antivirus scanning, automated alerting for unexpected
changes to the system, and daily vulnerability scans for all Oracle-managed
infrastructure systems in the fleet.
• Least Privilege
To ensure that processes only have access to the privileges they require, Oracle
Secure Coding Standards require the paradigm of least privilege.
Each process and daemon, must run as a normal, unprivileged user unless
it can prove a requirement for a higher level of privilege. This helps contain
any unforeseen issues or vulnerabilities to unprivileged user space and not
compromise an entire system.
This principle also applies to Oracle operations team members who use individual
named accounts to access the Oracle Exadata Cloud@Customer infrastructure for
maintenance or troubleshooting. Only when necessary will they use the audited
access to higher levels of privilege to solve or resolve an issue. Most issues are
resolved through automation, so we also employ least privilege by not permitting
human operators to access a system unless the automation is unable to resolve
the issue.
• Auditing and Accountability
When required, access to the system is allowed, but all access and actions are
logged and tracked for accountability.

32-2
 Chapter 32
Security Configurations and Default Enabled Features

This ensures that both Oracle and customers know what was done on the system
and when that occurred. These facts not only ensure we remain compliant with
reporting needs for external audits, but also can help match up some change with
a change in perceived behavior in the application.
Auditing capabilities are provided at all infrastructure components to ensure all
actions are captured. Customers also have ability to configure auditing for their
database and Guest VM configuration and may choose to integrate those with
other enterprise auditing systems.
• Automating Cloud Operations
By eliminating manual operations required to provision, patch, maintain,
troubleshoot, and configure systems, the opportunity for error is reduced and a
secure configuration is ensured.
The service is designed to be secure and by automating all provisioning,
configuration, and most other operational tasks, it is possible to avoid missed
configurations and ensure all necessary paths into the system are closed tightly.
Related Topics
• Overview of Oracle Exadata Database Machine Security

Security Features
• Hardened Operating System Image
– Minimal package installation:
Only the necessary packages required to run an efficient system are installed.
By installing a smaller set of packages, the attack surface of the operating
system is reduced and the system remains more secure.
– Secure configuration:
Many non-default configuration parameters are set during installation to
enhance the security posture of the system and its content. For example,
SSH is configured to only listen on certain network interfaces, sendmail
is configured to only accept localhost connections, and many other similar
restrictions are implemented during installation.
– Run only necessary services:
Any services that may be installed on the system, but not required for normal
operation are disabled by default. For example, while NFS is a service often
configured by customers for various application purposes, it is disabled by
default as it is not required for normal database operations. Customers may
choose to optionally configure services per their requirements.
• Minimized Attack Surface
As part of the hardened image, attack surface is reduced by disabling services.
• Additional Security Features Enabled (grub passwords, secure boot)
– Leveraging Exadata image capabilities, Exadata Cloud@Customer enjoys the
features integrated into the base image such as grub passwords and secure
boot in addition to many others.
– Through customization, customers may wish to further enhance their security
posture with additional configurations detailed later in this chapter.
• Secure Access Methods

32-3
 Chapter 32
Security Configurations and Default Enabled Features

– Accessing database servers through SSH using strong cryptographic ciphers.

Weak ciphers are disabled by default.
– Accessing databases via encrypted Oracle Net connections. By default, our
services are available using encrypted channels and a default configured
Oracle Net client will use encrypted sessions.
– Accessing diagnostics through Exadata MS web interface (https).
• Auditing and Logging
By default, auditing is enabled for administrative operations and those audit
records are communicated to OCI internal systems for automated review and
alerting when required.
• Deployment-Time Considerations
– Wallet file download contents and sensitivity: The wallet file download that is
obtained by a customer to enable the deployment to occur contains sensitive
information and should be handled appropriately to ensure the contents
are protected. The content of the wallet file download is not needed after
deployment is completed, so it should be destroyed to ensure no information
leakage occurs.
– Control Plane Server (CPS):
* Deployment requirements for the CPS include permitting outbound
HTTPS access so the CPS can connect to Oracle and enable remote
administration, monitoring, and maintenance. Find more details in the
Deployment Guide.
* Customer responsibilities include providing physical security to the
Exadata Cloud@Customer equipment in their data center. While Exadata
Cloud@Customer employs many software security features, physical
server compromise must be addressed by customer physical security to
ensure the safety of the servers' contents.

Guest VM Default Fixed Users

Several user accounts regularly manage the components of Oracle Exadata
Cloud@Customer. In all Exadata Cloud@Customer machines, Oracle uses and
recommends SSH based login only. No Oracle user or processes use password based
authentication system.
Below described are the different kind of users created by default.
• Default Users: No Logon Privileges
This user list consists of default operating system users along with some
specialized users like exawatch and dbmsvc. These users should not be altered.
These users cannot login to the system as all are set to /bin/false.
– exawatch:
The exawatch user is responsible for collecting and archiving system statistics
on both the database servers and the storage servers.
– dbmsvc:
User is used for Management Server on the database node service in Oracle
Exadata System.

32-4
 Chapter 32
Security Configurations and Default Enabled Features

NOLOGIN Users

bin:x:1:1:bin:/bin:/bin/false
daemon:x:2:2:daemon:/sbin:/bin/false
adm:x:3:4:adm:/dev/null:/bin/false
mail:x:8:12:mail:/var/spool/mail:/bin/false
nobody:x:99:99:Nobody:/:/bin/false
systemd-network:x:192:192:systemd Network Management:/:/bin/false
dbus:x:81:81:System message bus:/:/bin/false
rpm:x:37:37::/var/lib/rpm:/bin/false
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/bin/false
rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/bin/false
nscd:x:28:28:NSCD Daemon:/:/bin/false
saslauth:x:999:76:Saslauthd user:/run/saslauthd:/bin/false
mailnull:x:47:47::/var/spool/mqueue:/bin/false
smmsp:x:51:51::/var/spool/mqueue:/bin/false
chrony:x:998:997::/var/lib/chrony:/bin/false
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/bin/false
uucp:x:10:14:Uucp user:/var/spool/uucp:/bin/false
nslcd:x:65:55:LDAP Client User:/:/bin/false
tcpdump:x:72:72::/:/bin/false
exawatch:x:1010:510::/:/bin/false
sssd:x:997:508:User for sssd:/:/bin/false
tss:x:59:59:Account used by the trousers package to sandbox the
tcsd daemon:/dev/null:/bin/false
dbmsvc:x:12137:11137::/home/dbmsvc:/bin/false

• Default Users With Restricted Shell Access

These users are used for accomplishing a defined task with a restricted shell login.
These users should not be altered as the defined task will fail in case these users
are altered or deleted.
dbmmonitor: The dbmmonitor user is used for DBMCLI Utility. For more
information, see Using the DBMCLI Utility.
Restricted Shell Users

dbmmonitor:x:2003:2003::/home/dbmmonitor:/bin/rbash

• Default Users with Login permissions

These privileged users are used for accomplishing most of the tasks in the system.
These users should never be altered or deleted as it would have significant impact
on the running system.
SSH keys are used for login.
Privileged Users

root:x:0:0:root:/root:/bin/bash
oracle:x:1001:1001::/home/oracle:/bin/bash
grid:x:1000:1001::/home/grid:/bin/bash
opc:x:2000:2000::/home/opc:/bin/bash
dbmadmin:x:2002:2002::/home/dbmadmin:/bin/bash

32-5
 Chapter 32
Security Configurations and Default Enabled Features

– root: Linux requirement, used sparingly to run local privileged commands.

root is also used for some processes like Oracle Trace File Analyzer Agent
and ExaWatcher.
– grid: Owns Oracle Grid Infrastructure software installation and runs Grid
Infastructure processes.
– oracle: Owns Oracle database software installation and runs Oracle
Database processes.
– opc:
* Used by Oracle Cloud automation for automation tasks.
* Has the ability to run certain privileged commands without further
authentication (to support automation functions).
* Runs the local agent, also known as “DCS Agent” that performs lifecycle
operations for Oracle Database and Oracle Grid Infastructure software
(patching, create database, and so on).
– dbmadmin:
* The dbmadmin user is used for Oracle Exadata Database Machine
Command-Line Interface (DBMCLI) utility.
* The dbmadmin user should be used to run all services on the database
server. For more information, see Using the DBMCLI Utility.
Related Topics
• Using the DBMCLI Utility

Guest VM Default Security Settings

In addition to all of the Exadata features explained in Security Features of Oracle
Exadata Database Machine, the following security settings are also applicable.
• Custom database deployment with non-default parameters.
The command host_access_control is to configure Exadata security settings:
– Implementing password aging and complexity policies.
– Defining account lockout and session timeout policies.
– Restricting remote root access.
– Restricting network access to certain accounts.
– Implementing login warning banner.
• account-disable: Disables a user account when certain configured conditions are
met.
• pam-auth: Various PAM settings for password changes and password
authentication.
• rootssh: Adjusts the PermitRootLogin value in /etc/ssh/sshd_config, which
permits or denies the root user to login through SSH.
– By default, PermitRootLogin is set to yes.
– It is recommended to disable allowance of SSH root login PermitRootLogin
to no.

32-6
 Chapter 32
Security Configurations and Default Enabled Features

• session-limit: Sets the * hard maxlogins parameter in /etc/security/

limits.conf, which is the maximum number of logins for all users. This limit
does not apply to a user with uid=0.
Defaults to * hard maxlogins 10 and it is the recommended secure value.
• ssh-macs: Specifies the available Message Authentication Code (MAC) algorithms.
– The MAC algorithm is used in protocol version 2 for data integrity protection.
– Defaults to hmac-sha1, hmac-sha2-256, hmac-sha2-512 for both server and
client.
– Secure recommended values: hmac-sha2-256, hmac-sha2-512 for both server
and client.
• password-aging: Sets or displays the current password aging for interactive user
accounts.
– -M: Maximum number of days a password may be used.
– -m: Minimum number of days allowed between password changes.
– -W: Number of days warning given before a password expires.
– Defaults to -M 99999, -m 0, -W 7
– --strict_compliance_only -M 60, -m 1, -W 7
– Secure recommended values: -M 60, -m 1, -W 7

Related Topics
• Security Features of Oracle Exadata Database Machine

Guest VM Default Processes

• Exadata Cloud@Customer Guest VM agent: Cloud agent for handling database
lifecycle operations
– Runs as opc user.
– Process table shows it running as a Java process with jar
names, dbcs-agent-VersionNumber-SNAPSHOT.jar and dbcs-admin-
VersionNumver-SNAPSHOT.jar.
• Oracle Trace File Analyzer agent: Oracle Trace File Analyzer (TFA) provides a
number of diagnostic tools in a single bundle, making it easy to gather diagnostic
information about the Oracle Database and Oracle Clusterware, which in turn
helps with problem resolution when dealing with Oracle Support.
– Runs as root user.
– Runs as initd demon, /etc/init.d/init.tfa.
– Process tables show a Java application, oracle.rat.tfa.TFAMain.
• ExaWatcher:
– Runs as root and exawatch users.
– Runs as backgroud script, ExaWatcher.sh and all its child process run as a
Perl process.
– Process table shows as multiple Perl applications.

32-7
 Chapter 32
Security Configurations and Default Enabled Features

• Oracle Database and Oracle Grid Infrastructure (Oracle Clusterware):

– Runs as dbmsvc and grid users.
– Process table shows following applications:
* oraagent.bin, apx_*, and ams_* as grid user.
* dbrsMain, and Java applications, derbyclient.jar and weblogic.Server
as oracle user.
• Management Server (MS): Part of Exadata image software for managing and
monitoring the image functions.
– Runs as dbmadmin user.
– Process table shows it running as a Java process.

Guest VM Network Security

Table 32-1 Default Port Matrix for Guest VM Services

Type of interface Name of interface Port Process running

Bridge on client VLAN bondeth0 22 sshd
1521 Oracle TNS listener
5000 Oracle Trace File
Analyzer Collector
7878 Oracle WebLogic
Server
7879 Oracle WebLogic
Server
bondeth0:1 1521 Oracle TNS listener
bondeth0:2 1521 Oracle TNS listener
Bridge on backup bondeth1 7878 Oracle WebLogic
VLAN Server
7879 Oracle WebLogic
Server
CPS to DBS clib0 1525 Oracle TNS listener
Agent communication 3260 Synology DSM iSCSI
through Infiniband.
7878 Oracle WebLogic
Server
7879 Oracle WebLogic
Server
13698 Oracle TNS listener
27178 Oracle Trace File
Analyzer Collector
33124 Cluster Logging
service
63484 Oracle TNS listener
clib1 1525 Oracle TNS listener
7878 Oracle WebLogic
Server
7879 Oracle WebLogic
Server

32-8
 Chapter 32
Security Configurations and Default Enabled Features

Table 32-1 (Cont.) Default Port Matrix for Guest VM Services

Type of interface Name of interface Port Process running

27178 Oracle Trace File
Analyzer Collector
42266 Oracle TNS listener
59457 Oracle TNS listener
stib0 7060 dbcs-admin
7070 dbcs-agent
7878 Oracle WebLogic
Server
7879 Oracle WebLogic
Server
stib1 7060 dbcs-admin
7070 dbcs-agent
7878 Oracle WebLogic
Server
7879 Oracle WebLogic
Server
Ethernet eth0 22 sshd
Loopback lo 22 sshd
199 snmpd
2016 Oracle Grid
Infrastructure
5043 Oracle WebLogic
Server
6100 Oracle Notification
Service (ONS), part of
grid infrastructure
7878 WebLogic - Exadata
Management Server
(MS)
7879 WebLogic - Exadata
Management Server
(MS)

Default iptables rules for Guest VM:

The default iptables are setup to ACCEPT connections on input, forward, and output
chains.

#iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

pkts bytes target prot opt in out source
destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

32-9
 Chapter 32
Additional Procedures for Updating Security Posture

pkts bytes target prot opt in out source

destination

Additional Procedures for Updating Security Posture

• Customer Responsibilities
• Enabling Additional Security Capabilities

Customer Responsibilities

Table 32-2 Resposibilities

Oracle Cloud Platform Customer/Tenant Instances

Monitoring Oracle Cloud Ops Customer Oracle Cloud Ops Customer
Infrastructure, Provide network Infrastructure Monitoring of
Control Plane, access to support availability to customer
hardware faults, Oracle support customer operating system,
availability, infrastructure log monitoring of databases, apps
capacity collection and customer
monitoring services
Incident Incident Onsite diagnostic Support for any Incident
Management Management and assistance, for incidents related Management and
and Resolution Remediation example, network to the underlying resolution for
Spare parts and troubleshooting platform Customer’s apps
field dispatch
Patch Proactive Provide network Staging of Patching of
Management patching of access to support available patches, tenant instances
hardware, IaaS/ patch delivery for example, Testing
PaaS control Oracle Database
stack patch set
Backup and Infrastructure and Provide network Provide running Snapshots /
Restoration Control Plane access to support and customer backup and
backup and cloud automation accessible VM recovey of
recovery, receate delivery customer's IaaS
customer VMs and PaaS data
using Oracle
native or third-
party capability
Cloud Support Response and Submit SR Response and Submit SR
resolution of SR through MOS resolution of SR through Suppot
related to portal
infrastructure or
subscription
issues

Enabling Additional Security Capabilities

Migrating TDE Keys to HSM
For more information, see Managing the Keystore and the Master Encryption Key.

32-10
 Chapter 32
Additional Procedures for Updating Security Posture

Migrating from a Password-Protected Software Keystore to a Hardware Keystore

You can migrate from a password-protected software keystore to a hardware keystore.
• Step 1: Convert the Software Keystore to Open with the Hardware Keystore
Some Oracle tools require access to the old software keystore to encrypt or
decrypt data that was exported or backed up using the software keystore.
• Step 2: Configure the Hardware Security Module Keystore Type
You can use the ALTER SYSTEM statement to configure the HSM keystore type.
• Step 3: Perform the Hardware Keystore Migration
You can use the ADMINISTER KEY MANAGEMENT SQL statement to perform a
hardware keystore migration.
1. Convert the Software Keystore to Open with the Hardware Keystore
Some Oracle tools require access to the old software keystore to encrypt or
decrypt data that was exported or backed up using the software keystore.
Examples of these tools are Oracle Data Pump and Oracle Recovery Manager.
Use the ADMINISTER KEY MANAGEMENT SQL statement to convert a software
keystore to a open with a hardware keystore.
• To set the software keystore password as that of the hardware keystore, use
the following syntax:

ADMINISTER KEY MANAGEMENT ALTER KEYSTORE PASSWORD

FORCE KEYSTORE

IDENTIFIED BY software_keystore_password

SET "hardware_keystore_credentials" WITH BACKUP

[USING 'backup_identifier'];

In this specification,
– software_keystore_password is the same password that you used when
creating the software keystore.
– hardware_keystore_credentials is the new software keystore password
which is the same as the password of the hardware keystore.
– WITH BACKUP creates a backup of the software keystore. Optionally, you
can use the USING clause to add a brief description of the backup.
Enclose this description in single quotation marks (' '). This identifier
is appended to the named keystore file, for example, ewallet_time-
stamp_emp_key_backup.p12, with emp_key_backup being the backup
identifier. Follow the file naming conventions that your operating system
uses.

32-11
 Chapter 32
Additional Procedures for Updating Security Posture

• To create an auto-login keystore for a software keystore, use the following

syntax:

ADMINISTER KEY MANAGEMENT CREATE [LOCAL] AUTO_LOGIN KEYSTORE

FROM KEYSTORE 'keystore_location'

IDENTIFIED BY software_keystore_password;

In this specification,
– LOCAL enables you to create a local auto-login software keystore.
Otherwise, omit this clause if you want the keystore to be accessible by
other computers.
– keystore_location is the path to the keystore directory location of the
keystore that is configured in the sqlnet.ora file.
– software_keystore_password is the existing password of the configured
software keystore.
2. Configure the Hardware Security Module Keystore Type
You can use the ALTER SYSTEM statement to configure the HSM keystore type.
For the software keystore to open with the hardware keystore, either the software
keystore must have the same password as the hardware keystore, or alternatively,
you can create an auto-login keystore for the software keystore.
a. Log in to the database instance as a user who has been granted the SYSDBA
administrative privilege.
For example:

sqlplus sec_admin as sysdba

Enter password: password

b. Set the TDE_CONFIGURATION dynamic initialization parameter.

The following example migrates from a TDE keystore to a hardware keystore:

ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=HSM|

FILE";

The next example migrates from a TDE keystore to an Oracle Key Vault
keystore:

ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=OKV|

FILE";

c. Restart the database.

SHUTDOWN IMMEDIATE
STARTUP

3. Perform the Hardware Keystore migration.

You can use the ADMINISTER KEY MANAGEMENT SQL statement to perform a
hardware keystore migration.

32-12
 Chapter 32
Additional Procedures for Updating Security Posture

To migrate from the software keystore to hardware keystore, you must use the
MIGRATE USING keystore_password clause in the ADMINISTER KEY MANAGEMENT
SET KEY SQL statement to decrypt the existing TDE table keys and the tablespace
encryption keys with the TDE master encryption key in the software keystore and
then reencrypt them with the newly created TDE master encryption key in the
hardware keystore.
After you complete the migration, you do not need to restart the database, nor
do you need to manually re-open the hardware keystore. The migration process
automatically reloads the keystore keys in memory.
• Migrate the hardware keystores by using the following syntax:

ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY

IDENTIFIED BY "user_name:password"
MIGRATE USING software_keystore_password
[WITH BACKUP [USING 'backup_identifier']];

In this specification,
– user_name:password is the user ID and password that was created in Step
2 under Step 2: Configure the Hardware Security Module (in Configuring
Transparent Data Encryption). Enclose this setting in double quotation
marks (" ") and separate user_name and password with a colon (:).
– software_keystore_password is the same password that you used when
creating the software keystore or that you have changed to in Step 1:
Convert the Software Keystore to Open with the Hardware Keystore.
– USING enables you to add a brief description of the backup. Enclose
this description in single quotation marks (' '). This identifier is
appended to the named keystore file (for example, ewallet_time-
stamp_emp_key_backup.p12, with emp_key_backup being the backup
identifier). Follow the file naming conventions that your operating system
uses.

Note:
If the database contains columns encrypted with a public key, then
the columns are decrypted and reencrypted with an AES symmetric
key generated by HSM-based Transparent Data Encryption.

Modifying Password Complexity Requirements Using host_access_control

Table 32-3 host_access_control password-aging

Option Description
-s, --status Displays current user password aging.
-u USER, --user=USER A valid interactive user's username.
--defaults Sets all password-aging values to *Exadata
factory defaults for all interactive users.

32-13
 Chapter 32
Additional Procedures for Updating Security Posture

Table 32-3 (Cont.) host_access_control password-aging

Option Description
--secdefaults Sets all password-aging values to **Exadata
secure defaults for all interactive users.
--policy Sets all password-aging values to the aging
policy as defind by the password-policy
command (or /etc/login.defs) for all
interactive users.
-M int, --maxdays=int Maximum number of days a password may be
used. Input limited to from 1 to 99999.
-m int, --mindays=int Minimum number of days allowed between
password changes. Input limited to from 0 to
99999, 0 for anytime.
-W int, --warndays=int Number of days warning given before a
password expires. Input limited to from 0 to
99999.
host_access_control password-policy --PASS_MAX_DAYS integer (60)*
--PASS_MIN_DAYS integer ( 1)*
--PASS_MIN_LEN integer ( 8)*
--PASS_WARN_AGE integer ( 7)*
--defaults
--status

Table 32-4 host_access_control pam-auth

Options Description
-h, --help Shows this help message and exits.
-d DENY, --deny=DENY Number of failed login attempts before an
account will be locked. Input is limited to from
1 to 10. (*Exadata factory default is 5)
-l LOCK_TIME, --lock=LOCK_TIME Number of seconds (integer) an account will
be locked due to a single failed login attempt.
Input is limited to from 0 to 31557600 (one
year) (*Exadata factory default is 600 (10m))

32-14
 Chapter 32
Additional Procedures for Updating Security Posture

Table 32-4 (Cont.) host_access_control pam-auth

Options Description
-p list, --passwdqc=list FOR SYSTEMS RUNNING ON LESS THAN
OL7
Comma-separated set of 5 values:
N0,N1,N2,N3,N4 defining the minimum
allowed length for different types of password/
passphrases. Each subsequent number is
required to be no larger than the preceding
one. The keyword "disabled" can be used to
disallow passwords of a given kind regardless
of their length. (Refer to the pam_passwdqc
manpage for an explanation).
Passwords must use three character classes.
Character classes for passwords are digits,
lowercase letters, uppercase letters, and
other characters. Minimum password length
is 12 characters when using three character
classes.
Minimum password length is 8 characters
when using four character classes. ( *Exadata
factory default is 5,5,5,5,5) (**Exadata secure
default is disabled,disabled,16,12,8)
-q PWQUALITY, --pwquality=PWQUALITY FOR SYSTEMS RUNNING ON OL7 AND
GREATER
Integer, ranging from 6 to 40, defining the
minimum allowed password length. defined by
the Exadata secure defaults. All classes will
be required for password changes as well
as other checks enforced for lengths >7. For
lengths <8, class requirements are not used.
(*Exadata factory default is: minlen=8
dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1
difok=8 maxrepeat=3 maxclassrepeat=4)
(**Exadata secure default is: minlen=15
dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1
difok=8 maxrepeat=3 maxclassrepeat=4)
(Refer to the pam_pwquality manpage for
details)
-r REMEMBER, --remember=REMEMBER The last n passwords to remember for
password change history. Valid range is an
integer from 0 to 1000.
(*Exadata factory default is 10)
--defaults Sets all pam-auth values to *Exadata factory
defaults.
--secdefaults Sets all pam-auth values to **Exadata secure
defaults.
-s, --status Displays current PAM authentication settings.

Implementing or Updating the iptables firewall Configuration in Guest VM

iptables configuration and firewall rules are stored in /etc/sysconfig/iptables.

32-15
 Chapter 32
Additional Procedures for Updating Security Posture

man iptables : To get iptables help. Various websites online have many tutorials as
well.
iptables --list : To get current iptables rules.

Refer to earlier section "Guest VM Network Security" for details on what ports may
be required on Guest VM. To configure the firewall manually, create commands like
the following example. Note that it is possible to lock yourself out of the system by
blocking the ports over which you connect, so it's recommended to consult a test
system and engage an experienced iptables administrator if possible.
1. At the command prompt, enter the appropriate command for each port to be
opened, for example:

# iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 7002

-j ACCEPT

# iptables -A INPUT -m state --state NEW -m udp -p udp --dport 123

-j ACCEPT

2. Save the iptables configuration.

# service iptables save

Changing passwords and Updating Authorized Keys

To change a user password the password command is used. Passwords must be
changed 7 days prior expiration date. Password policies are described above in the
default security settings section.
Default Oracle Exadata Users and Passwords - See My Oracle Support note https://
support.oracle.com/epmos/faces/DocContentDisplay?id=1291766.1. Other accounts
not included in that note are listed below.

Table 32-5 User Accounts

User Name and Password User Type Component

opc - key-based login only Operating system user Oracle Exadata Database
Servers
exawatch (release 19.1.0 and Operating system user Oracle Exadata Database
later) - no logon privileges Servers
Oracle Exadata Storage
Servers
SYS/We1come$ Oracle Database user Oracle Exadata Database
Servers
SYSTEM/We1come$ Oracle Database user Oracle Exadata Database
Servers

32-16
 Chapter 32
Additional Procedures for Updating Security Posture

Table 32-5 (Cont.) User Accounts

User Name and Password User Type Component

MSUser ILOM user Database server ILOMs
Management Server (MS) Oracle Exadata Storage
uses this account to manage Server ILOMs
ILOM and reset it if it detects a
hang.
The MSUser password is not
persisted anywhere. Each time
MS starts up, it deletes the
previous MSUser account and
re-creates the account with a
randomly generated password.
Do not modify this account.
This account is to be used by
MS only.

Pay Attention to What Actions May Impact Service-Related Logins for Cloud
Automation
For example, procedures will include ensuring that authorized keys used for cloud
automation actions remain intact.
For more information about Physical Network access controls including guidelines
for Oracle Cloud Automation, see Oracle Gen2 Exadata Cloud@Customer Security
Controls.
Oracle Cloud Automation access to the customer VM is controlled through token
based SSH. Public keys for Oracle Cloud Automation access are stored in the
authorized keys files of the oracle, opc, and root users of the customer VM.
The private keys used by the automation are stored and protected by the Oracle
Cloud Automation software running in the Exadata Cloud@Customer hardware in
the customer’s data center. The customer’s OCI Identity and Access Management
(IAM) controls govern if and how a customer can execute Oracle Cloud Automation
functionality against the customer VM and databases. The customer may further
control access through the management network and Oracle Cloud Automation
keys by blocking network access (firewall rules, disabling network interface), and by
revoking the credentials used by the Oracle Cloud Automation (remove the public keys
from the authorized keys files). Oracle Cloud Automation Access may be temporarily
restored by the customer to permit the subset of functionality required to access
the customer VM and customer databases, such as customer VM operating system
patching. Oracle Cloud Automation does not need network access the customer VM
to perform OCPU scaling, and OCPU scaling functionality will function normally when
customers block Oracle Cloud Automation network access to the customer VM.

Configure Encrypted Channels for Database Listener (Oracle Net) Connectivity

For more information, see Configuring Oracle Database Native Network Encryption
and Data Integrity.
Related Topics
• Managing the Keystore and the Master Encryption Key
• https://support.oracle.com/epmos/faces/DocContentDisplay?id=1291766.1

32-17
 Chapter 32
Additional Procedures for Updating Security Posture

• Oracle Gen2 Exadata Cloud@Customer Security Controls

• Configuring Oracle Database Native Network Encryption and Data Integrity

32-18
Index

Index-1