Oracle's next chapter: The Autonomous Database and the DBA

The autonomous database was the central theme of this year's Oracle OpenWorld event that wrapped up last week. With the product now generally available, Oracle showcased several production Autonomous Data Warehouse references. The next steps are showing real business impacts and educating customers on why DBAs remain relevant.
Written by Tony Baer (dbInsight), Contributor

For obvious reasons, databases have always been up front and center to Oracle chairman and founder Larry Ellison, the prominence of the autonomous database at last week's Oracle OpenWorld gave Ellison a chance to head back to memory lane. In this case, the memories were recent as Oracle introduced the concept last year and, surprise, surprise, provided the opportunity for Ellison to revisit the benchmark thing vs Amazon.

The benchmarks didn't go away in this year's keynote, but with product now in release (Autonomous Data Warehouse, or ADW, in March; and Autonomous Transaction Processing, or ATP, in August) there's now the beginnings of a track record with real world results. Specifically, the autonomous database is only available as a service for Oracle Database 18c in the Oracle Public Cloud -- at this point, you can't try this at home.

Oracle is also introducing an option for autonomous database that allows customers to get an isolated, single-tenant Exadata rack in the Oracle Public Cloud. It's targeted at clients whose policies preclude sharing resources with other companies. The new service is just a logical step away from making it available for Oracle Cloud at Customer.

We attended a panel featuring roughly a half dozen early ADW customers, but given the newness of the offerings, the results are preliminary -- most of the customers speaking had about 1 - 3 months of production experience. DataIntensity, which itself is an Oracle database service provider, had the most extensive experience, as it found time-to-benefit improvements. In the few months that it has run ADW for its enterprise clients, deployments were 10x faster, and more importantly, it reported saving clients $225,000 in licensing and operating costs. Other customers pointed to promising early results that they expect will lead to meaningful TCOs (total cost of ownership), once they get to the six- or 12-month marks.

This is the point where autonomy meets the real world, and it becomes a question of what the terms of engagement between man and machine are. Oracle's message is that autonomous databases won't replace DBAs. It makes the case that the autonomous database eliminates annoying and tedious housekeeping chores like patching and keeping security fully updated. What was interesting was that, outside of the keynotes, the biggest lines that we saw was the one for the breakout session "DBA vs. Autonomous Database." Actually, let's correct that, there were so many people (OK, it would be safe to assume, DBAs) lined up, that it took two lines to contain them all -- and in all likelihood, only a fraction made it through the doors.


Oracle OpenWorld 2018 attendees queuing for DBA vs. Autonomous Database session before the second line formed

There clearly is fear and trepidation in the DBA community as to whether autonomous databases are going to make them obsolete. It comes atop all-too-familiar horror stories of when enterprises shrunk their IT organizations in the early 2000s in the mad dash to outsourcing as they mindlessly embraced the notion that IT didn't matter. It's compounded by true life tales of companies forcing IT staff to train their offshore replacements to avoid forfeiting their severance packages. And even when organizations embraced new technologies, they all too often have relied on the kindness of strangers. We recall, for instance, advising a client that was planning to implement Hadoop that was prepared to totally leave the driving to consultants because they lacked the talent and weren't willing to train or hire.

So, yes, there will be clueless companies out there that will use autonomous databases as an excuse to zap DBAs off the payroll. Those that do will likely find themselves subsequently retracing their steps as they desperately try refilling those positions when cost and performance start going south.

For instance, the autonomous database won't model your data or create the schema. While applying machine learning to a set of data could generate a skeletal schema, at some point, somebody needs to write some SQL statements to lock in the model. While machine learning can spot disconnects in performance and costs, it won't spot whether end users are getting the answers that they really need.

With real world experience coming in, Oracle is starting to tweak the autonomous databases with options to adjust the degree of automation for certain tasks. Indexes for data warehouse and transaction processing are good cases in point. For instance, OLTP tends to rely on them more heavily because there's a much higher incidence of random access queries to specific records. At the other end of the spectrum, while columnar and compression are supposed to reduce the need for indexing in analytics, some enterprises rely on them for operational reporting. Oracle will be adding the ability to add your own indexes for ADW, and for ATP, is introducing automated indexing capabilities that supplement, not replace the indexes that are the bedrocks of operational systems.

Real world experience is also driving Oracle to add some options for adjusting or temporarily turning off compression for data warehouses that are use row-by-row ETL process or trickle feeds, in place of batch. As Oracle makes its own appliances, we might suggest adding some one more: for database transfer (a la Amazon Snowball). This would address an issue that one of its early ADW clients faced: Poor local bandwidth posing a bottleneck to moving its database to the Oracle cloud. The database copy command wouldn't work because of the lack of bandwidth. In this case, they did a workaround by generating compressed CSV file extracts.

As Oracle ramps up marketing the autonomous database beyond early adopters, it must get ahead of several issues. First, there's the matter of the DBA role. Yes, Oracle has already gone on record that autonomous databases won't replace DBAs, but it should go further and educate on how the role evolves to two audiences: DBAs, so they understand how to stay relevant in the autonomous database world, and enterprises, so they don't stupidly eliminate their DBAs and then wonder what hit them.

Secondly, Oracle also needs to make the case of why the Oracle Public Cloud and its Gen2 infrastructure is essential for the autonomous database to deliver on its promise. In our travels across the conference circuit this fall, we saw clear signs of other database vendors with their own self-driving plans (if you look back at where we've been tweeting from this fall, you can probably guess who we're talking about). We'll likely be seeing a mix of expanded options such as the ability to run these smart databases on premises or in public clouds like AWS or Azure. Oracle needs to explain why it's Oracle Public Cloud-only strategy is not locking customers in.

And then there is the need to get beyond benchmarks to real world results. No matter how painstaking the benchmark, once a vendor runs it, there's the perception of a preset agenda; if a third party runs it, there's the question of currency. At OpenWorld, 11880.com, a German telecom business search provider and early ADW customer, took it the next step by offering benchmarks comparing it to Redshift and Exasol. But next year, Oracle will have ADW and ATP customers with at least 6 - 12 months actual experience. At that point we can get beyond performance. Real-world TCO's should headline next year's keynotes.

Editorial standards