3

We are looking at a new environment to run our Oracle Database running on SUSE (potentially migrating to RedHat). Our database is approximately 100GB and performs adequately on our current hardware (x86_64) with approximately 6GB of ram allocated to it. We are growing quickly however and will require more performance shortly.

Given the cost of Oracle licenses we would like to maximize the value from each license by choosing the most appropriate CPU to run the software on.

The questions are:

Are there substantial benefits to looking at Itanium or Sparc hardware, are there any drawbacks? Is there a point where one starts to scale out better?

What are the long term support options for Itanium? Given the dominance of x86 would it be safer long term to stick with x86?

On average what would be the performance benefit of implementing an Oracle database on Itanium or Sparc over x86_64? Is this an issue at all or will other factors (IO/RAM) cap out first?

If anyone can point me towards some solid documentation on comparisons between the platforms that provides good case analysis of when to choose which I'm more than happy to accept that as an answer.

Edit:- Added Sparc as an Option as it was previously not considered however with the recent Oracle Sun aquisition seems very relevant.

Antitribu
  • 1,709
  • 3
  • 23
  • 37
  • 1
    my *gut* says with the acquisition of Sun, Oracle will push its flagship products on x86-64 far more than Itanium. But I have no hard data to back that up. – warren Apr 21 '10 at 14:49
  • 4
    according to the wikipedia article on Itanium, both Microsft and Red Hat are planning to drop support for the OS as of the next release (ie, RHEL5 and Windows 2008 will be the last editions to support IA64) - http://en.wikipedia.org/wiki/Itanium#Software_support – warren Apr 21 '10 at 14:51

4 Answers4

4

This isn’t the solid documentation you asked for, but it may aid in the decision-making process:

Vendors (both hardware and software) are phasing out support for Itanium across the board — you’re likely to struggle to be able to buy Itanium kit from anybody except HP fairly soon. That said, RedHat doesn’t have a habit of dropping support for a platform unilaterally without a lot of notice.

The big issue for me would be future migrations — if Itanium continues on the current trend, you may run into problems replacing or upgrading your server(s) a couple of years down the line (unless Intel starts supporting the IA64 instruction set on x86_64 processors in the meantime).

Whether Itanium as an architecture is an improvement upon x86_64 is going to be largely down to the nature of your workload, but for many database applications you’ll hit I/O bottlenecks and RAM starvation before the differences in architecture become particularly apparent (I don’t know if this would hold true in your case, obviously). As x86_64 is being developed pretty aggressively, the difference is going to be rapidly approaching zero depending on application.

Mo.
  • 2,166
  • 16
  • 9
  • 1
    http://www.theregister.co.uk/2009/12/18/redhat_rhel6_itanium_dead/ & http://blogs.technet.com/windowsserver/archive/2010/04/02/windows-server-2008-r2-to-phase-out-itanium.aspx – warren Apr 21 '10 at 14:56
  • these are pretty much my main fears. It feels like a dying platform and I can't help but get that Aplha CPU vibe from it. I don't want to bind out core services into heavy handed support arrangements for an extra fraction of performance. Anything that would prevent us from moving forward or staying current with software releases would be a non starter. – Antitribu Apr 21 '10 at 15:01
  • just to clarify, by “unilateral support” I did include security updates and the like there, though the fact that RedHat is dropping mainline support as of the next release would to me mean I’d need a pretty compelling reason to choose it as a platform for a new deployment running the OS. – Mo. Apr 21 '10 at 15:01
  • “Alpha CPU vibe” seems like a pretty good way to sum it up, yes! – Mo. Apr 21 '10 at 15:02
4
  • There was a time when people bought Itanium for performance - that time has passed.

  • There was until very recently a time when people bought Itanium for it's Reliability, Availability and Serviceability (RAS) features - the introduction of Intel's Xeon 75xx series means that for all but a fraction of a percent of server buyer that time has also passed.

  • As others have mentioned OS vendors are abandoning Itanium - HP, Itanium's biggest supporter, are backing away from the platform (don't expect their product managers to admit this though).

For all but a tiny number of legacy users Itanium's time has passed.

High-prices or not Oracle is a volume-oriented business so whilst they will always keep a foot in the high-performance/low-volume sector they are far more focussed on the x86/x64 market. Certainly they'll maintain code for a narrowing range of processors for years to come, just think of the maintenance contact margin! But their focus on these secondary platforms will wane, it's also not in Oracle's interest to plough more R&D investment into SPARC than they absolutely have to.

