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 -- //www.freelists.org/webpage/oracle-l -- //www.freelists.org/webpage/oracle-l