Re: Netbackup on a RAC

  • From: "Niall Litchfield" <niall.litchfield@xxxxxxxxx>
  • To: mkline1@xxxxxxxxxxx
  • Date: Tue, 19 Jun 2007 14:35:38 +0100

I won't comment on the politics other than to say that there is some, and
that it will need to be addressed.

You do look however as if you are in project stage. I'd be hoping that
backup, storage and scalability requirements were a project design issue (I
can dream can't I). They aren't an implementation decision. It might be that
the project manager could usefully review the issues, using whatever issues
management methodology they are familiar with, raised in the email.

meanwhile some info that might help. We backup a 160gb RAC environment (3
nodes - we had to move beyond the special case just for fun) to nfs mounted
disk in 2 and a bit hours. This is on commodity intel hardware supplied by a
manufacturer begining with D :). That gets backed up to tape afterwards. I
haven't had any complaints about the speed of either the disk backup or the
tape backup. We do use a dedicated node for disk backup and a central tape
server for tape backup of the disk.




On 6/16/07, Michael Kline <mkline1@xxxxxxxxxxx> wrote:

 Got this info from our NetBackup person. I'm not sure how much is true or
not. Looking for tips and suggestions.



The database is 10G on some large IBM AIX servers. I think P595, but not
positive.

From our NetBackup guy.

Please hear me on this.

Implement large databases requiring backup on standalone servers.  Do not
use a shared or LPAR environment.

An effective backup of a large database requires access to either a
dedicated offnet NIC or a tape attached HBA.

Right now, we have a project which is having to reinstall to another
server since they implemented on a shared IO environment.

This database has been quoted to me as 30g.  If RAC/AIX/LPAR is feasible
at all at our software level (enquiry has been submitted to the vendor),
that doesnt sound too bad.

IF this is QA and there is a larger Prod component planned, or any other
project planned with a large database,  don t implement it this way.  Use a
standalone server.

I will save this email so we can all remember that this was mentioned.



Michael Kline

Midlothian, VA  23112

O: 804.744.1545

Fax: 804.763.0114






--
Niall Litchfield
Oracle DBA
http://www.orawin.info

Other related posts: