Um guia para processamento de consulta de tabelas com otimizao de...

1 de 6

https://msdn.microsoft.com/pt-br/library/dn205319.aspx

Este artigo foi traduzido manualmente. Coloque o ponteiro do mouse sobre as frases do artigo para ver o texto original. Mais informaes.

Traduo

Original

Um guia para processamento de consulta de tabelas com

otimizao de memria
SQL Server 2014
O OLTP na memria incorpora as tabelas com otimizao de memria e os procedimentos armazenados compilados nativamente no SQL Server. Este artigo fornece uma viso geral do
processamento de consulta para tabelas com otimizao de memria e procedimentos armazenados compilados nativamente.
O documento explica como as consultas em tabelas com otimizao de memria so compiladas e executadas, incluindo:
O pipeline do processamento de consulta no SQL Server para tabelas baseadas em disco.
Otimizao de consulta; a funo de estatsticas sobre tabelas com otimizao de memria, bem como diretrizes para solucionar problemas de planos de consulta incorretos.
O uso do Transact-SQL interpretado para acessar tabelas com otimizao de memria.
Consideraes sobre a otimizao de consulta no acesso tabela com otimizao de memria.
Compilao e processamento do procedimento armazenado originalmente compilado.
Estatsticas que so usadas para estimativa de custo pelo otimizador.
Modos de corrigir planos de consulta incorretos.

Consulta de exemplo
O exemplo a seguir ser usado para ilustrar conceitos de processamento de consulta discutidos neste artigo.
Vamos considerar duas tabelas, Customer e Order. O script Transact-SQL a seguir contm as definies dessas duas tabelas e os ndices associados, em seu formato baseado em disco
(tradicional):
Transact-SQL
CREATE TABLE dbo.[Customer] (
CustomerID nchar (5) NOT NULL PRIMARY KEY,
ContactName nvarchar (30) NOT NULL
)
GO
CREATE TABLE dbo.[Order] (
OrderID int NOT NULL PRIMARY KEY,
CustomerID nchar (5) NOT NULL,
OrderDate date NOT NULL
)
GO
CREATE INDEX IX_CustomerID ON dbo.[Order](CustomerID)
GO
CREATE INDEX IX_OrderDate ON dbo.[Order](OrderDate)
GO

Para construir os planos de consulta mostrados neste artigo, as duas tabelas foram populadas com dados de exemplo do banco de dados de exemplo Northwind, que voc pode baixar
em Bancos de dados de exemplo Northwind e pubs do SQL Server 2000.
Considere a consulta a seguir, que une as tabelas Customer e Order e retorna a ID da ordem e as informaes de cliente associadas:
Transact-SQL
SELECT o.OrderID, c.* FROM dbo.[Customer] c INNER JOIN dbo.[Order] o ON c.CustomerID = o.CustomerID

O plano de execuo estimado, conforme exibido pelo SQL Server Management Studio como segue
Plano de consulta para a juno de tabelas baseadas em disco.

Sobre esse plano de consulta:

As linhas da tabela Customer so recuperadas do ndice clusterizado, que a estrutura de dados primria e tem os dados de tabela completos.
Os dados da tabela Order so recuperados usando o ndice no clusterizado na coluna CustomerID. Esse ndice contm a coluna CustomerID, que usada para a juno, e a
coluna de chave primria OrderID, que retornada ao usurio. O retorno de colunas adicionais da tabela Order exigiria pesquisas no ndice clusterizado da tabela Order.
O operador lgico Inner Join implementado pelo operador fsico Merge Join. Os outros tipos de juno fsica so Nested Loops e Hash Join. O operador Merge Join
aproveita o fato de que ambos os ndices so classificados na coluna de juno CustomerID.

25/05/2015 20:49

Um guia para processamento de consulta de tabelas com otimizao de...

2 de 6

https://msdn.microsoft.com/pt-br/library/dn205319.aspx

Considere uma ligeira variao nessa consulta, que retorna todas as linhas da tabela Order, no apenas OrderID:
Transact-SQL
SELECT o.*, c.* FROM dbo.[Customer] c INNER JOIN dbo.[Order] o ON c.CustomerID = o.CustomerID

O plano estimado para essa consulta :

Plano de consulta para uma juno hash de tabelas baseadas em disco.

