[10g] Table partionnée (by hash)

Version imprimable

04/02/2010, 14h56
macben

[10g] Table partionnée (by hash)

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". :mouarf:

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é) ? 8O

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.
04/02/2010, 15h05
mboubidi

Citation:

Envoyé par 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". :mouarf:

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é) ? 8O

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.
05/02/2010, 08h37
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)

Citation:

Envoyé par marsup077

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:

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:

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

05/02/2010, 13h27
Laurent_du_78

Citation:

Envoyé par 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)

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
05/02/2010, 17h24
scheu

Citation:

Envoyé par macben

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) ?
18/02/2010, 11h31
macben

Citation:

Envoyé par scheu

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.