Optimisation methode insertion

[keub51]

Bonjour tout le monde,

Je cherche le moyen d'optimiser une méthode qui prend beaucoup de temps. cette methode consigne dans trois tables des données d'un objet Erreur

voici la méthode :

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
 
public void INSERT(Erreur E,String nom_fic) throws SQLException
{
	//int INDEX = getFreeIndex();
	String requete = "insert into TL_LOGMSG(DATLOGMSG,HMSLOGMSG,NOMCLA,LIBSEV,LIBMSG,NOMXCP,NOMFCH) values('"+E.Date+"','"+E.Time+"','"+Pars(E.Class)+"','"+E.Level+"','"+Pars(E.Intitule)+"','"+Pars(E.theException)+"','"+ nom_fic +"')";
	//System.out.println(requete);
	this.execute2(requete);
	int id = getIndex();
	IF(E.Pile!=NULL || !E.Pile.isEmpty())
	{
		Iterator iter = E.Pile.iterator() ;
				int i=0;
				while (iter.hasNext()) 
				{
					i++;
				this.execute2("insert into TL_LOGPILMTH(TK_LOGMSG,ODRPILMTH,PTHMTH)values("+id+","+i+",'"+Pars((String)iter.next())+"')");
				}
	}
	IF(E.Arg!=NULL || !E.Arg.isEmpty())
	{
		Iterator iter = E.Arg.iterator() ;
				int i=0;
				while (iter.hasNext()) 
				{
				String s = (String) iter.next();
				String lib = s.substring(0,s.indexOf(":"));
				String valeur = s.substring(s.indexOf(":")+1,s.length());	
				requete = "insert into TL_LOGARG(TK_LOGMSG,LIBARG,VALARG)values("+id+",'"+Pars(lib)+"','"+Pars(valeur)+"')";
				this.execute2(requete);
				}
	}	
}

voici comment sont construites mes tables :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
 
CREATE TABLE TL_LOGMSG(
TK_LOGMSG INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 0, INCREMENT BY 1, NO CACHE ),
DATLOGMSG varchar(11),
HMSLOGMSG varchar(13),
NOMCLA varchar(100),
LIBSEV varchar(30),
LIBMSG varchar(400),
NOMXCP varchar(600),
NOMFCH varchar(256));
 
CREATE TABLE TL_LOGARG(
TK_LOGMSG INTEGER,
LIBARG varchar(100),
VALARG varchar(100));
 
CREATE TABLE TL_LOGPILMTH(
TK_LOGMSG INTEGER,
ODRPILMTH Integer,
PTHMTH varchar(700));

Donc voila je me demandais si par exemple il serai plus judicieux et possible de faire une seule et unique requete.
Aussi si je devrais revoir mes tables, la façon dont elles sont construites.

Sinon je sais que je ne suis pas dans le forum approprié mais ca m'aidera aussi : pensez vous que l'algorythme ( JAVA ) est correct ? Est il possible de faire plus concis et rapide ?

Merci

[keub51]

Je précise que je travaille sur DB2...

[fsmrel]

Bonjour,

Pour la partie strictement DB2 :

Où sont passées les clés primaires ?
Où sont les index ?
Avez-vous exécutés les Réorganisations ? Les Runstats ? Les Rebind à suivre ?
Avez-vous analysé les Explain ?
Quelles sont les volumétries ?
Avez-vous vérifié dans le catalogue que les espaces physiques sont taillés de façon pertinente ?
S’agit-il de DB2 pour z/OS ou autre ?
Etc.

Si vous avez des problèmes de performance, vous devez être à même de déterminer si c’est la partie SQL qui est en cause et/ou les programmes qui hébergent les requêtes. Les requêtes doivent donc être testées hors programme et si vous avez des outils de mesure, n’hésitez pas à en vous en servir.

[rberthou]

Au niveau du code java il est déjà bien préférable d'utiliser :
- prepareStatement : mais cela risque de modifier ton code.
- des batchUpdate : dans le cas ou tu boucle sur les insertions (avec bien sur des prepareStatement)

