9 Process Architecture
001 |
This chapter discusses the processes in an Oracle database system and
the different configurations available for an Oracle system. |
本章讨论 Oracle 数据库系统内的各种进程,以及 Oracle 系统的两种运行模式。 |
002 | This chapter contains the following topics: | 本章包含以下主题: |
003 |
Introduction to Processes |
9.1 进程简介 |
004 |
All connected Oracle users must run two modules of code to access an
Oracle database instance.
|
每个连接到 Oracle 的用户需要运行两个模块才能访问 Oracle 实例。
|
005 |
These code modules are run by processes.
A
process is a "thread
of control" or a mechanism in an operating system that can run a series
of steps. (Some operating systems use the terms job or task.)
A process normally has its own private memory area in which it runs. |
这两种模块都是以进程的形式运行的。进程可以看做是“对一系列操作的控制”或操作系统中
执行一系列操作的机制(在某些操作系统中也被称为
job 或 task)。进程通常运行在其私有的内存区中。 |
006 |
Multiple-Process Oracle Systems |
9.1.1 多进程 Oracle 系统 |
007 |
Multiple-process Oracle (also called multiuser Oracle)
uses several processes to run different parts of the Oracle code and
additional processes for the users—either one process for each connected
user or one or more processes shared by multiple users. Most database
systems are multiuser, because one of the primary benefits of a database
is managing data needed by multiple users at the same time. |
在一个多进程 Oracle 系统(multiple-process Oracle)(也被称为多用户 Oracle 系统(multiuser Oracle))中,存在数个进程分别运行
Oracle
系统的不同模块,以及用户使用的进程——每个用户使用一个进程或多个用户共享一个进程。绝大多数数据库系统都是多用户的,因为数据库系统的独特优势就是能够管理数据以供多个用户同时使用。 |
008 |
Each process in an Oracle instance performs a specific job. By dividing
the work of Oracle and database applications into several processes,
multiple users and applications can connect to a single database
instance simultaneously while the system maintains excellent
performance. |
Oracle 实例中的每种进程都有其独特的任务。通过将 Oracle
系统及数据库应用程序的工作分配给数个进程,多个用户及应用就可以同时连接到同一个数据库实例,且系统仍旧能保证优异的性能。 |
009 |
Types of Processes |
9.1.2 进程的种类 |
010 |
The processes in an Oracle system can be categorized into two major
groups:
|
Oracle 系统中的各种进程可以被分为两大类:
|
011 |
The process structure varies for different Oracle configurations,
depending on the operating system and the choice of Oracle options. The
code for connected users can be configured as a dedicated server or a
shared server. |
从运行 Oracle 的操作系统及 Oracle 安装选项来看,不同配置的 Oracle 系统的进程结构也有所不同。例如,为连接到 Oracle
系统的用户提供服务的模块可以被配置为专用服务器(dedicated server)或共享服务器(shared server)。 |
012 |
With dedicated server, for each user, the database application is run by
a different process (a user process) than the one that runs the Oracle
database server code (a dedicated server process). |
当使用专用服务器时,每个用户执行一个数据库应用时需要两个进程:一个执行此应用的进程(用户进程),一个运行 Oracle
数据库服务模块的进程(专用服务器进程)。 |
013 |
With shared server, the database application is run by a different
process (a user process) than the one that runs the Oracle database
server code. Each server process that runs Oracle database server code
(a shared server process) can serve multiple user processes. |
当使用共享服务器时,每个用户执行一个数据库应用时也需要两个进程:一个执行此应用的进程(用户进程),一个运行 Oracle
数据库服务模块的进程。但与专用服务器模式不同的是,运行 Oracle 数据库服务模块的服务进程(共享服务器进程)可以为多个用户进程提供服务。 |
014 |
Figure 9-1 illustrates a dedicated
server configuration. Each connected user has a separate user process,
and several background processes run Oracle. |
图9-1 显示了一个运行在专用服务器模式下的 Oracle
实例。每个连接到系统的用户拥有一个独立的用户进程,同时系统中还存在多个运行 Oracle 模块的后台进程。 |
015 |
Figure 9-1 An Oracle Instance |
图9-1 一个 Oracle 实例 |
016 | ||
017 |
|
图9-1 中间为 SGA。其上为用户进程,及表示各进程与 SGA 交换数据的双向箭头。其下为 Oracle 进程(后台进程),例如 RECO,PMON,SMON,DBWn,LGWR 和 ARC0。在各 Oracle 进程与 SGA 间也有表示数据交换的双向箭头。 |
018 |
Figure 9-1 can represent multiple
concurrent users running an application on the same computer as Oracle.
This particular configuration usually runs on a mainframe or
minicomputer. |
图9-1 展现了多个并发用户连接到位于同一台计算机上的 Oracle
数据库时的进程结构。这种数据库系统结构常见于大型机(mainframe)或小型机(minicomputer)。 |
019 |
|
|
020 |
Overview of User Processes |
9.2 用户进程概述 |
021 |
When a user runs an application program (such as a Pro*C program) or an
Oracle tool (such as Enterprise Manager or SQL*Plus), Oracle creates a
user process to run the user's application. |
当用户运行一个应用程序(例如 Pro*C 程序)或 Oracle 工具(例如企业管理器或 SQL*Plus)时,Oracle 将创建一个用户进程(user process)来运行用户的应用程序。 |
022 |
Connections and Sessions |
9.2.1 连接与会话 |
023 |
Connection and session are closely related to user
process but are very different in meaning. |
连接(connection)与会话(session)这两个概念均与用户进程(user process)紧密相关,但二者又具有不同的含义。 |
024 |
A connection is a communication pathway between a user process
and an Oracle instance. A communication pathway is established using
available interprocess communication mechanisms (on a computer that runs
both the user process and Oracle) or network software (when different
computers run the database application and Oracle, and communicate
through a network). |
连接是用户进程和 Oracle 实例间的通信通道(communication
pathway)。这个通信通道是通过进程间的通信机制(interprocess communication
mechanisms)(在同一个计算机上运行用户进程和 Oracle 进程)或网络软件(network software)(当数据库应用程序与
Oracle 服务器运行在不同的计算机上时,就需要通过网络来通信)建立的。 |
025 |
A session is a specific connection of a user to an Oracle
instance through a user process. For example, when a user starts
SQL*Plus, the user must provide a valid user name and password, and then
a session is established for that user. A session lasts from the time
the user connects until the time the user disconnects or exits the
database application. |
会话是用户通过用户进程与 Oracle 实例建立的连接[此处连接与上文中的连接含义不同
,主要指用户和数据库间的联系]。例如,当用户启动
SQL*Plus 时必须提供有效的用户名和密码,之后 Oracle
为此用户建立一个会话。从用户开始连接到用户断开连接(或退出数据库应用程序)期间,会话一直持续。 |
026 |
Multiple sessions can be created and exist concurrently for a single
Oracle user using the same user name. For example, a user with the user
name/password of SCOTT/TIGER can connect to
the same Oracle instance several times. |
Oracle 数据库中的同一个用户可以同时创建多个会话。例如,用户名/密码为的 SCOTT/TIGER
用户可以多次连接到同一个 Oracle 实例。 |
027 |
In configurations without the shared server, Oracle creates a server
process on behalf of each user session. However, with the shared server,
many user sessions can share a single server process. |
当系统没有运行在共享服务模式下时,Oracle 为每个用户会话创建一个服务进程(server
process)。而当系统运行在共享服务模式下时,多个用户会话可以共享同一个服务进程。 |
028 |
|
另见: |
029 |
Overview of Oracle Processes |
9.3 Oracle 进程概述 |
030 |
This section describes the two types of processes that run the
Oracle database server code (server processes and background
processes). It also describes the trace files and alert logs, which
record database events for the Oracle processes. |
本节描述两种运行 Oracle 数据库服务器模块的进程(服务进程(server process)和后台进程(background
process))。本节还将讲述为 Oracle 进程记录数据库事件的跟踪文件(trace file)及告警日志(alert log)。 |
031 |
Server Processes |
9.3.1 服务进程 |
032 |
Oracle creates server processes to handle the requests of user
processes connected to the instance. In some situations when the
application and Oracle operate on the same computer, it is possible to
combine the user process and corresponding server process into a single
process to reduce system overhead. However, when the application and
Oracle operate on different computers, a user process always
communicates with Oracle through a separate server process. |
Oracle 需要创建服务进程(server process)来处理连接到实例的用户进程(user
process)提交的请求。当应用程序与 Oracle
服务器运行在同一计算机时,某些用户进程可以和其服务进程合并为一个进程,以便减小系统开销。但是,当应用程序与 Oracle
服务器运行在不同计算机时,用户进程必须通过一个服务进程与 Oracle 通信。 |
033 |
Server processes (or the server portion of combined user/server
processes) created on behalf of each user's application can perform one
or more of the following:
|
为用户应用程序创建的服务进程(或用户/服务进程合并后的服务进程部分)可以完成以下工作:
|
034 |
Background Processes |
9.3.2 后台进程 |
035 |
To maximize performance and accommodate many users, a multiprocess
Oracle system uses some additional Oracle processes called background
processes. |
为了实现为多用户提供服务且保证系统性能,在一个多进程 Oracle 系统(multiprocess Oracle
system)中,存在多个被称为后台进程(background process)的 Oracle 进程。 |
036 | An Oracle instance can have many background processes; not all are always present. There are numerous background processes. See the V$BGPROCESS view for more information on the background processes. The background processes in an Oracle instance can include the following: | 一个 Oracle 实例中可以包含多种后台进程,这些进程不一定全部出现在实例中。系统中运行的后台进程数量众多,用户可以通过 V$BGPROCESS 视图查询关于后台进程的信息。Oracle 实例中可能运行的后台进程有: |
037 |
On many operating systems, background processes are created
automatically when an instance is started. |
在许多操作系统中,后台进程在实例启动时能够被自动地创建。 |
038 |
Figure 9-2 illustrates how each background process interacts with the
different parts of an Oracle database, and the rest of this section
describes each process. |
图9-2 显示了后台进程如何与 Oracle
数据库的各部分交互,后续各节将讲述这些后台进程。 |
039 |
|
|
040 |
Figure 9-2 Background
Processes of a Multiple-Process Oracle Instance |
图9-2 多进程 Oracle 实例中的后台进程 |
041 | ||
042 |
|
图9-2 中间为 SGA。上部为 RECO,PMON,及 SMON 进程,其间的双向箭头表示各进程与实例间的通信。下部左侧为 DBW0 和 LGWR 进程,这两个进程分别和数据缓存区与重做日志缓冲区进行通信,同时还分别访问数据文件和重做日志文件。 |
043 |
Database Writer Process (DBWn) |
9.3.2.1 数据写入进程(DBWn) |
044 |
The database writer process (DBWn) writes the contents of buffers
to datafiles. The DBWn processes are responsible for writing modified
(dirty) buffers in the database buffer cache to disk. Although one
database writer process (DBW0) is adequate for most systems, you can
configure additional processes (DBW1 through DBW9 and DBWa through DBWj)
to improve write performance if your system modifies data heavily. These
additional DBWn processes are not useful on uniprocessor systems. |
数据写入进程(database writer process,DBWn)的功能是将数据缓冲区的内容写入数据文件。DBWn
进程负责将数据缓存区(database buffer cache)内修改过的缓冲区(即 dirty
buffer)写入磁盘。对于大多数数据库系统来说,使用一个数据写入进程(DBW0)就足够了。当系统中数据修改操作较频繁时,DBA
可以配置额外的数据写入进程(DBW1 到 DBW9 及 DBWa 到 DBWj)来提高数据写入的性能。在单处理器系统(uniprocessor
system)中,额外的数据写入进程并不能提高系统性能。 |
045 |
When a buffer in the database buffer cache is modified, it is marked
dirty. A cold buffer is a buffer that has not been recently
used according to the least recently used (LRU) algorithm. The DBWn
process writes cold, dirty buffers to disk so that user processes are
able to find cold, clean buffers that can be used to read new blocks
into the cache. As buffers are dirtied by user processes, the number of
free buffers diminishes. If the number of free buffers drops too low,
user processes that must read blocks from disk into the cache are not
able to find free buffers. DBWn manages the buffer cache so that user
processes can always find free buffers. |
当数据缓存区内的某个缓冲区被修改过之后,将被标记为脏缓冲区(dirty)。而死缓冲区(cold buffer)指根据
LRU 算法选出的最近最少被使用的缓冲区。DBWn 进程将最近最少使用的脏缓冲区(cold, dirty
buffer)写入磁盘,使用户进程(user process)能够找到最近最少使用的可用缓冲区(cold, clean
buffer)用于将新数据块写入缓存区。当某个缓冲区的内容被用户进程修改后,则此缓冲区将不能再用于写入新数据。如果数据缓存区内的可用缓冲区的数量过少,用户进程就无法找到足够的空间写入新的数据块。DBWn
进程能够有效地管理数据缓存区,保证用户进程总能获得可用的缓冲区。 |
046 |
By writing cold, dirty buffers to disk, DBWn improves the performance of
finding free buffers while keeping recently used buffers resident in
memory. For example, blocks that are part of frequently accessed small
tables or indexes are kept in the cache so that they do not need to be
read in again from disk. The LRU algorithm keeps more frequently
accessed blocks in the buffer cache so that when a buffer is written to
disk, it is unlikely to contain data that will be useful soon. |
DBWn
进程总是将最近最少使用的脏缓冲区写入磁盘,这既减少了用户进程找到可用缓冲区的时间,同时令最近使用较频繁的缓冲区能够保留在内存中。例如,存储访问频率较高的小数据表或索引的数据块能够被保留在内存中,而无需反复地从磁盘中读取。由于
LRU 算法能够将访问频率较高的数据块保留在数据缓存区内,因此一个缓冲区被写入磁盘后,其中所包含的数据被马上使用的可能性较小。 |
047 |
The initialization parameter
DB_WRITER_PROCESSES specifies the number of DBWn processes.
The maximum number of DBWn processes is 20. If it is not specified
by the user during startup, Oracle determines how to set
DB_WRITER_PROCESSES based on the number
of CPUs and processor groups. |
初始化参数
DB_WRITER_PROCESSES 用于设定系统中 DBWn 进程的数量。此参数的最大值为
20。如果实例启动时用户没有设定此参数,Oracle 将根据 CPU 及 处理器组(processor group)的数量决定如何设置
DB_WRITER_PROCESSES 参数。 |
048 |
The DBWn process writes dirty buffers to disk under the following
conditions:
|
当满足以下条件时,DBWn 进程会将脏缓冲区写入磁盘:
|
049 |
In all cases, DBWn performs batched (multiblock) writes to improve
efficiency. The number of blocks written in a multiblock write varies by
operating system. |
无论上述那种情况,DBWn 进程都将进行批量(多数据块)写入以便提高性能。一次批量写入的数据块数量依操作系统而不同。 |
050 |
|
|
051 |
Log Writer Process (LGWR) |
9.3.2.2 日志写入进程(LGWR) |
052 |
The log writer process (LGWR) is responsible for redo log buffer
management—writing the redo log buffer to a redo log file on disk. LGWR
writes all redo entries that have been copied into the buffer since the
last time it wrote. |
日志写入进程(log writer process,LGWR)负责对重做日志进行管理——将重做日志缓冲区(redo log
buffer)内的数据写入磁盘上的重做日志文件中。LGWR 进程将上次写入之后进入缓冲区的所有重做条目(redo entry)写入磁盘中。 |
053 |
The redo log buffer is a circular buffer. When LGWR writes redo entries
from the redo log buffer to a redo log file, server processes can then
copy new entries over the entries in the redo log buffer that have been
written to disk. LGWR normally writes fast enough to ensure that space
is always available in the buffer for new entries, even when access to
the redo log is heavy. |
重做日志缓冲区是一个循环使用的缓冲区(circular buffer)。当 LGWR
进程将重做条目从重做日志缓冲区写入重做日志文件后,服务进程(server
process)就可以用新产生的重做条目覆盖重做日志缓冲区内已写入磁盘的条目。即便重做日志数量巨大,LGWR
进程通常也能保证迅速地向磁盘写入重做条目,确保缓冲区内有足够的可用空间用于写入新条目。 |
054 |
LGWR writes one contiguous portion of the buffer to disk. LGWR writes:
|
LGWR 进程每次将重做日志缓冲区中的一组连续的缓冲区写入磁盘。LGWR 进程写入的内容有:
|
055 |
Note: |
提示: |
056 |
LGWR writes synchronously to the active mirrored group of redo log
files. If one of the files in the group is damaged or unavailable, LGWR
continues writing to other files in the group and logs an error in the
LGWR trace file and in the system alert log. If all files in a group are
damaged, or the group is unavailable because it has not been archived,
LGWR cannot continue to function. |
LGWR 进程将同步地向当前活动的重做日志文件镜像组(active mirrored group of redo log
files)写入数据。如果镜像组内的某个文件被损坏或不可用,LGWR 进程将继续向组内的其他文件写入数据,并在 LGWR
进程的跟踪文件(trace file)及系统的告警日志(alert
log)内记录一条错误信息。如果镜像组内的所有文件均被损坏,或镜像组因为未归档而不可用,LGWR 进程将无法继续工作。 |
057 |
When a user issues a
COMMIT statement, LGWR
puts a commit record in the redo log buffer and writes it to disk
immediately, along with the transaction's redo entries. The
corresponding changes to data blocks are deferred until it is more
efficient to write them. This is called a fast commit mechanism.
The atomic write of the redo entry containing the transaction's commit
record is the single event that determines the transaction has
committed. Oracle returns a success code to the committing transaction,
although the data buffers have not yet been written to disk. |
当用户执行 COMMIT
语句时,LGWR
进程在重做日志缓冲区内存储一条提交记录,并将此记录与所提交事务的重做条目立即写入磁盘。而此事务对数据库的修改将等到最高效的时机才被写入磁盘。这被称为快速提交(fast commit)机制。一个事务的提交记录及相关的重做条目将通过一个原子性(atomic)的写操作记录到磁盘上,这个单一事件决定了事务是否被成功地提交。尽管此时被修改的数据缓冲区还没有写入磁盘,Oracle
已经能够向用户返回事务提交成功的信息。 |
058 |
Note: |
提示: |
059 |
When a user commits a transaction, the transaction is assigned a
system change number (SCN), which Oracle records along with the
transaction's redo entries in the redo log.
SCNs are recorded in the
redo log so that recovery operations can be synchronized in Real
Application Clusters and distributed databases. |
当用户提交一个事务时,此事务将被赋予一个系统变化编号(system change number,SCN),Oracle
将在事务的重做条目中记录此编号。通过重做日志中记录的 SCN,RAC 及分布式数据库的恢复操作才能够同步进行。 |
060 |
In times of high activity, LGWR can write to the redo log file using
group commits. For example, assume that a user commits a
transaction. LGWR must write the transaction's redo entries to disk, and
as this happens, other users issue COMMIT
statements. However, LGWR cannot write to the redo log file to commit
these transactions until it has completed its previous write operation.
After the first transaction's entries are written to the redo log file,
the entire list of redo entries of waiting transactions (not yet
committed) can be written to disk in one operation, requiring less I/O
than do transaction entries handled individually. Therefore, Oracle
minimizes disk I/O and maximizes performance of LGWR. If requests to
commit continue at a high rate, then every write (by LGWR) from the redo
log buffer can contain multiple commit records. |
在数据修改操作较频繁时,LGWR 进程能够采取批量提交(group commits)技术向重做日志文件写入数据。例如,当一个用户提交了一个事务后,LGWR
进程会将此事务的重做条目(redo entry)写入磁盘,与此同时系统中的其他用户也可能在执行
COMMIT 语句。但是 LGWR
进程需要在之前的写入操作完成后,才能为后续的提交事务写入重做信息。当第一个事务的重做条目被写入磁盘后,在此期间等待提交的事物的重做条目可以被一起写入磁盘,这比分别写入每个事务的重做条目所需的
I/O 操作要少。Oracle 通过这种办法减少了磁盘 I/O 并提升了 LGWR 进程的性能。如果系统中的提交频率一直很高,那么 LGWR
进程每次从重做日志缓冲区向磁盘的写入数据中都包含多个提交事务的信息。 |
061 |
|
|
062 |
Checkpoint Process (CKPT) |
9.3.2.3 检查点进程(CKPT) |
063 |
When a checkpoint occurs, Oracle must update the headers of all
datafiles to record the details of the checkpoint. This is done by the
CKPT process. The CKPT process does not write blocks to disk; DBWn
always performs that work. |
当一个检查点(checkpoint)事件发生时,Oracle 需要更新所有数据文件的文件头来记录检查点事件的详细信息。这个工作是由 CKPT
进程完成的。但是将数据块写入数据文件的不是 CKPT 进程,而是 DBWn 进程。 |
064 |
The statistic
DBWR checkpoints displayed by the
System_Statistics monitor in Enterprise
Manager indicates the number of checkpoint requests completed. |
由企业管理器(Enterprise Manager)的
System_Statistics 监视器显示的 DBWR checkpoints
统计信息显示了系统中需要完成的检查点操作。 |
065 |
See Also: |
另见: |
066 |
System Monitor Process (SMON) |
9.3.2.4 系统监控进程(SMON) |
067 |
The system monitor process (SMON) performs recovery, if
necessary, at instance startup. SMON is also responsible for cleaning up
temporary segments that are no longer in use and for coalescing
contiguous free extents within dictionary managed tablespaces. If any
terminated transactions were skipped during instance recovery because of
file-read or offline errors, SMON recovers them when the tablespace or
file is brought back online. SMON checks regularly to see whether it is
needed. Other processes can call SMON if they detect a need for it. |
实例启动时如有需要,系统监控进程(system monitor
process,SMON)将负责进行恢复(recovery)工作。此外,SMON 还负责清除系统中不再使用的临时段(temporary
segment),以及为数据字典管理的表空间(dictionary managed
tablespace)合并相邻的可用数据扩展(extent)。在实例恢复过程中,如果由于文件读取错误或所需文件处于脱机状态而导致某些异常终止的事务未被恢复,SMON
将在表空间或文件恢复联机状态后再次恢复这些事务。SMON 将定期地检查系统中是否存在问题。系统内的其他进程需要服务时也能够调用 SMON 进程。 |
068 |
With Real Application Clusters, the SMON process of one instance can
perform instance recovery for a failed CPU or instance. |
在 RAC 环境中,一个实例的 SMON 进程能够为出错的
CPU 或 实例进行实例恢复(instance recovery)。 |
069 |
See Also: |
另见: |
070 |
Process Monitor Process (PMON) |
9.3.2.5 进程监控进程(PMON) |
071 |
The process monitor (PMON) performs process recovery when a user
process fails. PMON is responsible for cleaning up the database buffer
cache and freeing resources that the user process was using. For
example, it resets the status of the active transaction table, releases
locks, and removes the process ID from the list of active processes. |
当一个用户进程(user process)失败后,进程监控进程(process monitor,PMON)将对其进行恢复。PMON
进程将清除相关的数据缓存区(database buffer cache)并释放被此用户进程使用的资源。例如,PMON
进程将重置活动事务表(active transaction table),释放锁,并从活动进程列表(list of active
process)中删除出错进程的 ID。 |
072 |
PMON periodically checks the status of
dispatcher and server processes,
and restarts any that have stopped running (but not any that Oracle has
terminated intentionally). PMON also registers information about the
instance and dispatcher processes with the network listener. |
PMON 进程会周期性地对调度器(dispatcher)和服务进程(server process)进行检查,重新启动停止运行的进程(不包括
Oracle 有意停止的进程)。PMON 进程还负责将实例和调度器进程的信息注册到网络监听器(network listener)。 |
073 |
Like SMON, PMON checks regularly to see whether it is needed and can be
called if another process detects the need for it. |
同 SMON 进程一样,PMON 进程也会定期地检查系统中是否有问题需要处理,当系统内的其他进程需要服务是也能够调用 PMON 进程。 |
074 |
Recoverer Process (RECO) |
9.3.2.6 恢复进程(RECO) |
075 |
The recoverer process (RECO) is a background process used
with the distributed database configuration that automatically
resolves failures involving distributed transactions. The RECO
process of a node automatically connects to other databases involved
in an in-doubt distributed transaction. When the RECO process
reestablishes a connection between involved database servers, it
automatically resolves all in-doubt transactions, removing from each
database's pending transaction table any rows that correspond to the
resolved in-doubt transactions. |
恢复进程(recoverer process,RECO)是在分布式数据库环境(distributed database
configuration)中自动地解决分布式事务(distributed transaction)错误的后台进程。一个节点(node)上的
RECO 进程能够连接到出现了不可信的分布式事务(in-doubt distributed transaction)的数据库。当 RECO
进程重新连接到与不可信的事务相关的数据库后,她将负责对此事务进行处理,并从相关数据库的活动事务表(pending transaction
table)中移除和此事务有关的数据。 |
076 |
If the RECO process fails to connect with a remote server, RECO
automatically tries to connect again after a timed interval. However,
RECO waits an increasing amount of time (growing exponentially) before
it attempts another connection. The RECO process is present only if the
instance permits distributed transactions. The number of concurrent
distributed transactions is not limited. |
如果 REC0
进程无法连接到远程数据库,她将在一定时间间隔后尝试再次连接。每次重新连接间的时间间隔会以指数级的方式增长。只有实例允许分布式事务时才会启动
REC0 进程。实例中不会限制并发的分布式事务的数量。 |
077 |
See Also: |
另见: |
078 |
Job Queue Processes |
9.3.2.7 作业队列进程 |
079 |
Job queue processes are used for batch processing. They run user jobs.
They can be viewed as a scheduler service that can be used to schedule
jobs as PL/SQL statements or procedures on an Oracle instance. Given a
start date and an interval, the job queue processes try to run the job
at the next occurrence of the interval. |
作业队列进程(job queue process)的功能是进行批处理(batch
processing)。这种进程用于运行用户的作业(job)。这种进程能够提供作业调度服务(scheduler service),在
Oracle 实例中调度 PL/SQL 语句及存储过程。用户只需提供作业的开始时间及调度间隔,作业队列进程就能够按用户的设定调度作业。 |
080 |
Job queue processes are managed dynamically. This allows job queue
clients to use more job queue processes when required.
The resources
used by the new processes are released when they are idle. |
作业队列进程可以被动态地管理。这样当用户需要时就能够使用更多的作业队列进程。当一个作业队列进程进入空闲状态(idle)后,其使用的资源将被释放。 |
081 |
Dynamic job queue processes can run a large number of jobs concurrently
at a given interval. The job queue processes run user jobs as they are
assigned by the CJQ process. Here's what happens:
|
动态的作业队列进程可以按指定的时间间隔运行大量的作业。用户的作业是由 CJQ 进程交给作业队列进程执行的。具体步骤如下:
|
082 |
The initialization parameter JOB_QUEUE_PROCESSES
represents the maximum number of job queue processes that can
concurrently run on an instance. However, clients should not assume that
all job queue processes are available for job execution. |
初始化参数 JOB_QUEUE_PROCESSES
表示实例中可以并行执行的最大作业队列进程数。但是并不是所有的作业队列进程都可以用于执行用户的作业。 |
083 |
Note: |
提示: |
084 |
See Also: |
另见: |
085 |
Archiver Processes (ARCn) |
9.3.2.8 归档进程(ARCn) |
086 |
The archiver process (ARCn) copies redo log files to a designated
storage device after a log switch has occurred. ARCn processes are
present only when the database is in ARCHIVELOG
mode, and automatic archiving is enabled. |
归档进程(archiver process,ARCn)在发生日志切换(log
switch)时将重做日志文件复制到指定的存储设备中。只有当数据库运行在 ARCHIVELOG
模式下,且自动归档功能被开启时,系统才会启动 ARCn 进程。 |
087 |
An Oracle instance can have up to 10 ARCn processes (ARC0 to ARC9). The
LGWR process starts a new ARCn process whenever the current number of
ARCn processes is insufficient to handle the workload. The alert log
keeps a record of when LGWR starts a new ARCn process. |
一个 Oracle 实例中最多可以运行 10 个 ARCn 进程(ARC0 到 ARC9)。如果当前所有的 ARCn
进程还不能满足工作负载的需要,LGWR 进程将启动新的 ARCn 进程。当 LGWR 进程启动新的 ARCn 进程时,告警日志(alert
log)会进行记录。 |
088 |
If you anticipate a heavy workload for archiving, such as during bulk
loading of data, you can specify multiple archiver processes with the
initialization parameter LOG_ARCHIVE_MAX_PROCESSES.
The ALTER SYSTEM statement can change the
value of this parameter dynamically to increase or decrease the number
of ARCn processes. However, you do not need to change this parameter
from its default value of 1, because the system determines how many ARCn
processes are needed, and LGWR automatically starts up more ARCn
processes when the database workload requires more. |
如果 DBA 预计系统中归档的工作负载将提升,例如将进行大量的数据加载(bulk loading of data),则应通过初始化参数 LOG_ARCHIVE_MAX_PROCESSES
设置多个归档进程。ALTER SYSTEM
语句能够修改此参数值,并动态地增加或减少归档进程的数量。实际上用户无需修改此参数的值(默认为1),因为系统能够自动地决定需要多少个 ARCn
进程,且当数据库负载增大时,LGWR 进程能够自动地启动新的 ARCn 进程。 |
089 |
|
|
090 |
Queue Monitor Processes (QMNn) |
9.3.2.9 队列监控进程(QMNn) |
091 |
The queue monitor process is an optional background process for
Oracle Streams Advanced Queuing, which monitors the message queues. You
can configure up to 10 queue monitor processes. These processes, like
the job queue processes, are different from other Oracle background
processes in that process failure does not cause the instance to fail. |
队列监控进程(queue monitor process)是供 Oracle 工作流高级队列(Oracle Streams
Advanced Queuing)使用的可选的进程,用于监控消息队列。队列监控进程和作业队列进程(job queue process)与其他
Oracle 后台进程的区别在于,这两类进程出错不会导致整个实例出错。 |
092 |
|
|
093 |
Other Background Processes |
9.3.2.10 其他后台进程 |
094 |
There are several other background processes that might be running.
These can include the following: |
Oracle 数据库中还可能运行其他后台进程。包括: |
095 |
MMON performs various manageability-related background tasks, for
example:
|
MMON 进程负责执行多种和可管理性相关(manageability-related)的后台任务,例如:
|
096 |
MMNL performs frequent and light-weight manageability-related tasks,
such as session history capture and metrics computation. |
MMNL 进程负责执行轻量级的且频率较高的和可管理性相关的后台任务,例如捕获会话历史信息,测量值计算等。 |
097 |
MMAN is used for internal database tasks. |
MMAN 进程负责执行数据库系统的内部任务。 |
098 |
RBAL coordinates rebalance activity for disk groups in an Automatic
Storage Management instance. It performs a global open on Automatic
Storage Management disks.ORBn performs the actual rebalance data extent
movements in an Automatic Storage Management instance. There can be many
of these at a time, called ORB0, ORB1, and so forth. |
在使用了自动存储管理(Automatic Storage Management)的实例中,RBAL
进程负责协调磁盘组间的负载平衡工作。她可以使多个实例同时访问一个 ASM 磁盘(global open)。最终由 ORBn
进程实际执行数据扩展的负载均衡。实例中可以运行多个 ORBn 进程,分别为 ORB0,ORB1,以此类推。 |
099 |
OSMB is present in a database instance using an Automatic Storage
Management disk group. It communicates with the Automatic Storage
Management instance. |
当数据库实例使用 ASM 磁盘组时,还要启动 OSMB
进程。此进程负责和 ASM 实例(Automatic Storage Management instance)通信。 |
100 |
Trace Files and the Alert Log |
9.3.3 跟踪文件与告警日志 |
101 |
Each server and background process can write to an associated trace
file. When a process detects an internal error, it dumps information
about the error to its trace file. If an internal error occurs and
information is written to a trace file, the administrator should contact
Oracle Support Services. |
每个服务进程(server process)和后台进程(background process)都可以向自己的跟踪文件(trace
file)写入信息。当一个进程检查到内部错误时,能够将错误信息写入跟踪文件,DBA 可以向 Oracle 支持服务(Oracle Support
Services)提交此信息。 |
102 |
All filenames of trace files associated with a background process
contain the name of the process that generated the trace file. The one
exception to this is trace files generated by job queue processes
(Jnnn). |
跟踪文件的文件名中包含产生此文件的进程的名称。但作业队列进程(job queue processes,Jnnn)产生的跟踪文件名例外。 |
103 |
Additional information in trace files can provide guidance for tuning
applications or an instance. Background processes always write this
information to a trace file when appropriate. |
跟踪文件中的附加信息还可以为应用程序及实例的调优提供指导。后台进程经常在适当时机向跟踪文件写入此类信息。 |
104 |
Each database also has an alert.log. The
alert log of a database is a chronological log of messages and errors,
including the following:
|
每个数据库中还有一个告警日志(alert log)文件 alert.log。告警日志按时间顺序记录数据库中的消息和错误,主要包括以下内容:
|
105 |
Oracle uses the alert log to keep a record of these events as an
alternative to displaying the information on an operator's console.
(Many systems also display this information on the console.) If an
administrative operation is successful, a message is written in the
alert log as "completed" along with a time stamp. |
Oracle 使用告警日志来记录上述事件,这些内容和操作员控制台(operator's
console)显示的信息类似。(在很多系统中控制台也会显示告警日志中的信息。)如果一项管理性操作成功执行,那么 Oracle
将在告警日志中记录一条“完成”消息及当时的时间戳(time stamp)。 |
106 |
|
|
107 |
Shared Server Architecture |
9.4 共享服务器体系结构 |
108 |
Shared server architecture eliminates the need for a dedicated
server process for each connection. A dispatcher directs multiple
incoming network session requests to a pool of shared server processes.
An idle shared server process from a shared pool of server processes
picks up a request from a common queue, which means a small number of
shared servers can perform the same amount of processing as many
dedicated servers. Also, because the amount of memory required for each
user is relatively small, less memory and process management are
required, and more users can be supported. |
系统采用共享服务器(shared
server)体系结构后,就可以避免为每个用户连接(connection)都建立专用服务进程(dedicated server
process)。调度器(dispatcher)能够将众多网络会话请求提交给共享服务进程池(pool of shared server
process)。池内的空闲共享进程可以为在队列(common
queue)中等待的请求提供服务,与使用专用服务进程相比,少量的共享服务进程(shared server
process)就能完成同样的处理工作。此外,由于进程数减少,平均每个用户连接所使用的内存也会减少,这减轻了系统中内存和进程管理的开销,使系统能够为更多用户服务。 |
109 |
A number of different processes are needed in a shared server system:
|
在共享服务体系结构(shared server architecture)中,需要多种进程配合工作:
|
110 |
Shared server processes require Oracle Net Services or SQL*Net version
2. |
共享服务进程需要使用 Oracle Net Services 或 SQL*Net 的第二版。 |
111 |
Note: |
提示: |
112 |
When an instance starts, the network listener process opens and
establishes a communication pathway through which users connect to
Oracle. Then, each dispatcher process gives the listener process an
address at which the dispatcher listens for connection requests. At
least one dispatcher process must be configured and started for each
network protocol that the database clients will use. |
在实例启动后,网络监听进程建立并打开一条通信通道,供用户连接 Oracle
只用。之后,每个调度进程向监听进程提交其用于等待用户连接请求的地址。对于每种数据库客户端可能使用的网络协议(network
protocol),至少需要配置并启动一个调度进程。 |
113 |
When a user process makes a connection request, the listener examines
the request and determines whether the user process can use a shared
server process. If so, the listener returns the address of the
dispatcher process that has the lightest load, and the user process
connects to the dispatcher directly. |
当一个用户进程发起连接请求时,监听器将检查此请求,并确定用户进程是否能使用共享服务进程。如果可以,监听器将为用户进程返回当前工作负载最轻的调度进程的地址,用户进程就能够直接连接到调度器上。 |
114 |
Some user processes cannot communicate with the dispatcher, so the
network listener process cannot connect them to a dispatcher. In this
case, or if the user process requests a dedicated server, the listener
creates a dedicated server and establishes an appropriate connection. |
有些用户进程不能和调度器通信,此时网络监听器不能将其和调度器连接。在上述情况下,或者在用户进程请求一个专用服务器时,监听器将创建一个专用服务器,并为用户进程建立连接。 |
115 |
Oracle's shared server architecture increases the scalability of
applications and the number of clients simultaneously connected to the
database. It can enable existing applications to scale up without making
any changes to the application itself. |
Oracle
的共享服务体系结构提高了应用的可伸缩性(scalability)及并发连接到数据库的客户端数量。她能够提高已存在的应用程序的服务规模,而无需对应用程序进行任何修改。 |
116 |
|
|
117 |
Dispatcher Request and Response Queues |
9.4.1 调度器的请求队列与响应队列 |
118 |
A request from a user is a single program interface call that is part of
the user's SQL statement. When a user makes a call, its dispatcher
places the request on the request queue, where it is picked up by
the next available shared server process. |
用户执行 SQL 语句时对数据库的请求(request)实际上就是一次程序接口调用(program interface
call)。当用户发起调用时,为其服务的调度器(dispatcher)会将请求放入请求队列(request queue)中,等待空闲的共享服务进程(shared
server process)将其取出。 |
119 |
The request queue is in the SGA and is common to all dispatcher
processes of an instance. The shared server processes check the common
request queue for new requests, picking up new requests on a
first-in-first-out basis. One shared server process picks up one request
in the queue and makes all necessary calls to the database to complete
that request. |
请求队列位于 SGA
中,她对于实例内的所有调度器是公用的。共享服务进程会检测请求队列中是否存在新请求,如存在则按照先进先出(first-in-first-out)的原则取出。每个共享服务进程每次从请求队列中取出一个用户请求,并调用数据库功能完成此请求。 |
120 |
When the server completes the request, it places the response on the
calling dispatcher's response queue. Each dispatcher has its own
response queue in the SGA. The dispatcher then returns the completed
request to the appropriate user process. |
当服务器完成了用户请求后,将在提交请求的调度器的响应队列(response queue)中放入响应信息。每个调度器在 SGA
中有自己的响应队列。这时调度器就可以将处理完成的请求返回给相应的用户。 |
121 |
For example, in an order entry system each clerk's user process connects
to a dispatcher and each request made by the clerk is sent to that
dispatcher, which places the request in the request queue. The next
available shared server process picks up the request, services it, and
puts the response in the response queue. When a clerk's request is
completed, the clerk remains connected to the dispatcher, but the shared
server process that processed the request is released and available for
other requests. While one clerk is talking to a customer, another clerk
can use the same shared server process. |
例如,在一个订单系统中(order entry
system),每个营业员的用户进程都连接到一个调度器,营业员的请求将发送到其连接的调度器,这个调度器负责将用户请求放入请求队列。下一个可用的共享服务进程将取出一个用户请求,为其服务,并将
响应结果放入响应队列。当某个营业员的请求处理完毕后,此营业员的用户进程依然和调度器保持连接,但是刚才为此营业员服务的共享服务进程已经被释放,并可以为下一个用户请求服务。当一个营业员暂时不使用数据库时(例如在和客户谈话),其他营业员可以使用同一个共享服务进程。 |
122 |
Figure 9-3 illustrates how user
processes communicate with the dispatcher across the program interface
and how the dispatcher communicates users' requests to shared server
processes. |
图9-3
显示了用户进程如何通过程序接口与调度器通信,及调度器如何与共享服务进程通信以处理用户请求。 |
123 |
Figure 9-3 The Shared Server
Configuration and Processes |
图9-3 共享服务器模式及相关的进程 |
124 | ||
125 |
Figure 9-3 shows a user process at the top, sending a dispatcher process to the database. The dispatcher process sends it along to the request queue in the SGA, which sends it to the Oracle Database, which sends it to the response queue, which sends it back to the dispatcher process, which then sends it back to the user. |
图9-3 的顶部为用户进程,向数据库的调度进程提交请求。调度进程又将此请求放入 SGA 的请求队列中,服务进程对请求进行处理后,将响应结果放入调度进程的响应队列,调度进程再将此结果返回给用户。 |
126 |
Dispatcher Processes (Dnnn) |
9.4.1.1 调度进程(Dnnn) |
127 |
The dispatcher processes support shared server configuration by
allowing user processes to share a limited number of server processes.
With the shared server, fewer shared server processes are required for
the same number of users, Therefore, the shared server can support a
greater number of users, particularly in client/server environments
where the client application and server operate on different computers. |
在共享服务模式下(shared server configuration),较少数量的服务进程(server process)在调度进程(dispatcher
process)的配合下就可以为多个用户进程(user
process)服务。与使用专用服务进程相比,较少的共享进程就可以为同样多的用户服务,因此共享服务模式下的系统能够支持更大数量的用户,这种特性非常符合客户端应用程序与服务器运行在不同计算机上的
C/S 系统(client/server environment)的要求。 |
128 |
You can create multiple dispatcher processes for a single database
instance. At least one dispatcher must be created for each network
protocol used with Oracle. The database administrator starts an optimal
number of dispatcher processes depending on the operating system
limitation and the number of connections for each process, and can add
and remove dispatcher processes while the instance runs. |
DBA 可以为一个数据库实例创建多个调度进程。Oracle 所使用的每种网络协议都至少需要一个调度进程。DBA
应依据操作系统的限制以及每个调度进程服务的用户连接数来决定调度进程的数量,并可以在实例运行时动态地添加或减少调度进程。 |
129 |
Note: |
提示: |
130 |
In a shared server configuration, a network listener process waits for
connection requests from client applications and routes each to a
dispatcher process. If it cannot connect a client application to a
dispatcher, the listener process starts a dedicated server process, and
connects the client application to the dedicated server. The listener
process is not part of an Oracle instance; rather, it is part of the
networking processes that work with Oracle. |
在共享服务模式下,网络监听进程(network listener
process)等待来自客户端应用程序的连接请求,并将其传递给调度进程。如果客户端应用程序无法连接到调度器,监听进程将启动一个专用服务进程(dedicated
server process),并为客户端应用程序与此进程建立连接。监听进程不属于 Oracle 实例,她是配合 Oracle
系统工作的网络组件之一。 |
131 |
|
|
132 |
Shared Server Processes (Snnn) |
9.4.1.2 共享服务进程(Snnn) |
133 |
Each shared server process serves multiple client requests in the
shared server configuration. Shared server processes and dedicated
server processes provide the same functionality, except shared server
processes are not associated with a specific user process. Instead, a
shared server process serves any client request in the shared server
configuration. |
在共享服务模式(shared server
configuration)下,每个共享服务进程(shared server process)能够为多个用户请求提供服务。共享服务进程与专用服务进程(dedicated
server process)的功能相同,不同之处在于后者只为一个与之相关的用户进程(user
process)提供服务。而共享服务进程可以为共享服务模式下的任何用户请求提供服务。 |
134 |
The PGA of a shared server process does not contain user-related data
(which needs to be accessible to all shared server processes).
The PGA
of a shared server process contains only stack space and
process-specific variables. |
共享服务进程的 PGA 中不存储和用户相关的信息[此处指的是 session memory](这些信息应该允许所有共享服务进程访问)。共享服务进程的
PGA 中只包含栈空间(stack space)和属于此进程的变量(process-specific variable)。 |
135 |
All session-related information is contained in the SGA. Each shared
server process needs to be able to access all sessions' data spaces so
that any server can handle requests from any session. Space is allocated
in the SGA for each session's data space. You can limit the amount of
space that a session can allocate by setting the resource limit
PRIVATE_SGA to the desired amount of space
in the user's profile. |
所有和会话相关的信息存储在 SGA 中。共享服务进程必须能够访问系统中所有会话的数据区(data
space),这样才能为任意会话的请求提供服务。Oracle 会在 SGA 为每个会话分配数据区。DBA
可以在用户档案(profile)中设置资源限制(resource limit)参数
PRIVATE_SGA,使为每个会话分配的数据区容量处于合理范围。 |
136 |
Oracle dynamically adjusts the number of shared server processes based
on the length of the request queue. The number of shared server
processes that can be created ranges between the values of the
initialization parameters SHARED_SERVERS
and MAX_SHARED_SERVERS. |
系统中共享服务进程的数量被限制在初始化参数 SHARED_SERVERS
和 MAX_SHARED_SERVERS 之间。Oracle
能够依据请求队列(request queue)的长度在此范围内动态地调整共享服务进程的数量。 |
137 |
|
|
138 |
Restricted Operations of the Shared Server |
9.4.2 共享服务模式下被限制的数据库操作 |
139 |
Certain administrative activities cannot be performed while
connected to a dispatcher process, including shutting down or
starting an instance and media recovery. An error message is issued
if you attempt to perform these activities while connected to a
dispatcher process. |
如果用户进程连接的是调度进程,则不能执行某些管理性操作,例如启动、关闭实例及介质恢复(media
recovery)等。连接到调度进程的用户提交此类命令时将得到错误信息。 |
140 |
These activities are typically performed when connected with
administrator privileges. When you want to connect with
administrator privileges in a system configured with shared servers,
you must state in your connect string that you want to use a
dedicated server process (SERVER=DEDICATED) instead of a dispatcher
process. |
上述管理性操作通常需要以管理员权限连接才能执行。如果一个系统被配置为共享服务模式,但用户希望进行管理性操作时,用户需要在连接字符串(connect
string)中加入 (SERVER=DEDICATED)
来指明连接到专用服务进程(dedicated server process)而非共享服务进程。 |
141 |
|
|
142 |
Dedicated Server Configuration |
9.5 专用服务器模式 |
143 |
Figure 9-4 illustrates Oracle
running on two computers using the dedicated server architecture. In
this configuration, a user process runs the database application on one
computer, and a server process runs the associated Oracle database
server on another computer. |
图9-4 显示了在专用服务模式(Dedicated Server
Configuration)下运行 Oracle 的两台计算机。在这种模式下,用户进程(user
process)在一台计算机上运行数据库应用程序,服务进程(server process)在另一台计算机上实现 Oracle 数据库服务功能。 |
144 |
Figure 9-4 Oracle Using
Dedicated Server Processes |
图9-4 使用专用服务模式的 Oracle 系统 |
145 | ||
146 |
The user and server processes are separate, distinct processes. The
separate server process created on behalf of each user process is called
a dedicated server process (or shadow process), because
this server process acts only on behalf of the associated user process. |
用户和服务为两个独立的进程。专为每个用户进程建立的服务进程被称为专用服务进程(dedicated server process)(或称为附属进程(shadow
process)),因为这样的服务进程总是在为与之相关的用户进程工作。 |
147 |
This configuration maintains a one-to-one ratio between the number of
user processes and server processes. Even when the user is not actively
making a database request, the dedicated server process remains (though
it is inactive and can be paged out on some operating systems). |
在专用服务模式下,用户进程与服务进程总是保持一对一的关系。即使在用户没有提交数据库请求时,专用服务进程依然保持运行状态(在有些操作系统中暂时不工作的专用服务进程可能被置为暂停状态(inactive
)并被交换出内存(page out))。 |
148 |
Figure 9-4 shows user and server
processes running on separate computers connected across a network.
However, the dedicated server architecture is also used if the same
computer runs both the client application and the Oracle database server
code but the host operating system could not maintain the separation of
the two programs if they were run in a single process. UNIX is a common
example of such an operating system. |
图9-4
显示了运行在不同计算机上的用户进程和服务进程通过网络进行连接。当客户端应用程序与 Oracle
服务器模块运行在同一计算机上时也能够使用专用服务模式,但是有些操作系统可能将用户进程与服务进程合并为一个进程。在 UNIX 操作系统下就是如此。 |
149 |
In the dedicated server configuration, the user and server processes
communicate using different mechanisms:
|
在专用服务模式下,用户进程与服务进程能够采用多种机制进行通信:
|
150 |
|
|
151 |
The Program Interface |
9.6 程序接口 |
152 |
The program interface is the software layer between a database
application and Oracle. The program interface:
|
程序接口(program interface)是数据库服务器与数据库应用程序之间的软件层(software
layer)。程序接口的作用是:
|
153 |
The Oracle code acts as a server, performing database tasks on
behalf of an application (a client), such as fetching rows from
data blocks. It consists of several parts, provided by both Oracle
software and operating system-specific software. |
Oracle服务端代码(Oracle code)提供服务,为应用程序(客户端)执行数据库操作,例如从数据块中获取数据行。Oracle
代码由多部分组成,其中包括 Oracle 软件及操作系统相关软件。 |
154 |
Program Interface Structure |
9.6.1 程序接口的构成 |
155 |
The program interface consists of the following pieces:
|
程序接口由以下内容构成:
|
156 |
Both the user and Oracle sides of the program interface run Oracle
software, as do the drivers. |
客户端及 Oracle 服务端的程序接口都需要使用 Oracle 软件及驱动程序。 |
157 |
Oracle Net Services is the portion of the program interface that allows
the client application program and the Oracle database server to reside
on separate computers in your communication network. |
客户端应用程序及 Oracle 数据库服务器利用 Oracle 网络服务(Oracle Net
Services)提供的程序接口,就能够在不同计算机上通过网络进行联系。 |
158 |
Program Interface Drivers |
9.6.2 程序接口驱动程序 |
159 |
Drivers are pieces of software that transport data, usually
across a network. They perform operations such as connect, disconnect,
signal errors, and test for errors. Drivers are specific to a
communications protocol, and there is always a default driver. |
驱动程序(driver)是用于(跨网络)传输数据的软件。她们负责进行连接,断开连接,检测错误,提示错误等操作。每种通信协议都必须使用专用的驱动程序,Oracle
还会指定一个连接时使用的默认驱动程序。 |
160 |
You can install multiple drivers (such as the asynchronous or DECnet
drivers) and select one as the default driver, but allow an individual
user to use other drivers by specifying the desired driver at the time
of connection. Different processes can use different drivers. A single
process can have concurrent connections to a single database or to
multiple databases (either local or remote) using different Oracle Net
Services drivers. |
管理员可以安装多种驱动程序(例如异步(asynchronous)驱动(asynchronous)或 DECnet
驱动),并选择一种作为默认的驱动,而每个用户在连接时也可以特别指定需要使用的驱动程序。系统中不同的进程可以使用不同的驱动程序。一个进程还可以使用不同的驱动程序连接到一个或多个数据库(本地或远程)。 |
161 |
|
|
162 |
Communications Software for the Operating System |
9.6.3 操作系统使用的通信软件 |
163 |
The lowest-level software connecting the user side to the Oracle side of
the program interface is the communications software, which is provided
by the host operating system. DECnet, TCP/IP, LU6.2, and ASYNC are
examples. The communication software can be supplied by Oracle, but it
is usually purchased separately from the hardware vendor or a
third-party software supplier. |
在用于连接客户端与 Oracle 服务器的所有编程接口中,处于最底层的软件为通信软件(communications
software),由操作系统提供。例如 DECnet,TCP/IP,LU6.2,及 ASYNC。Oracle
也能够提供通信软件,但通常通信软件都是从硬件厂商或第三方软件商处购买的。 |
164 |
See Also: |
另见: |
[041] dispatcher/scheduler 的区别 |
[045] cold buffer [072] dispatcher [134] stack space |
[005] A process is a "thread of
control" or a mechanism in an operating system that can run a series of
steps. [036] not all are always present. [048] DBWn writes dirty buffers to disk asynchronously while performing other processing. [080] The resources used by the new processes are released when they are idle. [105] (Many systems also display this information on the console.) [112] When an instance starts, the network listener process opens and establishes a communication pathway through which users connect to Oracle. Then, each dispatcher process gives the listener process an address at which the dispatcher listens for connection requests. [118] A request from a user is a single program interface call that is part of the user's SQL statement. [156] Both the user and Oracle sides of the program interface run Oracle software, as do the drivers. |
[025] [134] |
[137] Database Security |
1、周期性地写入也是针对 dirty buffer 么? [048] DBWn periodically writes buffers to advance the checkpoint 2、LGWR 进程向磁盘写入的时机? [054] When a DBWn process writes modified buffers to disk, if necessary [057] When a user issues a COMMIT statement, LGWR puts a commit record in the redo log buffer and writes it to disk immediately, along with the transaction's redo entries. 3、SCN 的用处?SCN 在 RAC 中的用处? [059] SCNs are recorded in the redo log so that recovery operations can be synchronized in Real Application Clusters and distributed databases. 4、检查点事件作了什么? [063] When a checkpoint occurs, Oracle must update the headers of all datafiles to record the details of the checkpoint. 5、在哪个界面查询? [064] The statistic DBWR checkpoints displayed by the System_Statistics monitor in Enterprise Manager indicates the number of checkpoint requests completed. 6、哪些进程需要调用 SMON,什么情况下需要调用? [067] SMON checks regularly to see whether it is needed. Other processes can call SMON if they detect a need for it. 7、一个实例的 SMON 进程可以为整个 RAC 进行恢复? [068] With Real Application Clusters, the SMON process of one instance can perform instance recovery for a failed CPU or instance. 8、CJQ process 是什么 [081] CJQ process 9、按什么时间排序? [081] New jobs selected are ordered by time. 10、为什么?因为有些系统工作也在用 job? [082] However, clients should not assume that all job queue processes are available for job execution. 11、什么的 snapshot? [095] Taking snapshots by spawning additional process (MMON slaves) 12、需要详细了解 [099] OSMB is present in a database instance using an Automatic Storage Management disk group. It communicates with the Automatic Storage Management instance. 13、什么队列? [108] common queue 14、stack space 指什么?process-specific variables 指什么? [134] The PGA of a shared server process contains only stack space and process-specific variables. 15、operating system-specific software 指什么? [153] It consists of several parts, provided by both Oracle software and operating system-specific software. 16、OCI 和 SQLLIB 是什么关系? [155] Oracle call interface (OCI) or the Oracle runtime library (SQLLIB) |