Since joining forces with Enkitec, I’ve managed to stay blissfully unaware of some of the things that they’re best known for. Namely being top of the food chain when it comes to knowing what’s what about Exadata.
However, that’s about to change!
A couple of the larger clients we worked with while we were still Sumneva have become so successful that they’re working to migrate their systems, including their APEX applications, to Exadata platforms.
Now this in itself isn’t a big deal. We all know that APEX runs inside the database and that it doesn’t care what the underlying hardware platform is. Exadata machines run Oracle, so it’s a no-brainer really.
The fun comes in when you start to think about the Exadata Secret Sauce, which in a nut shell has everything to do with the storage nodes and very little to do with the server nodes running the database. Those storage nodes are what provide the extreme speed and scalability to the Exadata platform and therefore anything that runs on them.
Understanding the underpinnings and how they can be used to help system performance can be extremely useful when taking a system that runs in a traditional oracle environment and migrating them to Exadata. Since most people are running APEX in a traditional environment, the data structures and queries have been written based on that knowledge.
And so starts my education about the technology behind Exadata and how differently (if at all) things need to be done in terms of database and query structure.
Along the way we’re looking at writing a few tools/products that are aimed squarely at the Exadata world, covering things from sizing to migration to performance and beyond.
I’ll be sharing what I learn about Exadata with regards to its relation to APEX et al as I move forward.