Re: Upgrade Plan
Date: Mon, 19 Jan 2009 14:13:16 -0600
Message-ID: <Q45dl.11285$D32.1156_at_flpi146.ffdc.sbc.com>
hpuxrac wrote:
> On Jan 18, 1:40 pm, Ruud de Koter <nob..._at_internet.org> wrote:
>> hpuxrac wrote:
>>> On Jan 17, 8:28 pm, Mladen Gogala <gogala.mla..._at_gmail.com> wrote:
>>> snip
>>>>> with 10g you can dump
>>>>> those expensive VCS licenses and use RAC/CRS only.
>>>> Actually, if they paid for them, VxFS/CFS with VCS is better
>>>> then ASM/CRS combination. Have in mind that ASM is not a fully
>>>> fledged file system and it's much harder to copy files to and from
>>>> ASM then it is to copy files to and from a file system. Also, VxFS
>>>> has caching (and cache coherence, of course) so you will not grow
>>>> old when waiting for scp to copy a file from a VxFS file system.
>>>> I wouldn't throw away those licenses, far from it.
>>> We eventually ditched RAC and are now completing a hpux to linux
>>> migration. When we were running rac on hpux service guard and raw
>>> worked well for us ( no veritas licenses ). At some point hp and so
>>> hpux started bundling in part of the veritas cluster software with
>>> service guard ... but that happened after we were headed in a
>>> different direction.
>>> With all the attention on the quality of oracle support *cough cough*
>>> there is no shortage of people wondering if it would not be better to
>>> avoid having your database vendor also provide your clustering
>>> software but of course oracle prevents that at the 10g level and
>>> above.
>> A very interesting post that rather stimulates my imagination. As I am
>> to formulate a policy for our databases (central or decentrealized
>> management), I am almost certain to run into the question "Why not
>> set up a RAC implementation?" at some point. Would you please outline
>> the sensitivities when choosing to do so (or more bluntly: would you
>> share what brought you to ditch RAC)? I think that would be a voice
>> from practice that could be very valuable for our decision making.
>>
>> My sincere thanks in advance,
>>
>> Ruud de Koter.
> > Email me individually and I can give my a phone number. > > The topic of to RAC or not really has been nailed by Moans Nogood ( a > former Oracle employee ) ( he has a real name ) ... try searching for > moans nogood ( and the words ) why you probably don't need RAC. > > He has written and framed the overall picture much better than I > could. His experience and breadth of knowledge is not to be > underestimated.
One of the biggest misconceptions of RAC is that if you throw together a bazillion "commodity" servers in RAC, it will out perform [your favorite more expensive vendor here] and will cost less. RAC licenses, like any other license from Oracle, is negotiable and your leverage will always depend upon how much you are willing to - or must spend for your environment and/or how good of a negotiator you are with your sales rep(s).
I will agree that you can really screw yourself if you do not understand how to configure the environment - from both database and application points of view.
My earlier point is that from a technical standpoint you would have a very difficult time convincing me that using both VCS with CRS in a 10/11g RAC cluster is the right thing to do. You end up with nothing but vendor finger-pointing should (more like when) something should go awry, not to mention the fact that you know have 2 cluster "managers" trying to keep the cluster up and they don't play very well in the same sand box.
I came from the DEC/VMS world - the one true cluster that no one has been able to duplicate in the more than 25+ years that the DEC cluster has been around and in conjunction with the formerly-DEC-now-Oracle Rdb was what Ellison always dreamed his RDBMS would become. His many attempts at OPS failed miserably even on VMS. When 9iRAC was first introduced back in 1999, the Oracle engineering rep at that time stated categorically, that it only worked as was originally designed on 2 platforms. OpenVMS and Tru64 UNIX clusters - because they are the ONLY ones that can natively mount ALL storage devices concurrently. ASM and CRS make that a bit easier, however, having a single set of OS files and directories across the cluster will continue to elude the UNIX market. Received on Mon Jan 19 2009 - 14:13:16 CST