Discussion :

[MoitieDeCigare]

Bonjour,
Cette requête

Code :

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

DELETE FROM PROJ WHERE ISCEN=1268;

met presque 5 minutes à s'executer, sachant que la table PROJ contient au départ environ 106000 enregistrements, et que cette requête en supprime 1000. Le champ ISCEN n'entre pas dans la définition d'une clé étrangère, peut être NULL, et est indexé.
La table PROJ contient une trentaine de champs, de type NUMBER, VARCHAR2, DATE ou CHAR.

Les requêtes passées avant l'appel de celle-ci s'effectuent toutes dans des temps normaux, et si je fais un UPDATE de cette table avec la même clause, il s'effectue en à peine une seconde.

Auriez vous une idée de la provenance de cette lenteur ?

Merci d'avance.

[Yorglaa]

est-ce que cette table (et pas juste le champ) est référencée par d'autres clef étrangère avec des "delete cascade" ?
auquel cas les suppression vont devoir se faire en cascade pour toutes les lignes référencées par les lignes que tu supprimes de la table mère

[MoitieDeCigare]

Oui, elle est elle-même référencée, mais justement, les requêtes précédant ce DELETE portent justement sur la suppression des enregistrements des autres tables où elle est référencée dans les clés étrangères.

[orafrance]

est-ce qu'il y a un trigger ? Tu es en AUM (UNDO) ? Quelles stats tu as dans v$sesison_wait pendant la supression ?

[Yorglaa]

si tu n'es pas dans un environnement de prod, essaye de désactiver ces clef étrangères...

même si tu delete les lignes filles d'abord, Oracle va peut-être quand même faire le contrôle sur les lignes restantes des tables filles.

[aline]

Bonjour,

Une autre possibilité:
As-tu beaucoup d'indexes sur ta table ou tu fais ton delete?
Cela peut le ralentir énormement..

[orafrance]

est-ce qu'elle est partitionnée ?

[MoitieDeCigare]

Yorglaa >> Effectivement en désactivant les FK, la suppression se passe beaucoup plus rapidement, dans des temps de l'ordre de la seconde.

Aline >> Une quinzaine d'indexes, ça fait beaucoup ?

je vais chercher du côté des FK, si je peux faire quelque chose...

[orafrance]

15 indexes ça commence à faire trop en effet

[aline]

Yorglaa >> Effectivement en désactivant les FK, la suppression se passe beaucoup plus rapidement, dans des temps de l'ordre de la seconde.

As tu indexé tes fk?
Sinon, tu te tape des tables access full sur tes tables qui référencent ta table principale à chaque delete.

Aline >> Une quinzaine d'indexes, ça fait beaucoup ?

.

oui et cela impacte surement pas mal, mais peut être que le problème principal se trouve au niveau des fk

[remi4444]

A partir d'une certaine échelle de base (très très grosse), il est conseillé de ne pas mettre de clef étrangère du tout. On considère qu'en régime de croisière, l'applicatif à été suffisament testé et validé et n'a pas à sous-traiter à la base les controles d'intégrité référentielles...

[aline]

A partir d'une certaine échelle de base (très très grosse), il est conseillé de ne pas mettre de clef étrangère du tout. On considère qu'en régime de croisière, l'applicatif à été suffisament testé et validé et n'a pas à sous-traiter à la base les controles d'intégrité référentielles...

Bonjour Remi,
Qui c'est ce on?
Pour rappel, les clés étrangères sont très importantes pour les problème d'intégrité de données mais pas seulement! Même si u es sur de toi, les clés étrangères ont une autre utilité: l'optimisation de requête.
en effet, Pour Oracle, c'est un peut la traduction d'une logique fonctionnelle.
Perso, je n'ai jamais entendu cela et suis totalement contre cette affirmation.
mais cela n'engage que moi et cela sort du cadre de ce post!

amicalement!

[remi4444]

"on" ce sont ces messieux de chez oracle... je suis déja intervenu sur une base de plusieurs teras avec une activité monstrueuse, qui avait été conçue en coordination avec oracle, ça m'avait surpris aussi au début cette absence de FK. Mais avec une telle dimension, les petites vérifications occasionnées par chaque controle l'intégrité étaient autant d'évenement consomateurs. Et plus les tables sont grosse, plus c'est consomateur. Pour information, je travaille en ce moment sur une base sybase de 8 Téras faisant partie d'un gros progiciel de facturation téléphonique, et il n'y a pas là non plus l'ombre d'une clef étrangère.

Le sujet de ce post en est la parfaite illustration d'ailleurs. Si on est obligé de créer des index juste pour que ces controles ne rament pas trop, avoue que c'est un peu génant. Mettre des clef étrangères pour une petite application où on a pas envie de blinder par de la bonne programmation la cohérence des données, c'est normal, on délèque à la base cette partie fonctionnelle. Mais ce faisant, on lui fait faire tout un tas de travail inutile. A petite échelle, c'est clair que ce n'est pas pénalisant par rapport au gain en sécurité et à l'économie de developpement que ça apporte. Mais j'ai déja vu une base ou le simple passage de stats sur les index se planifiait sur 12 jours! et là crois moi qu'on fait la chasse aux gaspi

Quant à l'optimisation, je ne crois vraiment pas que ça joue le moins du monde. Si on veux optimiser les jointures, il faut mettre des index ou faire carément des clusters, mais je vois pas en quoi les clef étrangères jouent un role, cepenant si tu as des sources à ce sujet ça m'interresse....

Sinon, je pense qu'on peut trouver un juste milieu. Dans une base, il y a bien souvent une foule de petites tables et seulement quelques tables très très grosse. Le bon compromis est de laisser FK partout mais de desactiver celles en rapport avec ces quelques tables "hors normes"

[nuke_y]

les clés étrangères ont une autre utilité: l'optimisation de requête.

Tu nous avais déjà parlé de ça dans un autre post effectivement, mais je t'avoue que je n'ai jamais pu le constater par moi même (même si je te fais confiance). Cependant dans le cas de TRES GROSSES bases comme celles dont parle Rémi, j'imagine que les requêtes sont plus ou moins figées (seuls les variables changent) et leur plan d'exécution aussi.

Dans ce cas, est-ce que les fk jouent vraiment un rôle d'optimisation, ou est-ce qu'elles ne sont utiles qu'à l'établissement du plan d'exécution ?

[remi4444]

Dans ce cas, est-ce que les fk jouent vraiment un rôle d'optimisation, ou est-ce qu'elles ne sont utiles qu'à l'établissement du plan d'exécution ?

ça voudrait dire un peu la même chose
Je peux me tromper, mais je ne crois ni à l'un ni à l'autre. On pourrait imaginer une influence dans l'optimisation si les rowid de la table de référence était sauvegardés dans les même blocks que les valeurs de colonnes FK des autres tables pointant sur la première, mais je n'ai jamais entendu parlé de choses pareilles chez oracle.

Lorsqu'on regarde la doc oracle de tunning, on ne voit pas non plus mentionné les FK...

http://download-uk.oracle.com/docs/c...33/index.htm#F
Donc si quelqu'un a des sources montrant que les FK ont une influence positive sur l'optim, je suis preneur...

[nuke_y]

Ce que je voulais dire c'est que soit les FK jouent un rôle d'optimisation SEULEMENT à l'établissement du plan d'exécution, soit elles jouent un autre rôle d'optimisation, et dans ce cas lequel ?

Si elles jouent un rôle SEULEMENT à l'établissement du plan d'exécution, elles ne serviront à rien si les requêtes et leurs plans d'exécutions sont figés (grosse applis).