problème de charge CPU SUR ORACLE

Bonjour, j'ai un petit soucie avec la commande delete que j'éxécute sur monn instance oracle.

Lors de cette commande, un simple delete sur 40000 enregistrements environ, cela me bloque completement mon serveur et m'affiche 100 % d'utilisation CPU.
Pourtant les commandes SELECT et INSERT passe corretement, les traitements sont effectuer presque instantanement. Il n'y a q'avecc la command DELETE

Config de mon serveur :
PIII 1200 MHz
4,5 Go de RAM
RAID 5

Config de mon instance au niveau mémoire :
Pool partagé : 28 Mo
cache de tampon : 1792 Mo
Zone de mémoire lage pool : 600 ko
Pool java : 32 ko

Nbr d'utilisateur max 700

Sur le gestionnaire de tache mon instance oracle affiche :
CPU time : 1:19:39
Mem usage : 629756 K ( ce qui me parrai énorme)

Si quelqu'un peut m'aider... merci d'avance

Ok c'est le fait que cela commande DELETE génére des informations de redo qui occupe ton temps processeur.

Est ce que tu souhaites vider completement la table ou souhaites tu juste vider un certain nombre de ligne.

En fait, je souhaite vider un certain nombre de ligne de ma table et lorsque que je lance ma requete, ma machine monte a 100% de charge CPU rendant mon instance de production inutilisable. Ce que je me peut me permettre.

Voici ma requete que je tape, avec 40000 enregistrement ce qui est peut :

Code:

---

delete from TABLE1 where IDENTIFIANT in (select ID from TABLE2)

---

[Balises code ajoutées par Helyos]

TABLE2 a bcp d'enregistrement ?

ma formule fétiche ;)

Essaye ceci :

Code:

---

1 2 3

delete from TABLE1 a where exists (select 1 from table2 b where a.IDENTIFIANT = b.id);

---

IDENTIFIANT est bien indexée ?

Si cette solution ne fonctionne pas il faudra alors utiliser une solution PL qui te permettra de commit à interval régulier

avant d'en arriver là, il serait intéressant aussi de voir si les redologs ne sont pas sous-dimensionnés ;)

Citation:

---

Envoyé par orafrance

IDENTIFIANT est bien indexée ?

---

Merci pour ta fomule fétiche mais cela n'a pas résolu le problème, lors de l'exécution de la requete, la charge monte à 100 % me bloquant le serveur.

Non mon IDENTIFIANT n'est pas indexée...

Citation:

---

Envoyé par helyos

Si cette solution ne fonctionne pas il faudra alors utiliser une solution PL qui te permettra de commit à interval régulier

---

c'est ce que je fesais lors de ma procesure Stocker mais cela me fait la meme chose, je ne comprend pas.

Il faut répondre à la question du dimensionnement des redo logs et voir si éventuellement il n'y aurait pas un trigger sur la table en delete ?

Et si il n'y a pas de trigger, est-ce que par hasard il n'y aurait pas des FK avec DELETE CASCADE sur plusieurs niveaux ?

Tout à fait d'accord avec SheikYerbouti et Orafrance

Citation:

---

Envoyé par orafrance

TABLE2 a bcp d'enregistrement ?

---

Sur ma TABLE 2 j'ai environ 410000 enregistrement au total et 11000 pour la TABLE 1

cele ne proviendrai t'il pas du SGA _MAX_SIZE ???

c'est koi la taille de tes redo logs? et de tes RBS

Merci de bien vouloir lire et vérifier toutes nos remarques avant de t'éparpiller dans d'autres directions ;)

Citation:

---

Envoyé par helyos

c'est koi la taille de tes redo logs? et de tes RBS

---

Mes redo logs ont la taille de : 1,048,576 Bytes
et mes RBS en size sont à 8,380,416

Et les DELETE CASCADE ? :?

Citation:

---

Envoyé par orafrance

Et les DELETE CASCADE ? :?

---

idem avec le DELETE CASCADE
je ne sais plus quoi faire.

il faut savoir également que j'ai du faire un dump de ma base et que depuis j'ai ce problème...
Est 'il possible que cela vienne de contrainte d'intégrité ??

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.

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

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

As tu essayés ma méthode?

Citation:

---

Envoyé par crasho007

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 ?

Citation:

---

Envoyé par helyos

As tu essayés ma méthode?

---

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

Citation:

---

Envoyé par SheikYerbouti

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.

Donc ca viendrais du trigger????

Pourrais tu coller le code du trigger stp?

Voici le code du trigger :

Code:

---

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]

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

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

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.

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

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

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 .....

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...

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:

---

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:

---

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 !

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