Nessa consulta, as linhas da tabela Order so recuperadas usando o ndice clusterizado. O operador fsico Hash Match agora usado para Inner Join. O ndice clusterizado em Order
no classificado em CustomerID e, portanto, Merge Join exigiria um operador de classificao, o que afetaria o desempenho. Observe o custo relativo do operador Hash Match
(75%) comparado com o custo do operador Merge Join no exemplo anterior (46%). O otimizador consideraria o operador Hash Match tambm no exemplo anterior, mas concluiu
que o operador Merge Join forneceu melhor desempenho.

Processamento de consulta do SQL Server para tabelas com base no disco

O diagrama a seguir descreve o fluxo de processamento de consulta no SQL Server para consultas ad hoc:
Pipeline do processamento de consulta do SQL Server.

Neste cenrio:
1. O usurio emite uma consulta.
2. O analisador e o algebrista constroem uma rvore de consulta com operadores lgicos de acordo com o texto Transact-SQL enviado pelo usurio.
3. O otimizador cria um plano de consulta otimizado que contm operadores fsicos (por exemplo, juno de loops aninhados). Depois da otimizao, o plano pode ser
armazenado no cache do plano. Essa etapa ser ignorada se o cache do plano j contiver um plano para essa consulta.
4. O mecanismo de execuo de consulta processa uma interpretao do plano de consulta.
5. Para cada busca de ndice, verificao de ndice e operador de verificao de tabela, o mecanismo de execuo solicita linhas das respectivas estruturas de ndice e tabela dos
Mtodos de Acesso.
6. Os Mtodos de Acesso recuperam as linhas das pginas de dados e de ndice no pool de buffers e carregam as pginas do disco no pool de buffers conforme a necessidade.
Para a primeira consulta de exemplo, o mecanismo de execuo solicita dos Mtodos de Acesso as linhas no ndice clusterizado em Customer e no ndice no clusterizado em Order. Os
Mtodos de Acesso passam pelas estruturas de ndice da rvore B para recuperar as linhas solicitadas. Nesse caso, todas as linhas so recuperadas como os planos de chamada para
verificaes de ndice completo.

Acesso do Transact-SQL interpretado a tabelas com otimizao de memria

Os procedimentos armazenados e lotes Transact-SQL ad hoc tambm so conhecidos como Transact-SQLinterpretado. Interpretado se refere ao fato de que o plano de consulta
interpretado pelo mecanismo de execuo da consulta para cada operador no plano de consulta. O mecanismo de execuo l o operador e seus parmetros e executa a operao.
O Transact-SQL interpretado pode ser usado para acessar tabelas com otimizao de memria e baseadas em disco. A figura a seguir ilustra o processamento de consulta para acesso
do Transact-SQL interpretado a tabelas com otimizao de memria:
Pipeline do processamento de consulta para acesso do Transact-SQL interpretado a tabelas com otimizao de memria.

Conforme ilustrado pela figura, na maioria das vezes, o pipeline do processamento de consulta permanece inalterado:
O analisador e o algebrista constroem a rvore de consulta.
O otimizador cria o plano de execuo.

25/05/2015 20:49

Um guia para processamento de consulta de tabelas com otimizao de...

3 de 6

https://msdn.microsoft.com/pt-br/library/dn205319.aspx

O mecanismo de execuo de consulta interpresta o plano de execuo.

A principal diferena em relao ao pipeline de processamento de consulta tradicional (figura 2) que as linhas das tabelas com otimizao de memria no so recuperadas no pool de
buffers usando os mtodos de acesso. Em vez disso, as linhas so recuperadas nas estruturas de dados na memria pelo mecanismo OLTP na memria. As diferenas nas estruturas de
dados fazem com que o otimizador escolha planos diferentes em alguns casos, conforme ilustrado pelo exemplo a seguir.
O script Transact-SQL a seguir contm verses com otimizao de memria das tabelas Order e Customer, usando ndices de hash:
Transact-SQL
CREATE TABLE dbo.[Customer] (
CustomerID nchar (5) NOT NULL PRIMARY KEY NONCLUSTERED,
ContactName nvarchar (30) NOT NULL
) WITH (MEMORY_OPTIMIZED=ON)
GO
CREATE TABLE dbo.[Order] (
OrderID int NOT NULL PRIMARY KEY NONCLUSTERED,
CustomerID nchar (5) NOT NULL INDEX IX_CustomerID HASH(CustomerID) WITH (BUCKET_COUNT=100000),
OrderDate date NOT NULL INDEX IX_OrderDate HASH(OrderDate) WITH (BUCKET_COUNT=100000)
) WITH (MEMORY_OPTIMIZED=ON)
GO

