Re: RMAN FILESPERSET

Hmm, puzzling indeed.

For starters, your output log appear truncated. I would have expected a "resync catalog" somewhere at the end. You could try "resync catalog" manually and try again.

Second, all datafiles should be listed in the output. This listing contains only 33+2*2 out of 92. Any clues from just looking at the datafiles not listed? Note TEMPFILEs are automatically excluded. Does specifying explicitly FILESPERSET obey instructions?

I am unclear what effect MAXPIECESIZE has on this. Do you have > 2GB datafiles? Regardless, all candidate datafiles should appear in the output.

It is always possible that all those scientific experiments conducted around the place introduce a 3-dimensional causal-effect on the neutronic, anti-gravitational pull on the inner workings of the simple, humble, RMAN. ;-)

• Original Message ----- To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Sent: Thursday, June 12, 2003 2:29 PM

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