Arquitetura física de log de transações
O log de transações é usado para garantir a integridade de dados do banco de dados e para recuperação de dados. Os tópicos nesta seção fornecem as informações sobre a arquitetura física do log de transações. A compreensão da arquitetura física pode melhorar sua efetividade na administração de logs de transações.
O log de transações em um banco de dados mapeia um ou mais arquivos físicos. Conceitualmente, o arquivo de log é uma cadeia de caracteres de registros de log. Fisicamente, a seqüência de registros de log é armazenada com eficiência no conjunto de arquivos físicos que implementam o log de transações.
O Mecanismo de Banco de Dados do SQL Server divide cada arquivo de log físico internamente em vários arquivos de log virtuais. Os arquivos de log virtuais não têm tamanho fixo e não há número fixo de arquivos de log virtuais para um arquivo de log físico. O Mecanismo de Banco de Dados escolhe o tamanho dos arquivos de log virtuais dinamicamente enquanto está criando ou estendendo os arquivos de log. O Mecanismo de Banco de Dados tenta manter um pequeno número de arquivos virtuais. O tamanho dos arquivos virtuais depois que um arquivo de log for estendido é a soma do tamanho do log existente com o tamanho do incremento do arquivo novo. O tamanho ou o número de arquivos de log virtuais não pode ser configurado nem definido por administradores.
A única vez que arquivos de log virtuais afetam o desempenho do sistema é quando os arquivos de log são definidos por valores de size e growth_increment pequenos. Se esses arquivos de log ficarem grandes por causa de diversos incrementos pequenos, eles terão muitos arquivos de log virtuais. Isso pode reduzir a velocidade de inicialização do banco de dados e também das operações de backup e restauração de log. Recomendamos que você atribua aos arquivos de log um valor de size próximo ao tamanho final necessário e também que tenha um valor de growth_increment relativamente grande.
O log de transações é um arquivo embrulhado. Por exemplo, considere um banco de dados com um arquivo de log físico dividido em quatro arquivos de log virtuais. Quando o banco de dados é criado, o arquivo de log lógico começa no início do arquivo de log físico. Novos registros de log são adicionados no final do log lógico e expandem-se para o final do log físico. O truncamento de logs libera quaisquer logs virtuais cujos registros apareçam todos na frente do número mínimo de seqüência de recuperação do log (MinLSN). O MinLSN é o número de seqüência de log do registro de log mais antigo que deve estar presente para o êxito de uma reversão de todo o banco de dados. O log de transações no banco de dados de exemplo pareceria semelhante ao apresentado na ilustração a seguir.
.gif "Arquivo de log dividido em quatro arquivos de log virtuais")
Quando o final do log lógico alcança o final do arquivo de log físico, os novos registros de log são adicionados no início do arquivo de log físico.
.gif "Registros de log delimitados no início do arquivo de log")
Esse ciclo repete-se indefinidamente, desde que o final do log lógico nunca alcance o início do log lógico. Se os registros de log antigos forem truncados com freqüência suficiente para sempre deixar espaço suficiente para todos os registros de log novos criados através do próximo ponto de verificação, o log nunca estará completo. Contudo, se o final do log lógico não alcançar o início do log lógico, ocorrerá uma das duas coisas:
Se a configuração de FILEGROWTH estiver ativada para o log e houver espaço disponível no disco, o arquivo será estendido na quantidade especificada em growth_increment e os novos registros de log serão adicionados à extensão. Para obter mais informações sobre a configuração do FILEGROWTH, consulte ALTER DATABASE (Transact-SQL).
Se a configuração de FILEGROWTH não estiver ativada ou se o disco que estiver mantendo o arquivo de log tiver menos espaço livre do que a quantidade especificada em growth_increment, será gerado um erro 9002.
Se o log contiver diversos arquivos de log físico, o log lógico percorrerá todos os arquivos de log físico antes de voltar ao início do primeiro arquivo de log físico.