SQL Server Query Análise de plano de execução

Uma query no SQL Server

Este artigo descreve o que acontece quando uma query � submetida dentro do SQL Server, criando uma base conceitual a respeito do funcionamento do plano de execu��o e dos fatores que o influenciam.

A aplica��o dos conceitos e o entendimento do plano de execu��o s�o recomendados para profissionais em empresas de todos os segmentos. A constru��o de queries visando performance e tendo a compreens�o da melhor maneira de constru�-las influencia na qualidade de qualquer projeto que envolva extra��o de informa��o do SQL Server.

Hoje, com a grande necessidade de extrair informa��es do banco de dados, podendo ser tanto para carga e manipula��o desses dados como para disponibiliza��o de informa��es anal�ticas, entre outras finalidades, surgem alguns problemas para disponibilizar os dados com rapidez a qual n�o foi prevista durante a constru��o da query.

Ent�o surge a quest�o, se os dados n�o est�o sendo recuperados com a velocidade desejada, o plano de execu��o da query foi analisado? Uma vez que este plano foi ao menos gerado, s�o compreens�veis quais foram os fatores de influ�ncia dentro da constru��o da query para o resultado gerado pelo plano de execu��o no SQL? O que acontece dentro do SQL quando uma query � submetida?

No desenvolvimento de um projeto de banco de dados, as informa��es precisam ser disponibilizadas de forma eficiente e eficaz, ou seja, com rapidez e qualidade. No entanto, nem sempre � poss�vel alcan�ar isso.

Em um mundo em que os projetos s�o sempre para ontem, as necessidades est�o cada vez mais urgentes e muitas vezes o pre�o de um processo dentro do banco de dados mais lento do que o suport�vel � o pre�o a ser pago.

Mas o tempo escasso e a urg�ncia n�o s�o os �nicos inimigos a serem vencidos, ou administrados. A falta de conhecimento a respeito de como � gerado o plano de execu��o de um comando T-SQL e quais fatores influenciam na constru��o de queries coerentes para obter performance s�o itens a serem considerados.

Na maioria das vezes, as queries s�o constru�das no processo de tentativa e erro e a sorte passa a ser um fator dominante, ao inv�s do conhecimento.

Alcan�ar performance na constru��o de queries no SQL est� al�m de entender os operadores envolvidos em um plano de execu��o. Tamb�m envolve compreender o porqu� esses operadores foram gerados, como foram gerados e quais foram os fatores que influenciaram o SQL a tomar as decis�es que tomou para gerar o plano.

Por exemplo, quais as informa��es que foram levadas em considera��o para que o �ndice criado n�o fosse usado, ou por que uma determinada query est� levando mais tempo que o esperado para recuperar as informa��es, ou ainda por que determinado processo de carga de dados est� levando mais tempo que a janela disponibilizada, entre outros problemas.

Considerando isso, o objetivo deste artigo � compreender o funcionamento do processamento de uma query dentro do SQL, e baseado nisso, ajustar o comando T-SQL para que alcance as necessidades do processo o qual faz parte. Afinal, como obter o melhor de algo que n�o se entende como funciona?

Logo, � preciso no come�o cavar um pouco mais fundo para que o alicerce do conhecimento esteja bem fundamentado.

O que � um plano de execu��o?

Segundo a o livro The Art of High Performance SQL Code: SQL Server Execution Plans, plano de execu��o � definido como uma maneira simples do query optimizer calcular o caminho mais eficiente para implementar uma requisi��o representada pelo T-SQL, quando esta for submetida dentro SQL Server.

Portanto, uma vez que a query for submetida, o SQL vai calcular v�rios caminhos e escolher uma op��o dentre esses.

Plano de Execu��o � Modo gr�fico

Para entender visualmente a ideia do que � um plano de execu��o o primeiro exemplo a ser apresentado ser� no modo gr�fico. O script disponibilizado na Listagem 1 � um passo a passo que ser� utilizado neste artigo para o estudo de como funciona o plano de execu��o. Atrav�s do SQL Management Query Editor, considerando que o SQL Server j� esteja instalado, este acess�vel pelo SQL Management Studio, conecte no servidor a ser usado para este estudo, clique em New Query e execute o script abaixo atrav�s da tecla F5.

Listagem 1. Script para constru��o da tabela LOG_EXECUCAO.


  --Cria��o da tabela
  CREATE TABLE [dbo].[LOG_EXECUCAO](
        [ID]                    [int] IDENTITY(1,1) NOT NULL,
        [DATA_ATUALIZACAO]      [DATETIME]          NOT NULL,
        [ID_PROCESSO]           [INT]               NOT NULL,
        [NOME_SISTEMA]          [VARCHAR](100)      NOT NULL
   CONSTRAINT [PK_LOG_EXECUCAO_ID] PRIMARY KEY NONCLUSTERED 
  (
        [ID] ASC
  )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, 
ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
  ) ON [PRIMARY]
   
  GO
   
  --Inser��o de dados
  INSERT INTO dbo.LOG_EXECUCAO
              (DATA_ATUALIZACAO
              ,ID_PROCESSO
              ,NOME_SISTEMA)
  VALUES  (GETDATE()
              ,1
              ,'SISTEMA DE VENDAS')
              
  GO
   
  INSERT INTO dbo.LOG_EXECUCAO
              (DATA_ATUALIZACAO
              ,ID_PROCESSO
              ,NOME_SISTEMA)
  VALUES  (GETDATE()
              ,2
              ,'SISTEMA DE CONTROLE')
              
  GO
  INSERT INTO dbo.LOG_EXECUCAO
              (DATA_ATUALIZACAO
              ,ID_PROCESSO
              ,NOME_SISTEMA)
  VALUES  (GETDATE()
              ,3
              ,'SISTEMA DE ESTOQUE')
  GO    
  INSERT INTO dbo.LOG_EXECUCAO
              (DATA_ATUALIZACAO
              ,ID_PROCESSO
              ,NOME_SISTEMA)
  VALUES  (GETDATE()
              ,4
              ,'SISTEMA DE MONITORA��O')
  GO
  INSERT INTO dbo.LOG_EXECUCAO
              (DATA_ATUALIZACAO
              ,ID_PROCESSO
              ,NOME_SISTEMA)
  VALUES  (GETDATE()
              ,5
              ,'SISTEMA DE LOG�STICA')
   
  --Select dos dados
  SELECT * FROM DBO.LOG_EXECUCAO

Uma vez que a query que ser� analisada esteja montada, ou seja, como mostrado na Listagem 1, a query a ser analisada � o select da tabela LOG_EXECUCAO. � poss�vel obter o plano de execu��o de diversas maneiras, entre elas o modo gr�fico.

