Oracle s Autonomous Database

18c: An Initial Assessment

Machine learning meets the DBA

Publication Date: 21 Nov 2017 | Product code: INT002-000011

Tony Baer
Oracle s Autonomous Database 18c: An Initial Assessment

Summary
Catalyst
Oracle has raised the stakes in its rivalry with Amazon with the introduction of the latest version of its
database: Oracle Database 18c. With its cloud-first strategy, Oracle will be introducing the platform
initially in its Exadata Public Cloud. But that does not tell the full story: The database that debuts in the
cloud will be what Oracle terms "autonomous." It will be a self-running database that will be controlled
using a combination of database and cloud automation, which is guided by machine learning (ML).
Although Oracle is not the first vendor to talk about the idea of a database running itself, by
December, it will be the first to actually have a cloud service running it. Initially, Oracle is targeting the
most straightforward use case: data warehousing. Future additions will target OLTP and mixed
workloads, followed later on with an autonomous edition of a new NoSQL platform.

Ovum view
The Oracle autonomous database capitalizes on existing automation built into the Oracle Public Cloud
and the Oracle Database and utilizes ML, an idea whose time has come. The most straightforward
part of autonomous operation is patching and repair; that is already part of most managed cloud
database services today – Oracle and non-Oracle. Tuning operations present more complex and
variable challenges; this is where the autonomy kicks in. Because data warehousing has a well-
defined pattern of workloads, it is Oracle s obvious first target for its autonomous database. Handling
mixed OLTP and analytic workloads will be clearly more challenging. Being first out of the gate with an
autonomous database will bolster Oracle s competitiveness regarding its own cloud for its own
database.The good news is that ML, by its nature, should get better over time as Oracle runs more
autonomous database workloads in its cloud. As with any 1.0 release, customer expectations should
be modest; treat the autonomous database as a journey where the most important (and attainable)
short-term goal will be ironing out the headaches of patches, and where the most elusive goals (which
will improve over time) will be in the self-tuning. Hold Oracle s feet to the fire for what it is promising:
consistent performance and lower costs.

Key messages
 Applying ML to database operation is an idea whose time has come.
 The autonomous database will be a journey; Oracle s first step (targeting analytics with the
goal of consistent performance) is a realistic one.
 As this is a 1.0 release, customers should keep their expectations modest, but should hold
Oracle s feet to the fire for what it is promising: consistent performance and lower costs.
 The biggest challenge for Oracle will be winning DBA trust that autonomy will be "better" than
human control. The biggest challenge for customers will be how to best redeploy DBAs when
the bane of their existence (keeping the lights on and the database optimized) is magically
lifted off their shoulders.

© Ovum. All rights reserved. Unauthorized reproduction prohibited. Page 2

Oracle s Autonomous Database 18c: An Initial Assessment

Recommendations
Recommendations for enterprises
Ovum expects that, for data platforms, managed cloud services (database-as-a-service, or DBaaS)
will provide more bang for the buck for enterprises, because they will more effectively deliver on the
promise of operational simplification. A key draw for managed DBaaS is that it automates much, if not
all, of the legwork for provisioning infrastructure, patching, and healing; this was already supported by
Oracle s management database services in its managed database services in its Public Cloud (and
Cloud at Customer), not to mention DBaaS services from all the other major cloud players.

Self-running, or "autonomous," databases are the next logical step in that process; this is all about the
database making its own decisions on where to deploy and partition data. If implemented properly,
this should further lift the load off DBAs shoulders. Growing experience with ML is making the idea of
the self-running database thinkable because it provides a far more flexible approach that can "learn"
over time compared to static rules-based approaches. The easy part is automation; the challenge is
optimization and tuning, where the real decisions happen.

Oracle is not the first to put ML on the agenda for running its database; Microsoft has made similar
pronouncements for the future roadmap for SQL Server, and there is significant research ongoing in
the academic communities on how to use ML to replace all the "knobs" that DBAs use to configure the
database. Over the next year, we expect that Microsoft (and others) will also jump on this bandwagon.

Approach this like any v1 release, trying it with pilot or standalone new development projects. Coming
out of the starting gate, Oracle is shooting for consistent performance; if you are looking for extreme
performance, wait for a future Oracle release. Hold Oracle s feet to the fire with its
 promised SLAs: three nines (for "standard" workloads) or four nines (for mission-critical
workloads, equivalent to a half hour of downtime per year) for the enterprise and mission
critical-tiers, respectively
 guarantees to underprice Amazon Redshift or Oracle RDS services by 50% (actually, the RDS
promise will not be hard to meet, given Oracle s pricing for Amazon RDS).

