Era tanto che non scrivevo una nuova avventura. L'ultimo risale al 3/9/2006. Spero che quello che segue
vi farà sorridere.
Prima di procedere però, vorrei sottolineare il concetto che le (dis)avventure sono di pura fantasia ed il DBA
di cui parlo non esiste. Come potrebbe? Ribadisco quindi che tale persona è un parto della mia immaginazione.
Dunque, tutto comincia a seguito di un problema avvenuto durante la notte su un cluster SUN a 4 nodi: improvvisamente tutte
le transazioni dei webserver si bloccano ed i database non sono più raggiungibili.
Su uno dei 4 nodi del cluster, girano due istanze: una Oracle 8iR3 e l'altra Oracle 9iR2. La mattina dopo,
il sistemista invia una email per comunicare l'accaduto.
Vi riassumo brevemente l'accaduto di stamane sul cluster.
Abbiamo terminato ora le operazioni di ripristino dei resource group DB1-rg e DB2-rg che questa mattina hanno
spontaneamente tentato (a quanto sembra) uno switch, che poi è fallito.
Quando ci siamo collegati, abbiamo trovato i resource group in uno stato di fallimento, le risorse storage erano montate
ed alcuni processi erano rimasti appesi, tutto questo inibiva ogni azione di switch da un nodo all'altro.
Pertanto abbiamo optato per riavviare l'intero nodo ospite delle due istanze per riordinare la situazione a livello di
cluster, questo ha poi reso possibile il restart dei due resource group manualmente (sempre a livello di cluster).
Sia a livello di sistema che di database la situazione sembra essere stabile.
Chiamo il dba per scambiare due chiacchiere e sembra che il responsabile del problema è il processo "in.mpathd" di Solaris.
La definizione di tale demone la potete trovare al
seguente indirizzo. Di seguito
riporto una breve definizione, presa direttamente dal link indicato:
The in.mpathd multipathing daemon detects failures and repairs by sending out probes on all the interfaces that are part
of a group.
Dopo qualche ora, il problema si ripresenta. Questa volta è il
nostro dba ad informaci dell'accaduto.
Si sono presentati di nuovo problemi sul cluster.
Il log di oracle però segnalava il seguente errore:
Errors in file /app/DB1/oracle/admin/DB1/udump/DB1_ora_27025.trc:
ORA-07445: exception encountered: core dump [0000000100600DE0] [SIGBUS] [Object specific hardware error]
[0xFFFFFFFF7CCB0000] [] []
E' un problema di questo tipo:
An ORA-7445 error is raised by an Oracle server process when it has received a fatal signal from the operating system.
Data la situazione abbiamo deciso di switchare l'istanza DB2 su nodo2 e l'istanza DB1 su nodo3.
Se il problema è relativo al nodo cldbrm1a non dovrebbe più presentarsi.
Speriamo.
In pratica, isolano il nodo su cui risiedeno le due istanze. Effettivamente se il problema è di tipo
hardware, l'unica cosa da fare è quella spostare le istanze sugli altrni nodi.
Risentiamo il dba. Ci dice che dato l'errore presente
nel file di trace, ritiene che il problema sia da imputare al Bug numero 1367773. Suggerisce la nota
1367773.8. Leggendola osserviamo che:
- Le versioni impattate sono >= 8 ma < 8.1.7.1
- Le piattaforme influenzate sono tutte
- Il problema è fissato in 8.1.7.1 (Server Patch Set) e 9.0.1.0 (Base Release)
- Il sintomo è un "Memory Leak"
- Il workaround è (riporto direttamente dalla nota): Periodically "alter system set job_queue_processes = 0;" and wait
until all SNP processes are gone then restart some new processes.
Risentiamo il dba il quale ci aggiorna e dice che a seguito del bug, sull'istanza 8.1.7.4, risulta che la memoria dei
processi snapshot è di 11GB e che applicando il workaronud, la dimensione dei processi era diminuita ed a nulla era
servito il restart del db: i processi erano rimasti ad 11GB.
11GB? Azz, il sistema operativo è stato configurato per permettere che un processo utente possa raggiungere tali dimensioni?
Ma poi, il bug non è stato fissato in 8.1.7.1?
11GB...wow. Ci pensate? un processo occupa 11GB di RAM. Pazzesco. Forse conviene che i sistemisti limitino le risorse
all'utente oracle in modo da evitare una tale situazione.
Voglio dire che se si permette ad un singolo processo di crescere in questo modo, si rischia poi di andare in contro a
situazioni non controllate.
Non so voi, ma ci sono ancora dei punti oscuri, dei passaggi non chiari. Gli chiediamo spiegazioni via email:
Cia, dba. Ho letto il documento che mi ha passato, relativo al bug 1367773. Non ho trovato però nulla che indicava che
la dimensione dei processi SNP non si riazzera a seguito di un restart del db. Un’altra cosa. Come è legato la non
raggiungibilità del database con questo bug? Dopo la telefonata di ieri sera, ero convinto che il problema fosse da
imputarsi al processo “in.mpathd”.
E lui risponde:
I processi incriminati avevano un uptime di circa 25 giorni, allocavano 11G di memeoria ciascuno. L'ultimo restart del db è
avvenuto alle 14:37 del 5 Febbraio 06 (oggi è 6/2). Ne deduco che il restart del db e addirittura del nodo avvenuto il
giorno prima non azzerano l'allocazione di memoria dei processi snp. Abbiamo verificato che l'errore relativo
al multipathing era una conseguenza non una causa del problema.
In questo stato la macchina andava in swap, priva di risorse per i processi oracle.
Comunque stiamo a vedere cosa succede nelle prossime ore.
Domani manderò una mail esplicativa(spero) di quanto è successo. Voglio prima aspettare che non si ripresenti il
problema.
Bhé la macchina andava in swap: il fatto che il db non rispondesse più era allora solo il sintomo di una estrema lentezza
della macchina.
Mmmm.....i processi snp allocavano 11GB ciascuno.....mmmmm, mi viene un sospetto: non è che il nostro sta misurando la
shared memory? Noooooooo, non è possibile, lo saprà che ogni processo Oracle condivide la SGA e che la dimensione che
si vede con ps, ad esempio, non è quella reale ma quella condivisa. Del resto che gli
dico: "scusa ma sai come si legge il ps?". No no. E poi il workaround ha funzionato per cui il problema deve essere
sicuramente quello.
Io però una parte della email mica l'ho capita. Che vuol dire che "il restart del nodo del giorno prima non ha azzerato
l'allocazione di memoria? Qui urge rettifica e quindi gli scriviamo una nuova email:
Giusto una curiosità. I processi snp avevano un ultime di 25gg, nonostante il restart del db. Poiché i processi snp sono
processi che partono insieme agli altri porcessi oracle, stai dicendo che nonostante il restart del db, questi restavano
in piedi?
Un “kill -9”, avrebbe avuto allora lo stesso effetto?
Cosa vuol dire che “il restart del nodo non azzera l'allocazione di memoria dei processi snp”?
Bhè, non ci resta che aspettare e levarci ogni dubbio:
Che anche dopo il restart del nodo i processi sono restati in vita con i loro 11G.
:-() Ahahahah, che uomo di spirto. Tu restarti la macchina ed i processi restano su.....ahahahah. Però voglio dimostrare
di non essere di meno, così faccio finta di stare al gioco:
Cioè stai dicendo che se riavvi la macchina i processi restano in piedi?
Voi non ci crederete, ma non ho mai ricevuto risposta e non ha mandato neanche il resoconto del problema. Secondo voi, il
fatto che non abbia più risposto che significa? Lo prendo come "cretino non hai capito che scherzavo?", oppure lo devo
interpretare come: "esattamente. Dopo che ho riavviato la macchina i processi erano ancora in piedi".
Oddio, la cosa mi preoccupa non poco. Se fosse vero, se ritiene possibile che dopo il reboot di una macchina i processi
siano ancora in piedi, secondo voi, che tipo di analisi può aver condotto fino ad ora? I risultati che ci ha illustrato
cosa rappresentano? Forse non li avrà fatti lui.
Forse avrà chiesto aiuto a qualcuno e poi ha aggiunto delle....cose sue, in modo da dire che anche lui c'era.