Newsgroup: it.comp.os.linux.sys
Titolo: Server per Oracle

Salve,
dorevi fare un server dedicato a un Oracle (+ vari script di 
elaborazione decisamente pesantucci).
Vorrei quindi chiedervi un consiglio.
Limiti: budget non be definito ma mi pare di avre capito che potrei 
arrivare ai 7000-8000 euro. Altro requisito: Hardware HP (ne abbiamo 
diversi, ci siamo sempre trovati bene e ho un server Insight Control 
Environment per il loro controllo).
Purtroppo niente macchina esterna di storage (SAS, iSCSI o FC che 
siano), deve essere un server singolo.
Avrei pensato a un DL380 G7 con due CPU Xeon da 6 core, 12 GB di RAM e 
dischi SAS in RAID 10 (ne supporta 8 o fino a 16 con hw aggiuntivo).
Premetto che da quello che ho visto ci sono circa 400 tabelle di cui 3-4 
con milioni di record (una con pochi milioni mentre un'altra con oltre 
40 milioni di record).
Le elaborazioni sono quasi del tutto di I/O (molto inserimento dati, o 
spostamenti da una tabella all'altra), non richiedono grosse 
elaborazioni di CPU o RAM. Attualmente sono su un DL380 G4 con Xeon 
DualCore, 5 GB di RAM e 6 dischi SCSI 72GB da 10000rpm (tre catene di 
mirroring).
Quindi mi concentrerei innanzi tutto sui dischi. Dite che 6/8 dischi SAS 
da 146GB 15000rpm in RAID10 possano andare bene?
Ah, lo spazio occupato non è tantissimo, attualmente lo spazio utile è 
di 216GB utilizzato al 65% (140GB in tutto) e la crescita è costante ma 
non esagerata (una 10/20GB all'anno circa), 438GB garantiti da 6 SAS 
andrebbero più che bene.
Riassumento, in termini di I/O i dischi SAS 15000rpm con il controller 
"HP Smart Array P410i/1GB FBWC Controller" potrebbero darmi una buona 
"potenza di I/O"?
Altra domanda da novellino (scusatemi ma ho sempre fatto solo dei 
semplici mirroring o al massimo RAID5), con quel controller, se io ho 6 
disci in RAID10 e ne aggiungo altri due, posso ampliare il RAID10 (senza 
distruggere i dati ovviamente) o posso solo fare un mirroring degli 
ultimi due e farlo vedere come disco separato?
Grazie.

 dischi SAS in RAID 10 (ne supporta 8 o fino a 16 con hw aggiuntivo).
Avete problemi di budget per la licenza? Verifica con un commerciale
quanto ti fanno pagare per quelle CPU.
Io con 8 dischi ho fatto due diversi array RAID10, cosï¿œ ho separato la
Flash Recovery Area dal resto.
Ciao
	Y.

 Flash Recovery Area dal resto.
Intendi per il backup?
Quello lo facciamo in maniera "manuale". Un dump completo da script 
tutte le notti che lo mette su un NAS. Poi un altro server "di servizio" 
con un'altra installazione di Oracle preleva il dump e ricrea il 
database "del giorno prima". Ci è servito diverse volte per controllare 
eventuali dati alterati in maniera non corretta, persi o altri controlli 
del genere (a livello quindi anche di singolo record).

 del genere (a livello quindi anche di singolo record).
E se ti servono i dati di 2 giorni prima?
E se qualcosa va storto durante il restore notturno?
E se i dati vengono aggiornati durante il dump?
Quello che fate può essere una cosa comoda, ma non può assolutamente
sostituire una vera procedura di backup del database, se i dati sono
importanti. Se hai dei dubbi cerca in rete o chiedi su
comp.databases.oracle.server.
Ad ogni modo io nella FGA oltre al backup RMAN metto gli archivelog e
gli onlinelog.
	Y.

 ultimi due e farlo vedere come disco separato?
No, non puoi espandere un volume RAID senza distruggere i dati. Ma ci
sono diversi modi per gestire l'espansione in maniera indolore (ad
esempio puoi usare LVM o semplicemente distribuire i datafile sul
nuovo volume).
bye!

 No, non puoi espandere un volume RAID senza distruggere i dati.
Uh? lo fanno tutti i controller raid HW decenti e anche il raid software 
del kernel (
https://raid.wiki.kernel.org/index.php/Growing
)
Non l'ho mai fatto ma con i serveraid della IBM potevi anche aggiungere 
dischi e passare a sistema avviato da RAID 1 a RAID 5 o 6

 mirroring).
