Diferentes SQL_ID com o mesmo SQL_TEXT
- 18/03/2017/
- Acontecimentos do dia a dia
Ha uma situação em que a mesma Query escrita EXATAMENTE DA MESMA FORMA (sentença - texto do SQL : exemplo : "select sysdate from dual") gere diferentes SQL_ID e códigos de assinatura (EXACT_MATCHING_SIGNATURE e FORCE_MATCHING_SIGNATURE).
- SQLI ID : É uma string alfanumérica produzida no parse, à partir do CODIGO SQL.
Código de assinatura :
EXACT_MATCHING_SIGNATURE - Assinatura em HASH, trata-se de uma string numérica produzida à partir da desnormalização do CODIGO SQL (desnormalização = Remover os espaços do texto, uppercasing de todas as palavras e por fim gerar um HASH)
FORCE_MATCHING_SIGNATURE - Mesmo mecanismo do EXACT_MATCHING_SIGNATURE, porem é usado quando CURSOR_SHARING é setado como FORCE (Sendo assim, CURSOR_SHARING tiver como EXACT, isso significa que EXACT_MATCHING_SIGNATURE = FORCE_MATCHING_SIGNATURE, por outro lado, se CURSOR_SHARING tiver como SIMILAR ou FORCE, isso significa que EXACT_MATCHING_SIGNATURE <> FORCE_MATCHING_SIGNATURE - ou seja, assinaturas diferentes)
Em cenários em que existem duplicação dos objetos compilados em library cache (tornar hot object), ou seja, QUAISQUER objetos de parse referente a "sentenças SQL" (QUERY) marcados como HOT (usando dbms_shared_pool.markhot), sofre um re-parse com diferente SQL ID para o mesmo texto de QUERY.
Conclusão: NUNCA SUBMETA UMA QUERY PARA SER HOT OBJECT NA SHAREDPOOL.
Different Sql_id's But Sql Is The Same Text When Sql Is Marked Hot (Doc ID 2234171.1)