From what I’ve seen so far, Backup Exec 2012, Oracle and tape don’t work well together. If your experience is different, please comment.
Does anyone have a work around for the following issue?
An oracle database has been backed up to disk. Later as a separate job, this database backup set is selected for duplication to tape. During the job execution, many tapes are used far in excess of what should have been required. It’s not possible to see what is actually written to these tapes since Oracle databases don’t show up on tapes as backup sets. Ref: (Backup Exec 2012 - Oracle backup sets on tapes are special (not displayed))
The problem of the use of many extra tapes doesn’t occur when the duplication to tape job is a linked stage in a oracle backup job.
My actual Oracle databases are backed up directly to deduplication storage. If I separately duplicate from that to tape, the problem occurs. If I duplicate to regular disk storage first and then duplicate to tape, the disk duplication works and then the duplication to tape has the many tape usage problem. I don’t think it matters if the original Oracle backup is to deduplication or disk, but it might.
I’m using a Dell TL4000 library with 4 LTO5 drives. The capacity of each tape is far larger then any of my Oracle databases. The jobs are sent to a single drive. Tapes used may end up with the Not appendable (End marker unreadable) status. This problem doesn't occur with the duplication of any other backup set other than Oracle.
Duplicate Set Summary
Backed up 5 Oracle RMAN backup pieces.
Processed 41,714,450,432 bytes in 6 minutes and 58 seconds.
Throughput rate: 5710 MB/min
All Media Used
The issues that you described seem to be vaugely similar to a restore issue which is being worked upon by Engineering. However, the same has not yet been reported to happen while backing up or duplication. Is it possible for you to open a support case as we might need a lot more information which can ge gathered from different debug logs.
As a test could you create a new test job which first backs up the data to a B2D and then link job duplicates this data to a Tape and then to a Dedup. See if this changes anything.