Newsgroup: it.comp.software.database
Titolo: Tabelle partizionate e relativi indici (lunghetto)

ciao a tutti, vi chiedo aiuto circa un dubbio che mi e' sorto sulla
creazione di tabelle partizionate e sopratutto dei relativi indici.
vi racconto il mio caso:
data la mancanza di spazio per far crescere il DB, io alcune tabelle grandi
tabelle le ho create partizionate per mese cosi' posso lasciare online gli
ultimi 3 mesi piu' il corrente e cancellare l'ultimo.
con le tabelle partizionate la cosa e' semplice perche' basta che faccio una
drop della partizione che mi interessa.
il problema pero' sono gli indici.
ho fatto alcune prove di creazione e ho visto che
1. se creo l'indice non partizionato, quando droppo la partizione l'indice
rimane a stato VALID ma ovviamente lo spazio occupato non diminuisce e
dovrei fare tutte le volte una rebuild (oporazione lunghissima dato le
dimensioni delle tabelle).
2. se creo l'indice local, quando droppo la partizione l'indice passa a
stato N/A (non so cosa vuol dire) e acendo una rebuild partizione per
partizione lo stato non cambia. addirittura anche droppando e ricreandolo
rimane sempre in questo stato (prima era VALID).
avete suggerimenti da dare?
grazie in anticipo a chi potra'/vorra' aiutarmi.
Max
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 
Se nella dba_indexes trovi N/A dovi controllare la dba_ind_partitions 
per vedere lo stato delle partizioni (che una di esse sia INVALID?).
La 10g ha introdotto un'opzione piu' generica di UPDATE INDEXES.
Nei local index controlla che l'indice della partizione sia stato 
droppato con la tabella. Altrimenti dovrai eseguire l'operazione a mano.
Scusa la fretta nella risposta.
Al massimo integro in un altro post quando ho maggior tempo a disposizione.
-- 
Fabrizio Magni
fabrizi...@mycontinent.com
replace mycontinent with europe

 ha
scritto:



 avete suggerimenti da dare?
...questa è una problematica che ho affrontato abbastanza
approfonditamente.
Attualmente sto gestendo tabelle con 1/2 miliardi di record
...ovviamente partizionate :)
In linea di massima non esiste una linea guida precisa, dipende
molto dall'utilizzo degli indici e il perchè partizioni
Tieni conto che:
- un indice locale non ha necessità di essere rebuildato in
caso di drop/truncate della partizione (ovviamente)
- un indice locale univoco (pk ad esempio) può essere creato
ses la chiave di partizionamento fa parte dell'indice (e qui
può sorgere qualche problema)
nel mio dibbi ho situazioni eterogeneee...
1 - tabelle partizionate con indici locali + pk locale
2 - tabelle partizionate con indici locali + pk globale
3 - tabelle partizionate con indici globali
e sto pensando anche a gli indici partizionati :)
a prima vista la 3 potrebbe sembrare un controsenso ma non
lo è... Oracle ci mette più ad effettuare un piano di tipo
- partition range all
     index range scan (local)
piuttosto che un index range scan secco...
quindi se non hai possibilità o non hai necessità di fare
pruning sulle partizioni, ma utilizzi il partizionamento
esclusivamente per operazioni di svecchiamento ci penserei
un pochino su e andrei sul globale... tieni conto che
in fase di rebuild degli indici puoi sfruttare egregiamente il
parellelismo e comunque nella 9i il tutto viene effettuato
online.
Il discorso è più complesso di quanto si creda quindi
dovresti esporre il problema in maniera più chiara...
Inoltre, n/a sulle viste è dovuto al fatto che stai leggendo
sulla vista sbagliata devi andare sulle *_ind_partitions.
Quando crei una tabella partizionata Oracle divide fisicamente
la tabella in segmenti diversi... cosa non vera per il
sottopartizionamento.
Saluti,
Giorgio
-- 
:: Well some people try to pick up girls and get called assholes
:: This never happened to Pablo Picasso


Come no! Nel caso di sottopartizionamento, il segmento è relativo alla 
sottopartizione, non alla partizione. 


ehm... espresso male <:) intendevo proprio che nel caso della
partizione il segmento coincide, mentre nel sottopartizionamento
il segmento coincide con la sottopartizione e non con la partizione.
giusta precisazione la tua

grazie in ritardo per la tua risposta (ero ad un corso alla Oracle) e a
conti fatti (la rebuild degli indici mi prenderebbe almeno 5 o 6 ore ad
indice) penso che faro' gli indici locali cosi' non devo ricostruirli ogni
mese.
ciao e buona giornata
Max

