I would like the mechanism of the new oracle redo log backup to be improved.
My biggest concern is the fact, that Veeam B&R copies the redo log files to the "/tmp" directroy when backing up (Linux-Server , donnot know about Win).
This is a solution that might be o.k. for smaller databases with only few changes in data. For large databases with heavy data modification which results in a big amount of redo logs beeing produced, this is a "no go" in my point of view.
TMP-Directories with 2-4GB of free space are usually sufficient for an oracle database server. But this won't work for veeam backup.
There needs to be at least as much space in TMP availabe for veeam as the amount of redo logs the database genereates in one redo log backup cycle (default 15 min. in Veeam) in worst case!
But that is hardly predictable. In addition it is also not predictable how much of the available space in TMP is used by other applications on the server at any time.
It gets worse when backup is under maintanance for a certain time. After maintananace there will be even more redo logs to backup in one cycle.
Sooner or later TMP will run out of space. Redo log backup will get an error and the situation will get even worse since backup will halt and even more redo logs that need to be backed up in the next cycle will be produced by the database.
This is what I encountered in my first tests and Veeam B&R didnot seem to recover from this scenario by itself. I ended up delete the tmp directory manually and triggering the parent job that truncated all redo log files.
To have a robust solution the only way would be to size the tmp directory to the same size as the oracle archive log area, but this is a big waste of storage, since most times this space would not be used.
And why copy the files anyway? They are already there in the archivelog directory, ready to be picked up by veeam. Why not get them from the original location? In that case nobody has to worry about free space in TMP.
I think when backing up a machine or database, free space on the server to be backed up should not be an issue...
An alternative would be to detect the filesystem full condition and only copy that much files to TMP that will fit there, then transport them to the repository, delete them from TMP and then copy the next files ...
I am more than satisfied with the other veeam capabilities and I was hoping with the v9 oracle integration I could get rid of the HP Data Protector. So I would very much welcome the described improvements, I am not feeling save about switching database backups to veeam at the moment.