http://qs321.pair.com?node_id=167889

The DBI module has a prepare_cached() method that is used heavily in some applications (in particular with Oracle), to streamline the client code. You can just call prepare_cached() with a query and if a statement handle with this query already exists it will be returned without the overhead of actually preparing the statement again.
This is great - but it doesn't work with Sybase, because of the limitation of one active statement handle per connection.

I ran into this problem last week - a fairly large Sybase database is being converted to Oracle, and the conversion script had a lot of prepare_cached() calls for two pretty simple queries which often return no rows. But this script is run in parallel (40 to 50 parallel sessions), and the total number of items to be converted is around 3-4 million or so.

What happened here is that the database server (running on a 12 processor E4500) started showing serious locking contention issues for the production code that is still running during the conversion. Hitting the server this hard with prepare() calls that include placeholders (which is more work than just executing a simple SQL statement) was causing excessive CPU usage, and the locking needed for the reqular processing was just taking a little longer to clear, causing everything to back up.

The solution: write two very small stored procedures, and call these instead. Now the server could handle 30-40 instances of the conversion script in addition to the normal work without noticing any difference.

To get back to prepare_cached() - I really understand its need, and I can see that an application would want to use it, but Sybase's support of placeholders is (maybe) somewhat limited in this respect. I'll try to find a way to cache statements effectively, but this may not be easy (and each cached statement means an open connection to the database), but in the meantime if you find yourself using prepare_cached() with Sybase consider writing a small stored procedure instead - it will be much faster.

Michael

Replies are listed 'Best First'.
Re: DBI prepare_cached and DBD::Sybase
by dws (Chancellor) on May 20, 2002 at 19:25 UTC
    I really understand [the need for prepare_cached()], and I can see that an application would want to use it, but Sybase's support of placeholders is (maybe) somewhat limited in this respect.

    Sometimes abstractions work great in theory, but suck for some edge cases. Trying to pretend that all databases support placeholders makes code much more portable, at the expense of suboptimal (or just plain terrible) performance when dealing with a database that doesn't support placeholders. Sybase, at least through the native DB*Lib API, doesn't support placeholders (I think this is true through CT*Lib, though that's years back, and I don't have that API at hand). To cope with this, the various abstract APIs (e.g., DBI, ODBC) that sit atop the native API have to pretend to prepare a query while in reality they're expanding the query and quoting bind variables at execute time.

[reply]
      The CTlib API supports placeholders (and I've even added that support to Sybase::CTlib).

      But the support is in the server - this means that some code examples given in the DBI man page fail miserably. In particular, perldoc DBI mentions that to include NULL values from placeholders in a WHERE clause you need to do something like this: 

      ... WHERE (product_code = ? OR (? IS NULL AND product_code IS NULL))

      [download]
      This will fail miserably with Sybase, because Sybase will attempt to find the datatype of each placeholder by matching it with a column. The ? is null doesn't map to any column name, so Sybase returns an error.

      Whether this is a behavior that is valid or not is maybe debatable, but the great advantage is that Sybase knows the datatype of each placeholder when you execute a prepared statement - no need to bind them with a specific datatype (and in fact using bind_param() with a datatype will ignore the hint).

      Cross-platform APIs are non-trivial, and cross-platform programming with databases is even more so because various forms of SQL syntax can have a huge impact on performance.

      Michael

[reply]
[d/l]
[select]

Back to Meditations