Não gosto de publicar informações de como não se deve configurar o ambiente, porém diante da quantidade de acessos no artigo de piores parâmetros, me convenci da necessidade de publicar mais uma situação comum de atendermos: Como otimizar o desempenho do banco de dados?
Já publiquei uma série de artigos de como otimizar o desempenho, não apenas do banco de dados, mas do ambiente inteiro. Então partindo pelo lado prático de como DEVE ser feito, sugiro a leitura dos artigos de Desempenho X Segurança.
Na prática, o que vemos é uma série mal sucedida de adaptações das recomendações cientificamente fundamentadas. Essas adaptações simplificam a análise e as demandas de um ambiente, passando a utilizar rotinas genérias de configuração.
A primeira prática não fundamentada são os números mágicos. Verifique se já ouviu esse comentário:
"- Informe tal valor para esse parâmetro que você vai sentir a diferença. Fiz isso em outro cliente e a melhora foi fantástica".
Isso não existe. Toda configuração ou parametrização tem uma razão de ser feita, e não necessariamente a melhor configuração para um ambiente reflete a melhor configuração para outro ambiente. Confira os manuais do Progress antes de definir qualquer parametrização desconhecida. Se um consultor está configurando o seu ambiente, exija que seja explicado o motivo de cada definição nova ou alteração da configuração existente. É o seu ambiente que está em jogo.
A segunda prática é o dump-load. Confira a conversa:
"- Meu sistema está lento."
"- Humm, a quanto tempo que você não faz um dump-load."
"- O último foi ano passado."
"- É, faz muito tempo mesmo. Deve ser esse o problema."
Um dump-load é um processo crítico para o ambiente, não apenas pela parada causada ao ambiente quanto pelos riscos envolvidos no processo. Essa não é (ou não deveria ser) uma atividade de rotina. Existem apenas 3 situações que um dump-load é necessário:
1. Alteração do tamanho de bloco do banco, que por uma deficiência do banco de dados Progress ainda não é possível sem o dump-load;
2. Conversão do sistema operacional do servidor de banco de dados, sempre que alterado o identificador "Media ID" da instalação de Progress;
3. Corrupção do meta-schema do banco, ou de alguma parte que influencie a estrutura do banco.
O novo processo de conversão dos produtos Datasul foi projetado para evitar o dump-load também para migração de produto. Confira o artigo Novo proceso de conversão de produtos para detalhes.
Quanto ao desempenho, desde a versão 8 do Progress não vejo um caso onde o dump-load beneficiaria o desempenho do banco inteiro. As vezes uma ou outra tabela pode necessitar de dump-load, principalmente se ela for uma tabela significativa que não está alocada em uma Storage Area II, o que indica um erro de configuração e não um problema de desempenho.
A terceira prática é o aumento do buffer pool (-B). Confira a conversa:
"- O sistema está lento."
"- Então aumente o -B."
"- Eu já aumentei e continua lento."
"- Então aumenta mais."
"- Mas se eu aumentar mais vai estourar a memória do servidor." (veja, finalmente alguém se preocupou com o ambiente)
"- Humm, nesse caso, teremos que programar um upgrade de memória no servidor."
Infelimente existem muitos "Tunings de -B" no mercado. A área de buffer pool é uma das partes que devem ser configuradas no ambiente. Quando afirmo a palavra "configurada" significa que indicadores devem ser monitorados para determinar a área necessária para cada banco de dados. O parâmetro -B pode ser configurado errado, tanto para mais quanto para menos. É claro que podem existir casos em que não há o que fazer pois o servidor de banco de dados é ultrapassado e não consegue manter o ambiente rápido ou mesmo estável. Porém um conjunto de indicadores devem ser avaliados para determinar isso.
A quarta prática é o APW. Perceba o comentário:
"- O APW você deve definir 5, porque daí você fica com 5 processos gravando o banco de dados"
Novamente, existem indicadores que determinam se seu ambiente precisa de um ou mais APW's. Basicamente, se o banco de dados sofre muita gravação, talvez você precise de mais de um APW. Se o banco não tem volume de gravação suficiente para os APW's trabalharem, um APW significa um processo a mais executando no servidor, que consome processamento, consome memória, e constantemente faz acesso a uma parte do buffer pool (10 blocos, especificamente). São recursos do servidor consumidos indevidamente.
A última prática que não gostaria de mencionar é a utilização (indevida) de storage areas. Confira a conversa:
"- O meu sistema está lento."
"- Humm, o Progress dispõe de um novo recurso no banco de dados que permite dividir o banco de dados em áreas."
"- E o que eu ganho com isso?"
"- É que dessa forma o banco fica mais quebradinho e ele trabalha mais rápido."
"- Mas isso não usa mais memória?"
"- Usa, mas aí aumentamos um pouco o -B para compensar."
"- Legal, vamos fazer então."
"- OK, vamos agendar esse serviço e já aproveitamos para fazer um dump-load do banco."
A partir da versão 9 o Progress dispõe de um recurso que possibilita identificar os arquivos que conterão dados de cada tabela ou índice. Isso ajuda no balanceamento de carga do disco e principalmente na melhor alocação de registros por bloco de cada tabela. Porém, a não ser que cada tabela de seu banco seja maior de 64 Gbytes, não faz sentido criar uma storage area por tabela. Já montei ambientes grandes, com mais de 300 usuários simultâneos e aproximadamente 90 Gbytes de banco, usando 7 storage areas para dados e 3 para índices. Para esse ambiente, definir mais storage areas seria complicar o ambiente inutilmente, pois não haveria mais ganho de desempenho.
Essas são apenas 5 situações comuns que além de não surtirem efeito positivo no ambiente, podem complicar a sua estabilidade. A recomendação é sempre procurar informação de diversas fontes antes de alterar o ambiente, ou mesmo procurar consultores certificados em banco de dados Progress para auxiliá-lo. Backup também nunca é demais.
Assinar feeds (RSS)