Introduction To The Oracle Server: It Includes The Following
Introduction To The Oracle Server: It Includes The Following
An Oracle database is a collection of data treated as a unit. The purpose of a database is to store
and retrieve related information. A database server is the key to solving the problems of
information management. In general, a server reliably manages a large amount of data in a
multiuser environment so that many users can concurrently access the same data. All this is
accomplished while delivering high performance. A database server also prevents unauthorized
access and provides efficient solutions for failure recovery.
The database has logical structures and physical structures. Because the physical and logical
structures are separate, the physical storage of data can be managed without affecting the access
to logical storage structures.
The logical structures of an Oracle database include schema objects, data blocks, extents,
segments, and tablespaces.
The following sections explain the physical database structures of an Oracle database, including
datafiles, redo log files, and control files.
Datafiles
Every Oracle database has one or more physical datafiles. The datafiles contain all the database
data. The data of logical database structures, such as tables and indexes, is physically stored in
the datafiles allocated for a database.
Every Oracle database has a set of two or more redo log files. The set of redo log files is
collectively known as the redo log for the database. A redo log is made up of redo entries (also
called redo records).
The primary function of the redo log is to record all changes made to data. If a failure prevents
modified data from being permanently written to the datafiles, then the changes can be obtained
from the redo log, so work is never lost.
To protect against a failure involving the redo log itself, Oracle allows a multiplexed redo log
so that two or more copies of the redo log can be maintained on different disks.
Control Files
Every Oracle database has a control file. A control file contains entries that specify the physical
structure of the database. For example, it contains the following information:
• Database name
• Names and locations of datafiles and redo log files
• Time stamp of database creation
Like the redo log, Oracle lets the control file be multiplexed for protection of the control file.
The relationship between databases, tablespaces, and datafiles (datafiles are described in the next
section)
Memory Structure and Processes Overview
An Oracle server uses memory structures and processes to manage and access the database. All
memory structures exist in the main memory of the computers that constitute the database
system. Processes are jobs that work in the memory of these computers.
The architectural features discussed in this section enable the Oracle server to support:
Figure 1-3 shows a typical variation of the Oracle server memory and process structures.
Figure 1-3 Memory Structures and Processes of Oracle
An Oracle Instance
An Oracle server consists of an Oracle database and an Oracle server instance. Every time a
database is started, a system global area (SGA) is allocated and Oracle background processes are
started. The combination of the background processes and memory buffers is called an Oracle
instance.
Memory Structures
Oracle creates and uses memory structures to complete several jobs. For example, memory stores
program code being run and data shared among users. Two basic memory structures are
associated with Oracle: the system global area and the program global area. The following
subsections explain each in detail.
The System Global Area (SGA) is a shared memory region that contains data and control
information for one Oracle instance. Oracle allocates the SGA when an instance starts and
deallocates it when the instance shuts down. Each instance has its own SGA.
The information stored in the SGA is divided into several types of memory
structures, including the database buffers, redo log buffer, and the shared
pool.
Database buffers store the most recently used blocks of data. The set of database buffers in an
instance is the database buffer cache. The buffer cache contains modified as well as unmodified
blocks. Because the most recently (and often, the most frequently) used data is kept in memory,
less disk I/O is necessary, and performance is improved.
The redo log buffer stores redo entries--a log of changes made to the database. The redo entries
stored in the redo log buffers are written to an online redo log, which is used if database
recovery is necessary. The size of the redo log is static.
The shared pool contains shared memory constructs, such as shared SQL areas. A shared SQL
area is required to process every unique SQL statement submitted to a database. A shared SQL
area contains information such as the parse tree and execution plan for the corresponding
statement. A single shared SQL area is used by multiple applications that issue the same
statement, leaving more shared memory for other uses.
The large pool is an optional area that provides large memory allocations for Oracle backup and
restore operations, I/O server processes, and session memory for the shared server and Oracle
XA (used where transactions interact with more than one database)
Program Global Area
The Program Global Area (PGA) is a memory buffer that contains data and control
information for a server process. A PGA is created by Oracle when a server process is started.
The information in a PGA depends on the Oracle configuration.
Oracle Processes
Oracle processes are invoked by other processes to perform functions on behalf of the invoking
process. The different types of Oracle processes and their specific functions are discussed in the
following sections.
Server Processes
Oracle creates server processes to handle requests from connected user processes. A server
process communicates with the user process and interacts with Oracle to carry out requests from
the associated user process. For example, if a user queries some data not already in the database
buffers of the SGA, then the associated server process reads the proper data blocks from the
datafiles into the SGA
Background Processes
Oracle creates a set of background processes for each instance. The background processes
consolidate functions that would otherwise be handled by multiple Oracle programs running for
each user process. They asynchronously perform I/O and monitor other Oracle process to
provide increased parallelism for better performance and reliability.
Each Oracle instance can use several background processes. The names of these processes are
DBWn, LGWR, CKPT, SMON, PMON, ARCn, RECO, Jnnn, Dnnn, LMS, and QMNn.
The database writer writes modified blocks from the database buffer cache to the datafiles.
Although one database writer process (DBW0) is sufficient for most systems, you can configure
additional processes (DBW1 through DBW9 and DBWa through DBWj) to improve write
performance for a system that modifies data heavily. The initialization parameter
DB_WRITER_PROCESSES specifies the number of DBWn processes.
Because Oracle uses write-ahead logging, DBWn does not need to write blocks when a
transaction commits. Instead, DBWn is designed to perform batched writes with high efficiency.
In the most common case, DBWn writes only when more data needs to be read into the SGA and
too few database buffers are free. The least recently used data is written to the datafiles first.
DBWn also performs writes for other functions, such as checkpointing.
Log Writer (LGWR)
The log writer writes redo log entries to disk. Redo log entries are generated in the redo log
buffer of the SGA, and LGWR writes the redo log entries sequentially into an online redo log. If
the database has a multiplexed redo log, then LGWR writes the redo log entries to a group of
online redo log files.
Checkpoint (CKPT)
At specific times, all modified database buffers in the SGA are written to the datafiles by
DBWn. This event is called a checkpoint. The checkpoint process is responsible for signaling
DBWn at checkpoints and updating all the datafiles and control files of the database to indicate
the most recent checkpoint.
The system monitor performs recovery when a failed instance starts up again. With Real
Application Clusters, the SMON process of one instance can perform instance recovery for other
instances that have failed. SMON also cleans up temporary segments that are no longer in use
and recovers terminated transactions skipped during recovery because of file-read or offline
errors. These transactions are eventually recovered by SMON when the tablespace or file is
brought back online. SMON also coalesces free extents in the dictionary managed tablespaces to
make free space contiguous and easier to allocate.
The process monitor performs process recovery when a user process fails. PMON is responsible
for cleaning up the cache and freeing resources that the process was using. PMON also checks
on dispatcher and server processes and restarts them if they have failed.
Archiver (ARCn)
The archiver copies the online redo log files to archival storage after a log switch has occurred.
Although a single ARCn process (ARC0) is sufficient for most systems, you can specify up to 10
ARCn processes by using the dynamic initialization parameter LOG_ARCHIVE_MAX_PROCESSES. If
the workload becomes too great for the current number of ARCn processes, then LGWR
automatically starts another ARCn process up to the maximum of 10 processes. ARCn is active
only when a database is in ARCHIVELOG mode and automatic archiving is enabled.
There are two common ways to architect a database: client/server or multitier. As internet
computing becomes more prevalent in computing environments, many database management
systems are moving to a multitier environment.
Client/Server Architecture
Multiprocessing uses more than one processor for a set of related jobs. Distributed processing
reduces the load on a single processor by allowing different processors to concentrate on a subset
of related tasks, thus improving the performance and capabilities of the system as a whole.
An Oracle database system can easily take advantage of distributed processing by using its
client/server architecture. In this architecture, the database system is divided into two parts: a
front-end or a client and a back-end or a server.
The Client
The client is the front-end database application, accessed by a user through the keyboard,
display, and pointing device, such as a mouse. The client has no data access responsibilities. It
requests, processes, and presents data managed by the server. The client workstation can be
optimized for its job. For example, it might not need large disk capacity, or it might benefit from
graphic capabilities.
Often, the client runs on a different computer than the database server, generally on a PC. Many
clients can simultaneously run against one server.
The Server
The server runs Oracle software and handles the functions required for concurrent, shared data
access. The server receives and processes the SQL and PL/SQL statements that originate from
client applications. The computer that manages the server can be optimized for its duties. For
example, it can have large disk capacity and fast processors.
A distributed database is a network of databases managed by multiple database servers that are
used together. They are not usually seen as a single logical database. The data of all databases in
the distributed database can be simultaneously accessed and modified. The primary benefit of a
distributed database is that the data of physically separate databases can be logically combined
and potentially made accessible to all users on a network.
Each computer that manages a database in the distributed database is called a node. The database
to which a user is directly connected is called the local database. Any additional databases
accessed by this user are called remote databases. When a local database accesses a remote
database for information, the local database is a client of the remote server. This is an example of
client/server architecture.
A database link describes a path from one database to another. Database links are implicitly
used when a reference is made to a global object name in a distributed database.
While a distributed database enables increased access to a large amount of data across a network,
it must also hide the location of the data and the complexity of accessing it across the network.
The distributed database management system must also preserve the advantages of
administrating each local database as though it were not distributed.
Oracle supports materialized views that are hierarchical and updatable. Multitier replication
provides increased flexibility of design for a distributed application. Using multitier materialized
views, applications can manage multilevel data subsets with no direct connection between levels.
An updatable materialized view lets you insert, update, and delete rows in the materialized view
and propagate the changes to the target master table. Synchronous and asynchronous replication
is supported.
Multitier Architecture
This section explains the software mechanisms used by Oracle to fulfill the following important
requirements of an information management system:
Oracle includes security features that control how a database is accessed and used. For example,
security mechanisms:
People who administer the operation of an Oracle database system, known as database
administrators (DBAs), are responsible for creating Oracle databases, ensuring their smooth
operation, and monitoring their use.
Enterprise Manager is a system management tool that provides an integrated solution for
centrally managing your heterogeneous environment. Combining a graphical console, Oracle
Management Servers, Oracle Intelligent Agents, common services, and administrative tools,
Enterprise Manager provides a comprehensive systems management platform for managing
Oracle products.
From the client interface, the Enterprise Manager Console, you can perform the following tasks:
Query Analyzer offers a quick and dirty method for performing queries against any
of your SQL Server databases. It's a great way to quickly pull information out of a
database in response to a user request, test queries before implementing them in
other applications, create/modify stored procedures and execute administrative
tasks.
SQL Profiler provides a window into the inner workings of your database. You can
monitor many different event types and observe database performance in real time.
SQL Profiler allows you to capture and replay system "traces" that log various
activities. It's a great tool for optimizing databases with performance issues or
troubleshooting particular problems.
Service Manager is used to control the MSSQLServer (the main SQL Server
process), MSDTC (Microsoft Distributed Transaction Coordinator) and
SQLServerAgent processes. An icon for this service normally resides in the system
tray of machines running SQL Server. You can use Service Manager to start, stop or
pause any one of these services.
Books Online is an often overlooked resource provided with SQL Server that
contains answers to a variety of administrative, development and installation
issues. It's a great resource to consult before turning to the Internet or technical
support.