Esse post faz parte da série: pequenas curiosidades que (quase) ninguém se importa, tipo a notícia que o G1 divulgou da marmota que ficou presa numa tampa de bueiro nos EUA.
O comando DBCC LOGINFO é um comando não-documentado pela Microsoft.
Mas existe. E tá aí firme e forte (e disponível) até hoje no código do SQL Server. Pode comprovar caso queira no SQL Server 2014. O que não quer dizer que estou recomendando o seu uso 🙂
Abaixo, resultado do comando exatamente depois que eu criei uma base qualquer.
E pra que ele é utilizado? Com ele, é possível visualizar de modo amigável os VLF’s do Log de Transação da base que está sendo utilizada no momento e descobrir duas informações importantes:
- Tamanho e quantidade dos VLF’s: Pelas linhas retornadas, você identifica se tem muitos VLF’s naquele T-log em específico. Pela coluna FileSize, identifica o tamanho. Esse é o caminho pra se identificar a famosa fragmentação no T-log.
- Status: 0 indica que aquele VLF está sem uso, 2 indica uso. Pra estudos, ela é ótima. Pra vida real mesmo, talvez seja útil para algum troubleshooting no arquivo de log.
Uma coluna que é bem interessante (mas por si só não diz muita coisa) é o FSeqNo, que é um número dinâmico que vai mudando de acordo com o crescimento e a movimentação circular nos VLF’s. Contudo, como o próprio nome sugere, deveria ser um número sequencial, certo?
Porque será que o único VLF utilizado (e ativado) começou do 89 e não de algum número como 1, por exemplo?
A resposta está na…..
Model 😀
A Model é aquela base de sistema que ninguém acha importante mas sem ela muita coisa não acontece, e uma delas é a criação de uma base. Uma das coisas que você pode ter pensado é a seguinte: – Será que esse número 89 veio da model?
Dá pra descobrir isso fazendo um DBCC LOGINFO na model (só pra tira-teima):
OH! O último VLF da model estava com o FSeqNo 88, e quando eu criei uma base nova, como todo filho deve ser, puxou os traços da mãe, e acrescentou um +1 no número da sequência. Em outras palavras, o FSeqNo da base recém-criada se baseia na model.
Curiosidade resolvida e documentada :p
Agora, três perguntas que podem estar sendo feitas:
- Porque o FSeqNo dessa model tá “tão alto”? Aqui na minha máquina deu diferente.
Porque eu tava fazendo uns testes nela que logaram algumas transações e aí a sequência chegou nesse número aí.
- Essa informação realmente é útil pra alguma coisa?
Bem, como esse número de sequência é mais de interesse do SQL do que nosso, não, não é de fato uma informação realmente útil. Mas é uma curiosidade legal pra quem está observando um pouco do T-log e alguns comandos relacionados. E é legal a gente pegar um caso assim, onde detalhes que muitos acharam randômicos, fazem algum sentido. MSSQL tá cheio de coisa nesse naipe.
- Então porque você postou algo assim?
Porque eu me divirto bastante postando e fiquei um tempão sem postar (e não quero perder isso). Postar pra retornar ao hábito. E por mais improvável que seja, talvez alguém faça esse questionamento. E se você uma vez se perguntar, lembra deste post. My 0,5 cent 😀
[]’s