Réécriture requête SQL

Version imprimable

Bonjour

je voudrais savoir si on peut réecrire cette requete d'une autre manière.

Code:

1
2
3
4
5
6
7
8
9
10
select * 
from [gger] tr1
Join [iddff] On [iddff].idf = tr1.param2
where left([etat],1) <> '5' and left([etat],1) <> '9' and type_trigger = '32000000' and tr1.id_trigger = any
(select top 1 tr2.id_trigger from [gger] tr2
where tr2.code_client = tr1.code_client and tr2.etat = tr1.etat 
order by id_trigger)
and
[iddff].service_send=1
order by tr1.date_heure , tr1.etat asc

Merci

Comme cela par exemple :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
select  * 
from    [gger]  tr1
    inner join 
        [iddff] idf
        On idf.idf = tr1.param2
where   left([etat],1) not in ('5', '9') 
    and type_trigger = '32000000' 
    and exists  
        (   select  null
            from    [gger]  tr2
            where   tr2.code_client = tr1.code_client 
                and tr2.etat        = tr1.etat 
                and tr2.id_trigger  = tr1.id_trigger
        )
    and idf.service_send = 1
order by tr1.date_heure
    ,   tr1.etat asc

Nota : il serait bon de qualifier (ajouter l'alias de la table) les colonnes etat et type_trigger dans la clause where.

Qu'est-ce qui te pose problème dans la requête originale ?

11/05/2017, 16h45
laraki.fissel

Merci al1_24, mais les deux requetes ne donnent pas le même resultat.

la premiere requete affiche 3 lignes alors que la tienne affiche 50 lignes.

Cdt
11/05/2017, 16h50
al1_24

En effet, j'avais omis de prendre en compte le top 1 :oops:
Il faut remplacer la ligne 13 par :

Code:

having tr1.id_trigger = min(tr1.id_trigger)
11/05/2017, 17h45
StringBuilder

Question stupide : pourquoi réécrire la requête ?

Lisibilité ?
Performances ?
Juste histoire de donner l'impression de bosser au patron/prof ?
11/05/2017, 18h14
laraki.fissel

merci bcp al1_24

voila je vais te dire pourquoi je voulais modifier la requetes,
avec l'ancien requete, sql server ne fait aucune proposition de création d'index, du coup la seule solution est de réécrire la requete plusieurs fois jusqu'a ce que SQL Server propose le meilleur index.

merci.
11/05/2017, 18h16
laraki.fissel

StringBuilder, franchement t'es fort,
tu avais vraimenet le temps pour écrire ces 2 mots ?. BRAVO
12/05/2017, 09h29
al1_24

Rien ne t'interdit de créer toi même des index qui te semblent utiles pour améliorer tes temps de traitement.
Au pire, si tes choix ne sont pas bons, les index ne seront pas utilisés.
12/05/2017, 09h30
StringBuilder

Si ma question t'as choqué, j'en suis désolé.

On ne réécrit en général pas une requête "pour le plaisir", et selon l'objectif recherché, on ne va pas l'écrire de la même manière, voir, la réécriture n'est pas forcément utile.

Je suis tout à fait circonspect quant au motif évoqué : "Avec l'ancienne écriture, SQL Server ne propose pas de meilleur index."
=> Ok, alors s'il n'en propose pas de meilleur, peut-être dispose-t-il déjà du meilleur index ?
=> Étant donné qu'en général, quand on crée l'index recommandé et qu'on exécute de nouveau la requête, il en propose un autre qui n'a rien à voir, t'es pas prêt de t'en sortir
=> Si SQL Server peut éventuellement te mettre sur la piste quant aux index à créer (notamment s'il te promet des améliorations de 90%), c'est pas au SGBD de décider de la présence d'index et encore moins de leur structure. C'est à toi, en écrivant tes requêtes, en concevant la base, et surtout, en vérifiant les plans d'exécution, qui doit décider des index à créer ou non.

Je reste absolument dubitatif quand à la pertinence de réécrire la requête, sans plus d'informations :
- On n'a pas le DDL
- On n'a pas de jeu de données
- On n'a aucune idée du volume de données
- On n'a toujours pas la moindre idée du problème rencontré (elle est lente au moins ta requête ?)

Edit : Sinon, vous parlez de SQL Server 2000.
Le support est arrêté depuis 2013. https://support.microsoft.com/fr-fr/...ice%20Pack%204

Comptez-vous migrer vers une version plus récente pendant que c'est encore possible ?

En effet, après SQL Server 2008 R2, plus moyen de récupérer une base créée avec 2000 (que ce soit en attachement de fichier ou de restauration de backup) et 2008 R2 n'est lui non plus plus supporté... https://support.microsoft.com/fr-fr/...ice%20Pack%203

Vos soucis de proposition d'index et de performances seront certainement tout autres avec une version plus récente... A mon avis vous feriez mieux de commencer par regarder de ce côté !

Edit 2 : Je ne me souviens plus du tout si SQL Server 2000 permet de créer un index sur une donnée calculée. Si c'est le cas, alors un index sur "left([etat],1)" devrait grandement améliorer les performances. Si ce n'est pas le cas, alors une migration vers une version actuelle de SQL Server permettra de faire de tels index.
12/05/2017, 10h15
laraki.fissel

Bonjour StringBuilder

Quand tu débarques dans une société et tu trouves une application phare qui utilise sql server 2000, tu vas leur dire quoi,
vous migrez tout de suite vers sql server 2008.
ou tu vas leur dire non, cette version n'est plus supporté par Microsoft, du coup je ma barre.

Une autre question si tu permets,
Quand t’as un I/O trop élevé avec des pics très fréquents de CPU de 90% , tu crées une charge de travail pour identifier les requêtes couteuses en I/O et CPU,
tu penses que t’aura le temps pour chercher un index pertinent pour chaque requête sans utiliser l’assistant de paramétrage de l’index.

Avant de quitter, je tiens à remercier bcp al1_24, j'apprécie bcp son attitude (donner une solution et poser ensuite des questions), je pense qu'il connait très bien le mot stress quand on travaille sur un environnement de Prod et nous avons que quelques minutes pour résoudre un problème.

Merci.
12/05/2017, 10h45
al1_24

Personnellement, j'aurais quelques préventions face à un DBA qui se repose sur les assistants du SGBD pour optimiser une requête :roll:
12/05/2017, 11h04
laraki.fissel

Bonjour al1_24

je respecte ton point de vue,

Un bon DBA?, waw c'est un sujet à part.

Merci.
12/05/2017, 15h22
Bernardos

Citation:

Quand tu débarques dans une société et tu trouves une application phare qui utilise sql server 2000, tu vas leur dire quoi,
vous migrez tout de suite vers sql server 2008.

Perso, Sans aucune hésitation, je dis de migrer vers 2014 au minimum.

Cordialement,
12/05/2017, 16h05
StringBuilder

Citation:

Envoyé par laraki.fissel

Quand tu débarques dans une société et tu trouves une application phare qui utilise sql server 2000, tu vas leur dire quoi,
vous migrez tout de suite vers sql server 2008.
ou tu vas leur dire non, cette version n'est plus supporté par Microsoft, du coup je ma barre.

Si tu "débarques" dans une société, c'est que soit tu as été embauché (pas pour tes beaux yeux, mais pour tes compétences) soit que ta prestation a été vendue (par pour tes beaux yeux, mais pour tes compétences).
Il est donc absolument normal de donner ton point de vue "d'expert" en indiquant que conserver une version obsolète d'un SGBD pour une application critique (et même non critique ceci dit) est une très mauvaise idée.
Rien n'empêche de continuer à l'utiliser, mais il me semble suicidaire de ne pas évoquer le problème et mettre en place un plan d'action pour changer de version.

Citation:

Envoyé par laraki.fissel

Une autre question si tu permets,
Quand t’as un I/O trop élevé avec des pics très fréquents de CPU de 90% , tu crées une charge de travail pour identifier les requêtes couteuses en I/O et CPU

Là pour le coup, j'ai pas de boule de cristal : à aucun moment tu n'as indiqué pourquoi tu souhaitais réécrire la requête. Au mieux, on pouvait s'en douter, ou à la limite s'en foutre. al1_24 a proposé une réécriture sans avoir la moindre idée de l'objectif de cette nouvelle écriture : elle résous peut-être ton problème, peut-être pas. Ni lui ni personne d'autre (que toi) n'a le moyen de le savoir, dans la mesure où à aucun moment tu n'exposes ton problème.
D'où ma première question, à laquelle je viens enfin d'avoir un partie de la réponse.
Une copie du plan d'exécution ne serait cependant pas de trop pour t'aider plus précisément.

Citation:

Envoyé par laraki.fissel

tu penses que t’aura le temps pour chercher un index pertinent pour chaque requête sans utiliser l’assistant de paramétrage de l’index.

Euh... oui.
Chaque économie de temps à cette étape, comme à n'importe quelle étape de la conception d'un logiciel, se paierait au centuple à un moment où à un autre.
Un index occupe de la place sur le disque, en mémoire, et consomme de précieuses ressources lors de sa mise à jour (donc à chaque mise à jour de la table).
Si des index non pertinents et redondants sont créés en fonction des suggestions de l'assistant de SQL Server, alors pour gagner parfois rien (voir perdre), tu vas ralentir l'ensemble de la base de données.
Attention : un index mal foutu peu s'avérer plus lent qu'un full scan d'une table.
Sur le blog de SQLPro (ainsi que dans ses bouquins) il y a maints exemple sur le sujet.
Le premier truc quand tu as besoin d'un nouvel index, c'est :
- de chercher comment t'en passer
- de chercher si un autre index peut être adapté pour répondre au besoin
Pas de créer tout ce que les assistants proposent sous prétexte qu'une requête est un peu longue.

En plus de la réécriture de la requête, mais ça, sans le DDL et une explication de ta part ainsi qu'un jeu de données, c'est pas possible de t'aider, parfois il manque carrément des éléments à la requête, qui empêchent l'utilisation d'index existants et performants.

Bref, madame Irma c'est la porte d'en face.
13/05/2017, 09h45
SQLpro

Citation:

Envoyé par StringBuilder

Edit 2 : Je ne me souviens plus du tout si SQL Server 2000 permet de créer un index sur une donnée calculée. Si c'est le cas, alors un index sur "left([etat],1)" devrait grandement améliorer les performances. Si ce n'est pas le cas, alors une migration vers une version actuelle de SQL Server permettra de faire de tels index.

Comme dirais Obama "yes you can" !

Les index sur colonne calculée persistante existent depuis au moins la version 2000, voire la version 7.

Et je te rejoins sur le fait qu'il faut impérativement indiquer à son client ou son employeur les risques de rester en version 2000...
Par exemple, SQL 2000, 2005, 2008 et 2008 R2 ne sont plus supportés sur les OS Windows actuels et les machines actuelles ne supportent pas les OS anciens...
Donc en cas de plantage grave du système (genre sinistre majeur) il va falloir trouver une vieille machine ou monter une VM, trouver un vieil OS, trouver une vieille version de SQL Server....
Bref, plusieurs jours d'indisponibilité si l'on en s'y es pas préparé !

A +
15/05/2017, 08h32
StringBuilder

La cyber attaque de ce week-end est la meilleure illustration de la nécessité de conserver des version logicielles à jour.
La système de gestion des urgences médicales (l'équivalent du 15 au Royaume-Uni) est complètement vétuste et toujours majoritairement sous Windows XP : depuis hier ils sont incapable de gérer les ambulances autrement que par téléphone, provoquant certainement déjà plusieurs décès faute d'ambulance arrivée dans les temps.

Un logiciel "supporté", c'est pas seulement un éditeur qui corrige des bugs et répond au téléphone : c'est aussi ded failles de sécurité corrigées : la faille utilisée ici et connue et corrigée par Microsoft sur ses logiciels supportés depuis plus de 2 mois... Mais certainement pas Windows 2000 ou 2003 (ni même 2008 il me semble).

Pour le coup, nombreux sont les DSI et techniciens qui vont pointer au chômage d'ici la fin de semaine...