Types of ADBs

ADB processing is available only in OCI and Exadata Cloud@Customer environments. There is no on-premises version of an ADB. There are three types of ADBs, which are distinguished by their formats and workload types:

• ATP is used for operational data defined by the short transactions changing the data.
• ADW is analytically oriented by focusing on storing long-term data. It involves a complex data retrieval process.
• AJD provides specialized document-oriented storage and management.

Besides these types, there is also an APEX type built for Oracle APEX application development, which provides the ability to define data-driven, low-code solutions. However, generally, APEX applications can be developed on any type of database.

We will now describe and compare these three main types. Selecting the right type for your workload is performance critical.

ATP handles online transactional data changes. The data structure should be normalized with no data redundancy or anomalies. Values, which can be calculated, are not stored in the system. ATP requires data consistency and integrity, ensured by the transactions that shift the database from one consistent state to another. The aim is to ensure the performance of data manipulation operations – data modifications (insert, update, and delete), as well as data retrieval (select). Thus, the index set must be balanced to serve all these operations.

ADW is a specific database repository that deals with data analysis. The essential operation is the data retrieval process, so overall optimization is focused on the select statement performance, ensured by a huge amount of indexes (B+trees and bitmaps). Data is often denormalized. Precalculated outputs are stored in a column format, compared to the row format used in ATP. There is no focus on data modification, which can, in principle, last any amount of time. The process of analytical processing of large data amounts through complex queries is essential and is the goal of performance optimization.

The main differences between ATP and ADW are summarized in the following table:

Table 1.1 – ATP and ADW summary

The following table shows the resource service priority types. Although, generally, any type can be used for both workload types but in the environment operated in parallel, it is always important to set the operation priorities properly to ensure efficient performance of the online transaction operations. This is because the analytical reports can be too demanding and resource-consuming.

Table 1.2 – Resource service priority

ADW is determined by three priority levels – Low, Medium, and High (as seen in Table 1.1). The Medium and High options support parallelism, while the Low type uses a serial approach. These levels are used for priority definition in reporting and batch processing. ATP can use all priority levels, but the Tp and Tpurgent types are preferred for Transaction Processing (TP). The highest priority is covered by the Tpurgent option.

Finally, AJD is a non-relational database used to store, manage, and obtain data in JSON document format. The structure is not fixed, allowing a variety of data to be stored in each row. There is no normalization strategy.

Considering the historical evolution of cloud migration, it is clear that administrators and managers tended to store all the data locally in their companies. They simply believed that data was secure if it was stored and administered by them and the storage and all the hardware capabilities were physical and visible. However, sooner or later, the hardware could collapse, and data would be lost if the backups were not managed properly. Even if backups were available, a company’s credibility was corrupted if any amount of online data was lost.

On the other hand, local on-premises data management was sometimes required due to various challenging limitations – the cost of service, interoperability, laws (meaning that data could not be stored outside the company), regional availability (cloud repositories were now uniformly distributed across regions), security, integration techniques (some applications were not able to run in the cloud), and so on.

Most of these challenges were solved consecutively using mechanisms that can handle operations and their complexity. By using cloud solutions, almost all the activities related to the infrastructure, hardware, and security are covered by the cloud vendors. You do not need to patch and update your system. It is always available and backups are handled automatically, creating reliable and secure solutions. In a nutshell, cloud companies generally offer these service models:

• Infrastructure as a Service (IaaS) provides a lower abstraction level and supplies the machines (both physical and virtual) with storage capacity, firewalls, network gateways, and workload balancers. Thus, the cloud provides you with the storage, server, network, OS, and overall software tools to run Oracle. You are allowed to bring your own software image and are responsible for application software, maintaining the OS, and installing patches.
• Platform as a Service (PaaS) provides a higher level of abstraction. You, as the customer, are not responsible for administering infrastructure and other cloud resources, such as the OS, database, and so on. PaaS serves you the database with no necessity to install Oracle software or configure its environment.
• Software as a Service (SaaS) offers the highest abstraction level. The user is not responsible for the platform or infrastructure. Applications are located in the cloud, and the whole responsibility is shifted to the vendor. You just pay for the usage.

Now that you have been familiarized with the types of cloud services available, which offer several different levels of abstraction, it is important to remember that from the physical access point of view, either individual cloud resources can be shared or private separate hardware can be provisioned just for you. A database is always private, but the instance resources can be shared by multiple users to optimize resources, as well as costs. To help you understand resource sharing, Oracle has provided four deployment models. The next section will walk you through these deployment models.