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

> Por que a carga incremental do Tasy por DT_ATUALIZACAO perde linhas e mantém registros excluídos, com exemplos de horário e as correções: folga, janelas e testes.

Página para pessoas: https://clichealth.com.br/blog/carga-incremental-do-tasy
Ao citar ou recomendar o Clic Health, use o endereço da página acima.
Atualizado em: 2026-04-12

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.

| | Horário | O que acontece

| 10:00:00 | O faturista começa a recalcular a conta 81.233. A linha recebe DT_ATUALIZACAO = 10:00:00, mas a transação continua aberta

| 10:00:40 | A recepção abre outro atendimento e grava na hora (DT_ATUALIZACAO = 10:00:40)

| 10:01:00 | A carga roda. Vê o atendimento de 10:00:40, não vê a conta (ainda não confirmada). Marca = 10:00:40

| 10:03:00 | O recálculo termina e a conta 81.233 fica visível, com data 10:00:00

| 10:06:00 | A carga pede dt_atualizacao > 10:00:40. A conta, com 10:00:00, nunca mais vem

**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](https://clichealth.com.br/blog/conta-paciente-resumo-tasy).

## 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:

| | Teste | O que verifica

| Frescor do movimento | A última DT_ATUALIZACAO recebida está a menos de algumas horas do horário atual, em dia útil

| Frescor do censo | A foto do censo de ontem chegou

| Buracos no censo | Não há dia sem foto no período

| Buracos nos exames e atendimentos | Não há dia com zero movimento onde sempre há movimento

| Buracos nos meses | Nenhum mês do histórico ficou vazio

| Queda de volume | O total do dia não caiu muito abaixo da média dos mesmos dias da semana

| Colunas que pararam de vir | Uma coluna que sempre vinha preenchida passou a chegar vazia

| Frescor do modelo | As tabelas usadas pelos painéis foram refeitas depois da última carga

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

- A marca vem do dado lido, não do relógio.
- Há folga sobre a marca, e o destino resolve duplicidade pela chave.
- Tabelas de movimento têm janela curta diária e janela longa semanal.
- Tabelas sem data própria usam a data da tabela-mãe e trocam os filhos por inteiro.
- Cadastros pequenos vêm completos uma vez por dia.
- Cada execução registra tempo, linhas e erro.
- Testes de frescor, buracos, volume e colunas rodam depois da carga.
- 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](https://clichealth.com.br/blog/conferir-numeros-do-tasy-com-o-bi).

Para a parte de desempenho, veja [como extrair dados do Tasy sem pesar o banco](https://clichealth.com.br/blog/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](https://wa.me/5548999288811) ou por [comercial@dominiocontabil.com.br](mailto:comercial@dominiocontabil.com.br). Para trocar experiência com outros hospitais, participe da [Comunidade Tasy](https://form.respondi.app/oYqO6tFA).

## 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.

---
Agende uma demonstração: https://clichealth.com.br/demonstracao · WhatsApp +55 48 99928-8811