Understanding why to use an Autonomous Database

There has been a major change starting with Oracle Database 9i, where Oracle started to introduce and enhance many automation capabilities, from memory management to workload monitoring and performance tuning. All of these set a solid foundation for autonomous capabilities and are used in ADB. Not only database automation but also database infrastructure with engineered systems was invested in and brought in by Oracle, which is considered the best platform for the Oracle Database workload, as these systems are preconfigured, pretested, and optimized converged platforms for the database. Take a look at the following automation capabilities over the span of a decade to get a view of the enhancements in Oracle Database:

Figure 1.5 – Depicting Oracle Database automation over the years

In addition to these innovations, Oracle has spent more than 10 years automating the database infrastructure:

Figure 1.6 – Depicting Oracle’s infrastructure automation over the years

Decades of innovation in the ML capabilities of Oracle Database

After all these innovations, let’s see how the Oracle database uses ML and AI right inside the database.

In Dec 2019, Oracle Machine Learning (earlier known as Advanced Analytics) became a free feature of every Oracle database. Oracle Machine Learning extends Oracle database(s) by delivering more than 30 in-database ML algorithms and automated ML functionality via SQL APIs (OML4SQL) and integration with open source Python (OML4Py) and R (OML4R). Oracle Machine Learning “moves the algorithms, not the data,” processing data where it resides. It further enhances the benefits of Oracle’s multi-model converged architecture by supporting various data types and data models such as Spatial, graphs, XML, JSON, and so on. Through innovation in infrastructure software and various algorithms for ML and statistical functions, Oracle optimized the platform to run different workload types, such as OLTP and DSS workload types. Without additional cost, customers can take full advantage of the enterprise-class performance, reliability, and security of Oracle Database for particular use cases, such as the following:

• Processing and analyzing all types of spatial data in business applications, Geographic Information Systems (GIS), and operational systems
• Using graph analysis to discover relationships in social networks, detect fraud, and make informed recommendations
• Building and deploying ML models for predictive analytics

Let’s take a look at various capabilities related to the uses of ML in ADB:

• ML is integrated across the database stack and infrastructure, resulting in the autonomous capabilities of the full Oracle stack being leveraged.
• By introducing ML, different personas such as data scientists, data analysts, developers, and DBAs/IT benefit.
• Complete stack intelligence eliminates expensive data movement and minimizes access latency between systems.
• Data exploration, data preparation, and ML algorithms are faster. More than 30 algorithms that support regression, classification, time series, clustering, feature extraction, and anomaly detection are included.
• ADB supports open sources, such as R and Python integration, useful for a data scientist.
• You can develop an ML model and R/Python with the provided tools.
• ADB automates key ML processes, such as workload patterns, auto-indexing behavior, SQL profiles, and so on.
• ADB supports existing enterprise backup, recovery, and security mechanisms and protocols.
• Most importantly, it brings the algorithms to the data.

With Oracle Machine Learning, along with Oracle Database and infrastructure capabilities, Oracle has evolved as a fully converged data management platform.

For any modern organization, databases play a critical role in storing important application and business information and are essential for the efficient operation of an organization. Databases are managed by DBAs and they are often occupied with operational things such as backups, patching, and performance tuning, and spend the majority of their time on this kind of manual task to make sure the database is up and running. Any DBA errors because of manual work can lead to a serious impact on database availability, performance, and security.

On the other hand, today, several data architecture challenges exist – several customers try to experiment with many different kinds of databases, such as relational, document store, graph and spatial, time series, NoSQL, and Big Data analytics to name a few. It brings several administration challenges:

• Hard to enforce consistency of data across applications
• Hard to do consistent backups for different databases
• Issues with cross-database compatibility
• Separate security patches for every database
• Separate upgrade cycles for databases
• Varied level of performance levels across databases
• Varied availability – different ways to implement disaster recovery
• Complex integration for analytics
• Hard to match varied skills for different databases

These challenges can be easily addressed with ADB because of its unified, simplified, and standardized approach.

If we explore it further, we see that failing to apply a patch or security update can leave open vulnerabilities in databases. With massive data growth, it brings more complexity, making them even more difficult for DBAs to manage, secure, and tune for maximum performance. Needless to say, databases that are not performant or slow-running can negatively impact employee productivity and impact customers. Poorly designed disaster recovery plans can lead to huge business impacts.

ADB uses ML in three key areas of ADB: diagnostics, recovery, and optimizations for each layer of the deployment stack, each respectively corresponding to the following:

• Inside database infrastructure, ADB automatically detects and recovers from failed servers, storage, or network switches or links
• Automatically detecting an anomaly or hangs in the database behavior, comparing these behaviors with known issues, and automatically identifying known issues and fixing them or automatically opening a Service Request (SR)
• Automatically optimizing customer workloads with real-time statistics and automatic indexing

So far, we have explored the generic benefits of using ADB.

Because ADB runs on Exadata systems, RACs are also provisioned in the background to support the on-demand CPU scalability of the service. This is transparent to the user and administrator of the service. For all ADB offerings, there is an option of creating an optional remote standby database (Autonomous Data Guard) for automatic failover capabilities and disaster recovery purposes.

