An Oracle database is composed of files. There are several types of files, and it is important that you as the DBA understand the purpose of each file, as well as what it contains. This module will help you do that.
Understand the Components of an Oracle Database
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
database,
pluggable
database,
container database, and
instance (terms that always seem to cause confusion).
How the Server manages memory?
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.
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 (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 12.1.0.1 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
ls -l
command shows that the directory is empty. There is no init.ora file and no SPFILEs (stored parameter files;).
When you have completed this module, you will be able to:
Identify the different files used by a database
Edit and understand a database initialization file
Explain the use and importance of redo logs for instance recovery
Understand the relationship between tablespaces and datafiles
Tablespaces, Datafiles, and Control Files
Oracle stores data logically in tablespaces and physically in datafiles associated with the corresponding tablespace. Figure 3-1 illustrates this relationship. Databases, tablespaces, and datafiles are closely related, but they have important differences:
An Oracle database consists of one or more logical storage units called tablespaces, which collectively store all of the database's data.
Each tablespace in an Oracle database consists of one or more files called datafiles, which are physical structures that conform to the operating system in which Oracle is running.
The data of a database is collectively stored in the datafiles that constitute each tablespace of the database. For example, the simplest Oracle database would have one tablespace and one datafile. Another database can have three tablespaces, each consisting of two datafiles
(for a total of six datafiles).