Category Archives: SQL Server Internals

Possible Index Corruption. Diagnosticando o problema

Olá pessoal,

Estou a algum tempo sem escrever nada tecnico e essa semana me deparei com um problema um tanto quanto chato, porem acho que será de extrema importancia relatar ele aqui para todos. Com certeza devemos ter outras referencias na web, então aqui será apenas mais uma fonte.

Problema

Sexta-feira 18:00 recebo o seguinte e-mail do SQL Server: “Possible index corruption detected. Run DBCC CHECKDB.” Entretanto um erro um tanto quanto estranho, já que o error id era 9100 e não os famosos 823 e 824.

O pior de tudo isso era o problema não retratar em qual base de dados o erro se encontrava. Fiz uma pequena pesquisa no connect e encontrei essa sugestão, e peço que todos votem na mesma. Read the rest of this entry

Quem é o responsável por garantir os dados da minha database?

Ola pessoal,

Iniciando o aprofundamento dos estudos sobre os componentes do SQL Server, vou ser breve em mostrar quem é o responsável por garantir a integridade da minha database. O que muitas vezes vemos errorlog do SQL Server sao essas frases:

Recovery completed for database master (database ID 1) in 2 second(s) (analysis 691 ms, redo 318 ms, undo 602 ms.) This is an informational message only. No user action is required.

ou

1 transactions rolled forward in database ‘AdventureWorksDW’ (6). This is an informational message only. No user action is required.

ou

10 transactions rolled back in database ‘AdventureWorksDW’ (6). This is an informational message only. No user action is required.

Ai eu te pergunto quem realiza essas operaçoes? E voce me responde que isso é de responsabilidade das operacoes UNDO e REDO.

Por parte isso esta certo, mas ainda assim por traz desses dois nomes temos um processo por traz disso tudo chamado de WRITE-AHEAD LOGGING.

Toda essa magica de sincronização acontece graças a esse agente que é garantido que cada mudança ocorrida é enviada primeiramente para o transaction log antes que digamos que esteja como commitada, e que os registros do log são sempre escritos no disco antes que as paginas de dados onde as mudanças foram atualmente feitas sejam escritas.

Vale lembrar que a escrita nas paginas de dados muitas vezes ocorrem de forma assíncrona, pois todas as mudanças podem ser recuperadas do arquivo de log se necessário. É importante lembrar também que o componente de gerenciamento do transaction log gerencia também a operacao de logging, recoverying, e gerenciamento do buffer.
Temos ainda um tipo de wait para ele que se chama WRITELOG. Em um outro post em um outro dia vamos falar um pouco dele.

Espero que tenham gostado desse post, tentei ser o mais simples possivel. A medida que os estudos forem avançando, vou avançando o conteudo dos posts.. so…. stay tuned !!

Att,
Marcos Freccia
[MCTS|MCITP|MCT SQL Server 2008]