um guia para processamento de consulta de tabelas com otimização de memória

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

Um guia para processamento de consulta de tabelas comotimizao de memria

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):

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:

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.

SQL Server 2014

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

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

Transact-SQL

Transact-SQL

Um guia para processamento de consulta de tabelas com otimizao de... https://msdn.microsoft.com/pt-br/library/dn205319.aspx

1 de 6 25/05/2015 20:49

Considere uma ligeira variao nessa consulta, que retorna todas as linhas da tabela Order, no apenas OrderID:

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:

O usurio emite uma consulta.1.

O analisador e o algebrista constroem uma rvore de consulta com operadores lgicos de acordo com o texto Transact-SQL enviado pelo usurio.2.

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.

3.

O mecanismo de execuo de consulta processa uma interpretao do plano de consulta.4.

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.

5.

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.6.

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.

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

Transact-SQL


2 de 6 25/05/2015 20:49

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:

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

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).

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:

Originalmente compilado Interpretado

Compilao inicial No momento da criao. Na primeira execuo.

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


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

Transact-SQL

Transact-SQL

Transact-SQL


3 de 6 25/05/2015 20:49

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:

O usurio emite uma instruo CREATE PROCEDURE no SQL Server.1.

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.

2.

O otimizador cria planos otimizados de execuo de consulta para todas as consultas no procedimento armazenado.3.

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.

4.

A DLL gerado carregada na memria.5.

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:

O usurio emite uma instruo EXECusp_myproc.1.

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.

2.

O tempo de execuo do OLTP na memria localiza o ponto de entrada da DLL do procedimento armazenado.3.

O cdigo de mquina no DLL executado e os resultados so retornados para o cliente.4.

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:

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:

SET SHOWPLAN_XML ON

GO

EXEC dbo.usp_myproc

GO

SET SHOWPLAN_XML OFF

GO

Transact-SQL


4 de 6 25/05/2015 20:49

operador Consulta de exemplo Observaes

select

INSERT

UPDATE

DELETE

Compute

Scalar

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 Join

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

Incio

Top-sort 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.

Stream

Aggregate

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

SELECT OrderID FROM dbo.[Order]

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

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

DELETE dbo.Customer WHERE CustomerID='abc'

SELECT OrderID+1 FROM dbo.[Order]

SELECT o.OrderID, c.CustomerID

FROM dbo.[Order] o INNER JOIN dbo.[Customer] c

SELECT ContactName FROM dbo.Customer

ORDER BY ContactName

SELECT TOP 10 ContactName FROM dbo.Customer

SELECT TOP 10 ContactName FROM dbo.Customer

ORDER BY ContactName

SELECT count(CustomerID) FROM dbo.Customer


5 de 6 25/05/2015 20:49

Contribuies da comunidade

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;

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

2015 Microsoft



6 de 6 25/05/2015 20:49

um guia para processamento de consulta de tabelas com otimização de memória

Documents