Précédent   Forum des professionnels en informatique > Bases de données > Oracle
Oracle Forum Oracle : le serveur, les outils, ... Voir F.A.Q Oracle Tutoriels Oracle
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 21/12/2010, 21h10   #1
Membre du Club
 
Inscription : juillet 2007
Messages : 310
Détails du profil
Informations forums :
Inscription : juillet 2007
Messages : 310
Points : 64
Points : 64
Par défaut delete trop long à cause d'une fk ou des stats oracle ?

bonjour,
j'ai une petite question Oracle ou SQL...

J'ai une table OPERATION

OPE_ID ##### OPE_DATE ##### OPE_PRECEDENTE
1 ######## 29/10/10 ######## NULL
2 ######## 29/10/10 ######## NULL
3 ######## 29/10/10 ######## 2
4 ######## 29/10/10 ######## 1
5 ######## 29/10/10 ######## 4

OPE_ID : clé primaire
OPE_PRECEDENTE : foreign key sur la clé primaire OPE_ID

J'ai une requête qui a 38000 enregistrements à supprimer de cette table OPERATION.
Code :
1
2
 
DELETE FROM operation WHERE ope_id IN (SELECT ope_id FROM extr_id_arc_pur);
Nous avons testé sur une base iso-prod en désactivant la contrainte (foreign key FK_OPE_PRECEDENTE) de cette table.

Le temps d'exécution est de 3min.

Nous avons réactivé cette contrainte et réimporter les données de la base et le temps d'exécution est > 6 heures.

Cette colonne OPE_PRECEDENTE peut avoir des valeurs null.

Il y a un index sur cette colonne.

J'aurai voulu savoir s'il est possible que cette contrainte puisse faire ralentir les perfs ? A chaque delete, Oracle que fait-il ? il contrôle les foreign key ?

Autre chose, après le re-import de la base, doit-on recalculer les statistiques oracle ?

En espérant avoir été clair !!!

Merci d'avance.
ekremyilmaz est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 22/12/2010, 14h56   #2
Modérateur
 
Homme Fabien
Ingénieur d'études en décisionnel
Inscription : septembre 2008
Messages : 5 684
Détails du profil
Informations personnelles :
Nom : Homme Fabien
Âge : 34
Localisation : France, Yvelines (Île de France)

Informations professionnelles :
Activité : Ingénieur d'études en décisionnel
Secteur : Arts - Culture

Informations forums :
Inscription : septembre 2008
Messages : 5 684
Points : 10 463
Points : 10 463
Envoyer un message via ICQ à Waldar Envoyer un message via Skype™ à Waldar
Oui, à chaque DELETE Oracle va vérifier l'intégrité référentielle, impacter les index et ça prend du temps.

Supprimer les index et désactiver les contraintes avant de faire la suppression est une pratique courante.

Pour les statistiques ça dépend. Si vous supprimez 38.000 lignes d'une table de 50.000 lignes ou de plusieurs millions. Dans le premier cas il faut recalculer, dans le second c'est à priori pas nécessaire.
__________________
Email : http://scr.im/waldar
Waldar est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 22/12/2010, 16h29   #3
Membre du Club
 
Inscription : juillet 2007
Messages : 310
Détails du profil
Informations forums :
Inscription : juillet 2007
Messages : 310
Points : 64
Points : 64
finalement, il n'y avait pas d'index sur cette colonne (pas en prod) uniquement en dev.
Dans l'environnement isoprod, il n'y avait pas d'index.

On l'a rajouté, on passe de 6h à 3min !!!!!!!

Lorsque nous avions supprimé la contrainte, il n'y avait pas de souci mais en la réactivant, il faisait un full scan

Code :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 
SELECT /*+ all_rows */ count(1) FROM "NAEADM"."OPERATION" WHERE "OPE_ID_PRECEDE                                                            
NTE" = :1                      
 
Plan 1(PHV: 2489153561)
Execution Plan                                                                                                                              
--------------------------------------------------------------------------------                                                            
| Id  | Operation          | Name      | Rows  | Bytes | Cost (%CPU)| Time     |                                                            
--------------------------------------------------------------------------------                                                            
|   0 | SELECT STATEMENT   |           |       |       | 39197 (100)|          |                                                            
|   1 |  SORT AGGREGATE    |           |     1 |     2 |            |          |                                                            
|   2 |   TABLE ACCESS FULL| OPERATION |     1 |     2 | 39197   (2)| 00:07:51 |                                                            
--------------------------------------------------------------------------------
ekremyilmaz est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité Cette discussion est résolue.
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 07h17.


 
 
 
 
Partenaires

Hébergement Web