frammentazione database oracle?

[pjfry]

mettiamo che creo un db oracle da 2 giga... immagino che si allochi tutte le sue tabelline per ottimizzare le prestazioni...
inserisco dati e vanno nello spazio vuoto, tutto ok...
cancello delle righe e si crea spazio che cmq sarà riutilizzato senza troppi problemi, credo, perchè la size totale non cala...
però quando i dati aumentano che succede? se la size supera i 2 giga iniziali viene allocato altro spazio, credo, ma quanto? e quanto ottimizzato? ho idea che dopo un pò di volte che fà così si frammenti un qualche tipo di indice, tipo MFT, e le prestazioni dovrebbero rallentare...
a quel punto che si fà?
sapete se c'è qualche tool di oracle per 'deframmentare', ricompattare o comecaspiodidice?
fare un dump, reinstallare il db + grande e ripristinare il dump può andare? in teoria ricrea le tabelle e inserisce i dati uno per volta, no? quindi (secondo me) potrebbe essere come formattare un disco frammentato e ricopiarci sopra la roba da zero...
che ne dite?

grazie

[archimede]

Domanda complessa (specie per me che lavoro con db Oracle ma non sono certo un esperto), comunque faccio un tentativo.

mettiamo che creo un db oracle da 2 giga... immagino che si allochi tutte le sue tabelline per ottimizzare le prestazioni...

Si.

cancello delle righe e si crea spazio che cmq sarà riutilizzato senza troppi problemi, credo, perchè la size totale non cala...

Si: quando cancelli records da una tabella i relativi blocchi vanno nella freelist della tabella e saranno riutilizzati nei successivi INSERT e UPDATE.

quando i dati aumentano che succede? se la size supera i 2 giga iniziali viene allocato altro spazio, credo, ma quanto?

Quando allochi i tuoi 2GB iniziali, puoi anche decidere se e in che misura tale spazio può essere automaticamente esteso.

ho idea che dopo un pò di volte che fà così si frammenti un qualche tipo di indice, tipo MFT, e le prestazioni dovrebbero rallentare...
a quel punto che si fà?

Non sono sicuro di aver compreso il tuo dubbio qui: se stiamo parlando di un db in produzione, io parto dal presupposto che se il db si è preso dello spazio in più è perchè gli serve (se non tutto ora, comunque in futuro) per cui non mi preoccupo di "recuperare" lo spazio libero al suo interno. Se invece si parla di operazioni "straordinarie" (tipo cancellare qualche milione di righe da una tabella che so che in futuro non verrà più popolata così pesantemente) allora ci sono diverse soluzioni possibili, ma qui mi fermo per paura di dire qualcosa di impreciso o, peggio, errato. Di sicuro però ti posso dire che non è certo necessario reinstallare Oracle: puoi usare export/import, creare una nuova tablespace ed importare i dati da quella vecchia, ecc.

Infine, ma probabilmente già lo sai, differenze a riguardo ci possono essere tra diverse versioni di Oracle e tra diverse piattaforme.

HTH.

Alessandro

[pjfry]

per adesso sono praticamente uno sprovveduto in fatto oracle, non so niente delle eventuali differenze
sei stato molto utile, quello che voglio capire è se le tabelle quando crescono lo fanno in modo ordinato oppure se i 2 giga iniziali restano com'erano e la roba in + si attacca in modo 'frammentato' e rallenta le prestazioni.
credo che per import\export intendi il dump che dicevo io... quindi secondo te se droppi tutto e poi riimporti la struttura del db viene creata in modo ottimale anche se prima si era incasinata, giusto?

P.S. da dove si parte per imparare oracle? c'è qualche sito 'bibbia' per caso?

grazie

[archimede]

quello che voglio capire è se le tabelle quando crescono lo fanno in modo ordinato oppure se i 2 giga iniziali restano com'erano e la roba in + si attacca in modo 'frammentato' e rallenta le prestazioni.

Guarda, non è che voglio eludere la domanda (ok, in parte si ) ma stiamo parlando di un prodotto complesso (credo più di quanto possa immaginare chi non ha mai usato Oracle) e le variabili "ambientali" tendono all'infinito. Ad esempio: sai che Oracle supporta le cosiddette "Raw Devices" (in pratica, usa un disco bypassando il file system del SO)? E' davvero difficile dare una risposta definitiva.

quindi secondo te se droppi tutto e poi riimporti la struttura del db viene creata in modo ottimale anche se prima si era incasinata, giusto?

Direi di si: ma prima di farlo leggerei bene la documentazione e chiederei consiglio a qualche esperto!

P.S. da dove si parte per imparare oracle? c'è qualche sito 'bibbia' per caso?

