SQL Server 2005 Express: a data do arquivo mdf não muda, o arquivo ldf fica enorme

Question

Desculpe se a pergunta foi respondida ou é feita de forma errada - sou desenvolvedor, não administrador de sistema ou banco de dados.

Problema: Um arquivo mdf do SQL Server 2005 Express (tamanho 370 MB) não alterou a data do arquivo por dois meses (mesmo após a reinicialização do servidor), enquanto o arquivo ldf cresceu para 56 GB.

O banco de dados está sendo executado em um servidor Webedition do Windows 2003.

É um cliente importante, eu não quero arriscar nada (então eu não tentei a opção "Shrink" no Management Studio por medo de perder dados ou um longo tempo de inatividade.

Estamos tentando configurar um novo servidor e estamos tentando restaurar o arquivo .bak mais recente, mas ele fica em "Executando 90%" há algum tempo.

O que pode ser feito? 1. Espere muito mais 2. Tente encolher banco de dados original site estará executando 3. Mais alguma coisa

Qualquer ajuda é muito apreciada.

Obrigado Olaf

    

Answer 1

As outras duas respostas estão corretas, mas acho que o motivo subjacente pode não estar aparecendo aqui:

No modo de recuperação Completa, o SQL Server não grava dados no arquivo mdf (dados) ... ele grava somente no log de transações.

A única maneira de obter esses dados no arquivo de dados é fazer um backup do log de transações. Geralmente, é aceito que um banco de dados de produção ativo no modo de recuperação Completa tenha seu log de transações com backup pelo menos uma vez por hora .

As sugestões postadas anteriormente são para mudar temporariamente o banco de dados para o modo de recuperação simples. Nesse modo, o SQL Server não mantém registros de dados de transações (editadas para não confundir algumas pessoas ) no log de transações por qualquer período de tempo. Se você fizer essa alteração, o SQL Server executará vários lotes de disco por uma boa quantidade de tempo, pois confirma as transações no log para o arquivo de dados.

Quando isso estiver concluído, você ainda terá um arquivo de log de transações de 56 GB, e seu arquivo de dados será maior. (não é muito maior, no entanto). O arquivo de log de transação não ficará menor até que você "encolha".

normalmente, isso é algo que você nunca deve fazer

Mas, devido à confusão em que esse banco de dados está, provavelmente é uma boa ideia reduzir o log de transações para talvez metade do tamanho do arquivo de dados após o processo acima.

Em seguida ... mude o banco de dados de volta para Backup completo e coloque imediatamente um plano de manutenção .

Um comentador abaixo sugere que minha resposta está "completamente errada", com base em algumas pequenas lêndeas sendo escolhidas. Eu poderia escolher as mesmas lêndeas com esse comentário e dizer que ele está "completamente errado" também.

• Não quis sugerir que o SQL Server grava seus dados no log de transações. Ele escreve exatamente o que o nome sugere: registros de transações. Lamento que o comentarista não possa deduzir esse fato lendo; Eu não acredito que o OP tenha tal problema, então não achei necessário elaborar.

Mas isso deve ser observado: 'registros de transação' são dados .

Outras observações que faço sugerem claramente que sei muito bem o que o Log de transações contém - como minha afirmação de que, embora o arquivo de dados cresça assim que o TL é salvo, ele não crescerá tanto quanto o tamanho do log de transações. o TL.

• Eu não pretendia declarar - e realmente não acho que o fiz - que mudar o modelo de recuperação muda como o SQL Server grava dados no arquivo de dados. Mas eu afirmei que isso afeta quando dados são gravados no arquivo de dados. O comentador abaixo está escolhendo um nit incrível aqui - e usando palavras extremamente desajeitadas (irrelevantes) para fazê-lo.

O nit sendo escolhido é que o modelo de recuperação muda o que o SQL Server faz com os registros de log de transação. Em Simple , ele persiste essas transações para dados no arquivo de dados e os remove do TL 'rapidamente'. Em Full , ele os deixa sozinhos até que um backup TL seja feito.

Você poderia argumentar que o modelo de recuperação, portanto, não tem nada a ver, especificamente, com o arquivo Dados ou quando os dados são gravados nele. Mas é como argumentar que pressionar o acelerador em seu carro não faz com que o carro se mova mais rápido, porque, bem; tudo o que realmente está fazendo é fazer com que o motor gire mais rápido.

Talvez tecnicamente correto, mas uma adição totalmente inútil de informações no contexto em que estamos falando.

    

Answer 2

Duas opções

1. Altere seu modelo de recuperação para Simples
2. Comece a fazer backups de log de transações (e verifique se você também está fazendo backups completos de banco de dados.)

Algo que você deve fazer:

1. Comece a ler essas coisas ou contrate alguém que já conheça (e possa treiná-lo sobre o que você precisa saber.)

Answer 3

Correr um swerever é como dirigir um carro. Sem saber o que você faz ... você tem problemas. Como você faz.

• date of mdf file doesn't change

IIRC muda quando o arquivo é fechado ... e o SQL Server somente fecha arquivos quando você o desliga.

• ldf file get huge

Porque você não faz backups adequados? Sem BACKUP COMPLETO E DE LOG - o log fica cheio. isso é por design, eu sugiro strnogly que você leia sobre backup de bancos de dados ou você perderá esse cliente.

Para resolver o problema imediato, altere o modelo de recuperação do banco de dados para simples, de modo que nenhuma entrada de log seja mantida a longo prazo. Em seguida, afte um dia ou uma hora, transformando o arquivo de log em um nível gerenciável. Isto é ainda uma situação "você vai loocse o cliente", mas pelo menos o seu disco não funciona cheio.

Para não perder o cliente a longo prazo, certifique-se de ter o nível básico de compreensão da recuperação de saturação do satélite e começar a fazer backups.