Pourquoi le temps d'exécution d'une procédure stockée oracle est-il considérablement augmenté en fonction de la manière dont elle est exécutée ?

Essayez d'obtenir les paramètres nls de vos différents cas (programmes ide ou java), ils doivent être différents

select * from NLS_SESSION_PARAMETERS

Ensuite, à l'intérieur de votre procédure de magasin, définissez les variables pour les rendre égales à partir du cas le plus rapide.

  execute immediate 'alter session set NLS_SORT=''SPANISH''';

Une fois que vous SP avez tous les paramètres nls . Il ira vite.

J'ai récemment trouvé un cas similaire dans Alter session qui ralentit la requête via Hibernate . mais dans leur cas, ils changent de paramètres et deviennent alors lents.

J'ai enquêté et découvert que les paramètres NLS_COMP et NLS_SORT peuvent affecter la façon dont Oracle utilise le plan d'exécution pour la chaîne (lorsqu'il compare ou ordonne)

Lorsque NLS_COMP est défini comme LINGUISTIC, il utilisera la langue définie dans NLS_SORT.

par exemple, si NLS_COMP =LINGUISTIC et NLS_SORT=BINARI_AI votre requête est

select * from table where string_column like 'HI%'

en interne ça ira

select * from table where  
NLSSORT(string_column,'BINARI_AI') >= HEXTORAW('324242432')
NLSSORT(string_column,'BINARI_AI') >= HEXTORAW('675757576')

donc si vous n'avez pas d'index pour NLSSORT(column,'BINARI_AI') ce sera très lent.

sachant que NLS_SORT=BINARY_AI rendra votre classement et vos comparaisons insensibles aux accents et à la casse.