Discussion :

[ldujard]

Bonjour,

Je suis arrivé il y a peu de temps en temps que DBA au sein d'une société qui avait besoin de quelqu'un pour remettre de l'ordre dans leurs BDDs qui en ont grandement besoin
Un petit florilège des pratiques très ancrées dans la culture et que je vais devoir faire changer

• Pas de dimensionnement Bases, Log, TempDB, ...
• Des tables temporaires (sans jamais de PK) par dizaines dans les prosto pour "aller plus vite"
• Des tables physiques sans PK deleté ou dropé chaque jour pour des process analytiques
• Des index jamais defragmenté,
• Les stats pas à jour
• Une requête est un peu longue ?? Pas de problème on reboote !!

Bref, je ne m'ennuie pas !!

J'en viens aux derniers problèmes en date, l'utilisation des synonymes :
Un dev m'a contacté pour une requête delete qui mets un temps fou alors qu'il n'y a aucune ligne à supprimer. Ma première idée était un problème au niveau des index, mais en faites quand il m'a dit qu'en remplaçant le synonyme par le nom complet la requête répondait instantanément, je n'ai pas su quoi lui répondre.

En fouillant un peu, j'ai finit par découvrir une totale aberration, la requête est exécutée sur le SERVEUR1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
USE BDD1
 
/* Cette requête ne répond pas */
DELETE FROM synonym_table2 WHERE champ1 = 'toto'
 
/* En regardant le chemin complet du synonyme je me suis aperçu qu'il pointant sur le même serveur, la même base, mais une table différente */
 
/* Et celle-ci est instantanée */
DELETE FROM SERVEUR1.BDD1.dbo.table2 WHERE champ1 = 'toto'

J'ai donc dit d'arrêter d'utiliser les synonymes pour ce genre de cas, seulement, pour ma culture personnelle, j'aimerai bien savoir si quelqu'un avait une explication à ce phénomène que je ne comprends pas.

MErci d'avance !

[escartefigue]

/* En regardant le chemin complet du synonyme je me suis aperçu qu'il pointant sur le même serveur, la même base, mais une table différente */

Si on crée un synonyme en se trompant de table ciblée, il est évident que la durée du DELETE est potentiellement différente, la table ciblée pouvant contenir des milliards de lignes alors que la table souhaitée n'en contenait que quelques unes...
Je ne vois aucun mystère la dedans.

[ldujard]

Oups désolé !! Si je dis des bétises, moi aussi, c'est normal que je ne puisse pas avoir la réponse attendue !!

synonym_table2 = SERVEUR1.BDD1.dbo.table2

Donc le DELETE se fait bien sur la même table.

[SQLpro]

N'y aurais t-il pas un serveur lié sur lui même ?

A +

[ldujard]

C'est ce que je croyais aussi mais non.

[Michel.Priori]

Bonjour,

Le premier réflexe quand on note une anomalie lors de l'exécution d'une requête est de sortir le plan d'exécution.
donc ma première question est :

Est-ce que les plans d'exécutions sont effectivement identiques ?

J'ai eu un cas rapprochant : la même procédure prenait plus ou moins de temps en fonction de l'utilisateur.
la réponse a été un mixte de :

1. contexte de connexion : pas la même base définie dans le login
2. définition de l'utilisateur : schéma par défaut
3. sécurité : ensemble de propriétaires différents

Pour notre gouverne :
Quelle est la version & édition de SQL ? ([edit] : faudrait que j'apprenne à lire le sujet ! c'est du 2008R2. Est-ce en version Express ?)
Est-ce que le problème est reproductible avec la même table mais dans une base "neuve" ?

[ldujard]

Bonjour,

Le problème c'est que pour la requête utilisant les synonymes le plan d'exécution ne s'affiche pas. Elle tourne sans cesse et ne se finit pas (je l'ai laissé tourné plus de 10 minutes). Même le plan d'exécution estimé ne vient pas.

C'est un 2008R2 Edition Standard.

Je n'ai pas faits le test sur une BDD "neuve".