Oracle on Ivan Luminaria

Oracle pe Linux: parametrii kernel pe care nimeni nu-i configurează

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

Clientul era o companie de logistică cu Oracle 19c Enterprise Edition pe Oracle Linux 8. Șaizeci de utilizatori concurenți, o aplicație ERP personalizată, circa 400 GB de date. Serverul era un Dell PowerEdge cu 128 GB de RAM și 32 de core-uri.

Plângerile erau vagi dar persistente: “Sistemul e lent.” “Query-urile de dimineață durează dublu față de acum două luni.” “Din când în când se blochează totul câteva secunde.”

Când m-am conectat pe server, primul lucru pe care l-am verificat nu a fost baza de date. A fost sistemul de operare.

AWR, ASH și cele 10 minute care au salvat un go-live

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

Vineri, ora 18:40. Aveam deja geaca pe mine, gata de plecare. Telefonul vibrează. E project managerul.

“Ivan, avem o problemă. Sistemul merge foarte lent. Mâine dimineață e go-live-ul.”

Nu e prima dată când primesc un astfel de apel. Dar tonul era diferit. Nu era plângerea obișnuită despre lentoare. Era panică.

Mă reconectez prin VPN, deschid o sesiune pe baza de date Oracle 19c a clientului. Primul lucru pe care îl fac e o verificare rapidă:

Utilizatori, roluri și privilegii în Oracle: de ce GRANT ALL nu este niciodată răspunsul

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

Mi s-a întâmplat de mai multe ori: intru într-un mediu Oracle și găsesc aceeași situație. Toți utilizatorii aplicativi conectați ca schema owner, cu rolul DBA atribuit. Dezvoltatori, procese batch, instrumente de raportare — toți cu aceleași privilegii ca utilizatorul proprietar al tabelelor.

Când întrebi de ce, răspunsul este mereu o variantă a: „Așa funcționează totul fără probleme de permisiuni."

Sigur. Totul funcționează. Până în ziua în care un dezvoltator execută un DROP TABLE pe tabela greșită. Sau un batch de import face un TRUNCATE pe o tabelă de producție crezând că este în mediul de test. Sau cineva execută un DELETE FROM clienti fără clauza WHERE.

Oracle Partitioning: când 2 miliarde de rânduri nu mai încap într-o interogare

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

Două miliarde de rânduri. Nu este un număr la care ajungi într-o zi. Durează ani de tranzacții, mișcări, înregistrări zilnice care se acumulează. Și în tot acest timp baza de date funcționează, interogările răspund, rapoartele ies. Apoi într-o zi cineva deschide un ticket: „raportul lunar durează patru ore."

Patru ore. Pentru un raport care cu șase luni înainte dura douăzeci de minute.

Nu este un bug. Nu este o problemă de rețea sau de stocare lentă. Este fizica datelor: când o tabelă crește peste un anumit prag, abordările care funcționau nu mai funcționează. Și dacă nu ai proiectat structura să gestioneze acea creștere, baza de date face singurul lucru pe care îl poate face: citește totul.

De la single instance la Data Guard: ziua în care CEO-ul a înțeles DR-ul

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

Clientul era o companie de dimensiuni medii din sectorul asigurărilor. Trei sute de angajați, o aplicație de gestiune internă pe Oracle 19c, un singur server fizic în camera serverelor de la parter. Fără replică. Fără standby. Fără plan de disaster recovery.

Timp de cinci ani totul funcționase. Și când lucrurile merg, nimeni nu vrea să cheltuie bani protejându-se de probleme pe care nu le-a văzut niciodată.

Ziua în care s-a oprit totul #

Într-o dimineață de miercuri din noiembrie, la 8:47, discul grupului principal de date a suferit o defecțiune fizică. Nu o eroare logică, nu o corupție recuperabilă. O defecțiune hardware. Controlerul RAID a pierdut două discuri simultan — unul era degradat de săptămâni fără ca nimeni să observe, celălalt a cedat brusc.