Considere a mesma consulta executada em tabelas com otimizao de memria:

Transact-SQL
SELECT o.OrderID, c.* FROM dbo.[Customer] c INNER JOIN dbo.[Order] o ON c.CustomerID = o.CustomerID

O plano estimado o seguinte:

Plano de consulta para a juno de tabelas com otimizao de memria.

Observe as seguintes diferenas em relao ao plano para a mesma consulta em tabelas baseadas em disco (figura 1):
Esse plano contm uma verificao de tabela em vez de uma verificao de ndice clusterizado para a tabela Customer:
A definio da tabela no contm um ndice clusterizado.
Os ndices clusterizados no tm suporte nas tabelas com otimizao de memria. Em vez disso, cada tabela com otimizao de memria deve ter pelo menos um ndice
no clusterizado e todos os ndices nas tabelas com otimizao de memria podem acessar com eficincia todas as colunas da tabela sem ter que armazen-las no ndice
ou consultar um ndice clusterizado.
Esse plano contm Hash Match em vez de Merge Join. Os ndices nas tabelas Order e Customer so ndices de hash e, portanto, no so ordenados. Um Merge Join exigiria os
operadores de classificao que diminuiriam o desempenho.

Procedimentos armazenados compilados nativamente

Os procedimentos armazenados compilados nativamente so procedimentos armazenados Transact-SQL compilados para cdigo de mquina, no sendo interpretados pela
mecanismo de execuo de consulta. O script a seguir cria um procedimento armazenado originalmente compilado que executa a consulta de exemplo (na seo Consulta de exemplo).
Transact-SQL
CREATE PROCEDURE usp_SampleJoin
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER
AS BEGIN ATOMIC WITH
( TRANSACTION ISOLATION LEVEL = SNAPSHOT,
LANGUAGE = 'english')
SELECT o.OrderID, c.CustomerID, c.ContactName
FROM dbo.[Order] o INNER JOIN dbo.[Customer] c
ON c.CustomerID = o.CustomerID
END

Os procedimentos armazenados compilados nativamente so compilados no momento da criao, enquanto os procedimentos armazenados interpretados so compilados no
momento da primeira execuo. (Uma parte da compilao, particularmente de anlise e algebrizao, ocorre na criao. No entanto, para procedimentos armazenados interpretados, a
otimizao dos planos de consulta ocorre na primeira execuo.) A lgica de recompilao semelhante. Os procedimentos armazenados compilados nativamente so recompilados na
primeira execuo do procedimento se o servidor for reiniciado. Os procedimentos armazenados interpretados sero recompilados se o plano no estiver mais no cache do plano. A
tabela a seguir resume os casos de compilao e recompilao para procedimentos armazenados interpretados e compilados nativamente:

Compilao inicial

Originalmente compilado

Interpretado

No momento da criao.

Na primeira execuo.

25/05/2015 20:49

Um guia para processamento de consulta de tabelas com otimizao de...

4 de 6

https://msdn.microsoft.com/pt-br/library/dn205319.aspx

Recompilao
automtica

Na primeira execuo do procedimento

aps o reincio do banco de dados ou do
servidor.

Na reinicializao do servidor. Ou, remoo do cache do plano, geralmente com base nas alteraes de
estatsticas ou esquema, ou demanda de memria.

Recompilao
manual

Sem suporte. A soluo alternativa

descartar e recriar o procedimento
armazenado.

Use o sp_recompile. Voc pode remover manualmente o plano do cache, por exemplo, usando DBCC
FREEPROCCACHE. Voc tambm pode criar o procedimento armazenado WITH RECOMPILE e o procedimento
armazenado ser recompilado em cada execuo.

Processamento de compilao e consulta

O diagrama a seguir ilustra o processo de compilao para procedimentos armazenados compilados nativamente:
Compilao nativa de procedimentos armazenados.

O processo descrito como:

