On 9/21/06, Martin, Jonathan (Contractor) <JMARTI05 at intersil.com> wrote:
> Not to interject, but I'm thinking quite the opposite here.
...
>     We can't have all nodes of
> the farm taking a backup "hit" at the same time now can we?

There are several ways to throttle the impact of NetBackup on your
network and servers.

Storage Unit:
  * Maximum concurrent drives used for backup
Policy:
  * Limit jobs per policy
  * Allow multiple data streams
Schedule:
  * Media Multiplexing
bp.conf:
  * LIMIT_BANDWIDTH
Java --> Host Properties --> Master Server --> Global attributes
  * Maximum jobs per client  (GLOBAL setting)
Java --> Host Properties --> Master Server --> Client attributes
  * Maximum data streams  (PER CLIENT setting)

The more NetBackup knows about your environment, the better it can handle it.

>       If you can get away with it, I'm sure
> one big window on Friday Night thru Sunday Evening is GREAT!  Throw in
> ALL_LOCAL_DRIVES and put all your machines in it.  (I wish!)  However,
> that kind of a general solution just doesn't cut it for my complex
> environment.

Why?

> As a side note, my Oracle DBAs spent a LOT of time consolidating their
> RMAN jobs into 4 policies, and we found out that Netbackup couldn't
> handle it.  We had to "back down" two of their policies to 6 or 8
> servers each, because 1 big job with all 18 servers causes jobs to fail!

Your DBAs may prefer to initiate their own jobs with cron (or
anything) instead of using NetBackup's scheduler.  It is extremely
dumb when it comes to Oracle and you don't need to use it.  All it
does is try to run the RMAN script on the Oracle server and will retry
the the whole job if it fails.  From Oracle/RMAN's point of view,
Netbackup looks like a tape drive.

>From MY point of view (Oracle notwithstanding), NetBackup can handle
the job scheduling much better than I can.  The point of policies
isn't to make configuration more complicated, but to logically group
systems.  It is much easier to review and understand a few policies
with a few schedules each than to review hundreds (or thousands) of
individual configurations posing as "policies."

Austin