Test insert delete

bonjour,

voilà je veux purger une table apres avoir l'historiser dans une autre table
D'abord j insere les enregistrement récupérés à l'aide de mon curseur dans la table d archivage, apres je les supprime
Mais il ne faut supprimer un enregistrement de la table d origine que s il est bien inserer dans la table d archivage ; j'arrive pas a faire ce test
Remarque : faut que j'utilise le BULK COLLECT et LIMIT

Merci bien de me repondre, c tres urgent

Voici une des solutions basée sur la gestion des exceptions clé dupliquée.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

For Ng In (Select * From Table_Origine) Loop Begin Insert Into Table_Cible Values(Ng.Col1,Ng.Col2....); -- L'insert s'est bien passé. Delete Table_Origine Where ...... Exception --Quand Erreur d'insertion, ne rien faire When Dup_Val_On_Index Then Null; End; End Loop;

---

Merci bien de m'avoir repondu

pour ça c bon, mais j'ai un soucis:
Quand j'utilise le fetch -mon_curseur- BULK COLLECT into l_rowid LIMIT &NB;
avec NB = 1000
et apres je fait le commit apres chaque ligne inserer et supprimer(dans la boucle for c a d), il me prend que les 1000 premier enregistrements
Est ce que si je met le commit apres la boucle for et dans la boucle loop du fetch ça ne causera pas de problème?

si je mets pas de commit sa prends tout les enregistrements


remarque: j'utilse le for update skip locked dans la requete de selection de mon curseur

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

DECLARE   CURSOR C1 IS SELECT rowid WHERE .. for update skip locked;       BEGIN     OPEN C1;   loop   fetch C1 BULK COLLECT into var LIMIT 1000;     if (var.COUNT != 0) then   for j in 1..var.COUNT loop   begin   insert into table_archive (select ... where rowid = var(j));   delete from table where rowid = var(j);       exception when others then NULL; dbms_output.put_line('erreur suppression'); end;   end loop;   commit; end if;   exit when C_stocouch%NOTFOUND;   end loop;   CLOSE C1;       EXCEPTION   WHEN OTHERS THEN   CLOSE C_stocouch;   END;

---

Le probleme c'est que juste le1000 premiers enregistrements sont traités

Merci de me repondre, c'est tres urgent

Citation:

---

Envoyé par zico_pro

Le probleme c'est que juste le1000 premiers enregistrements sont traités
Merci de me repondre, c'est tres urgent

---

Déjà merci de poser une question claire et de mettre ton message en forme avec la balise #...
C'est urgent ? Eh bien tu peux faire appel à des sociétés dont c'est le travail de traiter les urgences. Les gens du forum ont aussi leurs urgences.

Et pour ton problème que penses-tu de :

Code:

---

fetch C1 BULK COLLECT into var LIMIT 1000;

---

Sorry Jerome, j'avais pas vu.
Je supprime l'autre doublon.

Mais si la requete de mon curseur ramene 2300 enregistrements, le fetch doit les traiter tous

Alors pourquoi mettez-vous cette limite ?

le LIMIT ne sert-il pas à faire des lots de 1000 ? Il est dans un LOOP donc il n'y a pas de raison de ne traiter que 1000 lignes si il y a plus de lignes non ? :koi:

idem que : http://sheikyerbouti.developpez.com/...age=Chap5#L5.5

Oui, le LIMIT sert a faire des lots de 1000 lignes
Ils doit à chaque fois traiter 1000 ligne ensemble

pour 2300 enregistrements:
d abord il prend 1000 lignes
Apres les autres 1000
enfin 300

Citation:

---

Envoyé par zico_pro

...
remarque: j'utilse le for update skip locked dans la requete de selection de mon curseur

---

:aie: C'est une faute grave! :aie:
Nulle besoin de bulk, etc.

Code:

---

1 2 3 4 5

Insert /*+ APPEND */ Into table_hist Select ... From table_del Where ... / delete table_del (ou peut être truncate) /

---

Voilà.

