Chapter 2
Oracle Database Architecture

by Joe Greene

In This Chapter

•  Database Architecture

•  Oracle Processes

•  Memory and Speed

•  Disk Storage

•  Interfacing with the DBMS

•  Multiprocessor Configurations

•  Fault Tolerance

•  Microsoft Windows NT Configurations

Oracle8 is a rather complicated animal, even if you just consider the database itself and ignore all of the optional components, tools, and applications that are built on the Oracle8 architecture. There are a number of people who are expert Oracle developers or system support types who have never seen the need to understand what is “under the hood” in the Oracle database. This chapter is designed as your first peek into the guts of the Oracle relational database management system so you can understand why the system works the way it does and what you can do to take advantage of its architecture.

For those of you who are truly brave, I invite you to examine Part III of this book (“Oracle8 Components and Objects”) for a more detailed discussion of the topics previewed in this chapter. The chapters in this section go into the details that might help you speed up a job here or reduce your memory utilization there to make your application lean and efficient. For those of you who are already comfortable with the architecture of the Oracle version 7 database management system, you can probably skip this chapter. I was impressed at the way the Oracle7 architecture was able to accommodate the significant functional changes listed in Chapter 1, “Oracle8,” without a major rewrite. For the rest of you, I present this chapter to discuss what the components of Oracle8 are and how they interact with one another.

Database Architecture

Oracle is primarily designed to work in multiuser, multitasking computer environments. There have been versions of Oracle that work in batch processing environments (for example, IBM mainframes running S) and single-user, single-task environments such as the PC. However, the basic architecture is designed to work well with operating systems such as UNIX, VMS, and so forth. There are a few key concepts about these operating system environments you should know:

•  These operating systems run multiple jobs or processes at the same time. The system cycles between the jobs and gives processing time to the processes that are ready to do something. Some operating systems enable you to control the priority of the jobs so that certain jobs get more time than others.

•  The memory of these computers is divided into space reserved for the operating system, space reserved for the users, and space that is shared by multiple processes. The shared memory areas are not normally used by applications; however, as you will see, Oracle makes extensive use of shared memory areas.

•  The disk drives are shared between multiple users. Some form of security is usually present to control which users or groups of users can access data on particular disk drives.

Instances

One of the first concepts you need to understand about Oracle is the difference between an instance and a database. Think of this as your first Oracle-ism (those little quirks seen when you walk in the world of Oracle). A database is an organized collection of data stored in data files. An instance is the set of processes and memory areas that provide the capability of accessing this data. You need both to have a useful system.

The complexity and wonder of the Oracle RDBMS (see Figure 2.1) can be divided into three simple parts:

•  Background processes

•  Shared memory areas

•  Disk data storage areas

Figure 2.1.  The pieces of the Oracle RDBMS.

In most PC database environments, such as dBASE and Access, you interact directly with the data files using their DBMS commands. This works well for single-user, PC-based systems, but causes problems for large, multiuser systems such as Oracle. For example, how would the system coordinate two users writing records to a single table and index? Oracle, like most other multiuser database management systems, uses a series of background processes to accomplish the data writing process. Splitting the tasks into multiple processes also reduces the complexity of each of these processes, which is significant, considering how complex the system already is. These processes can be thought of as a series of specialists, each working on a particular task. For example, when a user writes changes to the database, these changes are placed in a memory area. When the memory area is ready to be written to disk, the database writer process transfers the changes from memory to the appropriate records on disk. The only data transmissions across the network are the query/transaction and the results. This reduces the network traffic and speeds application processing.

The exact number and configuration of the Oracle background processes depends on operating parameters, tuning parameters, and the optional packages selected by the database administrator. For example, if you want to keep all the files that log transactions applied to the database, you start an archiving process that copies these log files to tape or another area on disk. If you want to have many input/output database write operations being performed at the same time, you start multiple asynchronous database writer processes (you set up the number as a configuration parameter). If you are starting to get confused about how many processes to start, don’t worry. The basic configuration (hard coded into the DBMS software) works well for most situations. Later chapters discuss when to start the additional processes to improve performance or provide additional services (the checkpoint process, for example). For now, it is enough to understand the basic concepts of the background processes.

The final component in the Oracle database architecture is the memory areas. It is based on a very simple principle—memory is much faster to access than disk. When users need to write something, have them write it to memory and then go on about their business. When retrieving rows from the database, retrieve a few extra into memory and hope the next row the user needs is in that batch. A fair amount of the complexity of the Oracle RDBMS lies in the algorithms used to decide what to store in memory. Much of the tuning process involves working to achieve proper sizing of these memory areas. There’s a section later in this chapter, “Memory and Speed,” plus an entire chapter of this book (Chapter 10, “Oracle Memory Areas”) that discuss the memory areas.