Você está na página 1de 5

Como no otimizar o desempenho de um

banco de dados Progress OpenEdge


Fonte :
http://blog.uxtecnologia.com/post/2016/03/10/
Como-nao-otimizar-o-desempenho-de-umbanco-de-dados-Progress-OpenEdge.aspx
10 maro 2016 UX Tecnologia Banco de Dados, Desempenho, Progress (0)
(See How not to optimize performance of a Progress OpenEdge Database below)

comum vermos consultores de banco de dados que se baseiam em nmeros


mgicos e procedimentos padres para tratar assuntos de desempenho. Na
prtica isso se reflete em interpretaes e adaptaes mal sucedidas de
recomendaes cientificamente fundamentadas. Essas adaptaes simplificam
a anlise e as demandas de um ambiente, passando a utilizar rotinas genricas
de configurao.
A primeira prtica no fundamentada so os nmeros mgicos. Alguma fez
voc j ouviu uma recomendao desse tipo?
Informe tal valor para esse parmetro que voc vai sentir a diferena. Fiz isso
em outro cliente e a melhora foi fantstica!".
Isso no existe. Toda configurao ou parametrizao tem uma razo de ser
feita, e no necessariamente a melhor configurao para um ambiente reflete a
melhor configurao para outro ambiente. Confira os manuais do Progress antes
de definir qualquer parametrizao desconhecida. Se um consultor est
configurando o seu ambiente, exija que seja explicado o motivo de cada
definio nova ou alterao da configurao existente. o seu ambiente que
est em jogo.
A segunda prtica o dump-load. A conversa ocorre mais ou menos dessa
forma:
Cliente: Meu sistema est lento.
Consultor: Humm, a quanto tempo que voc no faz um dump-load?
Cliente: O ltimo foi ano passado.
Consultor: , faz muito tempo mesmo. Deve ser esse o problema.
Um dump-load um processo crtico para o ambiente, no apenas pela parada
causada ao ambiente quanto pelos riscos envolvidos no processo. Essa no
(ou no deveria ser) uma atividade de rotina.
Existem apenas 3 situaes em que um dump-load do banco necessrio:
1. Alterao do tamanho de bloco do banco, que o Progress OpenEdge no
permite ser alterado, e para isso, deve-se criar um novo banco e fazer
dump-load de dados, definies e valores de sequncia;

2. Converso do sistema operacional do servidor de banco de dados,


sempre que alterado o identificador "Media ID" da instalao de
Progress;
3. Corrupo do meta-schema do banco, ou de alguma parte que influencie
a estrutura do banco.
Quanto ao desempenho, desde a verso 8 do Progress no 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 no est alocada em uma Storage Area II, o que indica um erro
de configurao e no um problema de desempenho.
A terceira prtica o aumento do buffer pool (-B). Confira a conversa:
Cliente: O sistema est lento.
Consultor: Ento aumente o -B.
Cliente: Eu j aumentei e continua lento.
Consultor: Ento aumenta mais.
Cliente: Mas se eu aumentar mais vai estourar a memria do servidor.
Consultor: Humm, nesse caso, teremos que programar um upgrade de memria
no servidor e um dump-load.
Infelizmente 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 necessria para cada banco de dados. O parmetro -B pode
ser configurado errado, tanto para mais quanto para menos. claro que podem
existir casos em que no h o que fazer pois o servidor de banco de dados
ultrapassado e no consegue manter o ambiente rpido ou mesmo estvel.
Porm um conjunto de indicadores devem ser avaliados para determinar isso.
A quarta prtica o APW. Perceba o comentrio:
"Deve ser iniciado 5 APWs por banco, 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 gravao,
talvez voc precise de mais de um APW. Se o banco no tem volume de
gravao suficiente para os APW's trabalharem, um APW significa um processo
a mais executando no servidor, que consome processamento, consome
memria, e constantemente faz acesso a uma parte do buffer pool (10 blocos,
especificamente). So recursos do servidor consumidos indevidamente.
A quinta prtica a utilizao indevida de storage areas. Confira a conversa:
Cliente: O meu sistema est lento.
Consultor: Humm, o Progress dispe de um recurso no banco de dados que
permite dividir o banco de dados em reas.
Cliente: E o que eu ganho com isso?
Consultor: que dessa forma o banco fica mais quebradinho e ele trabalha mais
rpido.
Cliente: Mas isso no usa mais memria?
Consultor: Usa, mas a aumentamos um pouco o -B para compensar.
Cliente: Legal, vamos fazer ento.

Consultor: OK, vamos agendar esse servio e j aproveitamos para fazer um