More importantly is the people and process part. Self-running databases will not put DBAs out of
work. But a key battle will be winning their confidence that self-running is more practical than turning
knobs. The best way to win over skeptics is running side-by-side benchmarks based on your
workloads as part of your pilot. Should the result prove satisfactory, the question becomes how well
will your DBAs acclimate and how effectively can your organization best deploy them to higher value-
added tasks? Given the state of most IT backlogs, the problem will not be finding tasks, but getting
DBAs to be sufficiently comfortable to relinquish day-to-day control.

Recommendations for vendors

Oracle is the first vendor to actually implement ML in the operation of the database. ML is the final
piece to fall into place (atop database automation and cloud automation) that allows Oracle to ditch
the DBA control knobs and have the database run itself.

Applying basic ML (as opposed to deep learning or cognitive computing) is becoming better
understood, especially by cloud platform providers that are already offering ML services. Compared to
problems such as automating customer interaction, running a database is a relatively well-bounded

© Ovum. All rights reserved. Unauthorized reproduction prohibited. Page 3

Oracle s Autonomous Database 18c: An Initial Assessment

problem (although the optimizations will vary because you cannot apply the same recipes for analytics
databases to operational NoSQL databases or SQL OLTP systems). We expect cloud platform
providers of managed database services to offer self-running services for single-purpose (workload)
platforms as logical extensions of their managed services within the next 12–18 months. Enterprises
seeking managed cloud database services should be very receptive to self-running operation.

Oracle s unveiling of autonomous database capabilities for 18c is restricted to Oracle-managed cloud
for one valid reason: Variation is too infinite for the vendor to be accountable. But ML techniques
applied to self-running databases could also be applied to implify the operation of on-premises
databases. Oracle and competitors should take note.

The features of Oracle Database 18c

Note on terminology: When we refer generically to databa e acting autonomou ly, we will u e the
term " elf-running." When we de cribe the autonomou capabilitie of Oracle Databa e 18c, we will
u e Oracle' "autonomou " branding.

General outline of the release

Cloud- irst release
Oracle is following its cloud-first policy for releasing Database 18c. The headline may describe it as an
"autonomous database," but this only refers to implementations of Database 18c that run on Oracle s
Exadata Public Cloud and Exadata Cloud at Customer. In actuality, Database 18c and "autonomous"
are not synonymous. On-premises deployments of 18c will not be autonomous because Oracle
cannot control the environment; the customer runs their own mix of hardware software, network
backplane, and storage. The initial release of Database 18c, scheduled for December 2017, will be a
specialized Oracle Public Cloud and Oracle Cloud at Customer implementation of the 18c Database
on Exadata. Oracle has not disclosed when the on-premises version will be released, but if past
practice with the 12c generation is followed, it will happen about six months later.
While the initial Oracle autonomous database release will be confined to data warehousing, it will
follow up with OLTP/mixed workloads later in 2018, and be subsequently followed by releases of a
multimodel NoSQL database and a developer database.

Oh, and by the way, what s the deal with the skip in version numbering? The latest version was 12c
release 2, which was first announced back in 2013. So, what happened to Databases 13, 14, 15, 16,
and 17? Oracle is shifting to an annual release schedule. That makes more sense given that Oracle is
going to a cloud-first release strategy, and cloud platforms tend to be refreshed far more rapidly than
on-premises versions.
Two tiers o service
Database 18c will be offered with two tiers of service. The enterprise service will deliver three nines of
availability (99.95%), while the mission-critical service will offer four nines (99.995%), which amounts
to a half hour of down time per year. The mission-critical service adds Oracle Active Data Guard for
high availability and disaster recovery to meet the stricter SLA.

© Ovum. All rights reserved. Unauthorized reproduction prohibited. Page 4

Oracle s Autonomous Database 18c: An Initial Assessment

Per ormance and service levels

