Mladen or anyone else, can you explain <q>Adding the 3rd network point can
severely impact the performance, since all the communication would actually
go through that dedicated "backup server"</q>
I would think that the backups themselves would still run on the database
servers (isn't that where the rman and oracle binaries and db files are
located) and the backups would still be using the DB servers' CPU. The
'backup server' in this scenario may only have to communicate with each db
server and initiate the backups on a nightly basis. Am I right in my
assumption? If that is correct there will not be too much data flowing
between the DB servers and the backup server; the backup server will not be
a big bottleneck.
Reason I am asking is Seth's idea looks great to me, but would like to know
if the backup server would be a limiting factor. Also if anyone has such a
setup they can share their experiences.
Thanks
Ram.
If you like your shell scripts and are comfortable with cron, you might
be able to just enhance it enough to eliminate the single point of failure
and dramatically reduce your risks by centralizing your backups.
Modify your rman scripts to use an Oracle wallet to authenticate to the
databases remotely through an rman client. That way, you can take a backup
without having to be on the server and won't expose the password of a
privileged account.
What about performance? NetBackup usually pushes the data from DB server
to media server. Adding the 3rd network point can severely impact the
performance, since all the communication would actually go through that
dedicated "backup server". What happens if there are several simultaneous
backups, all going through the "backup server"? Do you need to backup all
the databases at separate times? RMAN maps libobk.so into its address space
at the time when "allocate channel device type SBT" is executed and it's
libobk.so which facilitates the communication between rman and the media
server. So, all communication for database backups would go through this
"backup server", which would not only be a bottleneck, but also a single
point of failure.
