none
Como calcular o tamanho do arquivo de LOG RRS feed

  • Pergunta

  • Galera.

    Gostaria de saber se alguem pode me ajudar?

    Analisando o arquivo de LOG, verifiquei que depois de um processo de carga de dados o tamanho ficou em 4.3GB, porém desse tamanho somente 30% estava realmente sendo usado.

    Alterei a forma de crescimento do log de 10% para 100MB,  o arquivo ficou com 3.2GB, mas continua usando somente os 30%.

    Já pesquisei em vários foruns, mas não conseguir encontrar como é feito esse cálculo que faz crescer tanto o log, porém menos da metade é usado.

    Existem algum formula para cálcular o crescimento do arquivo de LOG? Para calcular o crescimento de base de dados, existem váras formulas, mas nao encontrei nada sobre o cálculo do LOg.

    Alguem sabe esse cálculo?

    Obrigado.

     


    Brito
    segunda-feira, 13 de junho de 2011 22:21

Respostas

  • Boa Noite,

    Não existe um percentual entre o tamanho da base e o log de transações. Se eu disser 10%, talvez funcione bem para uma base de 1GB e um log de 100MB, mas seria um percentual enorme para uma base de 10TB, pois, isso representaria 1TB de log. Por outro lado, dizer 50% do tamanho para um log pode parecer um exagero, mas seria uma proporção adequada para uma base de 100MB por exemplo.

    A melhor forma de calcular não é olhando para o tamanho da base, mas sim para o uso do log e a frequência com que o backup de log ocorre (no caso de modelos archieve). Grandes bases podem usar muito pouco log, bases pequenas podem usar mais log que seus próprios dados. Em ambas as situações, se o cálculo for feito olhando-se o uso do LOG, você não irá errar.

    Pode parecer estranho, um log querer crescer se houver espaço livre dentro do arquivo. Se temos um arquivo de log de 10GB e ainda possuímos 3GB livre, porque então uma transação de 300MB (que cabe nos 3GB livre), fez o arquivo de log crescer para digamos 11GB ? Por que o SQL Server não aproveitou o espaço interno livre dentro do arquivo ?

    Com disse no meu post, isso acontece por conta dos arquivos dos virtual log files. Embora você possua um único arquivo LDF. Dentro desse arquivo há várias segmentações menores (Virtual Log Files). As transações são escritas dentro de um Virtual Log File dentro de um LDF. Muitas vezes, pode acontecer desses virtual log files ficarem fragmentados e sua reutilização ser impedida. Se a fragmentação dessas estruturas for muito significativa, o SQL Server poderá ter espaço dentro do LDF, mas precisar de espaço adicional, pois, o espaço livre dentro do Virtual Log File não pode ser usado. Se achar interessante entender melhor o seu caso, eu recomendo dar uma olhada em algumas referências sobre essas estruturas:

    Virtual Log Files
    http://msdn.microsoft.com/en-us/library/aa933049(v=sql.80).aspx

    Transaction Log Physical Architecture
    http://technet.microsoft.com/en-us/library/ms179355.aspx

    Monitoring SQL Server Virtual Log File Fragmentation
    http://www.simple-talk.com/sql/database-administration/monitoring-sql-server-virtual-log-file-fragmentation/

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    • Sugerido como Resposta Gustavo Maia Aguiar quinta-feira, 16 de junho de 2011 04:54
    • Marcado como Resposta Almeida.Brito quinta-feira, 16 de junho de 2011 14:33
    quinta-feira, 16 de junho de 2011 04:54
  • Bom Dia,

    Para entender o funcionamento do arquivo de Log, eu recomendo fortemente que você assista um Webcast no qual eu exponho o seu funcionamento. Você poderá encontrá-lo em:

    http://gustavomaiaaguiar.wordpress.com/2009/11/09/sql-server-day-%E2%80%93-depois-do-evento/

    Truncar o log é sem dúvida algo completamente inútil e sem sentido (tanto que o SQL Server 2008 não possui o comando de TRUNCATE do log). Recomendo a leitura dos artigos de minha autoria abaixo:

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY – Parte I
    http://gustavomaiaaguiar.wordpress.com/2009/08/01/piores-praticas-%E2%80%93-utilizar-o-comando-backup-log-com-a-opcao-with-truncate_only-%E2%80%93-parte-i/

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY – Parte II
    http://gustavomaiaaguiar.wordpress.com/2009/08/01/piores-praticas-%E2%80%93-utilizar-o-comando-backup-log-com-a-opcao-with-truncate_only-%E2%80%93-parte-ii/

    O log de transações é basicamente um diário de bordo que registra todos os acontecimentos que ocorrem no banco de dados. Não existe nenhuma operação de escrita que não seja anotada no log de transação. Isso é sempre verdade independente de qualquer configuração que você faça, muito embora, algumas configurações possam diminuir a quantidade de log gerada em algumas operações, mas toda operação de escrita sempre irá gerar log.

    O log de transações contém informações sobre os blocos afetados, as linhas inseridas, apagadas e alteradas além de outras informações de controle. Seu propósito é fazer com que o banco recupere-se após um cenário de parada não programado (queda de energia, boot, parada do serviço, etc). Se os dados fossem escritos diretamente no MDF, após um boot, não saberíamos em que pé que estava a escrita. Como o log de transações propõe-se a registrar o que acontece e não propriamente "fazer acontecer", teremos sempre o registro do que precisa ser feito e se já foi feito.

    Todo banco de dados (e não incluo somente o SQL Server) possui um processo chamado CHECKPOINT no qual de forma resumida, as alterações registradas no log de transações são efetivadas sobre os arquivos de dados (há alguns outros detalhes, mas enfim...). Se o banco possui modelo de log circular (Recovery Model Simple), então o CHECKPOINT limpa as entradas de log que foram contempladas nos dados. Se o banco possui modelo de log archieve (Recovery Model Bulk Logged ou Full), então mesmo após o CHECKPOINT, as entradas permanecem no log de transações (mesmo já tendo sido contempladas no MDF).

    O Recovery Model Simple lhe dará simplicidade e basicamente o log de transações deve ter o tamanho de sua maior transação. Se você sua maior transação possui 10GB de dados, seu log precisará de 10GB, pois, após essa transação ocorrer, um CHECKPOINT deve ser realizado liberando espaço. As demais transações irão "caber" nesse espaço. Como esse Recovery Model retira do log o que já foi aplicado sobre os dados, apenas Backups Full e Diferenciais são permitidos.

    O Recovery Model Full lhe dará mais trabalho na administração, pois, ele irá reter as transações no log mesmo após o CHECKPOINT. Como as transações só são expurgadas com um Backup de Log, o tamanho ideal é o maior tamanho entre a duração de seus backups de log. Se você faz backup de log a cada duas horas e o log chega até 15GB entre esses backups, 15GB seria o tamanho ideal para o seu arquivo de log, pois, no próximo backup esse volume será backupeado. Claro que é importante manter o dobro de espaço e mais um pouco, pois, é recomendável ter margens além do que um job pode falhar e seria ruim retardar suas transações para que o log cresça ou ainda provocar indisponibilidade por falta de espaço em disco.

    Analisando o seu problema, creio que se após a carga há 30% de espaço ocupado, temos algumas possibilidades:

    - Sua política de crescimento está exagerada. Você pode ter um log de 1GB e colocar o crescimento de 2GB. Assim, se o log estourar 100MB, você terá 1,1GB, mas pela política de crescimento do arquivo, você terá 3GB (1GB inicial + 2GB pela política de crescimento)

    - Há uma rotina de backup de log muito próxima após o crescimento. O log pode ter estourado, ativado a política de crescimento (uma ou várias vezes) e pouco tempo após, um backup de log foi feito liberando espaço dentro do arquivo. O backup de log apenas copia as transações, mas não vai fazer o SHRINK automaticamente e isso explicaria porque há apenas 30% ocupado.

    - Um backup de log não conseguiu copiar as transações de forma contígua entre os Virtual Logs (Mini Files). Isso pode acontecer porque transações começaram em um ponto (virtual log) e terminaram em outro ponto (Virtual Log). Nessa situação, um único backup de log não irá conseguir retirar as transações que possibilitam o SHRINK, mas ainda assim deixará área livre no arquivo. Será necessário tirar mais um (ou dois) backups de log para viabilizar a redução do arquivo.

    Ainda sobre o log de transações, embora concorde com muitas colocações nesse post, tenho algumas ressalvas

    "É necessario saber que voce só deve manter a base em recovery model Full quando ha uma solução de alta disponibilidade (Como o log shipping por exemplo) em execução, caso contrario voce só estara gastando espaço"

    Eu discordo dessa afirmação. Há soluções de alta disponibilidade que dependem do log de transações como replicação transacional, database mirroring e o log shipping, mas essas soluções usam o log e não simplesmente "justificam o log". Ter a base em Recovery Model Full é importante não porque você usa ou não uma solução de alta disponibilidade, mas sim porque o Recovery Model Full possibilita o backup de log e se você pode backupear o log, você poderá voltar o restore em pontos específicos (onde inclusive não havia backup) além de conseguir recuperar o banco em algumas situações em que não havia backup disponível (Tail Log). Supondo um backup full diário e um log de hora em hora, você pode voltar o banco em qualquer momento que desejar. Se um log é feito às 9h e outro às 10h, você pode tranquilamente voltar o backup às 09:31:34.121 mesmo sem ter um backup naquele momento, pois, como o log contempla esse período, você pode mandar parar naquele momento específico. Se você usa o Recovery Model Simple, você perde essa valiosa habilidade embora facilite a administração (ainda assim, full é o padrão na produção).

    "Recomendo um Shrink dos arquivos de log (DBCC SHRINKFILE(2)) para todas as databases de tempos em tempos (Em meus ambientes este comando roda para todas as bases de 15 em 15 minutos)"

    Não é uma prática que eu utilizaria em um ambiente de produção. Veja que o SHRINK tem por objetivo reduzir o tamanho do arquivo, mas qual a finalidade de reduzir o arquivo de log, se você sabe que ele irá crescer de novo ? Se você tem um log de 1GB e faz a redução para 300MB para "não desperdiçar", você irá ter problemas posteriormente, pois, o log de 300MB está em seu tamanho mínimo e a primeira transação mais "parruda" irá estourar os 300mb fazendo com que o log tenha de crescer. Isso significa que enquanto ele cresce, as transações esperam. Adicionalmente, cada vez que o arquivo crescer, ele irá absorver uma área não contígua do disco e isso poderá introduzir fragmentação física do arquivo.

    Não vejo sentido em reduzir alguma coisa que você sabe que irá aumentar (é gastar tempo e CPU à toa). Minha recomendação é que você deixe o arquivo de log em um tamanho adequado e não mexa com ele. Além de aliviar sua administração, você evita problemas de desempenho em potencial. Há muita gente que reduz o arquivo para economizar espaço. Não acho que isso faça diferença, pois, economizar espaço, não irá aumentar a vida útil do disco e nem devolver o dinheiro que você já pagou por ele. Se você comprou um disco de 1TB, você gastou 1TB independente se usa 1MB ou 1TB. Se você tem espaço sobrando e sabe que o arquivo de log vai ocupá-lo em algum momento, aloque-o e não o reduza sem necessidade. Não há ganho de desempenho nenhum em ter arquivos de log menores. Só reduza o log, se realmente não for mais usar todo o espaço que ele tem a oferecer

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    terça-feira, 14 de junho de 2011 14:16

