631.View the Exhibit and examine the output of the query in different times when the following command runs in an RMAN sessions:
RMAN> BACKUP DATABASE FILESPERSET 2;
The database has seven data files. Why is the %_COMPLETE refreshed to 13.59 in the third output after reaching 88.77
Exhibit:
A. Because the progress is reported for each data file
B. Because the progress is reported for each backup set
C. Because other RMAN sessions have issued the same BACKUP command
D. Because new data files have been added to the database while the RMAN backup is in progress
Answer: B
答案解析：
参考：http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmtunin.htm#BRADV89862
Monitoring RMAN Job Progress with V$SESSION_LONGOPS
You can monitor the progress of backups and restore jobs by querying the view V$SESSION_LONGOPS. RMAN uses two types of rows in V$SESSION_LONGOPS: detail rows and aggregate rows.
Detail rows describe the files being processed by one job step, whereas aggregate rows describe the files processed by all job steps in an RMAN command. A job step is the creation or restoration of one backup set or data file copy. Detail rows are updated with every buffer that is read or written during the backup step, so their granularity of update is small. Aggregate rows are updated when each job step completes, so their granularity of update is large.
Table 22-2 describes the columns in V$SESSION_LONGOPS that are most relevant for RMAN. Typically, you view the detail rows rather than the aggregate rows to determine the progress of each backup set.
Table 22-2 Columns of V$SESSION_LONGOPS Relevant for RMAN
| Column |
Description for Detail Rows |
| SID |
The server session ID corresponding to an RMAN channel |
| SERIAL# |
The server session serial number. This value changes each time a server session is reused. |
| OPNAME |
A text description of the row. Examples of details rows include RMAN: datafile copy, RMAN: full datafile backup, and RMAN: fulldatafile restore. Note: RMAN: aggregate input and RMAN: aggregate output are the only aggregate rows. |
| CONTEXT |
For backup output rows, this value is 2. For all other rows except proxy copy (which does not update this column), the value is 1. |
| SOFAR |
The meaning of this column depends on the type of operation described by this row: For image copies, the number of blocks that have been read For backup input rows, the number of blocks that have been read from the files being backed up For backup output rows, the number of blocks that have been written to the backup piece For restores, the number of blocks that have been processed to the files that are being restored in this one job step For proxy copies, the number of files that have been copied |
| TOTALWORK |
The meaning of this column depends on the type of operation described by this row: For image copies, the total number of blocks in the file. For backup input rows, the total number of blocks to be read from all files processed in this job step. For backup output rows, the value is 0 because RMAN does not know how many blocks that it will write into any backup piece. For restores, the total number of blocks in all files restored in this job step. For proxy copies, the total number of files to be copied in this job step. |
Each server session performing a backup or restore job reports its progress compared to the total work required for a job step. For example, if you restore the database with two channels, and each channel has two backup sets to restore (a total of four sets), then each server session reports its progress through a