locked
Tamanho do T-LOG RRS feed

  • Pergunta

  •  

    Defino em média uns 15-20% do tamanho da base para o tamanho máximo do T-LOG.

     

    Quando o log "estourar", o que o SQL faz? Começa a gravar o arquivo do início, matando os logs mais antigos?

     

     

    E, que tipo de transações ficariam em "standby" no t-log?  Isso vai depender da aplicação, certo ?

     

     

    Até.

    quinta-feira, 25 de setembro de 2008 18:32

Respostas

  • Olá Hélio,

     

    A maioria dos DBAs ou vem da infra-estrutura ou do desenvolvimento. É bem difícil um DBA vir do banco de dados (rs). Que bom que a área lhe interessa. Seus conhecimentos em Windows serão valiosos para entender o SQL Server.

     

    A base foi criada como recovery model full, mas isso não significa que não possamos alterá-la. Você pode alterar o recovery model sempre que desejar seja através do SQL Server Management Studio nas propriedades do banco de dados ou através do comando ALTER DATABASE (ex: ALTER DATABASE Banco SET Recovery FULL)

     

    Seu entendimento sobre o log no RECOVERY MODEL FULL está correto. Se você não faz backup de log, o arquivo de log vai acumular transações e irá crescer até estourar o espaço no HD (ao até ele atingir o MAXSIZE se houver). Se vocë realmente quer usar o recovery model full, faça os seus backups regularmente.

     

    Fazer o SHRINK no Log é um processo que idealmente nunca deveria ser usado. Se você fizer o SHRINK no arquivo de log e deixá-lo com um tamanho pequeno, log logo ele precisará crescer e enquanto cresce, as transações vão ter que aguardar até que o Windows aumente o arquivo. Então sugiro que você não faça o SHRINK sem necessidade. Dê um tamanho para o log de forma a mantê-lo estável. Se você faz o backup de log com regularidade, o arquivo de log não irá crescer sem controle.

     

    [ ]s,

     

    Gustavo

    sábado, 27 de setembro de 2008 02:51

