Pergunta

Os documentos para funções em pipeline dizem que DML não é permitido quando são usados ​​em uma instrução SQL (normalmente um SELECT), e na maioria dos exemplos as funções em pipeline são usadas para geração ou transformação de dados (aceitando um custor como parâmetro), mas não emitindo nenhuma instrução DML.

Agora, tecnicamente, é possível usar SELECTs sem nenhum erro do Oracle (ORA 14551 não irá ocorrer).No entanto, tenho experiências de comportamento estranho reproduzível do selecionado;embora PRAGMA AUTONOMOUS_TRANSACTION é não sendo usado, as linhas recuperadas pelo SELECT parecer não sempre levando em consideração a transação local atual, o que me parece um bug.Ainda mais perturbador é o facto de, quando se utiliza uma transacção distribuída (por exemplo, via ORAMTS em vez de uma transacção local), a transacção é utilizada.

Editar: Acontece que o efeito estranho parece relacionado a algumas instruções WITH na consulta, que às vezes funcionam e às vezes não (dependendo do humor atual do otimizador Oracle, pelo menos em 10g).Em alguns casos, recebo um ORA-32036, mas novamente isso não ocorre, sem alterar o código.Agora parece que as consultas que às vezes falham com o ORA-32036 são aquelas que também não conseguem usar a transação correta e podem não estar relacionadas à função de pipeline.

Então, minhas perguntas específicas são:

  • Existe alguma declaração, de preferência oficial, se SELECTs em funções de tabela em pipeline são permitidas e qual é seu contexto transacional?

  • Existe outra maneira de modularizar consultas comumente usadas que podem ser usadas em instruções SQL (assim como as funções de tabela podem com TABLE())?

  • Alguém também experimentou tal comportamento e talvez saiba mais sobre isso?Pesquisei no metalink, mas infelizmente não encontrei nada específico sobre o assunto.

Foi útil?

Solução

  1. normalmente as restrições DML dizem respeito apenas a instruções de modificação (UPDATE, DELETE ...), então SELECT deve estar OK.Tentarei encontrar uma declaração específica da Oracle.

  2. As visualizações seriam sua primeira ferramenta para modularizar consultas comumente usadas.

  3. As funções têm uma desvantagem em relação às visualizações:se forem chamados de outro SELECT, não serão executados no mesmo momento que o SELECT principal.Cada chamada para um SELECT é consistente, mas como o SELECT está no código da função e não no SQL principal, você pode retornar resultados inconsistentes.Isso não é possível com visualizações e subseleções:se uma instrução grande chamar uma visualização, a visualização será construída no mesmo momento que a consulta principal.

Atualizar:em relação ao seu comentário sobre consultas parametrizadas

Você pode construir visualizações parametrizadas, ou seja, visualizações que dependem de variáveis ​​definidas antes da execução. Aqui está um exemplo no AskTom mostrando como você poderia fazer isso com userenv('client_info') ou dbms_session.set_context.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top