Database Reference
In-Depth Information
What I'll do, then, is define some terms and give a general overview of what Oracle looks like (if you were to
draw it on a whiteboard). There will be two architectures to consider. One is the architecture the Oracle database
employed exclusively from version 6 through 11
g
(referred to now as
single tenant
in this topic) and a new multitenant
architecture available with Oracle 12
c
. You'll then be ready to get into some of the details.
Defining Database and Instance
There are two terms that, when used in an Oracle context, seem to cause a great deal of confusion:
database
and
instance
. In Oracle terminology, the definitions of these terms are as follows:
•
Database
: A collection of physical operating system files or disks. When using Oracle
Automatic Storage Management (ASM) or RAW partitions, the database may not appear as
individual, separate files in the operating system, but the definition remains the same. There
are three distinct types of databases in Oracle Database 12
c
.
•
A single-tenant database
: This is a self-contained set of data files, control files, redo log
files, parameter files, and so on, that include all of the Oracle metadata (the definition of
ALL_OBJECTS
, for example), Oracle data, and Oracle code (such as the code for
DBMS_OUTPUT
), in addition to all of the application metadata, data, and code. This is the
only type of database in releases prior to version 12
c
.
•
A container or root database
: This is a self-contained set of data files, control files, redo
log files, parameter files, and so on, that only include the Oracle metadata, Oracle data,
and Oracle code. There are no application objects or code in these data files—only
Oracle-supplied metadata and Oracle-supplied code objects. This database is
self-contained in that it can be mounted and opened without any other supporting
physical structures.
•
A pluggable database
: This is a set of data files only. It is not self-contained. A pluggable
database needs a container database to be “plugged into” to be opened and accessible.
These data files contain only metadata for application objects, application data, and
code for those applications. There is no Oracle metadata or any Oracle code in these data
files. There are no redo log files, control files, parameter files, and so on—only data files
associated with a pluggable database. The pluggable database inherits these other types
of files from the container database it is currently plugged into.
•
Instance:
A set of Oracle background processes or threads and a shared memory area, which
is memory that is shared across those threads or processes running on a single computer. This
is the place for volatile, nonpersistent stuff, some of which gets flushed to disk. A database
instance can exist without any disk storage whatsoever. It might not be the most useful thing
in the world, but thinking about it that way definitely helps draw the line between the instance
and the database.
The two terms,
instance
and
database
, are sometimes used interchangeably, but they embrace very different
concepts, especially now in the multitenant architecture. The relationship between them is that a single-tenant or
container database (herein referred to simply as
database
, meaning either a single-tenant or container database;
when discussing pluggable databases,
pluggable
will be explicitly referenced) may be mounted and opened by
many instances. An instance may mount and open just a single database at any point in time. In fact, it is true to say
that an instance will mount and open, at most, a single database in its entire lifetime! We'll look at an example of
that in a moment.
