• September 10, 2014

Build Your Own Exadata? Questions that make you go Hmmmm..... #2 (Part 1)

Guest Author
So, I've been told on occasion "Hey, this Exadata stuff is expensive! I've just costed out my own Exadata Killer and it's like a quarter of the price. I'm just going to build my own!"

Yeah - right. I had the ability to participate in a discussion about this and I postulated a lot of things that I don't think that people who throw out the "Build my own" argument ever consider. Let me share my thoughts with you about this. I'm going to chop this up into three parts over the next week or so.

Here are the thoughts I expressed:

I’m sure at one time or another we have heard someone speculate about their ability to build their own. Often their off the top of their head cost model is based on some quick pricing of various components. This is typical of technowizard types who think that something like an engineered system is just some marketing hype. They have not taken the time to really understand what it is, because they are so wrapped up in their own technical point-of-view that can’t possibly be wrong.

Because they are often technical types, they often don’t consider the non-technical costs more often than not they are not database people in the first place they are pure hardware people who probably lust at the idea of creating an Exadata beater .. budget? meh... who cares about overall costs and that they will fail in the end.

I rather think that you could produce a detailed cost estimate comparing the two and find that Exadata is by and far the cheaper solution. Things I’d consider in my overall cost analysis:

1. Cost of *comparable* hardware as already pointed out in this thread.

2. Costs for differential memory requirements due to lack of cell offload. Thus they will require more memory for SGA than an equivalent Exadata database will.

3. Costs for additional Flash than would be in an Exadata box. This is because their flash will be flushed during backups and will not intelligently store blocks like smart flash cache will. Thus, their flash performance will be less impressive.

4. Time related and other costs required to initially standup and online the architecture they propose. I am assuming that they had not considered these significant costs.

a. Time spent in initial architectural decision making (ie: how much disk, speed of CPU’s, etc)

b. Time spent to ensure that the architecture will actually be supported by the different vendors.

c. Time spent determining how to connect everything together correctly with fully redundant pathing (as mentioned already in this thread).

d. Time spent determining if components selected are certified to work with each other and are compatible with Oracle RAC.

e. Time spent ordering components. Time spent reordering incorrectly ordered components.

f. Time spent installing the components.

g. Time spent configuring the components.

h. Time spent installing Oracle CW, ASM and RAC. Configuring disk groups, etc.

i. Time spent talking to Oracle support to solve problems while trying to perform item h.

j. Time spent troubleshooting configuration issues (can be HUGE)

k. Time spent trying to figure out why your RAC nodes fence all the time (because something is miss-configured or not compatible that you didn’t find until now).

l. Time reconfiguring things so it will work.

m. Money required for additional components you didn’t order or architect that you later realize you needed to provide HA.

n. Time spent in meetings explaining why you are behind schedule and trying to justify why your project has already cost upwards of 70% of the cost of an Exadata machine, fully installed and operational.

o. Time spent because the old system is not able to be moved in the time frames required, which caused certain unexpected expenses such as extension of support contracts (I’ve seen this happen more than once).

p. Costs related to stake holder discomfort with the stability of the system you are standing up.

q. Costs related to standing up a backup infrastructure that will support the large amounts of data that you will need to backup (remember – incremental backups are offloaded to the cells – so they won’t get this benefit).

r. Costs related to multi-vendor calls for support as you attempt to standup the system.

s. Costs for additional equipment needed to provide for quick failed part replacements.

t. Costs for RandR of failed equipment. Cost of loss productivity due to resource being required for RandR of equipment.

u. Costs to customize database parameters for this hardware configuration.

v. Cost of not being able to use Exadata related features such as HCC, DBRM and IO Resource Manager as available on Exadata.

w. Costs to integrate the database server you are creating with the application servers.

i. Cost of providing Infiniband connectivity

ii. Cost of slower applications running on non-exalogic hardware.

iii. Cost of slower application responses since database performance will likely be slower than with Exadata.

x. Costs to properly decide where on the disks to best physically locate disk groups and how to allocate those disk groups properly.

y. Costs of lack of a community that has equipment similar to yours. Little or no peer feedback to questions or issues. Smaller information base on your configuration which makes problem research times longer – perhaps significantly longer.

z. Costs of having normal Oracle support rather than that offered to Exadata customers. Cost of paying for Oracle support and paying for all other vendor support contracts.

aa. Cost of labor scale as you will need to hire more SME’s to manage this environment – especially if it scales out.

Next post will be on the costs of operations and Other ongoing cost considerations.


Note: Edited due to some formatting issues and a *gasp* spelling error.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.