Discussion :

[macben]

Bonjour,

Je suis en train de créer des tables partionnées "by hash".

Je suis déjà supris qu'il faille désigner une colonne car dans ma compréhension du truc Oracle "se débrouille".

Du coup je me trouve à devoir préciser une colonne sans savoir laquelle sélectionner, dois-je lui indiquer une colonne discriminante (exemple la PK) ou une colonne plus générique (exemple la nationalité) ?

J'en profite pour vous demander des conseils sur le fait d'associer un tablespace unique par partition, avantages, inconvénients ?

Merci pour vos réponses.

[mboubidi]

Bonjour,

Je suis en train de créer des tables partionnées "by hash".

Je suis déjà supris qu'il faille désigner une colonne car dans ma compréhension du truc Oracle "se débrouille".

Du coup je me trouve à devoir préciser une colonne sans savoir laquelle sélectionner, dois-je lui indiquer une colonne discriminante (exemple la PK) ou une colonne plus générique (exemple la nationalité) ?

J'en profite pour vous demander des conseils sur le fait d'associer un tablespace unique par partition, avantages, inconvénients ?

Merci pour vos réponses.

Bonjour,
vous lui donner la colonne la plus importante pour les recherches (a mon avis) et ce que je fait avec mes BD, pour les TBS cela te facilite la gestion d'espace si tu opte pour l'archivage et mieux géré ton storage.
Salutations.

[marsup077]

Bonjour,

Pour compléter un peu la réponse de mboubidi :
- en effet la colonne la plus discriminante doit être utilisée comme clé de partitionnement. Pour les partitions by hash je sais pas, mais dans le cas des partitions by range,, la clé de partitionnement doit faire partie de la primary key
- mettre un tbs différent par partition n'est pas obligatoire mais ça facilite la gestion de l'espace. Tu peux ajouter/supprimer des partitions sans fragmenter l'espace (puisqu'il est propre à chaque partition)

[Ahmed AANGOUR]

Bonjour,

... Pour les partitions by hash je sais pas, mais dans le cas des partitions by range,, la clé de partitionnement doit faire partie de la primary key
...

Non dans le cas des partitions by range la clé de partitionnement ne doit pas forcément faire partie de la PK:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
SQL> CREATE TABLE t (
  2  id NUMBER,
  3  d1 DATE,
  4  n1 NUMBER,
  5  n2 NUMBER,
  6  n3 NUMBER,
  7  pad VARCHAR2(4000),
  8  CONSTRAINT t_pk PRIMARY KEY (id)
  9  )
 10  PARTITION BY RANGE (n1, d1) (
 11  PARTITION t_jan_2007_1 VALUES LESS THAN (1, to_date('2007-02-01','yyyy-mm-dd')),
 12  PARTITION t_feb_2007_1 VALUES LESS THAN (1, to_date('2007-03-01','yyyy-mm-dd')),
 13  PARTITION t_mar_2007_1 VALUES LESS THAN (1, to_date('2007-04-01','yyyy-mm-dd')),
 14  PARTITION t_oct_2007_4 VALUES LESS THAN (4, to_date('2007-11-01','yyyy-mm-dd')),
 15  PARTITION t_nov_2007_4 VALUES LESS THAN (4, to_date('2007-12-01','yyyy-mm-dd')),
 16  PARTITION t_dec_2007_4 VALUES LESS THAN (4, to_date('2008-01-01','yyyy-mm-dd'))
 17  );
 
Table crÚÚe.

Tu dois confondre avec le fait qu'un Index unique pour être LOCAL doit contenir la clé de partitionnement:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
SQL> drop table t purge;

Table supprimÚe.

SQL> CREATE TABLE t (
  2  id NUMBER,
  3  d1 DATE,
  4  n1 NUMBER,
  5  n2 NUMBER,
  6  n3 NUMBER,
  7  pad VARCHAR2(4000),
  8  CONSTRAINT t_pk PRIMARY KEY (id) using INDEX LOCAL
  9  )
 10  PARTITION BY RANGE (n1, d1) (
 11  PARTITION t_jan_2007_1 VALUES LESS THAN (1, to_date('2007-02-01','yyyy-mm-dd')),
 12  PARTITION t_feb_2007_1 VALUES LESS THAN (1, to_date('2007-03-01','yyyy-mm-dd')),
 13  PARTITION t_mar_2007_1 VALUES LESS THAN (1, to_date('2007-04-01','yyyy-mm-dd')),
 14  PARTITION t_oct_2007_4 VALUES LESS THAN (4, to_date('2007-11-01','yyyy-mm-dd')),
 15  PARTITION t_nov_2007_4 VALUES LESS THAN (4, to_date('2007-12-01','yyyy-mm-dd')),
 16  PARTITION t_dec_2007_4 VALUES LESS THAN (4, to_date('2008-01-01','yyyy-mm-dd'))
 17  );
CREATE TABLE t (
*
ERREUR Ó la ligne 1 :
ORA-14039: les colonnes de partitionnement doivent former un sous-ensemble de
colonnes clÚs d'un index UNIQUE

[Laurent_du_78]

Bonjour,

Pour compléter un peu la réponse de mboubidi :
- en effet la colonne la plus discriminante doit être utilisée comme clé de partitionnement. Pour les partitions by hash je sais pas, mais dans le cas des partitions by range,, la clé de partitionnement doit faire partie de la primary key
- mettre un tbs différent par partition n'est pas obligatoire mais ça facilite la gestion de l'espace. Tu peux ajouter/supprimer des partitions sans fragmenter l'espace (puisqu'il est propre à chaque partition)

Le choix de la partition du BY HASH dépend des derniers bit de la colonne utilisée.
Donc :
- colonne discriminante (et très utilisée dans les requêtes)
- les valeurs ne doivent pas se terminer par les mêmes caractères, sinon tous va dans une seule partition
- le nombre de partitions est une puissance de 2, sinon les partitions ne sont pas équilibrées

[scheu]

J'en profite pour vous demander des conseils sur le fait d'associer un tablespace unique par partition, avantages, inconvénients ?

En même temps quel est l'intérêt de partitionner par hash si ce n'est pour pouvoir répartir tes partitions de manière homogènes sur plusieurs disque (donc sur plusieurs tablespaces différents) ?

[macben]

En même temps quel est l'intérêt de partitionner par hash si ce n'est pour pouvoir répartir tes partitions de manière homogènes sur plusieurs disque (donc sur plusieurs tablespaces différents) ?

Le but final est d'augmenter les performances en lecture de la table.