Unix Technical Forum

Rac Backups....

This is a discussion on Rac Backups.... within the Oracle Database forums, part of the Database Server Software category; --> Hi all, My thanks in advance for Reading and any posts. We currently have a Rac Database which runs ...


Go Back   Unix Technical Forum > Database Server Software > Oracle Database

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 02-25-2008, 06:44 AM
B14
 
Posts: n/a
Default Rac Backups....

Hi all,

My thanks in advance for Reading and any posts.

We currently have a Rac Database which runs on Linux Redhat Ent 3 with
Oracle 9i database on it. It is backed up by a Solaris 8 x86 box with
Netbackup 5.1 and 2 tape drives. It is all connect via a 100mb
standard line which is set up for full duplex on both ends.

The database is about 500 - 600 gigs in size. Currently we do a full
level 0 backup of the database daily. The tapes get changed on a
Tuesday and a Friday, unfortunately the box is in America (Las Vegas)
and I am in the UK, so it would be quite difficult (but not totally
impossible) for us to run an incremental backup strategy of some sort.
The backup takes about 14 hours to run.

The current script that we are using looks like this:

DATE=`date +%m%d%Y-%H%M%S`; export DATE
USER=`id | cut -f2 -d"(" | cut -f1 -d")"`
ORACLE_SID=[sid]; export ORACLE_SID
ORACLE_USER=[user]; export ORACLE_USER
ORACLE_HOME=[path] export ORACLE_HOME

#delete log files older than 35 days
find /var/adm/netbackup -name "auslive*" -mtime +35 -type f -exec rm {}
\;

#if [ "${USER}" = "root" ]
#then
# su - ${ORACLE_USER} "cd /rac/DBA/scripts/BACKUP/" #-c
"${CMD_STRING}"
# SUCCESS=$?
#else
# eval "/rac/DBA/scripts/BACKUP"
# SUCCESS=$?
#fi

<<EOF su - [user]
<<EOF1 /u01/oracle/product/9.2.0/bin/rman msglog
/var/adm/netbackup/AUSLIVE_b
ackup.${DATE} append


connect target [user]/[pass]@box
connect catalog [user]/[pass]@box
#change archivelog all validate;
run {

allocate channel ch1 type sbt_tape
PARMS="BLKSIZE=1048576";
allocate channel ch2 type sbt_tape
PARMS="BLKSIZE=1048576";
#allocate channel ch3 type sbt_tape;
CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
CONFIGURE CHANNEL 1 DEVICE TYPE 'SBT_TAPE' MAXPIECESIZE
100000m
CONNECT = '[user]/[pass]@box';
CONFIGURE CHANNEL 2 DEVICE TYPE 'SBT_TAPE' MAXPIECESIZE
100000m
CONNECT = '[user]/[pass]@box';
#CONFIGURE CHANNEL 3 DEVICE TYPE 'SBT_TAPE' CONNECT =
'[user]/[pass]@box';
change archivelog all validate;
send "NB_ORA_CLASS=[policy]";
#send "NB_ORA_CLIENT=[client]";
send "NB_ORA_CLIENT={client]";
send "NB_ORA_SCHED=full";
backup
incremental level=0
filesperset 150
format "bk_%s_%p_%t"
tag "hot_${ORACLE_SID}_${DATE}"
database;
sql "alter system archive log current";
backup
filesperset 10
format "ct_%s_%p_%t"
current controlfile;
sql "alter system archive log current";
backup
filesperset 150
format "al_%s_%p_%t"
archivelog all not backed up 2 times;
backup
filesperset 50
format "al_%s_%p_%t"
archivelog until time 'SYSDATE-4' delete input;
release channel ch1;
release channel ch2;
#release channel ch3;
}
exit

I have been through this with Oracle, but they are just saying that its
a problem with the Veritas End.

The one thing that I have noticed is that when the backup runs,
initially for the first 45 mins both tape drives are used. After that
1 is utlized, and it stays utilized for the full backup, then slowly
but surely a few other channels are kicked off, much like the second
and last for about 45 mins.

My question is this. Is there any way for me to split the work load up
between the 2 tape drives more evenly I.E. both tape drives are being
used more often, rather than just 1. I thought I might be able to do
this via maxpeicesize in the rman script.

Any ideas anyone?

Thanks again for reading and any posts,

B14... aka... Marky Mark...

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #2 (permalink)  
Old 02-25-2008, 06:44 AM
B14
 
Posts: n/a
Default Re: Rac Backups....