en tout cas, passer par le ROWID c'est pas très lumineux comme idée tant c'est peu fiable comme données.

Sinon, tu es sûr que tu as bien 2300 lignes ? T'as essayé de mettre des messages pour voir par exemple combien de fois il boucle parce que tu déclenches peut-être une exception :?

Bon, j'ai fusionné les 2 discussions et du coup j'y vois plus clair.

La solution est donc très simple, un trigger BEFORE DELETE pour insérer les lignes dans la table archive et tu fais un DELETE de tes lignes :)

Citation:

---

Envoyé par orafrance

en tout cas, passer par le ROWID c'est pas très lumineux comme idée tant c'est peu fiable comme données.

Sinon, tu es sûr que tu as bien 2300 lignes ? T'as essayé de mettre des messages pour voir par exemple combien de fois il boucle parce que tu déclenches peut-être une exception :?

---

Passer par rowid c'est fiable mais dans ce cas c'est une perte de temps.
Et mon préféré

Code:

---

1 2 3 4 5 6

... when others then NULL; dbms_output.put_line('erreur suppression'); ...

---

est peut être la pour créer un problème.

Citation:

---

Envoyé par orafrance

Bon, j'ai fusionné les 2 discussions et du coup j'y vois plus clair.

La solution est donc très simple, un trigger BEFORE DELETE pour insérer les lignes dans la table archive et tu fais un DELETE de tes lignes :)

---

Voilà les trigger maintenant la où il n'ont rien a chercher :aie:.

Citation:

---

Envoyé par mnitu

Passer par rowid c'est fiable mais dans ce cas c'est une perte de temps.

---

c'est fiable jusqu'à ce qu'une migration de ligne ou un update soit fait :?

Il faut supprimer une ligne de la table d'origine que si elle a été bien inserer dans la table d'archivage

si elle n'est pas insérée le trigger déclenchera une erreur et le DELETE ne se fera pas :)

Je laisse le curseur?

tu enléves tout, tu fais ton trigger et après tu pourras faire un simple DELETE :)

Mais comme ça je vais avoir 3 select imbriqués
Et en plus, si y aura une ligne qui n est pas bien inserée, le trigger va sortir, alors que moi je dois suivre les lignes une par une
C est à dire si une ligne n'est pas inserer, je ne la supprime pas de la table et je passe à la ligne suivante

bah tu fais un curseur dans ce cas évidemment.

mais comme ça on va tomber dans le meme cas nn?

la question est : Pourquoi tu veux faire un BULK COLLECT ?

Chui obligé de le faire
Je veux traiter les enregistrement par lots de 1000 lignes

En plus dans ma requete ce que je comprends pas c'est qu'en virant le commit sa marche, mais si je mets le commit on dirait que le loop de fetch ne marche plus, il s'arrete au premier lot de 1000 enregistrements

Parce que tu as une exception déclenchée que tu ne vois pas à cause du WHEN OTHERS... je te l'ai déjà dit :roll:

Et le traitement pas lot c'est bien mais alors ça veut dire que tu acceptes qu'en cas d'erreur tu peux avoir 1000 lignes non traitées ?

Moi ce que je veux faire c'est : traiter les enreg par lot de 1000
pour chaque 1000 enreg, les parcourir un par un inserer et supprimer chacun(boucle for), si je rencontre un probleme pour un enregistrement je passe au suivant

Apres je passe au lot suivant

supprime la partie EXCEPTION pour voir l'erreur... je ne le dirais pas une 4eme fois :roll:

effectivement j'ai eu l erreur ORA-00600 : internal error code

je comprends pas

Si je vire le commit j ai pas cet erreur

Citation:

---

Envoyé par orafrance

c'est fiable jusqu'à ce qu'une migration de ligne ou un update soit fait :?

---

Je n'ai pas proposé de les stocker dans une table. Donc c'est quoi le souci qui empêche un traitement de lire le rowid et de les utiliser ?

Le probleme c'est l'utilisation du for update skip locked

