Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: RMAN FILESPERSET

RE: RMAN FILESPERSET

From: MacGregor, Ian A. <ian_at_SLAC.Stanford.EDU>
Date: Wed, 11 Jun 2003 19:21:05 -0700
Message-ID: <F001.005AFBB9.20030611182942@fatcity.com>


The information matches what was reported while the backup was in progress. Here is the beginning of the log for
The "read write" backup.

channel c1: starting full datafile backupset channel c1: specifying datafile(s) in backupset including current controlfile in backupset

input datafile fno=00122 name=/u9/oradata/NLCO/chanarch_pepii_active_data03.dbf
input datafile fno=00120 name=/u6/oradata/NLCO/chanarch_pepii_active_data01.dbf
input datafile fno=00121 name=/u7/oradata/NLCO/chanarch_pepii_active_data02.dbf
input datafile fno=00001 name=/u3/oradata/NLCO/system01.dbf
input datafile fno=00044 name=/u9/oradata/NLCO/chanarch_dev_data03.dbf
input datafile fno=00160 name=/u9/oradata/NLCO/chanarch_pack_active_data02.dbf
input datafile fno=00006 name=/u9/oradata/NLCO/chanarch_nlc_data01.dbf
input datafile fno=00016 name=/u9/oradata/NLCO/chanarch_pack_data03.dbf
input datafile fno=00146 name=/u9/oradata/NLCO/chanarch_nlc_2003_06_data03.dbf
input datafile fno=00203 name=/u9/oradata/NLCO/chanarch_nlc_2003_05_data03.dbf
input datafile fno=00207 name=/u9/oradata/NLCO/chanarch_PACK_2003_05_data01.dbf
input datafile fno=00228 name=/u9/oradata/NLCO/chanarch_PACK_2003_06_data01.dbf
input datafile fno=00090 name=/u9/oradata/NLCO/chanarch_nlc_active_data01.dbf
input datafile fno=00033 name=/u9/oradata/NLCO/chanarch_nlc_index03.dbf
input datafile fno=00163 name=/u9/oradata/NLCO/chanarch_pack_index02.dbf
input datafile fno=00214 name=/u9/oradata/NLCO/chanarch_PEPII_2003_05_data02.dbf
input datafile fno=00217 name=/u9/oradata/NLCO/chanarch_PEPII_2003_05_data05.dbf
input datafile fno=00220 name=/u9/oradata/NLCO/chanarch_PEPII_2003_05_data08.dbf
input datafile fno=00235 name=/u9/oradata/NLCO/chanarch_PEPII_2003_06_data02.dbf
input datafile fno=00238 name=/u9/oradata/NLCO/chanarch_PEPII_2003_06_data05.dbf
input datafile fno=00241 name=/u9/oradata/NLCO/chanarch_PEPII_2003_06_data08.dbf
input datafile fno=00204 name=/u9/oradata/NLCO/chanarch_nlc_2003_05_index01.dbf
input datafile fno=00211 name=/u9/oradata/NLCO/chanarch_PACK_2003_05_index02.dbf
input datafile fno=00224 name=/u9/oradata/NLCO/chanarch_PEPII_2003_05_index03.dbf
input datafile fno=00225 name=/u9/oradata/NLCO/chanarch_nlc_2003_06_index01.dbf
input datafile fno=00232 name=/u9/oradata/NLCO/chanarch_PACK_2003_06_index02.dbf
input datafile fno=00245 name=/u9/oradata/NLCO/chanarch_PEPII_2003_06_index03.dbf
input datafile fno=00002 name=/u9/oradata/NLCO/nlco_rollback01.dbf
input datafile fno=00005 name=/u9/oradata/NLCO/nlco_rollback04.dbf
input datafile fno=00018 name=/u9/oradata/NLCO/chanarch_pepii_data02.dbf
input datafile fno=00035 name=/u9/oradata/NLCO/chanarch_pepii_index02.dbf
input datafile fno=00200 name=/u9/oradata/NLCO/chanarch_pepii_active_data06.dbf
input datafile fno=00095 name=/u9/oradata/NLCO/arch_version_data.dbf
channel c1: starting piece 1 at 11-JUN-2003:10:21:12
channel c2: starting full datafile backupset channel c2: specifying datafile(s) in backupset input datafile fno=00043 name=/u6/oradata/NLCO/chanarch_dev_data02.dbf input datafile fno=00029 name=/u7/oradata/NLCO/chanarch_dev_data01.dbf channel c2: starting piece 1 at 11-JUN-2003:10:21:12 channel c2: finished piece 1 at 11-JUN-2003:10:29:27 piece handle=df_496405272_30_1 comment=API Version 2.0,MMS Version 2.2.1.0
channel c2: backup set complete, elapsed time: 00:08:15
channel c2: starting full datafile backupset
channel c2: specifying datafile(s) in backupset
input datafile fno=00161 name=/u6/oradata/NLCO/chanarch_pack_active_data03.dbf input datafile fno=00159 name=/u7/oradata/NLCO/chanarch_pack_active_data01.dbf channel c2: starting piece 1 at 11-JUN-2003:10:29:28 channel c1: finished piece 1 at 11-JUN-2003:10:29:53 piece handle=df_496405271_29_1 comment=API Version 2.0,MMS Version 2.2.1.0 channel c1: starting piece 2 at 11-JUN-2003:10:29:53 channel c2: finished piece 1 at 11-JUN-2003:10:37:58 piece handle=df_496405768_31_1 comment=API Version 2.0,MMS Version 2.2.1.0 channel c2: starting piece 2 at 11-JUN-2003:10:37:58 channel c1: finished piece 2 at 11-JUN-2003:10:39:53 piece handle=df_496405271_29_2 comment=API Version 2.0,MMS Version 2.2.1.0 channel c1: starting piece 3 at 11-JUN-2003:10:39:53 channel c2: finished piece 2 at 11-JUN-2003:10:46:08 piece handle=df_496405768_31_2 comment=API Version 2.0,MMS Version 2.2.1.0 channel c2: backup set complete, elapsed time: 00:16:40

