Discussion :

[hatman-UTC]

Bonjour,

Je travaille actuellement sur une base de données SQL Server 2008 contenant différentes données. Cette base contient entre autre des objets complexes sous la forme suivante :
- une table contient les caractéristiques basiques de l'objet (nom, type, etc..)
- six autres tables contiennent les éléments susceptibles d'être contenus dans l'objet complexe (une table contenant tous les éléments de type A, une autre tous les éléments de types B, etc...)
- enfin, six tables de jointure font le lien entre l'objet complexe et les éléments qu'il contient

Ces 13 tables permettent donc de savoir qu'un objet complexe X contient 10 éléments A, 50 éléments B, etc...

J'ai mis en place une procédure stockée permettant de supprimer un objet complexe. Cette procédure va donc supprimer l'objet et va aussi effectuer un nettoyage dans les tables d'éléments et les tables de jointures. Les références vont être supprimées des tables de jointures et les éléments n'étant contenus que dans l'objet X que l'on cherche à supprimer le seront également. Les éléments partagés par un objet X et un objet Y resteront dans la base jusqu'à ce que l'objet Y soit supprimé à son tour.

J'ai également mis en places des procédures permettant d'insérer facilement dans la base de nouveaux objets.

J'ai expérimentés différents scénarios et j'avoue que certains d'entre eux me laissent perplexes :
- lorsque je supprime à l'aide de ma procédure un objet X de la base puis un objet Y, la procédure s'exécute à chaque fois en 1s.
- lorsque je supprime à l'aide de ma procédure un objet X, que je le réinsère, puis que je supprime un objet Y, la procédure de suppression s'exécute à chaque fois en 1s.
- lorsque je supprime à l'aide de ma procédure un objet X, que je le réinsère, puis que je supprime à nouveau cet objet X, la procédure de suppression s'exécute cette fois-ci durant un laps de temps compris entre 1 et 4mn !

J'avoue ne pas comprendre cette lenteur soudaine. J'ai tenté de laisser "souffler" le serveur entre ma suppression/insertion et ma nouvelle suppression, rien n'y a fait. Reconstruire les index n'a rien changé non plus. Auriez-vous une idée de ce qui pourrait être la cause de ce ralentissement soudain ?

Merci d'avance pour votre aide
Cdlt

Hatman

[kagemaru]

bonjour,

il faudrait poster le code et la structure des tables si possible. A vue de nez, ces lenteurs pourraient venir du fait que les index clustered doivent être ordonnés lors de cette réinsertion (si le même identifiant est conservé).... mais c'est difficile sans idée précise de votre situation.

merci

[hatman-UTC]

Bonjour,

Je ne peux malheureusement pas poster le schéma de ma base en elle même car il contient des informations confidentielles. Voici un schéma "type" s'en approchant :

Différents type d'éléments existent, chacun contenus dans une table les jointure se faisant par le biais de tables de jointure comme sur le schéma. Votre remarque sur les index me semble pertinente mais j'avoue ne pas être spécialisé en SGBD (mon profil est plus "générique"). Mes tables utilisent quasiment toutes des clefs artificielles donc les mêmes identifiants ne sont pas réutilisés. J'ai par contre des index autres que ceux de clefs primaires sur certaines tables. Par exemple, sur la table ElementB, j'ai ajouté un index (non unique, non cluster) sur les champs Name & Number. J'ai également sur chaque clef des index cluster (mis en place automatiquement par le système).

J'ai essayé, entre la ré-insertion et la seconde suppression, de reconstruire les index de mes tables à l'aide d'instructions du type

Code :

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

1
2
ALTER INDEX ALL ON ElementA
REBUILD;

mais cela n'a changé en rien ma lenteur d'exécution.
Ma procédure de suppression a donc pour but de supprimer un ObjetComplex de la base, de supprimer toutes les informations de jointure et de supprimer des tables d'éléments, les éléments qui n'étaient contenus que dans l'Objetcomplex que l'on supprime. Les éléments contenus à la fois dans une Objet A et un Objet B ne doivent bien entendu pas être supprimées lorsque l'on supprime A mais pas B. La procédure de suppression utilise des tables temporaire pour stocker des informations à supprimer du type :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
IF OBJECT_ID(N'tempdb..#ElementB', N'U') IS NOT NULL 
		DROP TABLE #ElementB;
 
		SELECT Oe.ElementBKey
		INTO #ElementB
		FROM JoinObjetComplexElementB AS Oe
		WHERE NOT EXISTS (
			SELECT o.ObjetComplexKey
			FROM JoinObjetComplexElementB AS 0
			WHERE o.ObjetComplexKey <> @ClefDeLobjetASupprimer AND o.ElementBKey= Oe.ElementBKey
		)
 
		DELETE FROM JoinObjetComplexElementB 
		WHERE ElementBKey IN (
			SELECT ElementBKey
			FROM #ElementB
		)
 
		DELETE FROM ElementB
		WHERE ElementBKey IN (
			SELECT ElementBKey
			FROM #ElementB
		)

mais il ne me semble pas que la lenteur provienne de ces tables puisque lorsque je supprime à la suite deux Objets Complexes différents, l'exécution se passe rapidement.

Cela vous éclaire t-il ? Comment puis améliorer mes index ? J'avoue que la notion de cluster/non-cluster/XML Primaire/Spatial m'est quelque peu absconse. Je vais essayer de me renseigner de mon coté mais si vous pouviez m'éclairer...

Merci d'avance pour votre temps et votre aide,
cdlt

Hatman

[Sergejack]

Pourquoi ne pas employer ON DELETE CASCADE sur ces différentes table liés par des clés étrangères ?

[hatman-UTC]

Effectivement, je pourrais mettre en place des ON DELETE CASCADE sur les tables d'éléments afin d'éviter l'utilisation des tables temporaires. Cela permettra t-il d'éviter les ralentissements ? Je vais tester cette solution.

[hatman-UTC]

J'ai mis en place des ON DELETE CASCADE sur toutes les tables concernées, ai pu donc supprimer les tables temporaires de ma procédure, mais le problème persiste quand même avec ma nouvelle procédure ! Si quelqu'un à une piste, je suis preneur !
Merci

Hatman