Newsgroup: it.comp.software.database
Titolo: query su tabelle partizionate Oracle

Scusate,
sto "studiando" le tabelle partizionate di Oracle (vers. 9.2) e ho un
dubbio su quelle composite, ovvero le composite di tipo range-list.
Quello che volevo chiedervi e': se io faccio una query basata solo sul
campo di partizionamento di tipo range sfrutto il partizionamento?
(ovvero lo sfrutto come se fosse un partizionamento  semplice basato
su range?)
e se lo faccio solo sul campo di listing e' lo stesso?
In pratica, il partizionamento composito vale solo se utilizzo la
stessa "gerarchia" nell'interrogazione e/o solo se uso entrambi i
campi di partizionamento, altrimenti ne perdo i vantaggi?
(purtroppo non sono in grado di fare delle prove..)
grazie,

 grazie,
in pratica vedila così:
il partizionamento, ti consente di accedere a subset di dati a
seconda di un unico criterio. Quando aggiungi sub-partitions stai in
definitiva, aggiungendo altri criteri a quello già esistente.
Es, crei una tabella (start_date date, id number) partizionata per
range, diciamo per data. Quando esegui una query con una where condition
sulla colonna start_date, stai di certo eliminando le partizioni non
interessate (quello che Oracle chiama partition pruning).
Sin quì nulla di nuovo.
Ora aggiungiamo delle sub-partitions, diciamo tre sub-partitions
per ogni partizione con logica = list. La diversificazione è ovviamente
sulla colonna id. Valgono i seguenti casi:
1) select con where condition sulla start_Date, vale quanto
detto prima, le sub-partitions non entrano in nessun modo nel merito.
2) select con where condition sulla colonna id. Stavolta le partizioni
non entrano nel merito, e l'iterazione avviene sulle sub-partitions. in
pratica all'interno di ogni partizione viene eseguito il partition
pruning sulle sub-partitions. Ovviamente vengono accedute tutte le
partizioni.
3) select con where condition su start_date e su id. Il partition
pruning avviene sia sulla partizione che sulle sottostanti sub-partitions.
4) select senza where condition. IL db si spazzola tutta la tabella
(partitions + sub-partitions)
ciao

ok, sei stato chiarissimo, grazie!

 ok, sei stato chiarissimo, grazie!
prego.
ciao

freCho ha scritto:

Scusate l'intromissione
Dopo la chiarissima esposizione di freCho mi viene una domanda (visto 
che proprio ora stò trafficando con una tabella partizionata - in oracle 
10g però - e mi stò chiedendo se vale la pena mettere in gioco anche 
degli indici).
Se si fanno degli indici LOCAL sulla tabella partizionata es. IDX_1 su 
"start_date", "id" e IDX_2 su "Id","start_date" il meccanismo di pruning 
viene comunque utilizzato?
1) Quando la select ha where condition sulla colonna start_date e sulla 
colonna id come si comporta Oracle?
2) Quando la select ha where condition solo sulla colonna id come si 
comporta Oracle?
Baciolemani

> 
[CUT]

ciao,
in breve e fermo restando l'esempio che ho fatto a citte:
devi distinguere a seconda che ci sia un prefixed index o
un nonprefixed index. Il primo è un indice la cui colonna
è la stessa usata per la partizione, il secondo ovviamente
non soddisfa questa condizione.
Nell'esempio che porti tu, l'indice IDX1 e prefixed, IDX2 invece
non lo è.
1) select con where condition su start_date:
il partition pruning avviene senz'altro, viene acceduta solo
la partizione interessata. All'interno di questo subset di dati,
i singoli record vengono acceduti attraverso l'indice, perchè
è sicuro (per la where condition di sopra) che i dati richiesti
sono solo e soltanto nella partizione corrente. Per la precisione
viene acceduta solo la partizione dell'indice relativa all'analoga
partizione sulla tabella: NB solo per LOCAL partitioned indexes
2) select con where condition su id. Oracle non può sapere come
sono distribuiti i record contenenti la chiave di ricerca all'interno
delle partizioni. In questo caso il partizionamento non ha effetti 
sulla selezione, il db si spazzola tutto l'indice, ossia accede a
tutte le partizioni che concorrono a formare l'intero indice.
3) where condition su start_Date e su id.
la condizione su start_Date restringe l'accesso
ad una sola partizione. La relativa partizione dell'indice viene
acceduta per ricavare i rowid dei singoli record che soddisfano
le condizioni.
4) l'esistenza di un indice non comporta automaticamente l'accesso
per rowid, sia chiaro..ma questo è un altro paio di maniche.
ciao
ps- data la stanchezza potrei aver scritto idiozie.
Nel caso IGNORARLE PLEASE  :)

 Il Tue, 10 Jul 2007 14:11:30 +0200, Resolver ha scritto:
[CUT]
Grazie per la risposta.
Ora ci medito...