Discussion :

[beubeu40]

Bonjour,

J'ai modifié la clé primaire d'une table, pour la passer de 3 colonnes (varchar2 / date / number) à une seule colonne, une séquence numérique tout ce qu'il y a de plus normal.

Lorsque je fais une requête delete, en passant sur cette nouvelle clé primaire, la suppression met 36secondes. Avant cette modification de clé primaire, il y avait un index sur CODECR, et le delete par CODECR était instantanné.
Quelqu'un aurait-il une explication, une piste à explorer pour expliquer ce temps de traitement ?


Je mets des infos sur les manips que j'ai faites.
Il s'agit d'une table ECR, avec comme colonnes
IDECHA VARCHAR2(3)
DTEECR DATE
HORECR NUMBER(4)
CODECR NUMBER(8) (<= séquence)
[...]

La PK était :

ALTER TABLE ECR ADD ( CONSTRAINT PK_ECR
PRIMARY KEY (IDECHA, DTEECR, HORECR)

C'est désormais

ALTER TABLE ECR ADD ( CONSTRAINT PK_ECR
PRIMARY KEY (CODECR)

- j'ai recréé un index sur l'ancienne PK IDECHA/DTEECR/HORECR
- un index unique existe sur CODECR d'après l'onglet Script de TOAD.
- j'ai fait une reprise de données pour les tables filles
- j'ai recalculé les stats sur tout le schéma

Malgré tout, un delete par codecr est très long.

Quel pourrait-être le problème ?
S'il manque des éléments, j'éditerai mon message après vos demandes.

Merci par avance

[nuke_y]

Tu peux dropper tous les index sauf celui de la PK et tenter un delete ? Pour voir si c'est la MAJ des index qui ralentit.

[beubeu40]

J'ai droppé 9 Index (pour 48 colonnes), et n'ai laissé que celui de la PK.
La suppression par delete sur CODECR dure toujours 36secondes.

[xdescamp]

Pourrais-tu nous donner l'ordre SQL qui pose problème et l'explain plan qui va avec ?

[beubeu40]

La requête :

delete from ecr where codecr=2912185

L'explain plan :



A noter qu'un update ou un select est instantanné !

J'avais modifié les clés étrangères des tables qui pointent vers ecr, en créant au préalable une colonne CODECR, puis en reprenant les données.
Je vais supprimer ces clés étrangères des tables qui pointent vers ecr, peut-être ces lenteurs sont-elles dues à des contrôles sur les tables filles ?


Résultat :
En supprimant la clé étrangère de la plus grosse table pointant vers ECR, la suppression passe à 7 secondes.
En supprimant l'ensemble des clés étrangères CODECR, la suppression devient immédiate.

Le problème étant maintenant identifié, quelles sont les pistes de résolution ?
Y a-t-il des manipulations à faire sur les tables ou à la création des clés étrangères pour que le traitement soit plus rapide ?

[mnitu]

...Résultat : en supprimant la clé étrangère de la plus grosse table pointant vers ECR, la suppression passe à 7 secondes.
...

Très probablement que la contrainte est de type ON DELETE CASCADE. 7 secondes pour une suppression par index unique est énorme. Exécutez la suppression avec une trace SQL pour avoir une vision complète de ce qui se passe.

[xdescamp]

Il y a des indexes sur les tables filles pour les colonnes des FK ?

[beubeu40]

Il me semble que non, je regarde, je recrée mes FK et je les indexe, et je reviens vous signaler si ça résout mon problème.
Gros oubli..

[nuke_y]

Mais on peut faire une clé étrangère qui cible une colonne qui n'a pas un index unique ou une clé primaire ?

[mnitu]

Mais on peut faire une clé étrangère qui cible une colonne qui n'a pas un index unique ou une clé primaire ?

Je pense qu'il parle d'indexer les clés étrangères.

[beubeu40]

Oui je parle de la clé étrangère elle-même qui n'est pas indexée, et non la colonne cible.
J'ai rechargé un dump, mon script de modification de clés et reprise de données est en train de tourner, je vous redis ça d'ici une heure.

[beubeu40]

Problème résolu, la suppression est maintenant immédiate.

Il manquait donc des index sur les nouvelles clés étrangères CODECR.
J'ajoute la création de ces index dans mon script, après la reprise de données sur CODECR.

Merci à tous !