none
log_reuse_wait na sys.databases RRS feed

  • Pergunta

  • Caros boa tarde!

    Preciso de uma ajuda da comunidade!

     

    Estou tendo problemas com meu banco de tempdb. Quando rodo dbcc sqlperf (logspace) ele está mostrando que meu tempdb está com 99% de utilização. Teoricamente o jeito mais facil de liberar o espaço lógico seria fazer um backup log com truncate_only e no_log. Porém quando fui consultar a log_reuse_wait na sys.sysdatabases o tempdb está com o status 4 de ACTIVE_TRANSACTION, nesse status eu não consigo diminuir o tamanho dele, somente se reiniciar o SQL, o que não seria muito agradavel. Alguem poderia ajudar para voltar o status para NOTHING.?


    []'s Douglas R. Oliveira
    quinta-feira, 5 de maio de 2011 20:08

Respostas

  • Bom Dia,

    Acredito que se o log estourou, pode ser sim que ele esteja mal dimensionado, mas pode ser sim um problema de aplicação ou alguma conexão presa. Um log de 1MB para o TEMPDB iria estourar a todo instante, mas se entregarmos 1TB de Log e uma transação criar tabelas temporárias e não for fechada, é possível que mesmo 1TB estoure e nesse caso não será um mau dimensionamento.

    O SQL Server 2005 e posteriormente disponibilizam algumas DMVs para descobrir quem anda mexendo no TempDB. Sugiro dar uma olhadinha da sys.dm_db_session_space_usage e sys.dm_db_task_space_usage. Elas são capazes de identificar quem está consumindo o TempDB. Eventualmente você pode fazer um JOIN com a sys.dm_exec_sessions ou a sys.dm_exec_requests para identificar quem ou que comando está provocando o problema. A sys.dm_tran_active_transactions também é muito boa, mas sem passar pelas requisições de TempDB, ela não será suficiente, pois, não como identificar apenas com ela se a transação usa ou não TempDB.

    [ ]s,

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


    Classifique as respostas. O seu feedback é imprescindível
    sexta-feira, 20 de maio de 2011 13:50

Todas as Respostas

  • Douglas,

     

    Ao invés de baixar o SQL, dê uma olhada na DMV sys.dm_tran_database_transactions. Nela você conseguirá identificar qual transação está aberta no TEMPDB, e se possível, poderá encerrar esta transação para voltar o status do log para NOTHING.

     

     

    Abraço


    Erickson Ricci SQL Server DBA @ BB Mapfre Email: ericksonfabricio@gmail.com Blog: ericksonricci.wordpress.com Twitter: @EricksonRicci TS: Microsoft SQL Server 2008, Database Development TS: Microsoft SQL Server 2008, Implementation and Maintenance TS: Microsoft SQL Server 2005, Implementation and Maintenance
    quinta-feira, 5 de maio de 2011 22:16
  • Douglas,

     

    se o log da tempdb esta ficando sem espaco, eh pq o log nao esta bem dimensionado.

    Verifique se os arquivos da tempdb estao com o autogrowth habilitado.

     

    []s!

     


    http://www.diaadiasql.com.br
    quinta-feira, 5 de maio de 2011 23:06
  • Douglas,

    Você poderia utilizar também a sys.dm_tran_active_transactions ou sys.dm_exec_connections para obter a relação de transações ativas no seu servidor.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]
    quarta-feira, 11 de maio de 2011 19:11
    Moderador
  • Douglas, qual o seria o problema? Contenção?

    No SQL Server a utilização do tempdb é realmente alta pq todos os bancos de dados contidos no servisor o utilização para realizar operações temporárias definidas no t-sql ou pq o query plan definiu que era necessário a utilização.

    Por default o recovery model do tempdb é simple, ou seja, o modo truncate_only é implito neste tipo de recoery model.

    Realizar backup do tempdb nao é recomendado tendo em vista a natureza da sua utlização, dados temporarios dos vários bancos que o utilizam. A cada boot no servidor o tempdb tem o seu reduzido para o tamanho definido nas propriedades.

    Em suma, como o colega falou, se o seu log está com 99% de area utilizada é pq o tamanho definido foi mal dimensionado. O normal seria ele ter um area de disco alocada de xx, mas com espaço utilizado de x.

    Espaços mal dimensionados seja no banco da aplicacao ou no tempdb causam interrupções no processamento para o sql server possa alocar mais espaço em disco.

     

    []s

     

     

     

    Estou tendo problemas com meu banco de tempdb. Quando rodo dbcc sqlperf (logspace) ele está mostrando que meu tempdb está com 99% de utilização. Teoricamente o jeito mais facil de liberar o espaço lógico seria fazer um backup log com truncate_only e no_log. Porém quando fui consultar a log_reuse_wait na sys.sysdatabases o tempdb está com o status 4 de ACTIVE_TRANSACTION, nesse status eu não consigo diminuir o tamanho dele, somente se reiniciar o SQL, o que não seria muito agradavel. Alguem poderia ajudar para voltar o status para NOTHING.?


    Wagner Andrade - SCSP - MCP - MCITP DBA
    sexta-feira, 20 de maio de 2011 13:19
  • Bom Dia,

    Acredito que se o log estourou, pode ser sim que ele esteja mal dimensionado, mas pode ser sim um problema de aplicação ou alguma conexão presa. Um log de 1MB para o TEMPDB iria estourar a todo instante, mas se entregarmos 1TB de Log e uma transação criar tabelas temporárias e não for fechada, é possível que mesmo 1TB estoure e nesse caso não será um mau dimensionamento.

    O SQL Server 2005 e posteriormente disponibilizam algumas DMVs para descobrir quem anda mexendo no TempDB. Sugiro dar uma olhadinha da sys.dm_db_session_space_usage e sys.dm_db_task_space_usage. Elas são capazes de identificar quem está consumindo o TempDB. Eventualmente você pode fazer um JOIN com a sys.dm_exec_sessions ou a sys.dm_exec_requests para identificar quem ou que comando está provocando o problema. A sys.dm_tran_active_transactions também é muito boa, mas sem passar pelas requisições de TempDB, ela não será suficiente, pois, não como identificar apenas com ela se a transação usa ou não TempDB.

    [ ]s,

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


    Classifique as respostas. O seu feedback é imprescindível
    sexta-feira, 20 de maio de 2011 13:50
  • Boa noite pessoal, depois de um longo periodo sem responde. Hoje tirei a tarde para finalmente resolver este meu problema de tempdb. Até então quando meu disco de tempdb enchia estava utilizando o processo mais arcaico e funcional do SQL Server, parando o serviço e iniciando novamente. Bom usei as respostas de todos e fui investigando, dei uma lida neste site da microsoft que ajuda muito também http://technet.microsoft.com/en-us/library/cc966545.aspx

    E finalmente através das dmvs consegui localizar o processo que estava consumindo minha tempdb, após isso rodei o dbcc sqlperf (logspace) e pronto liberado o espaço.

    Mas um ponto que me chamou muito a atenção na dmv sys.dm_db_task_space_usage a session id que estava com maior consumo de internal objects dealloc page count foi o resource monitor. Achei isso bem estranho, ai pergunto é normal?

     



    []'s Douglas R. Oliveira
    terça-feira, 14 de junho de 2011 00:23