You can see that channel 1 grabbed 33 files for the backup set while channel 2 has made 2 backup sets of two
Channels each

As far as how I got the information from the catalog. I just joined rc_backup_set with rc_backup_datafile using db_key and bs_key as the join columns.

-----Original Message-----
Sent: Wednesday, June 11, 2003 6:20 PM
To: Multiple recipients of list ORACLE-L

How did you join to get BS_KEY and FILE# together?

I don't believe the BS_KEY from a "backup database" relate directly to a FILE# from the rc_views.

> I'm a bit confused by the default for filesperset. I ran the
> following

yesterday ....
>
> run
> {
> allocate channel c1 device type sbt format 'df_%t_%s_%p'
maxpiecesize=2048M
> PARMS="SBT_LIBRARY=/opt/oracle/dbserver/9.0.1/lib/libobk.so,
> ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin/tdpo.opt)";
> backup database;
> backup current controlfile;
> release channel c1;
> }
>
> There were 245 datafiles in the database. RMAN made the following
> backup

sets
>
> BS_KEY COUNT(B.FILE#)
> ---------- --------------
> 9623 63
> 9727 64
> 9810 64
> 9892 35
> 9893 4
> 9894 4
> 9895 6
> 9896 5
> --------------
> sum 245
>
>
> As I understand it the default for filesperset is the lesser of 64 or
> the

number of input files / the number of channels.
> As there was only one channel I would have expected 3 backup sets of
> 64

files and one of 53 channels.
>
> Today I ran against the same target database
>
> run
> {
> allocate channel c1 device type sbt format 'df_%t_%s_%p'
maxpiecesize=2048M
> PARMS="SBT_LIBRARY=/opt/oracle/dbserver/9.0.1/lib/libobk.so,
> ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin/tdpo.opt)";
> allocate channel c2 device type sbt format 'df_%t_%s_%p'
maxpiecesize=2048M
> PARMS="SBT_LIBRARY=/opt/oracle/dbserver/9.0.1/lib/libobk.so,
> ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin/tdpo.opt)";
> backup database skip readonly;
> backup current controlfile;
> release channel c1;
> release channel c2;
> }
>
> There are 92 read write datafiles. I would have expected the job to
> be

divided into two backup sets with 46 files each.
>
> Instead I got
>
> BS_KEY COUNT(B.FILE#)
> ---------- --------------
> 10704 2
> 10705 2
> 10721 2
> 10722 2
> 10723 2
> 10724 2
> 10725 2
> 10726 2
> 10727 2
> 10728 2
> 10765 33
> 10766 4
> 10767 2
> 10768 1
> 10769 1
> 10770 1
> 10771 1
> 10772 1
> 10773 1
> 10774 1
> 10775 1
> 10776 1
> 10777 1
> 10778 1
> 10779 1
> 10780 2
> 10781 1
> 10782 18
> --------------
> sum 92
> ----------------------------------------------------------------------
> ----



>
> Any guesses as to why so many backup sets are being created.
>
> Ian MacGregor
> Stanford Linear Accelerator Center
> [EMAIL PROTECTED]
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: MacGregor, Ian A.
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L (or the
> name of mailing list you want to be removed from). You may also send
> the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Binley Lim
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, 
include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be 
removed from).  You may also send the HELP command for other information (like 
subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: MacGregor, Ian A.
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Wed Jun 11 2003 - 21:21:05 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US