ORACLE CLOUD

INFRASTRUCTURE (OCI)
What Makes it Unique for Your Oracle Workloads in the Cloud

Simon Pane,
Principal Consultant
Oracle ACE

Co Author
Nelson Calero
Internal Principal Consultant
Oracle ACE Director
Oracle Certified Expert

There have been options for running Oracle database workloads in the cloud for
many years. In fact, Amazon Web Services (AWS) was clearly one of the first places
to run Oracle databases in the cloud either on IaaS (AWS EC2) or through their
Relational Database Service (RDS).

Recently Oracle has been promoting their 2nd generation cloud known as Oracle
Cloud Infrastructure or “OCI”. But what makes OCI a more compelling option for
cloud database workloads and what are the limitations?

OPTIONS FOR RUNNING ORACLE WORKLOADS IN OTHER CLOUDS

Running Oracle Database workloads in non-Oracle clouds falls into two general
buckets: a build-your-own system based on cloud-based Infrastructure (IaaS) and
managed database services.

www.pythian.com | White Paper 1

 The former is quite similar to what you can do yourself on-premises with a few notable
exceptions. The main difference is that the infrastructure is provisioned in the cloud
service provider’s data center, is most often but not exclusively virtualized, and is
typically on shared infrastructure (at least to some degree). In such a configuration,
once the virtualized/cloud hardware is provisioned, it’s up to the administration team
to configure the OS, download and install the Oracle software, create the required
databases, setup the expected options for protection such as Data Guard replication
between cloud geographic regions (as the cloud does have outages), and eventually
migrate the data. Basically all of the same steps they would do on-premises.

With the other option of having a managed database service, AWS RDS is really
the main non-Oracle option. RDS takes care of server set up, software provisioning,
database creation, data backup, patching, and DR options if required. All based on
user inputs specified during provisioning. However, RDS is significantly locked down.
There’s limitations in what initialization parameters can be adjusted, limited access
to database internal APIs (some access is wrapped into Amazon-provided APIs), no
access to the underlying operating system, and non-direct workarounds for accessing
or viewing generated log and trace files.

Regardless of the cloud vendor and whether IaaS or a DBaaS option is chosen, a few
things are not possible (at least not in an Oracle-supported manner) in non-Oracle
clouds. Mainly:
• Oracle Real Application Clusters (RAC)
• Oracle Exadata (Engineered Systems)

There are some technical workarounds for building Oracle RAC databases in non-
Oracle clouds, often involving third party software. But the Oracle support position on
such deployments is complex. For a more complete explanation, refer to the Oracle
supplied white paper called “Oracle Real Application Clusters (RAC) Support on Third-
Party Clouds - An Overview and Clarification”

At one point the Oracle Multi tenant option was also restricted in third party clouds but
that restriction has since been lifted, likely as Oracle wants to push customers towards
the container database (CDB) architecture. The non-CDB architecture is currently
available but deprecated and in the future will be removed.

UNIQUE WAYS TO RUN ORACLE DATABASES IN OCI

OCI offers far more flexibility for running more advanced database configurations
in the cloud. OCI configurations include:
• Databases built on IaaS based “build it yourself” implementations.
• A managed service on Virtual Machines (VMs) or Bare Metal (BM) with
RAC options.

www.pythian.com | White Paper 2

 • Exadata Cloud Service (ExaCS).
• Autonomous Database (ADB) which is comprised of Autonomous Data
Warehouse (ADW) and Autonomous Transaction Processing (ATP).

So in addition to the core OCI technical differentiators such as off-board

networking, OCI provides unique database configurations including fully supported
RAC databases, engineered system options, and the new autonomous database.
Hence the ability to more closely mimic a typical on-premises configuration.

OCI’s managed database service (called the “DB Service”) is also more elaborate
than AWS RDS. Clearly the first few main differentiators are the options for
RAC databases and to build on powerful bare metal (BM) servers in addition to
traditional VMs.

