RE: Considerations to choose SUN server for Oracle

Kevin Closson supplied workload throughput equivalences a few minutes after
this message came through. And this is also a very nice logical take on the
whole evaluation. But I want to add one thing:

Under f), where you are considering data center facilities, it has become
increasingly important to check the rating of load per unit square that your
raised floor can support. No one is happy about it when the new computer
breaks the floor, tears up the under the floor cabling, and the young's
modulus deceleration of the computer with the underlying concrete
compromises the integrity of the new computer.

Experience shows this is an easy thing to omit from the facilities readiness
analysis for computers, UPS units, and disk storage arrays.

mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of David Robillard
Sent: Friday, August 27, 2010 11:46 AM
To: Denis
Cc: oracle-l digest users
Subject: Re: Considerations to choose SUN server for Oracle

Hello Yu (Denis),

> Hi, listers,
> Currently we have a Sun-Fire-15000  16CPUs  64 GB RAM, we need to move db
to
> another data center and thus is allowed to propose to buy a new server
with
> double compacity probably. I am wondering what type of Sun Server we can
> consider? T5440 or E25K? what kind of considerations are there?
>
> Yu (Denis) Sun

At my other job (in 2004) we used to run our Oracle 10g SAP databases
on five E25K. It handled 220 000 users and things were fine.
But the E25K has now been replaced by the M series. I think the E12K
is now the E8000 and the E25K is now the M9000 one (not sure, check
with your Oracle rep).

There are a lot of things to consider before you make a purchase.

a) Human resources. Or your internal staff knowledge in terms Operating
System.

If you have a complete staff of Solaris experts, then I would suggest
to keep Solaris. The transition from a know and well documented OS to
a new one is full of surprises, not always good ones. Plus you have to
revisit all your documentation which is a time consuming job. In 12
years of UNIX systems administration, I've had to manage Solaris, AIX,
HP-UX and numerous other Linux distributions. If you do decide to
change the OS, then I can say that the transition from Solaris to
RedHat Linux is IMHO the easiest. Don't move to AIX. Not that it's a
bad OS -it's very good- but it's also *very* different from Solaris.

b) Data center OS install base.

What is the dominant OS in your data center? If you have, say, 1000
servers all running Solaris. Then, again, keep that OS. If you have a
heterogenous environment, then check which OS you have your most
critical applications and which one is best understood and best
documented by your team and keep that one.

Note that you also want an OS that is on Oracle's first tier. For
example, Solaris x86 patches are available *after* Solaris SPARC, AIX
on POWER, RedHat Linux and Windows. But that may change with the
acquisition of Sun by Oracle.

c) Your Service Level Aggreements (SLA).

Do you have some SLA in place that say you have to move X amount of
data in Y time? For example, do you need to restore an enormous
database in a maximum of two hours? We used E25K systems because it
was, at the time, the only machine that could push the amount of data
in time required by our the SLA.

Also, in the SLA, check if you can survive a hardware failure and keep
going. Machines like the M series are hot-swap CPU, giving you a very
high level of service. On the other hand, Oracle RAC on small x86
machines can also give you the same amount of service.

d) Budget.

Of course, check how much money you have in this project. That
sometimes eliminates a few avenues right there and now.

e) Quality of technical support.

Check your partner's support services. Dell support is
*h.o.r.r.i.b.l.e* (in Canada at least, YMMV). You want a tried, tested
and true support plan from the likes of Oracle, IBM or HP. When the
s**t hits the fan, you don't want someone telling you it's not
supported or "leave a message after the beep" kind of support.

Also, beware of finger pointing. If your database is running on one
vendor, the storage comes from another one and the SAN switches come
from yet another one, you can be exposed to finger pointing. You don't
want that. So make sure you use only supported configurations.

f) Data center power, cooling, UPS and physical space.

Make sure your new systems fit with what's available in your data
center. If you buy new machines and find out that you need to purchase
a bigger cooling system and upgrade your electrical grid because of
them, it's going to add a very significant cost to your project.

g) Install base.

Check other channels (like this mailing list :) to see what other
people in the field are doing. That is, don't trust all what the
vendors tell you!

h) Tools.

Check your backup and recovery tools. Check your management tools.
Check your monitoring tools. Do they all work with your new setup?
Learning new tools is error prone and time consuming.

That being said, if you can afford them, the M series will keep you in
a relatively identical environment that you currently have. You may
want to check Oracle Exadata v2 as it appears to deliver. You could
also look into running Oracle RAC on top of Oracle x86 machines so
that you have single vendor to talk to. Keep in mind that both Exadata
and RAC will require your staff to learn either Oracle Linux or RedHat
Linux (which are basically the same anyway).

FWIW, we are now moving from a single instance Oracle 9iR2 on Solaris
SPARC with Oracle Application Server 10g to Oracle 11gR2 RAC on RedHat
5 x86_64 on Sun X4170 machines with Oracle Fusion Middleware also on
RH 5 x86_64 on Sun X4170 machines. So far, so good. But the tools,
documentation and testing is quite a long process.

Good luck, this looks like a fun project!

David
--
http://www.freelists.org/webpage/oracle-l




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


Other related posts: