Problemas com o CURSOR_SHARING = SIMILAR

Question

Olá,
Sou DBA de uma empresa que utiliza o Oracle 10G, e recentemente realizei uma alteração (para efeito de teste) do parâmetro CURSOR_SHARING. Alterei ele do seu valor default "EXACT" para o valor "SIMILAR".
Com a alteração, a taxa de hard parse diminuiu, e obtive um alto índice de reuso de query (ou scripts de modo geral).
Os testes estavam indo bem, quando és que surge uma consulta semelhante a seguinte:
select 'teste' as campo, 'Y' as tipo from dual
union
select 'teste1', 'N' from dual;
Com o parâmetro alterado, essa consulta foi interpretada como:
select '"SYS_B_0"' as campo, '"SYS_B_1"' as tipo from dual
union
select '"SYS_B_2"' as campo, '"SYS_B_3"' as tipo from dual;
Até então, tudo ocorreu conforme esperado, porém na aplicação que faz uso dessa base existia um teste:
<%
'Código ASP
if cstr(rs.fields("tipo")) = "Y" then
<< fazer algo >>
else
<< fazer algo >>
end if
%>
Mesmo quando o retorno da consulta era = "Y", nunca entre no if (e eu testei a consulta e ela realmente retornava Y).
Quando fui verificar o retorno pela aplicação, o campo "tipo" retornava "Y ¢¥¥├ò", ou seja, com um lixo após o valor.
Rodei a mesma consulta pelo sqlplus, e realmente o valor do retorno era apenas "Y".
Tentei alterar o provider da string de conexão do banco para ver se era esse o problema, mas o mesmo persistiu. O Oracle Client no servidor da aplicação é o 10G.
Não consegui entender o erro, e em todas as documentações e livros que pesquisei, os problemas oriundos da alteração desse parâmetro acarreta apenas em queda de performance (devido a por exemplo reutilizar um plano NÃO otimizado para uma consulta).
Esse problema inviabilizou a alteração que se comportara muito bem em outros aspectos.
Entendo que quando pensamos em reuso através de bind variables, associamos apenas à alterações dos parâmetros na seleção dos dados e não na projeção como é o caso citado.
Alguém tem alguma ideia sobre o que pode ser e se tem alguma alteração que possa ser feita para conseguir o ganho da performance dos "soft parses"?
Grato desde já.

Answer 1

Hi,
I'm a DBA for a company that uses Oracle 10G (release 10.2.0.3), and recently realized a change (for the purpose of testing) on parameter CURSOR_SHARING. I changed it to value "SIMILAR".
With the change, the rate decreased hard parse, and got a high degree of reuse of query (and scripts in general).
The tests were going well, when the query below arose:
select 'test' as campo, 'Y' as tipo from dual
union
select 'test1', 'N' from dual;
With the changed parameter, this query was interpreted as:
select '"SYS_B_0"' as campo, '"SYS_B_1"' as tipo from dual
union
select '"SYS_B_2"', '"SYS_B_3"' from dual;
Until then, everything went as expected, but the application that uses the database has a test:
<%
'ASP code
if CStr (rs.Fields ("tipo")) = "Y" then
<< something >>
else
<< something >>
end if
%>
Even when the query was returning = "Y", never executed the if clause (and I tested the query and it really returned "Y").
When I check the return by the application, the field "tipo" returned "Y ¢ ¥ ò ¥ ├", with a dirty code after.
I execute the same query through sqlplus, and really the value of the return was only "Y".
I tried changing the provider in the string connection of the database to see if that was the problem, but it persisted. The Oracle Client on the application server is 10G.
I could not understand the error, and all documentations and books I researched, the problems arising from the change of this parameter causes only drop in performance (eg due to reuse a NOT optimized plan for a query).
This problem prevented the change that had behaved very well in other respects.
I understand that when we think of reuse through bind variables, only associate the changes of the parameters in the selection of the data and not in the projection as in the case cited.
Anyone have any idea about what can be and if you have any changes that may be made to achieve the performance gain of the "soft parses"?
Thankful now.
<<< Sorry for my english >>>