Optimisation "GROS" SELECT dans une table partitionnée

Bonjour,

En BENCH depuis quelques jours sur un traitement d'extraction de données (un gros SELECT dans une table contenant ~6 Million d'enregistrements, droppée et recréée chaque jour + exécution des statistiques avant le SELECT) devant passer vers une architecture 2 tiers (1 serveur applicatif et 1 serveur de base de données sous ASE 12.0 avec 6 engines)
Le serveur de BDD est un HP Unix 11i avec 6 CPU
La table NEUF_CDR_DATA_TODAY est partitionée (12 et lock datarows)
Une interface 100Mb est en place entre les 2 serveurs (sera 1Gb en Production)

J'ai essayé plusieurs optimisation : de jouer avec les paramètres "max parallel degree" et "max scan parallel degree" ; mais le traitement reste toujours aussi long : ~1h20 pour traiter 400.000 enregistrements.

Avez-vous une piste d'optimisation ? ou de correction à apporter à la configuration du dataserver ?
D'avance merci

Ci-joint,
sp_sysmon.zip : résultat de sp_sysmon pendant l'exécution du traitement d'extraction
sp_configure.zip : configuration du dataserver ASE 12.0
show_plan.zip : show_plan de la requête d'extraction
requete_extraction.zip : la requête d'extraction (le gros SELECT)
table_neuf_cdr_data_today.zip : détail de la table NEUF_CDR_DATA_TODAY

Bonjour,

j'ai regardé votre requete SQL.
je ne comprends pas l'utilité de votre

Code:

---

1 2	AND EXISTS (select 1 from #extract_dailt_CDR_VGA9 tmp1 where cmf.parent_id = tmp1.account_no)

---

puisque vous avez deja une jointure :
si

Code:

---

tmp.account_no = cmf.parent_id

---

est vrai, fatalement votre clause EXISTS l'est aussi.

Avez vous essayé de mettre un index sur votre table temporaire (account_no) ?

Bon courage

Exact, j'ai retire la clause suivant dans le WHERE "AND EXISTS (SELECT 1 FROM #extract_dailt_CDR_VGA9 tmp1 where cmf.parent_id = tmp1.account_no)". Il est vrai que cela est redondant.

Je viens d'ajouter un index à la table temporaire; mais toujours pareil

Je pense que mon problème est plus dans la configuration du dataserver que dans la requête ....

Si quelqu'un à une idée je suis preneur car j'ai fait le tour ?

dans 90% des cas, les mauvaises perf d'un traitement sont sous-jacents a l'écriture du traitement en lui même. Optimiser les requêtes est une clé essentielle avant d'analyser les performances de vos serveurs.

Quand vous aurez optimisé au mieux vos requêtes et que les performances sont tout autant lamentables, alors il sera temps de mettre en cause la configuration du serveur.

Pouvez vous reposter le show plan apres vos modifications ?
Quelles sont les volumétries des differentes tables concernées ?
Les jointures des tables sont elles faites sur des colonnes indexées.
Les clauses sont elles réalisées sur les critères les plus discriminants (important pour vos produits carthésiens).

Bon courage