As mentioned, ADB runs on Exadata systems, but no Exadata installation, configuration, or management needs to be done or can be done. The init.ora parameters (database initialization parameters) are configured automatically in an Autonomous Database depending on the service selected – ADW, ATP, or AJD. Memory, parallelism, concurrency, number of sessions, and other parameters are automatically configured based on the number of CPUs allocated to the service. Most of these parameters cannot be modified, and the few that can be modified should only be done for very specific reasons by qualified DBAs. This is discouraged in ADB, as it defeats its purpose.

Quick note

When an Oracle instance starts, the very first file it reads is initialization parameters (init.ora) from an initialization parameter file. As of today, customers do not have the capability to set database parameters or resource manager configs while creating ADB instances or modifying them via the Console, APIs, or an SDK after the instance is created. All parameters are set to optimal values based on the specific workload type and this may be different from regular database defaults. The ATP and ADW have two different resource management plans. The ADW plan name is DWCS_PLAN and the ATP plan name is OLTP_PLAN.

Tablespace management is performed automatically by ADB and cannot be changed by the customer. Customers have full access to view the information of the space allocated to their instance, but it cannot be changed. The only input the customer needs to provide is the number of terabytes of data they would like the database to be able to hold. This number can be increased or decreased in real time. ADB handles adjusting the data location based on this user setting. The default tablespace is the same for ATP and ADW.

Loading and maintaining data in ADB can be done as one-time loads, best when staged through Oracle Object Store, or as continuous data ingestion or synchronization with other sources. ADB supports three object stores and can read and write directly to these three. The supported object stores are Oracle Object Store, Amazon S3, and Azure Object Store. Object stores are ideal for staging export dump files that are going to be imported into the Autonomous Database.

The same applies to flat files that would be loaded into the database. An ADB supports the Oracle Database external tables feature – so flat files on the object store can act as autonomous external tables. Please note that it is best to host these tables on Oracle Object Stores that are fast and connected to the Autonomous Database to reduce latency and other issues around access time to database objects.

Also available for transactions and data work location in real time or near real time, or to maintain synchronized copies of databases, is Oracle GoldenGate, which can be configured with an Autonomous Database as a target database. This allows ADB to become a full replica copy of another database for uses such as reporting, disaster recovery, development, testing, and QA. Once a decision is made to move the database to ADB services, the next step is to determine what to do with the application accessing that database.

Just like rehosting the database in the cloud, rehosting the application to the cloud may have its own benefits. If the application using the Autonomous Database is an existing application, there are two preferred options for hosting the application. The first option is to keep the application in its existing environment and replace the existing database with access to the Autonomous Database. The second option is to rehost the application to OCI. Rehosting the application may be straightforward or may require substantial reconfiguration.

Autonomous Database value proposition

OCI provides the required elasticity, agility, security, and global reach, and helps customers focus on their workloads and not the infrastructure. With OCI DbaaS, OCI is helping customers lift and shift their on-prem database workloads to the cloud. While OCI continues to add more tooling to the OCI DBaaS, customers want complete automation and no management overhead. They want their database service to be fully managed, where routine tasks such as patching are automatically done, backups are available to customers when they need it, systems scale automatically to workload requirements, and much more. ADB services such as ATP, ADW, and AJD aim to fully manage customer databases based on customer preferences. All exceptions and failure cases are automatically managed by Oracle.

The key principles of the ADB service are as follows:

• Self-driving: Customers define the service level and ADB makes it happen
• Self-securing: The service protects against external attacks and malicious internal access
• Self-repairing: The service enables higher availability with automated protection from downtime

The key customer benefits of ADB services are as follows:

• Reduced services costs and increase productivity for customers.
• Reduced admin costs, with complete automation of operations and tuning.
• Reduced runtime costs by dynamically adjusting resources and eliminating underutilization.
• Deploying new apps in minutes, with faster Time to Install (TTI) and faster Time to Deliver (TTD).
• Reduces the cost of downtime – less than 2.5 minutes per month.
• Elastically grows and shrinks compute or storage without downtime. Pay only for what you use.
• Eliminates human labor to provision, secure, monitor, backup, recover, troubleshoot, and tune.
• Automatically upgrades and patches itself while running. Testing automation ensures changes are safe.
• Protection from external attacks and from malicious internal users.
• Protection from attacks by automatically applying security updates with no downtime.
• Automatic encryption of all data.
• Most reliable.
• No human labor, and hence no human error
• Zero downtime with scale on-demand.
• SLA 99.995% guarantee available with the Active Data Guard (ADG)- Dedicated option. SLA 99.95% guarantee available with the ADG-Shared option.
• Automation eliminates administrator errors.
• SLA guarantees 99.995% availability. < 2.5 minutes of downtime per month, including planned maintenance.

So far, we have seen how Oracle Database has evolved over time to bring automation capabilities along with innovation in infrastructure and this innovation is continuing with each release. The current release of the Exadata platform, X9M, is the fastest database machine engineered to run ADB. Now, let’s review a few use cases and considerations for ADB.