Entenda o ciclo de vida de uma Query no SQL Server: Parte 2
Anteriormente, no último artigo, nós havíamos percorrido “todo” caminho de uma Query, da sua execução à entrega ao solicitante. Mas, será que algo além acontece nos bastidores? A resposta é, como quase sempre será, sim! Neste artigo, vamos nos aprofundar no Storage Engine, Buffer Pool, Access Methods e Transaction Log. Pegue o café e venha desvendar mais uma etapa sobre a execução de processos DDL e DML. Como falamos anteriormente, nesta etapa há diferenças entre processos DDL e DML. Vamos começar pela primeira: DDL é uma abreviação de Data Definition Language (Linguagem de Definição de Dados), ou seja, uma linguagem que cria ou modifica estrutura de objetos no banco de dados. Um exemplo rápido são comandos do tipo CREATE, ALTER E DROP. Neste caso, quando o procedimento chega no Query Executor há uma interação com o Storage Engine através do Access Methods, que é quem fornece as estruturas de armazenamento dos dados e índices, bem como a interface pela qual os dados são recuperados e modificados. Ele é responsável por armazenar operações de linha, índice, alocação de páginas e versionamento. Apesar de conter todo o código da operação, ele não executa, pois, neste ponto ele passa a requisição ao Buffer Manager. Você se lembra que, no primeiro artigo, comentamos que na etapa do Command Parser, o SQL analisa se há um plano de execução pronto para aquela requisição? Pois esta é justamente uma das funções do Buffer Manager: Ele é responsável por gerenciar o Buffer Pool, ou seja, ele cuida de toda parte de recebimento, armazenagem e entrega de dados. Se você precisar ler algumas linhas de uma página de dados, ele verificará se esta página já está na cache de memória e, caso não esteja, ele buscará esta página no disco, armazenará na cache e só então devolve o resultado ao Access Methods. É nesta última etapa que acontece o famoso Wait_Type PAGEIOLATCH, que representa o tempo necessário para ler uma página do disco e guardar em memória. Ele também é responsável por gerenciar funções de I/O de disco para trazer páginas de dados e índices para a cache de memória e compartilhar com os usuários, além de assegurar que o Transaction Log seja escrito antes que cada alteração de banco seja executada, garantindo que essas informações guardadas no Transaction Log tenham uma ordem específica e deixando claro quais blocos de registro devem ser processados em caso de falha de sistema, independentemente de quando ou onde houve a falha. Bom, já sabemos que existe Buffer Pool e que quem “gerencia” essa casinha é o Buffer Manager. Contudo, neste Pool não existe apenas a Plan Cache (aliás, esta é a menor parte), existe também o Data Cache e nós vamos falar um pouco mais sobre ele agora. O Data Cache é a partição do Buffer Pool que ocupa mais espaço. É nele que todas (sim, todas) as páginas de dados são lidas a partir do disco antes de serem usadas. E quando eu digo disco, são os datafiles dos bancos. O tempo que as páginas permanecem em cache é determinado por uma política LRU, para a qual precisamos abrir um parênteses: LRU-K (Last Recently Used) é um algoritmo que mantém “fresco na memória” uma página que é referenciada K vezes. Cada página de dados possui em seu cabeçalho detalhes das duas últimas vezes em que a página foi acessada e é feita uma varredura periódica para determinar se essa página deve ou não continuar em Cache. Essa varredura também é efetuada pelo Buffer Manager. Sempre que uma varredura é feita, um contador é colocado na página e é incrementado toda vez que a página não é acessada por um determinado período de tempo e quando o SQL Server precisa liberar espaço em cache. Então, as páginas com o contador mais baixo são retiradas da Cache. Um tempo recomendado para que todo esse processo deva ocorrer é de 1000s. Agora vamos falar sobre comandos do tipo DML. DML é uma abreviação de Data Modification Language (Linguagem de modificação de Dados). Esta é uma linguagem que resgata, guarda, modifica, insere, deleta e atualiza dados no banco de dados. Exemplo disso são comandos do tipo SELECT, UPDATE, INSERT, DELETE e etc. O que difere os processos de DML dos processos de DDL, é que, no DML, em paralelo atua também o Transaction Manager. Quando o Buffer Manager recebe uma requisição de alteração, ela encaminha antes ao Transaction Manager para que este guarde um log desta transação para que só então guarde as páginas em cache. O Transaction Manager possui dois componentes para garantir a consistência da requisição: O Lock Manager e o Log Manager. O Lock Manager gerencia a concorrência de dados através de locks e o Log Manager armazena de fato o log da transação no logfile. Esse tipo de processo é chamado de WAL (Write-ahead Logging). Mas, neste processo, ainda falta alguém. De maneira análoga, o Buffer Manager está para o Buffer Pool assim como o Transaction Manager está para o Transaction Log! O Transaction Log, utiliza o logfile através dos VLF’s (Virtual Log Files) para armazenar e ordenar esses dados “recuperáveis”. Essa arquitetura é relativamente simples e a receita que o SQL Server usa é basicamente o seguinte: E com isso, finalizamos mais um artigo. Os métodos de Recovery (recuperação) serão abordados em outra ocasião, pois é um processo um tanto quanto extenso. Então, fique atento ao Blog da Rox, pois em breve será publicada a parte 3 deste conteúdo superinteressante. Até a próxima e se inscreva em nossa newsletter!Storage Engine – Access Methods
Storage Engine – Buffer manager
Storage Engine – Data Cache
Storage Engine – Transaction Manager / Transaction Log
