Autonomous Database is Oracle’s flagship product. Does it hold promise for businesses currently using the Oracle database? Is it worth the upgrade? Will it make things better for those, like me, who administer Oracle Databases for a living?
Oracle’s Autonomous Database launched about two years ago in 2 flavors. Oracle first launched the Autonomous Data Warehouse (ADW) in the fall of 2017. This service is optimized for Analytics. It allows you to quickly load a vast variety of data and provides tools for sophisticated data analysis and easy sharing. A few months later Oracle came up with Autonomous Transaction Processing (ATP). ATP is optimized to execute a high volume of transactions. It also handles any complex workloads within those transactions.
But what is an Autonomous Database?
Basically, as Oracle’s documentation describes it, the Autonomous Database is “Self-Driving”, “Self-Securing” and “Self-Repairing”.
Self-Driving: Oracle automates many of the manual tasks DBAs have traditionally taken care of, such as database management, monitoring, and tuning. As you can imagine, this significantly reduces operational costs.
Self-Securing: Autonomous Database automatically encrypts all data, and automatically secures it by applying patches with no downtime. the system also ensures there is no unauthorized access.
Self-Repairing: Autonomous DB will self-recover, meaning it will actively scan for and detect errors and then apply corrective actions to ensure high-availability of the data.
Now, between you and me, what exactly does all that mean? Let’s compare the Autonomous Database to the “good old days” of database administration, from a DBA (my) point of view in four different situations:
1- When the business requested a new Oracle database
I remember just a few years ago when the sysadmin would get the go-ahead to prepare a brand-new Linux server. I would provide the Oracle pre-requisites packages, the OS parameters, and the required files systems names, and sizes. I’d also provide the required OS users that we needed to create. Then I would wait a couple of weeks to finally get the vanilla Linux server (No offense to the sysadmin :-))
Then, I’d transfer installation files over to the new server and launch the installation…until it failed because of a missing package or something I forget to ask …..
You see how this could easily circle back again and again. This is why we were constantly improving our recipe (methodology). Before starting any installation, we’d run processes to validate if the server was properly built. Bottom line though, there was lots of manual work, up until we came up with good OS images. Then we’d be good for 2 years and then Oracle would release a new database server version, and then we’d start the process all over again. One good thing that came out of these experiences was that having approved images and reusing them when needed saved us a whole lot of time.
Oracle Cloud provisioning in general, including Autonomous Database provisioning, is based on the concept of using images. The process takes as little as 20 minutes to complete. 20 minutes, compared to weeks the old way! Way less team effort and cost, thanks to the “self-driving” concept.
2- When the business said “the application is slow”
Ok, sorry, but what a generic sentence! For an IT person, that observation means nothing. I think we all agree on that. Back then, we’d think “Ok, now, where do we start troubleshooting this? So, everyone headed into a “war room”: the sysadmin, DBA, storage admin, network admin, IT manager and the application owner. The first questions would be to the application owner, “Exactly where inside the application is the slowness? Can you identify the specific process? can you reproduce it? And so on.
Once we identified a process, we then asked the appropriate expert (storage, sysadmin, DBA) to analyze what is happening on their end, when that process is running. The storage admin, the Sysadmin and the DBA would come up with a performance report saying that on their side everything looks normal, each happy to prove the efficiency of their component. Not necessarily a bad thing unless the slowness remained, which was often the case.
So, after further investigation, everyone would reconvene in the war room. 5-6 experts in a room sounds expensive, doesn’t it? We’d identify the problem and agree on the corrective action. We’ll move this portion of the database on faster disks. We’ll remove this SELECT statement doing full table scans over 3 million rows for no apparent reason. Or whatever. In the end, the application’s performance was brought back to normal. But it was a relatively long and costly process.
The Autonomous Database does this detective work automatically, using machine learning algorithms. Performance validation and application of tuning best practices isn’t just happening when the system slow; it is an ongoing process without human intervention.
3- When the IT security group wanted to apply database quarterly patches
Every quarter or as required, Oracle releases a patch. These patches contain software improvements but also very important fixes to remove security vulnerabilities. Theoretically, they are crucial if you want to be fully protected. Without them, you can’t enjoy a new feature or improve an existing one. In practical terms, however, it is difficult to get a business to accept a process allowing downtime to install these quarterly or on-demand patches because the patching process is usually complex and time-consuming. However, without it, your database is at risk. Remember the Equifax data breach in 2017? It happened because an IT employee did not ensure the implementation of a software fix that would have prevented the breach.
Oracle’s Autonomous Database takes care of this for you, automatically. The moment a security patch is released, it is automatically applied. Other regular patches are applied on a schedule. It’s done on a rolling basis, eliminating downtime and ensuring continuous availability of data. The automatic application of security patches certainly reduces costs and IT team stress! More importantly, though, it greatly reduces the risk of data breaches. The “self-securing” concept can help us all sleep better at night. Thank you.
4- When a production server went down
Ok, this is the worst situation ever. No one wants to deal with something like this. But it happens and for multiple reasons. Depending on the criticality of the database, your backup and recovery strategy might be one of these:
- Database backup (physical and or logical)
- Disaster recovery solution in place
- High Availability solution in place
- No backup at all
Theoretically, except for the last one, your scenario should be tested and validated on a regular basis.
I consider it very important to have either high availability (HA) or disaster recovery (DR) solutions in place. Having both solutions is even better. I don’t want to go too much into the definition of HA and DR but basically, we ‘ve deployed an HA solution locally to a site using Real Application Cluster (RAC) and we are also deploying a DR solution across multiple sites using Data Guard. A solution including both HA using RAC and DR using DataGuard is one of the most robust you can have. Whatever happens with your hardware or data center, your healthy HA and DR solution will save you. This robust deployment is considered complex if you have to build it piece by piece at 2 different sites.
Autonomous Database integrates Oracle Maximum Availability Architecture (MAA) technologies. It prevents (as much as possible) any type of failure or outage that could happen on a system.
How can Oracle’s Autonomous Database achieve all this?
Under the hood, Autonomous Database runs on the tried and true Engineers Systems Exadata. The same Exadata platform you might already be using on-premise. Oracle has in fact combined Exadata machine, Oracle Cloud Infrastructure (OCI), automation technologies, and machine learning to come up with a very powerful, cost-efficient, easy to use, secure, and highly available Autonomous Database
Image source: Oracle
Autonomous Database + APEX
Also included in Autonomous Database is Oracle’s powerful and proven Low-Code Rapid Application Development (RAD) tool, Application Express (APEX). This fully managed APEX environment allows the client to start developing rich applications, from the moment they finish provisioning the Autonomous Database.
Conclusion:
With this new service, clients won’t have to worry about configuring, upgrading, patching, or backing up the entire stack including the database and APEX. All of this is taken care of automatically by Oracle. IT management can plan their cloud transformation knowing it will be simple, quick, and low cost. Those who already administer an Oracle Database can enjoy the benefits of this new cloud technology in an environment they are already familiar with. With Autonomous Database, Oracle makes the Journey to the Cloud easier, simpler, while greatly minimizing risk.
We specialize in the Oracle Cloud. We offer a comprehensive lineup of cloud services aimed at helping you reduce on-premise infrastructure spending and quickly scale your computing resources to best suit your business needs. Contact us if you’re considering the Oracle cloud. We can help.