est ce que vous avez une solution pour ça

Il faut que je prends que les enregistrements qui sont pas loked
c a d si un enregistrement est utilisé par une autre session, il faut pas trop attendre pour qu'il soit libreré

Citation:

---

Envoyé par mnitu

Je n'ai pas proposé de les stocker dans une table. Donc c'est quoi le souci qui empêche un traitement de lire le rowid et de les utiliser ?

---

rien n'empêche un déplacement de ligne durant l'opération :?

il faut regarder le fichier des alertes

ce qui fou la merde c'est le skip locked, parce que en mettant le commit dans la boucle tout change, il faut faire qu un seul commit à la fin

Moi je veux faire le test suivant :
pour chaque ligne ramener par le curseur, il ne faut le supprimer que si elle est bien inserée et inversement

Voulez vous m aider pour ce test

Citation:

---

Envoyé par zico_pro

ce qui fou la merde c'est le skip locked...

---

Il me semble que j'ai déjà dit que "C'est une faute grave" :king:

pourquoi c est une faute grave?
il faut que je l'utilise pour ne prendre que les enregistrement non utilisés

Voilà un test pour ceux qui aiment les triggers

A) Sans trigger

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

lock table big_table in exclusive mode nowait / insert /*+ APPEND */ Into big_hist Select * from big_table where owner = 'PUBLIC' / delete mni.big_table Where owner = 'PUBLIC' / commit /

---

B) Avec trigger

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Create Or Replace Trigger BD_Big_Table Before Delete On Big_Table For Each Row Begin insert into big_hist (owner, object_name, subobject_name, object_id, data_object_id, object_type, created, last_ddl_time, timestamp, status, temporary, generated, secondary) values (:old.owner, :old.object_name, :old.subobject_name, :old.object_id, :old.data_object_id, :old.object_type, :old.created, :old.last_ddl_time, :old.timestamp, :old.status, :old.temporary, :old.generated, :old.secondary); End; / delete mni.big_table Where owner = 'PUBLIC' / commit /

---

Tkprof Sans trigger

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

delete mni.big_table Where owner = 'PUBLIC'   call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 0 Execute 1 6.83 158.51 9249 1866 274898 239616 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 2 6.83 158.52 9249 1866 274898 239616   insert /*+ APPEND */ Into big_hist Select * from big_table where owner = 'PUBLIC'   call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.03 0 0 0 0 Execute 1 1.62 21.23 7639 21577 1137 239616 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 2 1.62 21.26 7639 21577 1137 239616

---

Tkprof Avec trigger

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

delete mni.big_table Where owner = 'PUBLIC'   call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 0 Execute 1 27.34 197.61 7061 17665 993822 239616 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 2 27.34 197.62 7061 17665 993822 239616   INSERT INTO BIG_HIST (OWNER, OBJECT_NAME, SUBOBJECT_NAME, OBJECT_ID, DATA_OBJECT_ID, OBJECT_TYPE, CREATED, LAST_DDL_TIME, TIMESTAMP, STATUS, TEMPORARY, GENERATED, SECONDARY) VALUES (:B1 , :B2 , :B3 , :B4 , :B5 , :B6 , :B7 , :B8 , :B9 , :B10 , :B11 , :B12 , :B13 )     call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.02 0 0 0 0 Execute 239663 12.51 81.02 5 3397 266709 239663 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 239664 12.51 81.04 5 3397 266709 239663

---

A parte les différences en temps CPU, et Elapsed, j'aime bien les 239663 exécutions pour insérerer 239616 lignes

Citation:

---

Envoyé par zico_pro

pourquoi c est une faute grave?
...

---

Parce que skip n'est documenté; égal zéro contrôle ! Montre moi ou tu la trouves dans la documentation d'Oracle

Citation:

---

Envoyé par zico_pro

...il faut que je l'utilise pour ne prendre que les enregistrement non utilisés

---

Tu n'a que verrouillé d'aborde les enregistrements que tu veut traiter. Point !