Archiving SAP: menos custo de HANA, mais velocidade

Enquanto o mercado fala de migração e IA, o archiving SAP segue sendo a alavanca mais barata para deixar o sistema rápido de novo — e uma das menos usadas. O motivo é simples: gestão de volume de dados não é glamourosa. Os números, no entanto, são: em ambientes que analisamos, uma fração pequena das tabelas concentra a maior parte do banco, e boa parte desse volume é histórico que ninguém consulta — mas que todo mês custa memória de HANA, backup e janela de manutenção.

Por isso, neste artigo mostramos como o archiving SAP funciona na prática, por que ele vale ainda mais antes de uma migração para o S/4HANA e, além disso, como fazemos isso na Inove — inclusive com uma ferramenta própria de análise.

Em uma frase — archiving é a mudança do “arquivo morto” da empresa: os papéis que você não usa todo dia saem da mesa (o banco de dados caro e rápido) e vão para o arquivo (um armazenamento barato), organizados e à mão quando alguém precisar. A mesa fica livre — e tudo continua guardado.

O problema que cresce em silêncio

Todo SAP acumula dados: documentos de material, ordens, notas fiscais, registros de ponto, logs de interface. Como resultado, ano após ano esse volume cobra a conta em quatro lugares:

Memória do HANA. Antes de tudo, o banco em memória é o recurso mais caro do ambiente. Portanto, dado histórico ocupando RAM é dinheiro parado.
Performance. Além disso, relatórios varrendo dezenas de milhões de registros ficam lentos — por exemplo, MB51, FBL3N e consultas de faturamento.
Migração e upgrade. Do mesmo modo, cada teste de conversão para o S/4HANA copia e processa o banco inteiro. Ou seja: volume alto = janelas maiores, mais custo e mais risco.
Backup e DR. Por fim, janela de backup, storage replicado e tempo de restore — tudo cresce junto com o banco.

O iceberg do banco SAP: a maior parte do volume está submersa — histórico que ocupa memória cara sem gerar valor diário. O archiving devolve essa memória.

Por que archiving SAP vem antes da migração

Se o S/4HANA está no seu horizonte, então a ordem importa: arquivar antes de migrar. Cada gigabyte que sai do banco antes da conversão é um gigabyte que você não paga para migrar — em tempo de projeto, em sizing de infraestrutura e em licença de HANA. Em conversões brownfield, por exemplo, reduzir o volume encurta as janelas de downtime e diminui o risco de estouro no fim de semana de cutover. Já detalhamos essa relação no artigo sobre migração para o SAP S/4HANA.

Na prática — em um ambiente industrial que analisamos com nossa ferramenta, o levantamento cobriu 357 tabelas, com análise detalhada por ano e organização em 78 delas. O mapa mostrou o que sempre se repete: poucos objetos concentram o grosso do volume, e o histórico com mais de 5 anos respondia por uma fatia enorme do banco — candidato direto ao arquivamento, sem impacto na operação.

Archiving é parte de algo maior: DVM (Data Volume Management)

Arquivar documentos de negócio é a peça mais conhecida — no entanto, a disciplina completa se chama DVM (Data Volume Management), e a SAP a trata como um programa contínuo, não um projeto pontual. Em resumo, o DVM combina estas frentes:

Prevenção. Primeiro, evitar que o dado nasça: revisar logs de interface, parametrizações de gravação e housekeeping técnico. Tabelas como BALDAT (logs de aplicação), DBTABLOG (log de tabelas), APQD (batch input), TST03 (spool) e as SWW* (workflow) crescem sozinhas — e, no entanto, quase nunca precisam de tudo aquilo.
Anexos e conteúdo. Em seguida, a SOFFCONT1 guarda anexos (GOS/SAP Office) dentro do banco — um clássico: gigabytes de PDFs e imagens ocupando HANA/Oracle. A solução, portanto, é tirar o conteúdo do banco e manter só o vínculo no SAP. Em um cliente do setor de varejo, por exemplo, desenhamos exatamente isso com arquitetura de nuvem moderna: migração dos anexos para o Google Cloud Storage usando o ABAP SDK for Google Cloud — o SAP grava e lê direto no bucket, com custo de storage em objeto (frações do custo do banco) e sem mudar a experiência do usuário.
Sumarização e deleção. Além disso, dados técnicos que podem ser agregados ou simplesmente removidos após o prazo (jobs, spools, IDocs processados).

Do arquivamento ao data tiering — e ao custo

