Carga incremental do Tasy: por que linhas somem e como evitar

A carga incremental do Tasy é a forma certa de manter um BI atualizado sem pesar o banco: em vez de ler a tabela inteira, a rotina traz só as linhas alteradas desde a última execução, pela coluna DT_ATUALIZACAO. O problema é que, feita da forma mais simples, ela perde linhas sem avisar. O BI mostra 1.212 atendimentos no mês e o relatório do Tasy mostra 1.215, e ninguém sabe onde estão os três.

Este artigo mostra os cinco casos que encontramos com mais frequência e a correção de cada um.

Como a carga incremental funciona

A cada execução, a rotina guarda uma marca: o maior valor de DT_ATUALIZACAO que leu. Na execução seguinte, pede ao Tasy só o que tem data maior que a marca.

SELECT nr_atendimento, ie_tipo_atendimento, dt_entrada, dt_alta, dt_atualizacao
  FROM atendimento_paciente
 WHERE dt_atualizacao > :ultima_marca
 ORDER BY dt_atualizacao

Simples e leve. Os problemas aparecem nas situações em que DT_ATUALIZACAO não conta a história inteira.

Caso 1: a transação que termina tarde

O Tasy grava DT_ATUALIZACAO no momento em que altera a linha, mas a alteração só fica visível para outras sessões quando a transação termina (o commit). Se a transação demora, uma carga pode passar no meio e avançar a marca além dela.

Correção: folga. Cada carga relê também os últimos minutos antes da marca (dt_atualizacao > marca - 15 minutos). As linhas relidas em duplicidade são resolvidas no destino pela chave da tabela, ficando a versão mais recente. Quinze minutos cobrem a quase totalidade das transações do dia a dia; rotinas de lote muito longas pedem folga maior naquela tabela.

Caso 2: a linha excluída

Quando uma linha é apagada no Tasy, não sobra DT_ATUALIZACAO para a carga encontrar. Um atendimento lançado em duplicidade e excluído pela recepção, ou um item retirado da conta, continua no BI para sempre.

Correção: janelas de releitura. Periodicamente, a carga relê um intervalo recente pela data do negócio (DT_ENTRADA no atendimento, período da conta) e, no destino, apaga o que estava naquele intervalo e não veio de novo. No Padrão Clic Health usamos duas janelas em cada tabela de movimento: os últimos 7 dias, toda madrugada, e os últimos 3 meses, todo domingo. Exclusões mais antigas que isso são raras e aparecem na conferência mensal.

Caso 3: a tabela sem DT_ATUALIZACAO

Algumas tabelas não têm a coluna, ou têm e ela não muda quando a linha muda. O caso mais importante é CONTA_PACIENTE_RESUMO, que o Tasy refaz por inteiro quando a conta é recalculada.

Correção: usar a data da tabela-mãe e trocar os filhos por inteiro. A carga do resumo filtra pela DT_ATUALIZACAO de CONTA_PACIENTE e, no destino, cada conta que mudou tem o resumo inteiro substituído pelo que acabou de chegar. Acrescentar ou atualizar linha a linha soma itens que o Tasy já removeu. O exemplo completo, com valores, está em CONTA_PACIENTE_RESUMO: por que o resumo pode somar duas vezes.

Caso 4: atualização que não mexe na data

Algumas rotinas internas e correções feitas direto no banco alteram valores sem atualizar DT_ATUALIZACAO. A carga incremental não tem como perceber.

Correção: as mesmas janelas do caso 2 refletem essas alterações dentro do intervalo relido. Para correções em massa feitas pelo TI ou pelo fornecedor, combine um aviso: depois delas, uma recarga da tabela afetada resolve.

Caso 5: relógio e fuso

Se a marca é calculada pelo relógio do servidor de extração, e não pelo valor que veio do banco, qualquer diferença entre os relógios vira buraco. O mesmo vale para servidores em fusos diferentes.

Correção: a marca é sempre o maior DT_ATUALIZACAO lido, como veio do Tasy, nunca a hora da execução.

Os testes que avisam antes do painel

Mesmo com as correções, vale ter testes automáticos depois de cada carga. Os que usamos no Padrão Clic Health:

O teste de colunas pega um problema comum depois de atualização do Tasy: a coluna mudou de nome ou de lugar, a consulta continua rodando e o campo chega vazio.

Checklist da carga incremental

1. A marca vem do dado lido, não do relógio.
2. Há folga sobre a marca, e o destino resolve duplicidade pela chave.
3. Tabelas de movimento têm janela curta diária e janela longa semanal.
4. Tabelas sem data própria usam a data da tabela-mãe e trocam os filhos por inteiro.
5. Cadastros pequenos vêm completos uma vez por dia.
6. Cada execução registra tempo, linhas e erro.
7. Testes de frescor, buracos, volume e colunas rodam depois da carga.
8. Todo mês, o total do BI é conferido contra o relatório do Tasy, como em como conferir os números do Tasy com o BI.

Para a parte de desempenho, veja como extrair dados do Tasy sem pesar o banco.

Quem escreve

As correções deste artigo vieram de conferências reais entre o Tasy e o BI em hospitais que acompanhamos. A Domínio trabalha há mais de 20 anos com hospitais que usam o Tasy; se a sua carga está com diferença e você não acha a causa, fale com a gente pelo WhatsApp ou por comercial@dominiocontabil.com.br. Para trocar experiência com outros hospitais, participe da Comunidade Tasy.

Perguntas relacionadas

Qual folga usar sobre a marca?

Quinze minutos atendem a rotina normal. Se o hospital tem processamentos em lote longos numa tabela, como recálculo de contas em massa, aumente a folga dessa tabela.

A folga não traz linhas repetidas?

Traz, e é proposital. O destino grava pela chave da tabela e fica com a versão mais recente de cada linha.

Por que não reler tudo toda noite?

Para tabelas pequenas, é o que fazemos. Para as grandes, reler anos de histórico todo dia pesa no banco sem necessidade; as janelas de 7 dias e 3 meses resolvem quase todos os casos.

Como saber se estou perdendo linhas hoje?

Compare a contagem de um mês fechado no BI com a do Tasy, por dia. Diferenças espalhadas em dias aleatórios costumam ser transação tardia; linhas a mais no BI costumam ser exclusões.