Received: (qmail 20154 invoked from network); 2 Feb 2010 17:34:40 -0600 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by static-ip-85-25-126-90.inaddr.intergenia.de with SMTP; 2 Feb 2010 17:34:25 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 6861ECCE899; Tue, 2 Feb 2010 18:34:17 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at localhost.localdomain Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-RTeIEtXnKu; Tue, 2 Feb 2010 18:34:17 -0500 (EST) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id B06B0CCE846; Tue, 2 Feb 2010 18:33:35 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Tue, 02 Feb 2010 18:32:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 6804ACCE841 for ; Tue, 2 Feb 2010 18:32:54 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLa8GO6lwss8 for ; Tue, 2 Feb 2010 18:32:54 -0500 (EST) Received: from mail-pz0-f188.google.com (mail-pz0-f188.google.com [209.85.222.188]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id CF23CCCE844 for ; Tue, 2 Feb 2010 18:32:53 -0500 (EST) Received: by pzk26 with SMTP id 26so663336pzk.26 for ; Tue, 02 Feb 2010 15:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=/M6w5qSpSx6yZMvzWTYSvR434R7vQwBZAGH1jgIHJBc=; b=GZNRIQknB084S8o/9OUfFTkkNbGYOudAeAGTxUvKqDaAWBBOoxr4OfMDvz7r1ZxVUH AQsbTkr0ejvStjgIQ1m4wSnn8jrXqGO9VEZDgDvFlsl8mYlZenQb+eQp2ls0UaPtSoUU wlECWnBk6KXr7QpKLWpoOlB6nwq0sIOhixa/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=nPp9b1JALU8kLKwRO0cpZ6+cEqRPsNY3Q6/7t36mXRaeTd6LsZsDPMTKmU3pzGFyT5 PQqxcwm1RFVWyO1ifEfKppdhJzsXRjBI90OKPLUo2xME4eS7H/JNUB2a4GviLY95tnAA WUwikFI3DrTDT1+1lW7ZknPbF9SGvRD7rmIPM= MIME-Version: 1.0 Received: by 10.143.24.25 with SMTP id b25mr4497015wfj.165.1265153570378; Tue, 02 Feb 2010 15:32:50 -0800 (PST) In-Reply-To: References: <172762181002021351vc8b75d8r18842effb1e8e731@mail.gmail.com> Date: Tue, 2 Feb 2010 21:32:50 -0200 X-Google-Sender-Auth: 76f69c78ef6e2610 Message-ID: <172762181002021532l4110bc5fuce01597149a994bd@mail.gmail.com> Subject: Re: RAC for dev env From: Guillermo Alan Bort To: Thomas Roach Cc: veeeraman@gmail.com, ORACLE-L Content-Type: multipart/alternative; boundary=001636e0a66c2614be047ea68529 X-archive-position: 25264 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: cicciuxdba@gmail.com Precedence: normal Reply-to: cicciuxdba@gmail.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l --001636e0a66c2614be047ea68529 Content-Type: text/plain; charset=ISO-8859-1 I have horror stories of Siebel on RAC (windows)... they complained that in test/dev it worked fine, but in prod they got disconnected very often. We soon found out that there were about 3 instance evictions per week... and sometimes the servers would just freeze. This turned out to be a RAC bug on windows (nobody sensible ever used RAC on windows, so it was discovered in this environment. No patch for it... it's a 9i RAC. Oh, a load testing as well... they were performing separate tests... one for RW operations and one for RO. the RO was on prod the RW on dev... and they called THAT load testing... hth Alan.- On Tue, Feb 2, 2010 at 8:30 PM, Thomas Roach wrote: > I will give you a story where this bit me BIGTIME. > > We had a Solaris 10 RAC cluster (10.2.0.4) for production but the business > skimped because they didn't want to pay "all that money" for RAC just for a > Dev/QA environment. This was a system that was generating 600+ million > dollars in revenue, but they didn't want to spend a few hundred thousand to > get RAC. Sounds like the tail wagging the dog, and it was! > > So time came around to do security patches and what not. They also wanted > CRS Bundle patches. So we patched Dev/QA, no problem. When we went to apply > the CRS_BUNDLE patch there was an error with the patchset and it wiped out > the inittab. (I didn't know what happened, but eventually uncovered > inittab). The upgrade script bombed multiple times. I got Oracle support on > the line and we troubleshooted it. 8 hours later we got the systems back > online. > > The owner of this business segment was pissed. We had a post mortem that > was not pretty. She looked straight at me and said, why didn't we see these > problems in QA or even Dev? It cost us (a lot of money, more than Oracle RAC > licensing for Dev/QA would have cost). I told her that her environments did > not match. She said why? I said because no one wanted to spend the money to > make the environments match. That shut her up real quick. > > Needless to say it was a high priority to make them match and they spared > no money to get environments up to speed. > > I knew the lesson learned, but it was a lesson for the business. You need > to explicitly tell them that unless environments match, there is a risk that > not everything can be pretested prior to going into production. Let them > decide if it is worth it. If they say no, get it in writing. > > Tom > > > On Tue, Feb 2, 2010 at 4:51 PM, Guillermo Alan Bort wrote: > >> Hi Ram >> >> I have seen this in several places and it always leads to severe downtime >> in production. non RAC Dev environments could work for functional >> development. For performance and concurrency testing and for staiblity >> testing, you need a RAC environment. Furthermore, I'd suggest you get >> someone with a lot of experience in RAC before actually going to production >> with it. Having a TEST/DEV/QA RAC could help you gain that experience. >> >> I cannot speak as to licensing, but if you have the DB up, then it doesn't >> matter what you use it for... you still have to have a license, at least >> that is how I understand it. >> >> One suggestion, if you can't get someone with experience... get a couple >> of virtual machines and toy around with them. You can delete them >> afterwards, or burn them to DVD and hide them under your desk in case of an >> audit by Oracle, and still have a RAC sandbox... you wouldn't be able to >> perform stress tests here, but you can test functionality and the quirks of >> RAC. >> >> That being said, perhaps reviewing WHY they want RAC would reveal that >> they actually don't need RAC but a simple DataGuard. I've recently >> recommended moving from a two-node RAC to a single instance on a better >> server (better hardware, 64 bit instead of 32 bit and AIX instead of >> windows) and setting up a DataGuard for fast recovery and minimal data loss >> >> And just a word of advice... never, EVER, use RAC on Windows. Actually... >> never user windows for a database server... >> >> RAC is like exadata... it's useful only in very specific situations, other >> than that is just a waste of money and resources. >> >> hth >> Alan.- >> >> >> >> On Tue, Feb 2, 2010 at 6:30 PM, Ram Raman wrote: >> >>> Hi >>> >>> A decision has been made by upper management to use RAC for production >>> environment and nonRAC for dev/test environments. I would prefer to have a >>> parallel environment which is identical to prod. Is it possible to run a >>> dev environment without having to worry about license. If license might >>> be an issue for dev, can we have one environment where we just install RAC >>> for practice before deploying it in production. >>> >>> Any thoughts or guidances on the issue would be highly appreciated. >>> >>> Thanks, >>> Ram. >>> >>> >> >> > > > -- > Thomas Roach > 813-404-6066 > troach@gmail.com > --001636e0a66c2614be047ea68529 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have horror stories of Siebel on RAC (windows)... they complained that in= test/dev it worked fine, but in prod they got disconnected very often. We = soon found out that there were about 3 instance evictions per week... and s= ometimes the servers would just freeze. This turned out to be a RAC bug on = windows (nobody sensible ever used RAC on windows, so it was discovered in = this environment. No patch for it... it's a 9i RAC.

Oh, a load testing as well... they were performing separate tests... on= e for RW operations and one for RO. the RO was on prod the RW on dev... and= they called THAT load testing...

hth
Alan.-


On Tue, Feb 2, 2010 at 8:30 PM, Thomas R= oach <troach@gmail= .com> wrote:
I will give you a story where this bit me BIGTIME.

We had a Solaris = 10 RAC cluster (10.2.0.4) for production but the business skimped because t= hey didn't want to pay "all that money" for RAC just for a De= v/QA environment. This was a system that was generating 600+ million dollar= s in revenue, but they didn't want to spend a few hundred thousand to g= et RAC. Sounds like the tail wagging the dog, and it was!

So time came around to do security patches and what not. They also want= ed CRS Bundle patches. So we patched Dev/QA, no problem. When we went to ap= ply the CRS_BUNDLE patch there was an error with the patchset and it wiped = out the inittab. (I didn't know what happened, but eventually uncovered= inittab). The upgrade script bombed multiple times. I got Oracle support o= n the line and we troubleshooted it. 8 hours later we got the systems back = online.

The owner of this business segment was pissed. We had a post mortem tha= t was not pretty. She looked straight at me and said, why didn't we see= these problems in QA or even Dev? It cost us (a lot of money, more than Or= acle RAC licensing for Dev/QA would have cost). I told her that her environ= ments did not match. She said why? I said because no one wanted to spend th= e money to make the environments match. That shut her up real quick.

Needless to say it was a high priority to make them match and they spar= ed no money to get environments up to speed.

I knew the lesson learn= ed, but it was a lesson for the business. You need to explicitly tell them = that unless environments match, there is a risk that not everything can be = pretested prior to going into production. Let them decide if it is worth it= . If they say no, get it in writing.

Tom


On Tue, Feb 2, 2010 at 4:51 PM, Guillermo Alan Bort <= cicciuxdba@gmail.= com> wrote:
Hi Ram

I have seen this in several places and it always leads to sev= ere downtime in production. non RAC Dev environments could work for functio= nal development. For performance and concurrency testing and for staiblity = testing, you need a RAC environment. Furthermore, I'd suggest you get s= omeone with a lot of experience in RAC before actually going to production = with it. Having a TEST/DEV/QA RAC could help you gain that experience.

I cannot speak as to licensing, but if you have the DB up, then it does= n't matter what you use it for... you still have to have a license, at = least that is how I understand it.

One suggestion, if you can't = get someone with experience... get a couple of virtual machines and toy aro= und with them. You can delete them afterwards, or burn them to DVD and hide= them under your desk in case of an audit by Oracle, and still have a RAC s= andbox... you wouldn't be able to perform stress tests here, but you ca= n test functionality and the quirks of RAC.

That being said, perhaps reviewing WHY they want RAC would reveal that = they actually don't need RAC but a simple DataGuard. I've recently = recommended moving from a two-node RAC to a single instance on a better ser= ver (better hardware, 64 bit instead of 32 bit and AIX instead of windows) = and setting up a DataGuard for fast recovery and minimal data loss

And just a word of advice... never, EVER, use RAC on Windows. Actually.= .. never user windows for a database server...

RAC is like exadata..= . it's useful only in very specific situations, other than that is just= a waste of money and resources.

hth
Alan.-



On Tue, Feb 2, 2010 at 6:30 PM, Ram Rama= n <veeeraman@gmail.com> wrote:
Hi
=A0
A decision has been made by=A0upper management to use RAC for producti= on environment and nonRAC for dev/test environments. I would prefer to have= =A0a parallel environment which is identical to prod.=A0 Is it possible to = run a dev environment without having to=A0worry about license. If=A0license= might be=A0an issue for dev, can we have one environment where we just ins= tall RAC for practice before deploying it in production.
=A0=A0
Any thoughts or guidances on the issue would be highly appreciated.
=A0 =A0
Thanks,
Ram.
=A0




--
Thomas Roach
813-404-6066
troach@gmail.com

--001636e0a66c2614be047ea68529-- -- http://www.freelists.org/webpage/oracle-l