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