[SYBASE ASE 12.5.3] Triggers & performances

[lsone]

Bonjour,

J'explique un peu le contexte, j'ai réalisé une chaîne de traitement (korn shell / transact sql) pour éditer des statistiques téléphoniques (durée d'appel, temps d'attente, etc ...).
Les tables à partir desquelles je m'appuie pour faire ces statistiques, sont alimentées par un bandeau téléphonique développé par une société externe.
Ce bandeau s'appuie sur des serveurs de téléphonie CTI et SVI.

Deux tables sont alimentées par ce bandeau :
- une table stocke le début et la fin de connexion (TLM_CNX),
- une autre table stocke les activitées (TLM_ACTIVITE) entre le début et la fin de connexion.

Les enregistrements de date sont basés sur l'horloge des serveurs CTI et SVI, non sur le serveur ASE.
Et si les serveurs CTI et SVI on un décalage d'horloge mes statistiques sont fausses et erronées.
Pour palier à ce problème et en attendant de régler le problème de fond, j'ai ajouté des colonnes et posé des triggers.

Le problème est que les performances ont chutées.

Mes questions sont les suivantes :
- Le code de mes triggers est il correct ?
- Est ce que le fait de créer un trigger qui modifie des données dans la table sur laquelle il est basé, n'est pas la cause des mauvaises performances ?
- Faut il modifier le schéma de lock ? Passer en DOL ?

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
 
 
/*
** Création de la table TLM_CNX
** Structure de table sans ajout des colonnes et des triggers
*/
 
CREATE TABLE TLM_CNX (
CNX_ID char(13) NOT NULL
, CNX_DATDEB datetime NULL
, CNX_DATFIN datetime NULL
, CNX_SDA char(20) NULL
, CNX_NUMAPP char(20) NULL
, CNX_CONTRAT int NULL
, CNX_REFCALL varchar(10) NULL
, TR_CNX_DATEBEGIN datetime NULL
, TR_CNX_DATEEND datetime NULL
, TR_CNX_ID numeric(18,0) identity
)
go
 
ALTER TABLE TLM_CNX
ADD constraint TLM_CNX PRIMARY KEY nonclustered (CNX_ID)
go
 
/*
** Création de la table TLM_ACTIVITE
** Structure de table sans ajout des colonnes et des triggers
*/
 
CREATE TABLE TLM_ACTIVITE (
ACT_NUMORD int NOT NULL
, ACT_HDATE datetime NOT NULL
, ACT_NUMTEL char(20) NULL
, ACT_DOSID int NULL
, ACT_TYPID int NULL
, ACT_NUMPST char(5) NULL
, ACT_DATDEB datetime NULL
, ACT_USRID char(5) NOT NULL
, ACT_IDCNX char(13) NULL
, ACT_REFCALL varchar(10) NULL
, ACT_NUMCALL1 char(20) NULL
, ACT_NUMCALL2 char(20) NULL
, ACT_NUMCALL3 char(20) NULL
, ACT_NUMCALL4 char(20) NULL
, ACT_NUMCALL5 char(20) NULL
, ACT_NUMCALL6 char(20) NULL
, ACT_NUMCALL7 char(20) NULL
, TR_ACT_DATE datetime NULL
, TR_ACT_ID numeric(18,0) identity
)
go
 
ALTER TABLE TLM_ACTIVITE
ADD constraint ACTIVITE_FK1 FOREIGN KEY (ACT_TYPID) REFERENCES TLM_OPERATION
go
 
CREATE nonclustered INDEX TLM_ACT_IDX1
ON TLM_ACTIVITE (ACT_NUMPST , ACT_DATDEB , ACT_NUMORD)
go
 
/*
** Création du trigger sur TLM_CNX
** Sur insert mise à jour TR_CNX_DATEBEGIN avec getdate()
*/
 
CREATE TRIGGER trg_i_tlmcnx
ON TLM_CNX
FOR INSERT
AS
 
declare @num_rows int
SELECT @num_rows=@@rowcount
IF @num_rows=0
   RETURN
 
-- Sur insert mise à jour TR_CNX_DATEBEGIN avec getdate()
 
UPDATE TLM_CNX SET TR_CNX_DATEBEGIN=getdate() FROM TLM_CNX t, inserted i WHERE t.TR_CNX_ID=i.TR_CNX_ID
 
RETURN
go
 
/*
** Création du trigger sur TLM_CNX
** Sur update mise à jour TR_CNX_DATEEND avec getdate()
*/
 
CREATE TRIGGER trg_u_tlmcnx
ON TLM_CNX
FOR UPDATE
AS
 
declare @num_rows int
SELECT @num_rows=@@rowcount
IF @num_rows=0
   RETURN
 
-- Sur update mise à jour TR_CNX_DATEEND avec getdate()
 
IF UPDATE( CNX_DATFIN )
   begin
      UPDATE TLM_CNX SET TR_CNX_DATEEND=getdate() FROM TLM_CNX t, inserted i WHERE t.TR_CNX_ID=i.TR_CNX_ID
      RETURN
   end
 
