oracle incremental backup performance issue

[rookie11]

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

[sri_vani]

Please verify this link

http://www.symantec.com/business/support/index?page=content&id=TECH188913

[Marianne]

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.

[jim_dalton]

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]

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

[Marianne · Accepted solution]

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.