Discussion :

[helyos]

Moi je vois le pb autrement

Tu fais un delete basé sur une requete qui peut te renvoyer 40000 lignes.

Tu généres donc des informations dans ton cache puisqu'il est obligé de stocker les lignes correspondantes

Ensuite tu lances le delete qui lui génére des informations de redos et des informations dans les RBS

Le fait que tu effaces 40000 lignes peut occuper énormément de temps procésseur.

Il faudrai vérifié en dernier recours qu'il n'y a pas de trigger sur cette table.

Ensuite si il n'y a rien et que les solutions basique ne passent pas nous utiliserons une autre méthode.

[crasho007]

Je suis d'accord que cela peut occuper beaucoup de temps machine, surtout sur ce type de machine.

mais dela a prendre plus de deux heure pour supprimer mes enregistrements ...

Point de vu trigger, si j'en ai une, j'ai un trigger d'incrementation.

j'essaie ta méthode et je te tiens au courant

[crasho007]

je ne sais pas si cela ne pourrai pas venir du SGA_MAX_SIZE ou tout simplement a cause du dump qui m'aurai suppimer certaine contrainte d'intergriter.

J'ai été voir sur www.orafaq.com mais je ne sais pas trop ou chercher, aparament le problème c'est deja posé mais il me dépasse.

Il est fort possible que je me trompe

[helyos]

As tu essayés ma méthode?

[SheikYerbouti]

Point de vu trigger, si j'en ai une, j'ai un trigger d'incrementation.

pouvez-vous désactiver ce trigger avant le DELETE et le réactiver après ?

[crasho007]

As tu essayés ma méthode?

oui j'ai essayer, mais rien ne change ca deviens vraiment lassant...

pouvez-vous désactiver ce trigger avant le DELETE et le réactiver après ?

Enfin, enfin, enfin
MERCI MERCI ET ENCORE MERCI... tout ca a cause d'un malheureux trigger d'incrémentation...

En tout cas, merci encore pour tout vos conseils, je ne suis pas expert en plus sur oracle loin de la.

[helyos]

Donc ca viendrais du trigger????

Pourrais tu coller le code du trigger stp?

[crasho007]

Voici le code du trigger :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Create or replace trigger TABLE 1 before insert on table 1
 For each row
 begin
    select ID_SEQ.nextval INTO :new.IDENTIFIANT from dual;
 End;

Voila, dis moi pourquoi voulais tu ce trigger ?

[Balises code ajoutées par Helyos]

[helyos]

Je ne comprends pas pourquoi ca ferai ralentir la chose .....

[crasho007]

Ba moi non plus, je ne comprend pas, pourquoi en supprimant ce trigger ( le seul que j'ai de toute facon) cela a permi de ne plus faire ralentir le serveur.

Je croix qu'également le dump de la base qui à été faite a du être en cause également du problème, dump qui aurai supprimer certaine contrainte d'intégriter

[SheikYerbouti]

l'exécution d'un trigger ralenti l'opération, et ce, même s'il ne contient qu'une instruction Null; !!!

Dans les traitements en masse, il faut factoriser ce temps supplémentaire avec le nombre de lignes traitées.
La technique de base consiste donc a évaluer le bon fonctionnement en désactivant les triggers le temps de ces opérations de gros volumes.

[crasho007]

En tout cas, je le serai pour la prochaine fois...

Je à remercier personellement SheikYerbouti, helyos et orafrance pour tous leur conseils.

[helyos]

Oki je comprends bien ce que tu dis, mais le trigger ne fait qu'un test (il vérifie si c'est pas un insert)

Donc forcement cela rajoute une charge supplémentaire mais je pensais pas que cela pouvait autant impacter les performances avec un simple test .....

[crasho007]

En fait cela inpact considerablement le temps machine, car, j'ai 2 instances qui fonctionne sur mon serveur et je n'ai pas eu les fond suffisant pour prendre un serveur avec de meilleur configuration...

Il faut savoir que les deux instances sont de taille équivalente et il est fort possible qu'elles soient trop importante pour la machine sur laquelle elle tourne...

[SheikYerbouti]

Autre observation qui n'a rien à voir avec la choucroute (mais qui pourrais bien sentir la saussice brûlée dans certains cas!)

votre trigger en insert contient le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT ....NEXTVAL from DUAL ;

Il faut savoir que tout curseur implicite comme celui-ci n'est libéré qu'en fin de transaction (Commit ou Rollback principalement)

Si donc, un jour vous tentez non pas de supprimer mais d'insérer des lignes en masse, vous allez vous retrouver avec autant de curseurs ouverts que de lignes en insertion ! ( attention au navrant message TOO MUCH OPEN CURSORS...)

il vaut mieux prendre l'habitude de coder des curseurs explicites que vous fermez naturellement vous-même

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Declare
  Cursor C_NEXT IS
  Select ...NEXTVAL From Dual ;
...
Begin
  Open C_NEXT ;
  Fetch C_NEXT Into ... ;
  CLose C_NEXT ;
End;

Vous tiendrez la route dans tous les cas !

[orafrance]

bien vu l'aveugle... c'est vrai que c'est le genre de blague qui peut effectivement poser probléme