the expected result is that once i undef the $self->{dbo} variable, it would fall out of scope and the database connection would be implicitly released.
in practice this is not the case. it seams that once the variable has been undef'd it is left dangling in memory and not cleaned up.

What does DBI->trace reveal? That will show whether the underlying DBI handles are themselves actually destroyed or not. IIRC, the DBD::Oracle driver under high tracing will dump OCI calls -- so you should see DESTROYs followed by OCISessionEnd (I think) on successful implicit disconnects.

Is InactiveDestroy set to true on the DBI handles?

Does netstat/lsof/whatever confirm that your process has redundant DB connections open?

Your suspicion may be correct, but the symptoms are also consistent with at least a bug holding on to DBI handles, undesirable "Activeness" attributes, or a faulty proxy (circuit or DB-aware) between the daemon and the DB.