Database Reference
In-Depth Information
In the output from this example, it appears that the overall time for the RMAN backup
in question is about 188 seconds (the
aggregate input
figure is the one to use here). Keep
in mind that these figures are just for the individual backup operation that is currently run-
ning. The output is not cumulative for the entire
BACKUP
command.
For example, if you executed a backup using a command like
BACKUP AS COMPRESSED
BACKUPSET DATABASE PLUS ARCHIVELOG DELETE INPUT
, the output displayed would be only
for the database backup or the archived redo-log backup. Keep in mind that the
BACKUP
DATABASE PLUS ARCHIVELOG
command can show a series of backups. These would include
two individual archive-log backups, the database backup, and then the control-file auto-
backup. Each of these operations will appear in the
V$SESSION_LONGOPS
view differently.
Notice in the previous example that
OPNAME
is displayed as full data file backup. The value
for
OPNAME
would be different for different stages in the RMAN backup operation.
Tuning RMAN: it's the little Things That Count
In the real world, tuning RMAN can make a huge difference. RMAN works fine as it is out
of the box, but very often there is a lot you can do to make things run faster. Sometimes
even the smallest things can make a huge difference. One place where one of us worked
had limited tape drives for performing backups.
The problem was that individual DBAs were scheduling their backups for each of their
individual databases and there wasn't a lot of coordination of schedules going on. We
started getting complaints because backups were taking a long time.
It turned out that everyone was hitting the tape drives at the same time. The tape drives
would be working a specific backup, and all the other backups would sit and wait for a
tape device to become available. Once we worked out a reasonable schedule, the back-
ups started working better and everyone was much happier!
Using the
V$SESSION
and
V$SESSION_WAIT_HISTORY
Views
to Troubleshoot RMAN Problems
Trouble. We hate trouble. Sometimes you get into problems with RMAN and are not sure
what the trouble is. The
V$SESSION
and
V$SESSION_WAIT
views can be a big help in your
troubleshooting efforts. These views can help identify the cause of RMAN processes that are
not running as fast as you would like. In this example, we have an RMAN backup running,
and rather slowly at that. We query the
V$SESSION
view to determine the total number of waits
that the session has experienced and the wait event that the session is currently experiencing:
SQL> Select sid, serial#, event, seconds_in_wait
2 From v$session
Search WWH ::
Custom Search