OCP-1Z0-053-V13.02-631题

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:

OCP-1Z0-053-V13.02-631题_第1张图片

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 copyRMAN: 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 single backup set. When a set is completely restored, RMAN begins reporting progress on the next set to restore.

To monitor RMAN job progress:

  1. Before starting the RMAN job, create a script file (called, for this example, longops) containing the following SQL statement:

    SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK,
           ROUND(SOFAR/TOTALWORK*100,2) "%_COMPLETE"
    FROM   V$SESSION_LONGOPS
    WHERE  OPNAME LIKE 'RMAN%'
    AND    OPNAME NOT LIKE '%aggregate%'
    AND    TOTALWORK != 0
    AND    SOFAR <> TOTALWORK;
  2. Start RMAN and connect to the target database and recovery catalog (if used).

  3. Start an RMAN job. For example, enter:

    RMAN> RESTORE DATABASE;
  4. While the RMAN job is running, start SQL*Plus and connect to the target database, and execute the longops script to check the progress of the RMAN job. If you repeat the query while the RMAN job progresses, then you see output such as the following:

    SQL> @longops
           SID    SERIAL#    CONTEXT      SOFAR  TOTALWORK %_COMPLETE
    ---------- ---------- ---------- ---------- ---------- ----------
             8         19          1      10377      36617      28.34
     
    SQL> @longops
           SID    SERIAL#    CONTEXT      SOFAR  TOTALWORK % COMPLETE
    ---------- ---------- ---------- ---------- ---------- ----------
             8         19          1      21513      36617      58.75
     
    SQL> @longops
           SID    SERIAL#    CONTEXT      SOFAR  TOTALWORK % COMPLETE
    ---------- ---------- ---------- ---------- ---------- ----------
             8         19          1      29641      36617      80.95
     
    SQL> @longops
           SID    SERIAL#    CONTEXT      SOFAR  TOTALWORK % COMPLETE
    ---------- ---------- ---------- ---------- ---------- ----------
             8         19          1      35849      36617       97.9
     
    SQL> @longops
    no rows selected
  5. If you run the longops script at intervals of 2 minutes or more and the %_COMPLETE column does not increase, then RMAN is encountering a problem. See"Monitoring RMAN Interaction with the Media Manager" to obtain more information.

If you frequently monitor the execution of long-running tasks, then you could create a shell script or batch file under your host operating system that runs SQL*Plus to execute this query repeatedly.



FILESPERSET integer Specifies the maximum number of input files to include in each output backup set. This parameter is only relevant when BACKUP generates backup sets.

RMAN backs up the files in each backupSpec as one or more backup sets. When the number of files in eachbackupSpec exceeds the FILESPERSET setting, then RMAN splits the files into multiple backup sets accordingly. The default value for FILESPERSET is 64.

The RMAN behavior is illustrated by the following BACKUP commands:

BACKUP AS BACKUPSET (DATAFILE 3, 4, 5, 6, 7) (DATAFILE 8, 9);
BACKUP AS BACKUPSET DATAFILE 3, 4, 5, 6, 7, 8, 9;
BACKUP AS BACKUPSET DATAFILE 3, ... 72;

In the first command, RMAN places data files 3, 4, 5, 6, and 7 into one backup set and data files 8 and 9 into another backup set. In the second command, RMAN places all data files into one backup set. In the third command, the ellipses indicate data files 3 through 72. Because in this case RMAN is backing up 70 data files, RMAN places 64 files in one backup set and 6 in another.

By default, RMAN divides files among backup sets to make optimal use of channel resources. The number of files to be backed up is divided by the number of channels. If the result is less than 64, then this number is theFILESPERSET value. Otherwise, FILESPERSET defaults to 64.

Note: You cannot specify the number of backup pieces that are in a backup set.


你可能感兴趣的:(OCP-1Z0-053-V13.02-631题)