Video Screencast Help

oracle incremental backup performance issue

Created: 03 Nov 2013 • Updated: 23 Jun 2014 | 5 comments
This issue has been solved. See solution.

Hi folks

client server solaris 10, NBU version 7.1.0.2 backup going to data domain which is giving good dedupe rate. since past few weeks incremental backup time has increased 8 folds. datasize size is roughly the same. need some suggestions, NBU or oracle tweaking to produce results and reduce incremental backup time.
 
script which is in place on server:
 
RUN {
 
##########################################
# Back up the database.
# Use 4 channels as 4 parallel backup streams.
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch02 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch03 TYPE 'SBT_TAPE';
 
# Set NetBackup backup policy name
SEND 'NB_ORA_POLICY= att_fin_oracle-rman-full';
 
BACKUP
  INCREMENTAL LEVEL 1
  SKIP INACCESSIBLE
  # FILESPERSET to 1 facilitates database deduplication
  FILESPERSET 1
  # Include DB name, set numbet, piece number and time stamp
  FORMAT 'bk_att1_%d_%s_%p_%t'
  DATABASE;
 
  sql 'alter system archive log current';
 
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
RELEASE CHANNEL ch02;
RELEASE CHANNEL ch03;
 
##########################################
# Back up the archive logs
# The FILESPERSET parameter setting depends on the number of archive logs you have.
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE';
 
# Set NetBackup backup policy name
SEND 'NB_ORA_POLICY=att_fin_oracle-rman-full';
 
BACKUP
  SKIP INACCESSIBLE
  FILESPERSET 20
  FORMAT 'al_%d_%s_%p_%t'
  ARCHIVELOG ALL;
 
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
 
##########################################
# Backup control file
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
 
# Set NetBackup backup policy name
SEND 'NB_ORA_POLICY=att_fin_oracle-rman-full';
 
BACKUP
  FORMAT 'cntrl_%d_%s_%p_%t'
  CURRENT CONTROLFILE;
 
RELEASE CHANNEL ch00;
 
}
 
EOF
 
 
Operating Systems:

Comments 5 CommentsJump to latest comment

Marianne's picture

Try this:

http://docs.oracle.com/cd/B19306_01/backup.102/b14192/bkup004.htm#i1032148

4.4.4 Improving Incremental Backup Performance: Change Tracking

RMAN's change tracking feature for incremental backups improves incremental backup performance by recording changed blocks in each datafile in a change tracking file. If change tracking is enabled, RMAN uses the change tracking file to identify changed blocks for incremental backup, thus avoiding the need to scan every block in the datafile.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

jim dalton's picture

As MVDB says, change tracking can be very beneficial. Its an oracle feature, not NB. It rather depends on the size of your db, but here I run fulls or incrementals on small (multiGB) dbs but anything larger we have CT turned on. If your backup spends an age trying to figure out whats changed then it could be for you.

Comes as part of 10G and up I believe, but check with your DBA.

Its odd that the backup size hasnt increased but the time has: we'd need to see the job specfics and DB specifics eg has the DB increased x 8 (unlikely) but the change remained same: that would mean the DB has 8x the data to look at to figure if its changed.

If thats already on, then we have to explore other avenues.

Jim

Jim-90's picture

Suggest checking with DD suport as regards the support of mutlplexing.  You have FILESPERSET = 20 , my understanding this equates multiplexing (of 20).

 

 

 

Marianne's picture

Symantec and DD recommend fileperset of 1 with dedupe.
Increase amount of channels.

Symantec recommendation can be seen in sri's post.

I will see if I can find the link to a Symantec best practice pdf as well as DD's recommendation.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

SOLUTION