B14 wrote:
> Hi all,
>
> My thanks in advance for Reading and any posts.
>
> We currently have a Rac Database which runs on Linux Redhat Ent 3 with
> Oracle 9i database on it. It is backed up by a Solaris 8 x86 box with
> Netbackup 5.1 and 2 tape drives. It is all connect via a 100mb
> standard line which is set up for full duplex on both ends.
>
> The database is about 500 - 600 gigs in size. Currently we do a full
> level 0 backup of the database daily. The tapes get changed on a
> Tuesday and a Friday, unfortunately the box is in America (Las Vegas)
> and I am in the UK, so it would be quite difficult (but not totally
> impossible) for us to run an incremental backup strategy of some sort.
> The backup takes about 14 hours to run.
>
> The current script that we are using looks like this:
>
> DATE=`date +%m%d%Y-%H%M%S`; export DATE
> USER=`id | cut -f2 -d"(" | cut -f1 -d")"`
> ORACLE_SID=[sid]; export ORACLE_SID
> ORACLE_USER=[user]; export ORACLE_USER
> ORACLE_HOME=[path] export ORACLE_HOME
>
> #delete log files older than 35 days
> find /var/adm/netbackup -name "auslive*" -mtime +35 -type f -exec rm {}
> \;
>
> #if [ "${USER}" = "root" ]
> #then
> # su - ${ORACLE_USER} "cd /rac/DBA/scripts/BACKUP/" #-c
> "${CMD_STRING}"
> # SUCCESS=$?
> #else
> # eval "/rac/DBA/scripts/BACKUP"
> # SUCCESS=$?
> #fi
>
> <<EOF su - [user]
> <<EOF1 /u01/oracle/product/9.2.0/bin/rman msglog
> /var/adm/netbackup/AUSLIVE_b
> ackup.${DATE} append
>
>
> connect target [user]/[pass]@box
> connect catalog [user]/[pass]@box
> #change archivelog all validate;
> run {
>
> allocate channel ch1 type sbt_tape
> PARMS="BLKSIZE=1048576";
> allocate channel ch2 type sbt_tape
> PARMS="BLKSIZE=1048576";
> #allocate channel ch3 type sbt_tape;
> CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
> CONFIGURE CHANNEL 1 DEVICE TYPE 'SBT_TAPE' MAXPIECESIZE
> 100000m
> CONNECT = '[user]/[pass]@box';
> CONFIGURE CHANNEL 2 DEVICE TYPE 'SBT_TAPE' MAXPIECESIZE
> 100000m
> CONNECT = '[user]/[pass]@box';
> #CONFIGURE CHANNEL 3 DEVICE TYPE 'SBT_TAPE' CONNECT =
> '[user]/[pass]@box';
> change archivelog all validate;
> send "NB_ORA_CLASS=[policy]";
> #send "NB_ORA_CLIENT=[client]";
> send "NB_ORA_CLIENT={client]";
> send "NB_ORA_SCHED=full";
> backup
> incremental level=0
> filesperset 150
> format "bk_%s_%p_%t"
> tag "hot_${ORACLE_SID}_${DATE}"
> database;
> sql "alter system archive log current";
> backup
> filesperset 10
> format "ct_%s_%p_%t"
> current controlfile;
> sql "alter system archive log current";
> backup
> filesperset 150
> format "al_%s_%p_%t"
> archivelog all not backed up 2 times;
> backup
> filesperset 50
> format "al_%s_%p_%t"
> archivelog until time 'SYSDATE-4' delete input;
> release channel ch1;
> release channel ch2;
> #release channel ch3;
> }
> exit
>
> I have been through this with Oracle, but they are just saying that its
> a problem with the Veritas End.
>
> The one thing that I have noticed is that when the backup runs,
> initially for the first 45 mins both tape drives are used. After that
> 1 is utlized, and it stays utilized for the full backup, then slowly
> but surely a few other channels are kicked off, much like the second
> and last for about 45 mins.
>
> My question is this. Is there any way for me to split the work load up
> between the 2 tape drives more evenly I.E. both tape drives are being
> used more often, rather than just 1. I thought I might be able to do
> this via maxpeicesize in the rman script.
>
> Any ideas anyone?
>
> Thanks again for reading and any posts,
>
> B14... aka... Marky Mark...


Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #3 (permalink)  
Old 02-25-2008, 06:44 AM
B14
 
Posts: n/a
Default Re: Rac Backups....


