OID problem? Check those tablespaces!

I’ve been over this before. When it comes to Oracle Internet Directory (OID) the relational database backend can be a real Achilles Heel. In today’s edition of “Whose bright idea was it to make an LDAP directory dependent on an RDBMS?”: how running out of table space can keep your directory server from starting — or properly processing changes like EBS (E-Business Suite) integration.


For several weeks I’ve been struggling with a recalcitrant OID instance that refused to register an EBS node. This followed one of those EBS clone fests that are typical around here. Even opened one of the longest running SR’s with Oracle in my experience.

Then, as part of an unrelated maintenance routine the box hosting this OID had to be rebooted. After the host came back up OID refused to start.

I went through the usual troubleshooting checklist. Looked at one of my own posts. Also scanned related articles on Oracle Support and our friends at OnlineAppsDBA. Looked in Atul’s book. Checked to make sure I could get to the database as the ODS user with sqlplus from the box. I even yelled at my favorite DBA. No joy.

Then I remembered my past experiences with OID misbehaving due to the database running out of space.

So I went back in as ODS using sqlplus and ran V.S. Babu’s trusty tablespaces.sql script.

Voila! OLTS_CT_STORE (which stores Catalog tables for fast lookups — what we in the once independent BerkeleyDB-centric LDAP community call indexes) was 99.3% full.

Once my DBA friend extended that tablespace (autoextend wasn’t turned on) we were in like flint and OID started right up. It took no more than two seconds for the DBA to ask if he could re-run OID registration against the related EBS node. Great minds think alike. With my blessing he did, and registration was successful.

Life is good.