Discussion :

[LEK]

Bonsoir,
nous travaillons sur un traitement d'import qui "doit" (c'est les clients qui exigent) se faire sur une base OLTP alors que ceux-ci continuent de travailler.
La base en question contient en fait les données de plusieurs opérateurs qui utilisent les mêmes applicatifs mais leurs données sont cloisonnées (pas de partitionnement mais une clé permet d'identifier les données propres à chacun).
Lorsqu'un opérateur lance un import de la base des contacts, nous sommes donc sensés faire du efface et remplace des données de celui-ci sans perturber les autres.
Le problème que je rencontre c'est que mon delete :

Code :

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

1
2
 
delete from tab_contact where num_op=20;

met une dizaine de minutes pour s'exécuter. Et du coup ce sont les 6 autres opérateurs qui en payent aussi les frais car plus personne ne peut travailler avec
=>L'opérateur 20 (num_op=20) occupe effectivement 40% des enregistrements de la table.
=> La table tab_contact est indexée sur le champ num_op mais pour la requête précédente c'est un full scan qui est fait (probablement du au fait que 40% des données doivent être couvertes...) : peut-on forcer l'utilisation de l'index et y aurait il u intérêt ? Ou doit on plutôt désactiver les index pendant l'opération?
=> On a peur de passer par un CTAS alors que des utilisateurs utilisent les mêmes tables .

Le nombre de lignes dans la table pour l'opérateur en question et de l'ordre de 100 000 lignes.

Ma question est donc de savoir comment optimiser cette suppression en limitant la gène dans le travail des utilisateurs connectés (quitte à locker les tables quelques secondes si nécessaire). Des idées ?

[Rams7s]

Faites une trace étendue. Ça vous permettra d'enlever le mot probablement.
Parce que un delete ça peut aussi devoir vérifier des clefs étrangères, etc...

[LEK]

Je vais verifier en effet.

[Waldar]

En faisant une suppression par lot.
Vous supprimez 1000 lignes, vous committez, vous recommencez tant qu'il y a des lignes à supprimer.

Attention, ces commit intermédiaire vont flinguer la transaction globale qui ne sera plus intégralement récupérable, il faudra passer par des reprises ou du flashback si vous voulez revenir en arrière.

[mnitu]

En faisant une suppression par lot.
Vous supprimez 1000 lignes, vous committez, vous recommencez tant qu'il y a des lignes à supprimer.

Ca ne peut rien améliorer en termes de performance au contraire!
Est-ce que un merge c'est envisageable ? Mais avant tout tracez pour avoir les détails d'où le temps passe.