Optimisation de requete sql
Bonjour
C'est ma première demande....
J'ai un souci de performance avec cette requête stockée.
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
|
BEGIN
DECLARE RROL CHARACTER(20);
DECLARE RART CHARACTER(12);
DECLARE SQLCODE INTEGER DEFAULT 0;
DECLARE REC CURSOR FOR
SELECT ID_FACTURE, ID_ARTICLE
FROM DBPROD.T_ARCHIVES
WHERE AA_DATARCH is null ;
OPEN REC;
FETCH NEXT FROM REC INTO RROL, RART;
label0 : WHILE ( SQLCODE=0 ) DO
/*==== Archivage */
/* T_HISTACTU */
INSERT INTO DBARCHIVE.T_HISTACTU
( SELECT * FROM DBPROD.T_HISTACTU WHERE OID_OPERA IN (
SELECT OID_OPERA FROM DBPROD.TJ_POURS WHERE ID_FACTURE = RROL AND ID_ARTICLE = RART ) ) ;
/*==== Suppression */
/* T_HISTACTU */
DELETE FROM DBPROD.T_HISTACTU WHERE OID_OPERA IN (
SELECT OID_OPERA FROM DBPROD.TJ_POURS WHERE ID_FACTURE = RROL AND ID_ARTICLE = RART ) ;
FETCH NEXT FROM REC INTO RROL, RART;
END WHILE label0 ;
CLOSE REC; |
Il s'agit de déplacer des rows d'une table vers une table identique mais dans une base d'archives. Les rows insérées dans la table de la base archives viennent de la table production d'où elles sont retirées immédiatement après par delete.
Le tout tourne sous db2 et iserie 520 avec version OS 5.4. Cette requête dure en moyenne 8 heures. En mettant un index sur la table C, je suis descendu a 5 heures mais je trouve que cela fait encore beaucoup.
Ce n'est pas moi qui ait développé ces requêtes mais je les "récupère" suite à un départ. Je ne suis pas un cador en SQL. Merci aux bonne volontés de m'orienter vers certaines pistes (si c'est possible) pour tenter d'améliorer les temps d'exploitation. Là je sèche un peu. Les tables ne sont pas énormes TABLE A = 75400 et TABLEC=320000
Optimisation de requete sql
Bonjour
D'abord merci pour toutes ces réponses. J'ai plusieurs piste à explorer semble-t-il
Pour répondre au diverses questions
@punkoff
Citation:
As-tu pu identifier la partie de ta procédure qui étaient la plus longue ? (DBMON)
Sur les 8 heures les deletes durent 4h50 et les inserts 3h30 (index advisor). Pour DBMON faut que je regarde comment m'en servir
Citation:
Sinon pourrai-tu indiquer précisément les index en place sur tes tables?
Il n'y avait aucun index au départ, j'en ai créé un sur la table C pour arriver à 5h.Il a été créé sur ID_FACTURE, ID_ARTICLE et OID_OPERA
Citation:
Et enfin quand tu passe cette proc-stock es-tu en concurrence avec d'autre process ?
Pas de concurrence Le traitement passe la nuit avec le TP fermé et bien après les batchs quotidiens. C'est une petite base de 1,8G
Citation:
Qu'appel-tu table A et table C sachant que tu as 3 tables distincts ?
Table A = T_HISTACTU, Table C = TJ_POURS T_ARCHIVES serait la table B. Je me suis mal exprimé sur ce coup là
Citation:
- Est-ce normal que tu n'update pas la date d'archivage dans T_ARCHIVES apres ton process ?
Si il y a bien un update de cette date après le traitement. En fait je n'ai présenté qu'un petit bout de la procédure car elle concerne beaucoup plus de tables mais toujours sur le même principe. J'ai donc fait tourner un extrait pour voir ce que ça donnait.
Citation:
- Une étape d'archivage va bouger en gros combien de % de lignes de table de prod ?
Ca concerne environ 10% de la table
@KR2400
Merci pour ton aide, je vais examiner cela de plus près. Je un peu de temps vu que le traitement passe 1 fois par an.Et que je suis seul sur le coup.
@pdz74
Je précise que les tables ne sont pas journalisées. Est-ce la solution avec trigger reste valable.Je vais étudier cela aussi.
A tous, c'est bon de savoir qu'on est pas tout seul :ccool:. merci. Je vais faire mes tests et reviendrai vers vous dans quelques temps
