At first startup, the calendar_event query has a relatively reasonable explain plan. Oracle chooses this plan and it results in an execution time of around 114 ms. However, over time, this degrades to an execution time of several seconds. We observed this particular query gradually bubbling to the very top of our list in terms of execution time and resources.
Because these ranges are variable, over time, Oracle drifts away from the stable explain plan, and is unable to adapt, for some reason, by choosing better plans.
One of our developers decided to use bind variables instead, and this resulted in Oracle handling the query more efficiently. It forces Oracle to use a certain plan, regardless of the dynamic where clause.
I've created and attached a patch from our fix that will apply cleanly to sakai trunk (as of rev 116388 ) today.
Please also note, IU has been using this in production since November, and this patch completely fixed the issue described above.
Additionally, looking at the code changes, I don't see any reason why this would not also be better performance regardless what RDBMS an institution uses, and I certainly don't see this as being an Oracle-specific issue.