SQL Server alterar tabela para alterar TEXT para NVARCHAR (MAX), aumentando significativamente o tamanho do banco de dados


8

Preciso atualizar um banco de dados do SQL Server com cerca de 18 GB de tamanho para alterar um número significativo de TEXTcolunas para NVARCHAR(MAX).

O problema que estou tendo é depois de executar todos os alter tablecomandos que o banco de dados acaba tendo quase 26 GB de tamanho. Entendo que a partir daqui, o uso NVARCHAR(MAX)do DB permitirá que o DB cresça mais lentamente, mas existe alguma maneira de evitar esse inchaço?


2
Oh, não crie a mesma pergunta aqui. Basta sinalizá-lo no SO e os mods o migrarão aqui em um instante :-). Agora alguém precisa mesclar / limpar ... etc.
— Marian

2
O banco de dados é maior ou o log é muito grande?
— Aaron Bertrand

Desculpe Marian, entendo agora ...
— Aidan Lawless

Aaron, o arquivo MDF é muito maior .... quase 10GB maior
— Aidan Lawless

Respostas:


7

Espero que este post seja útil para você.

http://geekswithblogs.net/johnsPerfBlog/archive/2008/04/16/ntext-vs-nvarcharmax-in-sql-2005.aspx

Principais fatos:

  • Por padrão, o TEXT e o NTEXT armazenam o valor do texto na estrutura LOB
  • Por padrão, o NVARCHAR (MAX) armazena o valor do texto na estrutura da tabela (a menos que tenha mais de 8000 bytes)
  • Quando você altera a coluna de TEXT / NTEXT para NVARCHAR (MAX), a maneira como os dados são armazenados não é alterada; ele atualiza apenas os metadados da tabela. A estrutura de dados é alterada apenas na próxima vez que o valor for alterado. Isso pode ser feito imediatamente executando algo como isto:

      update mytable set mycolumn1 = mycolumn1
  • Se você usar a configuração de opção de tabela padrão para NVARCHAR (MAX), os dados em sua tabela serão maiores.

    - Você precisará examinar as configurações e o ambiente das opções da tabela antes de alterar a configuração para o que melhor se adequa às suas necessidades.

  • O tamanho da tabela eventualmente diminuirá se você seguir a instrução alter table com a instrução update table.

Em resumo, se você executar a instrução de atualização, forçando a alteração do armazenamento da estrutura de dados, o tamanho do banco de dados será menor, conforme o esperado.

EDIT : Como você mencionou TEXT e não NTEXT, seu ganho no espaço seria menos óbvio do que você imagina. O NTEXT ocupa o dobro da quantidade de espaço que o TEXT, mas, ao mesmo tempo, você deve esperar que o NVARCHAR (MAX) ocupe cerca de metade do espaço que o NTEXT. Pelo meu cálculo, você veria pouca alteração em relação ao tamanho original do banco de dados.


Crédito especial para http://www.douglubey.com/


2
você poderia resumir aqui os fatos importantes, caso o link fique morto.
— precisa

Como mencionado em outras respostas, TEXT vs. NTEXT terá um impacto no armazenamento, mas não tanto quanto você sugeriu.
— Roka

Obrigado ... Estou adiando há anos ... Fico feliz por estar aqui.
— Roka

Obrigado RoKA, que fez uma diferença significativa em algumas das tabelas em questão. Vou restaurar o banco de dados novamente e fazê-lo de forma incremental para ver os efeitos. Obrigado novamente .....
— Aidan Lawless

O prazer é meu.
— Roka

6

Pode ser um descuido na sua pergunta, mas você está dizendo TEXT para NVARCHAR (máximo) e não NTEXT para NVARCHAR (máximo). Se é isso que você realmente está fazendo, está mudando de ANSI para UNICODE e não deve se surpreender com a necessidade de mais espaço (caracteres de byte único versus caracteres de byte múltiplo).


Sim, é isso que estou fazendo ... embora com base em alguns cálculos simples, não seria responsável pelo tamanho do aumento.
— Aidan Lawless

2
Você já tentou com a sugestão de RoKa?
— Spaghettidba

11
@AidanLawless que cálculos são esses? O tamanho do banco de dados deve aumentar pelo menos o tamanho do TEXTcampo existente - o acesso ao unicode ocupa exatamente o dobro do espaço de armazenamento do ANSI.
— JNK # 03:

2
@JNK ... a menos que esteja usando compactação no 2008 R2 ou melhor, em que a compactação Unicode tratará caracteres ASCII armazenados no NVARCHAR como VARCHAR.
— Aaron Bertrand
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.