Neste caso para gerar o plano no modo gr�fico, clique na barra de ferramentas do Management Studio Query Editor, pode-se escolher entre duas op��es Display estimated execution plan e Include actual execution plan. Se a op��o escolhida for Include Actual Execution Plan, � preciso executar o script antes que o plano de execu��o seja gerado, pois dessa forma o plano trar� tamb�m o resultado atual al�m da estimativa, esta op��o pode ser identificada na Figura 1, circulada em vermelho.

Se a op��o desejada for Display Estimated Execution o script primeiro passa pelo processo de "parse", e depois a estimativa do plano de execu��o � gerada. A op��o Display Estimated Execution pode ser identificada circulada em preto na Figura 1.

Ap�s a sele��o de uma dessas op��es (Display Estimated Execution ou Include Actual Execution Plan) o plano gerado ser� simular ao mostrado na Figura 2. Esta � a visualiza��o do plano no modo gr�fico.

Para entender o caminho que foi percorrido na engine do SQL Server para gerar o plano de execu��o, usando como, por exemplo, na Figura 2 o operador Table Scan e ainda o que � um Table Scan, � preciso entender o que ocorre dentro do banco de dados quando a execu��o de uma query � submetida no SQL Server.

Processos do plano de execu��o

Quando uma determinada query � executada dentro SQL Server como, por exemplo, um select em uma tabela para obter o retorno de um conjunto de dados, ocorrem v�rios processos no servidor. O prop�sito deles � administrar a maneira como os dados ser�o retornados. Embora existam v�rios processos diferentes ocorrendo ao mesmo tempo, a query submetida vai passar basicamente por dois est�gios:

1. Processos que ocorrem na Relational Engine;

2. Processos que ocorrem na Storage Engine.

De forma resumida na Relational Engine � onde a query passa pelo processo de "parse" e � processada pelo query optimizer, o que ir� gerar o plano de execu��o. O plano � mandado (em formato bin�rio) para a Storage Engine para execu��o da query e retorno dos dados solicitados.

Query Parsing

O �parse� da query ocorre, como informado anteriormente, no Relational Engine. Isso significa que quando a query chega, esta dever� passar pelo processo de an�lise da escrita do T-SQL para que seja verificado se est� correta.

A query tamb�m ser� submetida ao algebrizer, o qual vai identificar entre as colunas todos os tipos de dados (varchar, char, nvarchar, etc.) de todos os objetos que est�o sendo acessados.Se existirem agrega��es ser�o localizadas (como group by) em um processo chamado de aggregation binding. A sa�da deste processo � a query gerada em forma de �rvore no qual s�o identificados os passos l�gicos para a execu��o da mesma (isso se o plano da query n�o existir em cache).

Depois disso a query passa ao Query Optimizer, aonde vai ser modelada, usando o resultado do query parsing e as estat�sticas dos dados.

Query Optimizer

O query optimizer � aonde os planos baseado em custo s�o gerados, o que significa que entre v�rias possibilidades uma � escolhida baseada no menor custo. Os c�lculos v�o levar em considera��o algumas informa��es como, por exemplo, recursos de CPU, I\O e estat�stica. As estat�sticas por default s�o coletadas automaticamente, baseadas nas colunas dos �ndices dentro do banco de dados elas descrevem a distribui��o dos dados, a unicidade, ou seletividade destes.

O caminho �timo para execu��o da query ser� definido pelo optimizer tendo como resultado o plano de execu��o. Neste processo ser�o definidos quais os tipos de joins ser�o usados, quais �ndices ser�o acessados e ainda outras informa��es que s�o baseadas em custo.

Se o plano n�o existir em cache v�rios planos ser�o gerados, o plano com o menor custo que leve menos tempo para ser gerado ser� escolhido (veja BOX 1), no entanto algumas vezes o plano menos eficiente vai ser escolhido.

Isso se o optimizer achar que vai ser mais r�pido escolher o plano menos eficiente, do que gerar mais planos. Por exemplo, no caso de uma query que fa�a uma consulta no SQL e n�o faz o uso de �ndices, c�lculos ou agrega��es. Ao inv�s de tentar o plano de execu��o �timo, o optimizer escolhe o plano de execu��o trivial.

BOX 1. Custo

O custo da query n�o � traduzido em segundos, � um n�mero utilizado para representar o valor de custo para cada recurso no plano. Para obter o custo dos operadores multiplica-se o valor base do operador pelo tamanho da linha e a estimativa de n�mero de linhas. A soma disso � o total de custo dos operadores.

Uma vez que o plano de execu��o foi gerado, tamb�m chamado de plano atual pelo optimizer, ele � e armazenado numa �rea da mem�ria chamada "plan cache", se um plano id�ntico j� existir no cache o plano vai ser reutilizado.

Plan Cache

Gerar os planos de execu��o no SQL pode consumir tempo e recurso intensivamente do banco de dados, logo faz sentido reusar um plano de execu��o sempre que � poss�vel. Ao reutilizar o plano de execu��o que foi gerado, por exemplo, torna-se desnecess�rio gerar um plano de execu��o para uma query muito complexa que j� tem seu plano armazenado em cache ou ainda uma query pequena que � chamada muitas vezes. Os planos de execu��o s�o armazenados numa �rea da mem�ria chamada plan cache.

Os planos de execu��o armazenados em cache s�o acess�veis atrav�s da DMV sys.dm_exec_cached_plans. Pode-se saber, por exemplo, quantas vezes o plano foi reutilizado. Na Listagem 2, o filtro para planos que foram reutilizados mais de uma vez foi aplicado atrav�s da coluna �usecounts > 1�:

Listagem 2. Planos reutilizados.


  SELECT usecounts, cacheobjtype, objtype, text 
  FROM sys.dm_exec_cached_plans 
  CROSS APPLY sys.dm_exec_sql_text(plan_handle) 
  WHERE usecounts > 1 
  ORDER BY usecounts DESC;

Algumas informa��es interessantes podem ser obtidas com uso das DMVS que o SQL disponibiliza. DMVs s�o Dynamic Management Views, ou seja, views de sistema que podem ser utilizadas para v�rias finalidades como an�lise de performance. Considerando os planos armazenados em cache obtidos atrav�s da DMV sys.dm_exec_cached_plans e a DMV sys.dm_exec_query_plan, a qual retorna os planos de execu��o em formato XML, � poss�vel gerar o plano de execu��o das queries que est�o em cache, como mostrados na Listagem 3.

Listagem 3. Planos de execu��o em cache.


  SELECT *
  FROM sys.dm_exec_cached_plans c
  CROSS APPLY sys.dm_exec_query_plan(c.plan_handle) p

Entre as informa��es que s�o resultadas da execu��o da Listagem 3 visualizadas na Figura 3, observa-se o retorno da coluna query_plan. Nela existe um link XML que acessa as informa��es gr�ficas do plano de execu��o armazenado no cache. Na maioria das vezes existir� no cache um plano armazenado por query, a n�o ser que o SQL descubra que uma execu��o paralela pode resultar numa performance melhor. Neste caso, o paralelismo passa a ser uma op��o, e um segundo plano � criado para aquela query.

**Figura 3.** Plano de execu��o e plan cache.

Os planos de execu��o n�o s�o mantidos na mem�ria para sempre. Eles envelhecem tamb�m, e a f�rmula que o SQL utiliza para determinar a idade de um plano de execu��o, consiste em multiplicar o custo do plano pela quantidade de vezes que ele foi executado. Este valor ser� decrescido pelo lazy writer (veja BOX 2).

BOX 2. Lazy writer

Lazy writer � o processo respons�vel por limpar o cache, inclusive a �rea chamada de plan cache. Periodicamente ele verifica os objetos que est�o no cache e diminui o valor que foi calculado para eles.

Portanto, quando a idade do plano chegar a zero ele vai deixar de constar no cache. Existem outras situa��es em que isso pode ocorrer como, por exemplo, quando mais mem�ria for requerida pelo sistema e toda mem�ria corrente estiver em uso.

Existem alguns casos em que o plano de execu��o ser� recompilado, esta opera��o pode ser bem cara para o SQL. Suponha que um plano de uma query esteja compilado e armazenado no plan cache, quando esta query for executada e o plano reutilizado, a validade e a otimiza��o deste plano ser�o validados. Se por alguma raz�o esta opera��o de valida��o do SQL no plano falhar, ele ser� compilado novamente e um novo plano ser� gerado. Seguem alguns exemplos que podem levar a recompila��o do plano de execu��o:

A estrutura da schema da tabela referenciada pela query foi modificado;
Mudar o �ndice usado pela query;
Dropar o �ndice usado pela query;
Atualizar as estat�sticas usadas pela query;
Utilizar a procedure sp_recompile.

Talvez em algum momento de an�lise de performance da query possa ser interessante for�ar a sa�da do armazenamento desta query no cache. O cache do SQL pode ser limpo completamente ou individualmente.

Para limp�-lo individualmente, por exemplo, pode ser feito atrav�s do plan_handle com o uso da DBCC FreeProcCache, a Listagem 4 mostra como obter o plan_handle, em seguida limpar individualmente o plano do cache.

Listagem 4. Planos de handle.


  SELECT plan_handle, st.text
  FROM sys.dm_exec_cached_plans 
  CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st
  WHERE text LIKE N'SELECT * FROM dbo.LOG_EXECUCAO%';
  GO
   
  DBCC FREEPROCCACHE (0x0600060022DC2D1E40818F85000000000000000000000000);

Como informado anteriormente, � poss�vel limpar todos os planos armazenados em cache, neste caso n�o � preciso passar o plan handle. A Listagem 5 mostra como realizar isso atrav�s do uso do comando DBCC FreeProcCache.

Listagem 5. Limpar todos os planos do cache.


  DBCC FREEPROCCACHE WITH NO_INFOMSGS;

Query Execution

A pr�xima fase pela qual a query que foi submetida ir� passar � o query execution, como nome j� diz � o momento em que ocorre a execu��o da query.

Depois que o plano � gerado na Storage Engine a query vai ser executada de acordo com o plano e os dados requeridos ser�o acessados. As p�ginas com os dados requeridos ou s�o obtidas por existirem no cache ou s�o acessadas no disco e depois disso colocadas no cache de dados.

O tempo que se leva para ler os dados do disco e coloc�-los na mem�ria � o tempo representado pelo waittype PageIOLatch.

Algumas vezes podem ocorrer diferen�as entre as estat�sticas coletadas e os dados que existem nas tabelas. Isso geralmente ocorre quando:

Os dados s�o inseridos e deletados;
A chave que define o �ndice sofre mudan�as;
A distribui��o da informa��o muda.

Isso gera um plano de execu��o menos eficiente e m� performance na execu��o da query.

Modos de se obter o plano de execu��o

O plano de execu��o no SQL pode ser obtido de v�rias maneiras e em v�rios formatos diferentes. A forma que ir� ser escolhida para an�lise vai variar de pessoa para a pessoa.

Tende-se a preferir o modo gr�fico, pois este � mais f�cil de compreender. O modo texto � uma feature deprecated, ou seja, em algum momento a Microsoft vai desabilitar este modo de visualiza��o.

O modo XML � o que dever� substituir o modo de visualiza��o texto e � mais f�cil de compreender.

Planos no modo texto

Uma vez que a gera��o de plano no modo texto � uma feature deprecated. Qual o sentido de saber como gerar o plano neste modo? A resposta � simples, nem sempre ao se desenvolver um projeto em SQL, os servidores est�o na �ltima vers�o do produto.

Em alguns casos, nem mesmo est�o usando o SQL 2005, neste caso por uma quest�o de compatibilidade � importante saber gerar plano de execu��o em diferentes vers�es e situa��es. A seguir est�o descritas as op��es que permitem gerar o plano de execu��o no modo texto:

SHOWPLAN_ALL: Esta op��o retorna a estimativa do plano de execu��o sem executar a query. Uma vez que esta op��o esteja habilitada todos os T-SQLs que forem executados retornar�o as estimativas do plano de execu��o at� que esta op��o seja desabilitada. Prov� uma quantidade razo�vel de dados para a an�lise;
SHOWPLAN_TEXT (Deprecated, ser� desabilitado em futuras vers�es): Tamb�m retorna a estimativa do plano de execu��o sem executar a query. Uma vez que esta op��o esteja habilitada todos os T-SQLs que forem executados retornar�o as estimativas do plano de execu��o at� que esta op��o seja desabilitada. Prov� uma quantidade limitada de dados, recomendado em ferramentas como osql.exe;
STATISTICS PROFILE: Similar ao SHOWPLAN_ALL exceto que representa os dados do plano de execu��o atual. Logo a query � executada, trazendo al�m do resultado da query o resultado do plano de execu��o.

Planos no modo XML

Os planos de execu��o no formato XML passaram a existir a partir do SQL 2005, dever�o substituir os planos de execu��o no modo texto. Eles podem ser visualizados em formato gr�fico ou formato XML e trazem at� mais informa��es que no modo gr�fico.

