Optimizations to Rails on Oracle: bind variable support and prefetching

For interoperability with existing data, we run Rails with Oracle. However, Rails doesn't support bind variables with Oracle, which are critical for achieving good performance at high scale.

Can anyone say ActiveRecord will support bind variables on Oracle?

In the meanwhile, my coworker Ray Fortna has developed fairly clean workaround; there is a session setting in Oracle which will cause Oracle to automatically turn all literals into bind variables. This is not optimal since it can lead to overbinding, but in the majority of apps it is a significant improvement, and applying this at the DB level makes it very low risk in terms of correctness. (For us, it cut the CPU usage to 1/3 of the previous value.)

The following code updates the Oracle connection class to set cursor sharing to force in the session, which converts literals to bind variables.

PhilBo wrote:

Can anyone say ActiveRecord will support bind variables on Oracle?

Yes. I've gotten it working for insert/update, still working on select.

The following code updates the Oracle connection class to set cursor sharing to force in the session, which converts literals to bind variables.

I've had more success using the "SIMILAR" option, rather than "FORCE".

A second significant optimization we've applied has been to set the Oracle driver to more aggressively prefetch rows.

Have you quantified the impact of this?

Can you sketch the approach being taken to support bind variables in ActiveRecord?

Yes, I can get you the quantification of the more aggressive prefetching in our application; it was significant. I will post that tomorrow.

PhilBo wrote:

Can you sketch the approach being taken to support bind variables in ActiveRecord?

At a high level it's to keep the sql represented as an array of sql text and bind values, and pass that array to the connection adapter for binding, rather than binding it in AR and passing a sql string. For those adapters that can handle that.

It was pretty straightforward to do for inserts and updates, much harder for selects since the sql is being constructed and bound all over the place.

Yes, I can get you the quantification of the more aggressive prefetching in our application; it was significant. I will post that tomorrow.

Thanks.

Michael A. Schoen wrote:

PhilBo wrote:

Can you sketch the approach being taken to support bind variables in ActiveRecord?

At a high level it's to keep the sql represented as an array of sql text and bind values, and pass that array to the connection adapter for binding, rather than binding it in AR and passing a sql string. For those adapters that can handle that.

It was pretty straightforward to do for inserts and updates, much harder for selects since the sql is being constructed and bound all over the place.

I may have time to help (and I'd be interested to see better support for Oracle bind variables), just let me know how i can help (may you post your patches?)

bye Luca Mearelli

PhilBo wrote:

Yes, I can get you the quantification of the more aggressive prefetching in our application; it was significant. I will post that tomorrow.

Played w/ this some, and for many-row extracts, I'm also seeing huge improvements.

I've got a cleaner implementation that leverages the fact that the OCI8 lib exposes prefetch_rows at the connection level. Also will allow folks to set prefetch_rows directly in their database.yml file.

I'll post it to the Trac server tonight, along with some benchmark results. I'm running some more data now, at the moment it appears that 100 is a good value -- higher seems to have only slight benefit for large extracts, and actually hurts small queries.

Michael A. Schoen wrote:

PhilBo wrote: I'll post it to the Trac server tonight, along with some benchmark results. I'm running some more data now, at the moment it appears that 100 is a good value -- higher seems to have only slight benefit for large extracts, and actually hurts small queries.

  http://dev.rubyonrails.org/ticket/6607

On the bind variables fix, would it be possible to reduce the scope of changes required by having sanitize_sql return a subclass of string that preserves binding information for drivers that know how to interpret that info?

BindVariablesString#unbound_string would return the original query with bind variables intact, and BindVariablesString#bind_variables_array would return the bind variables themselves.

The value of BindVariablesString would be the string after replacement of bind variables with literals, just as it is now, so drivers that don't know about the extended behavior wouldn't need any changes.

This is just a though, I haven't traced through the code enough to be certain that the BindVariablesString would be passed through intact through all the layers of code (perhaps ActiveRecord creates a new string for instance, losing the bind variables).