Qual é a maneira correta de definir o parâmetro de ajuste de custo do índice do otimizador para Oracle. Como desenvolvedor, observei enormes melhorias de desempenho à medida que esse parâmetro foi reduzido. As consultas comuns são reduzidas de 2 segundos para 200 ms. Existem muitos avisos na rede de que reduzir esse valor causará problemas graves no banco de dados, mas nenhum detalhe é fornecido sobre o que começará a dar errado.
Atualmente, estou vendo apenas uma vantagem, um desempenho de aplicativo muito melhorado e nenhuma desvantagem. Preciso entender melhor as possíveis repercussões negativas do ajuste desses parâmetros.
Responder1
A razão pela qual não é recomendado alterar esses parâmetros é que eles têm impacto em todo o banco de dados no otimizador - portanto, quando você os altera para ajustar uma consulta específica, provavelmente terá algum impacto em muitas outras consultas. Portanto, alterá-lo em produção sem testar cuidadosamente todo o aplicativo é perigoso.
No entanto:
- Configurá-lo em um ambiente de desenvolvimento/teste e permanecer com o mesmo valor na produção pode ser aceitável (costumava ser uma prática comum em sistemas OLTP). No entanto, você pode ter certeza de que seu aplicativo será executado em um banco de dados dedicado? e nunca será consolidado em outro banco de dados com um conjunto padrão de parâmetros?
- Os parâmetros ajudam porque a Oracle usa algumas heurísticas sobre o custo relativo de E/S versus CPU e, no seu caso, as heurísticas não são boas o suficiente, então a Oracle escolhe planos de execução abaixo do ideal. A maneira recomendada de corrigir a heurística é deixar a Oracle coletarestatísticas do sistemapara sua máquina de banco de dados - quão rápida é a CPU, quanto tempo leva para obter bloco único/bloco múltiplo do seu sistema de E/S durante o carregamento normal do sistema, etc.Consulte a documentação da Oracle.
Se você quiser usar as estatísticas do sistema e os parâmetros do otimizador, pesquise no Google, Jonathan Lewis escreveu sobre isso (desculpe, o site não me permite postar mais de um link)
Espero que ajude
Responder2
O parâmetro não deve ser alterado em um ambiente de produção. O principal uso é forçar uma mudança de plano apenas para verificar o desempenho com diferentes planos de execução. Basicamente, você está sugerindo ao otimizador que todos os índices do seu banco de dados sejam mais baratos de usar do que outro caminho de acesso. E isso pode ser verdade para alguns SQL e pode ser falso para outros.
Depois de ter um bom plano de desempenho, você deve entender por que o otimizador não o usa e tentar consertar (ou seja, nenhuma estatística atualizada/precisa está disponível -> coletar estatísticas novas e mais precisas).
Espero que isso ajude, Stefano
Responder3
Os padrões para esses 2 parâmetros são terríveis para sistemas OLTP, que são o tipo de banco de dados mais comum. Eles levam a varreduras de tabela mais completas e consultas incorretas. Geralmente você deseja definir esses parâmetros ANTES de entrar no ar. Você faz isso na fase de teste.
Se você alterá-los depois de entrar no ar, você corre o risco de alterar outras consultas que foram ajustadas com configurações incorretas. Parece que você não sabe muito sobre ajuste de banco de dados, já que mencionou o tempo de resposta em vez dos planos de consulta. Você não deve tocar nesses parâmetros.
A maioria dos DBAs não entende a diferença de conceitos entre correção e design. Depois de estar ao vivo, você está consertando e é aí que precisa ter cuidado ao alterar esses parâmetros. Antes de entrar em operação, você está na fase de design e desenvolvimento. É quando você ajusta parâmetros como este.
Aliás, um bom lugar para começar com esses parâmetros (observe ANTES DE IR PARA A PRODUÇÃO E SOMENTE SE VOCÊ SABE O QUE ESTÁ FAZENDO!)
otimizador_index_cost_adj=10 cache do otimizador=90
Isto é para OLTPs. Para processamento em lote, as configurações com as quais você deseja começar são muito diferentes. Eu mexo um pouco nisso, mas essas configurações me proporcionam os melhores resultados gerais 99% das vezes em um OLTP. No entanto, NÃO toco neles depois de irmos para a produção. Se estiverem ruins, deixo-os ruins e ajusto as consultas.