Oracle promises that Database 18c, operating autonomously under the premium (mission-critical)
service tier, will incur less than a half hour of down time per year. At the opening keynote for Oracle
OpenWorld, Larry Ellison demonstrated four Oracle-run benchmarks, using stress tests from various
Oracle clients across different sectors. He compared Database 18c in the Oracle Public Cloud with
Amazon Redshift and a version of Oracle running in the Amazon RDS database service. In general,
the results of Oracle s test showed 5–8x improved performance and lower costs, plus or minus. As a
result, Oracle is raising the stakes with Amazon, offering to write into its contract with Oracle 18c
customers in the Oracle Public Cloud that Oracle s costs will be half those of AWS – regardless of
whether customers are using Redshift or RDS. We always take benchmarks with a grain of salt. But
incorporation of ML into the database is a logical move for automating the routine duties that the DBA
performs. If ML models are sufficiently validated, they should be able to outperform humans.
Oracle components required or autonomous operation
The Oracle autonomous database will include several key features that may or may not be part of on-
premises implementations. For starters, it only runs on the Oracle Exadata Cloud, not the Oracle
Database or Oracle Database Express Cloud. Its features include
 Oracle RAC for scaling out the database
 Oracle Multitenant, which takes advantage of the pluggable database feature introduced in
Database 12c so that multiple databases can be administered and configured under a
common umbrella without changing the application
 Oracle Active Data Guard, which is used by the mission-critical service.

Although the autonomous database does not include the usual DBA knobs, it will provide REST-based
interfaces so that all lifecycle operations (e.g. activating or deactivating services, growing compute or
storage, and managing access keys) can integrate into the customer s existing automation stack,
such as ServiceNow for trouble ticketing, OpenStack, and Cloud Foundry.

What makes Oracle Database 18c "autonomous"?

Database automation is nothing new
Database automation for core housekeeping functions such as memory management and query
rewrites are not new. (Oracle already had them, and it is not alone.) Furthermore, automation of
maintenance functions such as patch management and self-repair is a pillar of managed cloud
database services from Oracle and its prime rivals. For instance, Amazon s Relational Database
Service (RDS) already automates provisioning, patching, backup, recovery, failure detection, and
repair of the database. Its Aurora database on RDS (MySQL is available, with PostgreSQL in preview)
automatically shards and replicates data.

ML is coming
The "secret sauce" of self-running databases is training ML algorithms on the vast corpus of database
logs. As opposed to rules, which are static, properly designed ML algorithms improve with use as they
digest more scenarios and events. Oracle is not the only provider talking about applying ML to

© Ovum. All rights reserved. Unauthorized reproduction prohibited. Page 5

Oracle s Autonomous Database 18c: An Initial Assessment

optimize the operation of the database: Microsoft recently disclosed that ML for running the database
is on the roadmap for its SQL Server 2017 and Azure SQL Database.

Self-running ("autonomous") functions

Oracle s autonomous database features are based on the idea that the database will be
 self-driving, where the user defines the service levels and the database then operates to
those specifications
 self-securing, where security measures to protect against internal and external threats are
automatically implemented
 self-repairing, where the database automatically fixes problems on the fly, without taking the
system offline.

The autonomous database s operable notion is eliminating legwork (e.g. the need to use tuning
knobs) for the DBAs. Specifically, it will aid
 configuration and tuning of systems, network, and storage
 database provisioning and patching
 backups, H/A, and disaster recovery
 database optimization.

As a result, the autonomous database does not come with Oracle Enterprise Manager (OEM). Neither
will Database and OS Administrator privileges be provided; exception and failure cases will be
handled by Oracle itself.

How autonomy works

Self-driving means that the database handles the provisioning of scale-out clusters; all patching;
testing and change management of applications and workloads; all monitoring and resource
management; and all failures and errors. This is what differentiates Database 18c from existing
managed cloud database services that use automation. One of the few knobs that the customer will
have involve when quarterly full-stack updates and patches are applied. Oracle promises no
downtime for patching.

Otherwise, the database will automatically scale CPUs and storage services (within the customer s
defined infrastructure footprint) to support full elasticity. This is where CPUs can be turned off by the
customer during periods of non-use. In the future, we expect that Oracle will add policy-based
automation such as automatically scaling up or down compute by time of day and week. The
database will automatically build indexes and implement partitions without DBA input. It will also
automatically tune the SQL (a function where ML will play a significant role).

As for optimization and tuning, initially Oracle will optimize for consistent, rather than extreme,
performance – a preference that it believes prevails among the bulk of its customers. Another
differentiator is the use of ML in the cluster health monitor for detecting anomalous events and
recommending (or automatically implementing) corrective actions. Admittedly, (as noted earlier) ML
could be applied to database automation as well.

This is also where the choice of analytics workload makes sense as the first service to be introduced,
although it is hardly a simple challenge. In general, analytics workloads have more common

© Ovum. All rights reserved. Unauthorized reproduction prohibited. Page 6

Oracle s Autonomous Database 18c: An Initial Assessment

