Oracle Strange Long query

Question

Hello,
I'm still in the process of finding what is wrong with my oracle connection.
Everytime a request is done, this query is executed:
SELECT NULL AS table_cat, t.owner AS table_schem,t.table_name AS
table_name,t.column_name AS column_name, DECODE (t.data_type, 'CHAR',
1, 'CLOB', 2005, 'BLOB', 2004, 'VARCHAR2', 12, 'NUMBER', 3, 'LONG',
-1, 'DATE', 93,'RAW', -3, 'LONG RAW', -4, 'BINARY_FLOAT', 7,
'BINARY_DOUBLE', 8, 'XMLTYPE',2005, 'BFILE',2004,'NCHAR',1,
'NVARCHAR2',12, 'NCLOB', 2005, 'ROWID', 12, 'FLOAT', 8, 1111) AS
data_type, t.data_type AS type_name, decode(t.data_type, 'NUMBER',
decode(t.data_precision, null, decode(t.data_scale, null, 0, 0, 38,
t.data_scale), t.data_precision), 'FLOAT', 15, 'CLOB',2147483647,
'NCLOB', 2147483647, 'LONG', 2147483647, 'BLOB', 2147483647, 'LONG
RAW', 2147483647, 'BFILE', 2147483647, 'DATE', 19, 'ROWID', 18,
'BINARY_FLOAT', 7, 'BINARY_DOUBLE', 15,decode(t.data_length, 0, 1,
t.data_length)) as column_size, 0 AS buffer_length,
decode(t.data_type, 'NUMBER', decode(t.data_scale, null,
decode(t.data_precision, null, 0,null), t.data_scale), 'FLOAT',
NULL,'DATE', 0, NULL) AS decimal_digits, decode(t.data_type,
'BINARY_FLOAT', 10, 'BINARY_DOUBLE', 10, 'FLOAT', 10, 'NUMBER', 10,
NULL) AS num_prec_radix, DECODE (t.nullable, 'N', 0, 1) AS nullable,
NULL AS remarks,NULL AS column_def, null AS sql_data_type, null AS
sql_datetime_sub, decode(t.data_type, 'VARCHAR2',
decode(t.data_length, 0, 1, t.data_length), 'CHAR', t.data_length,
'NCHAR', t.data_length, 'CLOB', 2147483647, 'NCLOB', 2147483647,
'LONG', 2147483647, 'BFILE', 2147483647, NULL) AS char_octet_length,
t.column_id AS ordinal_position, DECODE (t.nullable, 'N', 'NO', 'YES')
AS is_nullable, null as SCOPE_CATLOG, null as SCOPE_SCHEMA, null as
SCOPE_TABLE, null as SOURCE_DATA_TYPE FROM all_tab_columns t WHERE
t.owner LIKE 'REI' ESCAPE '\' AND t.table_name LIKE 'G_PAGE' ESCAPE
'\' AND t.column_name LIKE '%' ESCAPE '\' UNION ALL SELECT NULL,
asy.owner, asy.synonym_name , t.column_name, DECODE (t.data_type,
'CHAR', 1, 'CLOB', 2005, 'BLOB', 2004, 'VARCHAR2', 12, 'NUMBER', 3,
'LONG', -1, 'DATE', 93,'RAW', -3, 'LONG RAW', -4, 'BINARY_FLOAT', 7,
'BINARY_DOUBLE', 8, 'XMLTYPE',2005, 'BFILE',2004,'NCHAR',1,
'NVARCHAR2',12, 'NCLOB', 2005, 'ROWID', 12, 'FLOAT', 8, 1111),
t.data_type, decode(t.data_type, 'NUMBER', decode(t.data_precision,
null, decode(t.data_scale, null, 0, 0, 38, t.data_scale),
t.data_precision), 'FLOAT', 15, 'CLOB',2147483647, 'NCLOB',
2147483647, 'LONG', 2147483647, 'BLOB', 2147483647, 'LONG
RAW',2147483647, 'BFILE', 2147483647, 'DATE', 19, 'ROWID', 18,
'BINARY_FLOAT', 7, 'BINARY_DOUBLE', 15,decode(t.data_length, 0, 1,
t.data_length)), 0, decode(t.data_type, 'NUMBER', nvl(t.data_scale,
0), 'DATE', 0, 'FLOAT', NULL, NULL) AS decimal_digits,
decode(t.data_type, 'FLOAT', 10, 'NUMBER', 10, NULL), DECODE
(t.nullable, 'N', 0, 1), NULL, NULL, null, null, decode(t.data_type,
'VARCHAR2', decode(t.data_length, 0, 1, t.data_length), 'CHAR',
t.data_length, 'NCHAR', t.data_length, 'CLOB', 2147483647, 'NCLOB',
2147483647, 'LONG', 2147483647, 'BFILE', 2147483647, NULL),
t.column_id, DECODE (t.nullable, 'N', 'NO', 'YES'), null, null, null,
null FROM all_synonyms asy, all_tab_columns t WHERE t.table_name =
asy.table_name AND t.owner = asy.table_owner AND t.column_name LIKE
'%' ESCAPE '\' AND asy.owner LIKE 'REI' ESCAPE '\' AND
asy.synonym_name LIKE 'G_PAGE' ESCAPE '\' ORDER BY table_schem,
table_name, ordinal_positionThis is a very long and resource consuming query.
Why this query is executed everytime I do a commit, select or anything.
A commit is 30 sec long (http://swforum.sun.com/jive/thread.jspa?threadID=93759&tstart=0).
Are all Oracle users subject to this problem?
Regards
Kuon

Answer 1

Here's my theory:
Oracle's jdbc driver (not Sun's) doesn't support rowset.getMetaData() until the query statement is executed. I understand that the database itself doesn't have support. (a year ago this was a problem, I still think so now).
Sun's jdbc driver for Oracle (repackaged from DataDirect) does support rowset.getMetatData().
So how does it do this? I don't know exactly, but the only way I can think of is that it is to parse the query, get the database meta data, and use all that to determine the resultSet meta data.
I think you're seeing the "get the database meta data" request, and that's just taking along time.
I'd expect that data to be cached by the driver on (at least) a per-connection basis. Doesn't look like though.
Maybe someone from Sun has the current scoop for plans in this area.
In the meantime, I think you're hosed if you want to use a CachedRowSet.
Workarounds would be using plain old jdbc, hibernate, etc., to get the data then wrapping your results into an ObjectArrayDataProvider or whatever.
Good luck.