Eu tenho o Query Store (QS) em execução em uma instância do SQL 2017. Atualmente em RTM, com RTM CU13 atualmente em teste, para ser aplicado em prod na janela de patch do próximo mês.
Embora a maioria das consultas e relatórios retornem resultados rapidamente com pouco ou nenhum impacto, qualquer coisa que eu tento analisar espera é problemática. O uso da CPU sobe de 20 para 80 por cento e permanece lá por minutos até que eu o mate. Este é um sistema de produção 24 horas por dia, 7 dias por semana, portanto, se eu realmente quiser ver as esperas do QS, precisarei fazê-lo em outro lugar.
O banco de dados tem 150 GB com 1000 MB de espaço para QS. Eu tenho uma sandbox com 10 GB de espaço, então se eu pudesse obter os dados do QS, eu poderia brincar com eles lá.
Dei uma olhada e não estou achando como fazer isso. O melhor que encontrei foi este post sql.sasquatch 2016 com uma resposta de 2016 de Erin Stellato
No momento, não há opção para exportar e/ou importar dados do Query Store, mas há um item Connect para votar: https://connect.microsoft.com/SQLServer/feedback/details/2620017/export-query-store -tables-separately-from-the-database-tables
Nota: O link vai para um redirecionamento "Microsoft Connect Has Been Retired" Parece que o link real deve ser para https://feedback.azure.com/forums/908035-sql-server/suggestions/32901670-export-query-store -tabelas-separadamente-dos-dados
Olhando para a Microsoft, acho que quase tudo que você pode usar para acessar os dados é uma exibição, procedimento armazenado ou relatório. Não estou vendo uma maneira de extrair todas as coisas do QS do banco de dados.
Exemplos de consultas diretas, use as visualizações Exemplo de Kendra Little Eu brinquei com a ideia de apenas fazer um Select *
a partir das visualizações e exportar os resultados para minha sandbox. Mas como não encontrei ninguém falando sobre isso, não tenho certeza se é uma boa ideia.
Relacionado
- Prática recomendada com o repositório de consultas
- Como o Repositório de Consultas Coleta Dados
- Exibições do Catálogo do Repositório de Consultas
- Procedimentos armazenados do repositório de consultas
- Monitorando o desempenho usando o Repositório de Consultas
Além disso , gostaria de poder manter os resultados do Repositório de Consultas de pré-CU13 para usar como linha de base para comparar pós-CU13.
Editar após a primeira resposta e edições na mesma As edições recentes da resposta de jadarnel27 adicionam boas informações, mas não me importo com a interface do usuário, quero poder consultar os dados sem alterar o banco de dados ou afetar o desempenho. Como objetivo secundário, gostaria de poder arquivar os dados do QS, para que eu possa revisar o desempenho anterior (ou seja, antes e atualizar, mas depois que os dados antigos do QS forem removidos)
Em primeiro lugar, você pode obter um desempenho aceitável com consultas diretamente nas visualizações do catálogo do repositório de consultas atualizando as estatísticas, adicionando dicas de consulta com guias de plano ou alterando o nível de compatibilidade do banco de dados / CE. Veja as respostas de Forrest e Marian aqui:
Pesquisa interminável no repositório de consultas
Se você estiver no SP1 ou superior, a abordagem mais simples seria usar
DBCC CLONEDATABASE
- que inclui estatísticas, dados de armazenamento de consultas e objetos de esquema - mas nenhum dos dados reais das tabelas.Caso contrário, para exportar, uma abordagem seria simples
SELECT...INTO
das visualizações do repositório de consultas para o banco de dados "sandbox". Estes são os pontos de vista relevantes .A abordagem básica seria assim:
O bom dessa abordagem é que:
SELECT...INTO
consultas não devem aumentar a CPU como as consultas de relatórios do repositório de consultas integrado, porque elas não terão as junções problemáticas que causam acesso repetido aos TVFs na memóriaO "contra" dessa abordagem é que você não pode usar a interface do usuário do repositório de consultas. Uma solução alternativa para isso seria usar o criador de perfil ou eventos estendidos para capturar as consultas que estão sendo executadas pela interface do usuário para os relatórios específicos de que você precisa. Você pode até fazer essa captura em um ambiente sem produção, pois as consultas devem ser as mesmas.
Aviso: isso é potencialmente uma péssima ideia. Há uma razão pela qual você normalmente não pode gravar nessas tabelas. Agradecimentos especiais a Forrest por mencionar a possibilidade para mim.
Se você realmente quiser usar a interface do usuário, poderá carregar as tabelas básicas do Query Store com dados enquanto se conecta por meio do DAC . Aqui está o que funcionou para mim.
Lembrete: você precisa estar usando uma conexão DAC para fazer isso, caso contrário, você receberá erros relacionados às
sys.plan_persist_*
tabelas não existentesObservação: se você estiver no SQL Server 2016, precisará remover a linha sobre estatísticas de espera - essa exibição de catálogo não foi adicionada até o SQL Server 2017
Depois de fazer isso, consegui usar a interface do usuário do repositório de consultas no SSMS para exibir informações sobre as consultas do banco de dados de origem. Organizado!
É importante carregar os dados no banco de dados Sandbox com o Repositório de Consultas desativado e, em seguida, ativar o Repositório de Consultas no modo somente leitura. Caso contrário, o QS acabou em um estado de erro e isso foi gravado no log de erros do SQL Server:
Também notei que isso não funciona se houver tabelas OLTP (Hekaton) na memória no banco de dados de origem. Não importa o que eu faça, o Repositório de Consultas acaba no estado "Erro" com esta mensagem no log de erros:
Você pode contornar isso adicionando um grupo de arquivos com otimização de memória ao banco de dados Sandbox, ainda não tentei isso.
Como complemento à ótima resposta de Josh Darnell , li todas as descrições das visualizações de dados que estão sendo exportadas para tabelas. O código a seguir adiciona as chaves primárias, índices clusterizados e chaves estrangeiras conforme descrito nos documentos da Microsoft. Deve ajudar com consultas contra os dados.
Observe que query_store_runtime_stats e query_store_wait_stats não possuem chaves primárias descritas nos documentos da Microsoft. Como esses dados são exportados, valorizo índices clusterizados em várias estatísticas no intervalo mais atual.
O intervalo é uma definição de configuração interval_length_minutes listada como o 'Intervalo de Coleta de Estatísticas' na GUI de Propriedades da Página Repositório de Consultas, para o banco de dados.
Usar
EXEC sp_query_store_flush_db;
antesSELECT * INTO
Não compila as várias linhas no intervalo de estatísticas de tempo de execução atual para entradas únicas, evitando chaves primárias e índices clusterizados em query_store_runtime_stats & query_store_wait_stats em bancos de dados OLTP pesados . Nesse caso, antes de adicionar as chaves primárias, índices clusterizados e chaves estrangeiras (acima), exclua o intervalo de tempo de execução mais atual com o código abaixo.No meu caso, tenho intervalos de 30 minutos, portanto, se quiser todos os dados até as 6h, extraio alguns minutos após as 6h e excluo as 6h + com o abaixo.
Gostaria de saber se existe uma maneira de usar a opção de banco de dados clone e algum poker clássico de jiggery para manter os dados para análise na GUI do QS.
Não tenho certeza se isso funcionaria, apenas comida para pensar