Database Reference
In-Depth Information
I/O Slaves
I/O slaves are used to emulate asynchronous I/O for systems or devices that do not support it. For example, tape
devices (which are notoriously slow) do not support asynchronous I/O. By using I/O slaves, we can mimic for tape
drives what the operating system normally provides for disk drives. Just as with true asynchronous I/O, the process
writing to the device batches a large amount of data and hands it off to be written. When the data is successfully
written, the writer (our I/O slave this time,
not
the operating system) signals the original invoker, who removes this
batch of data from its list of data that needs to be written. In this fashion, we can achieve a much higher throughput,
since the I/O slaves are the ones waiting for the slow device, while their caller is off doing other important work getting
the data together for the next write.
I/O slaves are used in a couple of places in Oracle.
DBWn
and
LGWR
can make use of them to simulate asynchronous
I/O, and RMAN will make use of them when writing to tape.
Two parameters control the use of I/O slaves:
BACKUP_TAPE_IO_SLAVES
: This parameter specifies whether I/O slaves are used by RMAN
to back up, copy, or restore data to tape. Since this parameter is designed around
tape
devices, and tape devices may be accessed by only one process at any time, this parameter
is a Boolean, and not the number of slaves to use, as you might expect. RMAN will start up
as many slaves as necessary for the number of physical devices being used. When
BACKUP_
TAPE_IO_SLAVES = TRUE
, an I/O slave process is used to write to or read from a tape device.
If this parameter is
FALSE
(the default), then I/O slaves are not used for backups. Instead, the
dedicated server process engaged in the backup will access the tape device.
•
DBWR_IO_SLAVES
: This parameter specifies the number of I/O slaves used by the
DBW0
process.
The
DBW0
process and its slaves always perform the writing to disk of dirty blocks in the buffer
cache. By default, the value is 0 and I/O slaves are not used. Note that if you set this parameter
to a nonzero value,
LGWR
and
ARCn
will use their own I/O slaves as well, up to four I/O slaves for
LGWR
and
ARCn
will be permitted.
The
DBWn
I/O slaves appear with the name
I1nn
, and the
LGWR
I/O slaves appear with the name
I2nn
.
•
Pnnn: Parallel Query Execution Servers
Oracle 7.1.6 introduced the parallel query capability into the database. This is the capability to take a SQL statement
such as a
SELECT
,
CREATE TABLE
,
CREATE INDEX
,
UPDATE
, and so on and create an execution plan that consists of
many
execution plans that can be done simultaneously. The outputs of each of these plans are merged together into one
larger result. The goal is to do an operation in a fraction of the time it would take if you did it serially. For example,
say you have a really large table spread across ten different files. You have 16 CPUs at your disposal, and you need to
execute an ad hoc query on this table. It might be advantageous to break the query plan into 32 little pieces and really
make use of that machine, as opposed to just using one process to read and process all of that data serially.
When using parallel query, you will see processes named
Pnnn
—these are the parallel query execution servers
themselves. During the processing of a parallel statement, your server process will be known as the
Parallel Query
Coordinator
. Its name won't change at the operating system level, but as you read documentation on parallel query,
when you see references to the coordinator process, know that it is simply your original server process.
Prior to Oracle 12
c
, the default number of parallel execution servers started was zero. You could modify that
behavior by specifying a non-zero value for the
PARALLEL_MIN_SERVERS
parameter. Starting with Oracle 12
c
, your
instance will automatically create several parallel server processes. This occurs because the
PARALLEL_MIN_SERVERS
