title: OID: Split install = Splitting Headache link: https://onemoretech.wordpress.com/2007/07/14/oid-split-install-splitting-headache/ author: lembobro description: post_id: 673 created: 2007/07/14 06:25:00 created_gmt: 2007/07/14 06:25:00 comment_status: open post_name: oid-split-install-splitting-headache status: publish post_type: post

OID: Split install = Splitting Headache

Alot of people who read this are going to disagree with what I’m about to say. But here it is.

When building an Oracle 10g AS infrastructure most enterprises will do a split install, putting the application server(s) on one box and the metadata repository (Oracle database) on another. In many cases the applications may even be split up, with Oracle Internet Directory (OID) running on one box, SSO another and so on.

This is insane.

OID is the foundation for any Oracle 10g infrastructure. If OID is down, you’re hosed.

Restart lsnrctl, or lose your connection with the database either because the db or it’s host is being recycled, or because of an errant firewall rule or some other network connectivity transient, and OID will go out to lunch.

As much as I admire and respect all DBA’s, in the six months I’ve worked with OID the only times it’s hung or toppled over is when, for some reason, the database sitting on a remote server became unavailable. Most of the time because the instance I needed was down and no one realized it’s significance. Actually, make that 2 months. Up until that time all the test installs I used had the database on the same host as the infrastructure and I made damn well sure it was up.

There’s nothing more disheartening that having to jump into a VNC session to demonstrate to an experienced DBA that the problem really is a database issue (tnsping is useless for this, the best method is to log on as the system user, make sure your environment is set and fire up sqlplus as ODS).

Many years ago I made a similar argument about locating Microsoft Active Directory database files on a SAN. Given that AD is the heart and soul of the server operating system itself, putting the edb files off on remote storage is clearly asking for trouble.

While using a remote db could have some benefits, like allowing for a high availability configuration such as multiple infrastructure servers connected to a RAC, given the critical place that OID has in the environment I still think it would be better to have the metadata db on the same box as OID. If the environment needs to be highly available, you can still RAC at the app tier or use OID’s robust multi-master replication feature.

Copyright 2004-2019 Phil Lembo