characteristics than OLTP use cases, which increasingly also involve analytics. But within the
analytics space, there is significant variation of workload profiles. At one end of the spectrum is
reporting workloads that typically involve simple or only moderately complex queries with relatively
predictable resource consumption that in some cases may also require high concurrency. Then there
are interactive queries that may be relatively simple but have less predictable resource consumption
profiles. At the extreme end of the spectrum are forecasting, predictive, and other forms of advanced
analytics, where the queries are complex, and often highly resource-intensive. However, because
analytic workloads can take better advantage of capabilities such as columnar tables, compression,
and parallelization compared to OLTP, they present a much simpler target for optimization. Oracle
promises to have an autonomous release for OLTP/mixed scenarios next year. But, as noted above,
because OLTP workloads typically involve mixed scenarios, we expect that they may require some
DBA knobs.

Automation of security is a table-stakes feature for cloud-managed database services. At a later date,
Oracle will introduce new cybersecurity cloud services for autonomous Database 18c that will apply
ML to log files to detect and prevent anomalous activity. In the meantime, the autonomous database
will apply security patches on an ongoing basis and use Oracle Database Vault to prevent Oracle
cloud administrators from seeing user data, while allowing encryption keys to be managed by the
customer s security module.

Error handling will be similarly closed-loop. When errors occur, the database will isolate the problem
through log analysis and regression tests, applying ML for root-cause analysis and for preventing
recurrence of these conditions. And for self-repair, the database will automatically apply the patches to
resolve issues.
Table 1: Oracle's existing database automation capabilities
Oracle Database 9i, 10g Oracle Database 11g, 12c

Automatic Storage Management (ASM) Automatic SQL Tuning

Automatic Memory Management Automatic Workload Replay

Automatic DB Diagnostic Monitor (ADDM) Automatic Capture of SQL Monitor

Automatic Workload Repository (AWR) Automatic Data Optimization

Automatic Undo Tablespaces Automatic Storage Indexes

Automatic Segment Space Management Automatic Columnar Cache

Automatic Statistics Gathering Automatic Diagnostic Framework

Automatic Standby Management (broker) Automatic Refresh of Database Cloning

Automatic Query Rewrite Automatic Health Framework

Source: Oracle

© Ovum. All rights reserved. Unauthorized reproduction prohibited. Page 7

Oracle s Autonomous Database 18c: An Initial Assessment

Autonomy is an evolutionary journey

The autonomous database is the culmination of three trends:
 Automation that already underlies the Oracle Public Cloud (where the database PaaS service
automates updates and patches)
 Automation features that have been introduced to the Oracle database as far back as the 9i
generation a decade ago (see Table 1)
 The maturation of experience with ML to close the loop.

Oracle s autonomous database represents evolution, not revolution. For instance, a decade ago, IBM
was floating ideas of autonomic computing. But there is a reason why the idea of autonomy today
stands a more realistic chance compared to those early approaches for self-running computers.
Those early approaches were based on rules, whereas today, there is a broader base of systems
automation plus advances in ML to make the idea practical.

Let us first look at database automation. Table 1 shows the growing degree of automation in the
Oracle database, dating back to the 9i generation roughly a decade ago. Now atop that, the Oracle
Public Cloud also provides automation for functions such as software patching and upgrading. But
automation does not make a database autonomous. As mentioned earlier, Oracle defines autonomy
as a database that automatically operates to the user s specifications and automatically applies
security patches, diagnostics, and repairs.

Individually, each of these functions is a matter of automation. The decision-making, such as how to
perform these tasks, is where the autonomy comes in. The DBA does not provision, configure, or tune
the system to meet the specified SLAs. Neither does the DBA run the backups, restores, or patching
to keep the database running. Oracle has taken away the knobs that DBAs typically use to monitor
and run the database. For instance, DBAs do not get Secure Shell (SSH) access to the internals of
the database engine, nor does Oracle supply its Oracle Enterprise Manager (OEM) for monitoring.
Furthermore, Oracle has removed the lengthy list of questions that would otherwise be required for
customers to get an instance of the database up and running in the Oracle Cloud. The database now
only asks for name; region (i.e. which Oracle cloud data center); number of CPUs; size of storage (in
TBs); and the admin password. There are also a few optional questions regarding identifying the
object store.

Coming out of the starting gate, the goal is prioritizing consistent performance over peak performance.
This come despite the impression conveyed during Ellison s opening keynote regarding performance
numbers compared to several alternatives on Amazon, which are discussed in more detail below.

So how does Amazon compare?

