[IT168 Server Academy] Os logs de transações são uma parte muito importante, mas frequentemente ignorada, da estrutura do banco de dados. Como não é tão ativo quanto o esquema do banco de dados, poucas pessoas prestam atenção ao log de transações.
O log de transações é um registro de alterações no banco de dados. Ele pode registrar qualquer operação no banco de dados e salvar os resultados da gravação em um arquivo separado. Para cada processo de transação, o log de transações possui registros muito abrangentes e os arquivos de dados podem ser restaurados ao estado anterior à transação com base nesses registros. Desde o início da ação da transação, o log de transações está em estado de gravação. Quaisquer operações no banco de dados durante a transação estão dentro do escopo de gravação. A gravação não é concluída até que o usuário clique em enviar ou voltar. Cada banco de dados possui pelo menos um log de transações e um arquivo de dados.
Por motivos de desempenho, o SQL Server armazena as alterações do usuário no cache. Essas alterações são imediatamente gravadas no log de transações, mas não no arquivo de dados. O log de transações usa um ponto de marcação para determinar se uma transação gravou dados do cache no arquivo de dados. Quando o SQL Server for reiniciado, ele verificará o ponto de marcação mais recente no log e apagará os registros de transação após esse ponto de marcação, porque esses registros de transação não gravam realmente os dados do cache no arquivo de dados. Isso evita que as transações interrompidas modifiquem os arquivos de dados.
Manter o log de transações
Como muitas pessoas costumam esquecer o log de transações, isso também pode trazer alguns problemas ao sistema. À medida que o sistema continua a funcionar, mais e mais registros de log serão registrados e o tamanho dos arquivos de log também se tornará cada vez maior, eventualmente levando a espaço em disco disponível insuficiente. A menos que os logs sejam limpos com frequência no trabalho diário, os arquivos de log acabarão por ocupar todo o espaço disponível na partição. A configuração padrão do log é capacidade ilimitada. Se você trabalhar nesta configuração, ele continuará a se expandir e eventualmente ocupará todo o espaço disponível. Ambas as situações podem fazer com que o banco de dados pare de funcionar.
O backup de rotina dos logs de transações pode impedir efetivamente que os arquivos de log consumam espaço excessivo em disco. O processo de backup trunca partes do log que não são mais necessárias. O método de truncamento consiste primeiro em marcar os registros antigos como inativos e, em seguida, substituir os novos logs no local dos logs antigos, evitando assim que o log de transações aumente de tamanho. Se não for possível realizar backups regulares do log, é melhor definir o banco de dados para "modelo de recuperação simples". Neste modo, o sistema forçará o log de transações a truncar automaticamente cada vez que um ponto de marcação for registrado, substituindo o log antigo por um novo log.
O processo de truncamento ocorre ao fazer backup ou marcar pontos antigos como inativos, o que permite que registros de transações antigos sejam sobrescritos, mas não reduz o espaço real em disco ocupado pelo log de transações. Mesmo que o log não seja mais utilizado, ele ainda ocupará uma certa quantidade de espaço. Portanto, durante a manutenção, o log de transações também precisa ser compactado. Os logs de transações são compactados pela exclusão de registros inativos, reduzindo assim o espaço físico no disco rígido ocupado pelos arquivos de log.
O arquivo de log de transações do banco de dados atual pode ser compactado usando a instrução DBCC SHRINKDATABASE. A instrução DBCC SHRINKFILE é usada para compactar o arquivo de log de transações especificado. Além disso, a operação de compactação automática também pode ser ativada no banco de dados. Quando um log é compactado, os registros antigos são primeiro marcados como inativos e, em seguida, os registros marcados como inativos são completamente excluídos. Dependendo do método de compactação usado, você poderá não ver os resultados imediatamente. Idealmente, o trabalho de compactação deve ser realizado durante períodos em que o sistema não esteja muito ocupado, caso contrário poderá afetar o desempenho do banco de dados.
A restauração
do backup do registro de transações do banco de dados pode ser usada para restaurar o banco de dados para um estado especificado, mas o backup do registro de transações em si não é suficiente para concluir a tarefa de restauração do banco de dados, e os arquivos de dados de backup também precisam participar do trabalho de recuperação. Ao restaurar um banco de dados, a primeira etapa é restaurar os arquivos de dados. Não defina todo o arquivo de dados para o estado concluído até que todo o arquivo de dados seja restaurado, caso contrário, o log de transações não será restaurado. Quando a recuperação do arquivo de dados for concluída, o sistema restaurará o banco de dados ao estado desejado pelo usuário por meio do backup do log de transações. Se houver backups de vários arquivos de log após o último backup do banco de dados, o programa de backup irá restaurá-los em sequência de acordo com a hora em que foram criados.
Outro processo chamado envio de log pode fornecer recursos mais fortes de backup de banco de dados. Quando o envio de logs é configurado, ele pode copiar todo o banco de dados para outro servidor. Nesse caso, os logs de transações também são enviados periodicamente ao servidor de backup para recuperação de dados. Isso mantém o servidor em um estado de backup ativo, atualizando-o conforme os dados são alterados. O outro servidor é chamado de servidor monitor e pode ser usado para monitorar sinais de envio enviados em intervalos especificados. Se nenhum sinal for recebido dentro do tempo especificado, o servidor de monitoramento registrará esse evento no log de eventos. Esse mecanismo faz com que o envio de logs seja frequentemente usado em planos de recuperação de desastres.
O log de transações deotimização de desempenho
desempenha um papel importante no banco de dados e também tem um certo impacto no desempenho geral do sistema. Através de diversas opções, podemos otimizar o desempenho do log de transações. Como o log de transações é um processo contínuo de gravação em disco, nenhuma leitura ocorre durante esse processo. Portanto, colocar o arquivo de log em um disco independente desempenhará um papel importante na otimização do desempenho.
Outra medida de otimização está relacionada ao tamanho do arquivo de log. Podemos definir o tamanho do arquivo de log para não exceder uma pequena porcentagem do espaço do disco rígido ou determinar seu tamanho. Se for definido muito alto, desperdiçará espaço em disco e, se for definido muito pequeno, forçará o arquivo de log a tentar expandir continuamente, fazendo com que o desempenho do banco de dados diminua.
Arquivo de log de transações O arquivo de log de transações é um arquivo usado para registrar atualizações de banco de dados, com extensão ldf.
No SQL Server 7.0 e no SQL Server 2000, se o recurso de crescimento automático estiver definido, o arquivo de log de transações será expandido automaticamente.
Em geral, o tamanho do log de transações é estável quando pode acomodar o número máximo de transações que ocorrem entre o truncamento do log de transações, que é acionado por um ponto de verificação ou backup do log de transações.
No entanto, em alguns casos, o log de transações pode ficar tão grande que fica sem espaço ou cheio. Normalmente, quando o arquivo de log de transações preenche o espaço disponível em disco e não pode mais ser expandido, você receberá uma mensagem de erro como esta:
Erro:9002, Gravidade:17, Estado:2
O arquivo de log do banco de dados '%.*ls' está cheio.
Além dessa mensagem de erro, o SQL Server pode marcar o banco de dados como SUSPEITO devido à falta de espaço de extensão do log de transações. Para obter informações adicionais sobre como se recuperar dessa situação, consulte o tópico "Pouco espaço em disco" na Ajuda Online do SQL Server.
Além disso, a expansão do log de transações pode causar as seguintes situações:
· Arquivos de log de transações muito grandes.
· A transação pode falhar e começar a reverter.
· As transações podem levar muito tempo para serem concluídas.
· Podem ocorrer problemas de desempenho.
· Pode ocorrer bloqueio.
Causa A expansão do log de transações pode ocorrer devido aos seguintes motivos ou situações:
· Transações não confirmadas · Transações muito grandes · Operações: DBCC DBREINDEX e CREATE INDEX
· Ao restaurar a partir de um backup de log de transações · O aplicativo cliente não processa todos os resultados · A consulta atinge o tempo limite antes que o log de transações termine de expandir e você receba uma mensagem de erro falsa "Log Full" · Resolução de transação não replicada causada pelo arquivo de log sendo full Quando o banco de dados SQL não consegue gravar no arquivo, há dois métodos disponíveis:
Uma maneira: limpe o log.
1. Abra o analisador de consultas e digite o comando DUMP TRANSACTION nome do banco de dados COM NO_LOG
2. Abra o Enterprise Manager novamente - clique com o botão direito no banco de dados que deseja compactar - Todas as tarefas - Reduza o banco de dados - Reduza os arquivos - Selecione o arquivo de log - Selecione reduzir para XXM no modo de redução e um a permissão para encolher será dada aqui. Para atingir o número mínimo de M, insira diretamente este número e confirme.
O outro método apresenta certos riscos, porque o arquivo de log do SQL SERVER não é gravado imediatamente no arquivo do banco de dados principal. Se não for tratado corretamente, causará perda de dados.
1: Excluir LOG
Desanexar banco de dados Enterprise Manager -> Servidor -> Banco de dados -> Clique com o botão direito -> Desanexar banco de dados 2: Excluir arquivo LOG Anexar banco de dados Enterprise Manager -> Servidor -> Banco de dados -> Clique com o botão direito -> Anexar banco de dados Este método gera um novo LOG, o tamanho é apenas mais de 500K.
Nota: Recomenda-se usar o primeiro método.
Se no futuro você não quiser que ele cresça.
Usado no SQL2000:
Clique com o botão direito no banco de dados->Propriedades->Opções->Failure Recovery-Model-Select-Simple Model.
Ou use a instrução SQL:
alterar o nome do banco de dados definir recuperação simples
Além disso, conforme mostrado na figura acima, as propriedades do banco de dados possuem duas opções, relacionadas ao crescimento do log de transações:
Truncar log no ponto de verificação
(Esta opção é usada no SQL7.0. No SQL 2000, o modelo de recuperação de falhas é selecionado como modelo simples)
Quando o comando CHECKPOINT é executado, o conteúdo do arquivo de log de transações é limpo se exceder 70% do seu tamanho. Sempre defina esta opção como True ao desenvolver o banco de dados.
Encolhimento automático
Verifique regularmente o banco de dados. Quando o espaço não utilizado do arquivo de banco de dados ou arquivo de log exceder 25% do seu tamanho, o sistema reduzirá automaticamente o arquivo para tornar o espaço não utilizado igual a 25%. quando foi criado, ele não será O arquivo reduzido também deve ser maior ou igual ao seu tamanho original. A redução do arquivo de log de transações só pode ser feita durante o backup ou quando a opção Truncar log no ponto de verificação estiver definida como True.
Nota: Geralmente, as propriedades padrão do banco de dados criado por Li Cheng foram definidas, mas em caso de circunstâncias inesperadas, as propriedades do banco de dados são alteradas. Limpe o log e verifique as propriedades do banco de dados acima para evitar que o log de transações seja gerado. enchendo novamente.