Newsgroup: it.comp.os.linux.sys
Titolo: Nagios e Oracle

Ciao a tutti,
sto configurando alcuni check su una macchina oracle. In particolare
sto utilizzando questo plugin.
http://labs.consol.de/lang/de/nagios/check_oracle_health/
Che fa un sacco di check.. ecco appunto, io non ho grandissima
esperienza in merito a Oracle.
Quali di questi check sono sensati per un monitoraggio "corretto" ?
Che tipo di monitoraggio effettuate voi su oracle ?
grazie in anticipo

 Quali di questi check sono sensati per un monitoraggio "corretto" ?
Un consiglio generale: chiedi sempre a chi amministra un certo sistema
cosa abbia senso o meno monitorare.


Sono d'accordo,
ma da quanto ho capito si tratta di una macchina che cannibalizzano n
consultanti e quindi non ho un referente diretto e ovviamente il
cliente non sa niente tranne che "bisogna monitorare Oracle".
Solitamente mi danno un foglio e mi dicono devi monitorare questo
questo e questo.. stavolta no.
cia e grazie

 cliente non sa niente tranne che "bisogna monitorare Oracle".
Se lo scopo � vedere quali sono le query che schienano la macchina e se
le connessioni sono di tipo dedicated (a ogni connessione corrisponde un
processo shadow e viceversa) puoi anche usare top.

 ha scritto nel messaggio 
news:39dd8e88-a188-4008...@p4g2000yqm.googlegroups.com...

- Disponibilita' del servizio server (check_tcp sulla porta 1521 o quella 
eventualmente impostata)
- occupazione table space
- data buffer hit ratio
- carico cpu del sistema
- occupazione memoria del sistema
- spazio disco fisico
Il resto in funzione delle esigenze di chi usa il sistema che scoprirai 
strada facendo
Ciao
-- 
                      ^   ^
************** (.)_(.) *******************
 Un amico � uno che sa tutto di te e,
 nonostante questo, gli piaci
(E. Hobbard) 

Un grazie a tutti, alla fine ho optato per:
* check volumi oracle + e istanze
* load della macchina
* Data Buffer Hit Ratio per istanza
* Cache
* Invalid Objects
ciao

 ha scritto nel messaggio 
news:3c361896-f9ff-4ee3...@j24g2000yqa.googlegroups.com...

Se con volumi oracle intendi i dischi ma non i tablespace rischi di andar in 
crash per db pieno. Se intendi i tables space rischi di andar in crash per 
archive log o altro.



Chi ha concepito questa installazione di oracle ha deciso di usare
come spazio di storage dei LV in ext3 su RHEL5.
Vecchie installazioni hanno generato gli stessi problemi, ma io non
sono stato coinvolto direttamente nè mi è stato chiesto parere.
Ripeto, non sono un guru di Oracle ( a forza di dai, mi iscriverò a
qualche corso), ma presa la documentazione in mano, credo di aver
capito come si dovrebbe fare e come invece è stato fatto.
Il monitor ho deciso di farlo sull'LVM, non sui tablespace, anche
perchè, onestamente, si tratta di valori che non so quanti siano in
grado di leggere i dati che salterebbero fuori.

 grado di leggere i dati che salterebbero fuori.
scusa l'italia-cano, sono malato e faccio fatica a connettere...

grado di leggere i dati che salterebbero fuori.
Neanch'io sono un esperto di Oracle e l'ultimo che ho gestito risale alla 
prima release 8. Pero' i tablespace sono i contenitori entro cui crescono i 
db e le tabelle. Tu puoi anche aver giga di disco ma se non e' configurato 
perche' il tablespace si auto espanda, raggiunto il limite definito ogni 
transazione che richiede un aggiornamento va in rollback non potendo 
estendersi oltre lo spazio definito. Credo che questo controllo sia 
importante, pero valuta tu.


 importante, pero valuta tu.
Certo che è importante !
Grazie, ho imparato qualcosa anche oggi.
ciao

 archive log o altro.
Dipende da come configuri l'istanza di Oracle:
- Abilitare l'espansione automatica delle tablespace non e` mai una
  buona idea, in quanto ti mette a rischio di problemi del genere. Molto
  meglio un dimensionamento iniziale delle tablespace adeguato alla
  tipologia di lavoro del db e poi incrementare i datafile in caso le
  esigenze mutino oppure vi sia un aumento dei dati non previsto.
