Raccomandazioni Ram rispetto alla dimensione DB SQL

abbiamo un db di medie size di circa 40 GB e stiamo per spostarlo in una nuova casella con server 2008 r2 x64

un costoso appaltatore è appena arrivato e ha detto che abbiamo bisogno di 72 grammi di ram in modo che l'integer DB possa vivere in RAM immagino .., ritengo che ridicolo, ma forse mi manca qualcosa.

Mi stavo chiedendo se esista un 'calcolo di regola del pollice' che suggerisce una buona quantità di RAM da utilizzare su un'istanza SQL ..

EDIT: DB ha fino a 150 persone che lo colpiscono in qualsiasi momento, usate per eseguire un sistema di prenotazione. molto vecchio schema DB, orribili quantità di colonne in tante tavole, vasti archi di indici inutili. accessibile da .net che colpisce alcuni spuntori, ma anche interrogando con sql cruda e qualunque cosa utilizzi VisualDataFlex.

Grazie

nat

  • Come disinstallare IIS da Windows Server 2008
  • HTTP Errore 503. Il servizio non è disponibile. In Windows 2008 con iisstart.htm
  • Powerpoint mancante dalla configuration DCOM
  • Percorso di networking non trovato durante l'accesso a Active Directory
  • Windows 2008 Domain Multiple Sites / sottoreti Che cosa dovrebbe essere considerato
  • I client Mac che accedono a una condivisione di Windows NTFS ripristinano le autorizzazioni a livelli di cartella più profondi. Perché?
  • Come posso visualizzare i tempi di login / annullamento per Windows Server 2008?
  • Windows RDP, ho bisogno di condividere file e condivisione di printing?
  • One Solution collect form web for “Raccomandazioni Ram rispetto alla dimensione DB SQL”

    Non esiste una buona regola.

    La RAM aggiuntiva di utilità dipende molto da come è progettato il tuo database e dai templates di query o dai tuoi utenti. Come esempio estremo, se si dispone di 1 TB di dati in totale, di un buon indicizzatore e di 1000 utenti simultanei che solo dopo una particolare row (seleziona * da dbo.BigTable where pkey_id = 42), si potrebbe arrivare con pochissima RAM . L'impatto di più RAM può dipendere anche dal modo in cui il sottosistema di memorizzazione del disco è. Se si dispone di una memorizzazione super veloce (una buona SAN, un buon DASD o SSD), non si può notare il ritardo quando il server deve leggere i dati.

    Idealmente, si desidera che tutti i dati che il database abbia probabilmente bisogno durante il giorno memorizzato nella RAM. Ciò è a volte denominato "dati caldi" o "pagine calde" (in SQL Server, i dati sono organizzati in unità chiamate "pagine"). Un esempio di dati caldi potrebbe essere gli ordini presi oggi o ieri, che saranno necessari dai lavoratori che spediscono tali ordini. Un esempio di dati freddi potrebbe essere gli ordini presi due anni fa, ma che esistono ancora nel sistema in modo che le CSR possano cercare vecchi ordini.

    Con un sistema OLTP ben progettato con un totale di 40 GB di dati (a differenza dei file di dati che contengono fino a 40 GB), potrebbe essere ansible che i dati caldi arrivino solo a 10 GB, 5 GB, 1 GB o addirittura less . Nei giorni passati la differenza tra l'acquisto di 64 GB di RAM e 8 GB (o anche less) è stata astronomica e per get la quantità di RAM da acquistare è giusto vale la pena spendere molto tempo.

    Volete sempre una piccola RAM aggiuntiva per "overhead" come il sistema operativo, scanner di virus, sessioni di RDP. Vogli anche prendere in considerazione la crescita del database.

    Un'altra cosa da tenere in mente è che RAM entra in "pezzi". Non puoi decidere tra 48 GB e 49 GB, devi aumentare, probabilmente da 48 a 64 GB. La dimensione del pezzo dipende dalle tecnologie RAM attualmente in commercio e da quanti canali la tua memory ha. I vecchi server avevano una modifica alla memory, quindi i server hanno iniziato a avere due server attualmente più carini che dispongono di tre canali di memory. Quindi, non puoi solo aggiungere un bastone, è necessario aggiungere due tre alla volta.

    Se si dispone di un database mal progettato e male indicizzato, come si dice che lo fai, SQL finirà per leggere un sacco di dati che non dovrebbero avere con un database meglio progettato. Avere questi dati in RAM non significa che non lo legga tutto. Significa semplicemente che legge tutti i dati in RAM più velocemente di quanto fosse ansible se i dati erano seduti sul disco. Questo non è necessariamente corretto tutti i tuoi problemi; la lettura dei dati dalla RAM è veloce, ma richiede ancora un tempo finito e si possono ancora get blocchi e problemi di block che possono causare problemi di performance.

    Un'altra cosa è che più RAM aiuta quando le persone eseguono grandi report sul sistema che utilizzano i dati dello scorso anno. La gente tratta sisthemes OLTP come sisthemes di reporting per tutto il tempo. Questo non può essere un evento raro, in particolare con query SQL casuali.

    Potresti passare del tempo (e dei soldi) sugli sviluppatori e i tester per migliorare il disegno del database e fare qualsiasi modifica al fronte che questo richiedesse.

    Un viaggio molto veloce per hp.com mostra che posso get un server (molto) spogliato con 96 GB di RAM per circa 9.000 dollari USA.

    (Che è less di 100 dollari US per GB, senza fare parte di nessuna delle altre parti del server, parti come l'alimentatore o il processre, vecchie persone come me ricordano quando RAM era $ 5.000 US per Mega Byte.

    Quanto velocemente puoi spendere 9.000 dollari USA sul tempo di sviluppo e di prova? (A prezzi aziendali nella mia zona, che ti farà solo una persona intera per un integer mese). Ci sarà sufficiente tempo per risolvere tutto nel database? Cosa succede se un bug nel codice modificato scivola?

    Un interruzione del server per aggiungere RAM potrebbe richiedere un'ora, e quasi chiunque può fare il lavoro. La migrazione su un server totalmente nuovo potrebbe richiedere un paio di giorni di lavoro di preparazione e un'ora di down time, e avnetworking bisogno di qualcuno con esperienza (probabilmente un DBA).

    Aggiunta di RAM è improbabile che causino errori. La migrazione a un nuovo server non implica difficoltà a trovare problemi. (Generalmente, le cose funzionano o sono ovviamente rotte. Di solito "oops, password sbagliata" o "oops, dimenticato di copiare un server collegato", non è mai "questo calcolo improvvisamente non funziona correttamente").

    Quindi, supponendo che stiamo andando a mantenere tutto in RAM e abbiamo un database di 40 GB, vogliamo una certa spazio per sovraccarico. Pensavo a un server con 48 GB o così. Inoltre, vogliamo qualche spazio per la crescita. Diciamo di qui 25% di crescita da qui, che è di 12 GB e ci port fino a 60 GB. Il livello successivo in su (che in realtà è ansible acquistare) è di 64 GB. Se il tuo consulente sta raccomandando un server a tre canali, il livello successivo potrebbe essere superiore a 72 GB. Quindi, il suo suggerimento non è necessariamente strano. Forse non hai bisogno di molti core / socket, e questo potrebbe scendere a un server a due canali (che sarebbe comunque più economico) e si potrebbe comprare un po 'less RAM.

    TLDR:

    In breve, che raramente sono, la RAM è economica e il tempo è costoso. Se non hai i soldi, il tempo o l'inclinazione per risolvere il database o non volete rischiare di aggiungere bug alla tua applicazione, gettare RAM sul problema è difficile da mettere in discussione. L'altra buona mossa è migliorare la reattività del sistema di memorizzazione del disco (IOW, aggiungere altri mandrini, più RPM o andare con SSD).

    Mi chiedo perché il consulente non abbia voluto che tu trascorti un anno e un US $ 100.000 per lui per riscrivere il sistema.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.