SHOWPLAN_XML: Esta op��o retorna a estimativa do plano de execu��o sem executar a query. Uma vez que esta op��o esteja habilitada todos os T-SQLs que forem executados retornar�o as estimativas do plano de execu��o at� que esta op��o seja desabilitada. O retorno de dados desta op��o � o mais completo;
STATISTICS XML - Similar ao SHOWPLAN_XML exceto que representa os dados do plano de execu��o atual. Logo a query � executada, trazendo al�m do resultado da query o resultado do plano de execu��o.

Plano de execu��o no Modo Gr�fico

Para gerar o plano de execu��o em qualquer modo, seja XML, texto ou gr�fico � necess�rio ter permiss�o no banco de dados para isso. Se a pessoa que for gerar o plano de execu��o n�o for sysadmin, dbcreator ou dbowner, a permiss�o a necess�ria � de SHOWPLAN:

GRANT SHOWPLAN TO [USER]

Com as devidas permiss�es dadas, o pr�ximo passo � obter o plano de execu��o. Continuando pelo modo gr�fico, escolha Display Estimated Execution Plan. Al�m do caminho apresentado no t�pico �Exemplificando: Plano de Execu��o - Modo gr�fico� no in�cio deste artigo, tamb�m existem outros caminhos poss�veis para obter este modo de visualiza��o do plano de execu��o, sendo eles:

Clique com bot�o direito pr�ximo ou no local no qual a query foi digitada e selecione a op��o do menu, conforme mostra a Figura 4;
Selecione a op��o do menu query;
Digite CTRL+L.

Display Estimated Execution Plan com
o bot�o direito do mouse. — **Figura 4.** Display Estimated Execution Plan com o bot�o direito do mouse.

Uma vez que � gerado o plano apresentado, este pode ser visualizado na aba execution plan (ver Figura 5).

Display estimated execution, ao lado
de messages. — **Figura 5.** Display estimated execution, ao lado de messages.

Com o uso dos mesmos meios demonstrados j� descritos, o plano de execu��o com as informa��es atuais, pode ser obtido selecionando-se Include Actual Execution Plan. No entanto a tecla de atalho para acess�-lo � CTRL+M. Lembrando que o plano ser� gerado com a execu��o da query, por isso ele inclui as informa��es atuais al�m das estimativas, diferente do Display estimated execution plan.

Importante lembrar que no caso de se tentar ler o plano de execu��o de uma procedure que esteja encriptada, esta por uma quest�o de seguran�a n�o mostra o plano de execu��o.

Como ler o plano gerado no modo gr�fico

No modo gr�fico, a leitura do plano deve ser feita da direita para a esquerda de cima para baixo. S�o aproximadamente 78 opera��es que representam v�rias a��es e decis�es que podem ser tomadas pelo plano de execu��o, a opera��o mostrada na Figura 6, � uma das poss�veis.

Plano de execu��o e interpreta��o,
modo gr�fico. — **Figura 6.** Plano de execu��o e interpreta��o, modo gr�fico.

A seta que liga os �cones representa os dados que est�o sendo passados entre eles. Quanto mais grossa a seta, maior o n�mero de informa��es que est� sendo passada. Esta inclusive � uma pista que pode ser analisada em caso de problemas de performance.

Abaixo de cada item tem uma porcentagem que representa o custo relativo da query, para cada operador representado pelos �cones. Este custo vai de 0% at� 100%, uma query pode ter m�ltiplos passos, cada passo vai ter um valor de custo relativo dentro do contexto da query.

Ao passar com o mouse pelos �cones percebe-se uma janela aparecer como pode ser visualizada na Figura 7, esta janela � a �tooltip�. Cada operador tem uma �tooltip� associada a ele, com detalhes referente � execu��o da package. A natureza de execu��o de cada operador define um grupo de dados que estar� dispon�vel nesta �tooltip�.

**Figura 7.** Plano de execu��o e tooltip.

As seguintes informa��es podem aparecer nas tooltips:

Cached Plan Size (Operador Select): Tamanho do plano armazenado no Cache;
Logical Operation: Representa o resultado dos c�lculos do Optimizer para o que deve acontecer quando query executar;
Physical Operation: Representa o que realmente aconteceu quando a query foi executada. Geralmente Physical e Logical s�o iguais;
Actual Number Rows (dispon�vel se a op��o Include Actual Execution Plan for selecionada): N�mero atual das linhas retornadas baseada em quantas vezes a fun��o GetNext(), o qual retorna uma linha por dado, foi chamada;
Estimated I\O Cost: Baseado em c�lculos feitos pelo Optimizer, � apenas uma estimativa, mas pode ser um ponto de aten��o para queries com alto custo de I\O;
Estimated CPU Cost: Baseado em c�lculos feitos pelo Optimizer, � apenas uma estimativa, mas pode ser um ponto de aten��o para queries com alto custo de CPU;
Estimated Operator Cost: Estimativa de custo para a execu��o do operador. Ex: Estimativa de custo para um table Scan, ou seja, para a leitura de toda a tabela linha por linha sem uso de �ndice;
Estimated SubtreeCost: Custo acumulado da execu��o dos passos anteriores at� o passo atual (leitura deve ser feita da direita para a esquerda);
Estimated Number of Rows: C�lculo baseado na estat�stica dispon�vel para Optimizer produzindo a estimativa de n�mero de linhas. Esta varia de �cone a �cone os quais representam os operadores envolvidos no plano de execu��o. Cada operador esta lidando com um grupo e quantidade diferente de dados;
Estimated Row Size: Estimativa do tamanho da linha retornada, baseado em estat�stica;
Actual Rewbinds (dispon�vel se a op��o Include Actual Execution Plan for selecionada): Significa que um ou mais par�metros correlacionados ao join mudaram e o inner precisa ser reavaliado. Refere-se ao n�mero de vezes que o m�todo INIT() foi chamado;
Actual Rewinds (dispon�vel se a op��o Include Actual Execution Plan for selecionada): Significa que um ou mais par�metros correlacionados ao join mudaram antes do resultado do inner e este precisa ser usado novamente. Refere-se ao n�mero de vezes que o m�todo INIT() foi chamado;
Ordered: Valor do tipo boolean, o qual informa se os dados est�o ordenados ou n�o. Em alguns casos as informa��es retornadas por uma query v�o determinar que os dados ou um grupo deles estivessem organizados de maneira ordenada, isto pode gerar um processamento extra no plano;
Node ID: Simplesmente indica a ordem do n�, ou seja, a ordem dos operadores. Perceba que eles est�o ordenados da esquerda para a direita, embora a leitura do plano seja melhor da direita para a esquerda.