Beyond that, the OCI DB Service provides a lot more access. You’re given full access
to the database, including access to the SYS and SYSTEM users, as well as nd full
“Oracle software owner” and root access to the underlying operating system.

But full access brings the ability to break things. For example, it’s possible to move
listeners to a different port, apply patches manually, or even create new databases
manually using the DBCA. But doing so will effectively “break” the managed part
of the managed service. This means that a database added manually through the
DBCA instead of the OCI-specific tools or web console won’t appear in the OCI
console, won’t be monitored by the new OCI monitoring service, and won’t benefit
from the simplified patching tooling that the service provides. Just because you
can, doesn’t mean that you should.

The line between what can be done and what should be done is a little bit
blurry. The best way to ensure that you stay on the proper side of that line is by
administering the system and the database only through the OCI-provided tooling
such as the OCI web console, OCI-specific command line utilities including dbcli,
dbaasapi, and the OCI CLI utility, or the REST APIs.

TECHNICAL LIMITATIONS OF DATABASES IN OCI

While OCI does allow for configurations that more closely mirror what may be
deployed on-premises, not everything is possible.

Some key limitations worth understanding would include:

• DB Service limitations such as only a single database on VMs or a single
DB per Oracle home on BM deployments with Oracle listeners listening on
default ports only.
• A limitation of only two-node RAC implementations with the VM DB Service
and 2, 4 or 8 node RAC configurations in ExaCS (depending on the shape
used). Currently, RAC is not possible in the BM service.

www.pythian.com | White Paper 3

 • A predefined list of available Oracle database versions with the DB Service
and no ability to specify the exact version or release of the supporting Grid
Infrastructure software.
• No access to any ExaCS components beyond compute nodes.
• No option to build a custom RAC database using IaaS.

That last point is one that often takes people by surprise. Some hear the message
that RAC is available and is supported on OCI which is technically true. But only
in certain configurations. Specifically 2-node RAC databases on the VM-based
DB Service or as 2, 4, or 8 node RAC databases with ExaCS. What you cannot do
is build your own custom RAC with a size and shape of your choosing based on
IaaS. OCI still lacks the shared block volume storage, dedicated interconnect, and
multicast networking options required to support that.

PACKAGING AND LICENSING

Another key benefit of OCI is that the features and options have been re-packaged.
This gives customers easier options to use more advanced Oracle features with, in
many cases, a consumption-based model.

Traditionally, Oracle database customers have needed to purchase either Oracle

Standard Edition (SE) or Enterprise Edition (EE) licenses. Then on top of EE, they can
add additional separately licensed “options” that add technical functionality and
are often referred to as “packs”. Examples of separately licensed options (packs)
would include things like Partitioning, Advanced Compression, Database Vault, Real
Application Testing, Advanced Security, etc.

OCI supports a BYOL model and a license-included model. With the latter, rather
than first choosing the addition and then adding in the required Option Packs
(choosing out of more than a dozen), the license-included database services are
grouped into four editions:
• Standard Edition
• Enterprise Edition
• Enterprise High Performance
• Enterprise Extreme Performance

The last two are new and are cloud-unique offerings. Each includes several of the
aforementioned Option Packs.

And a nice plus is that all four editions include Oracle Database Transparent Data
Encryption to support database-based data encryption at rest in the cloud.

Between the new edition-based packaging and new cloud-based price points
including consumption-based (i.e. “pay as you go”) models, it makes using the
Oracle database arguably more cost-effective in OCI. Exact costs change at

www.pythian.com | White Paper 4

 Oracle’s discretion and hence are beyond this discussion. The key takeaway,
however, is that OCI provides different packaging and a more utility-based pricing
model unique to OCI.

OCI EVOLUTION AND FUTURE DIRECTION

OCI is evolving rapidly, arguably at a faster pace than other clouds as it’s a newer
platform. And some key new options will be available by the end of 2019.

The recently announced interconnect to Microsoft Azure. This really gives customers
the best of both worlds allowing them to take advantage of Azure-specific offerings such
as Azure Active Directory and Office365 while not having to compromise on their Oracle
database configurations.

