Deframmentazione indici e disco: quale prima ?
Goldrake
poi l'hard disk o viceversa ??
Grazie
Luca Bianchi
> e poi l'hard disk o viceversa ??
E' indifferente. Tieni presente che affinch� la deframmentazione dei file
possa andare a buon fine � indispensabile che il servizio SQL Server sia
fermo. In caso contrario i file risulteranno in uso e pertanto non
deframmentabili (se non con tools di terze parti).
Inoltre se la frammentazione degli indici � un fenomeno legato all'attivit�
sul database (e pertanto di difficile contrasto se non con la ricostruzione
regolare degli indici), la frammentazione del file system pu� essere tenuta
sotto controllo facendo in modo che le occorrenze di crescita siano limitate
sia nel numero che negli intervalli di crescita.
> Grazie
Bye
--
Luca Bianchi
Microsoft MVP - SQL Server
http://community.ugiss.org/blogs/lbianchi
Goldrake
news:OnwYXKc6...@TK2MSFTNGP04.phx.gbl...
>> Ai fini della migliore performance, bisogna deframmentare prima gli
>> indici e poi l'hard disk o viceversa ??
>
> E' indifferente. Tieni presente che affinch� la deframmentazione dei file
> possa andare a buon fine � indispensabile che il servizio SQL Server sia
> fermo. In caso contrario i file risulteranno in uso e pertanto non
> deframmentabili (se non con tools di terze parti).
Si si... lo so. Infatti ho sempre stoppato il servizio prima.
> Inoltre se la frammentazione degli indici � un fenomeno legato
> all'attivit� sul database (e pertanto di difficile contrasto se non con la
> ricostruzione regolare degli indici),
Come si fa a determinare ogni quanto ricostruire gli indici ?
Una volta alla settimana puo' andare bene ?
> la frammentazione del file system pu� essere tenuta sotto controllo
> facendo in modo che le occorrenze di crescita siano limitate sia nel
> numero che negli intervalli di crescita.
Per "occorenze di crescita" intendi il parametro legato alla dimensione del
file del database dove si puo' impostare la percentuale di crescita del file
stesso quando i dati raggiungono la dimensione massima ?
Grazie
Luca Bianchi
Dipende dall'attivit� che insiste sul database. Puoi conoscere lo stato di
frammentazione di ogni singolo indice interrogando la
sys.dm_db_index_physical_stats
> Una volta alla settimana puo' andare bene ?
Pu� essere poco o pu� essere troppo. Tuttavia se hai disponibile la finestra
del fine settimana per poter portare a termine la ricostruzione degli indici
a prescindere dallo stato di frammentazione rilevato fallo pure senza
pensarci troppo...
> Per "occorenze di crescita" intendi il parametro legato alla dimensione
> del file del database dove si puo' impostare la percentuale di crescita
> del file stesso quando i dati raggiungono la dimensione massima ?
In quella finestra imposti le DIMENSIONI con cui il file si espander�. Per
"occorrenze di crescita" si intende il NUMERO delle volte che ci� si
verifica. Evidente che maggiore � lo spazio con cui si espande il datafile
ad ogni occorrenza e minori saranno le volte che ci� accadr�...
Luca Bianchi
Meno si fanno e meglio stai
> Cioe', in altre parole, dato il fatto che ci sono tre attivita' principali
> di manutenzione: deframmentazione indici, compattazione db, compattazione
> file del db, come bisogna incastrare queste tre cose ?
Se la ricostruzione degli indici � una attivit� amministrativa da includere
regolarmente in un piano di manutenzione, la compattazione non lo �.
Indispensabile prevedere un piano di backup, di ricostruzione degli indici e
di controllo dell'integrit� logica, ma la compattazione, come detto, �
preferibile non farla. Se proprio rimuovi una grande quantit� di dati e sei
pi� che sicuro che per molti mesi quello spazio non ti serivir� (e al tempo
stesso quello spazio ti serve) puoi procedere IN VIA STRAORDINARIA a
compattare i file di database (preferibile rispetto alla compattazione del
db perch� ti da un maggior controllo su cosa compatti). Tra le attivit�
amministrative da prevedere si � parlato pi� volte sull'ordine in cui
eseguirle, ovvero
1) Rebuild (o reorganize) degli indici
2) Backup
3) Check db
Se fai una ricerca tra i post di questo ng troverai ulteriori
approfondimenti
Goldrake
Continuando il ragionamento...
in merito, invece, alla compattazione del db e del file del db ?
In che sequenza bisogna eseguire le procedure ?
Cioe', in altre parole, dato il fatto che ci sono tre attivita' principali
di manutenzione: deframmentazione indici, compattazione db, compattazione
file del db, come bisogna incastrare queste tre cose ?
Grazie
Goldrake
>> in merito, invece, alla compattazione del db e del file del db ?
>
> Meno si fanno e meglio stai
Mi sfugge la motivazione di questa tua affermazione.
Quale problema porta fare la compattazione deil db ?
> Se la ricostruzione degli indici � una attivit� amministrativa da
> includere regolarmente in un piano di manutenzione, la compattazione non
> lo �. Indispensabile prevedere un piano di backup,
Fatto
>di ricostruzione degli indici
Sto facendo :-)
> e di controllo dell'integrit� logica,
mmmhh... questo mi sfugge. Come si fa ?
> ma la compattazione, come detto, � preferibile non farla. Se proprio
> rimuovi una grande quantit� di dati e sei pi� che sicuro che per molti
> mesi quello spazio non ti serivir� (e al tempo stesso quello spazio ti
> serve) puoi procedere IN VIA STRAORDINARIA a compattare i file di database
> (preferibile rispetto alla compattazione del db perch� ti da un maggior
> controllo su cosa compatti).
Spero di non farti una domanda scema ma se compatto il db, quindi i file (ma
senza fare lo shrink), quindi mantengo di fatto la dimensione del file
originale, e' sempre una cosa brutta ?
Grazie
Luca Bianchi
>
> Mi sfugge la motivazione di questa tua affermazione.
> Quale problema porta fare la compattazione deil db ?
Fai una ricerca tra i post di questo ng.
Anche i sassi qui oramai sanno che le attivit� di compattazione non fanno
altro che dare il loro significativo contributo al proliferare della
frammentazione a livello di file system. Quindi meno compattazioni fai
e(tendenti a zero) e meno saranno frammentati i file di database
>> e di controllo dell'integrit� logica,
>
> mmmhh... questo mi sfugge. Come si fa ?
DBCC CHECKDB
> Spero di non farti una domanda scema ma se compatto il db, quindi i file
> (ma senza fare lo shrink),
Come fai a compattare il db senza fare lo shrink?
> quindi mantengo di fatto la dimensione del file originale, e' sempre una
> cosa brutta ?
Obiettivo della compattazione � quella di ridurre le dimensioni di uno o pi�
file. Come fai a dire che "mantieni le dimensioni del file originale"?
Goldrake
>>> Meno si fanno e meglio stai
>>
>> Mi sfugge la motivazione di questa tua affermazione.
>> Quale problema porta fare la compattazione deil db ?
>
> Fai una ricerca tra i post di questo ng.
> Anche i sassi qui oramai sanno che le attivit� di compattazione non fanno
> altro che dare il loro significativo contributo al proliferare della
> frammentazione a livello di file system. Quindi meno compattazioni fai
> e(tendenti a zero) e meno saranno frammentati i file di database
Ovviamente mi fido di quello che dici, ma proprio non capisco la ragione
tecnica per cui fare una compattazione dei file del db, e successivamente il
defrag dell'hard disk, aumenti il problema anziche' diminuirlo.
Cioe'... capisco che se compatto i dati dentro al file per ridurllo di
dimensione, la procedura puo' ulteriormente frammentarmi la disposizione del
file sulla superfice dell'hard disk, ma se poi lo deframmento, in teoria, i
vari pezzi del file dovrebbero diventare piu' contigui... o no.. ?!?!?
Boh.... :-S
>> Spero di non farti una domanda scema ma se compatto il db, quindi i file
>> (ma senza fare lo shrink),
>
> Come fai a compattare il db senza fare lo shrink?
mmmhhhh.... mi sa che sono un po' confuso sui termini.
Stavo confondendo il termine "shrink" con l'opzione "truncate".
Ma poi mi e' venuto in mente che "shrink" = "compattazione"....
:-(
Grazie per la pazienza.
giorgio rancati
"Goldrake" <nos...@nospam.com> ha scritto nel messaggio
news:ur$ILO36J...@TK2MSFTNGP04.phx.gbl...
>
> Ovviamente mi fido di quello che dici, ma proprio non capisco la ragione
> tecnica per cui fare una compattazione dei file del db, e successivamente
> il defrag dell'hard disk, aumenti il problema anziche' diminuirlo.
>
> Cioe'... capisco che se compatto i dati dentro al file per ridurllo di
> dimensione, la procedura puo' ulteriormente frammentarmi la disposizione
> del file sulla superfice dell'hard disk, ma se poi lo deframmento, in
> teoria, i vari pezzi del file dovrebbero diventare piu' contigui... o no..
> ?!?!?
>
> Boh.... :-S
Ciao Goldrake,
La compattazone del database comporta la deframmentazione degli indici
rendendoli praticamente inutilizzabili.
Quindi se vuoi compattare avrai:
1) Compattazione Database
2) Rebuild Indici
3) Defrag file system.
Ti accorgerai che dopo aver eseguito il punto 2 il database potr� avere una
dimensione uguale se non pi� grande di quella esistente prima
dell'esecuzione del punto 1.
Quindi il punto1 deframmenta il file system, il punto 2 anche con il
risultato che il defrag deve lavorare di pi�.
Morale: la compattazione del database serve solo a consumare energia
elettrica.
:-)
--
Giorgio Rancati
[Office Access MVP]
Luca Bianchi
> tecnica per cui fare una compattazione dei file del db, e successivamente
> il defrag dell'hard disk, aumenti il problema anziche' diminuirlo.
>
> Cioe'... capisco che se compatto i dati dentro al file per ridurllo di
> dimensione, la procedura puo' ulteriormente frammentarmi la disposizione
> del file sulla superfice dell'hard disk, ma se poi lo deframmento, in
> teoria, i vari pezzi del file dovrebbero diventare piu' contigui... o no..
> ?!?!?
Nell'immediato si... anche se resta il fatto che per deframmentare i file di
database hai dovuto interrompere il servizio e questo � gi� il primo aspetto
negativo. Riducendo le dimensioni dei file di database, per�, non fai altro
che ANTICIPARE le future occorrenze di crescita e quando queste si
verificheranno il file andr� ad espandersi, con tutta probabilit�, in una
zona non contigua. Se non avessi compattato il file, invece, a fronte di uno
"spreco" di spazio, avresti avuto un file monoblocco (o comunque con alte
probabilit� che sia tale) che, non richiedendo alcuna estensione, rimarr�
tale per un tempo sicuramente maggiore. Quindi compattare il file significa
fare in modo che le occorrenze di crescita vengano anticipate (e siano
numericamente superiori) rispetto ad un file che nasce "abbondante". In
altre parole puoi fare veramente poco per contrastare la frammentazione, ma
compattando ripetutamente il file dai il tuo significativo contributo al
proliferare della stessa...
> Grazie per la pazienza.
Goldrake
Ok!
Mi avete convinto.... giuro che non compattero' mai il db !!
:-))
Grazie a tutti e buon week end