Dimensione DB - Scelta Configurazione

martedì 17 giugno 2014 - 11.37

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Elenco Tags SQL Server 2008 R2

vittosss Profilo | Junior Member

124 messaggi | Data Invio: mar 17 giu 2014 - 11:37

Ciao,
ho un mio gestionale con relativo db sql server 2008.
i dati del gestionale sono contenuti in un db che cuba circa 80 gb che per i miei canoni è tanto. mi chiedevo dunque se fosse necessario o ci fosse una sorta di regola tale per cui si possa determinare, ad esempio, se vada clusterizzato o meno.
gli utenti non sono pochi. a spanne un centinaio.
attualmente il db è residente in un unico file mdf (+ ldf naturalmente) su un unico server (virtualizzato), nella medesima istanza, nello stesso filesystem.
le performance (anche per altri motivi) non sono al top. mi chiedevo se potessi operare scelte più opportune sulla configurazione del db.

ciao e grazie
V.

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mar 17 giu 2014 - 12:07

>Ciao,
ciao

>i dati del gestionale sono contenuti in un db che cuba circa
>80 gb che per i miei canoni è tanto. mi chiedevo dunque se fosse
>necessario o ci fosse una sorta di regola tale per cui si possa
>determinare, ad esempio, se vada clusterizzato o meno.
non è lo spazio occupato che ti sposta verso un'architettura ad alta disponibilità (HA).
Sono altri discorsi, come ad sempio:
- "scalare" perchè un server non regge più il carico di chiamate
- bassa latenza in caso di stop di un nodo nel recuperare l'attività dell'altro

>gli utenti non sono pochi. a spanne un centinaio.
Utenti dell'applicativo o di sql?

>attualmente il db è residente in un unico file mdf (+ ldf naturalmente)
>su un unico server (virtualizzato), nella medesima istanza, nello
>stesso filesystem.
questo non è il top.. un solo mdf è sconsigliato, e in alcuni casi, se c'è un corretto piano di indicizzazione, potrebbe essere necessario avere anche un file/filegroup per gli indici stessi in modo da velocizzare le operazioni di I/O su disco.
Anche i volumi dovrebbero essere differenti, e ogni volume dovrebbe avere la sua configurazione corretta per supportare affidabilità e velocità (come nel caso del ldf) e in generale sicurezza/ridondanza.
Inoltre c'è anche il tempdb da non sottovalutare, per cui dovrebbe esistere un file per ogni processore su cui il database "gira".

>le performance (anche per altri motivi) non sono al top. mi chiedevo
>se potessi operare scelte più opportune sulla configurazione del db.
a mio avviso l'approccio dovrebbe essere "a piramide", ovvero, prima configuri bene l'hardware, poi, quando sei certo che sia al top, passi al sistema operativo (con le dovute configurazioni) e ai driver.
Solo in quel momento si parla di sottosistema disco/rete per poi andare ad installare e configurare SQL con i dovuti canoni. Dopo aver configurato poi la parte disco/memoria/cpu dei tuoi database, passi alla modellazione ed infine, agli indici.
Cerca di fare fine tuning solo quando sei certo che il gross tuning è ad un buon punto e parti dal presupposto che su un ecosistema valido la vita è migliore

>ciao e grazie
di nulla!

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

vittosss Profilo | Junior Member

124 messaggi | Data Invio: mar 17 giu 2014 - 15:14

eccomi:

- "scalare" perchè un server non regge più il carico di chiamate
si questo è importante

Utenti dell'applicativo o di sql?
applicativo

questo non è il top.. un solo mdf è sconsigliato, e in alcuni casi, se c'è un corretto piano di indicizzazione, potrebbe essere necessario avere anche un file/filegroup per gli indici stessi in modo da velocizzare le operazioni di I/O su disco.
Anche i volumi dovrebbero essere differenti, e ogni volume dovrebbe avere la sua configurazione corretta per supportare affidabilità e velocità (come nel caso del ldf) e in generale sicurezza/ridondanza.
Inoltre c'è anche il tempdb da non sottovalutare, per cui dovrebbe esistere un file per ogni processore su cui il database "gira".
-- di norma cerco di avere 3 unità (C: D: E:) sul quale mettere, rispettivamente, tempdb, mdf, ldf. verò è però che virtualizzando il server e quindi i dischi in un solo storage perde un po' di senso. dove ho potuto ho creato diversi storage a seconda dell'utilizzo. dischi sas per i file mdf ed ldf e più classici, ed economici per sistema operativo.
non mi sono mai preoccupato però di dividere il file mdf. credo sia cosa buona e giusta? ha senso? creare quindi una quarta unità ad esempio?

ti ho convinto :-)

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mar 17 giu 2014 - 15:27

>- "scalare" perchè un server non regge più il carico di chiamate
>si questo è importante
Sql server non consente però l'A/A (attivo attivo) builtin. In realtà è un failover cluster (ovvero, si spegne il nodo principale, l'altro è già disponibile con poca latenza).
Se vuoi fare A/A dovrai inventarti qualcosa di manuale che separa le chiamate su di un nodo piuttosto che sull'altro, con il conseguente rovescio della medaglia della doppia amministrazione/doppia manutenzione/doppio deploy.
Ecco una guida: http://msdn.microsoft.com/en-us/library/ms190202(v=sql.105).aspx
Peccato, perchè con SQL Server 2012 avresti avuto AlwaysOn: http://msdn.microsoft.com/en-us/library/hh510230(v=sql.110).aspx

>-- di norma cerco di avere 3 unità (C: D: E:)
il temppdb deve essere veloce, quindi meglio se C è SSD..

>non mi sono mai preoccupato però di dividere il file mdf. credo
>sia cosa buona e giusta?
decisamente, pensa agli accessi paralleli su più file.. il multithread, ecc.. parallelizzando le I/O velocizzi l'accesso.

>ha senso? creare quindi una quarta unità ad esempio?
ha molto senso. La quantità dipende dal tipo di accesso che hai tu sui tuoi oggetti..
Ad esempio, potresti avere X schema su database (es. vendite, acquisti, utenti) e già questa potrebbe essere una separazione intelligente.

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

vittosss Profilo | Junior Member

124 messaggi | Data Invio: mar 17 giu 2014 - 15:43

quindi, se non erro,
mdf
ldf
+
ndf
giusto?

ma quindi posso dire se un file che tabelle mettere e su altro file quali altre tabelle mettere?

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mar 17 giu 2014 - 16:36

>mdf
per il filegroup PRIMARY, togliendo la spunta che lo imposta come DEFAULT

>ldf
per il log, e uno solo

>ndf
>giusto?
dipende, per me è N x ndf, uno per ogni file che mi serve.

>ma quindi posso dire se un file che tabelle mettere e su altro file quali altre tabelle mettere?
non solo, puoi anche cambiare il path su cui andare a salvare anche solo gli indici.
Devi lavorare con i Filegroup.

Di solito io ne faccio uno MISC che è il default (in modo da non creare mai oggetti sul primary, che di solito stanno su un disco non performante al top) e poi n x ndf file per quanto mi serve..
gli ndf e l'ldf li pongo sulla SAN (sempre che ce ne sia una) scegliendo il RAID configuration migliore per la tipologia del file.
E qui si apre un'altra grossa parentesi.. le configurazioni RAID.

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !