Tablespace affecté et option logging modifiés lors de la création d'objets

Version imprimable

Bonjour à tous.

Je suis confronté à un petit souci assez étrange:

Je crée des tables, avec une option NOLOGGING, affectées à un tablespace TBS_TOTO.

Puis, je crée les PK dans des instructions ALTER TABLE séparées, en spécifiant les options NOLOGGING, USING INDEX, et en leur affectant le tablespace TBS_TUTU.

Puis, je crée les FK entre les différentes tables.

Une fois ces créations effectuées, je constate que certains (pas tous) indexs de PK (ceux créés grâce à l'instruction using index) sont en mode LOGGING, et pire, affectés à TBS_TOTO!

Voici un exemple des créations effectuées:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 create table T_ALPHA ( REGION NUMBER(8) not null, DEPARTEMENT NUMBER(8) not null, CIRCONSCRIPTION NUMBER(3) not null, CANTON NUMBER(8) not null, COMMUNE NUMBER(8) not null, NB_VOTANTS NUMBER(8) , DT_INSERSION DATE ) tablespace TBS_TOTO nologging; alter table T_ALPHA add constraint PK_T_ALPHA primary key (REGION, DEPARTEMENT, CIRCONSCRIPTION, CANTON, COMMUNE) using index tablespace TBS_TUTU nologging;
Avec une FK sur une autre table créée de maniere identique.

Pourtant, plus tard, en regardant l'objet PK_T_ALPHA dans Toad, je m'aperçois qu'il est sur TBS_TOTO et en logging!

Pourquoi?

Merci :)

02/09/2011, 17h00
StringBuilder

Je vais peut-être dire une connerie mais... Il me semble bien que les PK sont forcément dans le même tablespace que les DATA de la table, non ?
02/09/2011, 18h17
eyghon

Dans ce cas, pourquoi ce n'est pas le cas pour tous les indexs de PK?

Citation:

Envoyé par StringBuilder

Je vais peut-être dire une connerie mais... Il me semble bien que les PK sont forcément dans le même tablespace que les DATA de la table, non ?

Oui, vous avez dit une connerie :D

On ne parle pas de tablespace pour PK mais pour les indexes qui couvrent les PK. Bien sûr que l'index d'une PK et sa table correspondante peuvent être mis dans des tablespaces différents

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
mhouri.world > drop table t purge;
 
Table dropped.
 
mhouri.world > create table t (x number, y number, z number);
 
Table created.
 
mhouri.world > select table_name, tablespace_name
  2  from user_tables
  3  where table_name = 'T';
 
TABLE_NAME                     TABLESPACE_NAME                                  
------------------------------ -------------------------                   
T                              XXX_128_8_D                                     
 
mhouri.world > create index non_uk_ind on t (x) tablespace XXX_128_8_i;
 
Index created.
 
 
mhouri.world > alter table t add constraint t_pk primary key (x) using index;
 
Table altered.
 
mhouri.world > select table_name, constraint_name
  2  from user_constraints
  3  where table_name = 'T';
 
TABLE_NAME                     CONSTRAINT_NAME                                                                          
------------------------------ -----------------                                                        
T                              T_PK         
 
mhouri.world > select index_name, tablespace_name, table_name
  2  from user_indexes
  3  where table_name = 'T';
 
INDEX_NAME                     TABLESPACE_NAME                TABLE_NAME                                                
------------------------------ ------------------------------ -------------                            
NON_UK_IND                     XXX_128_8_I                   T

On voit bien que

la contrainte primary key a bien été créé
aucun index supplémentaire n'a été crée pour couvrir cette PK
Le seul index qui subsiste c'est celui que j'ai créé
on peut même "policer" une PK via un index non unique situé dans un tablespace différent de celui de la table

PS : "policer" : que ce mot est simple est plein d'arguments: respect d'une règle établie à ne pas transgresser que la PK est là afin de veiller à la stricte obeissance de ladite régle.

05/09/2011, 09h48
StringBuilder

OK, désolé, confusion avec SQL Server alors :cry: