Eu tenho uma tabela em um banco de dados no servidor Microsoft SQL Server 2005 com 16 GB de tamanho e 58 milhões de linhas.
Tem uma coluna chamada 'balance_forward' que é char(10) (Escolha incomum para uma coluna numérica, mas não projetei a tabela) Preciso aumentar seu tamanho para acomodar saldos com mais de dez caracteres (xxxxxxxxx. xx)
Tentei alterá-lo para char(12) (arriscado, não dou desculpas), mas acho que* isso fez com que o arquivo de log do banco de dados crescesse muitos gigabytes (e enchesse a unidade de log) e a operação falhou de qualquer maneira (o tipo de dados ainda é char(10))
Mais tarde, percebi que faria mais sentido mudar para pelo menos varchar(12), dessa forma a coluna não ocuparia mais espaço à força, mas teria mais espaço para acomodar dados maiores.
Minha pergunta é - isso também fará com que o arquivo de log cresça novamente (consegui liberar algum espaço movendo outros arquivos para fora da unidade de log)
E estou correto ao supor que usar varchar em vez de char impedirá que os dados existentes ocupem mais espaço?
(Idealmente, o tipo de dados deve ser alterado para o tipo mais apropriado para saldos financeiros, mas acho que será uma mudança mais drástica em 58 milhões de linhas)
* Não tenho certeza. Eu pensei ter visto muito espaço na unidade de log antes da operação, mas posso ter visto 'mb' e confundido com 'gb'. Então pode ser que o log já tenha preenchido o drive. Aparentemente, os logs podem crescer até preencherem a unidade/espaço alocado
Com base nesta e nesta postagem, eu diria que sim, a alteração de
char(10)paravarchar(12)tocará todas as linhas e, portanto, aumentará o log. Meu raciocínio é que a coluna mudou da parte de comprimento fixo para a parte de comprimento variável da estrutura de linha e o mecanismo de armazenamento terá que persistir essa informação imediatamente.As colunas de comprimento variável terão uma sobrecarga de dois bytes para rastrear o comprimento real (veja acima). Se o comprimento médio de seus dados for de 8 bytes ou menos, você terá um vencedor com esta mudança. Caso contrário, você estará ocupando mais espaço com um arquivo
varchar.Os dígitos necessários podem ser armazenados em 9 bytes com um tipo numérico . Isso seria uma mudança muito grande em seu aplicativo, eu suspeito, mesmo que seja a maneira correta de manter esses dados.
Sugiro que você adicione uma nova coluna anulável do tipo e comprimento corretos. A partir da postagem acima, esta será uma operação apenas de metadados com registro mínimo. Coloque gatilhos para manter a nova coluna sincronizada com a existente. Em seguida, seu aplicativo pode continuar funcionando enquanto as etapas a seguir acontecem. Copie os dados existentes em blocos. Teste em sua caixa de desenvolvimento para descobrir qual tamanho de bloco fornece o equilíbrio certo de tempo decorrido e tamanho de log para seu sistema. Na minha experiência, 10.000 é o certo. Depois que tudo estiver no lugar, elimine a coluna e os gatilhos antigos e renomeie a nova coluna. Uma reconstrução de índice será necessária para recuperar espaço. Aqui estão algumas postagens do SO que tratam desse assunto.