Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A heavy CPU consumption SQL detected after executing jdbctemplate call to oracle 11gr2 store procedure [SPR-13432] #18011

Closed
spring-projects-issues opened this issue Sep 4, 2015 · 2 comments
Labels
in: data status: bulk-closed

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Sep 4, 2015

Hendry Lai opened SPR-13432 and commented

Spring Framework 4.0.6 , using jdbctemplate call oracle 11gr2 store procedure
a heavy CPU consumption SQL detected after executing jdbctemplate call to oracle 11gr2 store procedure.
We found that root cause is :
jdbcUtil try to get procedure metadata before execute store procedure, and that sql in oracle 11g is very slow ( reference to URL or SQL below )
For oracle maybe it can be improved performance if LIKE operator can be replaced as equal operator and prevent IS NULL condition (such as sub-query from ALL_OBJECTS view )

detected top sql like
http://stackoverflow.com/questions/3894896/mysterious-sql-blocking-my-stored-procedure-from-executing-on-oracle

SELECT package_name AS procedure_cat,
owner AS procedure_schem,
object_name AS procedure_name,
argument_name AS column_name,
DECODE(position,
0, 5,
DECODE(in_out,
'IN', 1,
'OUT', 4,
'IN/OUT', 2,
0)) AS column_type,
DECODE(data_type,
'CHAR', 1,
'VARCHAR2', 12,
'NUMBER', 3,
'LONG', -1,
'DATE', 91,
'RAW', -3,
'LONG RAW', -4,
'TIMESTAMP', 93,
'TIMESTAMP WITH TIME ZONE', -101,
'TIMESTAMP WITH LOCAL TIME ZONE', -102,
'INTERVAL YEAR TO MONTH', -103,
'INTERVAL DAY TO SECOND', -104,
'BINARY_FLOAT', 100,
'BINARY_DOUBLE', 101,
1111) AS data_type,
DECODE(data_type,
'OBJECT', type_owner || '.' || type_name,
data_type) AS type_name,
DECODE(data_precision,
NULL, data_length,
data_precision) AS precision,
data_length AS length,
data_scale AS scale,
10 AS radix,
1 AS nullable,
NULL AS remarks,
sequence,
overload,
default_value
FROM all_arguments
WHERE owner LIKE :1 ESCAPE '/' AND
object_name LIKE :2 ESCAPE '/' AND
package_name IS NULL AND
(argument_name LIKE :5 ESCAPE '/' OR
(argument_name IS NULL AND data_type IS NOT NULL))
ORDER BY procedure_schem, procedure_name, overload, sequence


Affects: 4.0.6

Reference URL: http://stackoverflow.com/questions/3894896/mysterious-sql-blocking-my-stored-procedure-from-executing-on-oracle

1 votes, 2 watchers

@spring-projects-issues spring-projects-issues added status: waiting-for-triage in: data type: enhancement and removed type: enhancement labels Jan 11, 2019
@rstoyanchev rstoyanchev added status: bulk-closed and removed status: waiting-for-triage labels Jan 11, 2019
@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 12, 2019

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

@stephanedaviet
Copy link

@stephanedaviet stephanedaviet commented Mar 11, 2021

I can confirm this bug. One way to prevent this request is to disable the retrieval of metadata by Spring JDBC before the procedure call by calling .withoutProcedureColumnMetaDataAccess() on SimpleJdbcCall. Here is a sample code:

SimpleJdbcCall jdbcCall = new SimpleJdbcCall(jdbcTemplate)
        .withoutProcedureColumnMetaDataAccess()
        .withSchemaName("<schema-name>")
        .withCatalogName("<catalog-name>")
        .withProcedureName("proc-name")
        .withNamedBinding()
        .useInParameterNames(<list-of-named-parameters> ...)
        .declareParameters(new SqlOutParameter("<param-name>", OracleTypes.NUMBER))
        ...

This behavior comes from GenericCallMetaDataProvider.java and is still present in the same class in latest 5.1.x Spring release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data status: bulk-closed
Projects
None yet
Development

No branches or pull requests

3 participants