Thursday Oct 03, 2013

Comparing Oracle Database Appliance (ODA) with manually built and assembled systems

I thought I ought to have this note to outline the differences between typical old-style system building approach and the engineered system approach used for Oracle Database Appliance. Oracle Database Appliance is a unique, modern product that is revolutionary and disruptive. It is an Oracle engineered system that serves as a highly available database and application server. Its benefits are unique and unparalleled. However, as with any new, disruptive product, users may not readily recognize all the benefits. Often new customers ask for the benefits of choosing Oracle Database Appliance versus building your own system. The matrix below tries to summarize the benefits.

Oracle Database Appliance

Manually assembled systems

Single vendor – Customer only needs to contact Oracle for any and all problems with the system. Oracle is able to rapidly diagnose the problem, match it with a fingerprint of the issue, and provide immediate solution.

Multiple vendors – Servers, storage, networking gear, and software components may be sourced from different vendors, that causes finger pointing and makes it hard to obtain support quickly and effectively

No integration required – Oracle Database Appliance is a pre-integrated, pre-tested, pre-tuned configuration. It requires no integration, other than simply plugging in some cables.

Extensive integration required – The components sourced from multiple vendors must be compatible and interoperate successfully.

Instant deployment – Deployment of Oracle Database Appliance in a customer environment is as easy as plugging in the cables, powering on the system and issuing a command.

Long drawn error prone deployment process – Deployment of a manually built system requires setting up and validating each component, going through multiple steps to configure operating system, networking, storage, database, and so forth. A missed-step can be costly.

Best practices are included – Oracle Database Appliance is built from the grounds up with Oracle’s best practices in mind. These best practices cover operating system, networking, storage, database, and performance and availability best practices.

Best practices implementation requires considerable extra effort - Best practices must be identified and implemented for each component. This may not be an easy task by any measure.

Patching is quick and predictable – With a known hardware and software configuration, Oracle is able to provide pre-tested, complete patch bundles that cover the entire firmware and software stack. Further, Oracle is able to structure and tune the patching process so that it executed flawlessly in an optimal amount of time with predictable results.

Patching is time consuming, risky and unpredictable – Customers often patch one component at a time, thereby increasing the frequency of patching. Patching process is unpredictable and therefore risky. Vendors have no way of testing the exact configuration that a customer may be using.

Problem diagnostics are immediate – Oracle knows exactly which information and logs are required for instant diagnosis of problems as well as how to collect it. Oracle makes it trivial for customers to collect the information. Quick diagnosis results in rapid problem resolution.

Problem diagnostics is complex and long drawn – Multiple experts may be needed to diagnose problems. Often it may not be readily apparent what information is relevant and required for a corresponding problem. Longer diagnosis results in delayed problem resolution.

Performance is predictable – An engineered system makes deploying workloads a science not an art. The system capacity and capability can be quantified exactly and workloads can be deployed using simple mathematics.

Performance may not always be predictable – Making workloads perform on manually assembled systems remains an art. Due to the various components and stack layers from different vendors, typically configured using an imprecise math, it is usually not possible to define capacity and capability correctly.

Service requests can be opened automatically – In case of a problem, such as hardware failure, a service request can be opened automatically by the system using Oracle Auto Service Request. A solution may be available even before the customer recognizes the problem.

Service request initiation and management is complex – In case of a problem first the correct vendor needs to be identified. The service request needs to be manually managed and diagnostics data needs to be identified, manually collected, and sent to the vendor. Manual analysis of diagnostics further delays solution that may need to be tested before it is deployed.

Storage is integrated and managed as a whole – Storage is pre-integrated with the servers and the system is managed end-to-end as a whole, including monitoring, management, diagnostics, and repair of storage.

Storage is separate and managed separately – Storage is managed, monitored, diagnosed and repaired separately, typically provided by a different vendor and managed by storage administrators

Pay-as-you-go licensing saves costs substantially – Significant CPU power available but only CPUs used need to be licensed while the remaining CPU power is available for instant deployment if and when needed

Must pay for all CPUs on the system upfront – All CPUs present in the servers must be licensed upfront whether fully used or not. Additional CPU addition typically requires costly hardware upgrades

Versatile system with support for both native and virtualized environments – The same system and software supports both native and virtualized implementations, switching from one to the other is easy

Typically vendor specialized hardware sold for native or virtualized implementations – Implementation of native and virtualized environments could be fundamentally different.

Host both application and database in a single system (system in a box) – Supports hosting of entire application stack in a single system; virtualized platform makes it possible to segregate different tiers of application stack into different virtual machines that are easy to size and tune

Application is typically hosted on separate hardware (one system many boxes) – Application, web, and database tiers are typically hosted on separate hardware and storage; it is not easy to resize these environments unless hardware is replaced

It is amazing!

About

The Oracle Database Appliance saves time and money by simplifying deployment, maintenance, and support of high-availability database solutions. This blog is dedicated to sharing updates about the Oracle Database Appliance from your product team.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today