locked
Melhor maneira de Liberar Espaço do Banco TempDB RRS feed

  • Pergunta

  • Prezados,

    O Tamanho do banco TempDB esta muito grande, porem não consigo reduzir através do shrink.
    Não da erro, porém o procedimento não realiza o que se propoem.
    O Banco em questao esta com 99% de espaço disponível.

    O que devo fazer?

    Versão do SQLServer utilizado é 2008

     

    • Movido Gustavo Maia Aguiar segunda-feira, 26 de abril de 2010 19:04 (De:SQL Server - Desenvolvimento Geral)
    segunda-feira, 26 de abril de 2010 17:29

Respostas

  • Ola Adriano,

    O artigo abaixo mostra 3 maneiras de se reduzir o tamanho do tempDB:

    http://support.microsoft.com/kb/307487

    Entretanto, como você disse que já tentou o shrink e não conseguiu, talvez tenha que usar a primeira opção citada lá.

    Se não for possível parar o SQL Server, minha sugestão é ir "matando" as conexões que estão há muito tempo no BD, e podem estar predendo dados no tempDB, e depois de "matar" estas conexões executar o processo shrink.

    Espero ter ajudado.

    Abraço


    hã?
    segunda-feira, 26 de abril de 2010 18:25
  • Boa Tarde,

    Conecte-se no TempDB e rode o comando DBCC OPENTRAN. O SPID retornado é o ID de quem está com alguma transação presa no TempdDB. Você deve eliminá-lo e prosseguir. Caso essa abordagem não dê certo, você pode rodar a DMV sys.dm_db_session_space_usage. Essa DMV mostrará as conexões que estão utilizando área temporária. Você pode fazer um join com a sys.dm_exec_sessions para ir matando as sessões mais antigas.

    Eu particularmente não adoto mais a abordagem de ir matando as conexões mais antigas, pois, com aplicações de conection pooling pode ter conexões muito antigas no SGBD que nada tem a ver com o problema no TempDB. Recomendo mesmo tentar ser mais certeiro, pois, matar alguém inadivertidamente pode significar um rollback de várias transações.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

     


    Classifique as respostas. O seu feedback é imprescindível
    segunda-feira, 26 de abril de 2010 18:55
  • Adriano,

    Estou entendendo que o TempDB está em um tamanho "fora do comum", mas realizar shrink em um banco de dados "TempDB" não é uma boa prática porque parte dos processos de sua instância SQL, relacionados a um ou mais bancos de dados podem estar sendo manipuladas durante este comando.

    Veja bem, não estou dizendo que você não deve realizar o shrink, mas que deve evitar de utilizar neste banco e, quando necessário, realizar em um horário alternativo para reduzir possibilidades de problemas em seu servidor SQL.

    Verifique como está a configuração deste banco, na propriedade "Recovery model" como segue na imagem abaixo:

    Para entrar nesta tela, abra o SSMS e clique com o botão direito no banco de dado "TempDB" e selecione a opção "Properties".

    Mantenha a propriedade "Recovery Model" com a opção "Simple". Então tente executar novamente o comando shrink como indicado pelo "DTito".

    Se ajudou na sua solução, não esqueça de marcar como resposta !

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    segunda-feira, 24 de novembro de 2014 17:03

Todas as Respostas

  • Ola Adriano,

    O artigo abaixo mostra 3 maneiras de se reduzir o tamanho do tempDB:

    http://support.microsoft.com/kb/307487

    Entretanto, como você disse que já tentou o shrink e não conseguiu, talvez tenha que usar a primeira opção citada lá.

    Se não for possível parar o SQL Server, minha sugestão é ir "matando" as conexões que estão há muito tempo no BD, e podem estar predendo dados no tempDB, e depois de "matar" estas conexões executar o processo shrink.

    Espero ter ajudado.

    Abraço


    hã?
    segunda-feira, 26 de abril de 2010 18:25
  • Boa Tarde,

    Conecte-se no TempDB e rode o comando DBCC OPENTRAN. O SPID retornado é o ID de quem está com alguma transação presa no TempdDB. Você deve eliminá-lo e prosseguir. Caso essa abordagem não dê certo, você pode rodar a DMV sys.dm_db_session_space_usage. Essa DMV mostrará as conexões que estão utilizando área temporária. Você pode fazer um join com a sys.dm_exec_sessions para ir matando as sessões mais antigas.

    Eu particularmente não adoto mais a abordagem de ir matando as conexões mais antigas, pois, com aplicações de conection pooling pode ter conexões muito antigas no SGBD que nada tem a ver com o problema no TempDB. Recomendo mesmo tentar ser mais certeiro, pois, matar alguém inadivertidamente pode significar um rollback de várias transações.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

     


    Classifique as respostas. O seu feedback é imprescindível
    segunda-feira, 26 de abril de 2010 18:55
  • Boa Tarde,

    Conecte-se no TempDB e rode o comando DBCC OPENTRAN. O SPID retornado é o ID de quem está com alguma transação presa no TempdDB. Você deve eliminá-lo e prosseguir. Caso essa abordagem não dê certo, você pode rodar a DMV sys.dm_db_session_space_usage. Essa DMV mostrará as conexões que estão utilizando área temporária. Você pode fazer um join com a sys.dm_exec_sessions para ir matando as sessões mais antigas.

    Eu particularmente não adoto mais a abordagem de ir matando as conexões mais antigas, pois, com aplicações de conection pooling pode ter conexões muito antigas no SGBD que nada tem a ver com o problema no TempDB. Recomendo mesmo tentar ser mais certeiro, pois, matar alguém inadivertidamente pode significar um rollback de várias transações.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

     


    Classifique as respostas. O seu feedback é imprescindível

    Gustavo, bom dia!

    No meu caso, como já tinha reiniciado o serviço do SQL Server, há poucas sessões com mais de 24h (A query com sys.dm_db_session_space_usage e sys.dm_exec_sessions )

    DBCC OPENTRAN não retornou nenhum dado.

    O DBCC SHRINKFILE (tempdev, 50) não diminuiu em nada o espaço consumido.

    Alguma outra sugestão?


    Alex de Figueiredo Siqueira Estudante de Sistemas de Informação e Gerente de TI na área de Desenvolvimento

    segunda-feira, 24 de novembro de 2014 13:14
  • Adriano,

    Estou entendendo que o TempDB está em um tamanho "fora do comum", mas realizar shrink em um banco de dados "TempDB" não é uma boa prática porque parte dos processos de sua instância SQL, relacionados a um ou mais bancos de dados podem estar sendo manipuladas durante este comando.

    Veja bem, não estou dizendo que você não deve realizar o shrink, mas que deve evitar de utilizar neste banco e, quando necessário, realizar em um horário alternativo para reduzir possibilidades de problemas em seu servidor SQL.

    Verifique como está a configuração deste banco, na propriedade "Recovery model" como segue na imagem abaixo:

    Para entrar nesta tela, abra o SSMS e clique com o botão direito no banco de dado "TempDB" e selecione a opção "Properties".

    Mantenha a propriedade "Recovery Model" com a opção "Simple". Então tente executar novamente o comando shrink como indicado pelo "DTito".

    Se ajudou na sua solução, não esqueça de marcar como resposta !

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    segunda-feira, 24 de novembro de 2014 17:03