First contact with OCI’s Autonomous Database

Introduction

Benefits of going into the Oracle Cloud (OCI) are clear for most of us: no more datacenter and hardware to manage. But what else? On OCI, you can also decide to get rid of part of the DBA tasks (the less interesting ones, for sure).

To create your Oracle database environment, you need to choose among these 3 solutions (for most of us):

• a compute instance you will manage yourself
• a DB System, basically a compute instance including Oracle binaries and a database you can easily provision and manage
• an Autonomous Database that will do most of the administration tasks for you

The first solution is probably not very interesting for Oracle databases, because you’ll need to set up everything by yourself as the OCI provisionning service stops after OS setup.

Most of us would choose creating the databases using DB Systems, because it’s cheap and you keep full control of the database and its server.

Autonomous Database is much more modern, as it proposes to automatically manage quite a lot of tasks without configuring anything.

What are the drawbacks of this solution?

Let’s start with the drawbacks, because you first need to know if it can fit your needs.

First of all, you will not have any connection to the host. That sounds obvious. And your DBA connection will be limited. No way of connecting as SYSDBA, you will use a dedicated Admin user. This is also quite logical as lots of actions are no more parts of your daily tasks.

Your database will be running on a shared platform, this is OK but it means that updates will be automatic: you cannot decide when a patch is applied. Here, we’re not talking about PSU every quarter, but weekly patch on the underlying platform. This is done on Sunday during the night (if your database is running in your region). As the platform is using RAC, your database will switch to another node, one already patched, and you will stay on this node for one week. If your applications are not RAC-aware, take this into consideration.

Another drawback is that there is no shrink of your tablespaces, it doesn’t seem to be a big deal but when doing a datapump import (for example for refreshing your DB from another one), dumpfile will be stored in a DBFS dedicated tablespace, and when removing the file, this tablespace will not shrink. This has to be known because you will pay for database storage, and this is included in database storage unlike other platforms.

For people using APEX, the APEX update will be also pushed as soon as available. You can only postpone this patch for 45 days on your production database, and let it apply when available on your development’s database.

But there is a lot of benefits!

First benefit of Autonomous Database, it runs on Exadata. Exadata is not less than the best platform you can expect for your databases. And as it is shared, you will pay only a slice of the cost of the server. Customer having few databases would have never been able to buy an Exadata, now they can use one. For sure, the cost of Autonomous Database is higher than a DB System, but it will ease your job so it’s a trade off.

Second benefit is the Autonomous features. I’m not aware of all of them, but for example, forget tablespace creation and management. This is done automatically. A DBA spends a lot of time managing space, this now belongs to the past. Forget also about sizing memory, this is also done automatically.

Third benefit is autopaching. Years ago, patching was not done on a regular basis, but nowadays this is a security concern, and this is a lot of work. Because we spend a lot of time applying patching. With Autonomous, your database will always be up-to-date.

Fourth benefit is autoscaling of the CPU. You can decide a base CPU numbers, a maximum CPU numbers, and your Autonomous Database will scale-up when more CPU is needed, and scale-down when the load is back to normal. And you will pay accordingly. No need to have spare CPUs activated all the time.

Fifth benefit, Autonomous will become smarter and better, without any patch or migration from your side. And as this is a flagship product for Oracle, your can expect the best for your database.

What is still possible to do?

Despite being automatically managed, you still can get AWR reports from your database, meaning that you can do tuning on the queries that are not running correctly, or look at the performance profile of your database. It’s not possible to change the snapshot interval of 1 hour, but using Diagnostic and Tuning pack is OK. You will find a performance tab in the OCI console to manage them. Yes Autonomous is still based on normal 19c database.

Using SQL developer or Toad is for sure possible, you will need a wallet to get connected to your DB, but browsing items or querying data dictionary is like you were on a “normal” database.

Obviously, your application’s users will not see any difference, switching your application from an on-premise database to an Autonomous one is easy.

Conclusion

If you have no time to manage your databases, and if you need performance with a minimum of tasks, this can be a solution that comes at a cost. Yes, Enterprise Edition with Exadata and Autonomous feature is for demanding databases. If you need extensive access to your database, a less expensive solution, or simply if you don’t need such level of performance, think about DB Systems. This is definitely more flexible, and with a solid partner for your SLA contract this could bring you the best of the Cloud and the best of the service.