Newsgroup: it.comp.software.database
Titolo: Gestione di un sistema Oracle 8.1.7

Ciao a tutti,
comincio subito a spiegare il mio problema:
Nella ditta per la quale lavoro si fa un largo uso del database in
oggetto in particolare per l registrazione di dati sensibili di privacy
degli utenti e delle chiamate a loro fatte.
Sul server database c'è una Red Hat 7.x e Oracle 8.1.7.
Il mio problem è che, a parte i dump giornalieri e relativo backup non
ho altro e il sistema dev'essere operativo 24/7 il che implica saltare
giù dal letto e correre in ufficio in caso di problemi.
Ora, ritenendo il mio sonno una cosa sacra e imprescindibile (lo so,
non dovevo fare il sysadm..) ho intenzione di preparare un server di
backup.
In questo senso ho provveduto ad installare il server di Oracle su un
2003 enterprise che al momento è abbastanza scarico.
La domanda è questa: in caso di crash del server primario è possibile
rendere il secondario operativo entro breve? L'importazione del dump
port via circa 3/4 ore, se non erro mi costringe ad eliminare e
ricreare lo user ed in ogni caso si tratta del dump del giorno prima
(con conseguente perdita di dati), è possibile tenere sincronizzati i
2 server in qualche modo?
Grazie a tutti coloro che mi risponderanno,
Vittorio

 degli utenti e delle chiamate a loro fatte.
deve essere una ditta POCO affidabile !
vedi di non pubblicizzare la cosa,
i clienti potrebbero NON gradire che i loro
dati sensibili siano su una versione di
DBMS fuori dal supporto.
il sui milgior tecnico chiede lumi su un NG !
GRIF ?
felice_pago
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 serio.
ah ma tanto sopra ci sono dei dati sensibili,
del cliente, mica niente !
ps:
sempre NL ?


    -- Noel Maddy
Maaah DB delle "Storie della sala macchine"?
Vittorio

 Non-Looping?
ho letto che sei diventato amerregano !
e minghia !


 in quel modo, usando una versione di Oracle e di RedHat supportata.
Per usare una versione di Oracle supportata bisogna pagarla..
Gli UberLuser locali non sono molto per la quale
La replica dei dati è fattibile indipendentemente dall'Os installato,
basta che la versione di Oracle sia la medesima, per il clustering ci
vogliono 2 macchine = in ogni senso?
V

 E allora digli che si attacchino al tram.
vedi che tanto ti conforti del fatto che
sei venito via da qua ?
:)


 Vittorio
Ciao,
soluzioni al tuo problema ne esistono, alcune anche molto performanti,
ma hanno un costo.
La piů veloce secondo me consiste nel mettere i datafiles su storage NFS
e avere due server con l'istanza configurata in modo identico. Se un nodo
va giů devi solo montare il volume sull'altro e startare l'istanza. Da
quě, passando per i cluster e le funzioni di replication proprie di
Oracle la scelta č soggettiva, ma presuppone una certa conoscenza della
piattaforma e, sopratutto un investimento in nuovo h/w.

 Windows is the best GUI - It always sticks!
Vi spiego, sono preoccupato a pari livello dei failure hardware e
dell'imputtan4mento software.. Capita che l'Oracle 8.1.7 abbia un baco
nella gestione dell'autoextend ovvero non ridimensiona un cacchio!
Arriva al limite e quando i pisquani CL lanciano determinate funzioni
il sistema decide che è ora di prendersi alcune ore di pausa e non
porta a termine il lavoro.
Situazione che ho risolto banalmente incrementando il numero di files
nelle tablespaces.
Il problema si è verificato alle 11.30 di sera di un lunedì fa, onde
per cui mi sono collegato in remoto per cercare di ripristinare la
situazione.. Mentre tentavo di ridimensionare la tablespace sono stati
eliminati i file .arc... quindi non sono + riuscito a tornare indietro
dalle modifiche fatte (QUELLA tablespace era off) e non ero in grado di
tirarla in piedi. Morale? Una notte in piedi a rispondere a UL(x) +
CL(x) (x tendente a + infinito) e andare avanti a tentativi inutili
quando ad un tipo on ADEGUATE competenze Oracle (che ovviamente mi
mancano..) sono bastati 20 minuti in vpn. Ovviamente non c'è stato
passaggio di know how e sembra che il tipo sia difficilmente
rggiungibile

 Davide
