SQL Saturday #792 – Brasília

Este slideshow necessita de JavaScript.

 

Pelo terceiro  ano consecutivo tive o prazer de palestrar no SQL Saturday #792 – Brasília, e dessa vez foi muito especial, pois palestrei junto com a minha amiga Raiane Lins (Nane).

Nossa palestra foi sobre BACKUP DB TO URL = ‘Blobo Storage’

Nane muito obrigada pela confiança e parceria amiga!

O evento foi bem organizado, estruturado, e com excelente palestras.

Passar um dia aprendendo, revendo amigos, fazendo amizades e network é muito bom.

Parabéns a todos organizadores, participantes, voluntários e palestrantes do SQL Saturday #792 – Brasília.

Segue o link para download dos materiais utilizados pelos palestrantes:  PPT.

Vale ressaltar que os SQL Sartudays são gratuitos, basta somente se inscrever e comparecer ao evento 😉

Ainda temos 3 SQL Saturdays no Brasil para acontecer esse ano (2018) ainda:

SQL Saturday #804  – São Paulo – Setembro

SQL Saturday #799 –  Salvador – Outubro

SQL Saturday  – Rio de Janeiro – Novembro

Venha participar da Comunidade SQL Server.

Vem com a gente 😉

#Sqlserver
#SomosComunidade
#pass
#Sqlsatbsb
#microsoft
#azure
#Comunidades
#sqlfamily
#MVPBR #MVPBuzz

Anúncios
Publicado em SQL Saturday | Deixe um comentário

Material SQL Saturday #744 – Caxias do Sul

Este slideshow necessita de JavaScript.

Pelo segundo ano consecutivo Caxias do Sul realiza o seu SQL Saturday, sendo o primeiro no dia 24/06/17 na Uniftec (SQL Saturday #609 – Caxias do Sul) .

No dia 23/06/18, aconteceu o segundo SQL Saturday: SQL Saturday #744 – Caxias do Sul.

Foi muito bem organizado, estruturado, e com excelente palestras.

Passar um dia aprendendo, revendo amigos, fazendo amizades e network é muito bom.

Minha palestra foi sobre: Backup Database On – Premisses no Azure, o material apresentado está disponível para download  aqui.

Parabéns a todos organizadores, participantes, voluntários e palestrantes do SQL Saturday #744 Caxias do Sul.

Vale ressaltar que os SQL Sartudays são gratuitos, basta somente se inscrever e comparecer ao evento 😉

E já temos vários outros SQL Saturdays confirmados no Brasil para o segundo semestre de 2018!

SQL Saturday # 792 – Brasília – 25/08/2018

SQL Saturday #804  – São Paulo – Setembro

SQL Saturday Salvador – Outubro

Venha participar da Comunidade SQL Server.

Vem com a gente 😉

#Sqlserver
#pass
#Sqlbh
#microsoft
#azure
#Comunidades
#sqlfamily
#MVPBR #MVPBuzz

 

 

Publicado em SQL Saturday | Deixe um comentário

DBA Brasil 3.0 (PPT e Script disponível)

Este slideshow necessita de JavaScript.

Pelo terceiro ano consecutivo, houve mais uma edição do DBA Brasil, no dia 05/05/2018.

Fico muito feliz em ter participado e palestrado nas duas últimas edições: DBA Brasil 2.0 e DBA Brasil 3.0

E como foi? O DBA Brasil 3.0 foi S-E-N-S-A-C-I-O-N-A-L!

Muito bem organizado, excelentes palestras, com um público de mais de 400 inscritos presentes !

Parabéns aos organizadores, voluntários, palestrantes e participantes por fazerem esse evento ser um sucesso!

Obrigada a todos que assistiram as minhas duas palestras sobre: 

1ª – Backup Database On – Premisses no Azure

2ª – Monitorando os Recursos e Processos do Servidor, através do Power BI

 Download do material (PPT e Scripts) apresentado nas minhas palestras:

  • Slides das apresentações disponíveis no SlideShare

 

 

  • Scripts das apresentações disponíveis no GitHub:

https://github.com/sdantas01/SQLServer.git

 

 

 

Publicado em Geral | Deixe um comentário

Monitorando os Contadores do Perfmon, através do Power BI – Parte 2

ppr2.png

 Relog

No post Monitorando os Contadores do Perfmon, através do Power BI – Parte 1, expliquei como acessar e configurar o Perfmon.

Nessa segunda parte, vamos utilizar  o Relog (um recurso disponível no Windows),  que  busca as informações, os dados coletados pelos contadores do Perfmon, e os importa para o SQL Server.

Para fazer essa importação, será necessário a realização de algumas etapas:

1ª Etapa: Criação de um Banco de Dados

O Banco de dados pode ser criado, conforme o script abaixo:

CREATE DATABASE Contadores ON PRIMARY
 (NAME = N'Contadores_Data',
 FILENAME = N'D:\Test\Contadores.mdf',
 SIZE = 8 MB,
 MAXSIZE = UNLIMITED,
 FILEGROWTH = 16 MB),

FILEGROUP FG1
 (NAME = N'Contadores_Data2',
 FILENAME = N'D:\Test\TK432.ndf',
 SIZE = 8 MB,
 MAXSIZE = UNLIMITED,
 FILEGROWTH = 16 MB),

FILEGROUP Documents CONTAINS FILESTREAM DEFAULT
 (NAME = N'Documents',
 FILENAME = N'D:\Test\ContadoresDocuments')

LOG ON
 (NAME = N'Contadores_Log',
 FILENAME = N'E:\Test\Contadores.ldf',
 SIZE = 8 MB,
 MAXSIZE = 2048 GB,
 FILEGROWTH = 16 MB)

Obs:( esse script acima, é meramente um exemplo)

2ª Etapa: Criação de uma ODBC

  • Acesse o painel de controle/Ferramentas Administrativas

relog1.png

  • Selecione ODBC Data Sources(64-bit)

relog2.png

  • Clique em Add, e faça a configuração

relog3.png

  • Selecione SQL Server

relog4.png

relog5.png

relog6.png

  • Selecione o banco de dados que foi criado acima.

relog7.png

  • Opção de alteração do idioma

relog8.png

  • Teste  a conexão

Relog9.png

A criação da conexão ODBC, foi criada com sucesso!

Depois das duas etapas acima, agora podemos fazer a importação dos dados coletados pelo Perfmon, através do relog.

Essa importação é feita pela sintaxe abaixo:

relog “D:\caminho do arquivo \*.blg”  -f SQL  -o SQL:Nome_ODBC!Nome_Maquina

  • Caminho do arquivo:  endereço onde estão  salvos os dados coletados pelo perfmon.
  • -f: utilizando as credenciais de usuário logado no windows
  • SQL: ODBC_Relog (nome criado na conexão ODBC)
  • Nome da máquina: Nome ou o IP do Servidor

Exemplo:

  • Acesse o cmd, pelo  no menu executar (Windows + R)
  • Digite cmd

Ao abrir o cmd, execute a sintaxe:

relog “D:\caminho do arquivo \*.blg”  -f SQL  -o SQL:Nome_ODBC!Nome_Maquina

relog13.png

relog15.png

relog16.png

Executado o relog, o mesmo cria três tabelas no Banco de Dados (nesse caso, o SQL Server).

Visualize as tabelas criadas por comando ou pelo SSMS:

  • Pelo SSMS: expanda a guia Database, selecione o banco criado na conexão ODBC, expanda a guia tables:

relog17

  • Por comando:
USE Contadores

GO

SELECT *
 FROM sys.tables

RELOG19

 

  • Counter Data: Contém informações obtidas pelo perfmon.
  • Counterdetails: Contém os dados coletados dos contadores

Esse post explicou como importar os dados obtidos pelos contadores do perfmon através do relog, para o SQL Server.

Monitorando os Contadores do Perfmon, através do Power BI – Parte 3 em Breve!

 

 

 

Publicado em BI | 5 Comentários

Overview Road Show Power BI BH

No final de semana 24/03 e 25/03, tivemos vários eventos de tecnologia em várias capitais do país, sendo uma delas Belo Horizonte.

O Road Show é uma parceria entre a Microsoft e a PBIX (Planilheiros) e tem como objetivo principal mostrar a importância do Power BI nas organizações e a sua evolução.

Fiquei muito feliz principalmente por alguns motivos, por BH ser a primeira capital a receber o Road Show, e pelo convite para participar e palestrar nesse evento fantástico.

Passamos o sábado inteiro  com os planilheiros, que com uma excelente didática e muito bom humor, nos proporcionaram muito conteúdo de Power BI.

Galera, esse evento vai rodar o Brasil todo, não percam!

#Comunidades
#planilheiros
#sqlbh
#microsoft
#powerbi
#juntos

Este slideshow necessita de JavaScript.

Publicado em Geral | 12 Comentários

ONG MTAC

No dia 28/02/2018, recebi o comunicado que fui eleita Conselheira Fiscal da ONG MTAC.

Esse vai ser o meu segundo mandato na ONG, como Conselheira Fiscal.

A ONG MTAC – Associação Multi-Platform Audience Contributor,  é formada por profissionais de TI independentes com atuação em todos os setores da Tecnologia da Informação e colaboradores voluntários com o objetivo de produzir e desenvolver conteúdos, eventos e treinamento de pessoas nas áreas técnicas, além de promover o networking.  ‘http://www.mtac.org.br/home‘.

Agradeço a todos!

#Comunidades
#mtac
#unidos

IMG_3982

 

Publicado em Geral | Deixe um comentário

Encontro Especial Random Hacks – Março/18

No dia 17/03/2018, fizemos um encontro Especial do Grupo Random Hacks, onde tivemos duas palestrantes: Juliana Helena  e Cibele Simões.

Nosso objetivo foi fazer uma homagens as mulheres, devido ao dia Internacional da Mulher no dia 08/03/2018.

Eu e a Amanda Karina, fizemos a abertura, onde falamos sobre a inclusão da Mulher na TI.

Excelente encontro 😉

Nos encontramos nos próximos encontros do Random Hacks 😉

#Comunidades
#randomhacks
#unidos
#juntos

random.png

 

 

Publicado em SQL BH | Deixe um comentário

Encontro SQL Business Intelligence Day

No dia 24/02/2018, organizamos o SQL Business Intelligence, onde tivemos 3 palestras  no decorrer do dia, sobre: BI no Azure, Arquitetura Lambda e Inteligência Artificial.

É muito gratificante passar o dia com a Comunidade, trocando conhecimentos, experiências, revendo e fazendo novos amigos.

Esse evento foi um esquenta para o primeiro SQL Saturday #715 Belo Horizonte

Que venha os próximos encontros!

Que venha o SQL Saturday #715 BH no dia 19/05/2018.

#sqlbh
#microsoft
#azure
#comunidades
#BidoBrasil
#Pass
#Unidos
#Puc

Obrigada  Microsoft pelo patrocínio, a PUC Minas e a BI do Brasil pelo apoio.

Agradecemos a todos pela presença 😉

intelligence day.png

Publicado em SQL BH | Deixe um comentário

Monitorando os Contadores do Perfmon, através do Power BI – Parte 1

bllog1.png

1ª Etapa   

O que é o  Perfmon?

O perfmon é uma ferramenta do Windows, que tem o objetivo de monitorar, através de seus contadores, recursos e processos do servidor, como por exemplo: desempenho da CPU, quantidade de memória utilizada e vários recursos específicos do SQL Server.

Os contadores monitorados nessa rotina, são:

  • Logical Disk
    • Avg Disk Sec/Read
    • Avg Disk Sec/Transfer
    • Avg Disk Sec/Write
    • Current Disk Queue Length
    • Disk Bytes/sec
    • Disk Read Bytes/sec
    • Disk Write Bytes/sec
    • Disk Reads/sec
    • Disk Transfers/sec
    • Disk Writes/sec
  • Memory
    • %Committed Bytes In Use
    • Available MB
    • Committed Bytes
    • Free System Page Table Entries
    • Pool Nonpaged Bytes
    • Pool Paged Bytes
  • Network Interfaces
    • Bytes Received/sec
    • Bytes Sent/sec
    • Bytes Total/sec
  • Processor
    • %Processor Time
    • %Privileged Time
  • System
    • Context Switches/sec
    • Exception Dispatches/sec
    • Processor Queue Length
    • System Calls/sec

“Existem dois casos nos quais o Perfmon se destaca em relação às demais ferramentas (Profiler, DMV, XE)

  • Analise a distribuição de memória do SQL Server
  • Medição dos tempos de resposta do storage “
(https://blogs.msdn.microsoft.com/fcatae/2016/02/09/contadores-do-perfmon/ )

Acessando o perfmon

  • Digite o comando w + x, selecione Run, e digite na caixa de diálogo perfmon

perf1.png

perf2.png

perf3.png

Expanda a aba Data Colletor, clique com o mouse direito em cima de User Defined e        selecione new/Data Colletor Set

Perf4.png

Crie o seu Data Colletor Set, preenchendo os campos de acordo com o seu ambiente.
Daremos o nome de Contadores_1.

Perf5.png

Após criado o  Contadores_1 acima, expanda a aba User Defined, e localize-o.

Perf6.png

Do lado direito, clique em cima do Contadores_1, com o mouse do lado direito, selecione propriedades.

Perf7.png

Clique Add, e selecione os contadores desejados, e demais configurações.

perf8.png

perf9.png

Agora clique do lado esquerdo, em cima do Contadores_1, e clique com o mouse do lado direito, selecione propriedades.
Nessa tela, várias configurações são feitas, por exemplo: condição de parada, tamanho, duração, início, permissões, e etc.
Configure de acordo com a necessidade do seu cenário.

perf10.png

Depois de feita toda a configuração do Contadores_1, o mesmo tem que ser iniciado, para isto, basta ir do lado esquerdo, selecioná-lo e com o mouse direito clicar em start.

perf11.png

Concluída a primeira etapa, já é possível fazer a coleta dos dados, através dos contadores selecionados e analisá-los.

perf12.png

Perf13.png

Monitorando os Contadores do Perfmon, através do Power BI – Parte 2

 

 

Publicado em BI | 1 Comentário

Query Store!

Este post tem o objetivo de mostrar ao DBA a importância da nova feature do SQL Server 2016: “Query Store”, de uma forma objetiva.

O Query Store é um repositório de consultas, onde registra em memória informações sobre o(s) plano(s) de execução de uma query,  para depois persistir  em disco.

Existem várias formas de análise de planos de execução para se obter uma melhor performance e desempenho na consulta de uma query.

Não vou entrar nos detalhes das outras features que auxiliam na análise dos planos de execução anterior ao Query Store. Porém, vale mencionar que devem ser avaliados e comparados os prós e os contras de cada uma delas, deixando claro que o Query Store não elimina o uso das outras features.

Uma query pode ter vários planos de execução por vários motivos, ex: um índice deletado, upgrade de versão, aumento nos registros de uma tabela, estatísticas desatualizadas, entre outros.

Exemplo clássico: uma consulta que normalmente gasta segundos para ser executada passa a demorar horas. Houve alguma mudança, certo? O que pode ser feito para se descobrir o motivo que levou a isso? É nessa hora que entra o Query Store: ele salva os planos de execução de uma query (que podem ser vários) no filegroup primário do banco de dados, no qual foi habilitado. (É habilitado por banco).

O Query Store possibilita fazer uma análise nos planos de execução gerados, permitindo ao DBA a opção de escolher qual o melhor plano para a execução de uma query, obtendo uma melhor performance, podendo, inclusive, fazer uma regressão de algum plano, caso seja necessário, ou seja, podemos forçar um plano de execução se necessário.

Lembrando que forçar um plano de execução não quer dizer que é a melhor solução, mas que em um determinado momento pode ser preciso, para tornar o processo mais ágil para a solução do problema, para depois analisar com mais calma a situação e corrigi-lá.

“Ao forçar um plano de execução, você está tratando o sintoma do problema e não a causa.”

Vantagens em utilizar o Query Store

  • Auxilia no processo de migração de uma versão
  • Mantém o histórico dos planos de execução, mesmo após um reinício do SQL Server
  • Consome somente os recursos configurados
  • Possui 19 extend events específicos para o Query Store

Como funciona a Arquitetura

Arquitetura

Ao enviar uma consulta ao banco de dados, o Query Store utiliza-se duas tabelas em memória: A Plan Store que grava dados dos planos de execução da query após ela ser compilada e a Runtime Stats Store, que grava as informações do tempo de consulta após a execução da query.

Os dados que estão nessas duas tabelas são gravados em disco de uma forma assíncrona. O tempo que esses dados ficam em memória, para posteriormente persistir em disco, é configurado no Query Store. Por meio do Query Store Views, os dados são liberados para consulta, hora pelas tabelas em memória, hora pelo disco, por isso é assíncrono.

Contadores Perfmon

O desempenho do Query Store pode ser monitorado por 4 contadores adicionados no monitor do perfmon.

contadores

Habilitando o Query Store

· Acesse o SSMS, selecione o banco desejado -> clique em propriedades -> Query Store

     q1

· Selecione a opção Read Write.

· A opção Read Only, deixa o Query Store somente como leitura (Essa opção será detalhada mais abaixo).

· Pode ser habilitado pelo Transact-SQL:

ALTER DATABASE Sat580 SET QUERY_ STORE = ON

2

Após habilitado, atualize o banco ->Expanda a aba do mesmo, e o Query Store já aparece disponível.

Possuí 4 relatórios padrão:
Regressed Queries,
Overall Resource Consumption,
Top Resource Consuming Queries
Tracked Queries.

3

Ao habilitar o Query Store, aparecem várias opções para configurações, tais como:

q4

· Data Flush Interval (Minute) – Tem como default o intervalo de 15 minutos.

Significa que a cada quinze minutos os planos de execução e as estatísicas de tempo de execução que estão nas tabelas Plan Store e Plan Runtime Store (que estão em memória), são gravados no disco. Esse intervalo pode ser alterado, para mais ou para menos, de acordo com a necessidade do ambiente.

· Statistics Colletion Interval – Tem como default o intervalo de 1 hora, está relacionado com a configuração do nível de granularidade das estatísticas de tempo de execução das consultas capturadas, que deseja obter.

· Max Size (MB) – Tamanho máximo do Query Store no Disco, por padrão vem habilitado com 100 MB. Ao atingir esse limite, o Query Store sai do modo read write e passa para o estado read only, ou seja, ele deixa de gravar novos planos de execução. Esse tamanho pode ser alterado de acordo com a necessidade do ambiente, chegando ao limite máximo de 1.0 TB, dependendo da versão do SQL Server 2016.

· Query Store Capture Mode – É a forma como o Query Store captura os planos de execução.

  • Possui 3 opções: All(1), None(2) e Auto(2):

Size Based Cleanup Mode – O Query Store limpa os dados automaticamente, quando eles atingirem um limite de 90% do tamanho máximo configurado, apagando os dados mais antigos.

Opções: Auto e Off, por padrão vem habilitada como Off.

Análise (Analise) bem essa opção.

· Stale Query Treshold(Days) – Esse modo permite manter armazenados os dados no Query Store pelo período configurado(dias).

· Purg Query Data – Remove todos os dados do Query Store.

As opções de configurações acima citadas, podem ser configuradas pelo Transact-SQL .

  •  (1) vem habilitado como All, ou seja, captura todos os planos de execução para as querys.
  • (2) Auto o Query Store captura somente consultas com planos de execução relevantes.
  • (3) None – O Query store para de capturar novos planos de execução.

Essas configurações acima, podem ser feitas pelo comando Transact T-SQL abaixo:

ALTER DATABASE <Meetup>

SET QUERY_STORE (

OPERATION_MODE = READ_WRITE,

CLEANUP_POLICY =

(STALE_QUERY_THRESHOLD_DAYS = 30),

DATA_FLUSH_INTERVAL_SECONDS = 3000,

MAX_STORAGE_SIZE_MB = 500,

INTERVAL_LENGTH_MINUTES = 15,

SIZE_BASED_CLEANUP_MODE = AUTO,

QUERY_CAPTURE_MODE = AUTO,

MAX_PLANS_PER_QUERY = 1000

);

Testando o Query Store:

Este exemplo mostra a opção de forçar um plano de execução, por meio do comando Force Plan.

Após habilitado o Query Store, vamos usar os seguintes comandos Transact-SQL:

Use Meetup

Go

UPDATE Ciclista
SET Nome = ‘Sulamita’,
Sobrenome = ‘Dantas’,
Email = ‘sdantas01@gmail.com’,
Sexo  = ‘F’
WHERE Codigo = 3

SELECT *
FROM Ciclista
WHERE Codigo = 3

Depois de executada a consulta, clique do lado esquerdo na opção abaixo do Query Store e selecione um dos relatórios disponíveis. Ao selecionar o Top Resource Consuming Queries, do lado direito já aparece o plano de execução da consulta, com o plan id 1. O Query Store mostra de uma forma bem simples, o plano de execução gerado para essa consulta, conforme figura abaixo:

Q5

A execução dessa consulta gerou um plano de execução, com um table scan.

Agora vamos fazer com que a query tenha um plano  de execução diferente do plano gerado acima.

Será criado um índice cluster:

CREATE CLUSTERED INDEX [IDX_Codigo] ON [dbo].[Ciclista]CREATE CLUSTERED INDEX [IDX_Codigo] ON [dbo].[Ciclista] ( [Codigo] ASC
)

Após a criação do índice, será feita uma nova consulta:

SELECT *
FROM Ciclista
WHERE Codigo = 3

Em seguida, execute o relatório Top Resource Consuming Queries novamente. Assim, o Query Store apresentará dois planos de execução para a query 1, o plan id 2 e o plan id 12.

Com a inclusão do índice, a query ganhou um novo plano de execução, gerando um Seek.

Q6

O que aconteceu?

A query 1 tinha um plano de execução que gerava um table scan, com a criação de um índice, ela ganhou um novo plano de execução, passando a gerar um seek, ou seja, houve uma uma mudança no plano de execução.

A query 1 agora possui dois planos de execução, e passou a usar o plano de execução id 12.

Por meio do Query Store, de uma forma simples, podemos fazer com que a query 1, volte a usar o plano de execução id 2, usando o botão force plan.

Obs: Lembrando que esse é um exemplo bem hipotético, somente para mostrar como forçar um plano de execução.

Q7

Pronto, agora a query já está usando o plan id 2, realizando um table scan, voltando ao seu plano de execução inicial.

Q8.png

Esse foi um exemplo bem simples, para que vocês possam se familiarizar com o Query Store e fazer análises mais complexas.

Possui 19 eventos Extend Events para o Query Store.

No site abaixo, temos as seguintes DMV’s de sistema, que podem ser utilizadas para uma maior análise de desempenho.

https://docs.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store

· Verificar o status atual do Query Store:

SELECT actual_state, actual_state_desc, readonly_reason,

current_storage_size_mb, max_storage_size_mb

FROM sys.database_query_store_options;

· Últimas consultas executadas no banco de dados:

SELECT TOP 10 qt.query_sql_text, q.query_id,

qt.query_text_id, p.plan_id, rs.last_execution_time

FROM sys.query_store_query_text AS qt

JOIN sys.query_store_query AS q

ON qt.query_text_id = q.query_text_id

JOIN sys.query_store_plan AS p

ON q.query_id = p.query_id

JOIN sys.query_store_runtime_stats AS rs

ON p.plan_id = rs.plan_id

ORDER BY rs.last_execution_time DESC;

· Número de execuções para cada consulta:

SELECT q.query_id, qt.query_text_id, qt.query_sql_text,

SUM(rs.count_executions) AS total_execution_count

FROM sys.query_store_query_text AS qt

JOIN sys.query_store_query AS q

ON qt.query_text_id = q.query_text_id

JOIN sys.query_store_plan AS p

ON q.query_id = p.query_id

JOIN sys.query_store_runtime_stats AS rs

ON p.plan_id = rs.plan_id

GROUP BY q.query_id, qt.query_text_id, qt.query_sql_text

ORDER BY total_execution_count DESC;

· O número de consultas com o tempo de execução médio mais longo na última hora:

SELECT TOP 10 rs.avg_duration, qt.query_sql_text, q.query_id,

qt.query_text_id, p.plan_id, GETUTCDATE() AS CurrentUTCTime,

rs.last_execution_time

FROM sys.query_store_query_text AS qt

JOIN sys.query_store_query AS q

ON qt.query_text_id = q.query_text_id

JOIN sys.query_store_plan AS p

ON q.query_id = p.query_id

JOIN sys.query_store_runtime_stats AS rs

ON p.plan_id = rs.plan_id

WHERE rs.last_execution_time > DATEADD(hour, -1, GETUTCDATE())

ORDER BY rs.avg_duration DESC;

· Consultas com vários planos de execução:

WITH Query_MultPlans

AS

(

SELECT COUNT(*) AS cnt, q.query_id

FROM sys.query_store_query_text AS qt

JOIN sys.query_store_query AS q

ON qt.query_text_id = q.query_text_id

JOIN sys.query_store_plan AS p

ON p.query_id = q.query_id

GROUP BY q.query_id

HAVING COUNT(distinct plan_id) > 1

)

SELECT q.query_id, object_name (object_id) AS ContainingObject,

query_sql_text, plan_id, p.query_plan AS plan_xml,

p.last_compile_start_time, p.last_execution_time

FROM Query_MultPlans AS qm

JOIN sys.query_store_query AS q

ON qm.query_id = q.query_id

JOIN sys.query_store_plan AS p

ON q.query_id = p.query_id

JOIN sys.query_store_query_text qt

ON qt.query_text_id = q.query_text_id

ORDER BY query_id, plan_id;

Conclusão:

Assim, o dba, por meio da interface gráfica ou DMV’s, pode acessar os planos de execução gerados pelo Query Store, descobrindo as querys lentas e pode fazer uma análise da melhor performance para determinada(s) query(s).

Explore essa  feature 😉

Publicado em SQL Server 2016 | Deixe um comentário