dump-load do banco.
Desde a verso 9 o Progress OpenEdge dispe de um recurso que possibilita
identificar as extenses que contero dados de cada tabela ou ndice. Isso
ajuda no balanceamento de carga do disco e principalmente na melhor
alocao de registros por bloco de cada tabela. Porm, a no ser que cada
tabela de seu banco seja maior de 64 Gbytes, no faz sentido criar uma storage
area por tabela. J montei bancos de dados de aproximadamente 90 Gbytes
usando 7 storage areas para dados e 3 para ndices. Para esse ambiente, definir
mais storage areas seria complicar o ambiente inutilmente, pois no haveria
mais ganho de desempenho.
Essas so apenas 5 situaes comuns que, alm de no surtirem efeito positivo
no ambiente, podem complicar a sua estabilidade. A recomendao sempre
procurar uma equipe de consultoria que tenha conhecimento para fundamentar
as recomendaes que sero aplicadas em seu ambiente, e conferir
informaes suspeitas com outros parceiros ou mesmo no manual do banco de
dados.

How not to optimize performance of a Progress


OpenEdge Database
It is common to see database consultants that bases his services on magic
numbers and standard procedures to address performance issues. In practice
this is reflected in unsuccessful interpretations and adaptations of sciencebased recommendations. These adjustments simplify the analysis and the
demands of an environment, using generic setup routines.
The first unsubstantiated practice are the magic numbers. Did you ever hear
such a recommendation?
"Enter this value for this parameter and you will feel the difference. I did it on
another customer and the improvement was fantastic."
There is not such a thing. All configuration and parameter set up have a reason
to be done, and not necessarily the best settings for an environment reflects the
best settings to another environment. Check the Progress manuals before
defining any unknown parameter set up. If a consultant is setting up your
environment, requires the reason for each new setting or changing to the
existing configuration is explained. It is your environment we are talking about.
The second practice is the dump-load. The conversation goes something like
this:
Customer: My system is slow.
Consultant: Humm, how long you dont do a dump-load?
Customer: The last one was in the previous year.
Consultant: Yeah, its been a long time. It must be the problem.
A dump-load is a critical process for the environment, not only by the
environment stop, but the risks involved. This is not (or should not be) a routine
activity.
There are only three situations in which a database dump-load is required:

1. Changing the database block size, that Progress OpenEdge does not
allow to be changed, and for this, you must create a new database and
performe a dump-load of data, definitions and sequence values;
2. Conversion of the database server operating system, whenever the
"Media ID" that identifies the Progress installation is different;
3. Corruption of the database meta-schema, or any part to influence the
database's structure.
About performance, since Progress version 8 I do not see an issue where the
dump-load would benefit the entire database performance. Sometimes one or
other table may need to dump-load, especially if it is a significant table that is
not allocated in a Storage Area II, which indicates a configuration error and not
a performance issue.
The third practice is to increase the buffer pool (-B). Check out the conversation:
Customer: The system is slow.
Consultant: So, increase the B.
Customer: I already dit it, but its still slow.
Consultant: So, increase again.
Customer: But if I increase it again, it will overflow de server memory.
Consultant: Humm, in this case, we will have to schedule a server memory
upgrade and a dump-load.
Unfortunately there are many "tunings of -B" in the market. The buffer pool area
is one of the parts that must be configured in the environment. When I say the
work "configured", it means that indicators should be monitored to determine
the space required for each database. The -B parameter can be set wrong, so to
more as for less. Of course, there may be cases in which there is nothing to do
because the database server is outdated and can not keep the environment fast
or stable. But a set of indicators should be analyzed to determine this.
The fourth practice is the APW. See this comment:
You must start 5 APWs for the database, because then you have 5 process
writing the database.
Again, there are indicators which determine whether your environment requires
one or more APW's. Basically, if the database suffers a lot of recording, you may
need more than one APW. If the database does not have enough recording
volume for APW's work, one APW means one more process running in the
server, consuming processing, memory and constantly makes access to a
portion of the buffer pool (10 blocks, specifically). These are server resources
consumed incorrectly.
The fifth practice is the improper use of storage areas. Check out the
conversation:
Client: My system is slow.
Consultant: Humm, Progress has a feature in the database to divide the
database into areas.
Customer: And what do I get with it?
Consultant: In this way the database gets more pieces and works faster.
Customer: But doent it use more memory?
Consultant: Yes, but then we increase the B a little to compensate.

Customer: Cool, let's do so.


Consultant: OK, let's schedule this service and intend for do a database dumpload.
Since version 9 Progress OpenEdge offers a feature to identify the extensions
that contain data from each table or index. This helps the disk load balancing
and mainly in better allocation of records per block of each table. However,
unless each table of your database is larger than 64 Gbytes, it makes no sense
to create a storage area per table. I already mounted databases of
approximately 90 Gbyte using 7 storage areas for data and 3 for indexes. For
this environment, to define more storage areas would unnecessarily complicate
the environment because there would be no performance gain.
These are just five common situations that, beside do not bring positive effect
on the environment, may complicate its stability. The recommendation is to
always look for a consulting team that has knowledge to support the
recommendations to be implemented in your environment, and check
suspicious information with other partners or even database manual.