Ciao,
ci sono diverse considerazioni sull'argomento e non sono proprio brevi... Cerco di riassumere:
1) Organizzazione generale dei databases e dei dischi
E' buona norma separare il carico di lavoro sui dischi in una installazione di SQL Server tenendo su dischi fisici
separati il file dati (.mdf), il file di log (.ldf) ed il tempdb (sia il file dati che il file di log). I files dati vengono acceduti in maniera random, mentre i log in maniera sequenziale, quindi già così
separo la tipologia di I/O. (Es. disco C: per S.O. e binari di SQL Server, disco E: per i dati (mdf), disco L: per i log (ldf), disco T: per i dati del tempdb).
Oltre a separare le lettere di unità è ovviamente indicato utilizzare tecnologie RAID per avere anche la fault tolerance nel caso in cui si guasti un disco. Quindi nell'esempio sopra considera RAID 1 per C:, RAID 5 o 10 per E:, RAID 1 per L:
e RAID 1/5 o 10 per T:)
Qui trovi indicazioni sul RAID.
2) Files multipli
Posso aggiungere per ogni databases una serie di files, che avranno estensione .ndf, solitamente perchè ho terminato lo spazio nel file principale :-), ma anche per suddividere il carico di lavoro sui dischi (devo però averli creati contestualmente
alla creazione del database, altrimenti non li riempe in parallelo, ma in cascata)
3) Filegroups
Insieme alla 1) la tecnica più consona se ho dei databases molto grandi (o con tanto traffico sui dischi) per separare il carico: posso mettere i dati e/o gli indici e/o i campi di tipo binario (immagini, documenti, etc) su file appartenenti a filegroups
diversi, ciascuno su un disco fisico diverso.
Normalmente SQL Server crea un unico filegroup PRIMARY in cui mette le tabelle di sistema e, per default, le mie tabelle.
Però posso, in fase di creazione del database, creare uno o più filegroups e metterci tabelle, indici o campi binari.
Maggiori informazioni
qui,
qui e
qui.
Quindi, per tornare alla tua domanda, non c'è un modo unico per suddividere l'I/O sui dischi, ed in generale l'architettura del database andrebbe progettata prima di crearlo. Puoi ovviamente intervenire anche in seguito, ma devi fare attenzione, soprattutto
in presenza di db di grandi dimensioni.
Qual'è l'esigenza specifica ? Per quale motivo avete l'esigenza di dividere la scrittura del db su più dischi ?
Danilo Dominici MCP MCDBA MCITP MCSE MCAD Questo post è fornito "così com'è". Non conferisce garanzie o diritti di alcun tipo. Ricorda di usare la funzione "segna come risposta" per i post che ti hanno aiutato a risolvere il problema
e "deseleziona come risposta" quando le risposte segnate non sono effettivamente utili. Questo è particolarmente utile per altri utenti che leggono il thread, alla ricerca di soluzioni a problemi similari. ENG: This posting is provided "AS IS"
with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community
members reading the thread.