B14 wrote:
> Hi all,
>
> My thanks in advance for Reading and any posts.
>
> We currently have a Rac Database which runs on Linux Redhat Ent 3 with
> Oracle 9i database on it. It is backed up by a Solaris 8 x86 box with
> Netbackup 5.1 and 2 tape drives. It is all connect via a 100mb
> standard line which is set up for full duplex on both ends.
>
> The database is about 500 - 600 gigs in size. Currently we do a full
> level 0 backup of the database daily. The tapes get changed on a
> Tuesday and a Friday, unfortunately the box is in America (Las Vegas)
> and I am in the UK, so it would be quite difficult (but not totally
> impossible) for us to run an incremental backup strategy of some sort.
> The backup takes about 14 hours to run.
>
> The current script that we are using looks like this:
>
> DATE=`date +%m%d%Y-%H%M%S`; export DATE
> USER=`id | cut -f2 -d"(" | cut -f1 -d")"`
> ORACLE_SID=[sid]; export ORACLE_SID
> ORACLE_USER=[user]; export ORACLE_USER
> ORACLE_HOME=[path] export ORACLE_HOME
>
> #delete log files older than 35 days
> find /var/adm/netbackup -name "auslive*" -mtime +35 -type f -exec rm {}
> \;
>
> #if [ "${USER}" = "root" ]
> #then
> # su - ${ORACLE_USER} "cd /rac/DBA/scripts/BACKUP/" #-c
> "${CMD_STRING}"
> # SUCCESS=$?
> #else
> # eval "/rac/DBA/scripts/BACKUP"
> # SUCCESS=$?
> #fi
>
> <<EOF su - [user]
> <<EOF1 /u01/oracle/product/9.2.0/bin/rman msglog
> /var/adm/netbackup/AUSLIVE_b
> ackup.${DATE} append
>
>
> connect target [user]/[pass]@box
> connect catalog [user]/[pass]@box
> #change archivelog all validate;
> run {
>
> allocate channel ch1 type sbt_tape
> PARMS="BLKSIZE=1048576";
> allocate channel ch2 type sbt_tape
> PARMS="BLKSIZE=1048576";
> #allocate channel ch3 type sbt_tape;
> CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
> CONFIGURE CHANNEL 1 DEVICE TYPE 'SBT_TAPE' MAXPIECESIZE
> 100000m
> CONNECT = '[user]/[pass]@box';
> CONFIGURE CHANNEL 2 DEVICE TYPE 'SBT_TAPE' MAXPIECESIZE
> 100000m
> CONNECT = '[user]/[pass]@box';
> #CONFIGURE CHANNEL 3 DEVICE TYPE 'SBT_TAPE' CONNECT =
> '[user]/[pass]@box';
> change archivelog all validate;
> send "NB_ORA_CLASS=[policy]";
> #send "NB_ORA_CLIENT=[client]";
> send "NB_ORA_CLIENT={client]";
> send "NB_ORA_SCHED=full";
> backup
> incremental level=0
> filesperset 150
> format "bk_%s_%p_%t"
> tag "hot_${ORACLE_SID}_${DATE}"
> database;
> sql "alter system archive log current";
> backup
> filesperset 10
> format "ct_%s_%p_%t"
> current controlfile;
> sql "alter system archive log current";
> backup
> filesperset 150
> format "al_%s_%p_%t"
> archivelog all not backed up 2 times;
> backup
> filesperset 50
> format "al_%s_%p_%t"
> archivelog until time 'SYSDATE-4' delete input;
> release channel ch1;
> release channel ch2;
> #release channel ch3;
> }
> exit
>
> I have been through this with Oracle, but they are just saying that its
> a problem with the Veritas End.
>
> The one thing that I have noticed is that when the backup runs,
> initially for the first 45 mins both tape drives are used. After that
> 1 is utlized, and it stays utilized for the full backup, then slowly
> but surely a few other channels are kicked off, much like the second
> and last for about 45 mins.
>
> My question is this. Is there any way for me to split the work load up
> between the 2 tape drives more evenly I.E. both tape drives are being
> used more often, rather than just 1. I thought I might be able to do
> this via maxpeicesize in the rman script.
>
> Any ideas anyone?
>
> Thanks again for reading and any posts,
>
> B14... aka... Marky Mark...


Based on a few replys I have had from other forums, the general opinion
seems to be changing the fileperset in the main backup to say 15
instead of 150.

Thought I would just put the answer on as it may be of use to someone
else later on,

thanks,

Mark.

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #4 (permalink)  
Old 02-25-2008, 06:45 AM
joel garry
 
Posts: n/a
Default Re: Rac Backups....


B14 wrote:

> Based on a few replys I have had from other forums, the general opinion
> seems to be changing the fileperset in the main backup to say 15
> instead of 150.
>
> Thought I would just put the answer on as it may be of use to someone
> else later on,
>


I don't know if it applies to anything beyond my particular situation,
but I've noticed if all data files are the same size, RMAN seems to
parallelize more evenly. If a few are much larger, those few seem to
spend a lot of time being worked on alone.

jg
--
@home.com is bogus.
anti-spam spam http://catless.ncl.ac.uk/Risks/24.40.html#subj4

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #5 (permalink)  
Old 02-25-2008, 06:56 AM
B14
 
Posts: n/a
Default Re: Rac Backups....


joel garry wrote:

> B14 wrote:
>
> > Based on a few replys I have had from other forums, the general opinion
> > seems to be changing the fileperset in the main backup to say 15
> > instead of 150.
> >
> > Thought I would just put the answer on as it may be of use to someone
> > else later on,
> >

>
> I don't know if it applies to anything beyond my particular situation,
> but I've noticed if all data files are the same size, RMAN seems to
> parallelize more evenly. If a few are much larger, those few seem to
> spend a lot of time being worked on alone.
>
> jg
> --
> @home.com is bogus.
> anti-spam spam http://catless.ncl.ac.uk/Risks/24.40.html#subj4


I think that this is really a veritas problem to be honest, I really
don't think it anything to do with Oracle, I mean it could be, but it
just seems like the bandwidth to the tape drives is being stiffled.

At the moment I am getting 10 mb per second write on 2 tape drives (the
backup is being done via a gig link line). When I backup other
databases I am getting 20mb per second on a single tape drive!

I don't know really whats up with it, some of guys in the office think
its because we are running on OCFS1 they reckon OCFS2 is a much quicker
file system.

Thanks again everyone,

Mark.

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 05:20 AM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.2.0
www.UnixAdminTalk.com