Gerenciamento de buffer
A finalidade principal de um banco de dados do SQL Server é armazenar e recuperar dados, portanto, a E/S intensiva de disco é uma característica principal do Mecanismo de Banco de Dados. Como as operações de E/S de disco podem consumir muitos recursos e levar um tempo relativamente longo para terminar, o SQL Server se concentra em tornar a E/S altamente eficiente. O gerenciamento de buffer é um componente fundamental para alcançar essa eficiência. O componente de gerenciamento de buffer consiste em dois mecanismos: o gerenciador de buffer para acessar e atualizar páginas de banco de dados e o cache do buffer (também chamado de pool de buffers), para reduzir a E/S do arquivo de banco de dados.
Como funciona o gerenciamento de buffer
Um buffer é uma página de 8 KB da memória, mesmo tamanho de uma página de dados ou de índice. Portanto, o cache do buffer é dividido em páginas de 8 KB. O gerenciador de buffer gerencia as funções lendo páginas de dados ou de índice dos arquivos do disco de banco de dados no cache do buffer e gravando páginas modificadas de volta no disco. Uma página permanece no cache do buffer até que o gerenciador de buffer precise da área de buffer para ler mais dados. Os dados serão gravados no disco apenas se forem modificados. Os dados podem ser modificados no cache do buffer várias vezes antes de serem gravados no disco. Para obter mais informações, consulte Lendo páginas e Gravando páginas.
Quando o SQL Server é iniciado, computa o tamanho de espaço de endereço virtual para o cache do buffer baseado em vários parâmetros, como quantidade de memória física no sistema, número configurado de threads de servidor máximo e vários parâmetros de inicialização. O SQL Server reserva essa quantidade computada de seu espaço de endereço virtual de processo (chamado destino de memória) para o cache do buffer, mas adquire (confirma) somente a quantidade exigida de memória física da carga atual. Você pode consultar as colunas bpool_commit_target e bpool_committed na exibição do catálogo sys.dm_os_sys_info para retornar o número de páginas reservado como destino de memória e o número de páginas atualmente confirmado no cache do buffer, respectivamente.
O intervalo entre a inicialização do SQL Server e o momento em que o cache do buffer obtém seu destino de memória é chamado de ramp-up. Nesse momento, as solicitações de leitura preenchem os buffers conforme necessário. Por exemplo, uma solicitação de leitura de página única preenche apenas uma página de buffer. Isso significa que o ramp-up depende do número e do tipo de solicitações do cliente. O ramp-up é expedido transformando as solicitações de leitura de página única em solicitações de oito páginas alinhadas. Isso permite ao ramp-up terminar de forma muito mais rápida, especialmente em máquinas com muita memória.
Como o gerenciador de buffer usa a maior parte da memória no processo do SQL Server, ele coopera com o gerenciador de memória para permitir que outros componentes usem seus buffers. O gerenciador de buffer interage principalmente com os seguintes componentes:
Gerenciador de recurso para controlar o uso de memória global e, em plataformas de 32 bits, controlar o uso de espaço de endereço.
Gerenciador de banco de dados e SQLOS (SQL Server Operating System) para operações de E/S de arquivo de nível baixo.
Gerenciador de log para log write-ahead.
Recursos com suporte
O gerenciador de buffer oferece suporte aos seguintes recursos:
O gerenciador de buffer reconhece NUMA (acesso não uniforme à memória por software). São distribuídas páginas de cache do buffer em nós NUMA de hardware, que permitem a um thread acessar uma página de buffer alocada no nó NUMA local em vez de memória externa. Para obter mais informações, consulte Como o SQL Server oferece suporte a NUMA. Para compreender como são atribuídas páginas de memória do cache do buffer ao usar NUMA, consulte Aumentando e reduzindo o pool de buffers no NUMA.
O gerenciador de buffer oferece suporte à Inclusão de Memória a Quente, que permite aos usuários adicionar memória física sem reiniciar o servidor. Para obter mais informações, consulte Inclusão de Memória a Quente.
O gerenciador de buffer oferece suporte à alocação de memória dinâmica em plataformas de 32 bits do Microsoft Windows XP e do Windows 2003 quando AWE está habilitado. A alocação de memória dinâmica permite ao Mecanismo de Banco de Dados adquirir e liberar eficazmente memória no cache do buffer para oferecer suporte à carga de trabalho atual. Para obter mais informações, consulte Gerenciamento de memória dinâmica.
O gerenciador de buffer oferece suporte a páginas grandes em plataformas de 64 bits. O tamanho da página é específico para a versão do Windows. Para obter mais informações, consulte a documentação do Windows.
O gerenciador de buffer fornece diagnósticos adicionais que são expostos por meio de exibições de gerenciamento dinâmico. Você pode usar essas exibições para monitorar uma variedade de recursos de sistema operacional específicos do SQL Server. Por exemplo, é possível usar a exibição sys.dm_os_buffer_descriptors para monitorar as páginas no cache do buffer. Para obter mais informações, consulte Funções e exibições de gerenciamento dinâmico relacionadas ao sistema operacional do SQL Server (Transact-SQL).
E/S de disco
O gerenciador de buffer apenas faz leituras e gravações no banco de dados. Outras operações de arquivo e banco de dados, como abrir, fechar, estender e reduzir são executadas pelos componentes do gerenciador de banco de dados e de arquivos.
As operações de E/S de disco pelo gerenciador de buffer têm as seguintes características:
Todas as E/S são executadas de forma assíncrona, o que permite ao thread de chamada continuar o processamento enquanto a operação de E/S acontece em segundo plano.
Todas as E/S são emitidas nos threads de chamada, a menos que a opção affinity I/O esteja em uso. A opção affinity I/O mask associa a E/S de disco do SQL Server a um subconjunto especificado de CPUs. Em ambientes avançados OLTP (transação online) do SQL Server, essa extensão pode aumentar o desempenho de threads do SQL Server que emitem E/Ss.
Várias E/Ss de página são realizadas com E/S de dispersar e reunir, que permite transferir dados para dentro ou para fora de áreas não contíguas de memória. Isso significa que o SQL Server pode preencher ou liberar o cache do buffer rapidamente enquanto evita várias solicitações de E/S físicas.
Solicitações de E/S demoradas
O gerenciador de buffer fornece informações sobre qualquer solicitação de E/S pendente durante pelo menos 15 segundos. Isso ajuda o administrador de sistema a distinguir entre problemas do SQL Server e problemas do subsistema de E/S. A Mensagem de erro 833 é informada e exibida no log de erros do SQL Server como segue:
O SQL Server encontrou % ocorrência(s) de solicitações de E/S que leva(m) mais de % segundos para ser(em) concluída(s) no arquivo [% ls] do banco de dados [% ls] (% d). O identificador de arquivo do SO é 0x%p. O deslocamento da E/S mais demorada é: %#016I64x.
Uma E/S demorada pode ser uma leitura ou uma gravação. Isso não está indicado atualmente na mensagem. Mensagens de E/S demoradas são avisos, não erros. Elas não indicam problemas com o SQL Server. As mensagens são informadas para ajudar o administrador de sistema a encontrar mais depressa a causa de tempos de resposta insatisfatórios do SQL Server e distinguir problemas que estão fora do controle do SQL Server. Como tal, eles não exigem nenhuma ação, mas o administrador de sistema deve investigar por que a solicitação de E/S demorou tanto e se o tempo é justificável.
Causas de solicitações de E/S demoradas
Uma mensagem de E/S demorada pode indicar que uma E/S está bloqueada permanentemente e nunca será concluída (conhecida como E/S perdida) ou, então, que apenas não foi concluída ainda. Não é possível distinguir qual é o cenário com base na mensagem, embora uma E/S perdida geralmente conduza a um tempo limite de trava.
E/S demorada geralmente indica uma carga de trabalho do SQL Server muito intensa para o subsistema de disco. Um subsistema de disco inadequado pode ser indicado quando:
Várias mensagens de E/S demorada são exibidas no log de erros durante uma carga de trabalho pesada do SQL Server.
Contadores de desempenho mostram latências de disco demoradas, filas de disco demoradas ou nenhum tempo ocioso de disco.
E/Ss demoradas também podem ser causadas por um componente no caminho de E/S (por exemplo, driver, controlador ou firmware) que continuamente adia o atendimento de uma solicitação de E/S antiga a favor do atendimento mais próximo à posição atual da cabeça de disco. A técnica comum de processamento de solicitações com prioridade baseada no atendimento mais próximo à posição atual da cabeça de leitura/gravação é conhecida como "busca de menor caminho". Isso pode ser difícil de confirmar com a ferramenta do Windows System Monitor (PERFMON.EXE) porque a maioria das E/Ss está sendo atendida prontamente. As solicitações de E/S demoradas podem ser agravadas por cargas de trabalho que executam grandes quantidades de E/S seqüenciais, como backup e restauração, exames de tabela, classificação, criação de índices, carregamentos em massa e anulação de arquivos de saída.
E/Ss demoradas e isoladas que não aparecem relacionadas a quaisquer condições anteriores podem ser causadas por um problema de hardware ou driver. O log de eventos do sistema pode conter um evento relacionado que ajuda a diagnosticar o problema.
Detecção de erro
As páginas de banco de dados podem usar um dentre dois mecanismos opcionais que ajudam a garantir a integridade da página do momento em que é gravada no disco até ser lida novamente: proteção de página interrompida e proteção de soma de verificação. Esses mecanismos permitem um método independente para verificar a exatidão não apenas do armazenamento de dados, mas de componentes de hardware, como controladores, drivers, cabos e até mesmo o sistema operacional. A proteção é adicionada à página um pouco antes da gravação no disco e verificada depois da leitura do disco.
Proteção de página interrompida
Proteção de página interrompida, apresentada no SQL Server 2000, é principalmente um modo de detectar páginas corrompidas devido a falhas de energia. Por exemplo, uma falha de energia inesperada pode deixar apenas parte de uma página gravada no disco. Quando a proteção de página interrompida é usada, uma assinatura de 2 bits é colocada no final de cada setor de 512 bytes na página (depois de ter copiado os dois bits originais no cabeçalho da página). A assinatura alterna entre 01 e 10 binário com toda gravação, de modo que seja sempre possível informar quando apenas uma parte dos setores realizou essa operação no disco: se um bit estiver com estado inválido quando a página for lida posteriormente, a página foi gravada incorretamente e uma página interrompida é detectada. A detecção de página interrompida usa recursos mínimos; porém, não detecta todos os erros causados por falhas de hardware de disco.
Proteção de soma de verificação
Proteção de soma de verificação, apresentada no SQL Server 2005, fornece verificação de integridade de dados mais resistente. Uma soma de verificação é calculada para os dados de cada página gravada e armazenada no cabeçalho da página. Sempre que uma página com uma soma de verificação armazenada é lida no disco, o Mecanismo de Banco de Dados recalcula a soma de verificação dos dados na página e gera o erro 824 se a nova soma de verificação for diferente da soma de verificação armazenada. A proteção de soma de verificação pode capturar mais erros que a proteção de página interrompida porque é afetada por todo byte da página, porém, é um recurso moderadamente intensivo. Quando a soma de verificação for habilitada, os erros causados por falta de energia e falha de hardware ou firmware poderão ser detectados sempre que o gerenciador de buffer ler uma página do disco.
O tipo de proteção de página usado é um atributo do banco de dados que contém a página. A proteção de soma de verificação é a proteção padrão para bancos de dados criados no SQL Server 2005 e posterior. O mecanismo de proteção de página é especificado no momento de criação do banco de dados e pode ser alterado usando ALTER DATABASE. Você pode determinar a configuração de proteção da página atual consultando a coluna de page_verify_option na exibição do catálogo sys.databases ou na propriedade IsTornPageDetectionEnabled da função DATABASEPROPERTYEX. Se a configuração de proteção de página for alterada, a configuração nova não afetará imediatamente o banco de dados inteiro. Em vez disso, as páginas adotarão o nível de proteção atual do banco de dados sempre que eles forem gravados posteriormente. Isso significa que o banco de dados pode ser composto de páginas com tipos diferentes de proteção.
Consulte também