Given that Amazon is the clear target for Oracle s autonomous database offering, here is how the
rivalry stacks up. Amazon s managed database services (RDS, Aurora, DynamoDB, and Redshift)
provide the automation that is customary for DBaaS services. They manage routine database tasks
such as failure detection, repair, and patching, but do not currently employ ML to optimize how they
are run. There are some differences in the degree of operation that is automated:
 Amazon RDS automates common administrative tasks such as performing backups and
patching the software. With optional Multi-AZ (Availability Zone) deployments, Amazon RDS
also manages synchronous data replication across AZs with automatic failover.

© Ovum. All rights reserved. Unauthorized reproduction prohibited. Page 8

Oracle s Autonomous Database 18c: An Initial Assessment

 Amazon DynamoDB automatically upgrades, patches, and tunes itself while running and
automatically scales your storage up as your capacity needs grow. With AWS DynamoDB,
you create a database table, set your target utilization for autoscaling, and let the service
handle the rest. This eliminates database management tasks such as hardware or software
provisioning, setup and configuration, database upgrade, monitoring, performance tuning,
data center replication, security patching, operating a reliable distributed database cluster,
and partitioning data over multiple instances as you scale.
 Amazon Redshift automatically upgrades minor (dot) releases, but gives the user the option to
disable major version upgrades. Users can choose automatic or manual snapshots for
backing up Redshift to S3 cloud storage. They also choose node types. Redshift includes a
query optimizer that can be used for tuning.

More grist for Amazon: Oracle is guaranteeing autonomous

database to be half the price
Here s a new one: Oracle will actually write into its contracts for the autonomous database that it will
be at least 50% cheaper than running the Oracle database or Redshift on Amazon. As Oracle is only
introducing the data warehousing service, for now the guarantee will only apply to that.

During the Oracle OpenWorld keynote, Ellison demonstrated why Oracle was willing to put it all in
writing. Benchmarking autonomous Database 18c for data warehouse against two Amazon
alternatives, the results were consistently 5–8x performance and cost advantage. Those scenarios
included running Oracle database on Amazon s RDS and running Amazon s own Redshift data
warehouse. For the record, there is a qualification here: Roughly six months ago, Oracle doubled the
price of running its database on Amazon RDS; so even without the autonomous database, Oracle has
already met that goal. Additionally, because Oracle now has a cloud-first policy, the version running on
Amazon is still 12c. Nonetheless, the bigger picture is that even with these qualifications, Oracle s
own benchmarks blew away those numbers. The savings will not be based on any technicality. And
while Oracle has stacked the odds in its favor for achieving better results for its database on its own
cloud, real differences remain between Redshift and the Oracle database. For instance, with the 18c
autonomous database using Exadata infrastructure, Oracle s database has the compute elasticity that
Redshift lacks.

Obviously, Amazon is not exactly facing the battle sitting down. It has just announced the availability
of Redshift on second-generation dense compute nodes (DC2) with twice the performance of the
previous generation for the same price; this is the configuration targeted at low-latency, high-
throughput data warehouse workloads. It also positions Redshift Spectrum as an elastic alternative;
but in this case, the elasticity is about using additional storage and compute. For now, you cannot turn
compute completely off for your base Redshift implementation. But we suggest that enterprises
should watch this space, as we expect Amazon to continue evolving Redshift Spectrum.

For customers, pricing promises from the likes of Oracle and Amazon should set up a virtuous cycle:
The onus is on the customer to stay vigilant on the constantly moving targets of cloud pricing and
infrastructure refreshes.

© Ovum. All rights reserved. Unauthorized reproduction prohibited. Page 9

Oracle s Autonomous Database 18c: An Initial Assessment

Oracle to DBAs: You still have a job

Self-running or "autonomous" databases are designed not to eliminate DBAs, because DBAs are still
needed for setting policy and providing feedback loops to ensure the database meets policy
requirements. Instead, they are designed for eliminating the legwork that DBAs typically perform, such
as providing patches, upgrades, configurations, and deciphering normal activity from the query from
hell (or something worse). Despite all the horror stories that ML and artificial intelligence are going to
replace people, this will not be the case for autonomous databases. DBAs will still be necessary for
strategic decisions and planning, such as designing the database architecture; specifying the schema;
defining security and SLA requirements; and conducting application-related tuning.