Stocazzo, scusa.
"non richiedono grosse operazioni di CPU o RAM".
Se sono grosse elaborazioni SICURAMENTE richiedono tanta RAM, soprattutto 
se devi spostare TANTI dati.
Più che lo storage, quadruplica la RAM e ne trarrai giovamento 
sicuramente più grade.
Se riesci a far stare tutto il DB e gli indici in RAM, allora il sistema 
vola letteralmente.

 importanti.
Scusa, mi manca un passaggio, cosa intendi per vera procedura?
Cosa manca nei dump visto che sono completi (full=y) e che sono su altri 
dispositivi di rete (anche su piani diversi se c'ï¿œ un incendio qui nel ced)?
Se anche il server non dovesse piï¿œ ripartire (e qui mi sono dato una 
gufata tremenda ^_^), ho comunque una virtual machine pronta a 
ripigliarsi su tutto il dump.
Il vero problema (e su questo effettivamente ho un buco e lo ammetto) ï¿œ 
che la "granularitï¿œ" ï¿œ solo giornaliera, se dovesse succedere qualcosa 
la sera.... ehm... abbiamo perso i dati di un giorno (per fortuna alcuni 
sono ricostruibili in quanto vengono inseriti da varie fonti FTP, file, 
ecc...).

 nuovo volume).
Ach, lo immaginavo.
Mi sa che quando succederà distribuirò i datafile, con LVM non ho un 
gran feeling :-)


Aspetta, correggimi se sbaglio, ma un conto è quando uno deve fare delle 
select e allora sì, che si cerca di fare caching il più possibile in 
modo da prelevare i dati dalla RAM, ma quando andiamo a fare "70000 
insert" lui comunque deve scriverli su disco.
Lo vedo "in diretta", non usa praticamente mai swap (confermato sia da 
htop che da top), eppure tuttte queste operazioni di insert sono molto 
lente per via del tempo di "waiting di I/O".
Le elaborazioni richieste sono boiate, somme di campi e cose del genere 
la CPU non viene usata un gran che, al limite per i calcoli degli indici.
Comunque sarei ben lieto di sbagliarmi se la RAM velocizzasse anche queste.
In presenza di grandi quantitativi di RAM, Oracle "se li pappa" da solo 
o devo controllare bene parametri di avvio, tuning SGA o cose simili?

 ced)?
L'argomento è troppo vasto per essere trattato qui. Ci sono interi libri
sull'argomento su 
http://tahiti.oracle.com/
, es:
http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/toc.htm
Dove una delle prime cose che si legge è:
"Physical backups are the foundation of any sound backup and recovery
strategy. Logical backups are a useful supplement to physical backups in
many circumstances but are not sufficient protection against data loss
without physical backups."

 insert" lui comunque deve scriverli su disco.
Se tu non usi le transazioni, allora ogni singola insert/update implica 
una write su disco.
Se tu usi le transazioni, coò non è assolutamente vero.
La transazione viene tenuta in memoria, fino a che ci sta e poi scritta 
su disco.
Linux e oracle stessi (come altri DB) implementano metodi di "delayed 
fsync" che forzano la scrittura su disco quando necessario ma, se non usi 
le transazioni, questo avviene troppo spesso e saturi i dischi.
Se usi le transazioni e hai TANTA memoria, minimizzi i checkpoint che il 
DB deve seguire per salvare la roba su disco.
A prescindere da questo, se hai poca memoria ed il DB non ci sta tutto 
dentro, tu dici che: fai un sacco di select e poi fai un sacco di write.
Se il DB non sta tutto in memoria, ragionevolmente la testina frullerà 
per cercare il dato.
Poi fai l'insert/update) e la testina frullerà ancora per scrivere, 
ritardando la lettura del dato seguente...
E cosi' via...
Le lentezze sui database di solito (come trattato in precedenza) sono 
date da:
1) programmatori wannabe che non capiscono un cazzo
 (E qui puoi rientrare se non usi le transazioni)