Ao clicar com o bot�o direito no plano de execu��o no modo gr�fico e selecionar propriedades, pode-se obter mais detalhes sobre as opera��es, conforme pode ser observado na Figura 8. A maioria do que est� dispon�vel nas propriedades j� � conhecido, exceto por algumas informa��es, como por exemplo:

Forced Index: Valor boolean, que vai ficar true se a query estiver usando algum hint para for�ar o uso de �ndice;
No Expand Hint: Mesmo conceito do Forced Index aplicado a indexed views;
Parallel: valor l�gico do tipo boolean, podendo assumir os valores 0 e 1. 0 indica que n�o est� rodando em paralelo, e 1 que est� rodando em paralelo.

**Figura 8.** Plano de execu��o e as propriedades.

Como gerar o plano no modo texto

O modo de visualiza��o de planos de execu��o no modo texto tem a vantagem de passar a informa��o de uma vez s�, sem a necessidade de utilizar recursos como tooltip ou as propriedades obtidas atrav�s do modo gr�fico.

Para ativar este modo de exibi��o, � preciso faz�-lo atrav�s de comando no SQL Server Management Studio, antes de executar a query, como por exemplo:

SET SHOWPLAN_ALL ON;

Logo, todos os comandos T-SQL que forem executados ap�s a ativa��o, como feita no exemplo acima, estar�o sujeitos � exibi��o do plano de execu��o. Lembrando que nos casos de SHOWPLAN_ALL, SHOWPLAN_TEXT, SHOWPLAN_XML, o plano de execu��o � estimado sem a execu��o da query. Para desabilitar esta op��o digite o comando:

SET SHOWPLAN_ALL OFF;

Considerando que este comando n�o executa a query, apenas gera o plano. Se a query estiver na depend�ncia da cria��o de uma tabela, e esta op��o for habilitada antes da cria��o da tabela, o comando ir� retornar erro. O comando n�o ir� executar a query, apenas estim�-la.

E uma vez que o comando n�o ir� executar a cria��o da tabela esta n�o vai existir para a gera��o do plano de execu��o. Esta situa��o pode ser observada na Figura 9.

**Figura 9.** Plano modo texto � Cria��o de tabela sem execu��o.

O modo de ativa��o do plano de execu��o no modo gr�fico � diferente da ativa��o no modo texto ou XML, neste caso utiliza-se a sintaxe: SET [modo do plano de execu��o] ON e para desativa��o SET [modo do plano de execu��o] OFF.

Seguem alguns exemplos na Listagem 6 de ativa��o e desativa��o do plano de execu��o.

Listagem 6. Ativa��o do plano de execu��o texto ou XML.


  SET SHOWPLAN_TEXT ON;
  SET SHOWPLAN_TEXT OFF;
   
  SET STATISTICS PROFILE ON; 
  SET STATISTICS PROFILE OFF;
   
  SET SHOWPLAN_XML ON; 
  SET SHOWPLAN_XML OFF; 
   
  SET STATISTICS XML ON;
  SET STATISTICS XML OFF;

Como ler o plano gerado no Modo Texto

O plano de execu��o no modo texto � mais complexo de ser lido do que no modo gr�fico, tanto que no geral o plano de execu��o no modo gr�fico � mais usado. Para tornar isso mais claro, segue na Figura 10 o mesmo plano de execu��o que foi gerado no modo gr�fico, exemplificado dessa vez no modo texto com uso do comando SHOWPLAN ALL.

No retorno obtido ao executar o comando SHOWPLAN_ALL, a primeira coluna � StmtText, e a primeira linha desta coluna � o SELECT que foi submetido ao plano de execu��o, as linhas ap�s isso s�o as opera��es. No modo gr�fico as opera��es eram mostradas atrav�s de �cones.

Quanto mais complexo o plano de execu��o, mais complexa � a leitura no modo textual. A leitura neste caso, n�o pode ser da direita para a esquerda como no modo gr�fico, no modo texto far� mais sentido ler a partir do meio e depois disso para fora seguindo o uso da endenta��o e do pipe (|).

As mesmas informa��es dispon�veis no modo gr�fico est�o dispon�veis no modo texto ou XML, e ainda um pouco mais de informa��o.

Lembrando que o modo mais recomendado para obter os planos de execu��o no modo texto s�o os planos gerados como XMLs.

Como gerar o plano no Modo XML

No modo XML, dispon�vel a partir do SQL 2005, � poss�vel visualizar mais informa��es que no modo gr�fico como, por exemplo, fra��es de mem�ria (como a mem�ria que foi disponibilizada � distribu�da entre os operadores no plano) e � notavelmente mais simples que o modo texto, no qual tem � se que se localizar atrav�s de endenta��es e pipes (|).

O plano de execu��o no modo XML traz os resultados do plano atrav�s de um link XML, conforme pode ser verificado na Figura 11, e pode ser visualizado tanto no modo gr�fico como em XML.

**Figura 11.** Plano de execu��o � ShowPlan_XML.

Ao clicar no link disponibilizado pelo plano de execu��o, percebe-se que um conjunto mais completo de informa��es, mesmo para uma query simples, � disponibilizado.

Algo interessante de se observar � o tipo de plano que foi gerado, esta informa��o � obtida atrav�s do valor em StatementOptmLevel = �TRIVIAL�. Logo, para a execu��o desta query foi escolhido um plano de execu��o trivial, ou seja, ao inv�s de escolher o plano de execu��o �timo, pela simplicidade da query foi escolhido o modo trivial.

Como ler o plano gerado no Modo XML

O modo XML prov� mais informa��o para an�lise e � melhor para ler que o modo texto, parte do plano pode ser observado pela Listagem 7 o qual o resultado foi gerado atrav�s do script da Listagem 8. A maioria das informa��es disponibilizadas j� s�o conhecidas como, por exemplo, EstimateRows ou EstimateIO e podem ser visualizadas tanto no modo XML , texto ou gr�fico.

Listagem 7. Parte do plano em XML.


  <ShowPlanXML xmlns="http://schemas.microsoft.com/sqlserver/2004/07/showplan" Version="1.1" Build="10.50.1600.1">
    <BatchSequence>
      <Batch>
        <Statements>
          <StmtSimple StatementText="SELECT * 
           FROM dbo.DatabaseLog
