Path: text.usenetserver.com!out02a.usenetserver.com!news.usenetserver.com!in02.usenetserver.com!news.usenetserver.com!cycny01.gnilink.net!cyclone1.gnilink.net!gnilink.net!nx01.iad.newshosting.com!newshosting.com!post01.iad!not-for-mail Date: Fri, 10 Oct 2008 06:17:57 -0700 From: DA Morgan Organization: Puget Sound Oracle Users Group User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 Newsgroups: comp.databases.oracle.server Subject: Re: RAC or Large SMP...? References: <368bb2a8-810e-4d23-9a5e-370ee4f46e36@b2g2000prf.googlegroups.com> <30456044-e3c2-457e-8165-2cabeedafe95@w13g2000prm.googlegroups.com> <1223443114.887587@bubbleator.drizzle.com> <1223446496.385495@bubbleator.drizzle.com> <7778d5a8-3621-4fdc-89f6-9e01487f672b@b30g2000prf.googlegroups.com> <6l6qmcFavcsgU1@mid.individual.net> <1223590623.384497@bubbleator.drizzle.com> <87hc7lmehw.fsf@lion.rapttech.com.au> <951152d1-95c5-42eb-8bb4-8d91aa14d34c@s9g2000prg.googlegroups.com> In-Reply-To: <951152d1-95c5-42eb-8bb4-8d91aa14d34c@s9g2000prg.googlegroups.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Message-ID: <1223644676.144318@bubbleator.drizzle.com> Cache-Post-Path: bubbleator.drizzle.com!unknown@dsl-216-162-218-178.drizzle.com X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) Lines: 92 X-Complaints-To: abuse@csolutions.net Xref: usenetserver.com comp.databases.oracle.server:448569 X-Received-Date: Fri, 10 Oct 2008 09:17:56 EDT (text.usenetserver.com) mccmx@hotmail.com wrote: >> I'm also not convinced that the fewer servers are easier to administer >> arguement is as valid these days. This was certainly true in the past, >> but modern package management has become quite sophisticated. >> Managing larger numbers of servers dedicated to the same role isn't that >> much of an overhead anymore. At least we haven't seen a substantial >> increase in administration since moving to RAC. In fact, the added >> fault tolerance has reduced impact and stress on staff when hardware >> failures occur. >> >> Tim > > Its exactly this area of RAC (i.e. adminstration) that concerns me. > In your experience does the following scenario sound familiar: > > > > "Ah yes, troubleshooting. I’ve seen many clusters that just froze for > no apparent > reason in my time. It’s always possible to make the OS or Cluster > software dump a > trace/log file when it happens. > > The resulting trace/log file from the cluster will normally be the > size of Texas, and > only one or two people in the entire vendor organisation can truly > understand them, > you will be told. > > Then the files (often with sizes measured in GB) are shipped to the > vendor and some > months later they will report back that it wasn’t possible to pinpoint > the exact reason > for the complete cluster freeze or crash, but that this parameter was > probably a bit low > and this parameter was probably a bit high. > > That’s what always happens. I have never – really: never – seen a > vendor who could > correctly diagnose and explain a hanging cluster or a cluster that > kept crashing. > As to Oracle trouble shooting I’m not so worried. Oracle will either > have a > performance problem, which is easy to diagnose using the Wait > Interface or you’ll > get ora-600 errors that are fairly easy to diagnose, although you’ll > need to spend the > required 42 hours logging and maintaining an iTAR or SR or whatever > the name is > these days. > > In other words: Finding out what’s wrong (if anything) in Oracle is > much easier than > finding out what’s wrong with a cluster." > > > > This quote was pulled from http://www.miracleas.dk/WritingsFromMogens/YouProbablyDontNeedRACUSVersion.pdf. > > Has the Oracle clusteware and RAC become mature enough so that the > above is no longer a common problem..? The company I now work for > deployed RAC 9i and went through 6 months of hell exactly like the > scenario above, so they have been burned in the past. > > There is also the argument that RAC systems will require more > scheduled downtime than single instance systems because there are more > Oracle homes to patch (CRS, multiple database homes, ASM homes etc). > > Personally, I'd love to implement the RAC solution as I think that it > is an excellent technology but somehow I think that I may regret it in > the long run...... The first RAC implementation I thought stable enough for production consideration was 9.2.0.4: Since then it has gotten substantially better. Mogen's comments on RAC are accurate within their context: That is not the only context there is. If you are going to go into RAC then make sure you build into your budget monies for a test cluster for software testing and to be used for DBA training and as a DBA sand box and also training for staff. With real hands-on RAC training, unfortunately something Oracle itself does not provide, 10gR2 and 11g RAC are not that much more difficult to manage than stand-alone. -- Daniel A. Morgan Oracle Ace Director & Instructor University of Washington damorgan@x.washington.edu (replace x with u to respond) Puget Sound Oracle Users Group www.psoug.org