• September 12, 2014

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

Guest Author

This is part two in my post about designing your own "Exadata Killer" vs. Buying Exadata. In this post I postulate several operational related costs that are not considered when building out your own Exadata like infrastructure. This post is a copy of an discussion I had on this topic a few days ago and I thought it might be worth posting:

Then there are the operational costs that are not being considered:

a. Cost to patch and upgrade the entire infrastructure on a regular basis (Quarterly). This includes:

i. Resource cost to be constantly in a patching mode.

ii. Cost/risk if opting to not patch on a regular basis.

iii. Time required to completely check all vendors to make sure you have the most current patches to apply. This includes any applicable bug fixes.

iv. Deciding what patches need to be applied.

v. Significant time testing the patches before applying them to ensure compatibility and certify.

vi. Costs of troubleshooting and support with various vendors. Tracking down bugs. Waiting for fixes. Etc.

vii. Deciding what other bug patches need to be applied to the patches you are applying.

viii. Assessing the impact of all patches on all components.

ix. Dealing with incompatible patches that you were told were compatible.

x. Not being able to easily rollback patches.

xi. Not having readily available scripts to perform many patching activities.

b. Cost of not having a single tool (Exacheck) to ensure your entire infrastructure is healthy and that it is meeting specific best practices. Also the cost of not being able to determine if your database needs to have critical patches installed on it that impact HA.

c. Lack of specific integration between Cloud Control and Your system. You have to manually configure the various monitors and alerts.

d. Costs of not having access to tools like cellcli that provide performance information to Cloud Control and via the command line.

e. Costs of not having a readily available, time reliable (relative) upgrade path available. If you want to expand the system then just repeat all costs from item number 4 times a multiple of about 1.5 to 2.0 to reflect that you are now dealing with a production system and testing and stability are now really key.

f. Costs of performance tuning queries that still don’t perform well, even on the souped up hardware.

g. Differential costs of power, cooling and space.


In part three I'll conclude my thoughts on Exadata "Killers" and why you just can't build your own. Later, I'll address my thoughts on why these vendor supplied Exadata "Killers" just can't hit the mark.

Note: Edited for content and formatting.

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.