" StatementId="1"
           StatementCompId="1" StatementType="SELECT" 
           StatementSubTreeCost="0.576891" StatementEstRows="1597" 
           StatementOptmLevel="TRIVIAL" QueryHash="0xCEA1767217FB35FD" 
           QueryPlanHash="0x2959B5DE1A3E7C7D">
            <StatementSetOptions QUOTED_IDENTIFIER="true" 
              ARITHABORT="true" CONCAT_NULL_YIELDS_NULL="true" 
              ANSI_NULLS="true" ANSI_PADDING="true" 
              ANSI_WARNINGS="true" NUMERIC_ROUNDABORT="false" />
            <QueryPlan CachedPlanSize="16" CompileTime="121" 
              CompileCPU="109" CompileMemory="88">
              <RelOp NodeId="0" PhysicalOp="Table Scan" 
               LogicalOp="Table Scan" EstimateRows="1597" 
               EstimateIO="0.574977" EstimateCPU="0.0019137" 
               AvgRowSize="8593" EstimatedTotalSubtreeCost="0.576891" 
               TableCardinality="1597" Parallel="0" 
               EstimateRebinds="0" EstimateRewinds="0">
                <OutputList>
                  <ColumnReference Database="[AdventureWorks2008R2]" 
                     Schema="[dbo]" Table="[DatabaseLog]" 
                     Column="DatabaseLogID" />
                  <ColumnReference Database="[AdventureWorks2008R2]" 
                    Schema="[dbo]" Table="[DatabaseLog]" 
                    Column="PostTime" />
                  <ColumnReference Database="[AdventureWorks2008R2]" 
                   Schema="[dbo]" Table="[DatabaseLog]" 
                   Column="DatabaseUser" />
                  <ColumnReference Database="[AdventureWorks2008R2]" 
                    Schema="[dbo]" Table="[DatabaseLog]" 
                    Column="Event" />
                  <ColumnReference Database="[AdventureWorks2008R2]" 
                   Schema="[dbo]" Table="[DatabaseLog]" 
                   Column="Schema" />
                  <ColumnReference Database="[AdventureWorks2008R2]" 
                   Schema="[dbo]" Table="[DatabaseLog]" 
                    Column="Object" />
                  <ColumnReference Database="[AdventureWorks2008R2]" 
                    Schema="[dbo]" Table="[DatabaseLog]" 
                    Column="TSQL" />
                  <ColumnReference Database="[AdventureWorks2008R2]" 
                    Schema="[dbo]" Table="[DatabaseLog]" 
                    Column="XmlEvent" />
                </OutputList>
                <TableScan Ordered="0" ForcedIndex="0" NoExpandHint="0">

Listagem 8. Habilitando plano em XML.


  SET SHOWPLAN_XML ON
  GO
  SELECT * FROM dbo.DatabaseLog
  GO
  SET SHOWPLAN_XML OFF

� poss�vel salvar o plano de execu��o, e para isso nem � preciso abri-lo. Basta clicar com o bot�o direito no link disponibilizado e escolher Save as. Da mesma forma o modo gr�fico pode ser salvo, apenas clicando com o bot�o direito do mouse e escolhendo a op��o Save as.

Como gerar e ler o plano usando Statistic

Entre as op��es poss�veis para gerar o plano de execu��o, existe a op��o Statistics XML, a qual vai executar a query antes de trazer o plano de execu��o, com isso as informa��es atuais como n�mero de linhas atuais ser�o disponibilizadas Diferente do comando SHOWPLAN_XML que apenas estima e n�o executa a query, portanto os dados atuais n�o aparecem apenas os dados estimados. A Figura 12 traz a execu��o do Statistics XML feita atrav�s dos comandos na Listagem 9.

Listagem 9. Habilitando Statisctics XML.


  SET STATISTICS XML ON
  GO
  SELECT * FROM dbo.DatabaseLog
  GO
  SET STATISTICS XML OFF

**Figura 12.** Plano de execu��o � Statistics XML.

Parte das informa��es contidas no link XML gerado pode ser vista na Listagem 10. Nela est�o as informa��es atuais do plano de execu��o.

Listagem 10. Parte do plano Statisctics XML.


  <ShowPlanXML xmlns="http://schemas.microsoft.com/sqlserver/2004/07/showplan" Version="1.1" Build="10.50.1600.1">
    <BatchSequence>
      <Batch>
        <Statements>
          <StmtSimple StatementText="SELECT * 
           FROM dbo.DatabaseLog
" StatementId="1" 
           StatementCompId="1" StatementType="SELECT" 
           StatementSubTreeCost="0.576891" StatementEstRows="1597" 
           StatementOptmLevel="TRIVIAL" QueryHash="0xCEA1767217FB35FD" 
           QueryPlanHash="0x2959B5DE1A3E7C7D">
            <StatementSetOptions QUOTED_IDENTIFIER="true" 
             ARITHABORT="true" CONCAT_NULL_YIELDS_NULL="true" 
             ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" 
             NUMERIC_ROUNDABORT="false" />
            <QueryPlan DegreeOfParallelism="1" CachedPlanSize="16" 
             CompileTime="121" CompileCPU="109" CompileMemory="88">
              <RelOp NodeId="0" PhysicalOp="Table Scan" 
               LogicalOp="Table Scan" EstimateRows="1597" 
               EstimateIO="0.574977" EstimateCPU="0.0019137" 
               AvgRowSize="8593" EstimatedTotalSubtreeCost="0.576891" 
               TableCardinality="1597" Parallel="0" 
               EstimateRebinds="0" EstimateRewinds="0">
                <OutputList>
                  <ColumnReference Database="[AdventureWorks2008R2]" 
                   Schema="[dbo]" Table="[DatabaseLog]" 
                   Column="DatabaseLogID" />
                  <ColumnReference Database="[AdventureWorks2008R2]" 
                   Schema="[dbo]" Table="[DatabaseLog]" 
                   Column="PostTime" />
                  <ColumnReference Database="[AdventureWorks2008R2]" 
                   Schema="[dbo]" Table="[DatabaseLog]" 
                   Column="DatabaseUser" />
                  <ColumnReference Database="[AdventureWorks2008R2]" 
                   Schema="[dbo]" Table="[DatabaseLog]" 
                   Column="Event" />
                  <ColumnReference Database="[AdventureWorks2008R2]" 
                   Schema="[dbo]" Table="[DatabaseLog]" 
                    Column="Schema" />
                  <ColumnReference Database="[AdventureWorks2008R2]" 
                    Schema="[dbo]" Table="[DatabaseLog]"
                    Column="Object" />
                  <ColumnReference Database="[AdventureWorks2008R2]" 
                   Schema="[dbo]" Table="[DatabaseLog]" Column="TSQL" />
                  <ColumnReference Database="[AdventureWorks2008R2]" 
                   Schema="[dbo]" Table="[DatabaseLog]" 
                   Column="XmlEvent" />
                </OutputList>
                <RunTimeInformation>
                  <RunTimeCountersPerThread Thread="0" ActualRows="1597" 
                   ActualEndOfScans="1" ActualExecutions="1" />
                </RunTimeInformation>
                <TableScan Ordered="0" ForcedIndex="0" NoExpandHint="0">

