Oracle on Ivan Luminaria

Oracle su Linux: i parametri kernel che nessuno configura

Tue, 24 Feb 2026 08:03:00 +0100

Il cliente era una società di logistica con un Oracle 19c Enterprise Edition su Oracle Linux 8. Sessanta utenti concorrenti, un gestionale custom, circa 400 GB di dati. Il server era un Dell PowerEdge con 128 GB di RAM e 32 core.

Le lamentele erano vaghe ma persistenti: “Il sistema è lento.” “Le query del mattino ci mettono il doppio rispetto a due mesi fa.” “Ogni tanto si blocca tutto per qualche secondo.”

AWR, ASH e i 10 minuti che hanno salvato un go-live

Tue, 10 Feb 2026 08:03:00 +0100

Venerdì, ore 18:40. Ero già con il giubbotto addosso, pronto per uscire. Il telefono vibra. È il project manager.

“Ivan, abbiamo un problema. Il sistema è lentissimo. Domani mattina c’è il go-live.”

Non è la prima volta che ricevo una chiamata del genere. Ma il tono era diverso dal solito. Non era la lamentela generica sulla lentezza. Era panico.

Mi ricollego in VPN, apro una sessione sul database Oracle 19c del cliente. La prima cosa che faccio è un controllo rapido:

Utenti, ruoli e privilegi in Oracle: perché GRANT ALL non è mai la risposta

Tue, 27 Jan 2026 08:03:00 +0100

Mi è capitato più volte di entrare in un ambiente Oracle e trovare la stessa situazione: tutti gli utenti applicativi connessi come schema owner, con il ruolo DBA assegnato. Sviluppatori, applicazioni batch, tool di reportistica — tutti con gli stessi privilegi dell’utente che possiede le tabelle.

Quando chiedi perché, la risposta è sempre una variante di: “Così funziona tutto senza problemi di permessi.”

Certo. Funziona tutto. Fino al giorno in cui uno sviluppatore lancia un DROP TABLE sulla tabella sbagliata. O un batch di import fa un TRUNCATE su una tabella di produzione pensando di essere in ambiente di test. O qualcuno esegue un DELETE FROM clienti senza la clausola WHERE.

Oracle Partitioning: quando 2 miliardi di righe non entrano più in una query

Tue, 23 Dec 2025 08:03:00 +0100

Due miliardi di righe. Non è un numero che si raggiunge in un giorno. Ci vogliono anni di transazioni, di movimenti, di registrazioni quotidiane che si accumulano. E per tutto quel tempo il database funziona, le query rispondono, i report escono. Poi un giorno qualcuno apre un ticket: “il report mensile ci mette quattro ore.”

Quattro ore. Per un report che sei mesi prima ne impiegava venti minuti.

Non è un bug. Non è un problema di rete o di storage lento. È la fisica dei dati: quando una tabella cresce oltre una certa soglia, gli approcci che funzionavano smettono di funzionare. E se non hai progettato la struttura per gestire quella crescita, il database fa l’unica cosa che può fare: leggere tutto.

Da single instance a Data Guard: il giorno in cui il CEO ha capito il DR

Tue, 16 Dec 2025 08:03:00 +0100

Il cliente era una media azienda nel settore assicurativo. Trecento dipendenti, un gestionale interno che girava su Oracle 19c, un solo server fisico in sala macchine al piano terra della sede. Nessuna replica. Nessuno standby. Nessun piano di disaster recovery.

Per cinque anni aveva funzionato tutto. E quando le cose funzionano, nessuno vuole spendere soldi per proteggersi da problemi che non si sono mai visti.

Il giorno in cui si è fermato tutto #

Un mercoledì mattina di novembre, alle 8:47, il disco del gruppo dati principale ha avuto un guasto fisico. Non un errore logico, non una corruzione recuperabile. Un guasto hardware. Il controller RAID ha perso due dischi contemporaneamente — uno già degradato da settimane senza che nessuno se ne accorgesse, l’altro ceduto di colpo.