Matt, Actually the Oracle note is correct and Veritas's note is incorrect. Veritas is aware of that the note you mention is incorrect. I believe the problem is the 4 nodes where not supported until Veritas released Maintenance Pack 1 (MP1) last December. Veritas has also indicated to me that they have successrully tested a 8 and 16 node Veritas cluster with 9i RAC and they are working with Oracle to get this certified.
So, yes Veritas DBE/AC 3.5 is currently supported up to 4 nodes with MP1 installed. Scott --- Matthew Zito <[EMAIL PROTECTED]> wrote: > > Pete's absolutely right - I didn't mean to give the > impression that it > was entirely Oracle's nefarious doings to conspire > to prevent people > from running RAC on their lovely Sun enterprise > servers. It's just the > combination of factors that are involved in these > type of configurations > where you have multiple vendors, each with highly > critical components > they're responsible for having to agree on something > they're all happy > with. So, in this particular example, its Veritas > that dictates the use > of EMC or HDS storage, not Oracle. I bet you could > run Veritas AC on > any storage that supports SCSI-3 persistent > reservation and it would > work at least reasonably well. The problem is, what > happens when you > have a problem and call Veritas? > > This sort of comes back to the classic question: is > the "supported" or > "certified" configuration always the "right" and > "only" configuration? > It varies wildly by company. In the storage space, > it runs from one > extreme - Netapp, which I have never ever heard say > that a config was > unsupported when there was a problem to be solved, > to the other extreme > - EMC (who I used to work for), who has a multi-meg > PDF describing every > single supported config down to things like > patchlevels of cluster > software. The flip side, of course, is that there's > a certain > confidence you're supposed to be able to have when > you're running a > "certified" configuration. > > With regards to RAC on Sun, there's a Metalink doc > that lays out the > compatible technologies (and as I look at it now, I > see that the oracle > docs claim 4 nodes on veritas AC 3.5 and the veritas > release notes say 2 > - interesting), and they're pretty explicit about > the technologies that > are certified. There's actually more options for > Sun than for Linux - > two cluster products instead of one on Linux. It's > just that the cost > and complexity of the Sun clustering options, > coupled with the higher > cost for Sun servers, seems to outweight the > benefits. Like Pete said, > RAC is mostly not about HA - I would argue its about > getting > cost-effective scalability and performance out of > databases > traditionally run on more expensive/larger > monolithic SMP machines. > > Pete's also right about raw - its really not _that_ > bad. I just prefer, > as it seems most people do, filesystem semantics for > management. My > full preference is actually for NAS, but that's just > the stingy person > in me not wanting to shell out the money for fibre > channel ports. > > Thanks, > Matt > -- > Matthew Zito > GridApp Systems > Email: [EMAIL PROTECTED] > Cell: 646-220-3551 > Phone: 212-358-8211 x 359 > -----Original Message----- > Pete Sharman > Sent: Thursday, June 05, 2003 3:01 PM > To: Multiple recipients of list ORACLE-L > > > From an Oracle perspective, we're fairly agnostic > about the cluster RAC > runs on. There was a major change in the > certification some time back > where we no longer certify the hardware. If it's a > cluster that's > supported by the OS vendor, then RAC should work on > it (and if it > doesn't then a bug needs to be logged). Here's a > couple of comments > from my personal perspective though (SELECT > standard_disclaimer FROM > company_requirements;) - none specifically aimed at > you personally: > > 1. I always find it difficult to > see why people have > so much difficulty with raw. I mean, really, come > on guys. If raw is > too hard, then how are you gonna cope with all the > other requirements of > HA (not just the Oracle ones but all the other > things like solid change > management and so on)? > 2. The problems with the Sun CFS > aren't so much with > the support of it as they are with the fact that the > performance of the > Sun CFS isn't good enough yet. CFS's are fine if > they're implemented > properly. Given my druthers, I'd go for a Compaq > system using their CFS > any time. After all, Digital / Compaq / HP / > whatever the next merger > is have been in the cluster game forever. Give me > my VAX back again! > :-) > 3. As an aside, raw is NOT a > requirement for RAC. Raw > is a requirement for those crappy OS's that can't > share open files. > Before the days of CFS's on Compaq, IIRC the only OS > that could do this > without raw was VAX/VMS. So don't blame RAC for raw > devices, blame the > crappy OS's it runs on. :-) > 4. Strange as it may seem to have > to mention it, you > do need more than RAC for real business continuity. > I did a > presentation at the DB Forum in Denmark last year on > this, and I'm still > constantly amazed by the number of people that think > RAC is all you need > to ensure real business continuity. RAC does one > thing and one thing > only in the HA space - it protects you against node > failure. Doesn't > protect you from sabotage - RMAN, LogMiner, > Flashback all provide parts > of that. Doesn't protect you from site failure - > DataGuard, Streams do > that. Doesn't protect you from human error - > DataGuard with delayed > redo apply, LogMiner and Flashback can all do that. > You need to > consider a lot more than just RAC for real business > continuity. > Luckily, Oracle has products that handle all of > that. :-) > > > Pete > > "Controlling developers is like herding cats." > Kevin Loney, Oracle DBA Handbook > > "Oh no, it's not. It's much harder than that!" > Bruce Pihlamae, long term Oracle DBA. > <snip> > __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Scott INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
