While backing up to the Oracle Fast Recovery Area (FRA), you determined the backup is taking too long and suspect a performance bottleneck. Which three are true about diagnosing and tuning these problems? (Choose three.)
A.
If an RMAN BACKUP VALIDATE command takes roughly the same time as an actual backup, then both read and write I/O are likely bottlenecks.
B.
Setting DBWR_IO_SLAVES to a non zero value can improve backup performance when using synchronous I/O.
C.
If an RMAN BACKUP VALIDATE command takes noticeably less than an actual backup, then write I/O is a likely bottleneck.
D.
If an RMAN BACKUP VALIDATE command takes roughly the same time as an actual backup, then read I/O is a likely bottleneck.
E.
Data files with a high value in V$BACKUP_SYNC_IO.DISCRETE_BYTES_PER_SECOND are a potential performance bottleneck when synchronous I/O is used.
F.
Setting DBWR_IO_SLAVES to a non zero value can improve backup performance when using asynchronous I/O/
G.
Data files with a high value in V$BACKUP_ASYNC_IO.SHORT_WAITS are a potential performance bottleneck when asynchronous I/O is used.
Answer: B,C,D
One reliable way to determine whether the output device or input disk I/O is the bottleneck in a given backup job is to compare the time required to run backup tasks with the time required to run BACKUP VALIDATE of the same tasks. BACKUP VALIDATE of a backup performs the same disk reads as a real backup but performs no I/O to an output device.
D -> If the time for the BACKUP VALIDATE to tape is about the same as the time for a real backup to tape, then reading from disk is the likely bottleneck.
C -> If the time for the BACKUP VALIDATE to tape is significantly less than the time for a real backup to tape, then writing to the output device is the likely bottleneck.
B -> Some operating systems support native asynchronous I/O. If and only if your disk does not support asynchronous I/O, then set DBWR_IO_SLAVES. Any nonzero value for DBWR_IO_SLAVES causes a fixed number of disk I/O slaves to be used for backup and restore, which simulates asynchronous I/O.
G -> incorrect - The simplest way to identify the bottleneck is to find the data file that has the largest ratio for LONG_WAITS divided by IO_COUNT
B,C,E
E , as per https://docs.oracle.com/en/database/oracle/oracle-database/18/bradv/tuning-rman-performance.html#GUID-5D8AAB8F-8A63-4B82-9BFB-16D22CE439FD
Yo mate, your link indicated that E is incorrect instead. The sentence of E is "Data files with a high value in V$BACKUP_SYNC_IO.DISCRETE_BYTES_PER_SECOND are a potential performance bottleneck when synchronous I/O is used". So, a high value means a high throughput with large number of bytes being transferred per second. Besides, the doc ask you to compare the transfer rate with the specified value with the device specification. Say the device support up to 1GB per second but the DISCRETE_BYTES_PER_SECOND is much lower then this value, then there is an issue.
BCD
DBWR_IO_SLAVES is used for asynchronous I/O.
High value of V$BACKUP_SYNC_IO.DISCRETE_BYTES_PER_SECOND is good.
https://docs.oracle.com/cd/B12037_01/server.101/b10755/dynviews_1033.htm
High value in V$BACKUP_ASYNC_IO.SHORT_WAITS is good.
Short waits are the number of times the backup or restore process made an operating system call to poll for I/O completion in a nonblocking mode.
https://docs.oracle.com/cd/E18283_01/backup.112/e10642/rcmtunin.htm
Student GUide
SET DBWR_IO_SLAVES if you use synchronous disk I/. if your disk does not support asnychronous I/O, try setting DBWR_IO_SLAVES initilization parameter to a nonzero value. any nonzero value for DBWR_IO_SLAVES causes fized number of 4 of disk I/O slaves to be used for backup and restore, simulating ASYNC IO
if backup validate time is less than the actual backup time, buffer copy or write to storage is the likely bottlneck
if BACKUP validate time ~= actual backup time, the read phase is the likely bottleneck.
so what do u think but ill go with B,C,D
E is wrong:
Determining Bottlenecks with Synchronous I/O
With synchronous I/O, it is difficult to identify specific bottlenecks because all synchronous I/O is a bottleneck to the process. The only way to tune synchronous I/O is to compare the bytes-per-second rate with the device's maximum throughput rate. If the bytes-per-second rate is lower than that device specifies, consider tuning that part of the backup/restore process. Use the V$BACKUP_SYNC_IO.DISCRETE_BYTES_PER_SECOND column to see the I/O rate.
Source: https://www.csee.umbc.edu/portal/help/oracle8/server.815/a67775/ch20_io.htm
B
Set DBWR_IO_SLAVES if you use synchronous disk I/O. If your disk does not support
asynchronous I/O, then try setting the DBWR_IO_SLAVES initialization parameter to a nonzero
value
C
Issue a backup validate command to provide the time required to read data files. Compare the time that command
takes to execute to the time it takes to perform a regular backup. The difference will give you the time RMAN is
spending on writing.
E
Query the DISCRETE_BYTES_PER_SECOND column from V$BACKUP_SYNC_IO to view the I/O rate
Corrects are BCE.
It is B correct as:
If you set DBWR_IO_SLAVES to a nonzero value,............. the number of I/O server processes used by Recovery Manager is set to 4 only if asynchronous I/O is disabled (either your platform does not support asynchronous I/O or disk_asynch_io is set to false).
https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/DBWR_IO_SLAVES.html#GUID-D8A04F0F-0D5A-4B28-895E-8F63BD3B7DC9
So, when DBWR_IO_SLAVES is set to a nonzero value, RMAN is set to 4 only if configuration is synchronous I/O.
If the time for the BACKUP VALIDATE to tape is about the same as the time for a real backup to tape, then reading from disk is the likely bottleneck. See "Tuning the Read Phase".
If the time for the BACKUP VALIDATE to tape is significantly less than the time for a real backup to tape, then writing to the output device is the likely bottleneck. See "Tuning the Copy and Write Phases".
https://docs.oracle.com/cd/E28271_01/backup.1111/e10642/rcmtunin.htm
C&D correct
B & F can't be both right, f is incorrect, as the number of I/O processes is set to 4 only if asynch io is disabled, so only in the case of synch io, it can help ==> b correct, f incorrect
Sorry: CEF is correct
With synchronous I/O, it is difficult to identify specific bottlenecks because all synchronous I/O is a bottleneck to the process. The only way to tune synchronous I/O is to compare the rate (in bytes/second) with the device's maximum throughput rate. If the rate is lower than the rate that the device specifies, then consider tuning this aspect of the backup and restore process.
To determine the rate of synchronous I/O:
Start SQL*Plus and connect to the target database.
Query the DISCRETE_BYTES_PER_SECOND column in the V$BACKUP_SYNC_IO view to display the I/O rate.
If you see data in V$BACKUP_SYNC_IO, then the problem is that you have not enabled asynchronous I/O or you are not using disk I/O slaves.
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
ssseee
Highly Voted 2 years, 1 month agokameni
Highly Voted 1 year, 10 months agoScottL
Most Recent 2 months, 1 week ago_gio_
2 months, 2 weeks agovkra
5 months agoAldrid
2 years, 1 month agowiprooracle
2 years, 1 month agoPortlandFighters
1 year, 9 months agoManojx
2 years, 1 month agoasefa
2 years, 5 months agoSchmeili
2 years, 7 months agoundoundo
2 years, 8 months agobugzbinny
2 years, 8 months agoproact
2 years, 9 months agoChansi
2 years, 10 months agojanw
2 years, 11 months agojanw
2 years, 11 months agoCyborgQ
2 years, 11 months ago