Numa operação SAP dentro de casa, o banco crescer é um problema de infraestrutura. Alguém compra disco, o backup demora mais, a vida segue. No RISE, é um item de fatura — e um item que você renegocia da pior posição possível: no meio do contrato, com o sistema já em produção e sem alternativa de fornecedor.

É a diferença que quase ninguém considera na assinatura. O contrato fecha um volume, o volume é dimensionado com o dado de hoje, e o crescimento dos três a cinco anos seguintes é cobrado a preço de meio de termo.

Por que crescer custa diferente no RISE

Três características do modelo se combinam, e o efeito delas é multiplicativo, não somado.

O volume é contratual, não técnico. Você não compra disco — você compra um direito de volume. Ultrapassar não gera lentidão, gera cobrança adicional por GB, negociada quando você já está dentro.

O dimensionamento anda em degraus. A memória HANA não é vendida por GB avulso: existe uma base contratada e extensões vendidas em bloco. Crescer alguns gigabytes além do degrau obriga a comprar o degrau inteiro seguinte. O custo não é proporcional ao crescimento — é uma escada.

O prazo é longo. Contratos de três a cinco anos significam que uma decisão de dimensionamento errada não é corrigida no ano seguinte: ela é paga até o fim do termo.

Some as três e aparece a assimetria que importa: o momento de agir é antes de encostar no degrau. Depois de subir, reduzir o volume raramente devolve dinheiro — o compromisso já está assinado. O valor de tirar peso do banco não está em desfazer o degrau que você pagou; está em não pagar o próximo.

A SOFFCONT1 é o candidato mais óbvio que existe

Toda base SAP com alguns anos tem essa tabela crescida sem decisão de ninguém. É onde os anexos de GOS ficam guardados dentro do banco: o PDF que alguém arrastou para a ordem, o e-mail que virou documento, a planilha anexada ao pedido.

Ela é o alvo certo por três motivos que raramente coincidem:

Não é dado de negócio. Tirar linha de documento contábil de lá exige projeto de arquivamento, regra de retenção e conversa com fiscal e auditoria. Anexo não — ele continua existindo e continua acessível, só que em outro lugar.

Ninguém decidiu colocar ali. É o comportamento padrão quando nenhum repositório de conteúdo foi configurado. Não há regra de negócio a preservar, há uma configuração que nunca foi feita.

Não para de crescer. É a única parte do banco que cresce com o hábito das pessoas, não com o volume de transações. E hábito não diminui sozinho.

Como o Cloud Storage vira repositório de conteúdo do SAP

Aqui está a parte que muda a conta, e ela é menos conhecida do que deveria.

O SAP guarda conteúdo externo através do ArchiveLink, e o ArchiveLink fala com um content server HTTP. Historicamente isso significava uma máquina a mais: instalar o SAP Content Server, licenciar, monitorar, atualizar, incluir no plano de recuperação. Boa parte do ganho de tirar o anexo do banco ia embora nesse servidor.

O ABAP SDK for Google Cloud resolve isso de um jeito elegante: ele traz um handler HTTP escrito em ABAP, publicado num nó do SICF dentro do próprio sistema. O ArchiveLink enxerga aquilo como um content server comum; o handler recebe a chamada e grava — ou lê — o objeto direto no bucket do Cloud Storage.

O sistema conversa com ele mesmo, e o único componente novo na paisagem é um bucket. Não há servidor de conteúdo para instalar, licenciar ou manter.

O desenho fica assim, em quatro peças:

• uma conta de serviço do Google Cloud com permissão de escrita no bucket;
• o nó SICF que publica o handler do SDK;
• um repositório de conteúdo criado na OAC0, do tipo content server HTTP, apontando para esse nó;
• a ligação dos tipos de documento ao repositório, na OAC3, para que o anexo novo já nasça fora do banco.

Para o que já está dentro da SOFFCONT1, a realocação é feita pelo report próprio do SAP — e é aí que mora a armadilha, que tratamos em detalhe em SOFFCONT1 e RSIRPIRL: o passo que parece falha. Vale ler antes de rodar, não depois.

