Insane DBA...

Cursordump is the way to go. I’ve moved my blog from https://insanedba.blogspot.com to https://dincosman.com Please update your bookmarks and follow/subscribe at the new address for all the latest updates and content. More up-to-date content of this post may be available there. Parse failures are actually not stored in the data dictionary and therefore cannot be identified through querying the data dictionary. As of Oracle 10g, event 10035 can be used to report all failed parses.   With the 19.16 Release Update, Oracle does not record SQL statements to alert.log. Any statement that fails at the parsing stage is recorded with the error number and the process OSPID. Also, setting the hidden "_kks_parse_error_warning" parameter to 1 does not help report ...

 Too many parse errors - how much do you mean? I’ve moved my blog from https://insanedba.blogspot.com to https://dincosman.com Please update your bookmarks and follow/subscribe at the new address for all the latest updates and content. More up-to-date content of this post may be available there. SQL syntax errors are always normal and commonly dealing with them is up to software developers.  But sometimes, they might bother database administrators too. When an SQL statement is syntactically (e.g., syntax error) or semantically (e.g., projection of a nonexistent column) incorrect, its processing fails at parsing stage and it never gets executed. If that happens too often, it can have a negative impact on overall database performance. With the 12.2 release, these failing SQL statements are recorded in alert.log as below if they are called excessively. In the above example, the "SELECT DU...