SOFFCONT1 e RSIRPIRL: o passo que parece falha e a perda que ninguém vê

24 agosto 2026

Toda base SAP com alguns anos tem uma tabela que cresceu sem ninguém decidir: a SOFFCONT1. É onde os anexos de GOS — o PDF que alguém arrastou para a ordem, o e-mail que virou documento, a planilha anexada ao pedido — ficam guardados dentro do banco, em vez de num repositório próprio.

Tirar isso de lá é um trabalho conhecido, com um report próprio: o RSIRPIRL. E aí começa a parte que os tutoriais não contam — porque o report tem um modo de operação cujo comportamento normal parece falha, e uma armadilha que causa perda silenciosa de conteúdo.

Em uma frase — no modo delay do RSIRPIRL a categoria do documento continua apontando para o banco depois da execução, e isso é o comportamento correto — não o sinal de que deu errado.

O que o RSIRPIRL faz, e o que ele não faz de imediato

A operação parece direta: você define a categoria de armazenamento nova na OACT, aponta o repositório de conteúdo, roda o RSIRPIRL e os documentos mudam de lugar.

Só que existe o parâmetro P_UPDATE — o “delete later”, o modo delay. Com ele marcado, o report não apaga o conteúdo do repositório de origem na hora. E é aqui que quase todo mundo conclui que a migração falhou:

  • o report termina com sucesso;
  • o documento aparece na tabela SDOK_PRELIM_CONT;
  • mas na SOFFPHIO a categoria continua SOFFDB, e não a nova categoria que você criou.

A expectativa natural é que a SOFFPHIO já mostre a categoria nova. Ela não mostra — e não deveria mostrar ainda. O documento está em estado preliminar, existindo nos dois lugares de propósito.

Por que o modo delay existe

Não é capricho. A própria SAP documenta o motivo na Nota 2991944 — “Introducing the Delay mode in report RSIRPIRL”: às vezes há problema ao criar o documento no repositório de destino. Se o conteúdo já tiver sido apagado da origem nesse momento, recuperá-lo fica muito difícil.

Ou seja: o modo delay é a rede de segurança que falta na maioria dos roteiros publicados. Ele transforma uma operação irreversível em duas etapas, com um ponto de conferência no meio.

A finalização é feita por outro report: o RSIR_CONTENT_UNMARK_PRELIM, que tira a marca de preliminar. Só depois dele o estado final é atingido — e aí sim a origem pode ser liberada.

A perda silenciosa que ninguém procura

Essa é a parte que custa caro e não aparece em nenhum checklist de blog.

Documentos gravados com tamanho de arquivo vazio nas tabelas de arquivo migram para o content server HTTP sem conteúdo. O registro vai, o arquivo não. A mesma nota da SAP diz isso com todas as letras: isso resulta em perda de dados.

E o pior é a assinatura do problema: a migração reporta sucesso. Você só descobre quando alguém tenta abrir o anexo, meses depois, e recebe um arquivo vazio. Nesse ponto a origem já foi limpa.

O recurso entregue pela nota permite excluir esses documentos da migração — mas você precisa saber que eles existem para excluí-los.

Antes de rodar em produção — três verificações que evitam as duas falhas acima: contar quantos documentos têm tamanho zero nas tabelas de arquivo, e decidir o que fazer com eles antes e não durante; confirmar que a nota 2991944 está aplicada, senão o parâmetro P_UPDATE nem existe na sua versão; e combinar quem executa o RSIR_CONTENT_UNMARK_PRELIM e quando — migração que fica em estado preliminar indefinidamente ocupa os dois lados e não economiza nada.

O que dá errado, com nome

Concluir que falhou porque a SOFFPHIO não mudou. É o caso mais comum. O time roda, confere a categoria, vê SOFFDB ainda lá e reverte tudo — desfazendo uma migração que estava correta.

Rodar sem o modo delay para “simplificar”. Funciona até o primeiro documento que o destino recusa. Aí a origem já foi apagada, e a recuperação é um trabalho de arqueologia.

Esquecer a etapa de finalização. O RSIR_CONTENT_UNMARK_PRELIM não roda sozinho. Sem ele, o conteúdo permanece nos dois lugares — e o objetivo era exatamente parar de ocupar o banco.

Migrar tudo de uma vez. Volume alto em janela apertada, sem contagem prévia por faixa, é como a migração vira incidente em vez de projeto.

O limite honesto

Tirar os anexos do banco reduz o tamanho da base, e isso é real. Mas não resolve o que costuma estar por trás do problema: ninguém decidiu o que deveria ser anexado ao SAP em primeiro lugar. A SOFFCONT1 volta a crescer, mais devagar, pelo mesmo motivo de antes.

E há um custo que aparece depois: com o conteúdo fora do banco, a recuperação passa a depender do content server estar no ar e acessível. O que era um problema de espaço vira um problema de disponibilidade — melhor, mas diferente, e precisa de monitoração própria.

Se o ponto de partida é entender quanto do seu banco é anexo e o que dá para tirar, comece pelo archiving SAP — a SOFFCONT1 costuma ser só uma das tabelas grandes. E se o objetivo maior é reduzir o ambiente antes de migrar, veja diagnóstico de TI.