Entre as op��es de Statistics usadas para gerar e avaliar o plano de execu��o existe a Statistics IO. As estat�sticas de I/O medem a quantidade de atividade em disco gerada pela query. O resultado do Statistics IO pode ser visto na Figura 13 habilitada atrav�s do script da Listagem 11.

Listagem 11. Habilitando Statistics IO.


  SET STATISTICS IO ON
  GO
  SELECT * FROM dbo.DatabaseLog
  GO
  SET STATISTICS IO OFF

**Figura 13.** Plano de execu��o � Statistics IO.

As informa��es produzidas por esta op��o est�o descritas a seguir:

N�mero de scans/seek em qualquer dire��o para retornar as informa��es, depois de o n�vel folha ter sido alcan�ado. Por exemplo, uma consulta filtrada pelo �ndice da tabela a fim de retornar apenas um valor, retorna scan count igual a 0. Isso por que o scan utiliza o �ndice e o filtro foi feito por apenas por um valor. Portanto, vai haver apenas um crit�rio de encontro de valores e n�o foi necess�rio realizar o scan na tabela no n�vel folha;
N�mero de p�ginas lidas do cache de dados, que seriam as leituras l�gicas ou logical reads;
N�mero de p�ginas lidas do disco, que seriam as leituras f�sicas ou physical reads;
N�mero de p�ginas colocadas no cache para consulta, que seriam as leituras read-ahead;
N�mero de text, ntext, image ou p�ginas com valores altos como varchar(max), nvarchar(max), varbinary(max) lidas do cache de dados, que seriam as leituras l�gicas lob ou lob logical reads;
N�mero de text, ntext, image ou p�ginas com valores altos colocadas no cache para consulta, que seriam as leituras f�sicas lob ou physical reads lob;
N�mero de text, ntext, image ou p�ginas com valores altos colocadas no cache para consulta, que seriam as leituras read-ahead lob.

Existe tamb�ma op��o Statistics Time, a qual informa o tempo em milissegundos para cada opera��o a ser completada no plano de execu��o. Habilitada atrav�s do exemplo na Listagem 12, os resultados podem ser vistos na Figura 14.

Listagem 12. Habilitando Statistics Time.


  SET STATISTICS TIME ON
  GO
  SELECT * FROM dbo.DatabaseLog
  GO
  SET STATISTICS TIME OFF

**Figura 14.**Plano de execu��o � Statistics Time.

O momento em que a op��o Statistics Time for habilitada e a query for rodada pode trazer varia��o no tempo informado, dependendo do tamanho do dataset retornado ou concorr�ncia no banco e etc.

Existem outros tipos de Sets Statistics, estes s�o apenas alguns dos que podem ser utilizados para a an�lise de performance da query.

Operadores envolvidos no plano de execu��o

Os exemplos de planos de execu��o que foram gerados no decorrer deste artigo apresentavam o operador table scan conforme pode ser visto na Figura 15. O que exatamente Table Scan significa?

Table Scan, conforme definido anteriormente, informa que o Optimizer escolheu fazer scan da tabela toda, linha a linha at� encontrar o resultado que foi requerido. Esta decis�o pode ter sido entre outros motivos por n�o ter �ndice na tabela, ou por que a quantidade de dados a ser trazida � t�o grande que n�o vale a pena utilizar o �ndice. Portanto os �ndices, caso existam, n�o est�o sendo utilizados.

Se a tabela for pequena, o table scan n�o chega a ser um problema. Entretanto se for uma tabela grande � interessante avaliar outras estrat�gias como: reescrever a query, verificar a possibilidade de cria��o de um �ndice de acordo com a consulta, ou filtr�-la e limitar os dados para que esta possa a utilizar �ndices que j� existam na tabela.

Al�m do Table Scan, existe outro tipo de operador que utiliza Scan e � muito encontrado nos planos de execu��o. Este � o Index Scan, o que isso significa dentro do plano de execu��o?

Index Scan � o scan do �ndice que pode ser cluster ou n�o cluster, ou seja, o �ndice todo ou uma grande parte dele esta sendo escaneado linha por linha at� alcan�ar o resultado desejado.

Os �ndices s�o armazenados em B-tree (v�rios n�s que apontam para um parente). Um �ndice cluster n�o armazena apenas a estrutura chave como um �ndice normal, mas tamb�m filtra e classifica o armazenamento do dado.

Por isso s� existe um �ndice cluster por tabela. Se um �ndice scan est� sendo retornado no plano de execu��o, isso significa que o Optimizer entendeu que muitas linhas precisam ser retornadas e � mais f�cil escanear o �ndice inteiro do que simplesmente utilizar as chaves providenciadas por ele.

Neste caso o que pode ser feito � analisar o uso do �ndice criado, estreitar, se poss�vel, o filtro da cl�usula WHERE, podem ser um bom caminho a seguir.

Outro operador comum de ser visualizado no plano de execu��o � o index seek, conforme pode ser visto na Figura 16. Este n�o � um operador de scan como os dois anteriores, � um operador de seek que funciona sobre o �ndice. O que isso significa para o plano de execu��o?

Index Seek, ao contr�rio do index scan, ocorre quando o Optimizer conseguiu localizar a informa��o requerida atrav�s do uso do �ndice que pode ser cluster ou n�o cluster. Logo atrav�s dos valores chaves do �ndice, rapidamente o valor da linha que precisa ser retornado foi encontrado. Percebe-se que quando h� o uso de cluster index seek a propriedade Ordered do plano de execu��o esta setada para true, ou seja, os dados est�o ordenados. Se o �ndice for n�o cluster, este pode ou n�o estar apontando para um �ndice cluster a fim de realizar o index seek.

Conclus�o

Compreender o que ocorre dentro do SQL e como os planos de execu��o s�o gerados permite diferenciar o que de fato � importante para o ganho de performance na constru��o de uma query do que n�o �.

Por exemplo, considerando que os planos de execu��o s�o baseados em custo e que cada operador tem sua base de custo para o c�lculo do plano de execu��o, pode-se concluir que o custo dos operadores n�o � baseado na velocidade do hardware. N�o se est� considerando que o hardware n�o � importante para performance, ao contr�rio, � importante, todavia o custo dos operadores independe do hardware.

Logo, o custo do operador calculado ser� o mesmo em qualquer vers�o e instala��o do SQL. Um fator de influ�ncia no c�lculo do plano neste caso, entre outros fatores, seria a atualiza��o das estat�sticas, pois o c�lculo de estimativa do custo leva em considera��o esta informa��o.

