Beruflich Dokumente
Kultur Dokumente
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.
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.
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
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.
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.
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.
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
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.
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.
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
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
Source: Oracle
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.
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.
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.
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.
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.
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
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.
INTERNATIONAL OFFICES
Beijing
Dubai
Hong Kong
Hyderabad
Johannesburg
London
Melbourne
New York
San Francisco
Sao Paulo
Tokyo