We use DBD::Oracle a lot in our current project but unlike many people we execute no SQL from Perl at all. What we do is write all the PL/SQL into procedures, wrap the procedures in packages and use definer rights on the package. In this way the user we login to the database as has no rights to select/insert/update/delete via SQL in Perl but can do all of those things from procedures in packages.
We also use application errors in Oracle i.e., we use the error number space -20000 to -20999 (reserved for applications by Oracle) to raise (RAISE_APPLICATION_ERROR) errors in our procedures. This has a disadvantage when using DBI and DBIx::Log4perl in that all errors in DBI call the HandleError sub DBIx::Log4perl registers with DBI which logs in the Log::Log4perl error state everything DBIx::Log4perl can find out about the state we were in when the error was registered (i.e., stack dump, SQL executing, bound parameters etc). This wouldn't be a problem normally except that some of the application errors we raise are expected e.g., your web session has expired. We don't want these expected errors logged by DBIx::Log4perl, we want real errors (the ones we didn't expect) logged as errors.
To facilitate this I've added the DBIx_l4p_ignore_err_regexp attribute to DBIx::Log4perl. This is a regular expression which is matched against the error number passed to the HandleError method and execute methods and if a match is made, nothing is logged.
Some time ago, we divided the Oracle reserved application error space into, internal errors (-20000 to -20499, errors where we will return the number to the outside application but no error text as they are internal and wholly unexpected), errors we are prepared to get to the outside applications (-20500 to -20899) and informational errors (-20900 to -20999, errors we expect to happen e.g., session expired). By setting DBIx_l4p_ignore_err_regexp to '20[5-9]\d\d' in DBIx::Log4perl, all the errors in the range -20500 to -20999 are ignored and not reported. Problem sorted.