Tu peux également regarder du cote de sqlj (si tu es sur DB2) pour en pas faire de sql dynamique (mais personnellement j'aime pas beaucoup sqlj)

[keub51]

Envoyé par fsmrel

Bonjour,

Pour la partie strictement DB2 :

Où sont passées les clés primaires ?
Où sont les index ?
Avez-vous exécutés les Réorganisations ? Les Runstats ? Les Rebind à suivre ?
Avez-vous analysé les Explain ?
Quelles sont les volumétries ?
Avez-vous vérifié dans le catalogue que les espaces physiques sont taillés de façon pertinente ?
S’agit-il de DB2 pour z/OS ou autre ?
Etc.

Si vous avez des problèmes de performance, vous devez être à même de déterminer si c’est la partie SQL qui est en cause et/ou les programmes qui hébergent les requêtes. Les requêtes doivent donc être testées hors programme et si vous avez des outils de mesure, n’hésitez pas à en vous en servir.

en ce qui concerne les clés primaires, leur utilisation m'a été déconseillée par un administrateur ... allez savoir pourquoi ...

les index sont les premieres colonnes de chaque table

Code :

1
2
3
4
5
Avez-vous exécutés les Réorganisations ? Les Runstats ? Les Rebind à suivre ?
Avez-vous analysé les EXPLAIN ?
Quelles sont les volumétries ?
Avez-vous vérifié dans le catalogue que les espaces physiques sont taillés de façON pertinente ?
S’agit-il de DB2 pour z/OS ou autre ?

sur ca je suis incapable de te répondre trop technique a mon goût

Je pense que les partie SQL/Programme ont toutes les deux besoin d'être optimisées ... Je m'explique : j'ai fait cette méthodes avec des connaissances de base, il y a surement des objets qui correspondent mieux ( je pense à preparedstatement au quel je vais jeter un oeil ... ). De plus la base de données que j'utilise est assez solicitée ...

Merci de vos réponses en tout cas je vais regarder ca en ce beau lundi matin

[rberthou]

exemple prepareStatement

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
 
PreparedStatement pstmt = NULL;
String sql = "insert into matable (zone1, zone2, zone3) values (?, ?, ?) " ;
try { 
   pstmt = conn.prepareStatement(sql);
   pstmt.setString(1, "valZone1" );
   pstmt.setInt(2, 25); // en supposant que zone2 soit un champ integer
   pstmt.setString(3, "valZone3" );
   pstmt.executeUpdate();
}
catch(SQLException sqle) {
// ... 
}

la meme chose dans le cas d'insert massif (cela doit etre le cas dans ton Iteration )

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
 
PreparedStatement pstmt = NULL;
String sql = "insert into matable (zone1, zone2, zone3) values (?, ?, ?) " ;
try { 
   pstmt = conn.prepareStatement(sql);
   FOR (int i= 0; i < 1050 ; i++) {
       pstmt.setString(1, "valZone" );
       pstmt.setInt(2, i); // en supposant que zone2 soit un champ integer
       pstmt.setString(3, "valZone3" );
       pstmt.addBatch();
       // commit toutes les 100 insertions
       IF ((i % 100) == 0) {
	  pstmt.executeBatch();
          conn.commit() ;
        }
   }
   // traitement des 50 dernieres lignes
   pstmt.executeBatch();
   conn.commit() ;
 
}
catch(SQLException sqle) {
// ... 
}

De plus au niveau sql il est preferable d'utiliser des champs date ou timestamp au lieu de varchar si c'est des dates/heures que tu traites.

[fsmrel]

Envoyé par keub51

en ce qui concerne les clés primaires, leur utilisation m'a été déconseillée par un administrateur ... allez savoir pourquoi ...

Il serait intéressant que votre administrateur expose ses motifs...
En attendant, vos tables ne sont pas des ensembles, mais des sacs : l’algèbre relationnelle ne s’applique pas. L’intégrité référentielle n’est pas contrôlée. Vous vous servez de votre SGBDR comme d’un SGBD non R. Le contenu de la base de données n’est peut-être pas très beau à voir.

Envoyé par keub51

les index sont les premieres colonnes de chaque table

C’est original, mais ça ne relève pas d’une étude sérieuse des besoins des applications...

Envoyé par keub51

Code :
Avez-vous exécutés les Réorganisations ? Les Runstats ? Les Rebind à suivre ?
Avez-vous analysé les EXPLAIN ?
Quelles sont les volumétries ?
Avez-vous vérifié dans le catalogue que les espaces physiques sont taillés de façon pertinente ?
S’agit-il de DB2 pour z/OS ou autre ?

sur ca je suis incapable de te répondre trop technique a mon goût

Et l’administrateur fait-il ce travail ?
A défaut, la base de données ne peut être qu’une brouette alors qu’elle pourrait être une Ferrari...

[jab]

Je ne suis pas spécialiste Java mais je vois que tes requêtes sont effectuée dans une méthode Execute2. Peux-tu fournir la méthode car en définitive, c'est-elle qui accède à la DB ? Ne fais-tu pas un open dans cette méthode par exemple ?

[alex.]

Bonjour,

Quelques articles pour un javaman :

http://www.ibm.com/developerworks/db...lio/index.html

http://www.ibm.com/developerworks/db...04pooloth.html

Attention si tu es sur DB2 z/OS au coût d'une DGTT.

Alex.

[alex.]

+ celui-ci

http://www.ibm.com/developerworks/db...3milligan.html