1. Define a Database
Oracle Database 11g is the latest offering from Oracle. Perhaps you have heard a lot of hype about Oracle Database 11g, and perhaps not. Regardless of your experience, 11g
is a rich, full-featured software intended to revolutionize the way
many companies do their database business. Think of a database as the
Fort Knox for your information. A database is an electronic collection
of information designed to meet a handful of needs:
What is a database?
Databases provide one-stop shopping for all your data storage
requirements, no matter whether the information has to do with human
resources, finance, inventory, sales, or something else. The database
can contain any amount of data, from very little to very big. Data
volumes in excess of many hundreds of gigabytes are commonplace in this
day and age, where a gigabyte is 1,073,741,824 bytes.
What must it be able to do?
Databases must provide mechanisms for retrieving data quickly as
applications interact with their contents. It is one thing to store tax
information for the 300 million citizens of a country, but it’s another
kettle of fish to retrieve that data, as required, in a short time
period.
How is it suitable for corporate data?
Databases allow the sharing of corporate data such that personnel data
is shared amongst one’s payroll, benefits, and pension systems. A
familiar adage in the database industry is “write once, read many.”
Databases are a manifestation of that saying—one’s name, address, and
other basic personnel information are stored in one place and read by as
many systems requiring these details.
Figure 1
shows, in a nutshell, the components that come together to deliver the
corporate database management solution affectionately called Oracle
Database 11g.
There is a great deal of
academic interest in the database industry, because the theory of the
relational database is founded in relational algebra. As data is entered
into and stored in Oracle Database 11g, the relationships it has to other data are defined
as well. This allows the assembling of required data as applications
run. These relationships can be described in plain English for a
fictitious computer parts store in the following example:
Each geographical location that the store does business in is uniquely identified by a quad_id.
Each
manufacturer that supplies parts is uniquely identified by a
ten-character manufacturer_id. When a new manufacturer is registered
with the system, it is assigned a quad_id based on its location.
Each
item in the store’s inventory is uniquely identified by a ten-character
part_id and must be associated with a valid manufacturer_id.
Based on these three points,
practitioners commonly develop statements similar to the following to
describe the relationships between locations, manufacturers, and parts:
A one-to-many relationship Locations and manufacturers—more than one manufacturer can reside in a specified location.
A many-to-many relationship Manufacturers and computer parts—the store purchases many different parts from each manufacturer.
These
two relationships are established as data is captured in the store’s
database and other relationships can be deduced as a result—for example,
one can safely say “parts
are manufactured in one or more locations based on the fact that there
are many manufacturers supplying many different products.” Oracle has
always been a relational database product, commanding a significant
percentage of market share compared to its major competition. Let’s get
started and look at the Oracle Database 11g architecture.
2. Learn the Oracle Database 11g Architecture
As with many new software experiences, there is some jargon that we should get out of the way before starting this section.
Startup This is the act of issuing the appropriate commands to make an Oracle Database 11g accessible to applications. After a startup activity completes, the database is referred to as opened. Once opened, the database moves to the next step where it is started. At this point, the database is ready to use.
Shutdown This is the act of stopping Oracle Database 11g. When Oracle Database 11g is shut down, nobody can access the data in its files.
Instance
This is a set of processes that run in a computer’s memory and provide
access to the many files that come together to define themselves as
Oracle Database 11g.
Background processes These are processes that support access to an Oracle Database 11g
that has been started, playing a vital role in Oracle’s database
implementation. Various background processes are spawned when the
database is started and each performs a handful of tasks until a
database is shut down.
Let’s look at the assortment of files and background processes that support Oracle Database 11g.
The Control Files
Oracle’s control files are binary files containing information about the assortment of files that come together to support Oracle Database 11g.
They contain information that describes the names, locations, and sizes
of the database files. Oracle insists there is only one control file,
but knowledgeable technicians have two or three and sometimes more. As
Oracle Database 11g is started, the control files are read and the files described therein are opened to support the running database.
The Online Redo Logs
As sessions interact with Oracle Database 11g,
the details of their activities are recorded in the online redo logs.
Redo logs may be thought of as transaction logs; these logs collect
transactions. A transaction
is a unit of work, passed to the database for processing. The following
listing shows a few activities that can be referred to as two
transactions:
-- Begin of transaction #1
create some new information
update some existing information
create some more new information
delete some information
save all the work that has been accomplished
-- End of transaction #1
-- Begin transaction #2
update some information
back out the update by not saving the changed data
-- End transaction #2
Oracle Database 11g
insists that there are at least two online redo logs to support the
instance. In fact, most databases have two or more redo log groups with
each group having the same number of equally sized members.
The System Tablespace
Tablespace is a fancy Oracle Database 11g name for a database file. Think of it as a space where a table resides. As an Oracle Database 11g is created, a system tablespace is built that contains Oracle’s data dictionary. As Oracle Database 11g
operates, it continually gets operational information out of its data
dictionary. As records are created, this system tablespace defines
attributes of the data it stores, such as
Data types
These are the characteristics of data stored in the database. Are they
numeric, alphanumeric, or perhaps binary of some video or audio format?
Field size
This is the maximum allowable size for fields as they are populated by
the applications. This is where, for example, a country description is
defined as from 1 to 30 characters long, containing only letters.
Ownership Who owns the information as the database data files are populated?
Viewing and manipulation rights Who is allowed to look at the data and what are the types of activities that each database user can perform on that data?
The system tablespace is a very close cousin of the sysaux tablespace discussed next.
The Sysaux Tablespace
Many of the tools and options that support the Oracle Database 11g
activities store their objects in this sysaux tablespace. This is
mandatory as a database is created. The Oracle Enterprise Manager (OEM)
Grid Control repository used to go in its own oem_repository tablespace,
but with Oracle Database 11g (and its predecessors), its objects now reside in sysaux.
Default Temporary Tablespace
As the dbca does its thing, a
tablespace is created that serves as the default location for
intermediary objects Oracle Database 11g builds as it processes SQL statements. SQL
stands for structured query language, an industry standard in the
database arena, which is used to retrieve, create, change, and update
data. Most of the work Oracle does to assemble a result set for a query
operation is done in memory. A result set
is a collection of data that qualifies for inclusion in a query passed
to Oracle. If the amount of memory allocated for query processing is
insufficient to accommodate all the activities required to assemble
data, Oracle uses this default temporary tablespace as its secondary
work area for many activities, including sorting.
Undo Tablespace
As sessions interact with Oracle Database 11g, they create, change, and delete data. Undo
is the act of restoring data to a previous state. Suppose one’s address
is changed from 123 Any Street to 456 New Street via a screen in the
personnel application. The user who is making the change has not yet
saved the transaction. Until that transaction is saved (referred to as committed in the world of Oracle Database 11g) or abandoned (referred to as rolled back in the same world), Oracle maintains a copy of the changed data in its undo tablespace.
The Server Parameter File
Oracle Database 11g sometimes calls the server parameter file its spfile. This is where its startup parameters are defined and the values in this file determine the environment
that database operates in. As one starts an Oracle instance, the spfile
is read and various memory structures are allocated based on its
contents.
Background Processes
Essentially, background processes facilitate access to Oracle Database 11g
and support the instance while it is running. These are the main
background processes; many of their names haven’t changed over the past
few releases prior to Oracle Database 11g.
The database writer (dbw0) process
This process (named dbwr in earlier versions of Oracle Database) is
responsible for writing the contents of database buffers to disk. As
sessions interact with Oracle Database 11g, all the information they use passes through Oracle’s database buffers, a segment of memory allocated for this activity.
The log writer (lgw0) process
This process (named lgwr in previous versions of Oracle Database)
manages the writing of information to the online redo logs. A log buffer
area is set aside in memory where information destined for the online
redo logs is staged. The transfer of this information from memory to
disk is handled by this process.
The checkpoint process (ckpt) This is responsible for updating information in Oracle Database 11g’s files during a checkpoint activity. A checkpoint is the activity of writing information from memory to the appropriate locations in Oracle Database 11g.
Think of a checkpoint as a stake in the ground allowing the restoration
of a system to a specific point in time. The checkpoint process may
trigger lgw0 and dbw0 to do their specialized tasks.
The system monitor (smon) process This is the gatekeeper of consistency as Oracle Database 11g runs. Consistency
defines the interrelatedness of the database components with one
another. A consistent instance must be established every time Oracle
Database 11g
starts, and it is smon’s job to continually enforce and reestablish
this consistency. Plainly put: an inconsistent database is trouble!
The process monitor (pmon)
This is responsible for cleaning up any resources that may have been
tied up by aborted sessions interacting with the database. The famous
CTRL-ALT-DEL that people tend to use to reboot a personal computer can
leave resources tied up in Oracle Database 11g. It is pmon’s job to free up these resources.
The job queue coordination (cjq0) process This is responsible for spawning job processes from Oracle Database 11g’s internal job queue. Oracle Database 11g does some self-management using its job queue, and users of the database can create jobs and have them submitted to this cjq0 coordinator.
The archiver (arc0) process
This is responsible for copying online redo logs to a secondary storage
location before they are reused by the next set of transactions.
Figure 2 illustrates the way the architecture components we have described come together to support Oracle Database 11g. Oracle Database 11g
is opened and then started, and the control files are read to get its
bearings. Then the online redo logs and the assortment of tablespaces
listed in the control files are acquired. As the instance comes to life,
the background processes take over and manage the operations of the
database from there.
