Vamos a um resumão do primeiro dia de evento aqui em Seattle...
Eu e o Fernando, outro SQLGeek que está aqui para o evento, chegamos no Washington conference center por volta de 7:30 e fizemos o registro no evento, depois de um lanchinho eu fui para a minha sessão pré-conferência: Care and feeding of the transaction log, com a famosa autora Kalen Delaney. O Fernando foi ouvir a Kimberly Tripp falando sobre indexação, espero que depois ele coloque mais informações no seu blog.
Nem preciso dizer que eu estava super ansioso pela sessão, mas acho que expectativa demais sempre é ruim. Em uma sala parcialmente cheia nós tivemos os seguintes tópicos sobre T-LOG:
- Log Internals
- Physical Log Management
- Restore and Recovery
- Logging Experinence
- Best and Wort Practices
O primeiro e segundo tópicos foram de uma profundidade razoável, falando um pouco sobre VLFs, log cíclico, DBCC LOGINFO, Truncate, etc. Aqui eu esperava ver mais detalhes sobre o T-LOG, mas acho que se ela aprofundasse mais o material seria considerado MS Only (interno da Microsoft). A discussão sobre quantidade de VLFs no log file foi interessante e ela disse que existe um post bacana da Kimberly sobre o assunto, que deve ser esse: http://www.sqlskills.com/BLOGS/KIMBERLY/post/Transaction-Log-VLFs-too-many-or-too-few.aspx. Parece que no SQL11 teremos um warning que irá nos avisar quando o número de VLFs chegar a mais de 1000, vamos ver se aparece mesmo.
Uma pergunta boa que passou sem resposta foi: porque o FSeqNo começa em 34 (ou outro número qualquer) quando um novo banco de dados foi criado?
Eu não tenho absoluta certeza do que vou dizer agora pois não busquei na documentação, mas acho que existe uma boa chance de eu estar certo... Todos os bancos de dados são criados seguindo o banco Model, que precisou do log para registrar as instruções em sua criação, usando VLFs e gerando FSeqNos. Quando criamos um novo banco ele leva a estrutura do Model, inclusive a informação do FSeqNo, por isso a numeração não começa no 1 (ou zero). Usando o SQL Server 2008 SP1 eu vejo o seguinte resultado, utilizando o DBCC LOGINFO na model e em um banco recém criado (respectivamente):
FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
----------- -------------------- -------------------- ----------- -----------
2 253952 8192 17 0 128 0
2 262144 262144 18 2 128 0
FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
----------- -------------------- -------------------- ----------- -----------
2 253952 8192 18 2 64 0
2 253952 262144 0 0 0 0
É interessante notar que a paridade muda, então não me parece uma cópia da informação, pois esse bit é alterado (64 ou 128) a cada novo uso do VLF.
No tópico Restore and Recovery vimos checkpoints, recovery, REDO, UNDO, backup e restore, com RECOVERY, NO_RECOVERY, COPY_ONLY e STANDBY. Muitas dúvidas sobre o assunto, algumas bem viajantes, outras não, que formam respondidas pela Kalen. Uma coisa que eu gostaria de ressaltar aqui é que os registros do log são escritos em disco SOMENTE quando uma transação é commitada ou checkpoint ocorre (e mais outros momentos, se não me engano), e não a todo momento em que uma instrução é executada. Isso é uma coisa que não é muito falada e eu mesmo acreditava no passado que a todo instante o SQL Server estava escrevendo no log, o que é errado.
Dentro todos os tópicos o mais legal foi quando discutimos logging experience, que falamos sobre os recovery models, onde houveram muitas perguntas e eu anotei alguns cenários que ficaram no ar para testar em casa. Deixo aqui uma referência que eu já havia dado uma olhada mas acho que deve ficar na lista de leitura de todos: The Data Loading Performance Guide (http://msdn.microsoft.com/en-us/library/dd425070.aspx).
Ela também falou um pouco sobre os comando DBCC LOG e FN_DBLOG, que já são conhecidos de quem brinca com o SQL Server faz um tempinho, então não sei se foi grande novidade para o pessoal na sala. No fim ela passou por uma lista de recomendações que devem ser lidas por todos, para vermos se não estamos esquecendo de alguma coisa.
Durante o evento ela falou sobre algoritmos de logging, aí eu lembrei de um paper interessante para os mais viciados: ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging (http://portal.acm.org/citation.cfm?id=128770).
Uma dica que deixo aqui é a página da Kalen, onde ela publica dados sobre suas apresentações em conferências. Dê uma olhada em: http://insidesqlserver.com/conferences/.
Minha avaliação sincera, sem querer parecer um babaca:
No fim eu achei a sessão regular, pois estava com a expectativa lá no céu, afinal é a KALEN DELANEY, e já faz algum tempo que estudo o T-LOG, inclusive com alguns dados mais detalhados enquanto estava na Microsoft. Porém para aqueles que já possuem experiência com o produto, mas não ficam alucinados com Internals e lendo livros atrás de livros, a sessão foi excelente, para os iniciantes, ela seria boa, mas um pouco viajante.
Também esperava que a Kalen tivesse a mesma energia contagiante que a Kimberly têm em suas sessões, pois gosto de ver o apresentador se empolgando com o que está falando...
Estou aqui no keynote de abertura oficial do evento, depois mando novidades para todos.
[]s
Luciano Caixeta Moreira - {Luti}
Chief Innovation Officer
Sr. Nimbus Serviços em Tecnologia Ltda
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
Nenhum comentário:
Postar um comentário