Todas as Respostas

  • Olá Hélio,

     

    Estou vendo suas dúvidas em relação ao Log de transações (essa não é a primeira e não será a última). Suas dúvidas são muito pertinentes e de antemão recomendo o livro Inside SQL Server 2005 - Storage Engine. Nesse livro você terá informações detalhadas sobre o funcionamento do log e verá exatamente como ele funciona.

     

    Em todo caso, a resposta a sua pergunta vai depender do recovery model.

     

    Se for full, quando o log chegar ao fim do arquivo ele irá parar e nenhuma transação que envolva escrita poderá ser feita no banco de dados até que o arquivo seja esvaziado. Você poderá fazer isso truncando o log ou fazendo o backup de log. Os dois limpam, mas o backup de log guarda as entradas enquanto o truncate as limpa sem guardar (por isso que fazer o backup de log é a solução correta na maioria dos casos e não simplesmente fazer o truncate como muitos insistem em indicar)

     

    Se o recovery model for simple, então de tempos em tempos (a cada checkpoint) o arquivo de log é limpo de forma que quando as transações atingirem o final do arquivo, possivelmente o início estará liberado para novas transações e nenhum aviso será dado. Isso funciona como um ciclo, ou seja, transações são escritas em direção ao final do arquivo e após alcançá-lo voltam ao início do arquivo (é por isso que muitas vezes essa modalidade é conhecida como log circular).

     

    Todas as transações ficam em Stand By no log até serem limpas. No recovery model simple o SQL Server faz isso para você. No recovery model full, você deve limpá-las seja fazendo um backup ou rodando o truncate.

     

    [ ]s,

     

    Gustavo

     

    PS: Não deixe de ler o livro que indiquei...

     

    quinta-feira, 25 de setembro de 2008 19:57
  • Gustavo,
    Muito boa a sua explicação...excelente. 
    sexta-feira, 26 de setembro de 2008 13:46
  • Olá Leivio,

     

    Obrigado pelos elogios. Tento sempre fazer o melhor possível.

     

    Abs,

     

    sexta-feira, 26 de setembro de 2008 13:54
  • Gustavo, vou comprar o livro sim. Na verdade trabalho com infra, participo da comunidade Windows Server. Mas, estou trocando de área na empresa e tenho uma noção de SQL. É por isto que estou coletando o máximo de informações.

     

    Então... ...a base foi criada com o modelo de recovery "FULL" e acho que não posso alterar. Se for isso, pelo que entendi, se o log chegar ao tamanho máximo que defini e eu não o limpá-lo, nenhum dado será inserido no banco??? Se for este o caso, é crítico! Eu até faço o backup e shrink do log;

     

    Um abraço!

     

     

    sábado, 27 de setembro de 2008 00:02
  • Olá Hélio,

     

    A maioria dos DBAs ou vem da infra-estrutura ou do desenvolvimento. É bem difícil um DBA vir do banco de dados (rs). Que bom que a área lhe interessa. Seus conhecimentos em Windows serão valiosos para entender o SQL Server.

     

    A base foi criada como recovery model full, mas isso não significa que não possamos alterá-la. Você pode alterar o recovery model sempre que desejar seja através do SQL Server Management Studio nas propriedades do banco de dados ou através do comando ALTER DATABASE (ex: ALTER DATABASE Banco SET Recovery FULL)

     

    Seu entendimento sobre o log no RECOVERY MODEL FULL está correto. Se você não faz backup de log, o arquivo de log vai acumular transações e irá crescer até estourar o espaço no HD (ao até ele atingir o MAXSIZE se houver). Se vocë realmente quer usar o recovery model full, faça os seus backups regularmente.

     

    Fazer o SHRINK no Log é um processo que idealmente nunca deveria ser usado. Se você fizer o SHRINK no arquivo de log e deixá-lo com um tamanho pequeno, log logo ele precisará crescer e enquanto cresce, as transações vão ter que aguardar até que o Windows aumente o arquivo. Então sugiro que você não faça o SHRINK sem necessidade. Dê um tamanho para o log de forma a mantê-lo estável. Se você faz o backup de log com regularidade, o arquivo de log não irá crescer sem controle.

     

    [ ]s,

     

    Gustavo

    sábado, 27 de setembro de 2008 02:51
  • Gustavo, eu já havia reparado que o backup do log "limpa" o arquivo (trunca), e armazena as transações no TRN. Se fizer só um truncate, eu "perco" as transações (limpo do log e nao gravo em arquivo). Por isso, eu faço um backup full à noite da base (0h) e no horário comercial, de 2h em 2h um backup apenas do LOG. Só faço o shrink do log após o backup full da base e o backup do t-log.

     

    Mas, em relação a isso, surgiu uma dúvida: neste horário do backup full, já que este backup contempla o log, vejo então que não preciso fazer o backup do log separado neste horário, certo? Basta que o backup das 0h seja full e pronto. Ele vai pegar a base e o log naquele momento, ou seja, terei a base 100% restaurável. Durante o dia, posso restaurar o full e o conjunto dos transaction logs desejados. O que me fez pensar que o full nao levava o log junto é que, supondo um log de 5GB e uma base de 50MB, o backup full (BAK) nao chega a 100MB. Por que isso? Será porque o full já trunca o log e so leva uma parte dele, deixando o arquivo de log "como está", ou seja, com os 5GB alocados?

     

    Todos meus logs possuem um maxsize... ...entao quer dizer que, quando o arquivo chegar no limite, meu banco não vai mais receber atualização dos usuários??! Entao nao é melhor optar pelo modelo circular?

     

    Vou fixar então um tamanho razoável e fixo para o log e não fazer o shrink dele. Acredito que, quando fizer o backup full, o SQL só vai usar o espaço em disco que está realmente em uso pelas transações arquivadas, e não usar o espaço alocado para o arquivo. Agora, quando faço o backup do T-LOG, vi que o SQL leva o arquivo alocado inteiro, ou seja, se o log tem 10GB alocados mas só tenho "2 linhas em uso" dentro dele, não importa. O backup (TRN) será na faixa dos 10GB! Pelo menos foi isso que reparei.

     

    Achava que, ao chegar no maxsize, ele voltava para o início do log. Assim estava bom! Agora, preciso pensar num modo de definir um tamanho X de log de forma a não "perder" as transações até que um backup do log seja feito. No exemplo que dei, o tamanho do log tem que "aguentar" o dia inteiro até a 0h, que é onde efetuamos um backup full. Ou então, como faço backup do log de 2h em 2h, o arquivo vai sendo limpo neste período... ...então acho que por enquanto está OK.

     

    Um abraço, e me dê uma luz nestas dúvidas finais!!!! Pode deixar que vou classificar seus posts!!!

     

    Abraço!!

     

    domingo, 28 de setembro de 2008 17:09
  •  

    Esqueci uma coisa... ...qual seria a vantagem em usar um modelo FULL e SIMPLE ?

     

    Todas minhas bases estão com FULL...

     

     

    Abraço!!

    domingo, 28 de setembro de 2008 17:13