RETURN
go
 
/*
** Création du trigger sur TLM_ACTIVITE
** Sur insert mise à jour TR_ACT_DATE avec getdate()
*/
 
CREATE TRIGGER trg_i_tlmactivite
ON TLM_ACTIVITE
FOR INSERT
AS
 
declare @num_rows int
SELECT @num_rows=@@rowcount
IF @num_rows=0
   RETURN
 
-- Sur insert mise à jour TR_ACT_DATE avec getdate()
 
UPDATE TLM_ACTIVITE SET TR_ACT_DATE=getdate() FROM TLM_ACTIVITE t, inserted i WHERE t.TR_ACT_ID=i.TR_ACT_ID
 
RETURN
go

[mpeppler]

A priori le code des triggers semble correcte. Evidemment ces updates ajoutent des IOs lors des insert et update, en particulier si il y a beaucoup d'insert ou d'update par batch.
Si c'était possible je pense que j'ajouterai un colonne (p.ex. systemdate datetime default getdate()) qui pourrait être utilisée comme valeur de référence pour chaque enregistrement, permettant le calcul des heures de début et fin ajustées pour l'horloge du dataserver.

L'utilisation du mode DOL n'a probablement pas d'influence sur les perfs dans ce cas (bien que cela devrait être confirmé.)

Michael

[lsone]

Je n'avais pas pensé au default sur un champ.
Merci beaucoup.

[Gauthde]

Bonjour,


Dans ton cas, je referais un calcule des statistiques (update all statistics) des tables modifiées (il me semble que tu as ajouté une colonne). Je pense que ça t'apportera un gain (à condition que tu ais un nombre de ligne > à 100 si mes souvenirs sont bons)

En suite au sujet du passage en datarow, tout dépend des contentions que tu pourrais constater sur tes objets et du nombre d'écriture (ou toute autre activité transactionnelle) sur une même page de data ou d'indexe. Je suis assez partisan (dans les versions 12/12.5) du tout datarow quand on commence à parler de base dont l'activité TP est soutenue. Si tu fais un monitoring (sp_sysmon, pour plus de détail monitor/historical server ou les tables derived stat ase 12.5.3) tu auras les informations nécessaire qui pourront t'orienté dans tes choix. Dans tout les cas si tu passes en datarows, n'oublie pas de recréer tout tes trigger et de faire un sp_recompile sur les tables.

[Gauthde]

oups, mauvaise manip

[lsone]

Envoyé par Gauthde

Bonjour,


Dans ton cas, je referais un calcule des statistiques (update all statistics) des tables modifiées (il me semble que tu as ajouté une colonne). Je pense que ça t'apportera un gain (à condition que tu ais un nombre de ligne > à 100 si mes souvenirs sont bons)

En suite au sujet du passage en datarow, tout dépend des contentions que tu pourrais constater sur tes objets et du nombre d'écriture (ou toute autre activité transactionnelle) sur une même page de data ou d'indexe. Je suis assez partisan (dans les versions 12/12.5) du tout datarow quand on commence à parler de base dont l'activité TP est soutenue. Si tu fais un monitoring (sp_sysmon, pour plus de détail monitor/historical server ou les tables derived stat ase 12.5.3) tu auras les informations nécessaire qui pourront t'orienté dans tes choix. Dans tout les cas si tu passes en datarows, n'oublie pas de recréer tout tes trigger et de faire un sp_recompile sur les tables.

Merci je vais regarder tout ça.

[lsone]

merci à vous deux pour ces précieux conseils !

[mpeppler]

J'éviterais le "update ALL statistics" - cela calcul des stats sur TOUTES les colonnes de la table, ce qui peut prendre très longtemps, et ce qui n'est pas nécessairement très utile pour l'optimiseur.

Par contre, le "update index statistics" est recommandé, puisque cela calcul les stats sur toutes les colonnes qui composent les indexes.

Michael

[Gauthde]

Envoyé par mpeppler

J'éviterais le "update ALL statistics" - cela calcul des stats sur TOUTES les colonnes de la table, ce qui peut prendre très longtemps, et ce qui n'est pas nécessairement très utile pour l'optimiseur.

Par contre, le "update index statistics" est recommandé, puisque cela calcul les stats sur toutes les colonnes qui composent les indexes.

Michael

Je suis assez d'accord avec toi, bien que le all stat est assez intéressant pour initialiser et un ensuite consolider avec par exemple un "update index stat" selon l'activité et la volumétrie.

Dans l'enthousiasme je me suis emporté

[lsone]

Envoyé par mpeppler

J'éviterais le "update ALL statistics" - cela calcul des stats sur TOUTES les colonnes de la table, ce qui peut prendre très longtemps, et ce qui n'est pas nécessairement très utile pour l'optimiseur.

Par contre, le "update index statistics" est recommandé, puisque cela calcul les stats sur toutes les colonnes qui composent les indexes.

Michael

Effectivement j'ai privilégié update index statistics.

Merci encore une fois.