Database Reference
In-Depth Information
Chapter 2
Architecture Overview
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'll 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-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 chapter, I present a broad picture of this architecture. We'll 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). We'll 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'll look in detail at the three major components of the Oracle
architecture:
•
Chapter 3 covers files. Here we'll look at the five general categories of files that make up the
database: parameter, data, temp, control, and redo log files. We'll also cover other types of
files, including trace, alert, dump (DMP), data pump, and simple flat files. We'll look at the
file area (in Oracle 10
g
and above) called the Fast Recovery Area, and we'll also discuss the
impact that Automatic Storage Management (ASM) has on file storage.
•
Chapter 4 covers the Oracle memory structures referred to as the System Global Area (SGA),
Process Global Area (PGA), and User Global Area (UGA). We'll examine the relationships
between these structures, and we'll also discuss the shared pool, large pool, Java pool, and
various other SGA components.
•
Chapter 5 covers Oracle's physical processes or threads. We'll look at the three different types
of processes that will be running on the database: server processes, background processes,
and slave processes.
It was hard to decide which of these components to cover first. The processes use the SGA, so discussing the SGA
before the processes might not make sense. On the other hand, when discussing the processes and what they do, I'll
need to make references to the SGA. These two components are closely tied: the files are acted on by the processes
and won't make sense without first understanding what the processes do.
