Newsgroup: it.comp.software.database
Titolo: creazione tabelle

mi servirebbe un metodo per creare una tabella su oracle 8.1.7 in modo che
non si deframmenti, come pooso fare

 non si deframmenti, come pooso fare
riporto due links (allo stesso documento) sulla frammentazione che avevo 
postato 3 giorni fa:
probabilmente ti accorgerai che non è semplice a farsi come lo è a dirsi...
http://www.oreilly.com/catalog/oressentials/chapter/defrag.pdf
http://metalink.oracle.com/cgi-bin/cr/getfile_cr.cgi?239049
sempre sul metalink dovresti trovare altri whitepapers sui parametri di 
storage a livello di riga di tabella (discorso chained rows).
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/philosophy/free-sw.it.html

 in modo che non si deframmenti
??? he ? spiega un po' che vuoi fare ....
Davide

 non si deframmenti, come pooso fare
parametro pct_increase > 0 (va bene anche 1)
Greetings,
Alessandro Trebbi
Pesaro, Italy
http://www.b3soft.com

 parametro pct_increase > 0 (va bene anche 1)
??? così si frammenta a manetta il tablespace e comunque anche la tabella!!!
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.efluxa.it/netiquette/

 parametro pct_increase > 0 (va bene anche
1)
Scusa ma questa è una cavolata, non metto in
dubbio
che pct_increase possa servire in alcuni
casi, ma
a cosa serve impostarlo > 0 (anche perchè non
mi risulta che
si possa impostare a <0) nel caso in
questione?
                                    danlio


 ??? cosě si frammenta a manetta il tablespace e comunque anche la tabella!!!
pctincrease=0 implica che oracle non deframmenta automaticamente le
tabelle, d'altra parte e' meglio tenerlo ad un valore molto basso (ed
il minimo e' 1).
Non e' di quanto si incrementa la dimensione, ma l'incremento
dell'incremento (vuol dire che la prima volta incrementas di next, la
seconda volta di next*1.01, la terza volta di next*1.01*1.01, etc.
(cfr. Oracle8i dba handbook, chapter 4, "implications of the storage
clause")


A complemento di quello che ho scritto, questo è un'articolo molto
interessante
http://www.ixora.com.au/tips/creation/extents.htm

 il minimo e' 1).
Vero, ma cosě perdi il controllo sulla dimensione degli extents, arrivi ad
una situazione in cui hai extents di diversa dimensione, cosa che rende la
tablespace estremamente frammentata. La situazione ottimale in genere č
quella di avere tablespaces con oggetti aventi extents della stessa
dimensione.
(scusa, ho fatto casino nel reply...)

 ??? cosě si frammenta a manetta il tablespace e comunque anche la tabella!!!
visto che ho ricevuto una mail di richiesta chiarimenti...
con pctincrease=0 oracle disabilita la deframmentazione automatica
delle tabelle, con pctincrease>0 non avrete mai bisogno di
deframmentare la tabella, 1 va benissimo (qualcuno ha obiettato sugli
extents di dimensioni diverse...)


 extents di dimensioni diverse...)
visti i danni che si fanno con Oracle, a livello di frammentazione,
Oracle consiglia di seguire il metodo 'SAFE'.
tra le regole principali trovo:
"Use Uniform Extents Size"
ovvero:
"the PCTINCREASE valuse should always be set to 0."
a tua ragione posso dire che effettivamente, se pctincrease è sempre 0,
l'smon di oracle non cerca di coalescare gli extents.
comunque a livello di free extents del tablespace, non a livello di tabella.
ma usando il 'SAFE mode': "Coalescing these extents proactively would add 
overhead while while providing no benefits. As long as the size of all free 
extents is a multiple of the tablespace extent size, the tablespace is not 
fragmented.
mi baso sul whitepaper:
HOW TO STOP DEFRAGMENTING AND START LIVING: THE DEFINITIVE WORD ON 
FRAGMENTATION
di Bhaskar Himatsingka, Oracle Corporation
e Juan Loaiza, Oracle Corporation
http://metalink.oracle.com/cgi-bin/cr/getfile_cr.cgi?239049
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/gnu/why-gnu-linux.it.html

 extents di dimensioni diverse...)
Allora...
Con pctincrease >0 SMON attiva il coalesce degli extents liberi, (vale a
dire, cerca di creare un singolo grande extents unendo piccoli extents
liberi contigui) ..solo che lo fa quando gli pare a lui, cosa che non sempre
è desiderabile x motivi di performance (potresti avere anche degli
ORA-01575: timeout waiting for space management resource). Inoltre, non c'è
assolutamente bisogno di effettuare un coalesce se tutti i segmenti di una
tablespace hanno extents della stessa dimensione, (o di un campione molto
ristretto) dato che   tutti gli extents liberi sono già della dimensione
giusta per i tuoi segmenti.
Se proprio non si riesce a mantenere la dimensione degli extents uniforme (o
cmq in un numero ristretto), allora è preferibile fare il coalesce a mano
(magari schedulandolo in cron) quando il db è più scarico.
saluti

 questione?
