ANBOB™

A few days ago a friend ask me to see a awr issue.

In the TOP 5 Times Events, as you see, Obviously,database has relatively high sbtbackup wait event, Backup:sbtbackup falls under the administrative category also realted to the RMAN. These wait events will occur when there is RMAN backup running on the server.

Backup: sbtbackup
Meaning: Wait situations during RMAN backup. The wait events that begin with “Backup: sbt” are associated with wait situations during a RMAN backup. This means they only affect the backup runtime.

other events related to Backup: sbtbackup 、imm op、sbtwrite2 、IO Done

imm op
Meaning: Waiting for an IMMEDIATE I/O request to a slave process to end.The event “imm op” may occur if I/O slaves are used,
that is, if parameters such as DBWR_IO_SLAVES or BACKUP_TAPE_IO_SLAVES are used.

BACKUP_TAPE_IO_SLAVES is set to TRUE in the case of a RMAN backup if dedicated I/O slave processes are to copy backup write processes to tape and not the Oracle shadow processes. In this case, “imm op” waits only affect the backup runtime, but not the live system.

How to RMAN Performance Tuning Diagnostics?
1. RMAN debug output
2. Channel debug=5 trace=1 or 5 output trace files.
3. STATSPACK reports
4. If the CPU and slow sql (rather than IO) is the issue, the 10046 trace
and tkprof.
5. The resulting trace can be used with tkprof to get the explain plan
6. Collecting data from v$backup_async_io
7. Backup to tape is slow

One has to be careful with these events especially during the peak time, they should not be in the TOP 5. If they are found in the peak time, one has to look at scheduling the backup during the non peak time and also these will occur when RMAN is backing up the database directly to the TAPE instead to a disk. As backup is a heavy DISK and CPU intensive job, it has to be done during the non peak time only.

打赏

微信扫一扫，打赏作者吧～