Oracle Cloud

Best Practices for operating Exadata Cloud Service and Exadata Cloud@Customer

Introduction

Oracle Exadata Database Machine is an optimized system specifically developed to run Oracle Databases providing high availability, high capacity, cost efficiency, and superior performance. It uses unique and intelligent Exadata software and ultra-fast internal network fabric supporting every kind of application workload. So it is little surprise that Oracle uses Exadata as their ONLY platform to run ALL their Autonomous Database offerings in the cloud and in customer’s data centers as Cloud@Customer.

Additionally, Oracle offers the Exadata Cloud Service in the Oracle Cloud (ExaCS), running on Exadata Infrastructure too, as the name reveals. It provides more customization, flexibility to choose your database release version and follow your own patching and upgrade timeline while still having a ton of automation to simplify your database life cycle management. The Exadata Cloud Service is also available as Cloud@Customer (ExaCC) offering, having the hardware in your own data center for lower latency and regulatory compliance.

The Responsibility Model

Whether ExaCS or ExaCC, Oracle is responsible for the hardware stack up to and including the hypervisor, while the customer is responsible for the VM cluster (DomU) and everything inside. In the case of Autonomous, Oracle is responsible for DomU and databases too, and the customer only for their data.

On traditional Exadata machines on-premises on the left side, the responsibility model is very clear. The customer purchases and owns the hardware and is responsible to manage the full stack.

On the right side, the customer subscribes to the Autonomous Database service in the Oracle Cloud or Cloud@Customer. Oracle is responsible to manage and maintain the full stack including DomU and the databases. The customer just gets a SQL*Net connection and is responsible for their data. Very straightforward.

ExaCS and ExaCC in the middle is a mix of both, therefore it is also referred to as “Co-Managed” service sometimes. Oracle owns, manages, and controls the storage servers, the network, the database servers, and the hypervisor. The customer subscribes to the service and is responsible for DomU and the databases. Everything’s fine, right? Yes! But let’s dig deeper.

The Operational Model

It is obvious that you manage and operate what you are responsible for, right? So we end up with the same picture as above?

The thing here is not about who, but HOW? In ExaCS and ExaCC you get full root access to the VMs and SYSDBA privileges to the databases. Hence, you are technically able to do ANYTHING you want on the virtual machines. But only because you are able to do something does not mean you should do it.

Even Cloud@Customer is CLOUD before being @Customer. Even if you put it in your basement at home, next to your freezer, it is still a Cloud Service. It is a pretty nice machine and too bad to put it in the basement. If I had one, I’d rather put it in my living room.

You WANT to use this Cloud Service to benefit from the automation and simplified management it provides.

The message is, you are responsible for operating and monitoring DomU and the databases, but you should use the Cloud automation that Oracle provides and recommends. Therefore, from the operational perspective, we could say that there is “some red color” in that picture in the DomU and database sections.

For sure, you are the one and only one responsible for DomU and the databases. If you want, no one will prevent you from completely ignoring that “some red color” and keep using your on-premises approach. But this is not why you WANTED to use a Cloud Service.

Automation

We mentioned cloud automation a few times now. So let’s have a look at what tasks can be done by using cloud automation:

  • Exadata Infrastructure: create, terminate, manage contacts, and define maintenance window.
  • VM cluster: create, terminate, scale-up/down OCPU/Memory/Storage, add SSH keys, and update license type.
  • Grid Infrastructure (GI): patch and upgrade. GI is automatically installed when the VM cluster is created.
  • Virtual Machines: stop, start, restart, and patch the operating system.
  • Custom Database Software Images: create and delete.
  • Oracle Homes: create, terminate, and patch.
  • Oracle Databases: create, terminate, enable automatic backup, edit backup settings, restore, move to another Oracle Home, patch, and upgrade. Transparent Data Encryption (TDE) is set up and enabled by default.
  • High Availability: databases are created as Real Application Clusters (RAC) databases by default.
  • Disaster Recovery: build (Active) Data Guard environments, Switchover, Failover, and Reinstate.

For these tasks, you’d use what’s called Cloud Tooling. These include the web-based UI, OCI CLI, SDKs, and REST APIs. Have a look at Command Line Interfaces (CLIs) in the Oracle Cloud for more information about the different tools available and when to use them.

Additionally, Oracle provides you with the dbaascli command line to manage PDBs and the Zero Downtime Migration tool to automate your database migration to Oracle Cloud.

Operational Best Practices

Your Exadata Cloud Service machine is immediately assigned to you (ExaCS) or delivered to your data center within few weeks (ExaCC). But what is next? If you should not operate it as an on-premises machine, how then?

  • Use the Cloud Tooling for all the tasks supported as mentioned in the Automation section above.
  • Customize as little as absolutely necessary. When you change a default configuration, make sure that operations via Cloud Tooling are not impacted.
  • Schedule Infrastructure Maintenance Windows quarterly. Postpone a maintenance window only if absolutely necessary.
    • When using Data Guard, schedule the Maintenance Window for your standby infrastructure to occur before the Maintenance Windows for the primary infrastructure. After patching, switch over to the standby infrastructure, so infrastructure patching always occurs on the standby.
  • Create as few VM Clusters as needed to save resources and minimize the management effort.
  • Create Custom Database Software Images and include any needed one-off patches.
  • Use Custom Database Software Images to create new Oracle Homes.
  • Create as few Oracle Homes as needed to save resources and minimize the management effort. Ideally, all your databases are at release version 19c and at the same and latest Release Update (RU).
  • Create all your databases as RAC databases across all cluster nodes (the default) for database high availability and manageability via Cloud Tooling.
  • Create user-defined database services to control accessibility and high availability settings.
  • Implement (Transparent) Application Continuity for your applications to automatically replay any aborted transactions caused by planned and unplanned downtime.
  • When enabling Data Guard across regions, choose the Maximum Performance (ASYNC) protection mode if the latency between the primary and standby region is higher than 5ms.
  • Use the recommended Multitenant Architecture and create as few CDBs and as many PDBs as appropriate according to your requirements and resource planning.
  • Patch your Operating System, Grid Infrastructure, and databases with the latest patch available.
  • Patch your databases with Release Updates (RUs) by moving them to a new Oracle Home (out-of-place patching) to minimize downtime and reduce risk.
    • Alternatively, patch single PDBs by moving them to already patched CDBs and running datapatch for the PDB afterward. Use Refreshable Clones to minimize downtime.

Conclusion

A Cloud Service provides standardization and automation to make your daily work easier, faster, and less error-prone. Benefit from this automation and have more time to focus on data and business value instead of operational tasks. This is why you have chosen a Cloud Service.

Further Reading

Would you like to get notified when the next post is published?