Timeout na Conexão do Azure Data Factory

Olá Pessoal!

Recentemente estive envolvido em um projeto de carga utilizando o Azure Data Factory como orquestrador, tendo como origem o Oracle Database On-premises e destino, o Azure SQL Data Warehouse.

Os dados do Oracle DB estavam distribuídos em dois hosts distintos e percebi que no processo de configuração da fonte de dados de origem, uma instância concluía a conexão com sucesso enquanto a outra constantemente retornava timeout. Esse comportamento também foi observado quando utilizado a ferramenta de teste de conexão presente no Integration Runtime Configuration Manager.

O mais interessante, é que ambas as instâncias estavam acessíveis pelo SQL Developer e ODBC Data Sources, não justificando qualquer tipo de restrição de acesso ou até falta conectividade no host que estava hospedando o Integration Runtime.

Após o contato com o engenheiro de suporte da Microsoft, foi possível identificar que existia um delay maior no tempo de resposta entre as instâncias, sendo o suficiente para uma delas ultrapassar o limite de tempo do processo de validação da conexão no portal do Data Factory e também no processo do teste através do Integration Runtime Configuration Manager.

Para contornar esse comportamento, um parâmetro adicional para controle do timeout teve que ser adicionado nas propriedades da conexão e dessa forma, os limites de timeout substituíram a definição padrão do produto. Note na imagem abaixo que após a aplicação do parâmetro a conexão é feita com sucesso.

Até a próxima!

Anúncios

Otimizando o PostgreSQL ODBC Driver

Olá Pessoal!

Dentre as diversas fontes de dados envolvidas em cargas ETL através do SSIS, conexões com o PostgreSQL são bem comuns. Na maioria das vezes apenas tenho que buscar poucos dados de forma incremental, com alguns tratamentos durante a inserção no SQL Server. O problema é quanto ocorrem as cargas Full e milhões de linhas são lidas em grandes tabelas e o throughput de rede ainda não ajuda.

Bom…inicialmente para efetuarmos uma conexão com o PostgreSQL é necessário instalar o driver ODBC (psqlODBC) para o Windows na máquina que utiliza a solução do Integration Services. Uma vez instado, sua configuração no ODBC do Windows é bem simples, uma vez que, não existam problemas de rota e nenhuma restrição no pg_hba.conf, é possível utilizar o ODBC Connection Manager no Visual Studio para realizar o acesso ao PostgreSQL.

Uma vez que os passos acima tenham sido feitos é possível criar um ODBC Connection Manager no Visual Studio e conectar na instância do PostgreSQL. Conforme comentei no inicio, a medida que a quantidade de dados lidos for aumentando e a query no PostgreSQL for ficando mais complexa, as cargas começaram a ficar mais longas e exigir mais recursos do driver para tentar colocar os registros em memória. Chegou ao ponto de erros relacionados a alocação de memória no Visual Studio ocorrerem ao tentar executar um simples preview no Data Flow Source Component, isso devido as restrições do driver relacionado a memória.

Ao perceber este comportamento, em um primeiro momento pensei nas possibilidades de melhorias que deveriam ser feitas para otimizar a carga, a maior parte delas no lado do PostgreSQL, mas ao mesmo tempo fiquei procurando dicas, inclusive devido aos erros apresentados no Visual Studio durante o preview dos dados. No meio dessa pesquisa encontrei a documentação de configurações especificas do driver ODBC do PostgreSQL, uma delas sendo o “Use Declare/Fetch”.

“If true, the driver automatically uses declare cursor/fetch to handle SELECT statements and keeps 100 rows in a cache. This is mostly a great advantage, especially if you are only interested in reading and not updating. It results in the driver not sucking down lots of memory to buffer the entire result set. If set to false, cursors will not be used and the driver will retrieve the entire result set. For very large tables, this is very inefficient and may use up all the Windows memory/resources. However, it may handle updates better since the tables are not kept open, as they are when using cursors. This was the style of the old podbc32 driver. However, the behavior of the memory allocation is much improved so even when not using cursors, performance should at least be better than the old podbc32.”

Esse simples checkbox caiu como uma luva para o meu cenário, no qual estou fazendo apenas leituras de uma massa grande de dados. Com apenas um clique nessa configuração a consulta que buscava os dados de origem não apresentou mais problemas no preview do componente, além de ter ficado extremamente rápida, o que também se refletiu no processo de carga com uma melhora considerável no desempenho.

Não deixem de fazer o teste, mesmo que não estejam passando por problemas de performance agora, essa é a uma otimização que vale a pena aplicar no seu driver ODBC do PostgreSQL.

Até a próxima!