Re: Exclusive-lock X Performance

111 views
Skip to first unread message

MARCOS BATISTA

unread,
Feb 13, 2009, 7:27:54 AM2/13/09
to wand...@gmail.com, Progre...@googlegroups.com, br-pr...@yahoogrupos.com.br
Quando à questão do tamanho da TRANSACTION, perfeito. Isto é crucial

Mas, voltando à questão do Use-Index, o critério de que o "Progress escolher o melhor índice" é relativo, eu prefiro dizer ao Progress qual índice utilizar, pelo menos, na maioria das vezes. Eu até posso ter uma aplicação em que eu deixe isto a cargo do mortor do BD, em que seja conveniente não indicar o índice (por exemplo, quando se usa query dinâmica), mas seriam situações pontuais.

Se você deixar implícito, num primeiro momento até pode atender, mas e se um outro programador desavisado alterar a sua cláusula de WHERE???
A adição de uma cláusula de where pode destruir a performance de uma consulta, fazendo com que o Progress passe a utilizar um índice inadequado.
Se você indicou o índice, pelo menos fica explícito para quem está alterando seu programa, erra "se quiser".
-----------------------------
E mais: e se o DBA precisar alterar um determinado índice e esse índice era o "melhor índice escolhido pelo Progress" numa consulta sua?
Com idenfificar quais programas precisar ser alterados?
Com o use-index eu saberia exatamente quais programas seriam afetados...
-----------------------------
Já tivemos problemas sérios causa disto (e ainda temos pois um sistema totalmente perfomático é utopia) , e "gato escaldado tem medo de água fria"...

sds
Batista
-------------
>>> wand...@gmail.com 13/02/2009 09:55:46 >>>
Concordo plenamente com o Marcos Batista com relação à preocupação com a
performance, cláusula Fields, etc. Tem que ter essa preocupação mesmo.

Só tenha cuidado com o uso do Transaction no seguinte caso: se houver uma
quantidade muito grande de registros tratados dentro do transaction, você
pode ter problemas de performance. Nesse caso o ideal é reduzir o escopo da
transação.

Com relação ao use-index, concordo em parte. Cada um tem uma forma de
trabalhar. O que eu faço é tentar ao máximo é adaptar as cláusulas WHERE a
um índice existente na tabela. Dessa forma o próprio progress já escolhe o
"melhor" índice. Eu sempre compilo os programas usando XREF e vejo no
arquivo xref gerado, se encontro a tag WHOLE-INDEX, que significa que o
programa está lendo a tabela inteira, sem uso de nenhum índice. (Exceção
para as tabelas que possuem um único registro, sempre indica whole-index -
ex.: tabelas de parâmetros). Outra sugestão é estudar a fundo como o
progress trata índices. Existe bom material na internet sobre isso,
geralmente em inglês.

Abraços,

Wander.

2009/2/13 MARCOS BATISTA <BAT...@agraria.com.br>

