The Oracle Database Appliance

In most cases, businesses and government agencies today have largely virtualized server infrastructure. VMware or Oracle VM Server is often used for this. VMs are then placed on these platforms in which Linux or Windows Server is installed. From a systems management point of view, this is generally a convenient, efficient and uncluttered solution.

However, we must bear in mind that the added value of server virtualization is mainly formed by improving manageability and cost-efficiency (supplemented by the possibility of absorbing hardware failures), but that it is a generic solution and not by definition the only or the best in all cases. Reasoning from “servers” is no longer as self-evident as it used to be. As developments around “the Cloud”, Linux (and with Server 2016 also Windows) Containers show, the forerunners in the software industry are increasingly abandoning the “server” concept in favor of “services” and also an Oracle database can very well be thought of as a service. Oracle’s proprietary multitenant architecture of database 12c, itself a form of abandoning the one-to-one relationship between databases and instances, can also be seen in that light.

Once we stop thinking in terms of servers, it makes sense to consider what the intended result should be before every addition/replacement of a (virtual) server for Oracle databases. In our view, this simply means offering one or more databases as (cost) efficient, flexible and manageable as possible. Any automation of creating new VMs and adding hypervisor hosts may not always be optimal.

Why not?

• Disk virtualization deprives the database software of the ability to optimize and distribute I/Os itself across disks and controllers. The database optimizer also benefits from predictable I/O behavior, which can be a problem with virtualized multi-tiered shared storage.
• Unpredictable side effects of transient load peaks on the hypervisor; these are untraceable in the VM itself, and a DBA can no longer tell with absolute certainty what the underlying cause of any poor database performance is (because the hypervisor “hides” the physical hardware load from the VM).
• Oracle software licensing is more complex; you typically need to license hardware, not VMs.
• Efficiency Loss: Since Oracle software is licensed per processor in the vast majority of cases, sharing this processor with multiple VMs creates additional overhead. Each VM has to run an entire Windows/Linux OS and in the worst case scenario this processor has to be shared even with non-database VMs meaning you can only use a part of the licensed processing power.

Ideally, a database system is flexible, manageable, insightful and efficient and delivers the best possible performance for the euros invested in it. We believe that Oracle offers a solution for this that delivers both consolidation and management benefits; a bit of an on-site database cloud-in-a-box if you will.

DBA.nl has been supplying, installing, configuring and managing this specialized database system for several years now, which we want to bring more attention to: the Oracle Database Appliance. This appliance aims to be an optimized all-in-one solution for the provision of databases with increased availability (optional) built in.

So…. if your curiosity is piqued now read on

What is an Oracle Database Appliance?

The Oracle Database Appliance (ODA) is what Oracle calls an “engineered system”. It is the smaller brother of the famous Oracle Exadata and includes a complete, rack-mountable package of CPUs, high-performance storage, 10 GBit Ethernet and a full software stack. You only need to supply the power and network connections.

At first sight it may seem unattractive to introduce a new type of system into your environment because nobody wants an unnecessary introduction of new knowledge requirements and procedures for software patching, firmware updates, disk/network configuration, hardware -maintenance, etc.

However, such fears are unfounded. From the outset, ODA was intended as a system that can be set up and managed relatively easily. A self-assembled set of storage, network switches, server hardware, Operating System and Oracle database requires good knowledge of all these components to configure, manage and upgrade it. The ODA, on the other hand, is already built in such a way that the components are guaranteed to match each other and is in that sense plug-and-play. Management has also been thought of. The ODA is equipped with smart tooling that makes it possible to keep control from system configuration to creating/deleting/upgrading databases with one utility. This single point of control not only makes the management of an ODA very consistent, but also makes it unnecessary to know in detail how the individual components are controlled.

Being a complete system, Oracle provides consolidated patches for software and firmware. There is no need for an administrator to search for separate updates for drivers, databases, operating system, etc. This reduces the chance of problems because separate checks are no longer required on the reliable cooperation of hardware, storage, network, operating system and database software. The system also comes with full hardware support. This allows the machine to be managed and maintained in its entirety by a DBA without the need for training or assistance from system administrators. Indeed, the machine is simply on-site but does not take up the capacity of your system administrators. An ODA contains (Linux) nodes for running the databases, but due to their extensive system integration and specialized function, they do not have to be treated as manageable platforms that would have to be adapted to an existing infrastructure.

Although an ODA is normally supplied and deployed as a bare-metal system, it is also possible to virtualize it using Oracle VM. It was previously argued that virtualization is not always obvious, but there are situations where existing management procedures and/or role separations facilitate the distribution of databases over multiple servers. It also happens that there is a desire to host other Oracle environments (such as Weblogic servers) with the databases. So if there is a need for multiple virtual servers, the ODA can still be useful as a consolidation platform.

The hardware of the ODA is aimed at achieving optimal database performance, partly thanks to the integrated NVMe SSDs, controlled by Oracle’s ASM software. Very high I/O bandwidth for your databases without your SAN noticing. The fact that the disks/SSDs are directly addressable by the database system makes it possible to tailor the RAID set(s) specifically and in daily practice a DBA can also see exactly where the I/Os are going without having to spend time consuming monitoring processes on shared storage.

But what if you do not yet know how much capacity you will need in the long term? This aspect has also been eliminated. By means of Capacity-on-demand licensing you can choose to use only a small part of the ODA (for example only 2 CPU cores) and to upgrade more CPU cores and/or disks later if necessary. This is not possible with a traditional server solution.

There are three sizes of ODAs. The models are:

The most important things at a glance:

• No SAN required
• Licenses from 2 to 72 CPU cores, you can vary according to your needs
• Standard or Enterprise Edition databases (on X6-2-HA only SE in a VM)
• Virtualization using Oracle VM is possible
• Very high performance relative to the capacity to be licensed
• No separate patches or maintenance contracts required
• One point of contact for any problems
• Manageable by a DBA, highly via only one tool (oakcli)
• Fits in any 19inch ServerRack
• Thanks to ILOM, the machine can also be switched on and off and troubleshooting remotely.
• Model X6-2HA can be equipped with RAC for high availability. DataGuard can of course be used to update a standby database. This can be towards another ODA, but possibly also towards another server or VM.

The ODA in practice

The implementation of an ODA follows a process that DBA.nl knows well. The start of this is determining the needs and adjusting the optimal system configuration accordingly, such as the number of CPU cores to be activated, disk configuration, network connections and whether or not the ODA is virtualized. We also make agreements about periodic maintenance, such as checking and applying future ODA bundle patches and keeping overall health indicators of the ODA and the components, VMs and databases installed on it. The system is connected and configured by us on site using a checklist. This ensures that the hardware functions properly, that the system can be accessed remotely and that the automatic error reporting to Oracle (ASR: Auto Service Request) works. If everything appears to be in order, the configuration of the Linux nodes, network addresses and storage can be done and the system is ready to use.

For regular activities, database management on an ODA is not much different in practice than on other systems. Databases on an ODA are not special and can therefore be used and maintained like any other Oracle database. The difference (for a DBA) only becomes clear when creating, upgrading and/or deleting a database. These activities are carried out on an ODA using the “oakcli” utility. This utility is the software equivalent of a Swiss Army Knife and is used for almost all changes that can be performed. This varies from configuring available CPUs and network addresses to creating new databases.

DBA.nl now has quite a few ODAs under management throughout the Netherlands and has noticed that existing customers again opt for a new ODA after the old one has been written off. We have not yet experienced that an ODA has been replaced by traditional (virtual) servers.

If you have become interested and would like to know more, please do not hesitate to contact us for more information or, for example, a proof-of-concept. We are happy to help you.