2) mancanza di indici di sviluppatori certificati al CEPU
 (e qui non ne hai parlato ma controlla)
3) solo alla fine: CPU E DISCO.
Se dici che la CPU non è un collo di bottiglia ma lo può essere il disco, 
fai prestissimo a controllare.
lanci iostat (man iostat) per vedere quanti blocchi vengono scritti su 
disco al secondo.
Contemporaneamente fai una prova con DD per vedere la velocità GREZZA di 
scrittura dei disci.
Confronti questi dati con quelli che ottieni quando le tue procedure sono 
in corso.
Se sono comparabili, il tappo è il disco.
Se non sono comparabili, guarda altrove.
Hai tutti gli strumenti per capire se cambiare server per usare dischi 
nuovi ha senso o ha senso comprare TANTA ram nuova.


Ok, grazie per i consigli, vedo di leggermi un po' di roba.
Sinceramente non ho mai avuto problemi a prelevare qualcosa da un dump 
mentre qualche noia nel "copiare a mano i file fisici" c'è stata.

 Se non sono comparabili, guarda altrove.
Ok, è quasi chiaro.
Però non capisco le ultime due frasi. Se ottengo una certa velocità 
quando è scarico e ottengo la stessa velocità durante la procedura che 
intasa tutto, perché il tappo è il disco? Mi viene da pensare che sia il 
contrario e cioè che se riesce a scrivere bene lo stesso il tappo è 
qualcos'altro.

 qualcos'altro.
chi ha parlato di disco scarico ?? (man dd)
Schemino...
Quanto possono scrivere velocemente i tuoi dischi ??
BOOOH
Come faccio a saperlo ??
usi iostat.
Si ma mentre vedo i numerelli di iostat, che devo fare ?
Devi caricare il disco in modo da farlo andare più veloce che può.
Se va più veloce che può, allora presumibilmente iostat mi starà dando i 
dati massimi che i miei dischi possono supportare.
Ok... poi che faccio ?
Collezioni gli stessi dati, con iostat, ma quando le procedure stanno 
girando.
Ok, figo, l'ho fatto. E ora ?
Ora, hai i dati massimi dei tuoi dischi e i dati riferiti alle procedure 
del DB.
Se questi dati sono comparabili, allora anche con il DB il disco sta 
andando al massimo e quindi il tappo è il disco.
Se sono diversi, allora:
1) ho misurato male se il DB fornisce valori molto più alti di dd
2) oppure se il DB carica meno il disco, il tappo non è il disco.


Ok, ora è vermente tutto chiaro :-)
Grazie!

 40 milioni di record).
Appunto. 
Riguardo la distribuzione, visto che pagherai un mucchio di Euro per Oracle, 
non ha senso risparmiarne qualche centinaio di licenze Red Hat, rischiando 
di non poter ottenere supporto.
LG

 lo stesso e quello che risparmi lo usi per portare a 16/24 Giga la RAM.
Ok, mi avete convinto. Metto in preventivo altri 12GB in modo da 
portarli a 24.
Sempre nella speranza che poi lo prendano davvero il server ^_^

 Sempre nella speranza che poi lo prendano davvero il server ^_^
Ma falla la prova che ti ho suggerito no ?
Magari scopri che non devi upgradare niente ad esclusione della RAM.
Proponi al tuo capo di darti un bonus, visto il risparmio.

 Proponi al tuo capo di darti un bonus, visto il risparmio.
Ah ah ah, bella battuta!!! :-)

 ced)?
Una su tutte, il dump (o il data pump) lavora su dati "live" (ovvero, se 
cancelli una tabella mentre stai facendo il dump, ti viene riportato un 
errore nonostante la procedura vada a buon fine), mentre RMAN lavora su 
snapshot del database (ovvero, se cancelli una tabella mentre RMAN e` in 
esecuzione, non ti verra` riportato alcun errore e la modifica sara` 
riportata nel backup successivo). Inoltre, RMAN (con ARCHIVELOG attivati) ti 
permette di eseguire backup incrementali, senza considerare che ti permette 
di pianificare un intero disaster recovery, a partire dalla creazione ex 
novo del database
Enrico


Grazie delle info.
Vedrò di studiarmi RMAN.