Newsgroup: it.comp.software.database
Titolo: devo mettere in piedi un db server...

Devo mettere in piedi un db server conbinato con un application server.
x l'hardware quali parametri devo valutare principalmente?
La velocita' di calcolo, la velocita' della memoria di massa, la capacita'
della memoria di massa, ecc.
Grazie
Massimo D.

 x l'hardware quali parametri devo valutare principalmente?
Senza sapere _quale_ application server, _quale_ database server,
come verra' utilizzato il tutto etc. e' impossibile dare delle
informazioni.
Ma se fai domande cosi' campate per aria, mi sa che sei parsec
fuori dalla tua area di competenza... forse fai meglio a rivolgerti
ad una societa' di consulenza.
Davide

 ha scritto nel messaggio
news:bf8vrd$c8iq6$1...@ID-18487.news.uni-berlin.de...

mi scusa x l'imprecisione della domanda ma in realta' richedevo
dei parametri generali di valutazione e non una soluzione.
Da quello che mi risulta un application server "generico" deve avere
come caratteristiche una alta capacita' di calcolo (server biprocessore...)
mentre un db server "generico" una alta velocita' alla memoria di massa
(velocita' dei dischi). Chiedevo solo una conferma ed eventualmente
ulteriori parametri di valutazione.
Massimo D.

 (velocita' dei dischi).
Anche questo non e' del tutto vero. Tutti i database ottimizzano in vari
modi l'accesso ai dischi utilizzando meccanismi di caching. 
Ripeto: rivolgiti ad una societa' di consulenza.
Davide

 ha scritto nel messaggio
news:bf98g6$c8uh7$1...@ID-18487.news.uni-berlin.de...

Lavoro x un'azienda non informatica in cui l'informatica, con tutti i suoi
consulenti,
e' vista come un "costo" e nulla piu'... figurati cosa mi risponderebbe la
"propieta'"
o gli "acquisti" (sono la stessa cosa...) ad una richiesta di consulenza x
l'implementazione
di un db server gia' x loro esosa... :(
Dato che l'ambiente e' questo (penso che molti colleghi sono nelle mie
condizioni...) purtroppo
ci si deve dare un pizzico sullo stomaco ed andare avanti :)
Premesso questo,
tutto quello che dici e' vero...
il caso mio, piu' generale, consiste in un gestionale aziendale (ERP) che
utilizza
un DBMS (Oracle, SQL2000, Informix, DB2, ecc..), tutto su una rete
Fast-Ethernet
basata esclusivamente su switch.
Saluti,
Massimo D.

 basata esclusivamente su switch.
per rispondere alle tue richieste e qui si entra in consulenza:
qual'è il carico dei dati dai client al server db?
tipo di connessione?
protocollo?
tipologia e topologia di rete?
il server deve garantire un uptime a 5 nove?
disaster recovery?
ecc.
queste sono alcune delle domande che devi porti, ma come vedi è solo la
punta dell'iceberg
-- 
ITHost (your host company)
Technical Manager
C. Paparelli (MCSE,MCSD,MCDBA)
http://www.ithost.ch


Secondo me, il problema e' molto meno complesso di come lo state ponendo...
prima di tutto non devo automatizzare una banca e non devo garantire un
servizio
24x7 :)
devo solo rendere piu' efficente la situazione attuale approfittando di
alcuni
cambiamenti in atto.
Grazie comunque,
Massimo D.

 24x7 :)
ok, ma supponi che per un motivo o per un altro il computer si guasti puoi
permetterti di lasciarlo spento per x ore, fino a che il guasto non č
risolto?



Il servizio piu' critico e' sicuramente la bollettazione, questa deve essere
effettuata
da tutti gli stabilimenti, piu' volte al giorno... ma anche qui se ci fosse
l'urgenza di spedire
ed il sistema informatico non rispondesse...si prende carta e penna e si
bolletta a mano!
X mia esperienza, la generalita' dei guasti, lascia sempre qualche spiraglio
di
ripresa... basta individuarlo ed attuarlo prontamente, cercando con la
massima
calma di risolvere il problema definitivamente.
Se avessi dovuto informatizzare una banca, un'attivita' di e-business,
un'azienda che fornisce
on-line servizi a terzi... beh allora avrei "preteso" una task-force di
consulenti :)
non e' questo il caso pero'...
Massimo D.

 sapere come implementarle....
Secondo me potresti facilitarti la vita sentendo il parere di 2 o 3
fornitori diversi che ti sembrano seri: spiegagli esattamente il tuo
problema e fatti fare un preventivo con una pre-analisi (questa viene fatta
gratuitamente). Fatti quindi spiegare BENE cosa intendono fare (con elenco
dei costi, cambiamenti da affrontare, benefici, bonta' del sistema etc.).
Alla fine avrai le idee un po' piu' chiare (e probabilmente scoprirari chi
cerca di venderti dei prodotti che non hanno nemmeno alla NASA ;-) ).
Ultimo consiglio (forse inutile perche' lo sai gia'): se un preventivo
differisce di parecchio dagli altri (sia in piu' che in meno) cerca di
capire il perche'. Di solito non e' un buon segno...
E' un procedimento che richiede un po' di tempo, ma di solito paga.
Buon lavoro
  Stefano

 cerca di venderti dei prodotti che non hanno nemmeno alla NASA ;-) ).
è un ottimo suggerimento, ma occhio che molte volte il commerciale che
redige l'offerta, vuoi per incompetenza vuoi perchè è una scelta voluta
(leggi fatturazione in un secondo tempo delle dimenticanze con maggiorazione
della tariffa e/o costi), ti propina un offerta incompleta.


 della tariffa e/o costi), ti propina un offerta incompleta.
Vero, e' per questo che piu' si e' chiari all'inizio e meglio e'.
Secondo la mia esperienza questo e' l'iter:
- Primo incontro cliente/fornitore per la definizione degli obiettivi.
- stesura di un preventivo/analisi di massima da parte del fornitore
- Se il cliente e' interessato seguono altri incontri per meglio definire le
richieste
- stesura di un preventivo dettagliato (prezzi, tempi, caratteristiche del
sistema)
- eventuale accettazione del preventivo da parte del cliente
Per chi e' interessato qui ho trovato una facile guida UML che aiuta in
questa (ma anche in altre) fase:
http://programmazione.html.it/uml/
L'eseperienza insegna che il tempo impiegato in fase di progettazione non e'
mai tempo perso (tutt'altro!).
Ovviamente si spera che sia il cliente che il fornitore siano persone serie,
altrimenti si hanno solo perdite di tempo..
Ciao
  Stefano


Vero, a patto che le persone coinvolte siano quelle adatte :)
