Tuning 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ă:

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.