Consolidation as an industry trend - Expert Consolidation in Oracle Database 12c - page 2

Finishing the chapter you are presented with an appetizer to Chapter 3 which explains a little more about
hardware changes and platform trends. The chapter will focus on the Intel architecture before giving you an insight
into developments of the other relevant platforms for the Oracle database. Hopefully, at the end of the chapter you
should have a better understanding about the motivation behind this topic, and why the Linux on x86-64 proposition
is a valuable one.

Consolidation
You, dear reader, are probably using this topic because a team somewhere in your organization decided that it was
time to consolidate databases and servers. Such a decision may have been made for many reasons, but most likely
somewhere cost is involved. When this topic was written, the economic outlook for the immediate future was not
great. The Eurozone was in financial trouble, and the United States was not much better off. Few economies in the
world grew, and even less so by more than one percent.
As a direct consequence many companies downsized support teams looking after the essential business
applications, increasing the burden on the remaining production support staff. What was not reduced, or at least not
in the same proportion, was the workload. This factor plays considerably into the steadily increasing number of tasks
to be juggled by the reduced workforce.
As another consequence engineering departments or local production support teams need to come up with ideas
on how to streamline their efforts, and to make it as easy as possible for new starters to become productive sooner.

■ “engineering” in this context refers to the team responsible for developing and certifying new (oracle) releases,
documenting processes, and performing third-line support. this is in contrast to the operational team which keeps the
databases running.

Note

Additionally, companies review their existing hardware estate with special emphasis on cost reduction. The
buzzwords associated with this situation are the ones heard often, and they are discussed in this topic: automation
and consolidation . If the workload cannot be reduced, then it undoubtedly has to be managed (more) efficiently.
For example, database administrators should not spend time on tasks that are repetitive and time consuming.
Provisioning a database used to be a long process when you run the dictionary creation scripts. While the DBA can
simply kick off the create database statement followed by invocations of catalog.sql and catproc.sql manually,
it would be better if the DBA could simply call a procedure that does the work on his behalf and simply returns a
success/error message back while he does other work.
However, this automated procedure needs to be created and maintained, and if you envision a wealth of server
platforms such as AIX, HP-UX, Solaris, and Linux in use the maintenance of any generic code applicable for all quickly
becomes very difficult. If it was instead possible to reduce the number of platforms many variables could be cut out
of the equation, and there would be less (parallel) code to maintain. Also, supporting patch instructions, bundling up
releases and other work performed in the engineering world would be greatly simplified. Database consolidation was
not the easiest of tasks before Oracle 12.1. The most stringent requirement was to have non-colliding namespaces.
For example, two users named “SCOTT” could not coexist in a consolidated database. Additionally, database links
proved tricky business and any reference and grant to PUBLIC could potentially cause unwanted side effects in the
consolidated environment. Luckily, Oracle 12c addresses these shortcomings of the previous release in a way so
elegant one is asking oneself why this has not yet been implemented before.
Now cost is not the only contributing factor to consolidation. There are other environmental aspects that could
contribute to the initiation of a project. Let's look at these in more detail.