Domanda da 100 punti! Nella mia limitata esperienza con il db Oracle (eh già, perchè Oracle ha anche una pletora di applicazioni "a corredo" del db vero e proprio) mi sono fatto l'idea che, contrariamente a quanto avviene in genere con i prodotti MS, l'approccio "installa/fai funzionicchiare/progredisci" non funziona. Forse ciò è dovuto anche al fatto che la documentazione (e l'installer) non è proprio il massimo: prima devi entrare nella "mentalità" Oracle, poi incominci a orientarti nei suoi meandri. Va da sè che il tutto implica uno sforzo non banale. D'altra parte, se ci sono riuscito io a far girare un db Oracle su WNT (in Internet) è segno che chiunque ci può riuscire, bene o male. Comunque eccoti qualche link utile:

http://otn.oracle.com (registrazione gratuita)
http://docs.oracle.com
http://tahiti.oracle.com (doc search engine)
http://asktom.oracle.com (se la parola guru ha un senso, in questo caso non è sprecata)
http://www.geocities.com/lydian_third/

Senza dimenticare, ovviamente, i vari newsgroups.

Good luck!

Alessandro

[kadosh]

I documenti di casa Oracle sono i migliori, in più vi è la Bibbia di Oracle, nel cui frontespizio vi è scritto che il buon dba legge almeno un'ora al giorno la sua bibba di oracle, anche se è il miglior dba oracle in circolazione.

[archimede]

I documenti di casa Oracle sono i migliori

Io avrei qualche riserva in proposito: non che siano una schifezza, per carità, ma potrebbero essere organizzati meglio. E poi per i "newbies" c'è vermanete poco materiale. Comunque i link li ho postati e sono pubblici: provare per credere...

in più vi è la Bibbia di Oracle, nel cui frontespizio vi è scritto che il buon dba legge almeno un'ora al giorno la sua bibba di oracle, anche se è il miglior dba oracle in circolazione.

Qui concordo: fa parte della "filosofia" cui accennavo prima.

Alessandro

[pjfry]

vabbè ho capito, tanto per cambiare mi tocca studiare
mai una volta che il forum faccia del lavoro per me

(scherzo, grazie 1000 )

[pjfry]

help:
ho una query 'siffatta'

Codice: Seleziona tutto

select A from tab1 where class='classe1' and B not in (select C from tab2)

select A from tab1 where class='classe1' ritorna 50050 elementi (più o meno), select C from tab2 circa 50000, quindi in uscita dovrei avere 50 elementi (gli altri sono sicuro che sono uguali)

problema: le 2 query tornano senza problemi, in circa 60 secondi l'una...
la query totale ha girato una notte intera (e poi ha ritornato il giusto numero di righe, almeno quello....)

il db è oracle 8 o 9, il server è decisamente all'altezza e non era impegnato in altro... oracle occupava la cpu sempre meno del 10%, e di ram libera ce n'era a camionate... quindi??? problemi di lockout? ma se la query torna...
perchè il db non sfrutta tutte le risorse possibili per computare? ha qualche 'limitatore' configurabile? (che ne sò, magari per migliorare la concorrenza...)
vedete un modo SQL per ottimizzare la query?

(per la cronaca... quelle 50 righe diverse me le sono trovate in 2 minuti confrontando le uscite di quelle parziali... ma mica si può fare sempre così! )

grazie

[archimede]

help:
ho una query 'siffatta'

Codice: Seleziona tutto

select A from tab1 where class='classe1' and B not in (select C from tab2)

Tanto per essere sicuro di aver capito bene...
A, B e class sono campi della tabella tab1, C è un campo della tabella tab2 e tu vuoi trovare tutti i record della tabella tab1 dove il campo class è uguale a 'classe1' ed il campo B contiene valori NON esistenti nel campo C della tabella tab2. E' questo che vuoi ottenere?

Alessandro

[pjfry]

esattamente... credo che si possano mettere ivari tab1.a,tab1.b ma il db non si inkazza quindi sono superflui, no?
cmq la query non l'ho scritta io

[archimede]

Ok, allora la prima stupidata che mi viene in mente è che se tab2.C contiene dei duplicati dovrebbe migliorare così:

Codice: Seleziona tutto

select A from tab1 where class='classe1' and B not in (select C from tab2 GROUP BY C)

Puoi verificare se cambia qualcosa in termini di prestazioni?

Alessandro

[pjfry]

grazie, forse domani riesco a provare... ma no credo che contenga dei duplicati, ho paura che quel sia una chiave
cmq fammi capire bene:
group by me li restituirebbe a gruppetti, tutti con lo stesso C, oppure solo le righe con i C diversi? in questo caso funzionerebbe come DISTINCT, o no?

[archimede]

group by me li restituirebbe a gruppetti, tutti con lo stesso C, oppure solo le righe con i C diversi? in questo caso funzionerebbe come DISTINCT, o no?

Si, in questo caso sarebbe come usare DISTINCT: ti restituirebbe un solo record per ogni valore univoco di C.

Un'altra idea, ma non sono affatto certo della sua efficacia, può essere:

Codice: Seleziona tutto

select T1.A from tab1 T1 where T1.class='classe1' and NOT EXISTS (select T2.C from tab2 T2 WHERE T2.C=T1.B)

nella speranza che in questo modo venga usato l'indice su C (giacchè non sono certo, viste anche le tue vicissitudini, che nel tuo caso venga usato).

HTH.

Alessandro

[pjfry]

forte! questa mi piace
NOT EXIST non mi ricordavo neanche che esisteva
se provo ti faccio sapere come và, grazie

[pjfry]

è saltata fuori l'eventualità che l'indice non c'è
ma dico, gli indici devo settarli io? possibile che quel genio che ha scritto una applicazione 'milionaria' (non parlo di oracle, ma del programma che lo usa) non ha configurato il db in modo giusto?
tra l'altro quei campi A, B e C sono proprio indici numerici che credo siano stati pensati per questo, altrimenti come chiavi conveniva usare i nomi

[archimede]

Immagino quindi che è tutto a posto ora, giusto? La query originale andava bene, vero?

Alessandro

[pjfry]

c'è da lavorarci un bel pò su
cmq mi hai dato dei consigli preziosi, grazie