Duas notas de realidade sobre o SDK: a edição que serve aqui é a “on-premises or any cloud”, que é a suportada em S/4HANA Cloud Private Edition — ou seja, RISE. E o limite de tamanho por objeto é o do próprio Cloud Storage, 5 TB, que para anexo de GOS é folga sem fim.

A conta — e os dois números que só você tem

Não dá para publicar o cálculo pronto, porque metade dele está no seu contrato. Mas a estrutura é simples e cabe numa planilha de uma aba.

Do seu lado do SAP, três medidas: quantos GB a SOFFCONT1 ocupa hoje; quanto ela cresceu nos últimos doze meses; e a quantos GB você está do próximo degrau de dimensionamento. Essa terceira é a que decide a urgência — e é a que quase ninguém tem à mão.

Do lado do contrato, um número: quanto custa o GB adicional no seu acordo, no preço de hoje e não no da assinatura.

Do lado do Google Cloud, uma escolha: a classe de armazenamento. Anexo que o usuário abre da tela do pedido precisa de classe padrão, com leitura imediata. Anexo de exercício encerrado, que só volta em auditoria, cabe em classe fria — muito mais barata por GB, com custo de recuperação quando é lido. Misturar as duas é o erro caro: colocar anexo vivo em classe fria transforma cada clique do usuário numa espera e numa taxa.

A ordem de grandeza costuma ser tão desigual que a planilha responde sozinha. O que ela não responde — e por isso está na seção seguinte — é se o resultado aparece na fatura ou só na próxima renovação.

O que dá errado, com nome

Achar que reduzir o banco reduz a fatura deste mês. Não reduz. O compromisso de volume está assinado. O ganho aparece quando o próximo degrau não é necessário — o que é enorme, e é diferente de economia imediata. Prometer a segunda coisa para aprovar o projeto é como o projeto perde credibilidade no primeiro relatório.

Tratar como projeto técnico dentro de um sistema que não é seu. No RISE quem opera é a SAP. Instalar o transporte do SDK, criar nó no SICF e abrir a saída de rede até o bucket passam pelo processo de operação do contrato. Fazer isso como surpresa não é agilidade — é criar uma discussão de fronteira de suporte no pior momento.

Confundir tirar do banco com apagar. A tabela guarda o conteúdo real do anexo. Todo o valor está em realocar; nada dele está em deletar.

Trocar um problema de espaço por um de disponibilidade. Com o conteúdo fora do banco, abrir o anexo passa a depender de rede e do bucket responder. É uma troca boa, mas é uma troca — e o que era monitorado pelo time de banco agora precisa de monitoração própria.

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 crescimento. Não resolve o que está por trás dele: ninguém decidiu o que deveria ser anexado ao SAP em primeiro lugar. A tabela volta a crescer, mais devagar, pelo mesmo motivo de antes. Sem uma regra sobre o que se anexa e por quanto tempo, isso é adiar, não corrigir.

Também não é a única fonte de peso. Anexo costuma ser a maior parte que dá para tirar sem projeto de negócio, mas se o objetivo é reduzir de fato o ambiente, ele é o começo — e o resto exige arquivamento com regra de retenção, que é outro trabalho e outra conversa.

E há o custo que muda de lugar em vez de sumir: sai da fatura da SAP e entra na do Google Cloud. Muito menor, com ordem de grandeza a seu favor — mas passa a existir, a precisar de dono e de acompanhamento.

Se o ponto de partida é saber quanto do seu banco é anexo e o que dá para tirar, comece pelo archiving SAP — a SOFFCONT1 costuma ser só uma das tabelas grandes. Se a conversa é sobre o contrato inteiro e não só sobre espaço, veja FinOps no SAP RISE. E se o objetivo maior é entender o ambiente antes de mexer nele, o caminho é o diagnóstico de TI.

Perguntas frequentes