Discussion :

[devkais]

Salut
J'ai une requête un peu compliqué qui utilise 10 tables partitionnées (même clé).
La clé de partitionnement de chaque table est la colonne ANNEEMOIS.
Tout accès à chacune des 10 tables doit utiliser une clause genre

Code :

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

SELECT ...FROM T1 WHERE ANNEEMOIS = '201305'

J’ai 2 questions :
1/Malgré la présence de cette clause dans chaque accès y a t il un risque qu'Oracle scanne toute
la table au lieu de la partition en question ? si oui dans quel cas et comment empêcher de scanner toute la table ?
2/ Les statistiques ne sont pas à jour sur chaque partition de chaque table.
Si je limite le calcul des statistiques UNIQUEMENT à la partition en question (201305) ,ma requête risque t-elle d'être NON performante ?
Dois je calculer les statistiques sur toutes les partitions de chaque table sachant que ma requête n'utilise que la partition 201305 ? si oui pourquoi ?
Thanks for help ...

[pachot]

Bonjour,

1/ Oui il y a toujours un risque. Une clause WHERE définit le résultat voulu mais ne force pas un certain type d'accès.
Un moyen de le forcer:

SELECT ...FROM T1 partition for ('201305') WHERE ANNEEMOIS = '201305'

2/ Je ne pense pas que les stats des autres partitions influencent quelque chose lorsqu'on est sur une seule partition. Mais les stats globales peut-être. Tous les index sont locaux ?

Cordialement,
Franck.

[Mohamed.Houri]

Lorsque la clé de partitionnement est présente dans la where clause il y aura forcément un "partition pruning" ou "partition elimination" même en l'absence d'index

Lorsque le CBO touche une seule partition il utilisera les statistiques au niveau partition.

Lorsque le CBO touche plusieurs partitions il utilisera les statistiques au niveau global

Mais, attention, ce qui précède concernant les statistiques est trop simple pour ne pas aller lire les autres cas de figures que certains ont déjà publiés

http://jonathanlewis.wordpress.com/2...rtition-stats/

[devkais]

bonjour
Les indexes de chaque table partitionnée sont tous locaux dans notre cas.
Si je dois calculer les stats globales , à quel moment dois-je le faire ?
après avoir calculer les stats au niveau de la partition en question ?
Est-ce obligatoire pour l'optimiseur 11g de calculer les stats globales ?
merci

[pachot]

Vu que les stats des partition peuvent être utilisées pour en déduire certaines stats globales: après. On peut aussi utiliser Incremental Statistics en 11g.

Est-ce obligatoire pour l'optimiseur 11g de calculer les stats globales ?
Obligatoire, non. Mais si une requête touche à toutes les partitions de mauvaises stats globales peuvent amener à un mauvais plan.

[Mohamed.Houri]

bonjour
Les indexes de chaque table partitionnée sont tous locaux dans notre cas.

Je me demande si vous avez dans vos applications des requêtes qui n'utilisent pas la clé de partitionnement ANNEEMOIS . Si c'est oui, je ne serai pas étonné d'apprendre que vous avez des problèmes de performance dans ces requêtes vu que tous les indexes sont locaux.

[devkais]

Je me demande si vous avez dans vos applications des requêtes qui n'utilisent pas la clé de partitionnement ANNEEMOIS . Si c'est oui, je ne serai pas étonné d'apprendre que vous avez des problèmes de performance dans ces requêtes vu que tous les indexes sont locaux.

Toutes nos requêtes utilisent SYSTEMATIQUEMENT cette clause :
ANNEEMOIS='201205' donc pas de souci.
Le partitionnement est fait uniquement pour les tables et eventuellement leurs indexes si la table est volumineuse.
Sinon la colonne ANNEEMOIS existe dans toutes les tables.
Si table partitionnée :
Les stats sont pour le moment calculées sur chaque partition de façon isolée.
Pas de stats globales pour l'instant ...
Si table non partitionnée (car petite) alors calcul de stats sur toute la table.
Merci les Experts