Discussion :

[marc85]

Bonjour

Lors du chargement d'un datewarehouse sous Oracle, le traitement lancé hier n'est pas encore terminé (déja plus de 20 heures)
Avec la console Oracle Enterprise Manager, je vois que la session a un onglet 'opération longue' qui affiche la dernière instruction :

Code :

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

1
2
DELETE FROM dwh_d_prestation_client
  WHERE to_char(sys_date_debut, 'YYYYMMDD') >= '20130701'

L'opération active est :

Table SCAN DW_DEV.DWH_D_PRESTATION_CLIENT

Qu'est ce qui pourrait causer de tel temps ?
Est-ce un problème de paramétrage ?

Le traitement normal dure 1 h

Merci pour vos réponses

[skuatamad]

Plusieurs possibilités :

• La modification du code
• La supression d'un index
• Un problème au niveau des stats
• Et sans doute d'autres...

Il est étrange de faire un to_char sur la date, un to_date sur le paramètre étant préférable.
Mais j'imagine qu'il existe (ou qu'il existait) un index de fonction sur to_char(sys_date_debut, 'YYYYMMDD').

En tout cas on peut raisonnablement supposer, qu'avant, l'accès à DW_DEV.DWH_D_PRESTATION_CLIENT se faisait via un index et non en FULL SCAN.

[Drawingrom]

Si votre table est partitionnée, vous pouvez également le prendre en compte dans votre requête. Vous devriez vérifier les plans d'exécutions.

Ce delete fait partie des batches normaux de votre DWH ? Ça n'arrivait pas avant ?

[tropiko]

Bonjour ,

Vérifier aussi qu'il n'existe pas d'index invisible sur la table en question.
Trigger ou pas sur la table
faire un test sans to_char :

Code :

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

WHERE sys_date_debut >= sysdate - 17

faire un test avec une FBI (to_char).

Sinon des infos pourront nous aider à vous aider :
Nbre de lignes à supprimer de la table et nombre total de lignes.

A+

[mnitu]

Bonjour
Qu'est ce qui pourrait causer de tel temps ?
...

Et aussi un verrou posé par une autre session.

[marc85]

Merci pour toutes les réponses mais cela ne fonctionne toujours pas

Quelques éléments :
la table en question fait 823788 enregistrements et le programme doit en supprimer 116552

J'ai essayé de faire les suppressions en plusieurs fois en rajoutant un filtre : la suppression de 11750 enregistrements seulement ne fonctionne pas mieux

ce que je ne comprends pas, c'est qu'un delete de 10000 enregistrements ne prend que quelques secondes avec mon autre base (Informix)

Je mets en pièce jointe une copie d'écran d'Oracle Enterprise Manager

Merci d'avance pour vos réponses

[skuatamad]

Il y a peu de donnée, la requête utilise bien un index, donc probablement un problème de verrou :
Questions on Locking

[marc85]

Je viens de visualiser les verrous actifs avec la requète ci-dessous

select username, v$lock.sid, trunc(id1/power(2,16)) rbs,
bitand(id1,to_number('ffff','xxxx'))+0 slot,
id2 seq,
lmode,
request
from v$lock, v$session
where v$lock.type = 'TX'
and v$lock.sid = v$session.sid
and v$session.username = 'DW_DEV';

et le seul verrou qui s'affiche est

USERNAME SID RBS SLOT SEQ LMODE REQUEST
------------------------------ ---------- ---------- ---------- ---------- ---------- ----------
DW_DEV 120 6 25 210599 6 0

et qui correspond à la session qui effectue le delete

Donc je ne pense pas que cela vienne de verrou

Un autre point : que signifie la petite croix rouge en phase de la ligne DELETE dans la copie d'écran jointe à la discussion ?

[pk93100]

Tu peux peut-être essayer:

select * from v$active_session_history where session_id = .... ;

Cette vue te donne l'historique des opérations effectuées par intervalle de 1 seconde ( pour la session donnée dans ce cas ci).

Tu sauras ainsi si ta requête fait quelquechose ou bien si elle est bloquée.
Egalement la vue: v$transaction
Bon courage

[marc85]

ça y est j'ai résolu mon problème :

cela venait du fait qu'il existait des contraintes non indexées dans des tables qui pointaient sur la table dont je voulais supprimer beaucoup d'enregistrements.

J'ai rajouté des index sur ces contraintes et tout est rentré dans l'ordre.

Encore merci pour vos réponses

[ora-2013]

Bonjour ,

J'ai rajouté des index sur ces contraintes et tout est rentré dans l'ordre.

Je n'ai pas bien compris le rapport entre indexer des contraintes et la résolution de votre problème ...
Pourriez-vous svp détailler la solution ( contraintes ? colonnes ? indexes ? ...).
merci.

[marc85]

En fait il manquait des index sur les champs qui comportaient des contraintes d'existence.

Je m'explique :

je veux supprimer un grand nombre de lignes dans la table TPRESTATION de clé primaire CODE_PRESTATION.

Une table TECHEANCE comporte un champ CODE_PRESTATION avec une contrainte d'existence de CODE_PRESTATION dans la table TPRESTATION.

Le problème qui se posait c'est que pour supprimer une ligne dans la table TPRESTATION Oracle allait voir séquentiellement dans la table TECHEANCE si le CODE_PRESTATION que l'on supprimait dans la table TPRESTATION existait dans TECHEANCE et passait alors un temps fou (plus de 20 heures).

J'ai uniquement ajouté un index sur le champ CODE_PRESTATION de TECHEANCE et le delete a durée moins d'une minute.

[tropiko]

Le problème qui se posait c'est que pour supprimer une ligne dans la table TPRESTATION Oracle allait voir séquentiellement dans la table TECHEANCE si le CODE_PRESTATION que l'on supprimait dans la table TPRESTATION existait dans TECHEANCE et passait alors un temps fou (plus de 20 heures).

J'ai uniquement ajouté un index sur le champ CODE_PRESTATION de TECHEANCE et le delete a durée moins d'une minute.

J'imagine que la suppression Maître-Détails se fait via un Nested Loop accéléré par un index sur la table fille ...vous confirmez ?