Impact du déclencheur sur la base tempdb

bonjour a tous

Suite a un état de saturation que j'aurai sur mes partitions data et suite au augmentation du taille de ma database "insertion des data de type image" j'utilise un déclencheur DML qui permet de me faire une suppression sur les données qui sont anciennes de plus qu'un mois pour cela j'utilise ce trigger

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO   CREATE TRIGGER dbo.SuppressionData ON dbo.feature AFTER INSERT AS BEGIN     delete   FROM Feature   WHERE Feature.Location_ID in (select location.location_id from location where Location.Inspection_end_time < CONVERT(DATETIME, getdate()-30, 102))     delete from location where Location.Inspection_end_time < CONVERT(DATETIME, getdate()-30, 102) SET NOCOUNT ON;     END GO

---

En premier lieu est ce que le syntaxe de mon déclencheur est juste ????
aussi est ce que je suis dans le bon chemin d'analyse si j'utilise ce trigger pour minimiser la taille de la base surtout que la table "Location" est la table le plus volumineux
Est ce que je doit faire un DBCC shrinkdatbase en parralléle avec le déclencheur lancer sur ma base pour gagner d'espace ??? y 'a t'il impact sur la base tempdb???

Oh que voila un code bien pourri !

Voici une correction....

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

CREATE TRIGGER dbo.SuppressionData ON dbo.feature AFTER INSERT AS BEGIN   SET NOCOUNT ON;   DELETE FROM F FROM dbo.Feature AS F INNER JOIN location AS L ON F.Location_ID = L.location_id WHERE L.Inspection_end_time < DATEADD(day, -30, getdate());   DELETE FROM dbo.location WHERE Inspection_end_time < DATEADD(day, -30, getdate());   END GO

---

1) utilisez les schémas sQL pour préfixer vos objets
2) utilisez DATEADD pour ajouter des intervalles (ici nombre de jours à vos dates)
3) utilisez des alias pour vos tables en jointure
4) placez le SEt NOCOUNT ON en première instruction
5) évitez le IN lorsque l'on peut faire une jointure
6) et le pire... une date étant un type de données, le convertir avec convert en chaine est absurde car il devra être reconvertit en date implicitement, donc deux conversions inutiles...

Bref, formez-vous au langage SQL. Mon site web, comme mon livre peut vous être utile !

A +

Citation:

---

Envoyé par SQLpro

Oh que voila un code bien pourri !

Voici une correction....

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

CREATE TRIGGER dbo.SuppressionData ON dbo.feature AFTER INSERT AS BEGIN   SET NOCOUNT ON;   DELETE FROM F FROM dbo.Feature AS F INNER JOIN location AS L ON F.Location_ID = L.location_id WHERE L.Inspection_end_time < DATEADD(day, -30, getdate());   DELETE FROM dbo.location WHERE Inspection_end_time < DATEADD(day, -30, getdate());   END GO

---

A +

---

est il nécessaire de faire après un "DBCC shrinckdatbase" pour gagner d'espace physique car ce ci c'est le but
pour la base il est en mode récupération simple
autre point y'aura t'il d'impact sur la base tempdb ??? si la base il du grand taille et la command "DBCC shrinckdatbase" prend beaucoup du temps
et merci pour vos conseil

SHRINK DATABASE peut faire gagner de la place au niveau physique, à condition que vos données soient défragmentées.
Avant il faut donc les défragmenter....

Et réduire les fichier par un SHRINK est le meilleur moyen de pourrir les performances....

A +

Citation:

---

Envoyé par SQLpro

SHRINK DATABASE peut faire gagner de la place au niveau physique, à condition que vos données soient défragmentées.
Avant il faut donc les défragmenter....

Et réduire les fichier par un SHRINK est le meilleur moyen de pourrir les performances....

A +

---

ok merci

par comptre au moment ou j'ai lancer la Command DBCC SHRINKFILE le log du base tempdb a atteint un état de saturation de 99%

peut il en parallèle shrinker tempdb ou c'est pas nécessaire je compléter mon travaille et il y 'aura plus d'impact

pour info j'ai annuler le travaille au moment ou j'ai constaté que le log du tempdb a atteint la valeur 99%

En tant que bonne pratique n°1, il faut dimensionner correctement vos espaces de stockages des bases de production et de la tempdb, de manière à avoir :

• aucune opération de croissance de fichier durant toute la durée d'exploitation de la base
• suffisamment de place sur les disques pour éviter d'utiliser un SHRINK.

A lire sur le sujet :
http://blog.developpez.com/sqlpro/p5..._fichiers_et_t
http://blog.developpez.com/sqlpro/p8...et_le_stocakge

A +

Afin de minimiser l’impact de la suppression sur le log est il possible d'utiliser dans le code transact du supression l'option

Code:

---

WAITFOR DELAY '00: 00: 01 '

---

pour arrêter la suppression afin d'assurer en parallèle un backup faite sur le fichier log surtout que mon database est en mode recovry full
cordialement