- L'abilitazione degli archivelog e` utile in molti casi, ma dannosa in
  molti altri. Se e` vero che ti mette al riparo da possibili danni al
  database, e` vero anche che le prestazioni del database ne risentono
  drammaticamente. A questo punto, visto che Oracle mette a disposizione
  parecchi meccanismi per il recupero dei dati (mi ricordo che una volta
  ho ricostruito un database Oracle partendo dai datafile), molto meglio
  utilizzare questi ultimi ed evitare gli archivelog (senza contare che
  il backup del database, fatto per mezzo di export e via datapump,
  dev'essere il primo accorgimento di qualsiasi DBA).
Enrico

   dev'essere il primo accorgimento di qualsiasi DBA).
Quello che scrivi � molto pericoloso, perch� qualcuno che non conosce
Oracle potrebbe prenderlo per buono per il solo fatto che � scritto in
un NG.
Export e datapump *non* sono un backup del database ma un export logico
dei dati e *non* sostituiscono il backup del database, che deve essere
assolutamente fatto come si deve a meno che i dati del database non
siano fuffa. Per fare un backup del database come si deve gli archivelog
sono *indispensabili* ed � assolutamente falso che "le prestazioni del
database ne risentono drammaticamente". Infine, ricostruire un database
sputtanato partendo dai datafile � possibile solo in circostanze
eccezionali e non � certo la norma.
Non so su quali basi si fondano le tue affermazioni ma ti consiglio di
tradurle in inglese e di postarle su comp.databases.oracle.server, poi
mi dici qual'� la parola pi� gentile con la quale ti hanno apostrofato...
y.

 mi dici qual'è la parola più gentile con la quale ti hanno apostrofato...
Le mie basi si fondano soprattutto sulla mia esperienza diretta e
sull'esperienza delle persone con cui lavoro e/o con cui ho avuto a che
fare a riguardo. Detto questo, ti ringrazio per il consiglio, in quanto
non solo ritengo che il confronto con altre persone sia quanto di piu`
costruttivo si possa fare in un campo come quello informatico, ma
sicuramente c'e` e ci sara` sempre qualcuno che ne sa piu` di me in
determinati ambiti (anche perche`, da quello che hai potuto capire, la
mia esperienza e` limitata rispetto a quanto vorrei). Del tuo discorso,
pero`, non capisco una cosa: perche` non consideri un export o un
datapump forme di backup? In definitiva, un export full mi permette di
salvare tutti i dati presenti nel database senza problemi. Le uniche
rogne ad usare una tecnica del genere sono date dal fatto che non mi
vengono esportate definizioni come utenti e tablespace, a cui pero`
basta poco per porre rimedio
Enrico

 basta poco per porre rimedio
Basta poco... dipende dalla complessità del database. Quando cominci ad
avere decine di schemi e utenti coi loro profili e grants può essere un
casino ricostruire la situazione. Anche i parametri di configurazione
del database, inoltre, sono importanti. Considera infine che l'export
non ti assicura la consistenza dei dati, il backup (hot o cold) sì.
Io normalmente faccio due tipi di backup: il full hot backup del
database serve a pararmi il sederino in caso di crash completo del
server, poi faccio un export per ogni schema per rimediare ad eventuali
errori umani.
Riguardo all'esperienza, nel mondo del crash recovery è meglio non
averne, nel senso che sarei ben felice di non avere mai bisogno di
ricorrere al mio backup. Però preferisco pararmi il sedere il più
possibile. Al giorno d'oggi fare un backup completo del database a caldo
è un'operazione talmente semplice e poco costosa che non vedo nessun
motivo valido per non farla a meno che, ripeto, i dati non siano fuffa.
Ciao
	Y.

 non ti assicura la consistenza dei dati, il backup (hot o cold) sì.
Ultimamente ho avuto parecchio tempo a disposizione che mi ha permesso
di dare un'occhiata approfondita al discorso. Le considerazioni da me
fatte, soprattutto considerando la mia situazione, sono state che, oltre
ad essere stato fortunato fino ad ora, conoscevo a malapena gli
strumenti che avevo a disposizione. Posto che RMAN e` sicuramente uno
strumento piu` potente di quello che ho potuto vedere, ma che mal si
adatta alle mie esigenze (l'uso degli archivelog si sente, e parecchio),
sono rimasto piacevolmente stupito del funzionamento dei data pump, che
equiparavo ad un export con la quarta ingranata. Con un backup eseguito
per mezzo di tale metodologia posso ricostruire tranquillamente la base
dati, in quanto nel datapump vengono salvate anche le definizioni degli
utenti (con tanto di password), delle tablespace (con tanto di numero e
posizione dei datafile) e di tutti i dati necessari per ricostruire il
database allo stato precedente al data pump. Personalmente, per ora,
penso di utilizzare questa metodologia per effettuare il backup dei miei
database (sicuramente e` un grande passo in avanti rispetto a prima).
Certo, ovviamente rimangono scoperti dei punti da te citati (e.g.
la consistenza del backup), ma per ora e` un rischio che mi sento di
correre :)
Enrico