Existe um motivo significativo para recompilar procedimentos armazenados?
É claro que os dados em um banco de dados mudam com o tempo e o conjunto de resultados de alguns procedimentos armazenados pode diferir devido a dados subjacentes alterados. Mas a menos que haja mudanças nas estruturas das tabelas, os procedimentos armazenados devem ser bons para sempre?
Estou falando do Sybase ASE 15.
Esta é a razão habitual. Embora o conceito de compilar um procedimento armazenado seja específico da implementação, ele geralmente envolve a produção de um plano de consulta para o procedimento e/ou as instruções individuais das quais ele é formado e o armazenamento para reutilização posterior (para salvar a parte do processo que está sendo repetida a cada momento em que o procedimento é chamado).
À medida que seus dados crescem, o saldo de dados em cada tabela/índice pode mudar de tal forma que o plano ideal quando o procedimento foi compilado pela última vez agora é muito mais ineficiente do que outras opções, de modo que o procedimento não terá mais desempenho poderia. Se você tivesse apenas algumas linhas em uma tabela quando o procedimento foi criado (ou compilado pela última vez), uma varredura pode ter sido mais eficiente do que uma ou mais buscas, por exemplo, mas isso pode não ser mais o caso posteriormente. Além disso, qual índice é mais eficiente tocar primeiro pode mudar ao longo do tempo, especialmente para consultas em tabelas largas e aquelas que se unem em várias tabelas.
O mecanismo de banco de dados geralmente terá algumas heurísticas incorporadas para causar uma recompilação após grandes alterações de dados, bem como após alterações estruturais, mas geralmente são bastante conservadoras em sua ação, portanto, às vezes, é necessário iniciar uma recompilação manualmente. Muito parecido com a heurística envolvida na decisão de quando reamostrar histogramas de estatísticas de índice (que, por sua vez, alimenta as decisões do plano de consulta em geral e em seus procs armazenados).
Às vezes, procs com parâmetros precisarão de planos diferentes para serem eficientes para entradas diferentes - às vezes há circunstâncias em que é benéfico sempre recompilar porque a diferença é tão alta que você não quer arriscar usar um plano de cache lento (no MS SQL Server, a
WITH RECOMPILE
dica existe para lidar com essas circunstâncias ou a instrução por instruçãoOPTION (RECOMPILE)
para uma abordagem mais detalhada). Procedimentos complexos o suficiente para que isso seja um problema importante geralmente são "cheiros de código", o que significa que seu design precisa de um ajuste, embora nem sempre sejam facilmente evitáveis.Uma razão final para recompilar procedimentos armazenados, funções, exibições e outros objetos programáticos é quando as alterações em outros lugares são feitas de uma maneira que interrompe a verificação de dependência, o que significa que uma recompilação automática não ocorre quando é realmente necessária. Por exemplo:
ALTER VIEW
).As informações de dependência proc->view agora estão perdidas.
Como a cadeia de dependência é quebrada, o mecanismo não sabe que as instruções no procedimento podem precisar ser recompiladas, o que significa que o procedimento pode começar a falhar completamente ou fornecer resultados incorretos.