[Power Alerts] Alerta colunas do tipo Int ou BigInt chegando próximo do limite

Um dos alertas que temos disponíveis atualmente no Power Alerts é sobre a definição de que a coluna INT está perto de chegar ao limite. Isso nos ajuda a identificar preventivamente um grande problema que pode fazer com que a aplicação pare de funcionar. O envio do alerta é feito de acordo com um valor de 750.000.000 registros (Valor customizável) que faltam para estourar o tamanho total do INT.

O alerta já é enviado com as informações de coluna – tabela – banco de dados.

Nossa avaliação nesses casos, começa a partir das informações descritas acima. Com base nisso, avaliamos:

• Quantidade total de registros e tamanho da tabela.

• A quantidade máxima de registros de dados do tipo int é de 2.147.483.647. Levando em conta que o valor máximo do campo ID está em 1.619.947.002, ainda restam 527.536.645 registros a serem inseridos. Também é gerado um gráfico com essa análise, conforme abaixo:

Com a implantação do Power Alerts temos um histórico de crescimento das tabelas e podemos ter uma média de crescimento das informações, o que nos ajuda a tomar decisões de acordo com a urgência.

Um ponto importante a ser validado, é verificar a forma com que esses dados são inseridos: se são inseridos aleatoriamente ou sequencialmente. Em caso de ser aleatoriamente, como por exemplo um número de série, isso poderia gerar um falso positivo em função do tamanho do número, e não pelo valor em si. Caso o valor seja inserido sequencialmente como um identity, sequence ou pela aplicação, este alerta se torna ainda mais importante, pois temos que tratar este campo para que os dados possam continuar a ser inseridos sem erros.

Caso a inserção neste campo seja aleatória, verificar com o cliente ou com o dono da APP se esta verificação pode ser ignorada para este campo específico.  

Estratégias que podemos avaliar para a solução dos casos:

•  Realizar um alter table para alterar o campo de INT para BIGINT: nesse caso recomenda-se ser executado em tabelas pequenas. Caso seja tabelas maiores, indicamos uma estratégias de migração dos dados para uma nova tabela (já com o campo BIGINT) sendo possíveis estratégias como INSERT INTO com TABLOCK, insert pararel, import/export,insert em blocos. Em todas as possíveis opções temos que validar se existe disco no ambiente que comporte o crescimento do log. Além de validação dos relacionamentos e índices da tabela, e iniciando a validação em ambiente de homologação.
• Resetar a identity, assim os novos registros seriam inseridos a partir do ID 1. Nesse caso é necessário avaliar se não causará nenhum conflito com dados de histórico, relacionamentos, índices.

Sendo assim, conseguimos fazer uma análise bem completa, com os cenários mapeados e alinhamento de todas as estratégias com o cliente. É importante enfatizarmos que toda essa análise e sugestão de melhorias deve ser feita de acordo com cada particularidade do cliente, por exemplo, features SQL Server, carga de trabalho atual do ambiente, discos e PRINCIPALMENTE regras de negócio da aplicação.