Database Reference
In-Depth Information
Under the multitenant architecture, each of the 50 pluggable databases containing the application data share a
common instance; hence when the DBA patches the instance, all 50 pluggable databases are patched instance wise.
Likewise, when the DBA patches the container database, the self-contained set of files that hold the Oracle metadata,
code, and data, all 50 pluggable databases inherit those updates. They share that Oracle metadata, code, and data. So
the act of patching a single container database would, in fact, patch all of the underlying pluggable databases.
If that is not desirable (patching all 50 at once), an alternative approach can be applied. Instead of patching
the existing container database, the DBA can just create a new container database that is patched. So now there are
two Oracle instances with two container databases: one at version X and the other at version Y. In order to patch a
pluggable database, the DBA “unplugs” it from the container database to which it is currently attached. Unplugging
creates an XML manifest file that describes the files belonging to that pluggable database. Then, the DBA “plugs”
that pluggable data into the new container database. The act of unplugging a pluggable database is very lightweight
and fast—all that needs to be done is to create the XML manifest file. The act of plugging in a database is likewise
lightweight and fast—the XML manifest file is read, the files associated with the pluggable database are registered
with the container database, and the pluggable database can be used again. The pluggable database is patched or
upgraded simply by plugging it into a container database that is patched. The DBA has one container database to
manage, patch, upgrade, and so on. The pluggable databases just inherit that work.
How Is a Pluggable Database Different?
From the perspective of a developer, a pluggable database is no different from a single-tenant database. The
application connects to the database in exactly the same way it would connect to a single-tenant database in earlier
releases. The earlier examples of creating connections, using shared servers, and using dedicated servers all still
apply. The differences lie in the underlying architecture—that of a single instance for many pluggable databases, and
the resulting reduced resource utilization on the server and the ease of management for the DBA.
From a DBA perspective, there are many changes in the way a database is administered—positive changes. For
example, if a DBA configured a container database for RAC, every pluggable database under that container would
be RAC enabled. The same with Data Guard, RMAN backups, and so on. The DBA has one instance to configure and
work with, instead of one instance per application as in the past.
Summary
This completes our overview of the Oracle architecture. In this chapter, we defined the terms instance , database , and
pluggable database , and saw how to connect to the database through either a dedicated server connection or a shared
server connection. Figure 2-6 sums up the material covered in the chapter and shows the interaction between a
client using a shared server connection and a client using a dedicated server connection. It also shows that an Oracle
instance may use both connection types simultaneously. (In fact, an Oracle database always supports dedicated
server connections—even when configured for shared server.)
 
Search WWH ::




Custom Search