>
> Apenas mais uma dica: sempre use Fields no for each (veja abaixo o
> exemplo)
>
> FOR EACH scb-op-it FIELDS(num-op /* INDICAR campos de que você usará na
> seqüência do programa*/)
> WHERE scb-op-it.num-op = INPUT FRAME fr-op fl-num-op
> AND scb-op-it.dt-op = vd-dt-op
> NO-LOCK:
> :::
> Outra coisa, sempre que possível use o USE-INDEX, indicando o melhor índice
> para a combinação da cláusula de where.
>
> Isto impacta em performance, que para mim, depois da funcionalidade, é o
> critério mais importante da programação para banco de dados relacionais.
>
> Agora, aidna quanto à funcionalidade, adotamos o critério de que rotinas
> que atualizam banco de dados, SEMPRE usar o DO TRANSACTION, e mais: em cada
> FOR EACH dentro deste DO TRANSACTION use o "ON ERROR UNDO, RETURN...".
> Isto é fundamental para você evitar transações "quebradas" ou "sujas",
> aliás, este é o pior erro que pode ocorrer em programação, gerando os erros
> de cálculos e atualizações mais difíceis de se encontrar.
>
> Veja baixo um exemplo de programa usando este critério:
> Gravar: DO TRANSACTION
> ON ERROR UNDO Gravar, RETURN ERROR
> ON QUIT UNDO Gravar, RETURN ERROR
> ON ENDKEY UNDO Gravar, RETURN ERROR
> ON STOP UNDO Gravar, RETURN ERROR:
> Estoq: FOR EACH tt_estoq ON ERROR UNDO Gravar, RETURN ERROR:
> IF tt_estoq.lfechado THEN DO:
> MESSAGE "Estoque já fechado. Programa:" PROGRAM-NAME(1).
> UNDO Gravar, RETURN ERROR.
> END.
> ASSIGN tt_estoq.lfechado = YES.
> END
> END. /* Gravar */
>
> ---------------
>
>
> Batista
> Analista de Sistemas - Depto.Informática
> Cooperativa Agrária Agroindustrial
> Fone: (42) 3625-8108
> bat...@agraria.com.br
> Visite: www.agraria.com.br
>
> >>> pie...@blitzkow.com 13/02/2009 08:40:48 >>>
> Bom Dia Pessoal,
>
> Agradeço a ajuda de todos, com base na dica de todos desenvolvi o seguinte
> trecho de código responsável por baixar a quantidade de um registro, estou
> anexando abaixo para todos analisarem e dar uma opinião se ainda pode estar
> sussetivel a algum erro e não baixar esta quantidade:
>
> procedure pi-baixa-quant:
>
> FOR EACH scb-op-it WHERE scb-op-it.num-op = INPUT FRAME fr-op fl-num-op
> AND scb-op-it.dt-op = vd-dt-op
> NO-LOCK:
>
> FIND FIRST scb-mov-atual WHERE scb-mov-atual.it-codigo =
> scb-op-it.it-codigo
> AND scb-mov-atual.endereco =
> scb-op-it.endereco
> NO-ERROR NO-WAIT
> IF NOT AVAILABLE scb-mov-atual THEN DO:
> IF LOCKED scb-mov-atual THEN DO:
> MESSAGE 'Registro de quantidade da bobina esta bloqueado,
> Ordem de Operação não pode ser salva.' SKIP
> 'Tente novamente.'
> VIEW-AS ALERT-BOX INFO BUTTONS OK.
> RETURN 'NOK'.
> END.
> ELSE DO:
> MESSAGE 'Registro de quantidade de bobina não foi
> encontrado.'
> VIEW-AS ALERT-BOX INFO BUTTONS OK.
> RETURN 'NOK'
> END.
> END.
> ELSE DO:
>
> ASSIGN scb-mov-atual.quant = scb-mov-atual.quant -
> (scb-op-it.quant-ped
> +
> (scb-op-it.quant-rolo * 100)
> +
> scb-op-it.quant-sucata
> +
> scb-op-it.quant-ret)
> scb-mov-atual.lance = vi-lance.
>
> RELEASE scb-mov-atual NO-ERROR.
>
> RETURN 'OK'.
>
> END.
> END.
> end procedure.
>
> Muito obrigado.
>
> Pierre.
>
> 2009/2/12 Wanderley S <wand...@gmail.com>
>
> > Pierre,
> >
> > Use o FIND com a cláusula NO-WAIT e em seguida utilize a função LOCKED
> para
> > testar se o registro está bloqueado.
> >
> > Dessa forma, o progress não ficará aguardando o registro ser liberado,
> não
> > exibirá a mensagem de registro bloqueado e você pode testar o bloqueio
> com a
> > função LOCKED (if locked tabçe)..
> >
> > Você pode inclusive utilizar um loop para aguardar, mas cuidado para não
> > causar um loop infinito.
> >
> > Sds,
> >
> > Wanderley.
> >
> > 2009/2/12 Vanildo Prates <vpr...@gmail.com>
> >
> >> Ola Pierre,
> >>
> >> Creio que impedir o usuario de clicar em cancelar ou desabilitar o botão
> >> não é possivel, mas vc pode validar se o registro esta bloqueado ou não,
> daí
> >> poderia dar um pause ou emitir um alerta sei la.
> >>
> >> Não estou achando o comando que verifica se o registro esta bloqueado,
> mas
> >> sei que tem.
> >>
> >> att
> >>
> >>
> >>
> >> 2009/2/12 Pierre blitzkow <pie...@blitzkow.com>
> >>
> >> Boa Tarde Pessoal,
> >>>
> >>> Normalmente quando utilizamos o exclusive-lock juntamente com um find
> >>> first se o registro esta bloqueado aparece a tela padrão do progress
> >>> avisando que o registro esta em uso por outro usuário com um botão de
> >>> cancelar, caso o usuário aperte em cancelar o programa pula o find e
> >>> continua porém gostaria de saber como fazer para avisar que o registro
> esta
> >>> bloqueado e não permitir que o usuário clique em cancelar e obrigue
> fazer
> >>> esperar até desbloquear o registro ?
> >>>
> >>> Grato,
> >>>
> >>>
> >>> -------
> >>> Pierre Blitzkow
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Abraço,
> >
> > Wanderley.
> >
> > "Nada baixa mais o nível da conversa do que elevar a voz". Stanley
> > Horowitz
> >
> > "...aos loucos a sua impressão de bem-estar os leva à perdição." Pv
> 1.32b.
> >
> > "Denunciei a fome como um flagelo fabricado pelos homens, contra outros
> > homens".
> > Josué de Castro
> >
> >
> >
> > >
> >
>
>
> --
> Pierre Blitzkow
>
>
>
> >
>


