Job trop lent [Résolu]

[wissem.ba]

Bonjour à tous,

J'ai créé un job job1 comme suit :

tOracleInput_1 -----------> tMap_1 -------------> tOracleOutput_2

Le tOracleInput_1 se connecte à une table T1 d'une base B1 (via le contexte) et ramène des données avec une requête select simple (sans jointure)

tOracleOutput_2 se connecte à une table T2 d'une base B2 (via le contexte) et y insère ce que le tOracleInput_1 a ramené comme lignes et ce via le tMap_1 simple (de colonne à colonne)

Ce job prend énormément de temps (50 minutes parfois) alors qu'il traite au plus 2000 lignes


J'ai créé un autre job similaire au premier mais qui se connecte à d'autres Tables, ce job ne prend qu'une seconde pourtant il traite le même nombre de lignes

Avez-vous une idée pourquoi le premier prend du temps ?

Je vous remercie

[DevNico]

Bonjour,

Dans un premier temps je ferais le test de remplacer le tOracleOutput par un tFileOutputDelimited, afin d'identifier si le problème vient bien de l'insertion dans la base.

Nicolas

[wissem.ba]

Je te remercie.

On m'a parlé de tOracleOutputBulk mais comme je suis débutant je ne sais pas ce que c'est et c'est quoi la différence entre ce composant et le tOracleOutput

[jsd03]

Pour moi le problème ne provient pas de Talend car 2000 lignes en 50 minutes.... mais plutôt d'une mauvaise configuration de tes tables Oracles ou/et des tablespaces. Vérifie la taille des block et des EXTENDS.

Vérifie quand même dans Talend à combien est positionné le Commit dans ton tOracleOutput

[Prjprj]

J'imagine que ton tOracleInput_1 pointe sur une table qui contient pas mal de données et sélectionne celles qu'il veut par l'intermédiaire d'un WHERE <un champ>=[une valeur]

Il est probable que la table sur laquelle tu fais cette requête ne soit pas indexée (ou le soit mais mal).

Essaie d'exécuter la requête SQL contenue dans ton tOracleInput_1 dans un client SQL et donnes nous le temps d'exécution et surtout le plan d'exécution.

Nous pourrons t'indiquer si le problème vient bien de là et te donner quelques pistes pour y remédier.

[jsd03]

Autre axe d'analyse : sur ta table cible : désactive les indexes et voit ce que ça fait

[wissem.ba]

Bonjour à tous,

je n'ai pas abandonné le sujet mais je n'ai pas vu vos réponses.

En fait le job marchait en 2 minutes sur une base B1 mais 2h sur une base B2

Sachant qu'on a fait une restauration de la B2 à partir de B1, autrement B2 doit être une copie conforme de B1, je viens de regarder et certaines tables leurs manque un index que je retrouve dans B1

Exemple :
---------

un tOracleOutput met à jour une table T1 (donc T1 est une table destination)
Dans la B1, T1 avait un index
Dans la B1, T2 n'a pas un index

Pensez-vous que la lenteur vient de là ?

Autre différence entre les 2 tables (destination) :

Le code de l'ancienne table T1 (celle sur laquelle le job est rapide) contient à la fin ce code :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING STORAGE
  (
    INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT
  )
  TABLESPACE "MINTSWF_DAT" ;
CREATE INDEX "MINTSWF"."IDX_ID_TICKET" ON "MINTSWF"."SWFTICKET"
  (
    "ID"
  )
  PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORAGE
  (
    INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT
  )
  TABLESPACE "MINTSWF_IDX" ;

Le code de la nouvelle table T1 (celle sur laquelle le job est lent) ne contient que ça à la fin ce code :

Code :

1
2
3
4
5
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING STORAGE
  (
    INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT
  )
  TABLESPACE "SWFDWHDA_DAT" ;

Est-ce normal ?

Merci

[Prjprj]

Avant de recoder Oracle en cherchant dans des Tablespaces, montres nous les requêtes que tu fais et donnes nous la structure de tes tables (tu peux changer les noms des colonnes si cela pose un problème à tes patrons).

