Hello AskTom team,
Can you please help with an architectural issue that we are facing as a result of movement to Exadata? Pasted below is the scenario and our question.
Thanks for all the good work you are doing.
We call a C library from Oracle DB using external procedure call. This library (client) talks with a daemon (server) running on the DB server. Calls to the C library complete quickly (in micro seconds) and the library will be heavily (millions of times) invoked from SQL / PL/SQL, in a row by row fashion. Due to some restrictions, we can not move the logic of C code inside DB.
This works fine in our standalone DB servers. However, we now have to move to Exadata and our Exadata team does not allow to keep any "non-Oracle" file on the servers. This includes the C library as well as the server C code.
We are trying to figure out what would be an apt location to move the library and the server code. We have considered multiple options like: 1) Create a RESTful service and invoke it instead of the C code, 2) Host the C code on a non-ExaCC DB server and call it via DB Link. However, as soon as we move the C code from the DB server, microseconds turns in to milliseconds, primarily because of communication over network.
Any idea, what other options we can explore ?
and Connor said...
I spoke to some of our Exa CC people - they replied
While we recommend to not install additional software on servers (as especially additional RPMs will affect OS patching/upgrade), it never says anywhere you are not allowed to install additional software….
One option you could consider is using a docker container for additional software, as this does not interfere with the OS updates then… See: Decoupling RPM Dependencies, running Oracle R Distribution (ORD) on Exadata Database Nodes in Docker (Doc ID 2257680.1)
If this is the case, you may want to put the software onto an ACFS folder, to have a common location across the cluster (and not to worry to have to update each node individually).