Prior to this, customers wanting to move into Microsoft Azure, but with complicated
Oracle database infrastructure, had some limitations:
• They could keep the Oracle part of their estate on-premises, hence, making
a hybrid-cloud deployment, meaning that they couldn’t fully divest of their
existing data centers.
• They could simplify their complicated Oracle workloads and run single-
instance only databases on Azure IaaS.

The new Microsoft-Oracle cloud interconnect adds the third option of an easier-to-
implement and a more tightly coupled multi-cloud deployment. Hence, they can fully
divest of existing data centers and use Azure for what it’s best for and OCI for what it’s
most suited for.

For this reason it’s probably a big step in the right direction for Oracle and their
customers. And will likely lead to more adoption of OCI in this multi-cloud model. And as
OCI adoption grows, so does its capabilities, scale, locations, and reliability.

Initially the Azure-OCI interconnect is in the popular U.S.-Virginia (Ashburn) region only
but this will likely expand rapidly.

CONCLUSION
There’s no doubt about it: OCI offers by far the most options and arguably at the best
price point for running non-trivial Oracle database workloads in the cloud. It matches
the functional capabilities of other clouds from a “build-it-yourself” perspective on IaaS
with their own uniqueness in the underlying infrastructure (i.e. compute shapes and
VM networking differences). It offers a DB Service which far exceeds the capabilities of
Amazon’s RDS by giving options of VM or BM offerings and full access to the database
and underlying OS. Plus the option of RAC on VMs. At the high end of the performance
perspective, the ExaCS service gives customers the full power of an Oracle Exadata-
based database but in the cloud without the procurement and long term commitment

www.pythian.com | White Paper 5

 of an on-premises Exadata acquisition. And the new Autonomous Database provides
a fully managed and dynamically scalable database service, leveraging Oracle’s most
powerful hardware and software combination under the hood.

With over 20 years of experience managing the world’s most complex Oracle
systems, Pythian’s certified experts can help you maximize your investment in
Oracle technologies. Pythian’s certified Oracle experts configure your architecture
to suit your unique processes and continuously maximize the performance of your
environment with our renowned 24x7x365 support. By combining the platform
with the people who know it best, we can ensure constant system optimization,
network monitoring, and performance that you can depend on.

Contact us to speak with our Pythian experts.

www.pythian.com | White Paper 6

 THE AUTHORS

Simon Pane
Principal Consultant
Oracle ACE

Simon is an accomplished Principal Consultant, who has developed

a multitude of complex solutions for Pythian clients. He leverages his
understanding of the industry and technologies such as Oracle, SQL Server,
Linux, Oracle Cloud, AWS and more, to propose timely solutions that best suit
the needs of clients. As a technology enthusiast, Simon is a highly sought-
after speaker at many user groups and international conferences.

Nelson Calero
Internal Principal Consultant
Oracle ACE Director
Oracle Certified Expert

Based out of Montevideo, Uruguay, Nelson enjoys a beautiful ocean view

working from home as an Oracle Database Consultant. In addition to being
the Founder and President of the Uruguayan Oracle User Group (UYOUG),
Nelson has contributed to the community by frequently speaking at industry
events, and working as an Instructor at Oracle University. He loves facing
new challenges at work, and confronts them by pushing boundaries to create
new solutions. When he isn’t working, Nelson enjoys photography, spending
time with his family and travelling.

info@pythian.com twitter.com/Pythian

linkedin.com/company/pythian +1-866-798-4426

ABOUT PYTHIAN
Founded in 1997, Pythian is a global IT services company that helps organizations transform how they compete and win by helping them turn data into valuable
insights, predictions and products. From cloud automation to machine learning, Pythian designs, implements and supports customized solutions to the toughest
data challenges.

OFFICES
Ottawa, Canada London, England
New York City, USA Hyderabad, India

www.pythian.com | White Paper 7

V01-072019-NA