Database Reference
In-Depth Information
A pluggable database will be associated with a single container database at a time and is only indirectly
associated with an instance; it will share the instance created to mount and open the container database. So, like a
container database, a pluggable database can be associated with one or more instances at any point in time. Unlike
a single-tenant database, however, an instance may be providing access to many (up to around 250) pluggable
databases simultaneously. That is, a single instance may be providing services for many pluggable databases, but only
one container or single-tenant database.
Confused even more? Some further explanation should help clear up these concepts.
An instance is simply a set of operating system processes, or a single process with many threads, and some
memory. These processes can operate on a single database, which is just a collection of files (data files, temporary files,
redo log files, and control files). At any time, an instance will have only one set of files (one container or single-tenant
database) associated with it. Multiple pluggable databases, subordinate to the container database, can be open and
accessible simultaneously—but will all share the single instance created to open the container database.
In most cases, the opposite is true as well: a container or single-tenant database will have only one instance
working on it. However, in the special case of Oracle Real Application Clusters (RAC), an Oracle option that allows it to
function on many computers in a clustered environment, we may have many instances simultaneously mounting and
opening this one database, which resides on a set of shared physical disks. This gives us access to this single database
from many different computers at the same time. Oracle RAC provides for extremely highly available systems and has
the potential to architect extremely scalable solutions.
Let's start by taking a look at a simple example. Let's say we've just installed Oracle 12 c version 12.1.0.1 on our
UNIX/Linux-based computer. We did a software-only installation. No starter databases, nothing—just the software.
The pwd command shows the current working directory, dbs (on Windows, this would be the database directory)
and the ls -l command shows that the directory is empty. There is no init.ora file and no SPFILEs (stored
parameter files; these will be discussed in detail in Chapter 3).
[ora12cr1@dellpe dbs]$ pwd
/home/ora12cr1/app/ora12cr1/product/12.1.0/dbhome_1/dbs
[ora12cr1@dellpe dbs]$ ls -l
total 0
Using the ps (process status) command, we can see all processes being run by the user ora12cr1 (the Oracle
software owner in this case). There are no Oracle database processes whatsoever at this point.
[ora12cr1@dellpe dbs]$ ps -aef | grep ora12cr1
root 18392 15416 0 14:31 pts/1 00:00:00 su - ora12cr1
ora12cr1 18401 18392 0 14:31 pts/1 00:00:00 -bash
ora12cr1 18461 18401 0 14:34 pts/1 00:00:00 ps -aef
ora12cr1 18462 18401 0 14:34 pts/1 00:00:00 grep ora12cr1
We then enter the ipcs command, a UNIX/Linux command that is used to show interprocess communication
devices, such as shared memory, semaphores, and the like. Currently, there are none in use on this system at all.
[ora12cr1@dellpe dbs]$ ipcs -a
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
------ Semaphore Arrays --------
key semid owner perms nsems
------ Message Queues --------
key msqid owner perms used-bytes messages
 
Search WWH ::




Custom Search