The future for business-critical DB servers is clear and only has two paths; commodity x64 (Xeon 56xx-series and AMD Magny-Cours are the CPU du jour) for 97-99% of the market where clustering will deliver 'five nines' for a relatviely low price, and Xeon 75xx-series for where 'zero nines' is the only option - everything else bar mainframe-level boxes will disappear.

Chopper3
  • 100,240
  • 9
  • 106
  • 238
  • I agree with most of your post. I have a bit of a problem with postitioning oracle database clustering (RAC) as a high availability solution (five nines). Clustering is a great solution for scalability and load-balancing. In the real world it takes a highly skilled team to improve availability. And beacause the rolling pacthes do not really exist pacthing a clustered database takes much more time. – Rob van Laarhoven Apr 22 '10 at 07:29
  • I bow to your superior knowledge on the matter, I do know that my Oracle guys manage 'five nines' from our various RACs however - maybe I drive them too hard :) – Chopper3 Apr 22 '10 at 08:34
  • Then it's my turn to bow to the skills of your oracle guys. – Rob van Laarhoven Apr 22 '10 at 14:31
3

I guess Itanium would be faster for a database system than x64 (x86-64) but as warren and Mo said before, it doesn't look good for Itanium support in the future.

Oracle probably wants you to go with SPARC soon.

So I'd say make a decision between x64 and SPARC, not between anything and Itanium.

Microsoft say Windows Server 2008 R2 will the be the last version of Windows to support Itanium, but will do so until 2018:

http://blogs.technet.com/windowsserver/archive/2010/04/02/windows-server-2008-r2-to-phase-out-itanium.aspx

However, I do remember that Windows dropped support for MIPS and PowerPC quite suddenly in 1997.

Andrew J. Brehm
  • 1,611
  • 7
  • 34
  • 57
  • Interesting point though trickier to implement with our current vendors it is definitely another option. – Antitribu Apr 21 '10 at 15:06
  • I keep reading that SPARC scales better than other architectures. Are you going for a multi-server setup? Of course, with SPARC you would want Solaris rather than Linux. But then SPARC CPUs are slower per CPU than x64 chips... – Andrew J. Brehm Apr 22 '10 at 08:47
1

The key point on what to use is depending on your system footprint an requirements, plus of course your inhouse skills.

Speaking genererally from Oracle technical archtict / dba view, you will be facing yourself the following questions:

  1. How much overhead do I want to have on support?

You naturally will have worse reaction times on non-Oracle platforms, like specially IBM Pseries as well as HP Itanium (due to historical reasons)

  1. What Service do I need provide and which technologies do I want to use?

Generally you shouldn't mix things having the same purpose like eg. RAC and virtualization, as this increases layers and eventually Cost.

You can nowerdays do great things with eg. Oracle VM (Xen) on x86-64 and Oracle Dataguard (eventually with Active Dataguard Option). Keep it simple and focused

RAC is for most companies too complicated to manage, as mostly it is not properly implemented. Also it only protects you against host failures => you still have the shared storage to be taken care of.

As most RAC installations iv'e seen in the past 10 years are based on "conventional wisdom", they are mainly 2 node clusters. Reason is simple: License Cost / Habits

So more simpler and valueable combination is too use Oracle VM for HA, which enables you to even do live migration of hosts in maintenance windows plus Oracle Dataguard for site failures. As you Dataguard you can offload backups to standby site to not bother users.

This is just one example, which works well for 11g OLTP Databases, put can also be applicated to DW Databases, if you take more care about availability than performance.

Reading Concepts Guide at Oracle, will certainly point you to a solutions that works for you.

When planning with virtualization technologies you should also consider not to consolidate too much into too little machines. You won't like to find yourself in situation, where you consolidated everything in 2 big fat enterprise level machines and the suddenly one breaks, which makes you loose 50% of your total capacity. Rather go for more, put smaller servers for multiple reasons:

  • Capacity on demand on big IBM, HP, SUN machines sounds good at first, but it turns out to be quite expensive after a few years, if you need to buy old RAM modules

  • At some extend you still need to shut down even those boxes and phyiscally upgrade anyway

  • If you really have technical problems with one server, you still have the other ones and you have more time with less performance & customer impact to replace the faulty one

  • As said as dba normally you have to deal more with bad application bugs, i/o contention, network issues. For I/O contention it does not make a big difference wheither you wait with a 4.7Ghz IBM Power 6 or a Intel 1.6 Ghz Itanium for I/O. You cannot wait faster. In such case you rather invest into a PCI-E SSD, if you really cannot handle the hot data block by re-design / tune the Application.