Nossos desenvolvedores (antes de eu ser DBA) definem o tipo de dados para um campo VARCHAR(MAX)quando, na realidade, ele só precisa serVARCHAR(255). Isso só foi descoberto depois que nossa tabela cresceu para mais de vários milhões de registros e quase um terabyte de dados. Quando vou para o modo de design nessa tabela para testar essa alteração em nosso ambiente de teste, descubro que o script criado faz uma cópia da tabela _tmp da tabela e, em seguida, descarta o original e renomeia _tmp para o original. Parece que me lembro de ter aprendido que o motivo por trás disso tinha algo a ver com a necessidade de mover os dados da seção "LOB" de um registro para a seção de comprimento fixo de um registro (pelo menos é o que minha memória recorda). No entanto, não consigo encontrar nenhuma documentação sobre por que exatamente isso ocorre (em vez de apenas alterar o tamanho no local). Alguém pode me indicar a direção certa para que eu possa explicar melhor ao gerenciamento por que fazer essa alteração agora em uma tabela de vários milhões de registros levará muito tempo.
O script que o SSMS gera não é o melhor.
Você deve ser capaz de usar simples
ALTER TABLE:Obviamente, certifique-se de que o texto armazenado nesta coluna caberá no limite de 255 caracteres.
Eu recomendo fortemente experimentá-lo no ambiente de teste primeiro para ter uma ideia de quanto tempo levaria. Não tenho certeza, e pode depender da versão e edição do seu servidor, mas é provável que esse tipo de alteração não seja realizada como uma alteração de metadados, o que significa que para um terabyte de dados seria necessário um significativo quantidade de tempo.
Esta questão ( Por que ALTER COLUMN para NOT NULL causa um crescimento massivo do arquivo de log? ) tem muitos detalhes sobre arquivos
ALTER COLUMN.