1. O usurio emite uma instruo CREATE PROCEDURE no SQL Server.
2. O analisador e o algebrista criam o fluxo de processamento para o procedimento, bem como as rvores de consulta para as consultas Transact-SQL no procedimento
armazenado.
3. O otimizador cria planos otimizados de execuo de consulta para todas as consultas no procedimento armazenado.
4. O compilador OLTP na memria usa o fluxo de processamento com os planos de consulta otimizados inseridos e gera uma DLL que contm o cdigo de mquina para execuo
do procedimento armazenado.
5. A DLL gerado carregada na memria.
A invocao de um procedimento armazenado originalmente compilado convertida para chamar uma funo na DLL.
Execuo de procedimentos armazenados compilados nativamente.

A invocao de um procedimento armazenado originalmente compilado descrita a seguir:

1. O usurio emite uma instruo EXECusp_myproc.
2. O analisador extrai os parmetros de nome e procedimento armazenado.
Se a instruo tiver sido preparada, por exemplo, usando sp_prep_exec, o analisador no precisar extrair os parmetros e o nome do procedimento no momento da execuo.
3. O tempo de execuo do OLTP na memria localiza o ponto de entrada da DLL do procedimento armazenado.
4. O cdigo de mquina no DLL executado e os resultados so retornados para o cliente.
Deteco de parmetro
Os procedimentos armazenados Transact-SQL interpretado so compilados na primeira execuo, em oposio aos procedimentos armazenados compilados nativamente, que so
compilados no momento da criao. Quando os procedimentos armazenados interpretados so compilados na invocao, os valores dos parmetros fornecidos para essa invocao
so usados pelo otimizador durante a gerao do plano de execuo. Esse uso de parmetros durante a compilao chamado de deteco de parmetro.
A deteco de parmetro no usada para compilar os procedimentos armazenados compilados nativamente. Todos os parmetros para o procedimento armazenado so
considerados como tendo valores UNKNOWN. Como so procedimentos armazenados interpretados, os procedimentos armazenados compilados nativos tambm do suporte dica
de OPTIMIZE FOR. Para obter mais informaes, consulte dicas de consulta (Transact-SQL).

Recuperando um plano de execuo de consulta para procedimentos armazenados compilados de forma nativa
O plano de execuo de consulta para um procedimento armazenado compilado nativamente pode ser recuperado usando o Plano de Execuo Estimado no Management Studio,
ou usando a opo SHOWPLAN_XML no Transact-SQL. Por exemplo:
Transact-SQL
SET SHOWPLAN_XML ON
GO
EXEC dbo.usp_myproc
GO
SET SHOWPLAN_XML OFF
GO

O plano de execuo gerado pelo otimizador de consulta consiste em uma rvore com operadores de consulta nos ns e nas folhas da rvore. A estrutura da rvore determina a
interao (o fluxo de linhas de um operador para outro) entre os operadores. Na exibio grfica do SQL Server Management Studio, o fluxo da direita para a esquerda. Por exemplo,
o plano de consulta na figura 1 contm dois operadores de verificao de ndice, que fornece linhas a um operador de juno de mesclagem. O operador de juno de mesclagem
fornece linhas a um operador de seleo. O operador de seleo, por fim, retorna as linhas ao cliente.

Operadores de consulta nos procedimentos armazenados compilados nativamente

A tabela a seguir resume os operadores de consulta com suporte em procedimentos armazenados compilados nativamente:

25/05/2015 20:49

Um guia para processamento de consulta de tabelas com otimizao de...

5 de 6

operador

Consulta de exemplo

https://msdn.microsoft.com/pt-br/library/dn205319.aspx

Observaes

select
SELECT OrderID FROM dbo.[Order]

INSERT
INSERT dbo.Customer VALUES ('abc', 'def')

UPDATE
UPDATE dbo.Customer SET ContactName='ghi' WHERE CustomerID='abc'

DELETE
DELETE dbo.Customer WHERE CustomerID='abc'

Compute
Scalar
SELECT OrderID+1 FROM dbo.[Order]

Nested
Loops Join
SELECT o.OrderID, c.CustomerID
FROM dbo.[Order] o INNER JOIN dbo.[Customer] c

Esse operador usado para funes intrnsecas e converses de tipo.

Nem todas as funes e converses de tipos tm suporte em
procedimentos armazenados compilados nativamente.

Nested Loops o nico operador de juno com suporte em

procedimentos armazenados compilados nativamente. Todos os planos
que contm junes usaro o operador Nested loops, mesmo se o
plano para a mesma consulta executada como Transact-SQL
interpretado contiver uma juno de mesclagem ou hash.

Classificao
SELECT ContactName FROM dbo.Customer
ORDER BY ContactName

