Wednesday, September 21, 2011

Oracle Database Appliance

I have spent the day on an oracle call, and reading all the subsequent tweets that follow.  I think the best way to describe the appliance is that it is NOT a mini-exadata, but it is a simple rac appliance.

My impression is that it is a nice product for the small to mid market, but those us working with the bigger toys I don't see the gain.

I know, I've spent more days than I care to remember schooling the SA's on how to set up an interconnect, and ensure that all the IP's are correct.  I've worked with Storage administrators on how to present the disks, and make them available to ASM, and I've worked with networking on the ranges of IP's I need for scan, interconnect, etc. etc.  I'm sure you get the picture.

I also think that people like me that work in a big organization and have a team to handle these tasks, are probably going huh ? what is this? 

Personally, I don't see the big deal in this.. I see lots of dissadvantages.

  • These Appliances cannot be clustered. What they have in them is all they will ever have in them.
  • The 2 database nodes have 96g of memory, not a lot in today server sizes..
  • There is no storage software like the exadata. No HCC, no offloading, no infiniband
  • This is local disk in the appliance, meaning no cloning, storage virtualization, etc.
  • The interconnect is 1ge, not infiniband.
  • You CANNOT hook up fiber to this server, ever.
  • It runs OEL, NOT redhat linux.. the differences are getting greater over time.
  • This is a closed system with specific patch sets that need to be maintained to a short list of acceptable patches.
I know for a small, to midsize, the ideal of creating a new rac system in 2 hours is thing of beauty, but for bigger companies, there isn't a lot there.

Especially without the Exadata candy filling (infiniband, HCC, offloading, storage indexes).

I still think virtualiation is the direction, and this is a step in the opposite direction.  There may be a few takers, but I think companies will realize that virtualization is a better direction than a single closed appliance.

We will see.. just some thoughts.


  1. I dont see the problem with the appliance running OL?
    What difference does it make that the differences between OL and RHEL might get bigger over time?

    If its built to run an Oracle product I'd say its a good thing that its not running RHEL..?
    Or maybe I just completely misunderstood your post..


  2. Peter,
    The problem I have from the beginning is that this isn't quite an appliance. An appliance is a complete closed system that you don't run anything else on (like netezza). This is a pre-built RAC system.
    The thing I don't like about OL, is for a lot of customers, this is not their standard, and standards rule. RHEL is more of a standard. It makes it difficult to ensure that all the monitoring/managaging/scheduling bloatware you put on a server runs with OL. RHEL is just easier as the ONLY linux OS.

    As far as the differences, OL is better than RHEL for an oracle workload, and that will continue as oracle customizes the Kernal. I know there is now 2 versions of OL (this was announced at openworld). I'm sure this split will continue.

    Yes, I would agree it's a good thing it's running OL and not RHEL, if you consider it a appliance. For those of us that consider it a RAC server to be added to our infrastructure, we want it to be standard. We don't want an appliance that offers nothing more than a standard cluster.

  3. Fair enough.

    Also, if you're already running RAC you probably wouldnt buy this thing anyway.