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.

----- Original Message -----
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
Sent: Thursday, June 12, 2003 10:25 AM


> 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).

Reply via email to