New Content

I’ve been prodded to add new content — and I thought no one cared :-)

Ok, here’s an old topic that got new life for me the other day, based on request to start an extproc listener.  We upgraded some vendor software the other day and their upgrade introduced a requirement for us to have one.

The older software used to use Java stored procedures and the internal database JVM in order to make calls out to another server to perform encryption functions.  Apparently the vendor came to the conclusion that the Java stored procs were too slow and they’ve moved to using essentially an external DLL for the same call-out functions.  I wonder whether or not they benchmarked the external DLL vs. Java before their initial development or if they just picked the Java stored procs because it was cool at the time :-)  I see a lot of this nowadays — people who use some more advanced database feature just because it’s there instead of checking to see if it’s the best way to do things.

Heck, you could probably write your own multi-processing O/S inside of the DB if you wanted to, given how rich the feature set is today.  Back when I started with Oracle, you had to write your own code uphill, both ways! :-)  None of these fancy helper functions and supplied stored procs.

Anyway, back to the topic…  An old, old idea of mine that’s been rattling around for a long time is to attempt to make the Oracle s/w directory read-only.  At one time I had this idea that you would install the s/w on a central server, and then mount it where you needed it.  In order to do this effectively, I wanted to see if you could make it read-only.

We got part of the way there with OFA.  And I’ve even found a stub draft of an article on one of my old backups about adapting OFA for the TNS listener — but it never saw the light of day.

As OFA has started to show its age, it’s been difficult for some people to articulate why they don’t like it and how to extend / improve it.  One of it’s problems is a simplistic assumption that the only s/w on the database server is the database software.  Hence the product and admin directories somewhat ignore things like app servers and/or the semi-independence of the TNS listener.  I sometimes wish we had defined OFA to have another level under product and admin — you can kind of see it coming under product.  Here on my PC I have product/10.2.0/client_1 and product/10.2.0/httpd.  I’m guessing I’d have something like product/10.2.0/db_1 if I installed the database software. 

I really think it would be useful under admin as well — admin/db/[SID] and admin/network/[listener_name].  Maybe I’ll start trying to move rdbms/network outside of the s/w tree a bit — heck, I’ve got to play with the listener stuff anyway…