Databases Reference
In-Depth Information
When you start an RMAN backup job, two target database server processes are initially created: the first
default server process and a polling process. The polling process can be ignored. The first default server process is
responsible for querying the target database control file (for RMAN metadata) and running any SQL statements issued
from within RMAN. If you're using a recovery catalog, an additional process is started on the recovery catalog server.
This process handles the communication between the RMAN client and recovery catalog (RMAN metadata).
Additionally, another server process is started for each channel that is allocated. These channel processes are
responsible for reading blocks from data files on disk, placing these blocks into a memory area, and then writing these
blocks to the backup pieces (either on disk or on tape).
Having said that, when you experience RMAN backup performance problems, we recommend you start by
investigating these architectural components:
•
RMAN reading metadata from the target database control file
•
RMAN reading metadata from the recovery catalog (if using)
•
SQL statements issued from RMAN client
•
Reading data file blocks from disk into memory
•
Writing blocks from memory to the backup location (either disk or tape)
Basically anywhere in Figure
16-1
where there is a data flow related to “metadata,” “blocks,” or “SQL” is where
you'll most likely experience RMAN performance issues. This is where you should initially focus your tuning efforts.
Most of the recipes in this chapter are in some way related to the prior bullets.
When first tuning RMAN, you should identify the extent of performance problems (see Recipes 16-1 through
16-3). Next determine whether the bottleneck is related to querying the RMAN repository metadata (Recipes 16-4 and
16-5). If the bottleneck is not related to querying the repository, you must figure out whether the issue is caused by
reading the data files or writing to the backups (Recipes 16-6 through 16-9). The remaining recipes in this chapter deal
with increasing RMAN performance, such as implementing parallelism, using incremental features, and so on.
■
See My Oracle Support (MOS) note 247611.1 for known rMan performance issues. this note lists issues, fixes,
and workarounds for several performance problems.
Tip
Identifying RMAN Processes
Problem
An RMAN backup job is running too long. You would like to identify the database sessions and operating system
processes associated with any RMAN jobs.
Solution
The following query will provide you a wealth of information regarding RMAN processes currently connected to your
target database:
COL username FORM a10
COL kill_string FORM A12
COL os_id FORM A6
COL client_info FORM A24
COL action FORM A21
