Não tem receita mágica… se o desempenho está ruim pode ser vários fatores, do mais simples para o mais complexo (mais caro) de corrigir:
1 – problema no modelo físico: estatísticas, indexação de tabelas, técnicas de particionamento, cluster tables, etc.
2 – problemas na aplicação: código não usa bind variables; operações de leitura e escrita (SQL e DML) codificadas row-by-row em vez de set based ou bulk (lote); SQL mal escrito, com vários acessos à mesma tabela (o vilão Union), produtos cartesianos e joins não otimizados.
3 – problemas no modelo de dados: o desenho das tabelas e seus relacionamentos não foram feitos pensando no tipo de uso que elas teriam – elas sofrem principalmente leituras ou escritas? As leituras são feitas de que forma, acessando geralmente quais colunas, filtrando por quais delas e usando joins com que outras tabelas?
Pelo que entendo essa ferramenta é parte de um suite de ERP que abstrai acesso de dados por uma API. Isso muitas vezes leva a uma análise pobre no desenho da camada do banco de dados, que por sua vez cobra a conta em forma de performance abaixo do esperado ou problemas de consistência e integridade de dados.
Gilkauer.
Gilkauer.
msartor
msartor
leandrolbs
fsitja
Gilkauer