Un server MySQL cu discul la 95%, 180 GB de binary log acumulate în șase luni. De acolo pornește o călătorie prin binlog: ce conțin, de ce există, cum funcționează cu replicarea și point-in-time recovery, și mai ales cum le gestionezi fără să faci pagube.
O bază de date PostgreSQL de 200 GB cu tabele umflate la triplul dimensiunii reale. Autovacuum era activ, dar prost configurat. Cum diagnostichezi bloat-ul, citești pg_stat_user_tables și faci tuning fără să dezactivezi nimic.
A gestiona AI într-un proiect nu înseamnă a folosi ChatGPT. Înseamnă a guverna impactul inteligenței artificiale asupra arhitecturilor, proceselor și oamenilor. Reflecții din aproape treizeci de ani de sisteme mission-critical.
În Italia, a plăti un consultant IT la 90 de zile este practica standard. În restul Europei, este o anomalie. Comparație directă între regulile europene și realitatea italiană, cu cifre, directive și strategii concrete pentru freelanceri.
Din Appio Latino până în Prati în 50 de minute de trafic și 35€ parcare, sau în 18 minute cu o Brompton electrică. Alegerea care mi-a schimbat zilele — și care ar putea să le schimbe și pe ale tale.
Un client cu Oracle 19c pe Linux și performanță dezamăgitoare. Instalare implicită, fără tuning. Huge Pages, semafoare, I/O scheduler, THP și limite de securitate: tot ce lipsea — cu cifrele de dinainte și după.
O analiză concretă asupra avantajelor economice și strategice ale muncii la distanță în companiile de consultanță IT. Cu cifre reale, raccordo-ul de la Roma și o alergare în parc la ora 6 dimineața.
Un client cu o ierarhie pe trei niveluri — Top Group, Group, Client — unde nu toate ramurile sunt complete. Cum am echilibrat o ragged hierarchy cu self-parenting: cine nu are părinte devine propriul părinte.
Un director comercial întreabă câți clienți avea regiunea Nord în iunie trecut. DWH-ul nu poate răspunde pentru că fiecare actualizare suprascrie datele anterioare. Cum am implementat o SCD Tip 2 cu chei surogat și date de valabilitate pentru a reda business-ului memoria istorică.
O fact table construită pe totalul lunar al facturării părea perfectă. Apoi business-ul a cerut detalii pe produs, pe linie, pe client. Și data warehouse-ul a amuțit.
A gestiona AI într-un proiect nu înseamnă a folosi ChatGPT. Înseamnă a guverna impactul inteligenței artificiale asupra arhitecturilor, proceselor și oamenilor. Reflecții din aproape treizeci de ani de sisteme mission-critical.
În Italia, a plăti un consultant IT la 90 de zile este practica standard. În restul Europei, este o anomalie. Comparație directă între regulile europene și realitatea italiană, cu cifre, directive și strategii concrete pentru freelanceri.
Din Appio Latino până în Prati în 50 de minute de trafic și 35€ parcare, sau în 18 minute cu o Brompton electrică. Alegerea care mi-a schimbat zilele — și care ar putea să le schimbe și pe ale tale.
O analiză concretă asupra avantajelor economice și strategice ale muncii la distanță în companiile de consultanță IT. Cu cifre reale, raccordo-ul de la Roma și o alergare în parc la ora 6 dimineața.
Un caz real de management de proiect: cum am propus GitHub și inteligența artificială pentru a transforma un proiect software haotic într-un flux de lucru ordonat, măsurabil și mai rapid.
Un client cu Oracle 19c pe Linux și performanță dezamăgitoare. Instalare implicită, fără tuning. Huge Pages, semafoare, I/O scheduler, THP și limite de securitate: tot ce lipsea — cu cifrele de dinainte și după.
Vineri seara, în ajunul unui go-live. Performanța se prăbușește. Cu AWR și ASH am găsit un full table scan ascuns într-o procedură stocată în mai puțin de zece minute — iar lansarea în producție a mers înainte.
Un client unde toți utilizatorii aplicativi se conectau ca schema owner cu rolul DBA. Cum am restructurat modelul de securitate Oracle aplicând principiul privilegiului minim — cu SQL real, roluri personalizate și Unified Audit.
Un client cu o tabelă de tranzacții de 2 miliarde de rânduri și interogări de raportare care trecuseră de la secunde la ore. Cum am rezolvat cu partitioning Oracle — range, interval, partition pruning și indecși locali.
O bază de date Oracle în producție fără nicio redundanță. O defecțiune de disc care a oprit totul timp de șase ore. Și decizia CEO-ului de a investi într-o arhitectură Active Data Guard cu switchover automat.
O bază de date PostgreSQL de 200 GB cu tabele umflate la triplul dimensiunii reale. Autovacuum era activ, dar prost configurat. Cum diagnostichezi bloat-ul, citești pg_stat_user_tables și faci tuning fără să dezactivezi nimic.
PostgreSQL nu distinge între utilizatori și roluri: totul este un ROLE. Modelul mental corect, un caz real și un exemplu complet pentru a construi un utilizator read-only cu adevărat mentenabil.
Un caz real de performanță în PostgreSQL în care un LIKE '%valoare%' a generat un full scan și a degradat timpii de răspuns. Analiza planului de execuție și o strategie de indexare scalabilă.
Un caz real in care optimizatorul a ales un nested loop pe 2 milioane de randuri pentru ca statisticile erau vechi. Cum sa citesti un plan de executie, sa gasesti semnalele de alarma si sa intervii.
Un server MySQL cu discul la 95%, 180 GB de binary log acumulate în șase luni. De acolo pornește o călătorie prin binlog: ce conțin, de ce există, cum funcționează cu replicarea și point-in-time recovery, și mai ales cum le gestionezi fără să faci pagube.
Un client cu un MySQL standalone care cădea în fiecare lună, luând cu el întreaga aplicație. Soluția mea: un Galera Cluster cu 3 noduri și replicare sincronă. De la diagnostic la punerea în producție, cu toate fișierele de configurare și parametrii critici.
În MySQL și MariaDB identitatea unui utilizator depinde de host-ul de la care se conectează. Un caz real, modelul de autentificare explicat în profunzime și cele mai frecvente greșeli în gestionarea accesului.
O operațiune care trebuia să dureze cinci minute — extragerea unui CSV din MySQL — se transformă într-o investigație printre instanțe multiple pe același server, socket-uri Unix, porturi diferite și directiva secure-file-priv care blochează totul. De la conectarea la instanța corectă până la exportul din shell.
Filesystem la 92% pe un cluster MySQL Group Replication cu 3 noduri. Cauza? Binary logs acumulate pe volumul principal. De la alertă la migrarea pe un volum dedicat, nod cu nod, fără a pierde quorum-ul.