Oracle is first out of the gate, but expect others to follow soon
Oracle is the first to publicly announce that it is incorporating ML into the operation of its database
services. But Microsoft has recently announced that incorporating ML into automating database
operation is on the roadmap for SQL Server 2017, Azure SQL Database, and Azure SQL Data
Warehouse. We believe that Google is applying ML with its latest database services, including
Spanner, and we expect that Amazon will follow with its Aurora database services.

However, as we noted before, ML is not synonymous with autonomy or self-running. ML can be used
for optimizing low-level patching and repairs/self-healing operations. The autonomy comes in with
tuning and optimization, where there are often multiple "right answers," but only one that is most
optimal for the requirement (which, initially for Database 18c, will be performance consistency). For
now, Oracle is the only provider that has gone the extra step with a database that is self-running. We
expect others to follow.

Beyond autonomous, the other updates are largely incremental

Beyond the spotlight, there is a series of mostly incremental enhancements to the database, a few of
which encompass:
 OLTP performance improvements with in-memory access and RAC
 improved data tiering for caching hot tables in memory from Oracle database or external
tables (e.g. from Hadoop)
 NVRAM-ready column store, which in upcoming releases will largely supplant DRAM to
significantly expand in-memory storage and caching
 ability to query and load from cloud object stores and Kafka, mirroring a trend that Ovum is
seeing with cloud-based analytics platforms (e.g. AWS Redshift Spectrum, Microsoft Azure,
and SQL Data Warehouse)
 user-defined sharding (in the previous 12c release, this was controlled by the database
engine)
 keys that can be assigned to specific pluggable databases (PDBs)
 graph analytics support via a new in-memory graph engine (which can also work atop the
Oracle NoSQL Database or HBase)
 expanding on "approximate query" capabilities first introduced in database 12c, by adding
percentile and median functions

© Ovum. All rights reserved. Unauthorized reproduction prohibited. Page 10

Oracle s Autonomous Database 18c: An Initial Assessment

 expanding the portfolio of Oracle-developed ML algorithms (i.e. algorithms for random forest
and neural networks for classification and regression)
 support for polymorphic table functions (where inputs and outputs can be specified at query
time) that debuted with ANSI SQL 2016.

Appendix
Methodology
This report was compiled while attending Oracle OpenWorld 2017, including deep dive sessions on
the autonomic database and one-to-one discussions with Oracle customers and product managers.

Further reading
"Oracle fills out the Cloud at Customer portfolio," IT0014-003323 (August 2017)

SWOT A e ment: Oracle Bare Metal Cloud Service , IT0022-00096 (May 2017)

"Oracle sees the cloud as a journey where customers want to start at different positions," IT0022-
000892 (March 2017)

The Cloud-Fir t Strategy of Oracle Databa e 12c Relea e 2, IT0014-003194 (January 2017)

Author
Tony Baer, Principal Analyst, Information Management

tony.baer@ovum.com

Ovum Consulting
We hope that this analysis will help you make informed and imaginative business decisions. If you
have further requirements, Ovum’s consulting team may be able to help you. For more information
about Ovum’s consulting capabilities, please contact us directly at consulting@ovum.com.

Copyright notice and disclaimer

The contents of this product are protected by international copyright laws, database rights and other
intellectual property rights. The owner of these rights is Informa Telecoms and Media Limited, our
affiliates or other third party licensors. All product and company names and logos contained within or
appearing on this product are the trademarks, service marks or trading names of their respective
owners, including Informa Telecoms and Media Limited. This product may not be copied, reproduced,
distributed or transmitted in any form or by any means without the prior permission of Informa
Telecoms and Media Limited.

Whilst reasonable efforts have been made to ensure that the information and content of this product
was correct as at the date of first publication, neither Informa Telecoms and Media Limited nor any
person engaged or employed by Informa Telecoms and Media Limited accepts any liability for any
errors, omissions or other inaccuracies. Readers should independently verify any facts and figures as

© Ovum. All rights reserved. Unauthorized reproduction prohibited. Page 11

Oracle s Autonomous Database 18c: An Initial Assessment

no liability can be accepted in this regard – readers assume full responsibility and risk accordingly for
their use of such information and content.

Any views and/or opinions expressed in this product by individual authors or contributors are their
personal views and/or opinions and do not necessarily reflect the views and/or opinions of Informa
Telecoms and Media Limited.

© Ovum. All rights reserved. Unauthorized reproduction prohibited. Page 12

CONTACT US
www.ovum.com
analystsupport@ovum.com

INTERNATIONAL OFFICES
Beijing
Dubai
Hong Kong
Hyderabad
Johannesburg
London
Melbourne
New York
San Francisco
Sao Paulo
Tokyo