Todas as Respostas

  • Almeida,

    Uma duvida, como voce esta calculando o tamanho do seu arquivo de dados? Bom, voce deve saber então que qualquer meio de calcular isso é mera estimativa, voce deve conhecer seu ambiente e saber como projeta-lo, eu por exemplo, todo novo ambiente coloco uma proc que é executada semanalmente responsavel por guardar o tamanho das bases em uma tabela, a partir dai, sei o quanto cresce meu ambiente, e quais upgrades são necessarios.

    Em relação ao arquivo de log.
    É necessario saber que voce só deve manter a base em recovery model Full quando ha uma solução de alta disponibilidade (Como o log shipping por exemplo) em execução, caso contrario voce só estara gastando espaço. Se seu log estiver em full, ele ira guardar o log de todas as transações realizadas em sua base, e a unica maneira de se limpar este log é fazendo um backup de log, ou truncando-o.
    Se estiver em recovery model simple, o log ira crescer em relação ao tamanho da transação aplicada. Exemplo: Voce possui uma tabela com 10.000.000 de linhas, ai voce roda esta query nesta tabela, UPDATE TABELA SET CAMPO=CAMPO+1, pronto, seu log acabou de crescer bastante rs...... agora, se voce rodar a query UPDATE TABELA SET CAMPO=CAMPO+1 WHERE PK_FIELD=1 seu log ira crescer muito pouco.
    Imagina o log como algo mais ou menos assim:
    A linha X da tabela Y, o campo A, mudou de B para C
    A linha X da tabela Y, o campo B, mudou de C para D

    Ou seja, o log esta diretamente ligado a quantidade de linhas envolvidas.

    Lembre-se tambem que delete não quer dizer que seu log ira diminuir, uma vez que este tipo de transação tambem gera log, por exemplo:
    A linha X da tabela Y foi DELETADA, ou seja, apesar de sua base estar menor, seu log cresceu.

    Teoricamente a base com recovery model simple, cresce o quanto é necessario para sua transação e depois volta ao tamanho denifido, porem isso acaba não acontecendo 100% do tempo, o que pode deixar seu log grande.

    Recomendo um Shrink dos arquivos de log (DBCC SHRINKFILE(2)) para todas as databases de tempos em tempos (Em meus ambientes este comando roda para todas as bases de 15 em 15 minutos)

    Algumas dicas: Quanto mais espaço seu log precisa em disco, mais lenta sera suas transações, por isso se voce possui um disco totalmente dedicado para o log de uma base (Mais comum para a tempdb do que outras bases), um dos tunnings que voce pode encontrar na internet é ja reservar todo o espaço em disco para este arquivo de log, fazendo-o por exemplo com 400GB, porem apenas 100MB ocupado.

    Creio que seja por todos esses motivos que voce não encontrou nenhuma formula magica de se calcular o tamanho do log.
    Oracle OCA11g, MCC 2011! Dicas e novidades: www.fabrizziocaputo.wordpress.com
    segunda-feira, 13 de junho de 2011 23:28
    Moderador
  • Bom Dia,

    Para entender o funcionamento do arquivo de Log, eu recomendo fortemente que você assista um Webcast no qual eu exponho o seu funcionamento. Você poderá encontrá-lo em:

    http://gustavomaiaaguiar.wordpress.com/2009/11/09/sql-server-day-%E2%80%93-depois-do-evento/

    Truncar o log é sem dúvida algo completamente inútil e sem sentido (tanto que o SQL Server 2008 não possui o comando de TRUNCATE do log). Recomendo a leitura dos artigos de minha autoria abaixo:

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY – Parte I
    http://gustavomaiaaguiar.wordpress.com/2009/08/01/piores-praticas-%E2%80%93-utilizar-o-comando-backup-log-com-a-opcao-with-truncate_only-%E2%80%93-parte-i/

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY – Parte II
    http://gustavomaiaaguiar.wordpress.com/2009/08/01/piores-praticas-%E2%80%93-utilizar-o-comando-backup-log-com-a-opcao-with-truncate_only-%E2%80%93-parte-ii/

    O log de transações é basicamente um diário de bordo que registra todos os acontecimentos que ocorrem no banco de dados. Não existe nenhuma operação de escrita que não seja anotada no log de transação. Isso é sempre verdade independente de qualquer configuração que você faça, muito embora, algumas configurações possam diminuir a quantidade de log gerada em algumas operações, mas toda operação de escrita sempre irá gerar log.

    O log de transações contém informações sobre os blocos afetados, as linhas inseridas, apagadas e alteradas além de outras informações de controle. Seu propósito é fazer com que o banco recupere-se após um cenário de parada não programado (queda de energia, boot, parada do serviço, etc). Se os dados fossem escritos diretamente no MDF, após um boot, não saberíamos em que pé que estava a escrita. Como o log de transações propõe-se a registrar o que acontece e não propriamente "fazer acontecer", teremos sempre o registro do que precisa ser feito e se já foi feito.

    Todo banco de dados (e não incluo somente o SQL Server) possui um processo chamado CHECKPOINT no qual de forma resumida, as alterações registradas no log de transações são efetivadas sobre os arquivos de dados (há alguns outros detalhes, mas enfim...). Se o banco possui modelo de log circular (Recovery Model Simple), então o CHECKPOINT limpa as entradas de log que foram contempladas nos dados. Se o banco possui modelo de log archieve (Recovery Model Bulk Logged ou Full), então mesmo após o CHECKPOINT, as entradas permanecem no log de transações (mesmo já tendo sido contempladas no MDF).

    O Recovery Model Simple lhe dará simplicidade e basicamente o log de transações deve ter o tamanho de sua maior transação. Se você sua maior transação possui 10GB de dados, seu log precisará de 10GB, pois, após essa transação ocorrer, um CHECKPOINT deve ser realizado liberando espaço. As demais transações irão "caber" nesse espaço. Como esse Recovery Model retira do log o que já foi aplicado sobre os dados, apenas Backups Full e Diferenciais são permitidos.

    O Recovery Model Full lhe dará mais trabalho na administração, pois, ele irá reter as transações no log mesmo após o CHECKPOINT. Como as transações só são expurgadas com um Backup de Log, o tamanho ideal é o maior tamanho entre a duração de seus backups de log. Se você faz backup de log a cada duas horas e o log chega até 15GB entre esses backups, 15GB seria o tamanho ideal para o seu arquivo de log, pois, no próximo backup esse volume será backupeado. Claro que é importante manter o dobro de espaço e mais um pouco, pois, é recomendável ter margens além do que um job pode falhar e seria ruim retardar suas transações para que o log cresça ou ainda provocar indisponibilidade por falta de espaço em disco.

    Analisando o seu problema, creio que se após a carga há 30% de espaço ocupado, temos algumas possibilidades:

    - Sua política de crescimento está exagerada. Você pode ter um log de 1GB e colocar o crescimento de 2GB. Assim, se o log estourar 100MB, você terá 1,1GB, mas pela política de crescimento do arquivo, você terá 3GB (1GB inicial + 2GB pela política de crescimento)

    - Há uma rotina de backup de log muito próxima após o crescimento. O log pode ter estourado, ativado a política de crescimento (uma ou várias vezes) e pouco tempo após, um backup de log foi feito liberando espaço dentro do arquivo. O backup de log apenas copia as transações, mas não vai fazer o SHRINK automaticamente e isso explicaria porque há apenas 30% ocupado.

    - Um backup de log não conseguiu copiar as transações de forma contígua entre os Virtual Logs (Mini Files). Isso pode acontecer porque transações começaram em um ponto (virtual log) e terminaram em outro ponto (Virtual Log). Nessa situação, um único backup de log não irá conseguir retirar as transações que possibilitam o SHRINK, mas ainda assim deixará área livre no arquivo. Será necessário tirar mais um (ou dois) backups de log para viabilizar a redução do arquivo.

    Ainda sobre o log de transações, embora concorde com muitas colocações nesse post, tenho algumas ressalvas

    "É necessario saber que voce só deve manter a base em recovery model Full quando ha uma solução de alta disponibilidade (Como o log shipping por exemplo) em execução, caso contrario voce só estara gastando espaço"

    Eu discordo dessa afirmação. Há soluções de alta disponibilidade que dependem do log de transações como replicação transacional, database mirroring e o log shipping, mas essas soluções usam o log e não simplesmente "justificam o log". Ter a base em Recovery Model Full é importante não porque você usa ou não uma solução de alta disponibilidade, mas sim porque o Recovery Model Full possibilita o backup de log e se você pode backupear o log, você poderá voltar o restore em pontos específicos (onde inclusive não havia backup) além de conseguir recuperar o banco em algumas situações em que não havia backup disponível (Tail Log). Supondo um backup full diário e um log de hora em hora, você pode voltar o banco em qualquer momento que desejar. Se um log é feito às 9h e outro às 10h, você pode tranquilamente voltar o backup às 09:31:34.121 mesmo sem ter um backup naquele momento, pois, como o log contempla esse período, você pode mandar parar naquele momento específico. Se você usa o Recovery Model Simple, você perde essa valiosa habilidade embora facilite a administração (ainda assim, full é o padrão na produção).

    "Recomendo um Shrink dos arquivos de log (DBCC SHRINKFILE(2)) para todas as databases de tempos em tempos (Em meus ambientes este comando roda para todas as bases de 15 em 15 minutos)"

    Não é uma prática que eu utilizaria em um ambiente de produção. Veja que o SHRINK tem por objetivo reduzir o tamanho do arquivo, mas qual a finalidade de reduzir o arquivo de log, se você sabe que ele irá crescer de novo ? Se você tem um log de 1GB e faz a redução para 300MB para "não desperdiçar", você irá ter problemas posteriormente, pois, o log de 300MB está em seu tamanho mínimo e a primeira transação mais "parruda" irá estourar os 300mb fazendo com que o log tenha de crescer. Isso significa que enquanto ele cresce, as transações esperam. Adicionalmente, cada vez que o arquivo crescer, ele irá absorver uma área não contígua do disco e isso poderá introduzir fragmentação física do arquivo.

    Não vejo sentido em reduzir alguma coisa que você sabe que irá aumentar (é gastar tempo e CPU à toa). Minha recomendação é que você deixe o arquivo de log em um tamanho adequado e não mexa com ele. Além de aliviar sua administração, você evita problemas de desempenho em potencial. Há muita gente que reduz o arquivo para economizar espaço. Não acho que isso faça diferença, pois, economizar espaço, não irá aumentar a vida útil do disco e nem devolver o dinheiro que você já pagou por ele. Se você comprou um disco de 1TB, você gastou 1TB independente se usa 1MB ou 1TB. Se você tem espaço sobrando e sabe que o arquivo de log vai ocupá-lo em algum momento, aloque-o e não o reduza sem necessidade. Não há ganho de desempenho nenhum em ter arquivos de log menores. Só reduza o log, se realmente não for mais usar todo o espaço que ele tem a oferecer

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    terça-feira, 14 de junho de 2011 14:16
  • Gustavo,

    Muito obrigado por sua resposta, porém não é exatamente isso que gostaria de saber.

    Eu preciso ter uma noção de como calcular o crescimento do log. Exemplo:

    Tenho uma base de 100GB e um log de 10GB como é feito o calculo para o crescimento desse arquivo de log? Existe metrica entre o tamanho da base e o arquivo?

    Fiz alguns testes com insert e update e de repente o log cresce, gostaria qual é a propoção que esse arquivo achar que deve crescer? Tipo: 10GB, depois de alguns inserts ele cresce para 12GB, mesmo tendo espaço ainda dentro dos 10GB, qual critério ele usou para saber que deve crescer?

    Obrigado.


    Brito
    quarta-feira, 15 de junho de 2011 13:46
  • Boa Noite,

    Não existe um percentual entre o tamanho da base e o log de transações. Se eu disser 10%, talvez funcione bem para uma base de 1GB e um log de 100MB, mas seria um percentual enorme para uma base de 10TB, pois, isso representaria 1TB de log. Por outro lado, dizer 50% do tamanho para um log pode parecer um exagero, mas seria uma proporção adequada para uma base de 100MB por exemplo.

    A melhor forma de calcular não é olhando para o tamanho da base, mas sim para o uso do log e a frequência com que o backup de log ocorre (no caso de modelos archieve). Grandes bases podem usar muito pouco log, bases pequenas podem usar mais log que seus próprios dados. Em ambas as situações, se o cálculo for feito olhando-se o uso do LOG, você não irá errar.

    Pode parecer estranho, um log querer crescer se houver espaço livre dentro do arquivo. Se temos um arquivo de log de 10GB e ainda possuímos 3GB livre, porque então uma transação de 300MB (que cabe nos 3GB livre), fez o arquivo de log crescer para digamos 11GB ? Por que o SQL Server não aproveitou o espaço interno livre dentro do arquivo ?

    Com disse no meu post, isso acontece por conta dos arquivos dos virtual log files. Embora você possua um único arquivo LDF. Dentro desse arquivo há várias segmentações menores (Virtual Log Files). As transações são escritas dentro de um Virtual Log File dentro de um LDF. Muitas vezes, pode acontecer desses virtual log files ficarem fragmentados e sua reutilização ser impedida. Se a fragmentação dessas estruturas for muito significativa, o SQL Server poderá ter espaço dentro do LDF, mas precisar de espaço adicional, pois, o espaço livre dentro do Virtual Log File não pode ser usado. Se achar interessante entender melhor o seu caso, eu recomendo dar uma olhada em algumas referências sobre essas estruturas:

    Virtual Log Files
    http://msdn.microsoft.com/en-us/library/aa933049(v=sql.80).aspx

    Transaction Log Physical Architecture
    http://technet.microsoft.com/en-us/library/ms179355.aspx

    Monitoring SQL Server Virtual Log File Fragmentation
    http://www.simple-talk.com/sql/database-administration/monitoring-sql-server-virtual-log-file-fragmentation/

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    • Sugerido como Resposta Gustavo Maia Aguiar quinta-feira, 16 de junho de 2011 04:54
    • Marcado como Resposta Almeida.Brito quinta-feira, 16 de junho de 2011 14:33
    quinta-feira, 16 de junho de 2011 04:54
  • Gustavo,

    Realmente o calculo do LOG é bem diferencça de calcular o crescimento de uma base ou tabela.

    Eu como DBA entendo as dificuldades de ter pelos menos uma base para gerar uma estimativa de crescimento, o dificil vai ser conversar a minha coordenadora sobre isso. Ela trabalhou muito tempo com Informix e com certeza as palavras dela deverao ser "Que absurdo o Informix informa isso direitinho. Esse SQL!!!"

    Obrigado pela ajuda.

    Grande abraço.


    Brito
    quinta-feira, 16 de junho de 2011 14:33
  • Boa Tarde,

    Tente não entrar nas especificidades. Explique para ela porque o % não é uma boa métrica e pergunte como o Informix consegue manter percentuais, pois, independente do SGBD me parece ser sem sentido. Sobre o Virtual Log File, não é preciso entrar nesse mérito. Deixe o log já aumentado, faça backups e não terá problemas.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 16 de junho de 2011 16:44