SQL Server como contornar o log de transações preenchendo ao atualizar uma coluna para um int


18

Eu tenho uma tabela do SQL Server 2005 chamada BRITTNEY_SPEARS_MARRIAGESe ela possui as seguintes colunas:

MarrigeId tinyint, 
HusbandName varchar(500),
MarrigeLength int

Agora eu tenho outra mesa BRITTNEY_SPEARS_MARRIAGE_STORIES

StoryId int, 
MarriageId tinyint, 
StoryText nvarchar(max)

O problema é que queremos atualizar a MarrigeIdcoluna para um intde a tinyint. Apenas sentimos que Brittney terá muitos casamentos antes que tudo seja dito e feito.

Agora, a BRITTNEY_SPEARS_MARRIAGE_STORIEStabela possui 18 milhões de linhas (ei, a garota tem alguns problemas); portanto, quando fazemos a atualização, o log de transações é preenchido e nossa caixa do SQL Server morre.

Como podemos contornar isso?

Existe alguma maneira de dizer "Ei, SQL Server, eu vou atualizar esta coluna e aumentá-la. Confie em mim neste SQL Server. Por favor, não preencha o log de transações enquanto você tenta validar tudo?"

Respostas:


7

Não há como dizer ao SQL Server para não usar o log de transações.

O que você pode fazer é definir o modelo de recuperação do banco de dados como SIMPLE, que substituirá as entradas de log antigas conforme o espaço necessário. Você não deve fazer isso no servidor de produção, no entanto, porque não poderá executar certos tipos de restaurações, como restaurações pontuais.

Como alternativa, você pode definir seu arquivo de log de transações como maior - como regra geral não científica, eu me certificaria de que A) seu log de transações tenha pelo menos 1,5x mais espaço livre do que o tamanho da sua tabela ou B) que seu log de transações pode crescer automaticamente em uma unidade que tenha pelo menos essa quantidade de espaço livre em disco.

Você pode liberar espaço no log de transações fazendo backup do log. Se você não se importa com o conteúdo do log, jogue o arquivo fora. Um atalho para isso é BACKUP LOG <Your Database Name> TO DISK = 'NUL:'. Novamente, não faça isso em um servidor de produção, a menos que tenha certeza absoluta de que entende as implicações.

Outra coisa a ter cuidado (embora não seja totalmente pertinente à sua pergunta) é garantir que a tabela que você está expandindo tenha um índice em cluster definido nela. Caso contrário, a tabela poderá incorrer em uma quantidade muito grande de fragmentação de heap e potencialmente se tornar desnecessariamente grande em uma alteração como essa.


5
  • Solte todas as chaves estrangeiras
  • Crie novas tabelas com em intvez detinyint
  • Mova as linhas por lote de 1000 (insira-as na nova tabela, exclua-as da antiga)
  • Largue as mesas antigas
  • Renomeie as novas tabelas para os nomes antigos usando sp_rename
  • Recrie as chaves estrangeiras

pS Se o seu log de transações for grande ... verifique seu modelo de recuperação. Se o seu modelo de recuperação não for simple, quanto tempo passou desde o último backup do log?


Você quer dizer que desde que você fez o backup do log, o backup do banco de dados não tornará o log menor.
HLGEM

@HLGEM: Você está certo, acabei de ler um artigo de Paul Randal sobre esse tópico. Um pouco inesperado, porém, se você fizesse backups completos, seu registro continuaria crescendo.
Andomar 27/06
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.