Estas informa��es podem ser conclu�das, porque h� entendimento de como o SQL funciona e o que acontece quando uma consulta � submetida. Com isso � poss�vel determinar quais as melhores decis�es a serem tomadas, as que realmente ir�o influenciar na performance do c�digo de acordo com o objetivo a ser atingido.

A partir dos pr�ximos artigos, a complexidade das queries vai aumentar e tamb�m o n�mero de operadores usados pelo plano de execu��o. Com isso ser�o abordados quais desses operadores devem sero foco de atua��o para obter ganho de performance

Refer�ncias

GRANT, Fritchey. The Art of High Performance SQL Code: SQL Server Execution Plans. Simple-Talk. 2008. p 17-46.

BOLTON Christian; LANGFORD Justin; BERRY Glen; PAYNE Gavin; BANERJEE Amit; FARLEY Rob. SQL Server 2012 Internals and Troubleshooting. John Wiley & Sons, Inc., Indian�polis, Indiana. 2013. p 48-55.

Saiba mais sobre SQL Server ;)

Processamento de consultas no SQL Server:
Este artigo apresenta como funciona o processamento de uma consulta no SQL Server, identificando os principais mecanismos e componentes desse sistema.
Performance no SQL Server: eliminando o operador Sort:
Veja neste artigo como otimizar a performance de consultas no SQL Server atrav�s da remo��o do operador Sort.
Schemas no SQL Server:
Veja neste artigo informa��es sobre Schemas, o que �? Como criar? Como usar ? Como alterar ? Os Schemas s�o uma cole��o de objetos dentro de um determinado database.

Tecnologias:

Confira outros conte�dos:

SQL SUM: somando os valores de uma...

SQL: INNER JOIN

SQL: Introdu��o ao Where

Assista grátis a nossa aula inaugural

Perguntas frequentes

Quem somos?

Por que a programação se tornou a profissão mais promissora da atualidade?

Como faço para começar a estudar?

Em quanto tempo de estudo vou me tornar um programador?

Sim, você pode se tornar um programador e não precisa ter diploma de curso superior!

O que eu irei aprender estudando pela DevMedia?

Principais diferenciais da DevMedia

Qual o investimento financeiro que preciso fazer para me tornar um programador?

Como funciona a forma de pagamento da DevMedia?

Por Liliam Em 2014

Coment�rios nesta publica��o Escrever um coment�rio sobre conte�do

Funda��o Bradesco

N�vel

Excelente artigo! Claro e com muitas informa��es importantes. Parab�ns!

há +1 ano

Moderacao Devmedia

N�vel 0

Ol� Funda��o Bradesco.

Muito obrigado pelo elogio. Estamos super felizes por te qualificar nosso artigo com excel�ncia. :))))

Valeu abra�os.

há +1 ano

Raquel Guimar�es

N�vel 0

Bem explicado, parab�ns!

há +1 ano

Rog�rio Silva

N�vel 0

Parab�ns!! Muito bom conte�do.

há +1 ano

Nossos casos de sucesso

Leonardo Carlos

Eu sabia pouqu�ssimas coisas de programa��o antes de come�ar a estudar com voc�s, fui me especializando em v�rias �reas e ferramentas que tinham na plataforma, e com essa bagagem consegui um est�gio logo no in�cio do meu primeiro per�odo na faculdade.

Lucas Rodrigues

Estudo aqui na Dev desde o meio do ano passado! Nesse per�odo a Dev me ajudou a crescer muito aqui no trampo.
Fui o primeiro desenvolvedor contratado pela minha empresa. Hoje eu lidero um time de desenvolvimento!
Minha meta � continuar estudando e praticando para ser um Full-Stack Dev!

Her�clito J�nior

Economizei 3 meses para assinar a plataforma e sendo sincero valeu muito a pena, pois a plataforma � bem intuitiva e muuuuito did�tica a metodologia de ensino. Sinto que estou EVOLUINDO a cada dia. Muito obrigado!

Julio Cablen

Nossa! Plataforma maravilhosa. To amando o curso de desenvolvimento front-end, tinha coisas que eu ainda n�o tinha visto. A did�tica � do jeito que qualquer pessoa consegue aprender. S�rio, to apaixonado, adorando demais.

Joelberth Sena

Adquiri o curso de voc�s e logo percebi que s�o os melhores do Brasil. � um passo a passo incr�vel. S� n�o aprende quem n�o quer. Foi o melhor investimento da minha vida!

Felipe Nunes

Foi um dos melhores investimentos que j� fiz na vida e tenho aprendido bastante com a plataforma. Voc�s est�o fazendo parte da minha jornada nesse mundo da programa��o, irei assinar meu contrato como programador gra�as a plataforma.

Wanderson Oliveira

Comprei a assinatura tem uma semana, aprendi mais do que 4 meses estudando outros cursos. Exerc�cios pr�ticos que n�o tem como n�o aprender, est�o de parab�ns!

Jos� Lucas

Obrigado DevMedia, nunca presenciei uma plataforma de ensino t�o presente na vida acad�mica de seus alunos, parab�ns!

Eduardo Dorneles

Aprendi React na plataforma da DevMedia h� cerca de 1 ano e meio... Hoje estou h� 1 ano empregado trabalhando 100% com React!

Adauto Junior

J� fiz alguns cursos na �rea e nenhum � t�o bom quanto o de voc�s. Estou aprendendo muito, muito obrigado por existirem. Est�o de parab�ns... Espero um dia conseguir um emprego na �rea.

Ver todos os casos de sucesso

SQL Server Query: an�lise do plano de execu��o

Este artigo descreve o que acontece quando uma query � submetida dentro do SQL Server, criando uma base conceitual a respeito do funcionamento do plano de execu��o e dos fatores que o influenciam.

Uma query no SQL Server

O que � um plano de execu��o?

Processos do plano de execu��o

Query Parsing

Query Optimizer

Plan Cache

Query Execution

Modos de se obter o plano de execu��o

Planos no modo texto

Planos no modo XML

Plano de execu��o no Modo Gr�fico

Como ler o plano gerado no modo gr�fico

Como gerar o plano no modo texto

Como ler o plano gerado no Modo Texto

Como gerar o plano no Modo XML

Como ler o plano gerado no Modo XML

Como gerar e ler o plano usando Statistic

Operadores envolvidos no plano de execu��o

Conclus�o

Refer�ncias

Saiba mais sobre SQL Server ;)

Confira outros conte�dos:

SQL SUM: somando os valores de uma...

SQL: INNER JOIN

SQL: Introdu��o ao Where

Perguntas frequentes

Nossos casos de sucesso