Perche' se = 0 Oracle non esegue la frammentazione automatica della
tabella.
Nel manuale citato c'e' una noticina dove spiega tutto, e in
conclusione dice appunto di settarlo a 1 e non a 0.
Non e' una cavolata.


 (magari schedulandolo in cron) quando il db č piů scarico.
ok, ma se uno vuole semplicemente sapere come evitare di frammentare
una tabella, la risposta, se permetti, e' di non settare pctincrease=0
senza contare che comunque il valore consigliato nel manuale e' 1
non capisco a cosa possa servire avere la dimensione degli extents
uniforme, oltretutto i valori vengono corretti da Oracle per adeguarsi
alle caratteristiche del sistema operativo, non avrai mai dimensioni
assurde ma sempre ottimali.


 assurde ma sempre ottimali.
Oracle corregge i valori in base alla db_block_size e in base ai parametri 
di default del tablespace.
però avere extents di dimensioni diverse per ogni tabella e oltretutto 
all'interno della tabella stessa ti porta, dopo un po' di tempo, alla 
frammentazione del tablespace.
oltre a perdere fisicamente la possibilità di allocare spazio (a meno di 
non settare nexts di dimensione ridicola, quindi migliaia di extents per 
tabella), costringi anche l'smon ad un lavoro che altrimenti non farebbe.
in ben 2 casi ho partecipato alla ristrutturazione di 2 tablespaces che, 
non avendo settato opportunamente gli extents (cioè non uguali o multipli 
tra di loro) al momento dello startup dell'istanza facevano partire la 
coalesce automatica ciucciando TUTTO il carico macchina (intendo lentezza 
dei comandi shell da console su un HP9000).
per uno dei due la drop ha impiegato, a produzione ferma, ben 4 ore.
per questo motivo io e i miei colleghi siamo sensibili al discorso 
frammentazione e dove possibile, consigliamo il metodo "SAFE" agli 
applicativi.


 Non e' una cavolata.
Nel manuale è semplicemente descritto il comportamento di SMON a
pctincrease>0, ma non è certo suggerito.
Nel corso di performance & tuning si suggerisce proprio l'incontrario.
Saluti

 assurde ma sempre ottimali.
Serve, appunto, ad evitare che la tablespace si frammenti, con una caterva
di free extents tutti di dimensione diversa e che potrebbe essere difficile
riutilizzare anche dopo un coalesce (ricordati che affinchč un coalesce
abbia successo gli extents liberi devono essere contigui).... Mi son trovato
piů di una volta a verificare una situazione di 'unable to allocate extents'
xchč, benchč lo spazio sulla tablespace ci fosse, questo era estremamente
frammentato (con pctincrease >0). Con extents di uguale dimensione non c'č
bisogno di alcun coalesce.
Del resto, uno dei vantaggi delle tablespaces locally managed č proprio
questo.
Ps: a parte i documenti che io e punkarruso abbiamo postato, su questo punto
c'č una marea di letteratura (prova a googleggiare)  quasi tutta concorde
sul pctincrease=0..
saluti

...