--
Abraço,

Wanderley.

"Nada baixa mais o nível da conversa do que elevar a voz". Stanley Horowitz


"...aos loucos a sua impressão de bem-estar os leva à perdição." Pv 1.32b.

"Denunciei a fome como um flagelo fabricado pelos homens, contra outros
homens".
Josué de Castro


Wanderley S

unread,
Feb 13, 2009, 2:32:09 PM2/13/09
to Progre...@googlegroups.com
Marcos, creio que nós concordamos em praticamente tudo - principalmente em que temos que tentar ter o máximo o controle da situação e as suas sugestões certamente funcionam, no limite que você citou, ou seja, que não existe sistema perfeito.
 
Só não posso deixar de responder a seus questionamentos (rs...) - o que eu faço pra não incorrer nesses erros que você citou:
 
1) Quanto ao "programador desavisado" - Com documentação e metodologia se previnem muitos desses problemas, ou seja, na documentação do programa deve estar explicitado o porquê daquele Where e também da cláusula BY (ou break by), que nós acabamos esquecendo na nossa conversa. Na minha prática, sempre uso verificar o Xref. Se eu estou alterando um programa, a partir da minha alteração a responsabilidade é minha ou do tal " programador desavisado". Documento todos os programas que passam por mim. Toda alteração em programa causa alteração na documentação. Mas não há nenhum qualquer restrição em utilizar o USE-INDEX, o que abunda não prejudica.... Lembrando que, toda empresa séria e que preza por qualidade deve utilizar documentação.
 
2) Quanto ao DBA mudar o índice - O progress utiliza por padrão o CRC. Dessa forma, o índice escolhido pelo banco é o do momento da compilação e isso fica gravado no .r gerado. Isso ocorre desde sempre no progress - pelo menos que eu me lembre desde o Progress 6. Nesse caso, numa próxima execução do programa, após a alteração do índice, haverá um erro de CRC e o programa deverá ser revisado e recompilado. Os programas recompilados deverão ser alterados da mesma forma que seriam anteriormente no caso de indicarmos o índice com o Use-Index. A não ser que se trabalhe sem compilar programas... o que não é indicado, também por causa de perda de performance na carga dos programas.
 
Particularmente, eu uso o USE-INDEX quando quero garantir que um determinado relatório ou consulta seja classificado pelo índice desejado e não pelo "melhor" índice, selecionado pelo Progress. Veja que coloquei "melhor", entre aspas.
 
De qualquer forma, acho sempre válido o debate e principalmente as divergências, porque delas é que surge conhecimento.
 
Abraço e um ótimo fim de semana para todos!
 
Wanderley.

2009/2/13 MARCOS BATISTA <BAT...@agraria.com.br>

MARCOS BATISTA

unread,
Feb 13, 2009, 2:53:00 PM2/13/09
to wand...@gmail.com, Progre...@googlegroups.com
Documentação é realmente fundamental, estamos fazendo um trabalho para melhorar a documentação em geral, e registrar tudo é preciso.

Um comentário, por mais simples que seja num código fonte, às vezes, abre um horizonte enorme de entendimento, principalmente para quem não fez o programa.
É como às ves eu digo aos meus colegas: conversem, dialoguem com o código fonte, e escreva nele, na forma de comentário, o que você "diz" a ele.

sds
Batista

>>> wand...@gmail.com 13/02/2009 17:32:09 >>>
Reply all
Reply to author
Forward
0 new messages