Discussion :

[marvelromy]

Boujour à tous,

Je recherche en ce moment une meilleur methode de gestion de mes tables partionnées.

- Comment savoir quand mes partitions sont FULL afin d'en créer d'autres?
- Comment voir l'état de mes partitions?
- Quelle précaution prendre pour une meilleur gestion des tables partitionnées?


Merci

[laurentschneider]

- Comment savoir quand mes partitions sont FULL afin d'en créer d'autres?

une partition n'est jamais FULL

- Comment voir l'état de mes partitions?

quel genre de status recherches-tu? Des partitions de tables ou d'index? Les partitions d'index UNUSABLE sont dans USER_IND_PARTITIONS

- Quelle précaution prendre pour une meilleur gestion des tables partitionnées?

Cela dépend. Parfois le partitionement se fait de manière très naturelle, style une partition par mois. Parfois il faut un peu plus réfléchir et effectuer quelques tests de performance

[orafrance]

- Quelle précaution prendre pour une meilleur gestion des tables partitionnées?

définit un extent initial pas trop gros si tu as beaucoup de partitions et particulièremement si elles sont vides pour le moment. En effet, le INITIAL s'applique à chaque partition ça peut donc être vite un facteur de consommation d'espace disque. Prends garde aussi à la définition de la clé de partitionnement notamment sur l'impact concernant les indexes qui doivent alors être globaux ou locaux (partitionnés).

[marvelromy]

Je comprend pas trop,
comment créer un extent initia(script d'exemple), comment l'affecter à mes partitions, et comment observer son influence comme indicateur de l'état d'occupation.

C'est l'état de mes partitions de tables que je veux suivre

Mes partitions sont pour la pluspart déjà occupées!

merci

[orafrance]

Bon... qu'est ce que tu veux exactement ? Suivre une table déjà partitionné ou créer des partitions et avoir une méthodologie pour le faire ? Quand au INITIAL, je ne peux que te renvoyer à la doc

[marvelromy]

Je veux suivre une table partitionnée!

[orafrance]

OK, donc on a répondu

[marvelromy]

Merci beaucoup je pense que je comprend maintenant.

[laurentschneider]

C'est l'état de mes partitions de tables que je veux suivre

C'est-à-dire?
Tu veux savoir quoi exactement? Le nombre de lignes par partitions? Le nom du Tablespace correspondant?

[marvelromy]

Je veux savoir quand est ce que je dois créer d'autre partitions pour ma table?

Je reformule la question,

Quels critères observer pour décider qu'il me faut créer de nouvelles partitions?

merci

[orafrance]

ça dépend du type de partition..
par hash : jamais
par liste : quand tu a besoin d'une autre valeur
par range : là tu peux regarder le contenu de la partition de débordement (MAXVALUE)... dans l'idéal elle est vide et sinon, au moins pas trop déséquilibrée.

[laurentschneider]

oui, il n'y a pas de règle.

Pour range, tu peux utiliser un partitionement par intervalles si tu as 11g. Sinon tu peux créer une partition par mois par exemple. Dans ce cas tu peux rajouter des partitions chaque mois, ou par avance pour les prochains mois.

Merci de toujours préciser la version

En gros il faut que tu nous dises pourquoi tu partitiones, comment tu partitiones, et ensuite quelle est la raison pourquoi tu voudrais rajouter des partitions.

Comme déjà dit, il n'y a pas de Status, il n'y a pas de Partition full, une partition peut faire quelque méga ou plusieurs giga, c'est à toi de faire ton design.

[marvelromy]

Je ne sais comment vous remercié car les choses deviennent de plus en plus claire pour moi.
Ma base de données reçoit plus de 200.000 enregistrements par jour dans une de mes tables qui a aujourdhui prés de 490 partitions sous le modèle:

nomtab_date_du_jour

exemple: nomtab20071204 ....

Il arrive que des traitements ne se font plus parceque je n'est pas créer d'autres partitions. alors je crais une partion pour chaque jour. j'ai alors créer des partition d'avance pour des jours récullés tel que nomtab20080101.

Alors je me demandais comment avoir un indicateur pour me signaler qu'il faut une nouvelle partition.

mais avec vos explications je commence à commprendre. je pense approfondir mes recherche dessu et voir comment en faire profiter d'autre.

Si vous avez des explications additionnelles je les attends.

- version oracle 9ir2
- partition range

merci beaucoup!

[orafrance]

déjà faut peut-être remettre la régle en question parce que 200000 lignes par partition c'est pas énorme... peut-être insuffisant. Les SELECT ne sélectionne les lignes que d'une journée ?

[marvelromy]

Non!
Les select s'étendent sur toutes les données de la table,
mais il y a beaucoup de select qui se font sur interval de date.

[orafrance]

alors je mettrais ma main au feu qu'au mieux les partitions sont trop petites et au pire que c'est pas du tout une bonne stratégie de partitionnement

D'ailleurs tu n'a probablement que des indexes locaux (sinon tu aurais parler d'index UNUSABLE ) alors que ça peut être très mauvais si tu parcours plusieurs partitions

[laurentschneider]

oui, peut-être un partitionement par mois et un sous-partitionement par HASH, qu'en penses-tu ?

A+
Laurent

[orafrance]

Oui à condition d'avoir une colonne unique pour le HASH

[laurentschneider]

ce n'est pas une condition

Code :

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

1
2
3
4
5
6
7
8
 
create table t (d,n) 
  partition by range (d) 
    subpartition by hash(n) subpartitions 2 
  (partition values less than (date '2000-01-01')) 
as select hiredate, sal from emp;
 
Table created.

bon c'est vrai qu'il vaut mieux éviter une colonne avec 99% des données qui soient nulles. La clé primaire est une colonne assez naturelle

Edit : ex où la clé n'est pas unique

Code :

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

1
2
3
4
5
6
7
8
9
10
11
select * from t subpartition (sys_subp5) order by n;
D                  N
--------- ----------
22-FEB-81       1250
28-SEP-81       1250
23-JAN-82       1300
09-JUN-81       2450
01-MAY-81       2850
19-APR-87       3000
03-DEC-81       3000
17-NOV-81       5000

[orafrance]

en effet, ce n'est pas une obligation dans l'absolu en revanche pour avoir une répartition égale entre toutes les partitions de hashage c'est incontournable

Et il doit y avoir 2^n partitions : 2,4,8,16,32, etc...