Arquivamento de negócio. Aqui entram os objetos clássicos (FI_DOCUMNT, MM_EKKO, SD_VBAK…), com retenção legal e acesso garantido — o tema central deste artigo.
Data tiering no HANA (NSE). Por fim, para bancos SAP HANA, o Native Storage Extension move o dado “warm” da memória para o disco sem sair do banco — as tabelas continuam consultáveis por SQL normal, mas param de ocupar RAM. Ou seja, é o complemento perfeito do archiving: o histórico recente que ainda precisa de consulta frequente vai para NSE; o antigo, para o arquivo. A combinação certa reduz o sizing de memória (e a licença) sem sacrificar acesso.

Além disso, há um elo direto com o bolso: no RISE with SAP, o contrato é dimensionado pela memória HANA — cada degrau de sizing tem preço. DVM bem feito (archiving + NSE + housekeeping) segura o crescimento do banco e evita subir de degrau na renovação. É FinOps aplicado ao SAP: gestão de volume virando redução direta de assinatura.

Experiência de campo — nossa metodologia de dependências entre objetos nasceu de projetos reais em grandes ambientes: a estrutura de referência que usamos mapeia 25 objetos de arquivamento e 30 dependências (MM, PP, FI, SD, CO, QM, PM), validada em siderurgia de grande porte; e já executamos archiving técnico com plano de cutover em indústria de manufatura, num banco de mais de 14 TB reconciliado segmento a segmento (dados, índices e LOBs).

O que um bom projeto de archiving envolve

Análise de volume por tabela e objeto. Primeiro, as ferramentas do próprio SAP — a TAANA (análise de tabelas) e a DB02 (visão do banco) — mostram onde está o peso: por ano, por organização, por módulo. Sem esse raio-X, portanto, o projeto vira chute.
Mapa de dependências entre objetos. Em seguida, no SAP os objetos de arquivamento (MM_EKKO, RV_LIKP, SD_VBAK, FI_DOCUMNT…) têm ordem: não se arquiva o faturamento antes da remessa. Um projeto sério respeita essa cadeia.
Política de retenção legal. Além disso, o fiscal brasileiro exige guarda longa — ou seja, o dado sai do banco, não do alcance. ILM e store adequado resolvem isso.
Acesso ao dado arquivado. Igualmente, leitura via transação, SARI/ALO ou anexo ao documento — afinal, o usuário não pode “perder” o histórico.
Execução em ondas, sem parar a operação. Por fim, escrita, verificação e deleção controladas, com janelas e monitoramento.

Como a Inove faz — com ferramenta própria

O archiving SAP é uma das nossas especialidades — a ponto, inclusive, de termos construído o SAP Archiving Analyzer, ferramenta própria da Inove que analisa as tabelas do seu ambiente e propõe a estratégia de arquivamento já respeitando as dependências entre objetos:

Raio-X do banco — distribuição por módulo, maiores tabelas, evolução do volume.
Análise por ano e organização — em seguida, quanto de cada tabela é histórico arquivável.
Mapa de dependências — depois, a ordem correta de arquivamento entre os objetos (MM, PP, FI, SD, CO…).
Recomendação priorizada — por fim, por ganho de memória e esforço, para começar pelo que mais devolve.

SAP Archiving Analyzer — visão geral do arquivamento: tamanho do banco, volume arquivável por objeto e potencial por módulo — O Analyzer em ação: 14 TB de banco analisados, objeto a objeto — com % arquivável calculado pela idade real dos dados (TAANA) versus retenção.

SAP Archiving Analyzer — mapa de dependências entre objetos de arquivamento, com prioridades de execução destacadas — O diferencial: o mapa de dependências — a ordem certa de arquivamento entre os objetos, com os prioritários numerados.

Com o diagnóstico na mão, então, executamos a estratégia completa: parametrização dos objetos, retenção legal, store do arquivo, execução em ondas e medição do ganho — memória liberada, performance e custo. Tudo dentro do nosso modelo de sustentação AMS, que mantém a política de arquivamento viva depois do projeto (arquivar uma vez e parar é enxugar gelo).

Nossa visão de sempre: queremos que o cliente não tenha dor de cabeça com TI e seja feliz — com um SAP leve, rápido e mais barato de sustentar.

Por onde começar

Raio-X de volume do seu SAP — onde está o peso, por tabela, ano e organização.
Estratégia de archiving — em seguida, objetos, dependências, retenção legal e store.
Piloto nos objetos de maior impacto — assim, ganho rápido e mensurável.
Rotina contínua — por fim, a política de arquivamento operando dentro da sustentação.

Archiving SAP: o jeito mais barato de deixar seu SAP rápido de novo