Incio
SELECT TOP 10 ContactName FROM dbo.Customer

Top-sort
SELECT TOP 10 ContactName FROM dbo.Customer
ORDER BY ContactName

Stream
Aggregate
SELECT count(CustomerID) FROM dbo.Customer

A expresso TOP (o nmero de linhas a serem retornadas) no pode

exceder 8.000 linhas. Menos se tambm houver operadores de juno e
agregao na consulta. As junes e a agregao normalmente
reduzem o nmero de linhas a serem classificadas, em comparao com
a contagem de linhas das tabelas base.

Observe que o operador Hash Match no tem suporte para agregao.

Desse modo, todas as agregaes em procedimentos armazenados
compilados nativamente usam o operador Stream Aggregate, mesmo
se o plano para a mesma consulta no Transact-SQL interpretado usar o
operador Hash Match.

Junes e estatsticas de coluna

O SQL Server mantm estatsticas sobre valores nas colunas de chave do ndice para ajudar a fazer uma estimativa do custo de determinadas operaes, como buscas de ndice e
verificao de ndice. (O SQL Server tambm cria estatsticas em colunas de chave no indexadas se voc cri-las explicitamente ou se o otimizador de consulta cri-los em resposta a
uma consulta com um predicado.) A principal mtrica na estimativa de custo o nmero de linhas processadas por um nico operador. Observe que para tabelas baseadas em disco, o
nmero de pginas acessadas por um operador especfico significativo na estimativa de custo. No entanto, como a contagem de pginas no importante para tabelas com
otimizao de memria (sempre ser zero), este documento se concentra na contagem de linhas. A estimativa iniciada com os operadores de verificao e busca de ndice no plano e
depois estendida para incluir os outros operadores, como o de juno. O nmero estimado de linhas a serem processadas por um operador de juno baseado na estimativa dos
operadores subjacentes de ndice, busca e verificao. Para obter acesso do Transact-SQL interpretado a tabelas com otimizao de memria, voc pode observar o plano de execuo
real ver a diferena entre as contagens de linhas estimadas e reais dos operadores no plano.
Para o exemplo na figura 1:
A verificao de ndice clusterizado em Customer estimou 91; real 91.
A verificao de ndice no clusterizado em CustomerID estimou 830; real 830.
O operador Merge Join estimou 815; real 830.
As estimativas para as verificaes de ndice so precisas. O SQL Server mantm a contagem de linhas para tabelas baseadas em disco. As estimativas para verificao de ndice e tabela
inteira sempre so precisas. A avaliao para a juno bastante precisa tambm.
Se essas estimativas forem alteradas, as consideraes de custo para diferentes alternativas de plano tambm sero alteradas. Por exemplo, se um dos lados da juno tiver uma

25/05/2015 20:49

Um guia para processamento de consulta de tabelas com otimizao de...

6 de 6

https://msdn.microsoft.com/pt-br/library/dn205319.aspx

contagem de linhas estimada de 1 ou apenas algumas linhas, usar as junes de loops aninhados menos dispendioso.
Veja a seguir o plano para a consulta;

SELECT o.OrderID, c.* FROM dbo.[Customer] c INNER JOIN dbo.[Order] o ON c.CustomerID = o.CustomerID

Depois de excluir todas as linhas, menos uma na tabela Customer:

Em relao a esse plano de consulta:

O Hash Match foi substitudo por um operador de juno fsico Nested Loops.
A verificao de ndice completo em IX_CustomerID foi substituda por uma busca de ndice. Isso resultou na verificao de 5 linhas, em vez das 830 linhas exigidas para a
verificao de ndice completo.

Estatsticas e cardinalidade para tabelas com otimizao de memria

O SQL Server mantm as estatsticas no nvel de coluna para tabelas com otimizao de memria. Alm disso, ele mantm a contagem real de linhas da tabela. No entanto, em
contraposio s tabelas baseadas em disco, as estatsticas de tabelas com otimizao de memria no so atualizadas automaticamente. Portanto, as estatsticas precisam ser
atualizadas manualmente depois que alteraes significativas so feitas nas tabelas. Para obter mais informaes, consulte Estatsticas para tabelas com otimizao de memria.

Consulte tambm
Conceitos
Introduo s tabelas com otimizao de memria

Contribuies da comunidade
2015 Microsoft

25/05/2015 20:49