RE: 9i RAC or 10g RAC ?

  • From: "Nelson, Allan" <anelson@xxxxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Wed, 12 May 2004 07:23:55 -0500

I don't know that much about your situation so if I miss by a mile,
please just ignore this.  That being said you have a rather large sun
machine.  If you are bottlenecked on CPU the probability is good that
you are doing too many lio's due to sql that is doing too much work for
the business benefit received.

The stinger to this is that bad sql can make it possible to kill any box
or boxes companies have the money to buy.

Statspack can show you how many lio's you are doing as well as give you
a start on identifiying the sql that is giving you the grief.  I notice
you are a contractor, so perhaps your management will prove unresponsive
to fixing the sql, and if so, you have my sympathy.

Consider also that a RAC environment will consume more CPU than a large
SMP machine because the cache fusion will require CPU in a RAC where it
would not in a SMP box.  Further RAC is still not at the state where you
can completely ignore the partitioning of your application.  If you
can't determine what sql's go to what boxes for application, technical,
or management issues, then the cache traffic can really eat you up.

Allan

-----Original Message-----
=46rom: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Singh, Ratnesh (GEI,
GEFA, Contractor)
Sent: Tuesday, May 11, 2004 7:14 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: 9i RAC or 10g RAC =3F


Please advise if i am wrong, but I'm hoping that moving to RAC would =3D
help improve performance because :=3D20

Our Solaris production box, which is 12 cpu 1200 mhz,24 gb ram is cpu =3D
bound at peak working hours, and its lease ends in 3 months.
Management does not want to spend money on a bigger Solaris box. So we =3D
decided to purchase new linux boxes.

Since 12+ cpu linux boxes are very expensive, we have decided to go for
=3D
4cpu linux boxes featuring 2.2ghz Opteron cpu's on 9i or 10g rac, and a
=3D
new san with faster disks.

rac is being used primarily because i want to link together these 3 or 4
=3D
linux boxes.
The combination of these factors, faster cpu's , faster disks and bigger
=3D
ram should provide better performance, i hope =3F

any advice is appreciated.=3D20

thanks & regards
ratnesh=3D20


-----Original Message-----
=46rom: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Cary Millsap
Sent: Tuesday, May 11, 2004 11:43 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: 9i RAC or 10g RAC =3F


I think it's:

- If you want better performance, go single instance.
- If you want higher availability, go single instance.
- If you can't go single instance, then RAC is there for you.

When you have to go to RAC, everything gets a /lot/ more
expensive--performance, availability, administration, licenses,
...everything--but it appears to beat having to go with a non-Oracle
solution.


Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *

Upcoming events:
- Performance Diagnosis 101: 5/18 Edison NJ, 6/22 Pittsburgh, 7/20 =3D
Boston
- SQL Optimization 101: 5/24 San Diego, 6/14 Chicago, 6/28 Denver
- Hotsos Symposium 2005: March 6-10 Dallas
- Visit www.hotsos.com for schedule details...


-----Original Message-----
=46rom: oracle-l-bounce@xxxxxxxxxxxxx =3D
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Browett, Darren
Sent: Tuesday, May 11, 2004 9:39 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: 9i RAC or 10g RAC =3F

>From my experience, RAC performance is based on how well your
inter-connect can perform.=3D3D20
If it cannot handle the traffic then RAC performance will suffer.

Granted I had more then one database running on the servers, and the
servers
were older slower systems.

I remember somebody commenting on this list, if you want high
performance, go single
instance, if you want high availability, then go RAC.

Darren

-----Original Message-----
=46rom: Singh, Ratnesh (GEI, GEFA, Contractor)
[mailto:Ratnesh.Singh@xxxxxx]=3D3D20
Sent: Monday, May 10, 2004 2:39 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: 9i RAC or 10g RAC =3F


Better Performance is my main concern.=3D3D3D20
We intend to move our production database, which is currently 150 gig =3D
=3D3D
=3D3D3D
and is expected to grow to 500 gig in a year.

Business case for RAC is primarily $$ because Management wants to move =3D
=3D3D
=3D3D3D
all Solaris boxes to Redhat Linux.
Our current Solaris box is 12cpu, and target is 3 or 4 4-cpu linux boxes
=3D3D3D
cluster running RAC.
That also would be our first  step towards High Availability.

thanks & regards
ratnesh=3D3D3D20

-----Original Message-----
=46rom: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Mladen Gogala
Sent: Monday, May 10, 2004 5:26 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: 9i RAC or 10g RAC =3F


What do you consider advantage=3F What is your business case for RAC=3F
What do you plan to do with RAC=3F Stability of RAC on Linux is, from all
that I hear, very good, for both versions.=3D3D3D20

On 05/10/2004 05:20:04 PM, "Singh, Ratnesh (GEI, GEFA, Contractor)" =3D
=3D3D3D
wrote:
> Does 10g rac have significant improvements or new features as compared
=3D3D3D
=3D3D3D3D
> to 9i rac =3F
> Is 10g rac more stable than 9i rac =3F=3D3D3D3D20
--=3D3D3D20
Mladen Gogala
Oracle DBA



Note:
This message is for the named person's use only.  It may contain =3D3D3D
confidential, proprietary or legally privileged information.  No =3D3D3D
confidentiality or privilege is waived or lost by any mistransmission.
=3D3D3D
If you receive this message in error, please immediately delete it and =3D
=3D3D
=3D3D3D
all copies of it from your system, destroy any hard copies of it and =3D
=3D3D3D
notify the sender.  You must not, directly or indirectly, use, disclose,
=3D3D3D
distribute, print, or copy any part of this message if you are not the =3D
=3D3D
=3D3D3D
intended recipient. Wang Trading LLC and any of its subsidiaries each =3D
=3D3D
=3D3D3D
reserve the right to monitor all e-mail communications through its =3D3D3D
networks.
Any views expressed in this message are those of the individual sender,
=3D3D3D
except where the message states otherwise and the sender is authorized =3D
=3D3D
=3D3D3D
to state them to be the views of any such entity.

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
=46AQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
=46AQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
=46AQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
=46AQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
=46AQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------


______________________________________________________________________________
This email is intended solely for the person or entity to which it is addressed 
and may contain confidential and/or privileged information.  Copying, 
forwarding or distributing this message by persons or entities other than the 
addressee is prohibited. If you have received this email in error, please 
contact the sender immediately and delete the material from any computer.  This 
email may have been monitored for policy compliance.  [021216]

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: