Ajude a encontrar uma ferramenta SQL antiga que reescreveu as consultas [fechadas

Question

Havia uma ferramenta antiga do SQL Server chamada Lectoneth ou algo assim, você colocaria as consultas SQL nela e a reescreveria para você.

Acho que a Quest comprou, mas não consigo encontrar onde baixar uma cópia gratuita desse software.

Realmente ajuda quando você não tem DBA e tem muitas consultas SQL para reescrever.

Obrigado

Craig

Answer 1

Não toca uma campainha, e presumivelmente você viu, mas nada óbvio na missão local na rede Internet

Talvez uma ferramenta como o Red Gate's Prompt SQL Ajudaria - a edição Pro faz SQL reformatando.

Editar
Acho que encontrei o que você está procurando, mencionado aqui - LECCO SQL Expert. O link para o site da LECCO realmente direciona para a Quest, mas um 404.

O LECCO SQL Expert é a única solução completa de ajuste e otimização de desempenho do SQL que oferece detecção problemática de SQL e reescrita automática de SQL. Com seu mecanismo de pesquisa de feedback baseado em Inteligência Artificial (IA) integrada, o LECCO SQL Expert reduz o esforço necessário para otimizar o SQL e torna até o programador mais júnior um especialista.

Os desenvolvedores usam o LECCO SQL Expert para otimizar o SQL durante o desenvolvimento de aplicativos. Os DBAs eliminam o SQL problemático antes que os usuários tenham problemas de desempenho de aplicativos usando o especialista em sistemas de produção da LECCO SQL.

Parece que não se trata mais - todas as menções em que eu consegui encontrar indicadas que ele suportou até o SQL 2000 e links obsoletos - parece que não era uma ferramenta gratuita. Como dito em meus comentários, acho que esse tipo de coisa é uma habilidade que vale a pena possuir e se beneficiaria a longo prazo para não transmitir uma ferramenta para tentar fazer isso por você.

Eu não estava ciente dessa ferramenta antes, então peguei algo dessa pergunta - me deixei intrigado!

Atualização final:
Para confirmar, esse produto foi realmente como a LECCO foi adquirida há alguns anos. Obrigado a Brent Ozar pela confirmação.

Answer 2

Eu acho que você está procurando um produto que foi fundido no Toad for SQL Server. A versão comercial do Toad possui um recurso SQL Optimizer que tenta muitas maneiras de reescrever suas instruções SQL e depois as testar para descobrir quais são as maneiras mais rápidas.

Você pode baixar o Toad aqui:

http://www.toadsoft.com/

Mas esteja ciente de que esse recurso é um recurso somente de versão paga.

Answer 3

Bem, em vez de gastar seu tempo procurando uma bala mágica, por que não gastar algum tempo aprendendo o ajuste do desempenho (você precisará de um livro, isso é muito complexo para a Internet em geral). Além disso, acredito que, se você deseja escrever um novo código decente, precisa entender o desempenho nos bancos de dados. Não há razão para ser incapaz de escrever um código que avivida os problemas mais comuns.

Primeiro, reescreva todas as consultas para usar a sintaxe ANSII sempre que você a abrir para revisá -la por qualquer outro motivo. A revisão do código todas as alterações do SQL e não passa na revisão do código, a menos que as junções explícitas fossem usadas.

Seu primeiro passo no ajuste de desempenho para identificar quais consultas e procs estão causando o problema. Você pode usar ferramentas que lhe contem as consultas com o pior desempenho em termos de tempo geral, mas não se esqueça de ajustar as consultas que também são executadas frequetly. Cortar segundos de uma consulta que funciona milhares de vezes por dia pode realmente acelerar as coisas. Além disso, como você já está no Oprod, provavelmente seus usuários estão reclamando de determinadas áreas, essas áreas devem ser analisadas no início.

Coisas para procurar isso causam problemas de desempenho:

Cursores

Subconserias correlacionadas

Visualizações que chamam visualizações

Falta de indexação adequada

Funções (especialmente função escalar que fazem da consulta a linha por linha por linha instantada através de um conjunto)

Onde cláusulas que não são sargáveis

Tabelas Eav

Retornando mais dados do que você precisa (se você tiver alguma coisa com seleção * e uma junção, corrija imediatamente isso.)

Reutilizando os SPs que agem em um registro para fazer um grande grupo de registros

Consultas complexas autogeneradas mal projetadas da ORMS

Tipos de dados incorretos, resultando na necessidade de estar continuamente convertendo dados para usá -los.

Como você tem a sintaxe do estilo antigo, é altamente provável que você tenha muita cruz acidental que se une

Uso de distintos quando pode ser substituído por uma tabela derivada em vez disso

Uso da união quando tudo funcionaria

Design de mesa ruim que requer uma construção difícil de consultas que nunca podem ter um bom desempenho. Se você se unir frequentemente à mesma tabela várias vezes para obter os dados necessários, observe o design das tabelas.

Além disso, como você usou junções implícitas, você precisa estar ciente de que, mesmo no SQL Server 2000, a sintaxe implícita esquerda e direita não funciona corretamente. Às vezes, isso interpreta uma junção cruzada, em vez de uma junção esquerda ou junta direita. Eu priorizaria encontrar e corrigir todas essas consultas imediatamente, pois elas podem estar retornando atualmente um conjunto de resultados incorreto. Resultados de dados ruins são ainda piores que os dados lentos retornem.

Boa sorte.