DBMS_STATS : lien entre partname et granularity

Bonjour,

Je souhaiterais savoir si il y a un lien entre le partname et la granulariry au niveau du package DBMS_STATS (version Oracle 9.2.0.8).

Dans le cas suivant, que fait Oracle ?

Code:

---

1 2 3 4 5 6 7

DBMS_STATS.GATHER_TABLE_STATS( ... partname => Nom_Partition, ... granularity => 'ALL', );

---

Et à l'inverse ?

Code:

---

1 2 3 4 5 6 7

DBMS_STATS.GATHER_TABLE_STATS( ... partname => NULL, ... granularity => 'PARTITION', );

---

ça ne me semble pas avoir beaucoup de sens mais j'aimerais savoir si il faut vraiment être cohérent dans la syntaxe et ce que choisit Oracle dans ces cas là.

Merci

Bonjour,

Voici un cas que j'au utilisé recement :

Code:

---

1 2	DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>'CLI' ,TABNAME=>'C_CLIENT', PARTNAME=>'S200906', GRANULARITY=>'PARTITION', CASCADE=> TRUE);

---

Sans le paramétre GRANULARITY=>'PARTITION', Oracle calcul les stats sur la partition et continue tout de même à le faire sur les autres partitions.

LBO72.

Citation:

---

Envoyé par iSylvain

Bonjour,

Je souhaiterais savoir si il y a un lien entre le partname et la granulariry au niveau du package DBMS_STATS (version Oracle 9.2.0.8).

Dans le cas suivant, que fait Oracle ?

Code:

---

1 2 3 4 5 6 7

DBMS_STATS.GATHER_TABLE_STATS( ... partname => Nom_Partition, ... granularity => 'ALL', );

---

Et à l'inverse ?

Code:

---

1 2 3 4 5 6 7

DBMS_STATS.GATHER_TABLE_STATS( ... partname => NULL, ... granularity => 'PARTITION', );

---

ça ne me semble pas avoir beaucoup de sens mais j'aimerais savoir si il faut vraiment être cohérent dans la syntaxe et ce que choisit Oracle dans ces cas là.

Merci

---

Bonjour,

Granularity all : donne les statistiques niveau table ,partition,souspartition

Granularity partition : s'arrete aux partitions, ne fait pas les stats globaux (pas de stats pour la table , ni pour les souspartitions)


voir note metalink Doc ID: 225473.1
et
Note 175258.1

Merci pour vos réponses. ;)