Pluggable Databases - Expert Consolidation in Oracle Database 12c - page 224

• Users with elevated privileges (the DBA role, all privileges with “any” in their name) can

read or even modify data in schemas they should not have access to unless special access
restrictions are in place.

• Auditing is made difficult as there is no concept of logical partitioning by application—all

events are recorded on the database level.

• Restore operations are complicated by the requirement to get approvals from the applications

not impacted by the data corruption.

There are of course some more, the ones mentioned above are the most obvious ones. In the past, some users
tried to get around the namespace restrictions by using dedicated databases per consolidated application. Although
that solved quite a few of the above-mentioned problems, this comes at the cost of a greatly amplified overhead
caused by additional background processes and memory requirements. For this reason the database-per-application
approach does not scale well.
Another common way of consolidating databases was to create virtual environments with exactly one database in
it. This approach is very heavily used in x86-64-based virtualization, but can also be found in the form of Solaris Zones
or IBM LPARs. Although there are benefits in terms of isolation of workloads, you should not forget to account for the
operating system patching if a full operating system stack is to be maintained. Granted, there is less overhead when
using Operating System virtualization such as Solaris Zones, since each virtual copy of the operating system is based
on the global operating environment. Figure 7-1 compares the three most popular consolidation approaches before
the release of Oracle 12c.

Figure 7-1. Common consolidation methods pre Oracle 12.1