Understanding the architecture of a running Oracle database instance is one of the key differentiators between an outstanding DBA and a run-of-the-mill DBA.
Learn the architecture well. I am always surprised at how many people do not do this.
Knowledge and understanding of how Oracle works behind the scenes is critical to the tuning process.
It can also be very helpful when it comes to planning for backup and recovery.
If you learn the architecture well, you will be able to solve problems that other people can not, and you will be well on your way to certification and a successful career as a DBA.
Oracle is designed to be a very portable database, it is available on every platform of relevance, from Windows to UNIX/Linux to mainframes.
However, the physical architecture of Oracle looks different on different operating systems.
For example, on a UNIX/Linux operating system, you will see Oracle implemented as many different operating system processes, virtually a process per major function. On UNIX/Linux, this is the correct implementation, as it works on a multiprocess foundation.
On Windows, however, this architecture would be inappropriate and would not work very well (it would be slow and nonscalable).
On the Windows platform, Oracle is implemented as a single process with multiple threads.
In the past, on IBM mainframe systems, running OS/390 and z/OS, the Oracle operating system's specific architecture exploits multiple OS/390 address spaces, all operating as a single Oracle instance.
Up to 255 address spaces can be configured for a single database instance.
Moreover, Oracle works together with OS/390 Workload Manager (WLM) to establish the execution priority of specific Oracle workloads relative to each other and relative to all other work in the OS/390 system. Even though the physical mechanisms used to implement Oracle from platform to platform vary,
the architecture is sufficiently generalized that you can get a good understanding of how Oracle works on all platforms.
In this module, I present a broad picture of this architecture. We will take a look at the Oracle server and define some terms such as
- container database, and
- instance (terms that always seem to cause confusion).
We will take a look at what happens when you connect to Oracle and, at a high level, how the server
manages memory. In the subsequent three chapters, we will look in detail at the three major components of the Oracle architecture:
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.
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 (RAC) Oracle Real Application Clusters,
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 us start by taking a look at a simple example. Let us say we have just installed Oracle 12c version 220.127.116.11 on our UNIX/Linux based computer.
We did a software-only installation. No starter databases, with nothing just the software.
The pwd command shows the current working directory, dbs (on Windows, this would be the database directory) and the
command shows that the directory is empty. There is no init.ora file and no SPFILEs (stored parameter files;).