En informatique, comme partout d'ailleurs, pour régler un problème, il faut commencer par le plus simple puis aller vers le plus compliqué.
Donc en premier, tu vérifies si c'est pas un problème de cable
Ensuite tu attaques sur le SQL et la structure de ta base

Et si tout cela ne suffit pas, tu pourras aller bidouiller les config' fines de ta base

[wissem.ba]

Ok,

voila le job en entier

tOracleInput_1 -----------> tMap_1 -------------> tOracleOutput_2

tOracleInput_1 fait appel à un select sans jointure mais avec un where

Code :

SELECT col1, col2, col3 FROM T1 WHERE col1 LIKE '%TICKET%'"

tOracleOutput_2 fait un insert dans une autre table T2

tMap_1 est simple, c'est à dire :

col1 ---> col1
col2 ---> col2
col3 ---> col3

T2 n'a pas d'index.

Qu'est ce que je pourrais donner comme d'autres infos ?

Merci

[DevNico]

Je suis d'accord avec Prjprj.

D'ailleurs :

Envoyé par DevNico

Bonjour,
Dans un premier temps je ferais le test de remplacer le tOracleOutput par un tFileOutputDelimited, afin d'identifier si le problème vient bien de l'insertion dans la base.
Nicolas

[wissem.ba]

Justement je n'ai pas accès à tout.

Pour tout dire je fais transiter des données d'une base à une autre en passant par une base intermédiaire et le job est programmé par une chaine control-M pour qu'il se lance chaque 15 minutes donc je ne peux pas changer les destinations.

Ce que j'ai fait c'est créer un autre job qui fait exactement la même chose et je l'ai testé sur une autre base de test, sur cette base le job prend 2 minutes donc je n'ai pas besoin de remplacer le tOracleOutput par un tFileOutputDelimited puisque c'est rapide.

Merci

[Prjprj]

Envoyé par wissem.ba

Qu'est ce que je pourrais donner comme d'autres infos ?

Combien de lignes dans la table T1?
Combien de lignes avant traitement dans T2? Alimentation en annule et remplace ou en insertion?
La colonne col1 de T1 est-elle indexée? (bien que je crois qu'un LIKE rende inutile l'index)
As-tu un autre moyen d'identifier les lignes de type "TICKET" que via un LIKE?

As-tu essayé d'exécuter la requête SELECT sur la base où tu as des problèmes pour voir combien de temps cela met?
Peux-tu nous donner le plan d'exécution?

[wissem.ba]

Combien de lignes dans la table T1?

--> Cela dépend des heures, parfois le job doit ramener 3 lignes parfois 3000. Mais 3000 ne justifie pas un temps d'exécution de 2 h.

Combien de lignes avant traitement dans T2? Alimentation en annule et remplace ou en insertion?

--> Il ne doit pas y avoir de soucis pour le nombre de lignes puisque j'ai fait un log dans lequel j'ai pu récupérer le nombre de lignes que le tOracleInput_1 a lu et le nombre de lignes que le tOracleOutput_2 a traité et c'est toujours le même. tOracleOutput_2 fait un insert ou update.

La colonne col1 de T1 est-elle indexée? (bien que je crois qu'un LIKE rende inutile l'index)

--> le tOracleInput_1 prend plus qu'une colonne, 30 en tout mais j'ai simplifié par un col1. Aucune colonne n'est indexée

As-tu un autre moyen d'identifier les lignes de type "TICKET" que via un LIKE?

--> C'est une comparaison de chaine de caractère donc je peux mettre un ="TICKET"

As-tu essayé d'exécuter la requête SELECT sur la base où tu as des problèmes pour voir combien de temps cela met?

--> oui et la requête est rapide, je pense que c'est le tOracleOutput_2 qui prend du temps donc dans l'insert et update

Peux-tu nous donner le plan d'exécution?

--> Je n'ai pas compris la question.


Juste une remarque :

