Database Reference
In-Depth Information
So, for example, the container database would have the definition of the “
SYS
” user (the metadata for the
SYS
user) and the compiled code and source code for objects like
DBMS_OUTPUT
and
UTL_FILE
. A pluggable database, on
the other hand, would have the definition of an application schema like
SCOTT
, all of the metadata describing the
tables in the
SCOTT
schema, all of the PL/SQL source code for the
SCOTT
schema, all of the
GRANTS
granted to the
SCOTT
schema, and so on. In short, a pluggable database has everything that describes a set of application schemas—the
metadata for the accounts, the metadata for the tables in those accounts, and the actual data for those tables. A
pluggable database is self-contained with respect to the application accounts it contains, but it needs a container
database to be “opened” and queried. Therefore, you can say that a pluggable database is not “self-contained,”
it needs something else in order to be opened and used.
A pluggable database is not directly opened by an instance, but rather an Oracle instance must be started and a
container database mounted and opened by that instance. Once the container instance is up and running, and the
container database is opened, that container database may open as many as 250 separate pluggable databases. Each
of these pluggable databases acts as if it were a “stand-alone” database. That is, they appear to be self-contained,
stand-alone “single tenant” databases. But they all share the same container database and container instance.
The main goals of the pluggable database, the multitenant architecture, are twofold:
•
To measurably reduce the amount of resources it takes to host many databases—many
applications—on a single host.
•
To reduce the maintenance work performed by the DBA to manage many databases—many
applications—on a single host.
Reduced Resource Utilization
As you've already seen, when you start an Oracle instance, there are many processes associated with it. In Chapter 5
you'll be introduced to each of them and see what they do; but as you can see, each instance is supported by some
20 to 40 processes. If you attempted to start up 50 single-tenant databases—where each database has an instance
associated with it, or its own instance—you would have upward of 1,000 processes just to get the databases started!
That is extremely taxing on the operating system, both to create that many processes and then to manage them.
Additionally, each instance would have its own SGA. Chapter 4 will cover what is in the SGA, but suffice it to say,
there is a lot of duplication. Each SGA would have a cached copy of
DBMS_OUTPUT
in its shared pool, and each SGA
would have a redo log buffer and many other duplicative data structures.
With pluggable databases, you can have the separation of application metadata, users, data, code, and so on, but
avoid the redundant instances. That is, you can have a single instance with a single container database (the Oracle
metadata, code, and data) that provides access to as many as 250 pluggable databases, each hosting a separate application.
Instead of 1,000 processes to start up 50 separate application databases, you can have 51 databases (one container and
50 application databases) sharing the same 20 to 40 processes. That's a massive reduction in server resource utilization.
Additionally, they all share a common SGA, allowing the repetitive parts of the 50 separate SGAs that would normally have
to be shared. In general, the size of the single SGA you would allocate for these 50 application databases will be smaller
than the sum of the 50 separate SGAs you would have to allocate otherwise.
Reduced Maintenance
If a DBA were tasked with managing 50 separate databases using the single-tenant architecture, she would have 50
databases to backup, monitor, manage, patch, upgrade, and so on. Each database would be managed independent
from every other database. In the multitenant architecture, there is a single “database” she would need to backup,
monitor, manage, patch, upgrade and so on. For example, the act of patching an Oracle database involves updating
the Oracle executables (updating the instance) and updating the Oracle metadata—the Oracle data dictionary. When
a DBA patches a database, she does not touch any of the underlying application metadata, schemas, data, code, and
so on—she only touches the Oracle instance and the Oracle metadata, data, and code.
