none
Trace Flag 1117 e 1118 (tempdb) RRS feed

  • Pergunta

  • Pessoal

         No caso do trace 1117 e 1118, quando ativado e os arquivos acaba ficando fora do padrão, existiria alguma maneira de colocamos novamente em ordem sem precisar reiniciar o serviço do SQL Server ?


    segunda-feira, 9 de dezembro de 2019 19:36

Todas as Respostas

  • Neibala,

    Estas duas trace flags, são utilizadas justamente para definir a forma de alocação e distribuição de dados entre os arquivos que forma o TempDB, listadas no KB 2154845

    Veja as referências e orientações do Brent Ozar:

    https://www.brentozar.com/archive/2014/06/trace-flags-1117-1118-tempdb-configuration/

    Este outro link do MSSQLTips também é bastante útil:

    https://www.mssqltips.com/sqlservertip/4364/sql-server-2016-trace-flags-1118-and-1117-for-page-allocations/

    Em 2018 um cliente meu estava justamente sofrendo de contenção de dados no TempDB justamente devido a uma configuração incorreta entre trace flags e isolation level. A partir do SQL Server 2016 a aloção das extent é feita de forma uniforme, o mesmo estava utilizando um banco de dados com isolation level 120 dentro do SQL Server 2016.

    Este vídeo official da Microsoft é muito interessante e apresenta de forma prática o uso destas trace flags:

    https://techcommunity.microsoft.com/t5/Premier-Field-Engineering/Trace-Flag-1117-Growth-and-Contention/ba-p/371390


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    • Sugerido como Resposta IgorFKModerator terça-feira, 10 de dezembro de 2019 12:59
    segunda-feira, 9 de dezembro de 2019 19:48
    Moderador
  • Deleted
    • Sugerido como Resposta IgorFKModerator terça-feira, 10 de dezembro de 2019 12:59
    segunda-feira, 9 de dezembro de 2019 21:27
  • Prezado Neibala, 

    Respondendo diretamente a sua pertgunta, não. 

    Se estiver usando os Tracers informados e quiser volta ao normal , terá que reiniciar. 

    nas versões mais Atuais do Sql Server 2016 a coisa melhorou bastante conforme já explorado aqui. 


    Se esta resposta lhe ajudou, marque-a como útil para que outra pessoa com dúvida ou problema semelhante possa encontrar resposta ou ajuda mais facilmente. * Jefferson Clyton Pereira da Silva - [ MCSA | MCP | MCTS | MTA | Analista de Banco de Dados - Sql Server e Oracle ]

    terça-feira, 10 de dezembro de 2019 02:26
  •    Jefferson / José Diz / Pedro

        Primeiramente quero agradecer a todas as informações e dicas enviadas, onde algumas tinha visto anteriormente, já outras adicionei como referência, pois achei algumas coisas muito interessante.

        Já vendo o problema que estou no momento e vendo a informação do Jefferson na questão do reiniciar eu acabei encontrando os links abaixo, onde agora estou com dúvida se a ordem que descrevi abaixo seria a mais correta e com isto eu não precisaria mais reiniciar o serviço do SQL Server, caso os arquivos do tempdb fiquem desalinhados na questão do tamanho dos arquivos.

    https://www.brentozar.com/archive/2016/02/when-shrinking-tempdb-just-wont-shrink/

    https://sqlsunday.com/2013/08/11/shrinking-tempdb-without-restarting-sql-server/

    CHECKPOINT;
    GO

    DBCC DROPCLEANBUFFERS;
    GO

    DBCC FREEPROCCACHE;
    GO

    DBCC FREESYSTEMCACHE ('ALL');
    GO

    DBCC FREESESSIONCACHE;
    GO

    quarta-feira, 11 de dezembro de 2019 12:35
  • Neibala,

    Na verdade para este procedimento não existe uma "ordem" único e exclusiva, na verdade este procedimento deve ser aplicado em horários em que seus bancos de dados não estão sendo acessandos por usuários ou aplicações externas.

    Mas sabia que estes procedimentos não vão alterar o tamanho ou liberar espaço em disco dos arquivos, todos eles estão diretamente relacionados com alocações de dados em memória, páginas de dados que estão em cache, bem como, demais elementos que encontra-se na fila de processsamento por parte do SQL Server, em relação ao Buffer Cache, Database Engine e Storage Engine.

    Para que realmente você possa ter uma nova mudança e redistribuição de espaço físico e lógico em disco, será necessário reinicializar o serviço do SQL Server.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    quarta-feira, 11 de dezembro de 2019 13:46
    Moderador
  • Deleted
    quarta-feira, 11 de dezembro de 2019 16:41
  • Pedro  / José Diz /  Jefferson

         Pessoal na questão do espaço a minha dúvida seria se eu utilizar esses comandos eu conseguiria rodar novamente depois o shrink onde estaria reorganizando os arquivos e com isto os meus arquivos tempdb voltaria quase ao mesmo tamanho e com isto eu não precisaria de momento reiniciar o serviço do SQL Server correto ?

    quinta-feira, 12 de dezembro de 2019 13:01
  • Neibala,

    A resposta simples e direta é NÃO, como já destacamos estes comandos não estão relacionados com o tamanho físico dos arquivos, muito menos com o processo de Shrink.

    O Shrink é um processo relacionado aos arquivos de dados e log, ao realizar o ShrinkDatabase ou ShrinkFile você estará através do Database Engine interagindo com o Storage Engine, e este mecanismo é o responsável por toda para de armazenamento de dados, ele é quem estará conversando com o Sistema Operacional para realizar as solicitações de diminuição, readequação e realocação de espaço físico em disco.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    quinta-feira, 12 de dezembro de 2019 16:55
    Moderador