Carregando ...
Desculpe, ocorreu um erro ao carregar o conteúdo.
 

Transaction log

Expandir mensagens
  • Eduardo
    ola galera como eu faço para ver os transactions log e limpa-los depois.. obrigado Att. Eduardo Morais
    Mensagem 1 de 6 , 27 de jun de 2007
      ola galera
      como eu faço para ver os transactions log
      e limpa-los depois..

      obrigado


      Att.
      Eduardo Morais



      ____________________________________________________________________________________
      Novo Yahoo! Cadê? - Experimente uma nova busca.
      http://yahoo.com.br/oqueeuganhocomisso

      [As partes desta mensagem que não continham texto foram removidas]
    • Ismael Costa Junior
      Bom dia pessoal, Precisei fazer um shrink em um transaction log, pois o cliente não fazia backup e deixou o arquivo ficar maior que os datafiles. Para isso,
      Mensagem 2 de 6 , 10 de set de 2015
        Bom dia pessoal,

        Precisei fazer um shrink em um transaction log, pois o cliente não fazia backup e deixou o arquivo ficar maior que os datafiles. Para isso, gerei um backup do log e depois fiz o shrink, porém após rodar este primeiro shrink o arquivo não diminuiu de tamanho. Precisei gerar um novo backup do log e depois do segundo shrink é que ele diminuiu o tamanho. 

        Alguém teria alguma dica do motivo disto ocorrer? Teoricamente, se eu fiz o primeiro backup do log, ele já não deveria fazer o shrink?

        Obrigado a todos,

        -- 
        Att.,

        Ismael Junior
      • Vinicius Kleber
        Ismael, boa tarde, Como a escrita do log e sequencial e incremental, ele segue uma ordem (Log Sequence Number). E todas as transações recebem um numero. A
        Mensagem 3 de 6 , 15 de set de 2015
          Ismael, boa tarde, 

          Como a escrita do log e sequencial e incremental, ele segue uma ordem (Log Sequence Number). E todas as transações recebem um numero. 
          A transação com mais tempo sem um commit ou um rollback passa a ser chamada de Min-LSN. Como o sql server necessita 
          de uma sequencia para garantir a consistencia dos dados, ele não pode "truncar" os VLFs depois dessa transação enquanto ela não receber rollback ou commit.

          Por isso no seu primeiro shrink havia uma min-lsn e você não conseguiu realizar o shrink, somente depois do segundo backup e segundo shrink.

          Esse pode ser um provavel motivo. 

          Segue um link falando mais sobre isso. 


          abs,

          Em 10 de setembro de 2015 11:38, Ismael Costa Junior icjunior07@... [mssql-l] <mssql-l@...> escreveu:
           

          Bom dia pessoal,

          Precisei fazer um shrink em um transaction log, pois o cliente não fazia backup e deixou o arquivo ficar maior que os datafiles. Para isso, gerei um backup do log e depois fiz o shrink, porém após rodar este primeiro shrink o arquivo não diminuiu de tamanho. Precisei gerar um novo backup do log e depois do segundo shrink é que ele diminuiu o tamanho. 

          Alguém teria alguma dica do motivo disto ocorrer? Teoricamente, se eu fiz o primeiro backup do log, ele já não deveria fazer o shrink?

          Obrigado a todos,

          -- 
          Att.,

          Ismael Junior


        • angelo
          Ismael, boa tarde, Acho que vc inverteu a ordem dos fatos ai... Pois o correto seria... fazer um backup full antes de tudo e depois o shrink file, shrink log
          Mensagem 4 de 6 , 15 de set de 2015
            Ismael,

            boa tarde,

            Acho que vc inverteu a ordem dos fatos ai... 

            Pois o correto seria... fazer um backup full antes de tudo  e depois o shrink file, shrink log
            É backup full e depois backup do log e segue a sequencia.

            E para causar um pouco de terror benefico no cliente e criar o habito, caso este nao se acostumar a fazer backup full e mais backup do transact log, a tendencia será o logfile crescer cada vez mais, até lotar o HD (se nao tiver configurado limite para esses arquivos crescer)  e o problema vai ficar bem sério.. $$$

            []s angelo




            2015-09-10 11:38 GMT-03:00 Ismael Costa Junior icjunior07@... [mssql-l] <mssql-l@...>:
             

            Bom dia pessoal,

            Precisei fazer um shrink em um transaction log, pois o cliente não fazia backup e deixou o arquivo ficar maior que os datafiles. Para isso, gerei um backup do log e depois fiz o shrink, porém após rodar este primeiro shrink o arquivo não diminuiu de tamanho. Precisei gerar um novo backup do log e depois do segundo shrink é que ele diminuiu o tamanho. 

            Alguém teria alguma dica do motivo disto ocorrer? Teoricamente, se eu fiz o primeiro backup do log, ele já não deveria fazer o shrink?

            Obrigado a todos,

            -- 
            Att.,

            Ismael Junior


          • João Polisel
            Ismael, Internamente o transaction log é dividido em porções menores chamadas VLF – Virtual Log File O shrink não é eficaz se houver um VLF ativo no
            Mensagem 5 de 6 , 16 de set de 2015

              Ismael,

               

              Internamente o transaction log é dividido em porções menores chamadas VLF – Virtual Log File

               

              O shrink não é eficaz se houver um VLF ativo no final do arquivo. Os VLFs podem ser usados em um sequência física diferente da sequência lógica.

               

              Pense que teu arquivo tem 100 VLFs numerados 1 a 100. Você está atualmente usando o VLF 100 e todos os outros estão ocupados. Você faz um backup de log, o SQL Server copia tudo para disco, marca os VLFs como livres, e move o VLF ativo para o de número 90.

               

              Neste caso o SHRINK não vai conseguir liberar muita coisa do arquivo. Se você fizer novamente o procedimento grandes são as chances do novo VLF ativo ser um mais para o começo do arquivo e aí sim você consegue liberar bastante espaço.

               

              Tenha em mente também que os VLFs podem ter tamanhos variáveis pois são calculados de acordo com o incremento que houve no tamanho do arquivo de log.

               

              O comando abaixo te retorna uma linha para cada VLF do banco de dados

               

              USE <DATABASE>

              GO

              DBCC LOGINFO

              GO

               

              Bancos de dados com grandes quantidades de VLFs também podem sofrer de problemas de performance durante operações que façam log scan, como o processo de recovery, replicação transacional e etc...

               

              A recomendação é que você mantenha a quantidade de VLFs sempre inferior a 300. Claro que há exceções, se teu log for gigantesco (e você precisa dele enorme assim) então talvez precise passar de 300 VLFs J

               

              No SQL Server 2012 ou mais recente quando um banco de dados tem mais de 10000 VLFs o SQL Server registra no ERRORLOG a seguinte mensagem durante o recovery:

               

              Database %ls has more than %d virtual log files which is excessive. Too many virtual log files can cause long startup and backup times. Consider shrinking the log and using a different growth increment to reduce the number of virtual log files.

               

              O banco de dados %1! tem mais de %2! arquivos de log virtuais, o que é excessivo. O excesso de arquivos de log virtuais pode causar longos tempos de inicialização e backup. Considere reduzir o log e usar um incremento de aumento diferente para reduzir o número de arquivos de log virtuais.

               

              Observe que o número de VLFs na mensagem não é uma constante e portanto isso pode mudar entre versões. De fato no SQL Server 2012 CTP a mensagem era exibida para qualquer quantidade acima de 1000 VLFs e no RTM multiplicaram esse valor por 10

               

              []s
              João Polisel

               

              From: mssql-l@... [mailto:mssql-l@...]
              Sent: Tuesday, September 15, 2015 6:32 PM
              To: mssql-l
              Subject: Re: [mssql-l] Transaction log

               

               

              Ismael,

               

              boa tarde,

               

              Acho que vc inverteu a ordem dos fatos ai... 

               

              Pois o correto seria... fazer um backup full antes de tudo  e depois o shrink file, shrink log

              É backup full e depois backup do log e segue a sequencia.

               

              E para causar um pouco de terror benefico no cliente e criar o habito, caso este nao se acostumar a fazer backup full e mais backup do transact log, a tendencia será o logfile crescer cada vez mais, até lotar o HD (se nao tiver configurado limite para esses arquivos crescer)  e o problema vai ficar bem sério.. $$$

               

              []s angelo

               

               

               

               

              2015-09-10 11:38 GMT-03:00 Ismael Costa Junior icjunior07@... [mssql-l] <mssql-l@...>:

               

              Bom dia pessoal,

               

              Precisei fazer um shrink em um transaction log, pois o cliente não fazia backup e deixou o arquivo ficar maior que os datafiles. Para isso, gerei um backup do log e depois fiz o shrink, porém após rodar este primeiro shrink o arquivo não diminuiu de tamanho. Precisei gerar um novo backup do log e depois do segundo shrink é que ele diminuiu o tamanho. 

               

              Alguém teria alguma dica do motivo disto ocorrer? Teoricamente, se eu fiz o primeiro backup do log, ele já não deveria fazer o shrink?

               

              Obrigado a todos,

               

              -- 

              Att.,

              Ismael Junior

               

            • Ismael Costa Junior
              Bom dia pessoal, Muito obrigado pelas explicações. Ajudou muito a entender melhor como funciona o log e VLF. Estou dando uma revisada geral no meu ambiente,
              Mensagem 6 de 6 , 17 de set de 2015
                Bom dia pessoal,

                Muito obrigado pelas explicações. Ajudou muito a entender melhor como funciona o log e VLF. Estou dando uma revisada geral no meu ambiente, e achei alguns gargalos para resolver.

                Grande abraço,

                Em 16 de setembro de 2015 09:45, João Polisel jpolisel@... [mssql-l] <mssql-l@...> escreveu:
                 

                Ismael,

                 

                Internamente o transaction log é dividido em porções menores chamadas VLF – Virtual Log File

                 

                O shrink não é eficaz se houver um VLF ativo no final do arquivo. Os VLFs podem ser usados em um sequência física diferente da sequência lógica.

                 

                Pense que teu arquivo tem 100 VLFs numerados 1 a 100. Você está atualmente usando o VLF 100 e todos os outros estão ocupados. Você faz um backup de log, o SQL Server copia tudo para disco, marca os VLFs como livres, e move o VLF ativo para o de número 90.

                 

                Neste caso o SHRINK não vai conseguir liberar muita coisa do arquivo. Se você fizer novamente o procedimento grandes são as chances do novo VLF ativo ser um mais para o começo do arquivo e aí sim você consegue liberar bastante espaço.

                 

                Tenha em mente também que os VLFs podem ter tamanhos variáveis pois são calculados de acordo com o incremento que houve no tamanho do arquivo de log.

                 

                O comando abaixo te retorna uma linha para cada VLF do banco de dados

                 

                USE <DATABASE>

                GO

                DBCC LOGINFO

                GO

                 

                Bancos de dados com grandes quantidades de VLFs também podem sofrer de problemas de performance durante operações que façam log scan, como o processo de recovery, replicação transacional e etc...

                 

                A recomendação é que você mantenha a quantidade de VLFs sempre inferior a 300. Claro que há exceções, se teu log for gigantesco (e você precisa dele enorme assim) então talvez precise passar de 300 VLFs J

                 

                No SQL Server 2012 ou mais recente quando um banco de dados tem mais de 10000 VLFs o SQL Server registra no ERRORLOG a seguinte mensagem durante o recovery:

                 

                Database %ls has more than %d virtual log files which is excessive. Too many virtual log files can cause long startup and backup times. Consider shrinking the log and using a different growth increment to reduce the number of virtual log files.

                 

                O banco de dados %1! tem mais de %2! arquivos de log virtuais, o que é excessivo. O excesso de arquivos de log virtuais pode causar longos tempos de inicialização e backup. Considere reduzir o log e usar um incremento de aumento diferente para reduzir o número de arquivos de log virtuais.

                 

                Observe que o número de VLFs na mensagem não é uma constante e portanto isso pode mudar entre versões. De fato no SQL Server 2012 CTP a mensagem era exibida para qualquer quantidade acima de 1000 VLFs e no RTM multiplicaram esse valor por 10

                 

                []s
                João Polisel

                 

                From: mssql-l@... [mailto:mssql-l@...]
                Sent: Tuesday, September 15, 2015 6:32 PM
                To: mssql-l
                Subject: Re: [mssql-l] Transaction log

                 

                 

                Ismael,

                 

                boa tarde,

                 

                Acho que vc inverteu a ordem dos fatos ai... 

                 

                Pois o correto seria... fazer um backup full antes de tudo  e depois o shrink file, shrink log

                É backup full e depois backup do log e segue a sequencia.

                 

                E para causar um pouco de terror benefico no cliente e criar o habito, caso este nao se acostumar a fazer backup full e mais backup do transact log, a tendencia será o logfile crescer cada vez mais, até lotar o HD (se nao tiver configurado limite para esses arquivos crescer)  e o problema vai ficar bem sério.. $$$

                 

                []s angelo

                 

                 

                 

                 

                2015-09-10 11:38 GMT-03:00 Ismael Costa Junior icjunior07@... [mssql-l] <mssql-l@...>:

                 

                Bom dia pessoal,

                 

                Precisei fazer um shrink em um transaction log, pois o cliente não fazia backup e deixou o arquivo ficar maior que os datafiles. Para isso, gerei um backup do log e depois fiz o shrink, porém após rodar este primeiro shrink o arquivo não diminuiu de tamanho. Precisei gerar um novo backup do log e depois do segundo shrink é que ele diminuiu o tamanho. 

                 

                Alguém teria alguma dica do motivo disto ocorrer? Teoricamente, se eu fiz o primeiro backup do log, ele já não deveria fazer o shrink?

                 

                Obrigado a todos,

                 

                -- 

                Att.,

                Ismael Junior

                 




                --
                Att.,

                Ismael Junior
              Sua mensagem foi enviada com êxito e será entregue aos destinatários em breve.