Newsgroup: it.comp.software.database
Titolo: Business continuity

Ohhhh allora,
arriva un cliente con in mano un depliant e mi riempie di parole strane ...
-----------------------------
ORACLE
RAC
BUSINESS CONTINUITY
FAILURE PREVENTION
BACKUP ATUTTICOST
e via di questo passo...
-----------------------------
Poi mi chiede "E noi queste cose cell'habbiamo tutte vero ???"
Risbosda "No, manco una cellh'abbiamo "
Answer   "E perche ???"
Risbosda "Perche' ve le avevo proposte gia' due anni fa, proposta bocciata 
visto i costi ..."
Chiaccherata finita li
Pero' il tipo, andando via, ripensava al depliant e a tutte 'ste belle 
parole sberluccicanti
Quindi, vorrei proporgli qualcosa che gli permetta un minimo di  'business 
continuity' tanto da permettergli di dire agli amici al bar che lui ha il 
sistema 'high availability'
Insomma un qualcosa del tipo "se si spacca la componente X  il sistema 
informatico e' ancora operativo"
Attualmente sono circa 10 postazioni che accedono ad un  file/db server (win 
xp + db server firebird)
Grossomodo 4 Gbyte di file documenti e db da 2 Gbyte
Pensavo di proporgli una seconda macchina per mantenere un duplicato del 
file/db server principale
Come gli replico i file ?
Ed il db server ?
Cosa fareste voi ?
Ciao e grazie
RobertoA

 
Due Server Blade IBM + NAS
Cerca con google IBM server e IBM NAS
Saluti
Max

 Cerca con google IBM server e IBM NAS
E se 'defunge' il nas (si dice defunge ?)  ???
Ciao
RobertoA


A parte che se bisogna identificare dove si vuole la business
continuity, per il database oppure su altri servizi?
Suppongo sul database (altrimenti sei OT), ma in questo caso la
soluzione non si basa solamente sull'architettura e l'hw da utilizzare
ma anche di una configurazione idonea del DB.
E cmq dipende sempre dal servizio che si vuole offrire e dal budget a
disposizione, etc..
Una volta definito ciò che si vuole ottenere e con quale spesa, allora
si raffrontano le possibili soluzioni, che saranno indicativamente in
ordine di affidabilità e continuità (e di costo):
1) RAC con SAN + ridondanza apaprati di rete
2) DB operativo + Standby database
3) Varie soluzioni entry level
Ma non bisogna dimenticare la parte di config. sw, ovvero (parlo per
oracle) l'implementazione di Archivelog + backup offline/online ed una
corretta procedura di backup su nastro, il tutto che garantisca un
ripristino in brevi tempi (vedi SLA) e sopratutto di Disaster Rec.
Anche questo è business continuity...
bye
Andrea

 bar che lui ha il sistema 'high availability'
Hum deja vu... ho come la sensazione che la soluzione non sara'
puramente tecnica... preparati ad usare un po' di linguaggio da
marketing; accanto alla soluzione tecnica, trova qualcosa da fargli
raccontare agli amici del bar, e ti raccomando la stoccata finale:
"...e comunque costa molto ma MOLTO meno"; funziona sempre :-DD
bye 

 RobertoA
A parte che se bisogna identificare dove si vuole la business
continuity, per il database oppure su altri servizi?
Suppongo sul database (altrimenti sei OT), ma in questo caso la
soluzione non si basa solamente sull'architettura e l'hw da utilizzare
ma anche di una configurazione idonea del DB.
E cmq dipende sempre dal servizio che si vuole offrire e dal budget a
disposizione, etc..
Una volta definito ciņ che si vuole ottenere e con quale spesa, allora
si raffrontano le possibili soluzioni, che saranno indicativamente in
ordine di affidabilitą e continuitą (e di costo):
1) RAC con SAN + ridondanza apaprati di rete
2) DB operativo + Standby database
3) Varie soluzioni entry level
Ma non bisogna dimenticare la parte di config. sw, ovvero (parlo per
oracle) l'implementazione di Archivelog + backup offline/online ed una
corretta procedura di backup su nastro, il tutto che garantisca un
ripristino in brevi tempi (vedi SLA) e sopratutto di Disaster Rec.
Anche questo č business continuity...
====================================
Iniziamo col dire che non e' che viene qualcuno in ufficio e ti chiede 
"Senti ho 20.000 euri da spendere, cosa mi viene ?"
Se il soddisfare un bisogno e' realmente sentito, si potra' soddisfarlo 
opure no se vi sono le sostanze per farlo
Quello che serve al cliente attualmente e' = Niente
Solo che vorrei cogliere al volo l'opportunita' offerta dal magico depliant 
per fornirgli almeno qualcuna delle paroline che gli accendono la fantasia
Insomma, quel che voglio dire e' che non c'e' attualmente un'obiettivo 
preciso da raggiungere
Ma che proporgli un sistema per 'irrobustire' l'impianto attuale sarebbe 
sicuramente ben visto
Quello che vorrei riuscire a proporre e' un sistema del secondo tipo, cioe' 
un db copia sempre pronto ad intervenire, al posto del principale se 
necessario
La commutazione dal principale al secondario andra' fatta manualmente
Vorrei mantenere il db secondario su un secondo computer cosi' da diminuire 
anche la sensibilita' ad eventuali problemi hardware dell'elaboratore 
principale
Ciao
RobertoA

 principale
ma che db ha?
Se ha oracle la soluzione migliore nel caso che hai descritto è sicuramente
uno standby database da tenere di scorta nel caso succedesse qualche disastro
su quello principale, oltretutto è possibile utilizzare cmq lo standby per
ottenere reportistica o query varie (datawarehouse) in sola lettura.
Ed inoltre una soluzione del genere è economica.
Se ti interessa ti mando qualche link in base alla versione in uso.
se però non è oracle... allora non ho idea :)

 se però non è oracle... allora non ho idea :)
Anche con PostgreSQL è possibile una cosa simile:
http://www.postgresql.org/docs/8.2/static/high-availability.html
Saluti  Manlio Perillo

 
http://www.postgresql.org/docs/8.2/static/high-availability.html
E' come paragonare una ferrari ad una 500....
G.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 E' come paragonare una ferrari ad una 500....
Con una ferrari oramai non vai piu' da nessuna parte
Una 500 va benissimo per il 90% delle cose per le quali ti serve un'auto
Guindi ==>> e mejjo la 500
RobertoA

 
per oracle:
http://www.oracle.com/technology/deploy/availability/htdocs/DataGuardOverview.html