I think Timur has answered your question about using the “pseudo” hint.

There was a problem in some older versions of Oracle where pl/sql lost the hints if you failed to leave a space between the “+” and the first word of the hint, though; and I think there was a more recent (but still pre-10g) version of one of the ODBC or JDBC drivers that managed to strip hints out of code in transit.

I like Piet’s point further down – OK, so it was generating lots of hard parses, but was it causing an impact to the business? Was there a gain by fixing it? I suspect yes, but Piet’s question is perhaps the core of “Why to Tune”.

Moha’s point was very good. I like that.

Housekeeping code – particularly code for partition maintenance – could reasonably loop through DDL: I’ve event implemented that type of thing myself.

If Dynamic-SQL or parsing seems a problem, I tend to look for nr of statements using the same plan to spot possible problem-stmnts. I suspect (nearly) all stmnts had the same plan, but did they ?
And you mention the relatively high number of 30 stmnts in 60 seconds and “causing hard parse on every statement”. But was parsing (or CPU usage, or shared-pool) acutally a problem on this system ?

Well, it’s not a rule.

I’m working in a project where we must create table partitions or “swap tables” on the fly so we have many loops where you can see “add partitions” or “create tables”.

It’s the only way to do it because partitions and “swap tables” depends on data (i.e. we have things like “partition by sysdate”)

So a DDL in a loop can be OK.

Bye,
Antonio

My question was deliberately a little vague and open-ended because I didn’t want to push people in any particular direction – I just wanted them to prompt their imagination.

Before I tell you the idea I had to justify this odd pattern, I’ll just commment on a few of the suggestions.

First the people who tried to explain the phenomenont:

Ceninual (#1) and others: when I pointed this out to the on-site DBA, his comment was: “It looks like they’re using the customer ID as the name of the bind variable.” So full marks for good guesswork – and Dave’s comment (#3) helps to explain why it sounds like a nice idea – but this isn’t a reasonable justification for what they’ve done, and in this case the developers need a proper explanation of why bind variables are important.

Charles’ comment (#4) is worth a mention because it is possible that some programming enviroment could be responsible for an unexpected and undeirable pattern of behaviour – and Joel’s follow-up in #5 is an interesting extension of that thought, does the process ID appear in the bind variable somehow … the “multiple schema” idea appearing in a later post also ties in here, as it might be one variable name per schema. (But it’s not a pl/sql thing – a couple of the other comments reminds us that pl/sql turns variable names into :Bnnn, where the nnn represents a numeric value).

I’m going to pick up mwidlake for an error – because we often learn from other people’s mistakes. If two pieces of SQL look different they will appear in the library cache (x$kglob) as different parent objects, and different parents will have different children. So if the texts look the same apart from the “:v_NNNNNN” then each text is a different parent with a child holding the execution plan.

Chen (#2): again a possibility – DDL inside the loop – but a little unlikely and not a good justification for what’s going on. If DDL in the loop is actually happening in production it’s definitely an error [but see comment #18] that should be corrected. (Although global temporary tables could be an exception, and did produce some catastrophic effects in earlier versionsof Oracle). A table name of customers makes DDL a little unlikely though.

A throwaway comment about primary keys and histograms – depending on the nature of the key and the queries, a histogram can be relevant to a PK if the values have an odd distribution, even if the frequencies do not. In this case, though, the nature of the query (customer by ID) seems to suggest that there is no intention of avoiding problems of data skew.

There was some discussion about different technologies, or function features, and their effects on how cursor caching and library cache contention may be affected – this type of discussion is important and Oracle has changed all sorts of details of cursor caching and cursor pinning over the versions from 8i to 10g, so it’s always worth testing your old coding ideas each time you start a new project.

Finally we come to the thought I had – and it’s very close to the idea from Moha (#11) about deliberately making identical queries look (slightly) different to avoid library cache latch contention.

The client has 32 web application servers addressing a single database. If this is a very popular query then the single library cache latch protecting a totally sharable query could get hammered and be the focus of a lot of library cache latch contention. In the past when I’ve seen this happening I’ve advised clients to introduce a mechanism that makes each application server use “different” SQL by creating SQL that includes a “hint” like: /*+ from WAS 23 */

Could it be that this client had done the same sort of thing – but made the SQL look different by generating variable names that were dependent in some way on the identity of the Web application server sending in the query ?

(In this case the answer was no – because every single query was executed just once, and they really were using the input value as the name of the bind variable. The DBA has since explained to them the reason why bind variable are good – but only if your bind variable names don’t keep changing).

Apologies for any typos – I’m on a three-hour train journey and the Wifi link keeps dropping.