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