ADB infrastructure deployment choices – shared and dedicated

Autonomous databases can be deployed on either the shared or dedicated Exadata infrastructure available in OCI. Shared Exadata infrastructure provides the smallest minimum commitment to get started, while dedicated Exadata infrastructure provides customers with more control over infrastructure operations, such as controlling the software version and update schedules.

There are several considerations for deciding which one to pick. We will go through them later in the chapter. For now, we will try to understand these services’ classifications on a high level.

Shared

The shared deployment offering is a fully managed multi-tenant environment on a shared infrastructure, powered by Exadata-engineered system hardware on the backend. This environment is shared with several customers but Oracle makes sure you get the needed isolation in terms of resources to run your workloads, such as CPUs and storage. The provisioning is super simple to deploy with very minimal input and customers can get started immediately upon provisioning. It’s also an effort to standardize the database environment for customers, including patching, without worrying about multiple life cycle environments, such as database software, versioning, environment separation, and so on. You can see that this environment is very simple to use, is commercially attractive, has no major commitment, has a flexible pricing model, which uses per-second billing; and can be configured for automatic scaling on demand.

Shared infrastructure is great for customers who want to be database users without worrying about any database operations, including software updates. Oracle has tried to bring uniformity, simplicity, and standardization, which can be considered the key to extreme scalability and performance. It is an ideal choice for a line of business, departmental applications, or data marts, as well as making an excellent environment for developers or data scientists. You can start to deploy your workload in a shared offering of ADB and transition to a dedicated Autonomous Database when you are done with all sorts of migration, testing, and user acceptance.

Quick note

For ADB on shared infrastructure, the minimum database version is 19c.

Dedicated

With dedicated infrastructure, customers have their own dedicated Exadata infrastructure in OCI. It is a little more customizable than the shared infrastructure offering and intentionally created by Oracle to cater to those customer bases that require more control for IT, DBAs, and storage admin groups within an organization. The capacity of dedicated infrastructure is controlled by customers for their workload. This offering provides completely isolated environments to customers, which could be a requirement for them. It provides an opportunity to create one or more container databases hosting thousands of PDBs within it.

The overall idea behind the dedicated deployment model is its customizable policy for the databases. The question comes – why does Oracle allow customization to this environment? To understand the answer to this, consider customer bases that are using Oracle databases for their workloads. There are customers with thousands of databases and several life cycle environments to manage. Not only that but certain applications could also be sensitive to database versions. Customers also want to control the update frequency, timing, and segregation of databases based on their behavior and workload types, which demands control of the database infrastructure. Consolidation is another important factor that is considered in dedicated offerings. These customizations provide flexibility to customers – yet Oracle manages operations that are repetitive in nature, such as backup, provisioning, patching, and so on.

Quick note

For autonomous databases on dedicated infrastructure, users have the ability to choose to patch Exadata infrastructure or container databases immediately via the Patch Now option. They can also reschedule an already scheduled Exadata infrastructure maintenance via the Edit options.

The following screenshot shows the flexibility of controlling the maintenance schedule in a dedicated infrastructure deployment. Customers can control this behavior based on their operational requirements.

Figure 1.4 – Maintenance schedule option for ADB

A dedicated ADB offering is available for both ADW and ATP workloads. A customer can have a dedicated ADB deployment and have either or both of these workloads running within it based on requirements. You can consider this as your own infrastructure running in the Oracle public cloud with services that are most concerning automated, such as provisioning, performance tuning, scaling, patching, database encryption, and backup and restore. As you know, Oracle Database has several options, such as RAC, Database In-Memory, Partitioning, Advanced Compression, and so on, to name a few, which are available within ADB offerings. Apart from this, additional Enterprise Manager Packs, such as Diagnostics Pack, Tuning Pack, RAC, and so on, are available within an ADB deployment.

There are broadly three logical roles that are involved in setting up a dedicated Autonomous Database: fleet administrators, DBAs, and database users. Depending on the separation of roles required for the deployment, you can have a specific role assigned or be part of multiple roles. Fleet administrators are mostly related to management aspects, such as provisioning the infrastructure, managing container resources within monitoring, and managing VM clusters within ADB dedicated on Exadata. A DBA, on the other hand, is responsible for creating, monitoring, and managing Autonomous Databases. These administrators have the ability to create application users, do backups, and restore configurations. The third type of user, database users, are mostly developers who are focused on application development and concerned about making a connection to the database for their work and queries. These users need not be part of Cloud Console users, as they can get connectivity information and required security wallets from an administrator in order to make database connections.

Quick note

ADB dedicated provides 99.995% SLA, which translates to <2.5 minutes of downtime per month. It is fully isolated from other tenants, as the VCN is hardware-enforced.

ADB on Exadata Cloud@Customer

As we saw with a dedicated offering for ADB running in the Oracle public cloud, this Cloud@Customer offering is different in the sense that ADB runs at a customer data center, behind their firewall. It also uses the same Exadata Database Machine infrastructure with networking configuration allowing Oracle to manage from the Oracle Cloud control plane. This option was brought by Oracle for customers who have strict data sovereignty requirements.

The most common reasons for using the Exadata Cloud@Customer (ExaC@C) model include the following:

• Corporate policies and regulations
• Network latency
• Integration needs
• Compliance and risk

Sometimes, it is hard for companies to move their workload to the public cloud, mostly because of country laws related to handling data. System integration needs could be more complex where several applications, hardware, and so on need to be tightly integrated. Network latency requirements also play a major role. Adopting a hybrid cloud strategy is another consideration, which plays a major role when considering cloud adoption. By keeping these in mind, Oracle came up with this offering under ADB on its engineered system platform for customers. Certain key facts about dedicated ADB deployments are listed here:

• The database offering named Oracle ExaC@C is not very new and was already announced in 2017. This option provided cloud flexibility to customers who were not able to move to the public cloud.
• With an ADB offering, Oracle was able to bring cloud self-service and a pay-per-use financial model to customers.
• Customers get the full advantage of ADB along with the benefits of dedicated infrastructure in their own data center.
• You can run a mix of Autonomous Transaction Processing-Dedicated (ATP-D) and Autonomous Data Warehouse-Dedicated (ADW-D) databases on the same dedicated ADB Exadata rack.
• Services can be managed via the OCI Console, the CLI, and APIs.

Quick note

There are a few key differences around networking configuration and backup support when you compare dedicated ADBs in the public cloud versus Cloud@Customer. On OCI, networking is configured via a VCN by the customer, whereas, on ADB ExaC@C, it requires connectivity to the cloud control plane and the Exadata system primary and client networks to be set up, which the Oracle field engineer will validate on-site.

• Backup locations: On OCI, only object storage is supported. On ExaC@C, customers have the option to back up to object storage, local Exadata storage, their own network-attached storage (NFS), or Zero Data Loss Recovery Appliance (ZDLRA), also known as Recovery Appliance (RA).

Quick note

ZDLRA is Oracle’s optimized solution for database backup and recovery. This RA changes the way backups and recovery are carried out in any traditional database deployment. It enables incremental forever backups and efficient any Point-in-Time Restore (PITR). The purpose of this appliance is to enable zero data loss functionality for RA backup destinations. The customer has the ability to choose to enable Real-Time Redo Transport in RA-configured environments, which enables the database to automatically ship all redo logs in real time to RA for a zero data loss (less than 1 second) recovery setup.

I believe that now that we have looked at every classification of ADB in terms of infrastructure type, you can make a decision based on your workload requirements to either go with shared or dedicated options. Let’s try to understand some of the merits to consider while considering this move with ADB.