Requête DELETE + jdbc

[Hakim93210]

Salut tout le monde,

J'ai un petit problème de conception en java mais qui a attrait à une requête DB2.

Dans un fichier .sql, j'ai une requête de la forme

Code :

1
2
 
DELETE FROM MATABLE WHERE ID <> 900 FETCH FIRST 1000 row only

L'utilisation du FETCH est imposée par les DBA pour ne pas exploser les logs.

Mon souci est que je ne sais pas comment supprimer mes lignes en jdbc car il se peut que je n'ai pas plus de 1000 lignes à supprimer ou, au contraire, plus de 1000 lignes à supprimer en mm tps.

Je propose ceci, qu'en pensez-vous?

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
int compteurLignesSupp = 0;
String query = "DELETE........";
 try
    {
     Statement st = conn.createStatement();
     st.executeUpdate(query);
 
     compteurLignesSupp =  st.updateCount();
     while (compteurLignesSupp >= 1000)
                 st.executeUpdate(query);
 
    }
    catch (SQLException ex)
    {
      System.err.println(ex.getMessage());
    }

Merci d'avance pour votre aide.

Cordialement,

[Luc Orient]

Quel DB2 ?

[Hakim93210]

Salut,

Il me semble que c une DB2 V7.

[Luc Orient]

DB2 for z/OS (Mainframe) ?
DB2 for LUW (Linux/Unix/Windows) ?
DB2 for i (AS/400) ?

[Karim93210]

Salut,

C'est du DB2 V9.5, sous Windows.

Cordialement,

[punkoff]

mais votre ordre sql marche ?

Car je ne vois nul part la possibilité de faire un fetch first sur un delete, ce qui parait logique.

http://publib.boulder.ibm.com/infoce...c/r0000939.htm

[Karim93210]

Bonjour à tous,

Oui mon ordre marche, c'est juste la manipulation depuis mon source Java qui me pose pb.

L'utilisation du FETCH dans le DELETE permet de ne pas faire exploser les logs.

[punkoff]

Mais si votre but c'est de tout supprimer, que vous les supprimiez en une fois ou en n fois ca reviendra au même, vos "log" vont quand même être rempli.

D'ailleurs, pourriez-vous développer un peu cette notion de log ?

[bboulch]

Bonjour,

L'utilisation du fetch doit peut être se faire comme ça :

Code :

DELETE FROM (SELECT salary FROM employee ORDER BY salary fetch first 50 rows only)

(requête trouvée sur la page suivante mais non testée : http://it.toolbox.com/blogs/db2luw/i...ll-select-7161).

Mais comme l'a précisé Punkoff, il se peut qu'au final les logs "explosent".

Il faudrait essayer l'option "ACTIVATE NOT LOGGED INITIALLY" de "ALTER TABLE" qui permet de désactiver temporairement les logs sur une table :

http://publib.boulder.ibm.com/infoce...n/r0000888.htm

Benoit

[punkoff]

Ces logs c'est un équivalant de la journalisation ?

edit :

If non-logged activity occurs against a table that has the NOT LOGGED INITIALLY attribute activated, and if a statement fails (causing a rollback), or a ROLLBACK TO SAVEPOINT is executed, the entire unit of work is rolled back (SQL1476N). Furthermore, the table for which the NOT LOGGED INITIALLY attribute was activated is marked inaccessible after the rollback has occurred and can only be dropped. Therefore, the opportunity for errors within the unit of work in which the NOT LOGGED INITIALLY attribute is activated should be minimized.

C'est violant comme solution

[bboulch]

Merci, je cherchais le terme correct ce matin.

Oui, il s'agit bien de la journalisation. C'est un problème ponctuel (de vidage de table) que j'ai rencontré il y a quelques années et cette solution convenait bien.

Effectivement cette solution est violente. Et du coup, elle ne convient peut être pas dans le cadre d'un traitement JDBC occasionnel qui aurait besoin de la journalisation.

Benoit