Bonjour à tous,

Je suis en train de bosser sur l'archivage des données de ma BDD. Sauf que toutes les tables sont un peu liées, donc en fait, je ne compte faire une suppression que sur une seule table et laisser faire le reste du boulot au DELETE CASCADE pour purger le reste.

Soucis 1 : suppression d'une ligne de donnée : 5 secondes.

Soucis 2 : j'ai 350 000 lignes à supprimer.

Soucis 1 + Soucis 2 => 350 000 * 5 secondes = 20 jours.

Je voudrais donc savoir pourquoi ça prend autant de temps pour faire un simple delete (enfin, 15 deletes si on prend en compte les CASCADE).

Y a-t-il un moyen simple pour savoir sur quelle table le delete prend tant de temps ?

Je suis sous Oracle SQL Dev.

Merci

Bonjour,

Tiffado a écrit:

suppression d'une ligne de donnée : 5 secondes

C'est énorme et pas tout à fait normal ... C'est surprenant car les contraintes de clé étrangère implique l'existence d'index sur les colonnes impliquées ... Donc la seule explication possible pour moi c'est l'hyper volumétrie d'une des tables impliquées (et de son index du coup) ...

Le EXPLAIN ne détaillera de toute façon pas ce qui se passe "en cascade" ... Peut-être activer une trace et observer le log a posteriori d'un DELETE ?

Après la latence ne peut-elle pas provenir du serveur ? Le SQL developper est en local ou distant ? La latence n'est-elle pas présente aussi sur d'autres requêtes plus communes ...

Après avoir faire des DELETE a la main sur chaque table liée, j'ai trouvé celle qui prend du temps. Sur cette table, c'est 1s/ligne le DELETE.

Et le constat, c'est que c'est bien la plus volumineuse du lot. Mais ca reste du 14M de lignes alors que les autres tables de 4M de lignes ne posent pas le moins soucis (ca va 50 fois plus vite).

Et pour le coup, le DELETE que j'ai tenté se base sur la PK.

Si je fais un SELECT, ça prend 50ms, et un DELETE 50s. (j'ai mis 10 lignes à DELETE). La seule explication que j'ai pour le moment, c'est que c'est la mise à jour des indexs qui fait prendre du temps. Mais bon, a part casser les index, faire mon DELETE et reconstruire les index par le suite, je vois pas quoi faire.

Tiffado a écrit:

a part casser les index, faire mon DELETE et reconstruire les index par le suite, je vois pas quoi faire.

Je pense que c'est la meilleure solution ... dans l'immédiat ...

Après tu pourras te pencher sur de partitionnement ou de l'archivage physique avec consolidation ... 14M ça commence à faire quand même ...

Bah c'est le but en fait de faire de l'archivage.

Mais ca implique à un moment donné de virer les lignes que j'ai pu archivé, c'est la que ça me pose soucis.

EDIT Avancé de mes recherches.

Je peux faire ce que je veux, je n'ai aucun gain....

J'ai viré tous les indexs de ma table (sauf celui de la PK), j'ai fait mon DELETE, et ça prend autant de temps. Y a-t-il moyen de virer aussi l'index de la PK ? je tombe à cours d'idée la

-
Edité par Tiffado 28 mars 2018 à 15:56:52

Désactive les archivelogs, tu pourrais avoir un gains, sinon vérifie que tu n'as pas de trigger on delete

Je n'ai aucun trigger sur la table.

Pour les archivelogs, je vais regarder ca, mais je vois pas en quoi les archivelogs plomberais les perfs uniquement sur le DELETE d'une table bien précise.

Sur de la suppression/écriture en masse les archivelog peuvent te plomber l'écriture (double écriture).

Sinon peux tu montrer la structure de la table ?

J'ai fait des essais avec des échantillons plutot léger. Genre 50 lignes, mais la constante est la : 1sec par ligne sur ma table.

J'ai dit 5 secondes dans mon 1er post car le delete cascade faisait en moyenne delete 5 lignes sur la table par ligne sur la table de départ.

-
Edité par Tiffado 29 mars 2018 à 10:28:48

Tu a beaucoup de table qui référence celle-si ?

Quand tu Delete/INSERT, le SGBD revalide les clefs, ce qui peux prendre potentiellement du temps, essaye juste pour le test de désactiver les contrainte FK de ta base, si le problème de lenteur disparait, le problème sera liée au trop grand nombre de référence dessus

( https://blog.devart.com/how-to-disable-all-foreign-keys-in-oracle-scheme.html )

Je n'ai que 2 tables qui ont une FK vers celle ci.

Et j'ai essayé en purgeant ces 2 tables avant de purger celle qui prend du temps (donc le delete cascade ne fait rien quoi), mais aucune amélioration.

Essaye de faire un EXPLAIN PLAN sur ton delete

Déjà fait, rien de particulier à en dire, il passe par mon index de la PK et tout.

Essaye de creer une table avec le même nombre de colonne et en copiant les données sans reprendre les index (sauf l'index que tu utilise pour filtrer) et voir si il y aussi le même problème au quel cas le problème viendrai de la volumétrie, sinon cela viendrait d'un index/FK

Ok, c'était la piste qu'on avait effectivement, mais le fait que tu valides l'idée est rassurant