Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se a:
SQL ServerInstância Gerenciada de SQL do Azure
A E/S de uma instância do Mecanismo de Banco de Dados do SQL Server inclui leituras lógicas e físicas. Uma leitura lógica ocorre sempre que o Mecanismo de Banco de Dados solicita uma página do cache de buffer, também conhecido como pool de buffers. Se a página não estiver atualmente no cache do buffer, uma leitura física primeiro copiará a página do disco para o cache.
As solicitações de leitura geradas por uma instância do Mecanismo de Banco de Dados são controladas pelo mecanismo relacional e otimizadas pelo mecanismo de armazenamento. O mecanismo relacional determina o método de acesso mais eficaz (como uma verificação de tabela, uma verificação de índice ou uma leitura com chave). Os métodos de acesso e os componentes do gerenciador de buffers do mecanismo de armazenamento determinam o padrão geral de leituras a serem executadas e otimizam as leituras necessárias para implementar o método de acesso. O thread que executa o lote agenda as leituras.
Leitura antecipada
O Mecanismo de Banco de Dados dá suporte a um mecanismo de otimização de desempenho chamado leitura antecipada. A leitura antecipada antecipa os dados e as páginas de índice necessárias para atender a um plano de execução de consulta e traz as páginas para o cache de buffer antes de serem usadas pela consulta. Esse processo permite que a computação e a E/S se sobreponham, aproveitando ao máximo a CPU e o disco.
O mecanismo de leitura antecipada permite que o Mecanismo de Banco de Dados leia até 64 páginas contíguas (512 KB) de um arquivo. A leitura é feita como uma só leitura de dispersão/coleta para o número apropriado de buffers (provavelmente não adjacentes) no pool de buffers. Se uma das páginas do intervalo já estiver presente no pool de buffers, a página correspondente da leitura será descartada quando for concluída. O intervalo de páginas também poderá ser “cortado” de uma das extremidades se as páginas correspondentes já estiverem presentes no cache.
Há dois tipos de leitura antecipada: um para páginas de dados e outro para páginas de índice.
Ler páginas de dados
As verificações de tabela usadas pelo Mecanismo de Banco de Dados para ler páginas de dados são eficientes. As páginas IAM (Index Allocation Map) em um banco de dados do SQL Server listam as extensões usadas por uma tabela ou um índice. O mecanismo de armazenamento pode ler o IAM para criar uma lista ordenada de endereços de disco que devem ser lidos. Isso permite ao mecanismo de armazenamento otimizar suas E/S como grandes leituras sequenciais, executadas em sequência, com base em seu local no disco. Para obter mais informações sobre páginas IAM, consulte Gerenciar espaço usado por objetos.
Ler páginas de índice
O mecanismo de armazenamento lê páginas de índice em série na ordem de chave. Por exemplo, esta ilustração mostra uma representação simplificada de um conjunto de páginas folha que contém um conjunto de chaves e o nó de índice intermediário que mapeia as páginas folha. Para obter mais informações sobre a estrutura de páginas em um índice, consulte índices clusterizados e não clusterizados.
O mecanismo de armazenamento utiliza as informações na página de índice intermediária acima do nível de folha para agendar antecipações de leitura sequenciais para as páginas que contêm as chaves. Se uma solicitação for feita para todas as chaves de ABC a DEF, o mecanismo de armazenamento primeiro lerá a página de índice acima da página folha. No entanto, ele não lê apenas cada página de dados em sequência da página 504 até a página 556 (a última página com chaves no intervalo especificado). Em vez disso, o mecanismo de armazenamento examina a página de índice intermediária e cria uma lista de páginas folha que devem ser lidas. O mecanismo de armazenamento agenda todas as leituras em ordem da chave. O mecanismo de armazenamento também reconhece que as páginas 504/505 e 527/528 são contíguas e executa uma única leitura de dispersão para recuperar as páginas adjacentes em uma única operação. Quando há muitas páginas a serem recuperadas em uma operação consecutiva, o mecanismo de armazenamento agenda um bloco de leituras por vez. Quando um subconjunto dessas leituras é concluído, o mecanismo de armazenamento agenda um número igual de novas leituras até que todas as leituras necessárias sejam agendadas.
O mecanismo de armazenamento usa a pré-busca para acelerar as pesquisas de tabela base de índices não clusterizados. As linhas de folha de um índice não clusterizado contêm ponteiros para as linhas de dados que contém cada valor de chave específico. À medida que o mecanismo de armazenamento lê as páginas folha do índice não clusterizado, ele também inicia o agendamento de leituras assíncronas para as linhas de dados cujos ponteiros já foram recuperados. Isso permite que o mecanismo de armazenamento recupere linhas de dados da tabela subjacente antes de concluir a verificação do índice não clusterizado. A pré-busca é usada independentemente de a tabela ter um índice clusterizado. O SQL Server Enterprise Edition usa mais pré-buscas do que as outras edições do SQL Server, permitindo que a leitura antecipada seja feita em um número maior de páginas. O nível de pré-busca não é configurável em nenhuma edição. Para obter mais informações sobre índices não clusterizados, consulte índices clusterizados e não clusterizados.
Verificação avançada
No SQL Server Enterprise Edition, o recurso de verificação avançada permite que várias tarefas compartilhem verificações de tabela completas. Caso o plano de execução de uma instrução Transact-SQL exija uma verificação das páginas de dados em uma tabela e o Mecanismo de Banco de Dados detecte que a tabela já está sendo verificada para outro plano de execução, o Mecanismo de Banco de Dados associará a segunda verificação à primeira, no local atual da segunda verificação. O Mecanismo de Banco de Dados lê cada página uma vez e passa as linhas de cada página para ambos os planos de execução. Isso continua até o fim da tabela ser alcançado.
Nesse ponto, o primeiro plano de execução já contém os resultados completos de um rastreamento. No entanto, o segundo plano de execução ainda precisa recuperar as páginas de dados que foram lidas antes da entrada na verificação em andamento. Em seguida, a verificação do segundo plano de execução volta à primeira página de dados da tabela e verifica mais adiante o ponto em que ela entrou na primeira verificação. Qualquer número de verificações pode ser combinado dessa forma. O Mecanismo de Banco de Dados continua circulando pelas páginas de dados até concluir todas as verificações. Esse mecanismo também é conhecido como “verificação carrossel” e demonstra o motivo pelo qual a ordem dos resultados retornada de uma instrução SELECT não pode ser garantida sem uma cláusula ORDER BY.
Por exemplo, suponha que você tenha uma tabela com 500.000 páginas. UserA executa uma instrução Transact-SQL que requer uma verificação da tabela. Quando essa verificação processa 100.000 páginas, UserB executa outra instrução Transact-SQL que verifica a mesma tabela. O Mecanismo de Banco de Dados agenda um conjunto de solicitações de leitura para as páginas após 100.001 e passa as linhas de cada página de volta para as duas verificações. Quando a verificação atinge a 200.000ª página, UserC executa outra instrução Transact-SQL que verifica a mesma tabela. A partir da página 200.001, o Mecanismo de Banco de Dados passa as linhas de cada página que lê de volta para as três verificações. Depois de ler a linha 500.000, a verificação do UserA será concluída, e as verificações do UserB e do UserC voltarão para o início e começarão a ler as páginas a partir da página 1. Quando o Mecanismo de Banco de Dados chegar à página 100.000, a verificação de UserB estará concluída. Em seguida, a verificação do UserC continua sozinha até ela ler a página 200.000. Nesse ponto, todas as verificações estarão concluídas.
Sem a verificação avançada, cada usuário precisaria competir pelo espaço do buffer e isso causaria a contenção do ARM do disco. As mesmas páginas seriam lidas uma vez para cada usuário, em vez de serem lidas uma vez e compartilhadas por vários usuários, reduzindo a velocidade do desempenho e sobrecarregando os recursos.