Initially i started reviewing the performance data from Enterprise Manager which led me to the point where i now believe the 'row cache locks' are the source of the slowness that their users are seeing.

After googling and trying to find out what to do about this newfound (possibly incorrect knowledge), i came across a set of sql statements to determine what's causing the row cache locks....but that's kind of where i'm stuck.

First of all, our system and our client's systems were both recently upgraded from 9 to 11. We run the same applications as well. We upgraded our system first, and while we came across several little snags early that we worked through, our system is now very stable. Our client was upgraded the last week of February and experienced no issues for nearly 2 weeks. Early this week, they began complaining that some apps would randomly take much longer to process than usual. And it wasn't reproducible. The app would run perfectly 9 times out of 10, but that one time, the app would take sometimes 5 times longer.

I opened Enterprise Manager and looked at the performance graphs, and noticed quite a few spikes in the Concurrency data. I can't really tell the google and thought path that got me from that data to 'row cache lock', so I very well could've just jumped to an invalid conclusion.

I can't really tell the google and thought path that got me from that data to 'row cache lock'

So you can also assume this is not the point and start to search what is the real concurrency issue.
This is the first point to determine, which kind of concurrency issue have you?
You have the AWR data, we have not.

And do not trust all scripts you find on the web, first try to understand them and be sure they are accurate.

"In order for DDL to execute, it must acquire a row cache lock to lock the Data Dictionary information."WHY? is application doing DDL so frequently?
I contend application only does DDL during application version upgrades during maintenance window.

"In order for DDL to execute, it must acquire a row cache lock to lock the Data Dictionary information."WHY? is application doing DDL so frequently?
I contend application only does DDL during application version upgrades during maintenance window.

One of the issues we have is our client likes to develop their own apps to supplement their business, and we end up supporting them.

Is there a way for me to find out exactly what these DDL's that are being called so frequently are?

"The "row cache" is an area in Oracle's shared pool that keeps data dictionary information in memory. The "row cache" lock prevents two sessions from updating the same information in the row cache simultaneously.
Most of the time, row cache updates are infrequent since data dictionary information is fairly static. However, if row cache information is being updated frequently then contention for the row cache lock can occur.

One scenario that can cause row cache contention is rapid sequence number generation from a sequence with an insufficient CACHE value. By default, sequences only cache 20 numbers. Every time the cache is exhausted, Oracle needs to update the row cache to get the next set of numbers. If sequence numbers are being allocated very rapidly then row cache lock waits might become serious.
"

Just for everyone's knowledge. I ended up entering a SR with Oracle to track this down.

Oracle has confirmed that due to an existing bug in 11.2.0.1, described in doc 1162566.1.

It looks like the issue occurs when there is a logon atempt that fails (not necessarily for this process), which required a row cache lock in order to modify the user data.

We found a lot of "custom" client apps that we had nothing to do with, had invalid logins, so we're pretty confident at this point that that was the actual cause of the issue. We're having our client go through and resolve these invalid logins.