Non parlavo del manule, ma di Oracle8i dba handbook (la 9 non ce l'ho
ma comunque ha l'autotuning), letteralmente c'e' scritto:
"[...] Set the default pctincrease for the tablespace to a very low
value, such as 1"
Fermo restando che la situazione ideale e' quella di allocare subito
un extent con la dimensione finale (e quindi non avere mai bisogno di
allocarne altri), con un next molto piccolo e pctincrease a 0 (nella
convinzione che se hai allocato bene non dovresti mai avere bisogno di
allocare altri segmenti)


...

Un'altra cosa interessante di Oracle9 e' che puoi ristrutturare i
tablespace senza fermare il db (con dbms_redefinition)
comunque ognuno fa come gli pare, io i disastri che voi lamentate non
li ho mai avuti, vorra' dire qualcosa?


 un extent con la dimensione finale (e quindi non avere mai bisogno di
Anche qui non generalizzerei. Ad es, se usi parallel query, con tablespace
splittata su datafiles su dischi/controller diversi, ti conviene distribuire
i dati su + extents, che, essendo allocati da oracle in round-robin sui
diversi datafiles, permettono di distribuire uniformemente il carico di i/o.
Diciamo più correttamente che sarebbe opportuno preallocare un certo numero
di extents...

 li ho mai avuti, vorra' dire qualcosa?
a proposito del pctincrease mi è venuto un dubbio:
visto che oracle arrotonda il next definito dal pctincrease al multiplo di 
db_block_size più vicino (oppure per difetto, non ricordo), non è che in 
alcuni casi, settando il pctincrease a 1 ti ritrovi ad avere un incremento 
di next*0.01 che magari non arriva alla db_block_size?
es:
db_block_size = 4096
ne ricavo che:
4096>next*0.01, quindi next<409600
con un next <409600 posso settare pctincrease=1 senza avere effettivamente 
incremento dell'extent.
mi confermate?
quindi con una blocksize da 32k arrivo a poter mettere next da ~3,2M?
considerate comunque che si parla di dimensioni esigue (cioè inventariare i 
miei cd audio occuperebbe spazio maggiore!) e degli extents 'normali' 
arriverebbero a sforare tranquilamente e quindi a frammentare la tbsp...
farò ulteriori prove...
bon travail!
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.collinelli.net/antispam/

 di next*0.01 che magari non arriva alla db_block_size?
si', pctincrease=1 e' paraticamente uguale a pctincrease=0, salvo che
con 0 non viene deframmentata la tabella in automatico. Tieni anche
presente che un buon dba dovrebbe calcolarsi a priori lo spazio
occupato dalle tabelle, per evitare il piu' possibile che vengano
allocati nuovi extents.


 sul pctincrease=0..
questo???
http://metalink.oracle.com/cgi-bin/cr/getfile_cr.cgi?239049
e' per oracle 7.3 :(
credo che il side effect di pctincrease=1 credo sia stato introdotto
nella 8
oltretutto (ma ho letto in fretta) in un altro documento mi sembra che
il coalesce all'avvio venga fatto se pctincrease=0 (ed era uno dei
problemi da voi lamentati), mentre con pctincrease=1 viene fatto da
oracle nei momenti di basso carico.
tieni presente che con Oracle8i e' stato introdotto il Resource
Manager, per controllare l'allocazione delle risorse di sistema e
suddividerle tra gli utenti (quindi nessun blocco se vengono avviati
processi in background)


 allocati nuovi extents.
:-( non me lo dire...
APPL: devo creare questa tabella
DBA: è uno storico?
APPL: in che senso?
DBA: vabbè, fa niente. quanti record ci devi inserire subito?
APPL: ma non so, circa 10 milioni.
DBA: e quanto pensi che crescerà, in milioni, all'anno?
APPL: ma, secondo le nostre stime, non più di 2 o 3.
DBA: <solite domande sulla lunchezza delle colonne>
APPL: <solite risposte vaghe>
DBA: <creazione della tabella>
6 mese dopo:
APPL: senti, dovrei passare questo script in produzione
DBA: l'avete provato in preproduzione?
APPL: certo!!
DBA: e dopo i test di carico era tutto ok?
APPL: certo!!
DBA: (carichissimo di lavoro) fai pure tu, allora!
APPL: <rollout>
APPL: senti, puoi mica controllare com'è che và così lento!
DBA: <controllo> OH, ma sta query vi aggiungeva 30 colonne varchar2 e
     settava default a "spiacente, questo campo non è valorizzato!!!!!!"
APPL: si, beh?
DBA: c'è che adesso hai 20.000.000 di chained rows.
    (infatti le previsioni di crescita erano leggermente sbagliate)
     com'è che in preproduzione non ci sono??
APPL: boh? si può rimettere il default a NULL e tornare come prima??
DBA: #§$@%£!!!!!
DBA: <3 giorni di ristrutturazione della tabella a produzione ferma>
come fai a prevedere?
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.netmeister.org/news/learn2quote.html

 e' per oracle 7.3 :(
Sono concetti sempre validi, tanto che vengono ribaditi nel corso di
system&performance tuning della 8i. Tra l'altro anche  nella  8i sono state
implementate le tbs locally-managed con uniform extents. fatto sta che è
meglio prevenire che curare, e con extents della stessa misura non hai
bisogno di alcun coalesce (che tra l'altro, se non ho letto male, SMON cerca
di fare anche su tbs read-only!!)
Quanto poi a mettere tutto in un'unico extents, come ho scritto
precedentemente non sempre è la cosa ottimale. La dimensione degli extents
dipende, oltre alla dimensione dei dati, dalla dimensione del blocco, dal
tipo di i/o (quanti dischi/controller hai, e come vuoi distribuire il
carico), dal tipo di accesso prevalente  (FTS o rowid), persino dal fatto
che utilizzi rawdevices o file-system based datafiles. Certo è che è bene
che gli extents non raggiungano un numero troppo elevato, soprattutto nelle
tbs dictionary-based, x le implicazioni negative che questo ha sul
datadictionary  e altro(vedi: tempi impressionanti x una drop)
saluti

      com'č che in preproduzione non ci sono??
Io ho un problema con una tabella dove ho un campo long (praticamente,
un file che viene prelevato ed aggiornato dai clients ad ogni
sessione) che mi si frammenta in continuazione; ad ogni update il file
cambia di dimensioni...


 deframmentazione (a livello di tablespace)
?? se intendi la coalesce dell'smon, recupera i free extents contigui, ma 
non deframmenta nessuna tabella!
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.php.net