Discussion :

[Donpi]

Bonjour,

Voilà, nous avons eu une grosse maintenance au niveau de notre gestion des prix.
Sur le principe, il n y a rien a signaler, en revanche, je dois maintenant créer les relations ventes prix rétroactivement sur les 30 dernière années.

Si je lance ma requête d'update j'ai estimer à ~80 jours de travail non stop en me basant sur le traitement de 50'000 records.
C'est bien évidement inenvisageable d'avoir une requête bloquante qui tourne pendant 80 jours (même 30 secondes en journée c'est trop).

Du coup j'ai fais une mesure en désactivant tous les triggers on update de cette table. Là je descend à ~6 jours.

Pour réglé le problème du blocage j’exécute des requêtes successives qui durent entre 2 et 4 secondes dans une séries de job du SQL Agent.
Je n'ai malheureusement qu'un créneau de 4h par nuit ou je suis certains de pouvoir coupé les triggers sans risque.

Je me demande donc si en englobant l'activation et la désactivation des trigger dans une même transaction, mon système restera fiable ?
J'imagine une requête du genre :

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
begin transaction T1;
disable trigger [Trigger1] on [La table des ventes];
disable trigger [Trigger2] on [La table des ventes];
 
WITH V AS (SELECT top 1000 IdVente,Ref,IdPrix from [La table des ventes]WHERE IdPrix is null)
Update V SET V.IdPrix=Px.IdPrix
FROM V
left JOIN [Le nouveau prix] P on P.Ref=V.Ref;
 
enable trigger [Trigger1] on [La table des ventes];
enable trigger [Trigger2] on [La table des ventes];
 
commit Transaction T1;
 
GO 10000;

[Bernardos]

Bonjour,

• que font les trigger?
• le top 1000 il est là pourquoi?
• est ce qu'on pourrait avoir les scripts ddl des 2 tables(pk et fk incluses)?
• AS tu des index, si oui lesquels?

cordialement,

[Donpi]

Bonjour,

• que font les trigger?
• le top 1000 il est là pourquoi?
• est ce qu'on pourrait avoir les scripts ddl des 2 tables(pk et fk incluses)?
• AS tu des index, si oui lesquels?

cordialement,

Bonjour,
dans l'ordre :

Les triggers maintiennent une table de stock et une table d'erreurs de prix
Le top 10000 est est utiliser pour subdiviser ma requête en plusieurs itérations afin d'éviter un blocage trop long.
Malheureusement la politique de ma société m’interdit de communiquer ce genre d'information.
Sans trop en dire, j'ai plusieurs indexes sur les références ainsi qu'un index sur IdPrix

Je sais, ça aide pas beaucoup...

[aieeeuuuuu]

Bonjour,

Attention, les performances d'une BDD ne sont pas linéaires : une requete mettant à jour toute une table ne mettra probablement pas deux fois plus de temps que la même requete qui mets à jour la moitié de la table. Comment avez vous fait vos calculs ? et surtout combien de milliards de lignes avez vous dans vos tables pour en arriver à de telles durées ?

Outre les triggers, les index peuvent ralentir la mises à jour (ou les accélérer dans certains cas, s'ils sont utiles à la requete de MAJ). Il pourrait donc être utile de faire le point sur les index sur ces tables et en désactiver certains le temps de la mise à jour. Pensez également aux vues indexées (voir les dépendances sur la table concernée pour être exhaustif)

Ne pouvez vous pas anonymiser les noms des objets pour nous fournir les DDL ? Connaitre la structure des deux tables et les index est indispensable pour vous aider efficacement.

[François DORIN]

Bonjour,

Il serait effectivement intéressant d'avoir une information sur la volumétrie. Cela permettra de se faire une idée des problèmes de performances : est-ce que le traitement est long parce qu'il y a une énorme volumétrie, ou est-ce qu'il est long car les requêtes sont lentes (trop d'index à mettre à jour, ou index manquant si, comme le signalait aieeeuuuuu ils peuvent être utile lors de la mise à jour, les triggers (qui dans votre cas particulier multiplie par 10 vos temps de traitement), mauvais schéma, etc...).

Par exemple, vous avez fait une extrapolation à partir du traitement de 50000 enregistrements. Combien de temps cela vous a-t-il pris ?

Ensuite, je ne peux qu'approuver encore une fois ce que dis aieeeuuuuu, à savoir que le traitement n'est pas linéaire. Eventuellement, auriez-vous une base de tests sur laquelle vous pourriez faire des essais ?

[Bernardos]

Malheureusement la politique de ma société m’interdit de communiquer ce genre d'information.

compréhensible, mais du coup ca va être plus dur pour t'aider.

Ne pouvez vous pas anonymiser les noms des objets pour nous fournir les DDL ? Connaitre la structure des deux tables et les index est indispensable pour vous aider efficacement.

ce serait une excellente idée! nous n'avons pas besoin de toutes les colonnes, juste celles utilisées par ta requête,participant à une clé primaire ou étrangère, et celles liées aux index . et du coup index, Clés primaires et clé étrangères.

Ce qu'ont veut pouvoir analyser :

• Manque de clés primaires
• Mauvaises clés primaires
• Manque de clés étrangère
• une éventuelle sous indexation
• une éventuelle sur indexation

Cordialement,

[Donpi]

Re,

C'est toujours compliqué de donner suffisamment d'information pour avoir de l'aide et rester dans le clous de ce qu'on a le droit de dire.

Il faut imaginé que tout ce qui peut être fait comme erreur (de schèma, de concepte, de designe, etc... ) ont été faite... plusieurs fois... pendant 20 ans..
La on essai de redresser un peu la barre dans la limite du réalisable pour notre structure.

La table de ventes contient ~60 millions de lignes, la table de prix ~3 millions.
Mon problème de triggers est qu'ils sont cascader. On traine plusieurs années de développement hasardeux.

Jusqu’à présent les prix étaient séparer des ventes et le seul moyen de retrouver le prix était de sélectionner le prix le plus récent pour chaque référence.
Ce qui rend les requêtes statistiques complexes et peu fiables car les dates peuvent changer etc...
Du coup j'ai profiter du projet de refonte des prix pour avoir une vrai relation entre la vente et le prix.

Dans la requête d'exemple il manque des bout dans la jointure qui la rendent forcément compliqué et lente.
La requête global serait du genre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
begin transaction T1;
disable trigger [Trigger1] on [La table des ventes];
disable trigger [Trigger2] on [La table des ventes];
 
Update V SET V.IdPrix=Px.IdPrix
FROM [La table des ventes] AS V
left JOIN [Le nouveau prix] AS P on P.Ref=V.Ref AND V.dtVente between P.DateDebut and P.dateFin AND P.TypeDuPrix = CASE [trois clauses] END
WHERE V.IdPrix is null
 
enable trigger [Trigger1] on [La table des ventes];
enable trigger [Trigger2] on [La table des ventes];
 
commit Transaction T1;

Je n'ai pas pu tester l'Update complet sur un environnement de test car cela sature le fichier de LOG.
Au bout de 18h le système plante et entame un rollback.
Mon test sur 50000 lignes à mis ~4.5 minutes.
(cependant je n'ai pas tester la totalité sans les trigger, ça tourne en ce moment même en test)

J'ai des clé primaires simples dans mes deux tables.
J'ai un index dans la table des ventes sur IdPrix.
Un dans le table des prix sur Ref,DateDebut et datefin.
Mes deux tables ont d'autres indexes sans importance dans ce contexte.

Et les trigger contiennent tous des curseurs ce qui ralentis à mort raison pour laquelle je les désactive.

A+