Be, uno già lo ha di server, quello in produzione.
Dovrebbe caso mai comprare uno storage esterno da 
condividere via NFS e trovare il modo di portare i
datafiles su quest'ulitmo col minimo disservizio.
Per la congruenza della base dati, si spera che un
recovery automatico allo start sia sufficiente,
altrimenti deve anche essere un buon dba a prescindere
dal tipo di architettura. Ovviamente lo storage NFS io
lo immagino "almeno" in raid, con dischi di spare ecc.ecc
Ovviamente quì si parla di dare consigli di massima.
Non mi sognerei mai di spiegare via ng come si gestisce
un cluster oracle!
ciao

 Davide
assolutamente d'accordo, sopratutto poi se è
accoppiato con pct_increase > 0 
inorridisco.....

 "Does it involve a high-powered rifle and a belltower?"
Vittorio


 A parte che mettere il db in NFS mi sembra un idea pessima a prescindere, 
qui lui ha un linux ed un win2003, quindi diversa architettura, x cui 
datafiles non son compatibili..

>> acquistarne uno solo (drdb per i dischi).
..e cmq, a prescindere dalla replicazione, sarebbe opportuno innanzitutto 
implementare una politica di backup fisico, oltre che gli export...

 implementare una politica di backup fisico, oltre che gli export...
Intendi una macchina di backup?
V

 datafiles non son compatibili..
Perché mai? dico sul serio, che problemi ci vedresti?
Dove lavoro io sono *tutti* con storage NFS, su cluster
Sun certificati e vanno a meraviglia.
Ovviamente la macchina win la scarterei!
ciao

 ha scritto nel messaggio 
news:1163156038.1...@i42g2000cwa.googlegroups.com...

No. Intendo proprio fare il backup del db. 


Se hai una struttura certificata, può andare, ma è cmq preferibile una SAN.
La stessa Oracle dice:
"Oracle does not support and recommend using an NFS device unless the NFS
vendor is a member of the Oracle Storage Compatibility Program (OSCP)
(See 
http://otn.oracle.com/deploy/availability/htdocs/vendors_nfs.html
 ).
Members in the Oracle Storage Compatibility Program (OSCP) test and verify
their products compatibility with the Oracle Server product"
Ora, non mi sembra il caso del ns. amico...

Mentre cercavo di capire la differenza tra una select e un drop database


ok, se riferito al caso specifico allora ti do in parte ragione.
Dico in parte perché, per dirla tutta, la certificazione ha senso
se è richiesta per motivi di "scarico di responsabilità" e per
ragioni contrattuali. In altre parole, dove lavoro io tutto  (quasi) è
certificato perché i contratti di supporto con le società
fornitrici di h/w e s/w ti vincolano a farlo a tutela di entrambe le parti.
Ma a titolo di test interno, abbiamo più volte verificato che anche 
piattaforme non 100% compliant con quanto richiesto dal produttore,
sono funzionanti e garantiscono ai fini pratici le stesse funzionalità.
Ora, non mi sembra che il nostro amico, come lo chiami tu :) stia in un
ambiente dove si sta stretti tra SLA e vincoli con i fornitori. Lungi da
me provocare discussioni infinite sul ng eh....
ciao

 Davide
Già sucesso, poteva solo essere MOOOOOOOOLTO peggio, e vi assicuro che
le operazioni che dovrebbero consentire il ridimensionamento automatico
le ho sempre fatte.. solo che pare non funzionino!
V


No, in questo caso la faccenda è diversa: NFS di per sè è un protocollo 
stateless, cioè quanto di meno adatto a garantire sicurezza ed integrità 
delle scritture su un disco.
Nelle architetture NAS che sono supportate da Oracle, tale protocollo è 
stato pesantemente modificato od implementato in maniera tale da sopperire 
alle sue "deficienze" (deficienze in questo ambito, x intenderci, che x 
altri utilizzi va benissimo).
Ma pensare di mettere su Oracle semplicemente su un FS esportato via NFS su 
un server è un suicidio.

Mentre cercavo di capire la differenza tra una select e un drop database


guarda, quello che dici è vero, sulla carta NFS non è il massimo
della sicurezza. Però, c'è modo e modo di fare le cose.Io ovviamente
intendevo il modo corretto :)
Se il volume NFS è accedibile attraverso uno switch dedicato (in
fibra ovviamente), se il SO è quello giusto (Solaris per es.), se la
configurazione di tutto il "contorno" è corretta, ti assicuro che la
possibilità di corruzione di qualche blocco è un evento raro.
Per quanto mi riguarda, come già detto, tutti gli Oracle sono configurati
così e, almeno negli ultimi 4 anni, cioè da quando me ne occupo io
non ci sono mai stati problemi. E ti garantisco che sono db di importanza
rilevante in azienda.
Cmq, visto che the.tzunami non vive evidentemente la mia stessa
realtà lavorativa, direi che sto andando OT quindi chiudo. ;)
ciao