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: Thu, 12 Jun 2003 11:11:56 -0700
Message-ID: <F001.005B06D6.20030612105458@fatcity.com> 





It appears truncated because it is only the top of the log.  I so indicated that by 
specifying  that only the beginning of the log was being posted.  All files do show up 
in the complete log.  I don't presently have files larger than 2GB.  The old backup 
system would not handle them.  I will however need to do so soon.  I expect in a month 
the database will be adding 60,000,000 + rows daily.  MAXPIECESIZE does not effect the 
size of the backup set, just the size of the piece.



I have not tried an explicit FILESPERSET yet.  It almost looks like  RMAN is trying to 
avoid two channels from reading off the same logical device simultaneously.




The information on page 327 of "Oracle9i RMAN Backup and Recovery"  to wit, "Using the 
restore comand with validate and or check logical only checks the most current backup 
set", appears to be incorrect.  "restore database validate;"   At the very least 
checks all the backup sets involved in the "backup database" command.  I believe it 
also checks other backup sets required for the restore as well.  But I have not 
confirmed that.



Ian  



-----Original Message-----


Sent: Thursday, June 12, 2003 9:30 AM


To: Multiple recipients of list ORACLE-L




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






> 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).
-- 
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 Thu Jun 12 2003 - 13:11:56 CDT












Original text of this message













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