23 Setembro 2019

Melhores Práticas em Informatica Powercenter

Este artigo pretende enumerar algumas das melhores práticas aquando da realização de desenvolvimentos em Informatica PowerCenter.

No entanto, se olharmos de uma forma mais genérica para estas recomendações, facilmente se conclui que estas práticas podem ser utilizadas em outras ferramentas, até mesmo em desenvolvimentos do nosso dia a dia.

Passo então a dar a conhecer algumas dessas boas práticas:

     1. Uso de Shared Folder para objetos comuns/partilhados por diferentes integrações

Em cada um dos repositórios existe a pasta DW_COMMON_OBJECTS. Esta pasta, tem como propósito a colocação de todas as Sources, Targets e Transformations que sejam comuns ou para partilha entre diferentes integrações. Aquando da utilização destes objetos em outras pastas do repositório, basta criar um shortcut com base no original.

Fig.1 – Pasta de objetos comuns

Fig.2 –  Atalhos em pasta da integração

Fig.3 – Uso dos atalhos em mapeamento

Desta forma, garantimos que qualquer necessidade de alterar um destes objetos, basta realizar a mesma na DW_COMMON_OBJECTS, que automaticamente fica refletida em todos os mapeamentos onde o shortcut para o objeto existe.

     2. Stop on errors nas sessões

Nas configurações das sessões o parâmetro “Stop on errors” deve ter sempre o valor 1.

 

Fig.4 – Localização do parâmetro nas propriedades da sessão

     3. Source Qualifiers e Lookups sem SQL Override

Devem ser utilizadas sempre as transformações nativas do PWC em detrimento do SQL override do Source Qualifier. As excepções em que o devemos utilizar serão casos pontuais em que seja necessário recorrer a hints:

     I. Utilizar transformações nativas do PWC permite fazer uso do particionamento de mapeamentos do PWC.

     II. Utilizar transformações nativas do PWC permite fazer do pushdown optimization do PWC.

A mesma lógica deve ser aplicada aquando da utilização de Lookups.

     4. Tipo de dados e precisão dos portos

O link entre portos deve garantir sempre o mesmo tipo de dados e precisão. Caso sejam necessárias transformações ao tipo de dados e precisão, devem ser utilizadas as Expression Transformations do PWC.

Fig5 – Objeto Expression Transformation

Fig6 – Localização da Expression Transformation na barra de ferramentas do Designer do PWC

     5. Mapeamentos complexos

Mapeamentos com mais de 40 transformações, devem ser partidos dentro do mesmo mapeamento ou feitos em mais de um mapeamento.

     6. Comentários e descritivos

Nos mapeamentos, sessões, mapllets e workflows devem ser preenchidos os comentários ou descritivos de forma clara em relação ao propósito do objeto, bem como alertas ou particularidades.

A mesma lógica deve ser aplicada nos objetos dentro de um mapeamento.

     7. Renomear as transformações

Todas as transformações de um mapeamento devem ser renomeadas e devendo ficar com o nome default atribuído pelo PWC.

     8. Commit Interval das sessões

O intervalo de commit não deverá ser o default de 10000. O developer deverá dedicar algum tempo, a tentar perceber se este valor deverá ser incrementado ou não. Para isso, deverão ser feitas algumas execuções do mapping de forma a perceber o seu comportamento (tempo de execução aumenta ou diminui).

     9. Parâmetros de memória das sessões

Os parâmetros de memória das sessões nunca devem ter o parâmetro de valor máximo de memória a utilizar a 0. A imagem seguinte demonstra o default, sendo que um ajuste ao valor máximo de memória a utilizar deve ser feito apenas quando o desempenho de execução do mapeamento não seja satisfatório.

     10. Portos das Lookups e Expression Transformations

Apenas devem ser marcados como output os portos que são realmente necessários para prosseguir no mapeamento. Portos que estejam marcados com output quando não o são, ocupam cache, tornando assim o mapeamento mais lento na sua execução.

     11. Pushdown Optimization

Esta opção deve ser utilizada sempre que possível. O seu uso implica um desenho de mapeamentos de acordo com as melhores práticas, ou seja, fazendo uso dos objetos PowerCenter em detrimento do SQL Override do Source Qualifier (devendo ser usado em casos pontuais e muito bem justificados), bem como o uso de procedimentos.

Quando já existir um número considerável de mapeamentos a fazer uso desta opção, deve o suporte DW solicitar junto dos DBAs, a monitorização do uso dos recursos da BD, caso seja necessário redefinir prioridades na BD e ordens de execução dos mapeamentos.

Para ativar esta opção devem ser efetuados os seguintes passos na sessão:

Fig.7 – Opções obrigatórias para ativar o pushdown optimization.

As sequências são opcionais, dependendo se o mapeamento faz uso das mesmas.

Fig.8 – Verificar o plano de execução

Fig.9 – Consideramos um mapeamento bem implementado quando o plano de execução do pushdown é total

O plano de execução (figura acima), caso não seja possível um pushdown total, indica os motivos para essa quebra, ajudando assim o developer no que deve alterar no seu mapeamento ou configurações da sessão.

Em tom de conclusão, espero que ao verificarem cada um destes 11 pontos, tenham a perceção que, para além da performance, estes visam também melhorar a escalabilidade e adaptabilidade dos desenvolvimentos, bem como a organização de todos os desenvolvimentos, para uma melhor análise e compreensão dos mesmos.

 

Pedro Almeida
Senior Consultant
Blog