J'ai un client qui lance une requête assez compliquée, la requête prend 2 minutes sur l'ancienne version de la base sur laquelle on travailler, on a migré vers une 2eme base B2 et la requête prend 1h30.

J'ai cherché s'il y a une différence entre B1 et B2, j'en ai trouvé plein grâce à Oracle SQL Developper notamment sur les index, je pense que l'origine de la lenteur vient de la config de la base B2 et non du job

Merci

[Prjprj]

Envoyé par wissem.ba

--> Cela dépend des heures, parfois le job doit ramener 3 lignes parfois 3000. Mais 3000 ne justifie pas un temps d'exécution de 2 h.

Ce que je demande c'est la volumétrie totale de la table, pas le nombre de lignes que tu dois ramener avec ta requête.
Si c'est effectivement quelques milliers de lignes au maximum, OK, le problème ne vient pas de là

Envoyé par wissem.ba

Il ne doit pas y avoir de soucis pour le nombre de lignes puisque j'ai fait un log dans lequel j'ai pu récupérer le nombre de lignes que le tOracleInput_1 a lu et le nombre de lignes que le tOracleOutput_2 a traité et c'est toujours le même. tOracleOutput_2 fait un insert ou update.

Quand tu fais un UPDATE, tu modifies des lignes, pour ce faire, Oracle est obligé de chercher les lignes à modifier, il a besoin pour cela de scanner la table (ou des index s'il y en a), si ta table fait des millions de lignes et que tu n'as pas d'index, ton job passera son temps à chercher les lignes à mettre à jour, donc prendra énormément de temps.

Envoyé par wissem.ba

C'est une comparaison de chaine de caractère donc je peux mettre un ="TICKET"

Utilises plutôt un ="TICKET", cela utilise les index, ce qui n'est pas le cas d'un LIKE "%TICKET%"

Envoyé par wissem.ba

oui et la requête est rapide, je pense que c'est le tOracleOutput_2 qui prend du temps donc dans l'insert et update

D'où l'importance de me donner le nombre de lignes dans la table cible...

Envoyé par wissem.ba

Peux-tu nous donner le plan d'exécution?

--> Je n'ai pas compris la question.

Dans SQL-Developer, tu as un bouton "Execute Explain plan (F6)", je veux le résultat (au pire avec une capture d'écran).

Envoyé par wissem.ba

Juste une remarque :

J'ai un client qui lance une requête assez compliquée, la requête prend 2 minutes sur l'ancienne version de la base sur laquelle on travailler, on a migré vers une 2eme base B2 et la requête prend 1h30.

J'ai cherché s'il y a une différence entre B1 et B2, j'en ai trouvé plein grâce à Oracle SQL Developper notamment sur les index, je pense que l'origine de la lenteur vient de la config de la base B2 et non du job

Merci

Les index ne sont pas de la configuration, cela fait partie de la structure d'une base, si les index manquent, il y a de fortes probabilités pour que le problème vienne de cela...

Pour ceux qui ne savent pas ce qu'est un index, pour faire simple, c'est comme l'index d'un bouquin, un index donne, pour chaque "mot" la ou les pages où l'on doit le chercher, ce qui évite de devoir lire tout le bouquin pour retrouver la bonne phrase

[wissem.ba]

Envoyé par Prjprj

Ce que je demande c'est la volumétrie totale de la table, pas le nombre de lignes que tu dois ramener avec ta requête.
Si c'est effectivement quelques milliers de lignes au maximum, OK, le problème ne vient pas de là

450 lignes pour la table cible, 336000 dans la table destination ce qui n'est pas beaucoup quand on fait un select ou insert

Envoyé par Prjprj

Quand tu fais un UPDATE, tu modifies des lignes, pour ce faire, Oracle est obligé de chercher les lignes à modifier, il a besoin pour cela de scanner la table (ou des index s'il y en a), si ta table fait des millions de lignes et que tu n'as pas d'index, ton job passera son temps à chercher les lignes à mettre à jour, donc prendra énormément de temps.

Tout à fait, d'où la nécessité de créer les indexs mais j'imagine qu'il ne faut pas les créer n'importe comment mais suivant des règles

Envoyé par Prjprj

Utilises plutôt un ="TICKET", cela utilise les index, ce qui n'est pas le cas d'un LIKE "%TICKET%"

OK

Envoyé par Prjprj

D'où l'importance de me donner le nombre de lignes dans la table cible...

450 lignes pour la table cible, 336000 dans la table destination

Envoyé par Prjprj

Dans SQL-Developer, tu as un bouton "Execute Explain plan (F6)", je veux le résultat (au pire avec une capture d'écran).

Voilà ce que j'ai
Privilèges insuffisants
Echec de l'accès à V$MYSTAT
Obtenez le privilège de lecture du catalogue de votre administrateur de base de données:
grant SELECT_CATALOG_ROLE to SWFDWHSA
grant SELECT ANY DICTIONARY toSWFDHSA

Envoyé par Prjprj

Les index ne sont pas de la configuration, cela fait partie de la structure d'une base, si les index manquent, il y a de fortes probabilités pour que le problème vienne de cela...

Oui c'est la piste la plus probable que j'ai actuellement parce que je travaille sur une version du job qui a toujours rapidement marché sur l'ancienne base et ce sans que je le modifie

Envoyé par Prjprj

Pour ceux qui ne savent pas ce qu'est un index, pour faire simple, c'est comme l'index d'un bouquin, un index donne, pour chaque "mot" la ou les pages où l'on doit le chercher, ce qui évite de devoir lire tout le bouquin pour retrouver la bonne phrase

Merci pour l'info, il est important que je pense aux index dans ma base

[Prjprj]

Envoyé par wissem.ba

Voilà ce que j'ai
Privilèges insuffisants
Echec de l'accès à V$MYSTAT
Obtenez le privilège de lecture du catalogue de votre administrateur de base de données:
grant SELECT_CATALOG_ROLE to SWFDWHSA
grant SELECT ANY DICTIONARY toSWFDHSA

Dans ce cas tu contactes ton DBA (l'administrateur de la base) avec la requête et tu lui demandes le plan d'exécution parce que tu as des problèmes de performances.

336 000 lignes, c'est beaucoup pour un insert/update, il faut des index.

La règle pour créer un index c'est de le faire sur la ou les colonnes qui ont le plus de "sens" pour tes requêtes.
L'idéal c'est d'indexer le ou les champs qui servent à identifier une ligne parmi toutes. Si tu as un identifiant unique par ligne, c'est lui qu'il faut indexer, si ce n'est pas le cas, il faut indexer le groupe de colonnes qui te permettent de d'identifier tes lignes.

Exemple simplifié volontairement :
Dans une table Clients, avec un identifiant unique du client, c'est cet identifiant qu'il faut indexer.
Dans une table Produits, avec un identifiant unique du produit, c'est cet identifiant qu'il faut indexer.
Dans une table Ventes avec l'identifiant du client et l'identifiant du produit mais pas d'identifiant de ta vente, tu dois indexer les deux identifiants.

[wissem.ba]

Je dois appliquer l'index sur la table source ou destination ?

Quand tu dis qu'il faut appliquer un index sur les colonnes qui ont un sens pour la requête pour mon exemple cela voudrait dire que je dois indexer toutes les colonnes (50 au total).

voilà la requête select dans le tOracleInput

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
SELECT SAS_CALISSUE_TER.ID,
		SAS_CALISSUE_TER.KEY,
		SAS_CALISSUE_TER.PROJECTKEY,
		SAS_CALISSUE_TER.RECORDKEY,
		SAS_CALISSUE_TER.RECORDTYPE,
		SAS_CALISSUE_TER.SUMMARY,
		SAS_CALISSUE_TER.DESCRIPTION,
		SAS_CALISSUE_TER.RESOLUTION,
		SAS_CALISSUE_TER.PRIORITY,
		SAS_CALISSUE_TER.ASSIGNEE,
		SAS_CALISSUE_TER.REPORTER,
		SAS_CALISSUE_TER.RECORDSTATUS,
		SAS_CALISSUE_TER.CREATEDDATE,
		SAS_CALISSUE_TER.UPDATEDDATE,
		SAS_CALISSUE_TER.LASTUPDATEDDATE,
		SAS_CALISSUE_TER.PROJECTID,
		SAS_CALISSUE_TER.ACTIONWKSOLUTION,
		SAS_CALISSUE_TER.ANALYSIS,
		SAS_CALISSUE_TER.REQUESTDATE,
		SAS_CALISSUE_TER.DESK,
		SAS_CALISSUE_TER.DOMAIN,
		SAS_CALISSUE_TER.RESOLUTIONDATE,
		SAS_CALISSUE_TER.RESOLUTIONDESC,
		SAS_CALISSUE_TER.QUICKFIXVERSION,
		SAS_CALISSUE_TER.FIXVERSION,
		SAS_CALISSUE_TER.AFFECTVERSION,
		SAS_CALISSUE_TER.APPLICATION,
		SAS_CALISSUE_TER.SITE,
		SAS_CALISSUE_TER.BUSINESSLINE,
		SAS_CALISSUE_TER.COMPONENT,
		SAS_CALISSUE_TER.CUSTOMER,
		SAS_CALISSUE_TER.ENDDATEPROJECT,
		SAS_CALISSUE_TER.ENVIRONMENT,
		SAS_CALISSUE_TER.ESTIMATEDWKFORBATEAM,
		SAS_CALISSUE_TER.ESTIMATEDWKFORDEVTEAM,
		SAS_CALISSUE_TER.ESTIMATEDWKFORTESTINGTEAM,
		SAS_CALISSUE_TER.EXTERNALURL,
		SAS_CALISSUE_TER.IMPACT,
		SAS_CALISSUE_TER.ISSUERESOLUTION,
		SAS_CALISSUE_TER.ISSUESUBTYPE,
		SAS_CALISSUE_TER.ISSUETYPE,
		SAS_CALISSUE_TER.KEYWORDS,
		SAS_CALISSUE_TER.OWNERTEAM,
		SAS_CALISSUE_TER.OWNERUSER,
		SAS_CALISSUE_TER.REPRODUCIBILITY,
		SAS_CALISSUE_TER.SEVERITY,
		SAS_CALISSUE_TER.STARTDATEPROJECT,
		SAS_CALISSUE_TER.SYMPTOMS,
		SAS_CALISSUE_TER.TARGETDATE,
		SAS_CALISSUE_TER.URGENCY,
		SAS_CALISSUE_TER.WKFORBATEAM,
		SAS_CALISSUE_TER.WKFORDEVTEAM,
		SAS_CALISSUE_TER.WKFORTESTINGTEAM,
		SAS_CALISSUE_TER.ENDDATEDEPLOYMENT,
		SAS_CALISSUE_TER.ENDDATEDEVELOPMENT,
		SAS_CALISSUE_TER.ENDDATESPECIFICATION,
		SAS_CALISSUE_TER.ENDDATEUAT,
		SAS_CALISSUE_TER.FORECASTENDDATE,
		SAS_CALISSUE_TER.FORECASTSTARTDATE,
		SAS_CALISSUE_TER.ACKNOWLEDGMENTDURATION,
		SAS_CALISSUE_TER.ACTUALWORKLOAD,
		SAS_CALISSUE_TER.ESTIMATEWORKLOAD,
		SAS_CALISSUE_TER.NBREJECTEDSOLUTIONS,
		SAS_CALISSUE_TER.ROOTCAUSE,
		SAS_CALISSUE_TER.SUPPORTTEAMDURATION,
		SAS_CALISSUE_TER.TICKETDURATION,
		SAS_CALISSUE_TER.TICKETRESOLUTION,
		SAS_CALISSUE_TER.TICKETTYPE,
		SAS_CALISSUE_TER.TICKETSUBTYPE,
		SAS_CALISSUE_TER.CLOSURETYPE,
		SAS_CALISSUE_TER.MANTIDOT_ID,
		SAS_CALISSUE_TER.MANTISIS_ID,
		SAS_CALISSUE_TER.MANTIS_LINK,
		SAS_CALISSUE_TER.CLEARQUEST_ID,
		SAS_CALISSUE_TER.INITIAL_PRIORITY,
		SAS_CALISSUE_TER.INITIAL_URGENCY
FROM	SAS_CALISSUE_TER
WHERE (UPPER(RECORDTYPE) LIKE '%TICKET%') OR (UPPER(RECORDTYPE) LIKE '%ISSUE%')

Est-ce qu'il faut indexer toutes les colonnes de la table ou juste la colonne RECORDTYPE puisque c'est sur elle que porte le where (donc c'est elle qui donne le plus de sens à ma requête) ?

[Prjprj]

Dans l'idéal, tu dois indexer les deux tables.

Ta table source doit être indexée sur le champ RECORDTYPE.
Par contre, ton WHERE n'est pas adapté à l'utilisation d'un index, il faut l'écrire plutôt de la façon suivante :

Code :

WHERE RECORDTYPE IN ('TICKET','ISSUE','ticket','issue')

Pour la liste des valeurs à mettre dans ton champ RECORDTYPE, tu fais la requête suivante et tu mets dedans la liste des résultats qui correspondent à ce dont tu as besoin:

Code :

SELECT DISTINCT RECORDTYPE FROM SAS_CALISSUE_TER;

Concernant la table destination, cela dépend du ou des champs qui te servent à identifier les lignes dans ton Insert/update.

Si c'est bien le champ ID, en l'indexant cela devrait fonctionner mieux.

Un conseil après création d'index, passer les statistiques sur les tables indexées :

Code :

1
2
3
Analyze Table TABLE
Estimate Statistics
Sample 33 Percent;

[wissem.ba]

Ok je tiens en compte de tout cela.

Juste une dernière remarque : la table destination n'a pas d'identifiant (il n'y a pas de clé et toutes les colonnes sont nullables).

Je ne pense pas pouvoir modifier la table destination, c'est la prod et je m'estime heureux qu'on m'autorise à y accéder.

voici le code SQL de la table destination

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
CREATE TABLE "SWFTICKETISSUE"
  (
    "ID"           NUMBER(12,0),
    "KEY"          VARCHAR2(255 BYTE),
    "PROJECTKEY"   VARCHAR2(255 BYTE),
    "RECORDKEY"    NUMBER(20,2),
    "RECORDTYPE"   VARCHAR2(60 BYTE),
    "SUMMARY"      VARCHAR2(255 BYTE),
    "DESCRIPTION"  VARCHAR2(4000 BYTE),
    "RESOLUTION"   VARCHAR2(60 BYTE),
    "PRIORITY"     VARCHAR2(60 BYTE),
    "ASSIGNEE"     VARCHAR2(255 BYTE),
    "REPORTER"     VARCHAR2(255 BYTE),
    "RECORDSTATUS" VARCHAR2(60 BYTE),
    "CREATEDDATE" DATE,
    "UPDATEDDATE" DATE,
    "LASTUPDATEDDATE" DATE,
    "PROJECTID"        NUMBER(12,0),
    "ACTIONWKSOLUTION" VARCHAR2(4000 BYTE),
    "ANALYSIS"         VARCHAR2(4000 BYTE),
    "REQUESTDATE" DATE,
    "DESK"            VARCHAR2(4000 BYTE),
    "DOMAIN"          VARCHAR2(4000 BYTE),
    "RESOLUTIONDATE"  VARCHAR2(17 BYTE),
    "RESOLUTIONDESC"  VARCHAR2(4000 BYTE),
    "QUICKFIXVERSION" VARCHAR2(1000 BYTE),
    "FIXVERSION"      VARCHAR2(4000 BYTE),
    "AFFECTVERSION"   VARCHAR2(4000 BYTE),
    "APPLICATION"     VARCHAR2(4000 BYTE),
    "SITE"            VARCHAR2(4000 BYTE),
    "BUSINESSLINE"    VARCHAR2(4000 BYTE),
    "COMPONENT"       VARCHAR2(4000 BYTE),
    "CUSTOMER"        VARCHAR2(255 BYTE),
    "ENDDATEPROJECT"  VARCHAR2(17 BYTE),
    "ENVIRONMENT"     VARCHAR2(4000 BYTE),
    "ESTIMATEDWKFORBATEAM" FLOAT(126),
    "ESTIMATEDWKFORDEVTEAM" FLOAT(126),
    "ESTIMATEDWKFORTESTINGTEAM" FLOAT(126),
    "EXTERNALURL"      VARCHAR2(255 BYTE),
    "IMPACT"           VARCHAR2(255 BYTE),
    "ISSUERESOLUTION"  VARCHAR2(255 BYTE),
    "ISSUESUBTYPE"     VARCHAR2(255 BYTE),
    "ISSUETYPE"        VARCHAR2(255 BYTE),
    "KEYWORDS"         VARCHAR2(4000 BYTE),
    "OWNERTEAM"        VARCHAR2(4000 BYTE),
    "OWNERUSER"        VARCHAR2(255 BYTE),
    "REPRODUCIBILITY"  VARCHAR2(255 BYTE),
    "SEVERITY"         VARCHAR2(255 BYTE),
    "STARTDATEPROJECT" VARCHAR2(17 BYTE),
    "SYMPTOMS"         VARCHAR2(255 BYTE),
    "TARGETDATE"       VARCHAR2(17 BYTE),
    "URGENCY"          VARCHAR2(255 BYTE),
    "WKFORBATEAM" FLOAT(126),
    "WKFORDEVTEAM" FLOAT(126),
    "WKFORTESTINGTEAM" FLOAT(126),
    "ENDDATEDEPLOYMENT"    VARCHAR2(17 BYTE),
    "ENDDATEDEVELOPMENT"   VARCHAR2(17 BYTE),
    "ENDDATESPECIFICATION" VARCHAR2(17 BYTE),
    "ENDDATEUAT"           VARCHAR2(17 BYTE),
    "FORECASTENDDATE"      VARCHAR2(17 BYTE),
    "FORECASTSTARTDATE"    VARCHAR2(17 BYTE),
    "ACKNOWLEDGMENTDURATION" FLOAT(126),
    "ACTUALWORKLOAD" FLOAT(126),
    "ESTIMATEWORKLOAD" FLOAT(126),
    "NBREJECTEDSOLUTIONS" FLOAT(126),
    "ROOTCAUSE" VARCHAR2(255 BYTE),
    "SUPPORTTEAMDURATION" FLOAT(126),
    "TICKETDURATION" FLOAT(126),
    "TICKETRESOLUTION" VARCHAR2(255 BYTE),
    "TICKETTYPE"       VARCHAR2(255 BYTE),
    "TICKETSUBTYPE"    VARCHAR2(255 BYTE),
    "CLOSURETYPE"      VARCHAR2(255 BYTE),
    "MANTIDOT_ID"      VARCHAR2(255 BYTE),
    "MANTISIS_ID"      VARCHAR2(255 BYTE),
    "MANTIS_LINK"      VARCHAR2(255 BYTE),
    "CLEARQUEST_ID"    VARCHAR2(255 BYTE),
    "INITIAL_PRIORITY" VARCHAR2(255 BYTE),
    "INITIAL_URGENCY"  VARCHAR2(255 BYTE)
  )
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING STORAGE
  (
    INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT
  )
  TABLESPACE "SWFDWHDA_DAT" ;

Merci

[wissem.ba]

Bonjour à tous,

Quand j'ai créé ce sujet je ne pensais jamais un jour cliquer sur "résolu".

Mon job prend 30 secondes aujourd'hui contre 3h avant le week end.

Pour ceux qui tombent sur le même cas que moi j'ai ajouté des index sur les tables volumineuses.

Merci à tous ceux qui m'ont aidé

Bonne journée à tous