Ivan Luminaria

Binary log în MySQL: ce sunt, cum le gestionezi și când le poți șterge

Tue, 31 Mar 2026 08:03:00 +0100

Mesajul pe canalul Slack al echipei de infrastructură era din acelea care te fac să ridici capul de la ecran: “Disc la 95% pe db-ul de producție. Cine poate să se uite?”

Serverul era un MySQL 8.0 pe Rocky Linux, un sistem de gestiune folosit de aproximativ o sută de utilizatori. Baza de date în sine ocupa circa 40 GB — nimic extraordinar. Dar în directorul de date se aflau 180 GB de binary log. Șase luni de binlog pe care nimeni nu se gândise să le gestioneze.

VACUUM și autovacuum: de ce PostgreSQL are nevoie ca cineva să facă curățenie

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

Acum câțiva ani mi s-a cerut să verific un PostgreSQL în producție care “se încetinește în fiecare săptămână”. Mereu același tipar: luni merge bine, vineri e dezastru. În weekend cineva repornește serviciul și se începe de la capăt.

Baza de date de aproximativ 200 GB. Tabelele principale ocupau aproape triplul spațiului efectiv al datelor. Query-uri care cădeau în sequential scan acolo unde nu ar fi trebuit. Timpii de răspuns creșteau zi de zi.

AI Manager și Project Management: când inteligența artificială intră în proiecte

Tue, 17 Mar 2026 08:03:00 +0100

Acum câteva luni, într-o întâlnire cu un client din sectorul bancar, CTO-ul a spus ceva ce mi-a rămas în minte.

„Avem nevoie de cineva care să gestioneze AI-ul. Nu cineva care îl folosește — cineva care îl guvernează."

Am dat din cap fără să vorbesc. Pentru că acea frază, în șapte secunde, descria un rol pe care piața îl caută fără să știe încă cum să-l numească.

🧩 Neînțelegerea fundamentală #

Există o confuzie răspândită, și o văd în fiecare proiect unde AI-ul intră în scenă.

Plăți la 60-90-120 de zile: normalitatea italiană care nu există în Europa

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

Prima dată când am lucrat cu un client internațional, mi s-a întâmplat ceva ciudat. M-au plătit în treizeci de zile.

Nu treizeci de zile de la sfârșitul lunii. Nu treizeci de zile de la data primirii facturii înregistrate și vizate de responsabilul administrativ. Treizeci de zile de la factură. Punct.

Am verificat extrasul de cont de două ori. Am crezut că este o greșeală.

Nu era o greșeală. Era normalitatea — doar că nu era normalitatea italiană.

Data Warehouse Architect

Tue, 10 Mar 2026 00:00:00 +0000

Descarca PDF | Profil LinkedIn

Profil Profesional #

Data Warehouse Architect si profesionist IT cu aproape 30 de ani de experienta in proiectarea, implementarea si gestionarea solutiilor DWH complexe si de inalta performanta in medii Oracle si PostgreSQL. Expert in metodologii de modelare multidimensionala a datelor (Kimball, Inmon) si in optimizarea proceselor ETL/ELT si a interogatiilor SQL pe seturi de date de la sute de milioane la miliarde de randuri. Capacitate demonstrata de a conduce proiecte DWH de la un capat la altul — de la analiza cerintelor pana la punerea in productie — asigurand integritatea, calitatea si disponibilitatea datelor pentru a sprijini deciziile de business. Leadership tehnic si mentalitate orientata catre rezolvarea problemelor in contexte internationale si full-remote.

Oracle DBA & Performance Tuning Expert

Tue, 10 Mar 2026 00:00:00 +0000

Descarca PDF | Profil LinkedIn

Profil Profesional #

Senior Oracle DBA si Performance Tuning Expert cu aproape 30 de ani de experienta specializata in administrarea, optimizarea si gestionarea bazelor de date Oracle complexe si critice, inclusiv medii Exadata, RAC si Oracle Cloud (OCI, Autonomous Database). Expertiza avansata in analiza performantei (AWR, ADDM, ASH), optimizarea interogatiilor SQL complexe, tuning-ul instantelor si rezolvarea problemelor de performanta. Cunostinte solide in practici legate de backup & recovery (RMAN), securitate (TDE), instalare, patching, migrari si gestionarea stocarii (ASM), performanta ramanand principala si cea mai aprofundata arie de expertiza, cruciala pentru integritatea, performanta si contributia la disponibilitatea ridicata a sistemelor Oracle in medii corporative exigente si internationale.

Oracle PL/SQL Developer

Tue, 10 Mar 2026 00:00:00 +0000

Descarca PDF | Profil LinkedIn

Profil Profesional #

Senior Oracle PL/SQL Developer cu aproape 30 de ani de experienta in proiectarea, dezvoltarea, testarea si optimizarea codului PL/SQL robust si eficient pentru aplicatii cu volume mari de date si sisteme Data Warehouse. Expertiza avansata in crearea de pachete, proceduri, functii, triggere si tipuri complexe, cu un accent constant pe performanta, mentenabilitate si calitatea codului. Expert in optimizarea interogarilor SQL complexe si gestionarea volumelor mari de date. Abilitate in transpunerea cerintelor de business in logica aplicativa performanta si scalabila in cadrul bazei de date Oracle. Parcurs consolidat si ca Oracle DBA si DWH Architect, oferind o viziune completa asupra ciclului de viata al datelor.

Project Manager

Tue, 10 Mar 2026 00:00:00 +0000

Descarca PDF | Profil LinkedIn

Profil Profesional #

Project Manager cu aproape 30 de ani de experienta in IT si un fundament tehnic solid in medii Data Warehouse si Oracle. Peste 10 proiecte livrate cu un istoric excelent de respectare a termenelor, gestionand echipe de 3-7 persoane in contexte multiculturale si remote, pe proiecte cu bugete in intervalul €100K-€500K. Competente concrete in planificare, managementul riscurilor, coordonarea resurselor si relatia cu stakeholderii — dezvoltate pe teren coordonand activitati de dezvoltare, release si mentenanta pentru clienti din sectoarele Bancar, Telco, Asigurari si Administratie Publica. Metodologii Agile (Scrum) aplicate in managementul zilnic al proiectelor, cu formare certificata. Fundament tehnic aprofundat (arhitectura DWH, Oracle DBA, PL/SQL, ETL/ELT) care permite comunicarea eficienta cu echipele de dezvoltare, evaluarea realista a fezabilitatii si identificarea timpurie a riscurilor tehnice.

Bicicletă vs Mașină la Roma: dimineața care mi-a deschis ochii

Tue, 03 Mar 2026 08:03:00 +0100

Luni dimineața. Alarma la 6:40. Duș, mic dejun rapid, cheile mașinii pe masă. Ies din casă la 7:15.

Locuiesc în zona Appio Latino. Biroul este pe Via Crescenzio, în Prati. Opt kilometri în linie dreaptă. Ar trebui să fie cincisprezece minute. La Roma, e altă poveste.

🚗 Dimineața cu mașina #

Via Appia Nuova e deja o parcare. Porta San Giovanni, o pâlnie. Lungotevere, o procesiune funebră cu claxoane.

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.

Smart working în consultanța IT: cifrele pe care nimeni nu vrea să le vadă

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

6:47 într-o marți obișnuită. Sunt în parcul de lângă casă, echipat pentru alergare. Aerul e proaspăt, soarele abia răsare. Am făcut deja patru kilometri. Mă simt viu.

La 7:00 sunt la duș. La 7:20 iau micul dejun în liniște. La 7:45 sunt la birou, odihnit, concentrat, gata de lucru.

La aceeași oră, un coleg al meu e încă blocat pe Pontina. Sau pe raccordo, între Casilina și Tuscolana. Are deja telefonul în mână — nu ca să lucreze, ci ca să trimită mesajul clasic: “Scuze, întârzii, a fost un accident.”

Despre mine

Fri, 20 Feb 2026 00:00:00 +0000

IVAN LUMINARIA

Oracle, PostgreSQL & MySQL Expert | DWH Architect | Project Manager

Profesionist IT cu aproximativ 30 de ani de experiență în proiectarea, implementarea și gestionarea soluțiilor de baze de date și Data Warehouse în medii Oracle, PostgreSQL și MySQL.

LinkedIn: ivanluminaria
Email: ivan (dot) luminaria (at) gmail (dot) com

Lucrez cu baze de date de aproximativ treizeci de ani.

Galera Cluster cu 3 noduri: cum am rezolvat o problemă de disponibilitate pe MySQL

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

Tichetul era laconic, cum se întâmplă adesea când problema e gravă: “Baza de date a căzut din nou. Aplicația e oprită. A treia oară în două luni.”

Clientul avea un MariaDB pe un singur server Linux — o aplicație de gestiune de afaceri folosită de aproximativ două sute de utilizatori interni, cu vârfuri de încărcare în timpul închiderilor contabile de sfârșit de lună. De fiecare dată când serverul avea o problemă — un disc care se încetinea, o actualizare de sistem care necesita restart, un proces care consuma toată memoria RAM — baza de date cădea și cu ea întreaga operativitate a companiei.

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

Roluri și utilizatori în PostgreSQL: de ce totul este (doar) un ROLE

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

Prima dată când am lucrat serios cu PostgreSQL veneam după ani de experiență cu alte baze de date. Căutam comanda CREATE USER. O găseam. Apoi vedeam CREATE ROLE. Apoi ALTER USER. Apoi ALTER ROLE.
Pentru câteva minute am gândit: „Bine, aici cineva se distrează încurcând lumea.”

În realitate, nu. PostgreSQL este mult mai coerent decât pare. Doar că este coerent în felul lui.

În PostgreSQL nu există utilizatori. Există roluri. #

Cheia este aceasta: în PostgreSQL totul este un ROLE.

Când haosul devine metodă: AI și GitHub pentru gestionarea unui proiect pe care nimeni nu voia să-l atingă

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

Mă sună un client. Voce tensionată, cuvinte măsurate.

“Ivan, avem o problemă. De fapt, avem problema.”

Cunosc tonul ăsta. E tonul celui care a încercat deja să rezolve lucrurile intern, a eșuat, și acum caută pe cineva care să-i spună adevărul fără ocolișuri.

Problema este un software de gestiune — nu un site web, nu o aplicație — un sistem critic pe care rulează procese de business importante. Are câțiva ani. A crescut repede, cum se întâmplă întotdeauna când business-ul aleargă mai repede decât arhitectura. Și acum s-a acumulat totul: bug-uri deschise pe care nimeni nu le închide, cereri de evoluție pe care nimeni nu le planifică, dezvoltatori care lucrează pe versiuni diferite ale codului fără să știe ce face celălalt.

Standup meeting: de ce funcționează doar dacă durează 15 minute

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

Prima zi de luni a proiectului. Echipă nouă, metodologie nouă, speranțe noi. PM-ul propune standup-ul zilnic. Toți dau din cap. “Cincisprezece minute, în picioare, trei întrebări. Simplu.”

Prima săptămână funcționează. La 9:15 începe, la 9:28 ești deja la birou. Fiecare spune ce are de spus în două minute, se semnalează blocajele, se salută. Eficiență pură.

A doua săptămână cineva ridică mâna în mijlocul rundei: “Pot să explic un moment problema pe care o am cu integrarea?” Cinci minute de discuție tehnică între două persoane. Ceilalți șase stau și ascultă ceva ce nu-i privește.

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.

Ierarhii dezechilibrate: când clientul nu are părinte și grupul nu are bunic

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

Trei niveluri. Top Group, Group, Client. Pare o structură banală — tipul de ierarhie pe care o desenezi pe o tablă în cinci minute și pe care orice instrument de BI ar trebui să o gestioneze fără probleme.

Apoi descoperi că nu toți clienții aparțin unui grup. Și că nu toate grupurile aparțin unui top group. Și că rapoartele de agregare pe care business-ul le solicită — cifra de afaceri per top group, număr de clienți per grup, drill-down de la vârf la frunză — produc rezultate greșite sau incomplete pentru că ierarhia are goluri.

Tehnica Da-Și: cum am evitat o discuție care era pe punctul de a exploda

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

Era o joi după-amiază, una dintre acele ședințe care pe hârtie trebuia să dureze o oră. Eram șapte, conectați într-un call. Ordinea de zi era simplă: să decidem strategia de migrare a unei baze de date Oracle din on-premise în cloud.

Simplă, desigur. Pe hârtie.

După douăzeci de minute, ședința se transformase într-un duel.

🔥 Scânteia #

De o parte era responsabilul de infrastructură. Om cu experiență, douăzeci de ani de datacentere în spate. Poziția lui era de granit: migrare lift-and-shift, zero modificări la arhitectură, mutăm totul așa cum este.

Utilizatori MySQL: de ce 'mario' și 'mario'@'localhost' nu sunt aceeași persoană

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

Acum câteva săptămâni un client mă sună. Ton pragmatic, cerere aparent banală:

„Trebuie să creez un utilizator pe MySQL pentru o aplicație care trebuie să acceseze o bază de date. Te poți ocupa?"

Sigur. CREATE USER, `GRANT` , următorul.

Doar că apoi adaugă: „Aplicația rulează pe două servere diferite. Și uneori ne vom conecta și local pentru mentenanță."

Când un LIKE '%valoare%' încetinește totul: un caz real de optimizare PostgreSQL

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

Cu câteva săptămâni în urmă, un client m-a contactat cu o problemă foarte comună:

“Căutarea din consola administrativă este lentă. Uneori durează câteva secunde. Am redus deja JOIN-urile, dar problema nu a dispărut.”

Mediu: PostgreSQL în cloud managed.
Tabela principală: payment_report (~6 milioane de rânduri, 3 GB).
Coloana căutată: reference_code.

Query problematic:

SELECT *
FROM reporting.payment_report r
JOIN reporting.payment_cart c ON c.id = r.cart_id
WHERE c.service_id = 1001
 AND r.reference_code LIKE '%ABC123%'
ORDER BY c.created_at DESC
LIMIT 100;

🧠 Prima observație: JOIN-urile nu erau problema #

Am comparat:

4 milioane de euro, două multinaționale, zero software: povestea reală a unui eșec anunțat

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

Povestea pe care urmează să o spun este reală. Nu voi da nume — nu din diplomație, ci pentru că numele nu contează. Ceea ce contează este să înțelegem mecanismul. Pentru că acest mecanism se repetă, identic, în zeci de companii. Și costă milioane.

🏢 Clientul: un grup de asigurări cu o ambiție legitimă #

O companie solidă din sectorul asigurărilor. Operațiuni în Italia, Franța, țări din Europa de Nord, Spania. Mii de angajați, milioane de polițe gestionate, o afacere în creștere.

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.

SCD Tip 2: istoria pe care business-ul nu știa că o vrea

Tue, 11 Nov 2025 08:03:00 +0100

Directorul comercial apare la ședința de luni dimineața cu o întrebare simplă: “Câți clienți aveam în regiunea Nord în iunie trecut?”

Răspunsul DWH-ului: liniște.

Nu pentru că sistemul era căzut, sau pentru că lipsea tabela. Datele erau acolo, tehnic vorbind. Dar erau greșite. DWH-ul returna clienții care astăzi sunt în regiunea Nord — nu pe cei care erau acolo în iunie. Pentru că în fiecare noapte, procesul de încărcare suprascria datele master ale clienților cu valorile curente, ștergând orice urmă a ceea ce fusese înainte.

MySQL multi-instanță: un ticket, un CSV și zidul secure-file-priv

Tue, 04 Nov 2025 08:03:00 +0100

Ticket-ul spunea: „Avem nevoie de un export CSV din tabelul ordini al aplicației de gestiune. Până la ora 14."

Era 11 dimineața. Trei ore pentru un SELECT cu INTO OUTFILE — treabă de cinci minute, mă gândeam. Apoi am deschis VPN-ul, m-am conectat la server și am înțeles că cinci minute n-o să fie de ajuns.

Serverul era o mașină CentOS 7 cu patru instanțe MySQL. Patru. Pe același host, cu patru servicii systemd diferite, patru porturi diferite, patru socket-uri Unix diferite, patru directoare de date diferite. Un setup pe care cineva îl pusese în picioare cu ani în urmă — probabil ca să economisească un al doilea server — și pe care de atunci nimeni nu-l mai atinsese și nici nu-l documentase.

EXPLAIN ANALYZE nu e suficient: cum sa citesti cu adevarat un plan de executie PostgreSQL

Tue, 28 Oct 2025 08:03:00 +0100

Zilele trecute un coleg imi trimite o captura de ecran pe Teams. Un query care ruleaza pe o tabela de 2 milioane de randuri, 45 de secunde timp de executie. Imi scrie:

“Am facut EXPLAIN ANALYZE, dar nu inteleg ce e in neregula. Planul pare corect.”

Spoiler: planul nu era deloc corect. Optimizatorul alesese un nested loop join unde era nevoie de un hash join , iar motivul era banal — statistici neactualizate. Dar ca sa ajung acolo a trebuit sa citesc planul rand cu rand, si atunci mi-am dat seama ca majoritatea DBA-ilor pe care ii cunosc folosesc EXPLAIN ANALYZE ca pe un oracol binar: daca timpul e mare, query-ul e lent. Sfarsitul analizei.

Granularitate greșită: când fact table nu răspunde la întrebările potrivite

Tue, 21 Oct 2025 08:03:00 +0100

Ședința începuse bine. Directorul comercial al unei companii de distribuție industrială — vreo șaizeci de milioane cifră de afaceri, trei mii de clienți activi, catalog cu douăsprezece mii de referințe — deschisese prezentarea noului data warehouse cu un zâmbet. Cifrele se potriveau, dashboard-urile arătau bine, totalurile lunare pe agent și pe zonă băteau cu contabilitatea.

Apoi cineva a pus întrebarea greșită. Sau mai bine zis, pe cea corectă.

“Pot să văd cât a cumpărat clientul Bianchi în luna martie, linie cu linie, produs cu produs?”

Disc plin pe un cluster MySQL: binary logs, Group Replication și o migrare care nu acceptă erori

Tue, 14 Oct 2025 08:03:00 +0100

Alerta a venit într-o dimineață de luni, între trei ședințe și o cafea încă fierbinte. “Filesystem /mysql la 85% pe nodul primar.” Pe un alt nod era la 66%, pe al treilea la 25%. Într-un cluster, când cifrele nu se potrivesc între noduri, întotdeauna e ceva dedesubt.

Prima întrebare care îți vine în minte este “cât spațiu mai trebuie?”. Dar e întrebarea greșită. Cea corectă este: “de ce se umple?”

Additive Measure

Mon, 01 Jan 0001 00:00:00 +0000

O additive measure (măsură aditivă) este o valoare numerică într-o fact table care poate fi sumată legitim de-a lungul oricărei dimensiuni: pe client, pe produs, pe perioadă, pe zonă.

Cum funcționează #

Măsurile din fact table se clasifică în trei categorii:

Aditive: pot fi sumate de-a lungul tuturor dimensiunilor (ex. sumă vânzare, cantitate, cost). Cele mai comune și cele mai utile
Semi-aditive: pot fi sumate de-a lungul unor dimensiuni dar nu de-a lungul timpului (ex. sold al unui cont: sumabil pe sucursală, nu pe lună)
Non-aditive: nu pot fi sumate deloc (ex. procente, rapoarte, medii precalculate)

La ce servește #

Măsurile aditive sunt inima fiecărei fact table deoarece permit agregările pe care business-ul le cere: totaluri pe perioadă, pe regiune, pe produs. Regula cheie: stochează întotdeauna valorile atomice (detaliul), niciodată agregatele. Dintr-o sumă pe linie de factură poți obține totalul lunar; din totalul lunar nu poți reconstitui liniile individuale.

AI Manager

Mon, 01 Jan 0001 00:00:00 +0000

AI Manager este rolul profesional care guvernează introducerea și utilizarea inteligenței artificiale într-un proiect sau organizație. Nu este cel care folosește AI-ul — este cel care decide unde, cum și cu ce precauții să-l integreze în arhitecturile existente.

Cum funcționează #

AI Managerul răspunde la întrebări la care niciun model nu poate răspunde: unde AI-ul generează valoare reală și unde generează doar entuziasm? Cât costă menținerea lui, nu doar implementarea? Ce se întâmplă când modelul greșește? Cum se integrează cu arhitecturile mission-critical fără a le compromite stabilitatea?

ANALYZE

Mon, 01 Jan 0001 00:00:00 +0000

ANALYZE este comanda PostgreSQL care colecteaza statistici despre distributia datelor in tabele si le stocheaza in catalogul pg_statistic (citibil prin vizualizarea pg_stats). Optimizatorul foloseste aceste statistici pentru a estima cardinalitatea — cate randuri va returna fiecare operatie — si a alege cel mai eficient plan de executie.

Ce colecteaza #

Statisticile colectate de ANALYZE includ:

Most common values: valorile cele mai frecvente pentru fiecare coloana si procentul lor
Histograme de distributie: cum sunt distribuite valorile ramase
Numarul de valori distincte: cate valori unice are fiecare coloana
Procentul de NULL: cate randuri au valoarea NULL pentru fiecare coloana

Calitatea acestor statistici depinde de numarul de esantioane colectate, controlat de parametrul default_statistics_target.

Anonymous User

Mon, 01 Jan 0001 00:00:00 +0000

Anonymous User (utilizatorul anonim) este un cont MySQL/MariaDB cu username gol (''@'localhost') care este creat automat în timpul instalării. Nu are nume și adesea nu are parolă.

Cum funcționează #

Când un utilizator se conectează, MySQL caută potrivirea cea mai specifică în tabelul mysql.user. Utilizatorul anonim ''@'localhost' este mai specific decât 'mario'@'%' pentru o conexiune de pe localhost, deoarece 'localhost' bate '%' în ierarhia specificității. În consecință, Mario care se conectează local este autentificat ca utilizator anonim și pierde toate privilegiile sale.

ASH

Mon, 01 Jan 0001 00:00:00 +0000

ASH (Active Session History) este o componenta a Oracle Database care esantioneaza starea fiecarei sesiuni active o data pe secunda si stocheaza datele intr-un buffer circular in memorie (view-ul V$ACTIVE_SESSION_HISTORY).

Cum functioneaza #

In fiecare secunda Oracle inregistreaza pentru fiecare sesiune activa:

SQL-ul in executie (SQL_ID)
Wait event-ul curent
Programul si modulul apelant
Planul de executie utilizat (SQL_PLAN_HASH_VALUE)

Datele mai vechi sunt descarcate automat in tabelele AWR (DBA_HIST_ACTIVE_SESS_HISTORY) si pastrate pentru perioada configurata.

Authentication Plugin

Mon, 01 Jan 0001 00:00:00 +0000

Un Authentication Plugin este modulul pe care MySQL sau MariaDB îl folosește pentru a verifica credențialele unui utilizator la momentul conexiunii. Fiecare utilizator din sistem este asociat cu un plugin specific care determină cum parola este hashată, transmisă și verificată.

Cum funcționează #

Plugin-urile principale sunt: mysql_native_password (implicit în MySQL 5.7 și MariaDB), care folosește un hash SHA1 dublu; caching_sha2_password (implicit în MySQL 8.0+), care folosește SHA-256 cu caching pentru îmbunătățirea securității și performanței. Când un client se conectează, trebuie să suporte plugin-ul utilizatorului la care încearcă să se autentifice.

Autovacuum

Mon, 01 Jan 0001 00:00:00 +0000

Autovacuum este un daemon PostgreSQL care rulează automat VACUUM și ANALYZE pe tabele când numărul de dead tuples depășește un prag calculat ca: threshold + scale_factor × n_live_tup. Cu valorile implicite (threshold=50, scale_factor=0.2), pe o tabelă cu 10 milioane de rânduri se activează după 2 milioane de dead tuples.

Cum funcționează #

Daemon-ul verifică periodic pg_stat_user_tables și lansează un worker pentru fiecare tabelă care depășește pragul. Numărul maxim de workeri simultani este controlat de autovacuum_max_workers (implicit 3). Parametrul autovacuum_vacuum_cost_delay controlează cât se autofrânează vacuum-ul pentru a nu supraîncărca I/O-ul.

AWR

Mon, 01 Jan 0001 00:00:00 +0000

AWR (Automatic Workload Repository) este o componenta integrata in Oracle Database care colecteaza automat statistici de performanta ale sistemului la intervale regulate (implicit la fiecare 60 de minute) si le pastreaza pentru o perioada configurabila.

Cum functioneaza #

AWR captureaza snapshot-uri periodice care includ:

Statistici ale sesiunilor si wait events
Metrici SQL (top SQL dupa timp de executie, I/O, CPU)
Statistici ale structurilor de memorie (SGA, PGA)
Statistici I/O per datafile si tablespace

La ce serveste #

Raportul AWR este instrumentul principal pentru diagnosticarea problemelor de performanta in Oracle. Comparand doua snapshot-uri se pot identifica:

B-Tree

Mon, 01 Jan 0001 00:00:00 +0000

B-Tree (Balanced Tree) este cea mai comună structură de date pentru indexuri în bazele de date relaționale și este tipul implicit de index în PostgreSQL, MySQL și Oracle. Menține datele sortate într-o structură de arbore echilibrat care garantează timpi de căutare logaritmici.

Cum funcționează #

Un B-Tree organizează cheile în noduri sortate, cu fiecare nod conținând pointeri către noduri copil. Căutarea pornește de la rădăcină și coboară către frunze, înjumătățind spațiul de căutare la fiecare nivel. Pentru o tabelă cu 6 milioane de rânduri, un B-Tree necesită tipic 3-4 nivele de adâncime, adică 3-4 citiri de pagină pentru a găsi o valoare.

Bicicletă Pliabilă

Mon, 01 Jan 0001 00:00:00 +0000

O Bicicletă Pliabilă este o bicicletă proiectată să se plieze în dimensiuni compacte (de obicei 60×55×25 cm) în câteva secunde, devenind transportabilă ca un bagaj. Brompton este cel mai cunoscut model, cu mecanism de pliere în 10-20 secunde.

Cum funcționează #

Un sistem de balamale și eliberări rapide permite plierea cadrului, ghidonului și pedalelor într-un pachet compact. Odată pliată, merge la birou sub birou, în metrou sau în portbagaj. În versiunea electrică, combină avantajele pedalării asistate cu portabilitatea totală.

Binary log

Mon, 01 Jan 0001 00:00:00 +0000

Binary log-ul (sau binlog) este un registru secvențial în format binar în care MySQL scrie toate evenimentele care modifică datele: INSERT, UPDATE, DELETE și operațiuni DDL. Fișierele sunt numerotate progresiv (mysql-bin.000001, mysql-bin.000002, etc.) și gestionate printr-un fișier index.

Cum funcționează #

De la MySQL 8.0, binary log-ul este activat implicit prin parametrul log_bin. MySQL creează un nou fișier binlog când serverul pornește, când fișierul curent atinge max_binlog_size, sau când se execută FLUSH BINARY LOGS. Suportă trei formate de înregistrare: STATEMENT (înregistrează instrucțiunile SQL), ROW (înregistrează modificările la nivel de rând) și MIXED (alegere automată).

Bloat

Mon, 01 Jan 0001 00:00:00 +0000

Bloat este acumularea de spațiu mort în cadrul unei tabele sau index PostgreSQL, cauzată de dead tuples care nu au fost încă eliminate de VACUUM. O tabelă cu 50% bloat ocupă de două ori spațiul necesar și forțează scanările secvențiale să citească de două ori mai multe pagini.

Cum funcționează #

Bloat-ul se măsoară comparând dimensiunea efectivă a tabelei cu dimensiunea așteptată bazată pe rândurile vii. Extensia pgstattuple oferă câmpul dead_tuple_percent. Un bloat peste 20-30% este un semnal de alarmă; peste 50% este o urgență.

Branch

Mon, 01 Jan 0001 00:00:00 +0000

Un Branch (ramură) este o linie de dezvoltare independentă într-un repository Git. Fiecare branch conține o copie a codului pe care se poate lucra fără a afecta branch-ul principal (main) sau munca altor dezvoltatori.

Cum funcționează #

Când un dezvoltator creează un branch (ex. fix/issue-234-eroare-calcul), Git creează un pointer la versiunea curentă a codului. Din acel moment, modificările făcute pe branch rămân izolate. La finalul lucrului, modificările se propun echipei prin Pull Request și, după aprobare, se unesc (merge) în branch-ul principal.

Brompton

Mon, 01 Jan 0001 00:00:00 +0000

Brompton este o bicicletă pliabilă fabricată la Londra din 1975, considerată referința mondială în categoria sa. Se pliază în 10-20 secunde atingând dimensiuni de aproximativ 58×56×27 cm — suficient de compactă pentru a încăpea sub un birou sau în portbagajul unei mașini mici.

Cum funcționează #

Mecanismul brevetat permite plierea bicicletei în trei mișcări: cadru, ghidon și șa. În versiunea electrică (Brompton Electric), un motor în butucul frontal oferă pedalare asistată până la 25 km/h cu o autonomie de 40-70 km. Bateria este detașabilă și se încarcă în 4 ore.

BYOL

Mon, 01 Jan 0001 00:00:00 +0000

BYOL (Bring Your Own License) este un program Oracle care permite organizatiilor sa transfere licentele software achizitionate pentru infrastructura on-premises catre Oracle Cloud Infrastructure (OCI), fara a fi nevoie sa achizitioneze licente cloud noi.

Cum functioneaza #

Cand o organizatie detine deja licente Oracle — de obicei Enterprise Edition cu optiuni precum RAC, Data Guard sau Partitioning — le poate “lua cu sine” in migrarea catre OCI. Contractul de suport (Software Update License & Support) se mentine, iar licentele sunt asociate resurselor cloud in locul serverelor fizice.

Carbon Footprint

Mon, 01 Jan 0001 00:00:00 +0000

Carbon Footprint (amprenta de carbon) este cantitatea totală de gaze cu efect de seră — în principal CO₂ — emise direct sau indirect de o activitate, produs sau individ, exprimată în tone de CO₂ echivalent.

Cum funcționează #

Pentru navetismul urban, calculul este direct: o mașină blocată în traficul din Roma produce în medie 120-150 g de CO₂ pe kilometru. În trafic congestionat chiar mai mult, pentru că motorul funcționează în gol consumând fără a se deplasa. O bicicletă produce zero emisii directe.

CDC

Mon, 01 Jan 0001 00:00:00 +0000

CDC (Change Data Capture) este o tehnică pentru interceptarea modificărilor de date (INSERT, UPDATE, DELETE) în momentul în care au loc și propagarea lor către alte sisteme în timp real sau aproape real. Spre deosebire de abordările batch tradiționale (ETL periodic), CDC captează modificările în mod continuu și incremental.

Cum funcționează #

Cea mai răspândită abordare este log-based CDC: o componentă externă citește log-urile de tranzacții ale bazei de date (binary log în MySQL, WAL în PostgreSQL, redo log în Oracle) și convertește evenimentele într-un flux de date consumabil de alte sisteme. Instrumente precum Debezium, Maxwell și Canal implementează această abordare pentru MySQL citind direct binary log-urile.

Cheie surogat

Mon, 01 Jan 0001 00:00:00 +0000

Cheia surogat (surrogate key) este un identificator numeric secvențial generat intern de data warehouse, fără nicio semnificație de business. Este distinctă de cheia naturală — cea care vine din sistemul sursă (ex. codul clientului, numărul de angajat).

De ce este necesară #

În SCD Tip 2, același client poate avea mai multe linii în tabela dimensională — câte una pentru fiecare versiune istorică. Cheia naturală (client_id) nu mai este unică, deci este nevoie de un identificator care să distingă fiecare versiune individuală: cheia surogat (client_key).

Churn

Mon, 01 Jan 0001 00:00:00 +0000

Churn-ul unei tabele este măsura a cât de mult se modifică datele sale după inserare. O tabelă cu churn ridicat suportă frecvente UPDATE-uri și DELETE-uri; o tabelă cu churn scăzut este predominant append-only (doar INSERT).

Cum funcționează #

În PostgreSQL, fiecare UPDATE creează o versiune nouă a rândului (datorită modelului MVCC) iar versiunea veche devine un dead tuple. DELETE-urile creează de asemenea dead tuples. Cu cât churn-ul este mai mare, cu atât mai multă muncă trebuie să facă VACUUM și indexurile pentru a menține performanța. Un index GIN pe o tabelă cu churn ridicat poate degrada semnificativ performanța la scriere.

COALESCE

Mon, 01 Jan 0001 00:00:00 +0000

COALESCE este o funcție SQL standard care acceptă o listă de expresii și returnează prima care nu este NULL. Dacă toate expresiile sunt NULL, returnează NULL.

Sintaxă #

COALESCE(expresie1, expresie2, expresie3, ...)

Echivalent cu un lanț de CASE WHEN:

CASE WHEN expresie1 IS NOT NULL THEN expresie1
 WHEN expresie2 IS NOT NULL THEN expresie2
 WHEN expresie3 IS NOT NULL THEN expresie3
 ELSE NULL END

Utilizare în ierarhii #

În contextul ragged hierarchies, COALESCE este adesea folosită pentru a completa nivelurile lipsă:

Code Review

Mon, 01 Jan 0001 00:00:00 +0000

Code Review este practica prin care un coleg examinează codul scris de un alt dezvoltator înainte ca acesta să fie incorporat în branch-ul principal. Pe GitHub are loc în interiorul Pull Request-urilor.

Cum funcționează #

Dezvoltatorul deschide un Pull Request cu modificările sale. Un reviewer atribuit examinează diff-ul codului, lasă comentarii, sugerează îmbunătățiri și în final aprobă sau cere modificări. Procesul este asincron: nu sunt necesare ședințe, review-ul are loc pe instrument. Doar după aprobare codul se fuzionează în branch-ul principal.

Compliance

Mon, 01 Jan 0001 00:00:00 +0000

Compliance (conformitate normativă) este aderarea unei organizații la legile, reglementările și standardele de sector aplicabile activității sale. În contextul AI, include GDPR, reglementări bancare (SOX, PCI-DSS), reglementări sanitare și politici interne privind utilizarea datelor.

Cum funcționează #

Conformitatea se verifică prin audituri, controale documentare și monitorizare continuă. Pentru proiectele AI, necesită trasabilitatea datelor folosite pentru training, documentarea deciziilor automatizate și capacitatea de a explica cum a ajuns modelul la un anumit output (explainability).

CTAS

Mon, 01 Jan 0001 00:00:00 +0000

CTAS (Create Table As Select) este o comandă SQL Oracle care creează o tabelă nouă și o populează într-o singură operație cu rezultatele unui SELECT. Este tehnica standard pentru migrarea datelor de la o structură la alta pe tabele de dimensiuni mari.

Cum funcționează #

Comanda combină DDL și DML: creează tabela cu structura derivată din SELECT și inserează datele într-un singur pas. Cu hint-ul PARALLEL și modul NOLOGGING, copierea a sute de GB se poate completa în câteva ore. După copiere, tabela originală se redenumește, cea nouă îi ia locul, iar downtime-ul se limitează la cele câteva secunde ale redenumirii.

Cutover

Mon, 01 Jan 0001 00:00:00 +0000

Cutover-ul este momentul in care un sistem de productie este mutat de pe infrastructura veche pe cea noua. Este faza cea mai vizibila a unei migrari — cea pe care toata lumea si-o aminteste, in bine sau in rau.

Anatomia unui cutover #

Un cutover bine planificat urmeaza un runbook detaliat cu pasi numerotati, timpi estimati, criterii de succes si proceduri de rollback pentru fiecare pas. Componentele tipice:

Daily Standup

Mon, 01 Jan 0001 00:00:00 +0000

Daily Standup este o ședință zilnică scurtă (maximum 15 minute) în care fiecare membru al echipei răspunde la trei întrebări: ce am făcut ieri, ce voi face azi, mă blochează ceva. Scopul este sincronizarea echipei, nu rezolvarea problemelor.

Cum funcționează #

Fiecare persoană are aproximativ două minute pentru actualizarea sa. Problemele sunt semnalate dar nu discutate: rezolvarea are loc după, între persoanele implicate. Constrângerea temporală este ceea ce face standup-ul eficient — fără ea, degenerează într-o ședință de status de 45 de minute.

Data Governance

Mon, 01 Jan 0001 00:00:00 +0000

Data Governance este setul de politici, procese, roluri și standarde pe care o organizație le adoptă pentru a garanta că datele sale sunt corecte, sigure, conforme cu reglementările și utilizate în mod coerent.

Cum funcționează #

Definește cine este responsabil de date (data owner, data steward), ce reguli de calitate se aplică, cum se clasifică datele după sensibilitate și cum se trasează proveniența lor (data lineage). Într-un context AI, include și verificarea provenienței și calității datelor folosite pentru training-ul modelelor.

Data Guard

Mon, 01 Jan 0001 00:00:00 +0000

Data Guard este tehnologia Oracle care mentine una sau mai multe copii sincronizate (standby) ale unei baze de date de productie (primar). Standby-ul primeste si aplica continuu redo log-urile generate de primar, ramanand aliniat in timp real sau aproape.

Cum functioneaza #

Primarul genereaza redo log-uri cu fiecare tranzactie. Aceste log-uri sunt transmise standby-ului prin retea, unde sunt aplicate in doua moduri posibile:

Data Warehouse

Mon, 01 Jan 0001 00:00:00 +0000

Un Data Warehouse (DWH) este un sistem de stocare a datelor proiectat specific pentru analiză, raportare și suport al deciziilor de afaceri. Spre deosebire de bazele de date operaționale (OLTP), un DWH colectează date din surse multiple, le transformă și le organizează în structuri optimizate pentru interogări analitice.

Cum funcționează #

Datele sunt extrase din sistemele sursă (aplicații de gestiune, CRM, ERP), transformate prin procese ETL care le curăță, normalizează și îmbogățesc, și în final încărcate în DWH. Modelul de date tipic este star schema: o tabelă de fapte centrală cu măsurile numerice conectată la tabele dimensionale care descriu contextul (timp, client, produs, geografie).

Dead Tuple

Mon, 01 Jan 0001 00:00:00 +0000

Un Dead Tuple este un rând într-o tabelă PostgreSQL care a fost actualizat (UPDATE) sau șters (DELETE) dar nu a fost încă eliminat fizic. Rămâne în paginile de date, ocupând spațiu pe disc și încetinind scanările.

Cum funcționează #

Când PostgreSQL execută un UPDATE, nu suprascrie rândul original: creează o versiune nouă și o marchează pe cea veche ca “moartă.” Rândul vechi rămâne fizic în pagina de date până când VACUUM îl curăță. Dead tuple-urile sunt prețul modelului MVCC — necesare pentru a garanta izolarea tranzacțională.

DEFAULT PRIVILEGES

Mon, 01 Jan 0001 00:00:00 +0000

DEFAULT PRIVILEGES este un mecanism PostgreSQL care permite definirea în avans a privilegiilor ce vor fi atribuite automat tuturor obiectelor viitoare create într-o schemă. Se configurează cu comanda ALTER DEFAULT PRIVILEGES.

Cum funcționează #

Comanda ALTER DEFAULT PRIVILEGES IN SCHEMA schema1 GRANT SELECT ON TABLES TO srv_monitorizare face ca fiecare tabelă nouă creată în schema1 să fie automat citibilă de srv_monitorizare. Fără această configurare, tabelele viitoare ar necesita un GRANT manual de fiecare dată.

default_statistics_target

Mon, 01 Jan 0001 00:00:00 +0000

default_statistics_target este parametrul PostgreSQL care defineste numarul de esantioane colectate de comanda ANALYZE pentru a construi statisticile fiecarei coloane. Valoarea implicita este 100.

Cum functioneaza #

PostgreSQL esantioneaza un anumit numar de valori pentru fiecare coloana si le foloseste pentru a construi doua structuri:

Most common values (MCV): lista valorilor celor mai frecvente, cu frecventele respective
Histograma: distributia valorilor ramase, impartita in bucket-uri de populatie egala

Parametrul default_statistics_target determina cate elemente vor avea aceste structuri. Cu valoarea implicita de 100, histograma va avea 100 de bucket-uri si lista MCV va contine pana la 100 de valori.

Directiva 2011/7/UE

Mon, 01 Jan 0001 00:00:00 +0000

Directiva 2011/7/UE este reglementarea europeană privind întârzierile la plată în tranzacțiile comerciale. Stabilește reguli clare: termen standard de 30 de zile, maxim 60 între întreprinderi (cu acord explicit), 30 pentru administrația publică, și dobânzi de întârziere automate la rata BCE + 8%.

Cum funcționează #

Directiva a fost transpusă în dreptul italian prin D.Lgs. 231/2002 (modificat în 2012). Pe hârtie regulile există: 30 de zile standard, dobânzi automate, compensație forfetară de 40€ per factură plătită cu întârziere. În practica italiană e ca și cum n-ar exista — DSO-ul mediu italian este de 80 de zile, mult peste maximul de 60.

Dobânzi de Întârziere

Mon, 01 Jan 0001 00:00:00 +0000

Dobânzile de Întârziere sunt dobânzile care se acumulează automat pe fiecare factură plătită cu întârziere față de termenul contractual. Conform D.Lgs. 231/2002 italian (transpunerea Directivei UE 2011/7/UE), rata este egală cu rata BCE + 8 puncte procentuale, fără necesitatea unei somații formale.

Cum funcționează #

Din ziua următoare scadenței facturii, dobânzile se acumulează automat. Creditorul are dreptul și la o compensație forfetară de 40€ pentru fiecare factură plătită cu întârziere, pentru cheltuielile de recuperare. Nu este necesară trimiterea unei somații — dreptul se naște din lege.

Drill-down

Mon, 01 Jan 0001 00:00:00 +0000

Drill-down-ul este operațiunea de navigare în rapoarte care permite trecerea de la un nivel agregat la un nivel de detaliu mai mare, coborând de-a lungul unei ierarhii.

Cum funcționează #

Într-o ierarhie Top Group → Group → Client:

Se pornește de la nivelul cel mai înalt: cifra de afaceri totală pe Top Group
Se face clic pe un Top Group pentru a vedea Group-urile sale (drill-down de primul nivel)
Se face clic pe un Group pentru a vedea Clienții individuali (drill-down de al doilea nivel)

Operațiunea inversă — revenirea de la detaliu la agregat — se numește drill-up (sau roll-up).

DSO

Mon, 01 Jan 0001 00:00:00 +0000

DSO (Days Sales Outstanding) este metrica care măsoară numărul mediu de zile pe care o companie le necesită pentru a-și încasa creanțele după emiterea facturii. Este indicatorul principal al vitezei de plată într-o piață.

Cum funcționează #

Se calculează ca: (Creanțe comerciale / Venituri) × Zile din perioadă. Un DSO de 30 înseamnă că în medie clienții plătesc într-o lună. În Italia DSO-ul mediu este de 80 de zile conform European Payment Report — aproape de trei ori media nordului Europei (24-27 zile).

ETL

Mon, 01 Jan 0001 00:00:00 +0000

ETL (Extract, Transform, Load) este procesul fundamental prin care datele sunt mutate din sistemele sursa (baze de date operationale, fisiere, API-uri) in data warehouse.

Cele trei faze #

Extract: extragerea datelor din sistemele sursa. Poate fi completa (full load) sau incrementala (doar date noi sau modificate)
Transform: curatarea, validarea, standardizarea si imbogatirea datelor. Aici se aplica regulile de business, lookup-urile pe dimensiuni, calculele derivate
Load: incarcarea datelor transformate in tabelele data warehouse-ului (fact si dimension)

De ce este critic #

ETL este partea cea mai putin vizibila dar cea mai critica a unui data warehouse. Daca datele sunt extrase incomplet, transformate cu reguli eronate sau incarcate fara verificari, tot ce sta deasupra — rapoarte, dashboard-uri, decizii — va fi gresit.

Exchange Partition

Mon, 01 Jan 0001 00:00:00 +0000

Exchange Partition este o operațiune DDL Oracle care permite schimbarea instantanee a conținutului unei partiții cu cel al unei tabele nepartiționate. Nu se mută niciun byte de date — operațiunea modifică doar pointerii din data dictionary.

Cum funcționează #

Comanda ALTER TABLE ... EXCHANGE PARTITION ... WITH TABLE ... modifică metadatele din data dictionary astfel încât segmentele fizice ale partiției și ale tabelei de staging să își schimbe proprietarul. Tabela de staging devine partiția și invers. Operațiunea durează mai puțin de o secundă indiferent de volumul datelor, deoarece nu implică nicio mișcare fizică.

Execution Plan

Mon, 01 Jan 0001 00:00:00 +0000

Un execution plan (plan de executie) este secventa de operatii pe care baza de date o alege pentru a rezolva o interogare SQL. Cand scrii un SELECT cu JOIN-uri, filtre WHERE si sortari, optimizatorul evalueaza zeci de strategii posibile si alege una pe baza statisticilor disponibile.

Cum functioneaza #

Planul este reprezentat ca un arbore de noduri: fiecare nod este o operatie (scan, join, sort, aggregate) care primeste date de la nodurile copil si le transmite nodului parinte. In PostgreSQL se vizualizeaza cu EXPLAIN (plan estimat) sau EXPLAIN ANALYZE (plan real cu timpii efectivi si contoarele de randuri).

Facilitator

Mon, 01 Jan 0001 00:00:00 +0000

Facilitatorul este persoana însărcinată cu ghidarea desfășurării unei ședințe. Nu este cel care decide — este cel care garantează că decizia se ia în mod ordonat, în timpul prevăzut și cu contribuția tuturor participanților.

Cum funcționează #

Facilitatorul ține timpul, gestionează turele de cuvânt, taie discuțiile în afara subiectului (“o notez în parking lot, discutăm după”) și se asigură că standup-ul nu depășește 15 minute. Rolul poate fi fix sau prin rotație în echipă.

Fact table

Mon, 01 Jan 0001 00:00:00 +0000

Fact table (tabela de fapte) este tabela centrală a unui star schema în data warehouse. Conține măsurile numerice — sume, cantități, contorizări, durate — și cheile externe care o conectează la tabelele dimensionale.

Structură #

Fiecare linie din fact table reprezintă un eveniment sau o tranzacție de business: o vânzare, o daună, o expediere, un acces. Coloanele se împart în două categorii:

Float Financiar

Mon, 01 Jan 0001 00:00:00 +0000

Float-ul Financiar este lichiditatea pe care o companie o generează din diferența dintre timpii de încasare de la clienții săi (mai scurți) și timpii de plată către furnizorii săi (mai lungi). Este efectiv un împrumut la cost zero obținut pe cheltuiala furnizorilor.

Cum funcționează #

O firmă de consultanță încasează de la clientul final la 30 de zile dar plătește consultanții proprii la 90 de zile. Diferența de 60 de zile generează un float: pentru fiecare 100.000€ de venituri lunare, compania dispune de ~200.000€ de lichiditate gratuită pe care o poate investi sau folosi ca capital circulant.

FLUSH PRIVILEGES

Mon, 01 Jan 0001 00:00:00 +0000

FLUSH PRIVILEGES este o comandă MySQL/MariaDB care forțează serverul să reîncarce în memorie tabelele de privilegii din baza de date mysql. Face imediat efective modificările permisiunilor.

Cum funcționează #

MySQL menține în memorie un cache al tabelelor de grant (mysql.user, mysql.db, mysql.tables_priv). Când se folosesc CREATE USER și GRANT, MySQL actualizează atât tabelele cât și cache-ul automat. Dar dacă tabelele de grant sunt modificate direct cu INSERT, UPDATE sau DELETE, cache-ul nu se actualizează. FLUSH PRIVILEGES forțează reîncărcarea cache-ului din tabele.

Full Table Scan

Mon, 01 Jan 0001 00:00:00 +0000

Full Table Scan (sau TABLE ACCESS FULL) este o operatie in care baza de date citeste toate blocurile de date ale unei tabele, de la inceput la sfarsit, fara a trece prin vreun index.

Cum functioneaza #

Oracle solicita blocuri de pe disc (sau din cache) in secventa, folosind citiri multi-bloc (db file scattered read). Fiecare rand din tabela este examinat, indiferent daca indeplineste sau nu criteriile query-ului.

GIN Index

Mon, 01 Jan 0001 00:00:00 +0000

Un GIN Index (Generalized Inverted Index) este un tip de index PostgreSQL proiectat pentru indexarea valorilor compuse: array-uri, documente JSONB, text cu trigrame și căutări full-text. Spre deosebire de B-Tree, un GIN creează un mapping inversat: de la fiecare element (cuvânt, trigramă, cheie JSON) la înregistrările care îl conțin.

Cum funcționează #

Pentru fiecare valoare distinctă din datele indexate, GIN menține o listă de pointeri către rândurile care conțin acea valoare. În cazul pg_trgm, textul este descompus în trigrame (secvențe de 3 caractere) și fiecare trigramă este indexată. O căutare LIKE '%ABC%' este tradusă într-o intersecție de trigrame, evitând scanarea secvențială.

Grain

Mon, 01 Jan 0001 00:00:00 +0000

Grain-ul (granularitatea) este nivelul de detaliu al unei fact table într-un data warehouse. Definește ce reprezintă un singur rând: o tranzacție, un sumar zilnic, un total lunar, o linie de factură.

Cum funcționează #

Alegerea grain-ului este prima decizie la proiectarea unei fact table. Toate celelalte decizii — măsuri, dimensiuni, ETL — decurg din ea:

Grain fin (ex. linie de factură): flexibilitate maximă în interogări, mai multe rânduri de gestionat
Grain agregat (ex. total lunar per client): mai puține rânduri, interogări mai rapide, dar imposibilitatea de a coborî în detaliu

Principiul fundamental al lui Kimball: modelează întotdeauna la cel mai fin nivel de detaliu disponibil în sistemul sursă.

GRANT

Mon, 01 Jan 0001 00:00:00 +0000

GRANT este comanda SQL folosită pentru atribuirea de privilegii unui utilizator sau rol pe obiecte specifice ale bazei de date. În MySQL și MariaDB, privilegiile se atribuie perechii 'utilizator'@'host', nu doar numelui de utilizator.

Cum funcționează #

Sintaxa de bază este GRANT <privilegii> ON <baza_de_date>.<tabel> TO 'utilizator'@'host'. Privilegiile pot fi granulare (SELECT, INSERT, UPDATE, DELETE) sau globale (ALL PRIVILEGES). În MySQL 8, GRANT nu mai creează utilizatori implicit: e nevoie mai întâi de un CREATE USER explicit, apoi GRANT. În MySQL 5.7 și MariaDB, GRANT cu IDENTIFIED BY creează utilizatorul și atribuie privilegiile într-o singură comandă.

Group Replication

Mon, 01 Jan 0001 00:00:00 +0000

Group Replication este mecanismul nativ al MySQL pentru crearea de clustere cu disponibilitate ridicată și replicare sincronă între mai multe noduri. Spre deosebire de replicarea clasică (asincronă, master-slave), Group Replication garantează că fiecare tranzacție este confirmată de majoritatea nodurilor înainte de a fi considerată committed.

Cum funcționează #

Nodurile comunică printr-un protocol de grup (GCS — Group Communication System) care gestionează consensul distribuit. Fiecare nod menține o copie completă a datelor. Tranzacțiile sunt certificate de grup: dacă nu există conflicte, sunt aplicate pe toate nodurile. Dacă apare un conflict, tranzacția este anulată pe nodul care a inițiat-o.

GTID

Mon, 01 Jan 0001 00:00:00 +0000

GTID (Global Transaction Identifier) este un identificator unic atribuit automat fiecărei tranzacții confirmate pe un server MySQL. Formatul este server_uuid:transaction_id — de exemplu 3E11FA47-71CA-11E1-9E33-C80AA9429562:23.

Cum funcționează #

Când GTID este activat (gtid_mode = ON), fiecare tranzacție primește un identificator care o face trasabilă pe orice server din clusterul de replicare. Replica știe exact ce tranzacții a executat deja și care îi mai lipsesc, fără a fi nevoie să specifice manual pozițiile binlog (fișier + offset).

Hash Join

Mon, 01 Jan 0001 00:00:00 +0000

Hash join este o strategie de join proiectata pentru volume mari de date. Functioneaza in doua faze: mai intai construieste o structura de date in memorie, apoi o foloseste pentru a gasi corespondentele eficient.

Cum functioneaza #

Baza de date citeste tabelul mai mic (build side) si construieste o hash table in memorie, indexand randurile dupa coloana de join. Apoi scaneaza tabelul mai mare (probe side) si pentru fiecare rand cauta corespondenta in hash table cu un lookup O(1).

Hot Desk

Mon, 01 Jan 0001 00:00:00 +0000

Hot Desk (hot desking) este un model de organizare a spațiilor de lucru în care birourile nu sunt atribuite angajaților individuali. Cine vine la birou ocupă un post de lucru liber, de obicei rezervabil printr-un sistem digital.

Cum funcționează #

În loc de 50 de posturi fixe pentru 50 de angajați, compania amenajează 15-20 de posturi partajate (hot desks) echipate cu monitor, docking station și conectivitate. Angajații rezervă postul în zilele în care trebuie să fie la birou, folosind celelalte zile în smart working.

Huge Pages

Mon, 01 Jan 0001 00:00:00 +0000

Huge Pages sunt pagini de memorie de 2 MB, față de cele standard de 4 KB ale Linux. Pentru o SGA Oracle de 64 GB, trecerea de la pagini de 4 KB (16,7 milioane de pagini) la Huge Pages de 2 MB (32.768 pagini) reduce de 500 de ori numărul de intrări în Page Table.

Cum funcționează #

Se configurează prin parametrul kernel vm.nr_hugepages în /etc/sysctl.d/. Numărul necesar se calculează împărțind dimensiunea SGA la 2 MB și adăugând o marjă de 1,5%. După repornirea instanței Oracle, SGA este alocată în Huge Pages, verificabil din /proc/meminfo.

I/O Scheduler

Mon, 01 Jan 0001 00:00:00 +0000

I/O Scheduler este componenta kernelului Linux care gestionează coada cererilor de citire și scriere către dispozitivele bloc (discuri). Decide ordinea de execuție a cererilor pentru a optimiza throughput-ul și a minimiza latența.

Cum funcționează #

Linux oferă mai mulți scheduleri: cfq (Completely Fair Queuing, pentru desktop), deadline/mq-deadline (pentru servere și baze de date), noop/none (pentru SSD/NVMe). Pentru Oracle recomandarea este deadline, care servește cererile minimizând seek-urile discului. Se configurează prin /sys/block/sdX/queue/scheduler și se face permanent prin GRUB.

INTO OUTFILE

Mon, 01 Jan 0001 00:00:00 +0000

INTO OUTFILE este o clauză SQL MySQL care permite exportul rezultatului unei interogări direct într-un fișier pe filesystem-ul serverului de baze de date. Este metoda nativă pentru generarea de fișiere CSV, TSV sau cu separatori personalizați.

Cum funcționează #

Clauza se adaugă la sfârșitul unui SELECT și specifică calea fișierului de destinație. Parametrii FIELDS TERMINATED BY, ENCLOSED BY și LINES TERMINATED BY controlează formatul output-ului. Fișierul este creat de utilizatorul de sistem MySQL (nu de utilizatorul care execută query-ul), deci trebuie să fie într-un director cu permisiunile corecte.

Issue Tracker

Mon, 01 Jan 0001 00:00:00 +0000

Un Issue Tracker este un sistem pentru înregistrarea, atribuirea, prioritizarea și monitorizarea bug-urilor, cererilor de funcționalități și task-urilor de proiect. Pe GitHub este integrat direct în repository-ul de cod.

Cum funcționează #

Fiecare problemă sau cerere este creată ca “issue” cu titlu, descriere, etichete de categorie/prioritate și atribuire unui dezvoltator. Issue-urile pot fi legate de branch-uri și Pull Request-uri: când un PR care referențiază un issue este fuzionat, issue-ul se închide automat. Aceasta creează o trasabilitate completă de la problemă la soluție.

IST

Mon, 01 Jan 0001 00:00:00 +0000

IST (Incremental State Transfer) este mecanismul prin care un nod Galera care revine în cluster după o absență scurtă primește doar tranzacțiile lipsă, fără a fi nevoie să descarce întregul set de date.

Cum funcționează #

Când un nod se reconectează la cluster, donatorul verifică dacă tranzacțiile lipsă sunt încă disponibile în gcache-ul său (Galera cache). Dacă gap-ul este acoperit de gcache, se execută un IST: doar tranzacțiile lipsă sunt trimise nodului, care le aplică și revine în starea Synced. Dacă gap-ul depășește gcache-ul, Galera recurge la un SST complet.

Kimball

Mon, 01 Jan 0001 00:00:00 +0000

Kimball se referă la Ralph Kimball și la metodologia sa de proiectare a data warehouse-urilor, descrisă în cartea The Data Warehouse Toolkit (prima ediție 1996, a treia ediție 2013).

Abordarea #

Metodologia Kimball se bazează pe trei piloni:

Dimensional modeling: organizarea datelor în star schema cu fact tables și dimension tables, optimizate pentru interogări analitice
Bottom-up: construirea DWH-ului pornind de la data mart-uri departamentale individuale, integrându-le progresiv prin dimensiuni conforme (conformed dimensions)
Bus architecture: un framework pentru a garanta coerența între data mart-uri prin dimensiuni și fapte partajate

Slowly Changing Dimensions #

Kimball a definit clasificarea SCD (Slowly Changing Dimensions) în tipurile de la 0 la 7, care a devenit standardul de facto în industrie. Tipul 2 — cu chei surogat și date de valabilitate — este cel mai utilizat pentru urmărirea istoriei dimensiunilor.

Knowledge Transfer

Mon, 01 Jan 0001 00:00:00 +0000

Knowledge Transfer (transfer de cunoștințe) este procesul prin care competențe, informații și know-how sunt transferate de la cei care le dețin la cei care au nevoie de ele — între colegi, între echipe, sau între persoane și sisteme de documentare.

Cum funcționează #

Poate fi formal (documentare, sesiuni de training, wiki-uri) sau informal (pair programming, mentorat, însoțire). AI-ul poate accelera knowledge transfer-ul generând documentație din cod, commituri și issue-uri — nu perfectă, dar suficientă pentru a nu pierde cunoștințe când cineva părăsește proiectul.

KPI

Mon, 01 Jan 0001 00:00:00 +0000

Un KPI (Key Performance Indicator) este o metrică cuantificabilă folosită pentru a evalua succesul unei activități, proiect sau organizații față de obiective predefinite. În contextul muncii la distanță, KPI-urile înlocuiesc prezența fizică ca indicator de productivitate.

Cum funcționează #

Un KPI eficient este specific, măsurabil și legat de un obiectiv concret. În consultanța IT: tickete închise, cod livrat, SLA-uri respectate, clienți satisfăcuți. Nu “ore la birou” — pentru că orele nu măsoară valoarea produsă, măsoară doar timpul petrecut.

Least Privilege

Mon, 01 Jan 0001 00:00:00 +0000

Least Privilege (principiul privilegiului minim) este un principiu fundamental al securității informatice: fiecare utilizator, proces sau sistem trebuie să aibă doar permisiunile strict necesare pentru a-și îndeplini funcția, nimic mai mult.

Cum funcționează #

În contextul bazelor de date, principiul se aplică atribuind privilegii granulare: SELECT dacă utilizatorul trebuie doar să citească, SELECT + INSERT + UPDATE dacă trebuie și să scrie, niciodată ALL PRIVILEGES dacă nu este strict necesar. Combinat cu modelul utilizator@host al MySQL, principiul poate fi aplicat și în funcție de originea conexiunii.

Lift-and-Shift

Mon, 01 Jan 0001 00:00:00 +0000

Lift-and-Shift (rehosting) este o strategie de migrare care constă în mutarea unui sistem dintr-un mediu în altul — de obicei din on-premise în cloud — fără a-i modifica arhitectura, codul aplicativ sau configurația. Sistemul este luat ca atare și “ridicat și mutat”.

Cum funcționează #

Infrastructura este replicată în mediul de destinație: aceleași mașini virtuale, aceleași baze de date, același middleware. Avantajul este viteza: nu există rescrierea codului, nu există reproiectare arhitecturală. Riscul este de a duce cu sine toate problemele din mediul original, inclusiv ineficiențele și datoria tehnică.

Local Index

Mon, 01 Jan 0001 00:00:00 +0000

Un Local Index este un index Oracle creat pe o tabelă partițională, care este automat partiționat cu aceeași cheie și aceleași limite ca tabela. Fiecare partiție a tabelei are o partiție de index corespunzătoare.

Cum funcționează #

Când se creează un index cu clauza LOCAL, Oracle creează o partiție de index pentru fiecare partiție a tabelei. Dacă tabela are 100 de partiții lunare, indexul va avea 100 de partiții corespunzătoare. Operațiile DDL pe o partiție (DROP, TRUNCATE, SPLIT) invalidează doar partiția de index corespunzătoare, nu întregul index.

MERGE

Mon, 01 Jan 0001 00:00:00 +0000

MERGE este o instrucțiune SQL care combină operațiunile de INSERT și UPDATE (și opțional DELETE) într-un singur statement. Dacă înregistrarea există o actualizează, dacă nu există o inserează. Este numită informal “upsert”.

Sintaxă Oracle #

MERGE INTO tabel_destinatie d
USING tabel_sursa s ON (d.cheie = s.cheie)
WHEN MATCHED THEN UPDATE SET
 d.camp = s.camp
WHEN NOT MATCHED THEN INSERT (cheie, camp)
 VALUES (s.cheie, s.camp);

Utilizare în data warehouse #

În contextul ETL, MERGE este mecanismul de bază pentru încărcarea tabelelor dimensionale:

Mobilitate Durabilă

Mon, 01 Jan 0001 00:00:00 +0000

Mobilitatea Durabilă este o abordare a transportului urban care privilegiază utilizarea mijloacelor cu impact scăzut asupra mediului — bicicletă, transport public, vehicule electrice, car sharing — față de mașina privată cu motor cu combustie internă.

Cum funcționează #

Se bazează pe o schimbare de paradigmă: în loc să se construiască mai multe drumuri pentru mai multe mașini, se investește în infrastructură ciclabilă, transport public eficient și stimulente pentru mobilitatea activă. Orașe precum Amsterdam, Copenhaga și München demonstrează că modelul funcționează la scară largă.

MVCC

Mon, 01 Jan 0001 00:00:00 +0000

MVCC (Multi-Version Concurrency Control) este modelul de concurență folosit de PostgreSQL pentru a gestiona accesul simultan la date. Fiecare UPDATE creează o nouă versiune a rândului și o marchează pe cea veche ca “moartă”; fiecare DELETE marchează rândul ca nevizibil. Citirile nu blochează scrierile și invers.

Cum funcționează #

Fiecare tranzacție vede un snapshot consistent al bazei de date din momentul începerii sale. Rândurile modificate de alte tranzacții neconfirmate sunt invizibile. Aceasta elimină nevoia de lock-uri exclusive pe citiri, permițând concurență ridicată — dar generează “gunoi” sub formă de dead tuples care trebuie curățate de VACUUM.

mydumper

Mon, 01 Jan 0001 00:00:00 +0000

mydumper este un instrument open source de backup logic pentru MySQL și MariaDB care implementează paralelism adevărat: nu doar între tabele diferite, ci și în interiorul aceleiași tabele, împărțind-o în chunk-uri bazate pe primary key.

Cum funcționează #

mydumper se conectează la serverul MySQL, achiziționează un snapshot consistent cu FLUSH TABLES WITH READ LOCK (sau --trx-consistency-only pentru a evita lock-urile globale pe InnoDB), apoi distribuie munca între thread-uri multiple. Fiecare tabelă mare este spartă în chunk-uri — implicit bazate pe range-urile primary key-ului — și fiecare chunk este exportat de un thread separat.

mysqlbinlog

Mon, 01 Jan 0001 00:00:00 +0000

mysqlbinlog este utilitarul de linie de comandă furnizat cu MySQL pentru citirea și decodificarea conținutului fișierelor binary log. Este singurul instrument capabil să convertească formatul binar al binlog-urilor în output lizibil sau în instrucțiuni SQL re-executabile.

Cum funcționează #

mysqlbinlog citește fișierele binlog și produce output în format text. Suportă mai multe filtre:

Pe interval de timp: --start-datetime și --stop-datetime pentru a limita output-ul la o fereastră temporală
Pe bază de date: --database pentru a filtra evenimentele unei baze de date specifice
Pe poziție: --start-position și --stop-position pentru a selecta evenimente specifice

Cu format ROW, flag-ul --verbose decodifică modificările la nivel de rând în format pseudo-SQL comentat, altfel output-ul este un blob binar ilizibil.

mysqldump

Mon, 01 Jan 0001 00:00:00 +0000

mysqldump este utilitarul de backup logic inclus standard în fiecare instalare de MySQL și MariaDB. Produce un fișier SQL care conține toate instrucțiunile (CREATE TABLE, INSERT) necesare pentru a reconstrui complet schema și datele unei baze de date.

Cum funcționează #

mysqldump se conectează la serverul MySQL și citește tabelele una câte una, generând instrucțiunile SQL corespunzătoare la ieșire. Operația este strict single-threaded: o tabelă după alta, un rând după altul. Fișierul produs poate fi comprimat extern (gzip, zstd) dar instrumentul în sine nu oferă compresie nativă.

mysqlpump

Mon, 01 Jan 0001 00:00:00 +0000

mysqlpump este utilitarul de backup logic introdus de Oracle în MySQL 5.7 ca evoluție a mysqldump. Diferența principală este suportul pentru paralelism la nivel de tabelă și compresia nativă a output-ului (zlib, lz4, zstd).

Cum funcționează #

mysqlpump poate face dump la mai multe tabele simultan folosind thread-uri paralele, configurabile cu --default-parallelism. Compresia se aplică direct în timpul dump-ului, fără a necesita pipe-uri externe către gzip. Suportă și dump-ul selectiv al utilizatorilor și conturilor MySQL.

Navetism

Mon, 01 Jan 0001 00:00:00 +0000

Navetismul (commuting) este deplasarea zilnică între casă și locul de muncă. În marile orașe italiene precum Roma, naveta medie absoarbe 2-4 ore pe zi, cu costuri directe (combustibil, parcare, transport public) și indirecte (stres, oboseală, productivitate pierdută).

Cum funcționează #

Un consultant IT care locuiește la 30 km de birou în Roma poate petrece 1h15-2h30 doar pentru dus. Pe 220 de zile lucrătoare, sunt 47-89 de ore pierdute pe lună — până la două săptămâni lucrătoare petrecute în mașină fără a produce nimic.

Nested Loop

Mon, 01 Jan 0001 00:00:00 +0000

Nested loop este cea mai simpla strategie de join: pentru fiecare rand din tabelul extern, baza de date cauta randurile corespunzatoare in tabelul intern. Functioneaza ca un dublu ciclu for imbricat — de aici numele.

Cum functioneaza #

Optimizatorul alege un tabel ca “extern” (outer) si unul ca “intern” (inner). Pentru fiecare rand din tabelul extern, executa o cautare in tabelul intern pe coloana de join. Daca tabelul intern are un index pe coloana de join, fiecare cautare este un acces direct via B-tree. Fara index, fiecare cautare devine un sequential scan complet.

NOLOGGING

Mon, 01 Jan 0001 00:00:00 +0000

NOLOGGING este un mod Oracle care dezactivează generarea de redo log în timpul operațiunilor de încărcare masivă. Operațiunile se completează mult mai rapid, dar datele nu sunt recuperabile prin redo în caz de crash înainte de un backup.

Cum funcționează #

Când un segment (tabelă, index, partiție) este în mod NOLOGGING, operațiunile masive precum CTAS, INSERT /*+ APPEND */ și ALTER TABLE MOVE nu scriu redo log pentru blocurile de date. Pe o copie de 380 GB, acest lucru elimină generarea aceleiași cantități de redo, prevenind saturarea zonei de archivelog și reducând timpii de la zile la ore.

Object Privilege

Mon, 01 Jan 0001 00:00:00 +0000

Un Object Privilege în Oracle este o autorizare care permite executarea operațiunilor pe un obiect specific al bazei de date: o tabelă, o vizualizare, o secvență sau o procedură PL/SQL. Exemple tipice includ SELECT ON schema.tabela, INSERT ON schema.tabela și EXECUTE ON schema.procedura.

Cum funcționează #

Privilegiile de obiect se acordă cu GRANT specificând operațiunea și obiectul țintă: GRANT SELECT ON app_owner.clienti TO srv_report. Pot fi atribuite utilizatorilor individuali sau rolurilor. Spre deosebire de privilegiile de sistem, operează pe un singur obiect și nu conferă puteri globale asupra bazei de date.

OCI

Mon, 01 Jan 0001 00:00:00 +0000

OCI (Oracle Cloud Infrastructure) este platforma cloud a Oracle, lansata in a doua generatie in 2018. Spre deosebire de alti furnizori cloud, OCI este proiectata nativ pentru workload-uri Oracle Database si ofera avantaje semnificative in ceea ce priveste licentierea si performanta.

De ce OCI pentru Oracle Database #

Avantajul principal tine de licentiere. Pe OCI, Oracle recunoaste propriile OCPU (Oracle CPU) cu un raport 1:1 pentru calculul licentelor. Pe alti furnizori cloud precum AWS sau Azure, raportul vCPU-licente este mai putin favorabil si riscul de audit este real.

OLAP

Mon, 01 Jan 0001 00:00:00 +0000

OLAP (Online Analytical Processing) indică o abordare a procesării datelor orientată spre analiza multidimensională: agregări, drill-down, comparații temporale, slice-and-dice pe volume mari de date istorice.

OLAP vs OLTP #

Caracteristică	OLAP	OLTP
Scop	Analiză și raportare	Tranzacții operative
Model de date	Star schema, denormalizat	3NF, normalizat
Interogare tipică	Agregări pe milioane de linii	Citire/scriere a câtorva linii
Utilizatori	Analiști, management	Aplicații, operatori
Actualizare	Batch (ETL periodic)	Timp real

Operațiuni OLAP #

Operațiunile fundamentale ale analizei OLAP sunt:

Outsourcing

Mon, 01 Jan 0001 00:00:00 +0000

Outsourcing-ul este practica de a încredința dezvoltarea, mentenanța sau gestionarea sistemelor IT unor furnizori externi companiei. Poate implica proiecte complete (dezvoltarea de software custom) sau servicii continue (gestionarea infrastructurii, suport aplicativ).

Cum funcționează #

Compania client definește cerințele și semnează un contract cu un furnizor extern care se angajează să realizeze proiectul. Cele mai comune modele contractuale sunt: la pachet (preț fix pentru rezultat definit), pe timp și materiale (zile-om facturate), sau hibride. Furnizorul pune la dispoziție o echipă de consultanți care lucrează pe proiect, adesea cu rotație periodică a personalului.

Parking Lot

Mon, 01 Jan 0001 00:00:00 +0000

Parking Lot este o listă vizibilă — pe o tablă, un document partajat sau chat — unde facilitatorul notează subiectele care apar în timpul unei ședințe dar care nu pot fi discutate în timpul disponibil. Subiectele sunt “parcate” și abordate după ședință doar cu persoanele implicate.

Cum funcționează #

Când în timpul unui standup cineva ridică o problemă complexă, facilitatorul spune: “O notez în parking lot, discutăm după.” Subiectul nu este ignorat — este doar mutat în contextul potrivit, unde poate fi abordat fără a pierde timpul celor neimplicați.

Partita IVA

Mon, 01 Jan 0001 00:00:00 +0000

Partita IVA este codul de identificare fiscală atribuit lucrătorilor independenți și întreprinderilor din Italia pentru operațiunile supuse TVA. În consultanța IT, “a lucra cu partita IVA” înseamnă a opera ca freelancer, facturând serviciile direct clientului.

Cum funcționează #

Consultantul freelancer emite factură clientului la sfârșitul perioadei de lucru. Plata se face conform termenilor contractuali — care în Italia sunt de obicei 60-90-120 de zile sfârșit de lună. Între timp, consultantul suportă toate cheltuielile (contribuții sociale, impozite, chirie, utilități) din fonduri proprii.

Partition Pruning

Mon, 01 Jan 0001 00:00:00 +0000

Partition Pruning este mecanismul prin care Oracle, în timpul execuției unei interogări pe o tabelă partițională, identifică și exclude automat partițiile care nu pot conține date relevante pentru predicatul interogării.

Cum funcționează #

Când o interogare include un predicat pe coloana de partiție (ex. WHERE data_movimento BETWEEN ...), Oracle consultă metadatele partițiilor și determină care partiții conțin date în intervalul solicitat. Doar acele partiții sunt citite. În planul de execuție apare ca PARTITION RANGE SINGLE sau PARTITION RANGE ITERATOR.

Pedalare Asistată

Mon, 01 Jan 0001 00:00:00 +0000

Pedalarea Asistată este un sistem de propulsie electrică montat pe o bicicletă care amplifică forța de pedalare a ciclistului printr-un motor electric. Motorul se activează doar când se pedalează și se dezactivează peste 25 km/h (limita europeană).

Cum funcționează #

Un senzor detectează forța și cadența pedalării și activează motorul electric proporțional. Cu cât pedalezi mai tare, cu atât motorul ajută mai mult. Rezultatul este că urcări precum dealul Celio din Roma devin o pantă ușoară, iar la destinație ajungi fără să transpiri — un detaliu crucial pentru cine trebuie să se prezinte la birou.

pg_stat_statements

Mon, 01 Jan 0001 00:00:00 +0000

pg_stat_statements este o extensie PostgreSQL — inclusă în distribuția oficială dar neactivă implicit — care ține evidența statisticilor de execuție pentru toate query-urile SQL care trec prin server. Query-urile sunt normalizate (valorile literale înlocuite cu parametri) pentru a grupa execuțiile aceluiași pattern.

Cum funcționează #

Extensia necesită încărcarea ca shared library la pornirea serverului prin parametrul shared_preload_libraries. Odată activă, înregistrează pentru fiecare query: numărul de execuții, timpul total și mediu, rândurile returnate, blocurile citite de pe disc și din cache. Parametrul pg_stat_statements.max controlează câte query-uri distincte sunt urmărite (implicit 5000).

pg_trgm

Mon, 01 Jan 0001 00:00:00 +0000

pg_trgm este o extensie PostgreSQL care implementează căutarea bazată pe trigrame — secvențe de trei caractere consecutive extrase din text. Activează utilizarea indexurilor GIN și GiST pentru a accelera căutări LIKE '%valoare%' și ILIKE, care altfel ar necesita scanări secvențiale.

Cum funcționează #

Extensia descompune fiecare șir în trigrame: de exemplu, “hello” devine {" h", " he", “hel”, “ell”, “llo”, “lo “}. Un index GIN cu operator class gin_trgm_ops indexează aceste trigrame. Când se execută un LIKE '%ell%', PostgreSQL caută trigramele corespunzătoare în index în loc să scaneze întreaga tabelă.

PITR

Mon, 01 Jan 0001 00:00:00 +0000

PITR (Point-in-Time Recovery) este o tehnică de restaurare care permite readucerea unei baze de date la orice moment în timp, nu doar la momentul backup-ului. Se bazează pe combinarea unui backup complet cu log-urile de tranzacții (binary log în MySQL, WAL în PostgreSQL, redo log în Oracle).

Cum funcționează #

Procesul se desfășoară în două faze:

Restaurarea backup-ului: baza de date este restaurată la ultimul backup disponibil
Replay-ul log-urilor: log-urile de tranzacții sunt reaplicate de la momentul backup-ului până la momentul dorit, excluzând evenimentul care a cauzat problema

În MySQL, tool-ul mysqlbinlog extrage evenimentele din binary log-uri și le reproduce pe baza de date restaurată.

Presenteism

Mon, 01 Jan 0001 00:00:00 +0000

Presenteismul este cultura organizațională care măsoară valoarea muncii pe baza prezenței fizice a angajatului la birou, indiferent de calitatea și cantitatea rezultatelor produse. Este presupunerea că “dacă te văd la birou, lucrezi.”

Cum funcționează #

Într-o organizație presenteistă, a fi la birou de la 9 la 18 este mai important decât închiderea task-urilor. A veni târziu este o problemă chiar dacă ai produs mai mult decât toți. A lucra de acasă este suspect chiar dacă rezultatele sunt excelente. Controlul se bazează pe vedere, nu pe metrici.

Pull Request

Mon, 01 Jan 0001 00:00:00 +0000

Un Pull Request (PR) este o cerere formală de incorporare a modificărilor dintr-un branch de dezvoltare în branch-ul principal al repository-ului. Este mecanismul central de colaborare pe GitHub și platforme similare.

Cum funcționează #

Dezvoltatorul lucrează pe un branch dedicat (ex. fix/issue-234-eroare-calcul), completează modificările și deschide un PR. PR-ul arată diff-ul codului, permite colegilor să comenteze rând cu rând, să ceară modificări sau să aprobe. Doar după aprobare codul se unește (merge) în branch-ul principal. Aceasta garantează că codul “bun” rămâne bun.

Quorum

Mon, 01 Jan 0001 00:00:00 +0000

Quorum-ul este numărul minim de noduri care trebuie să fie de acord pentru ca clusterul să fie considerat operațional. Într-un cluster cu 3 noduri, quorum-ul este 2 (majoritatea). Dacă un nod se deconectează, celelalte două recunosc că sunt majoritatea și continuă să funcționeze normal.

Cum funcționează #

Galera Cluster folosește un protocol de comunicare de grup care verifică continuu câte noduri sunt accesibile. Calculul este simplu: quorum = (număr total noduri / 2) + 1. Cu 3 noduri quorum-ul este 2, cu 5 noduri este 3. Nodurile care pierd quorum-ul trec în starea Non-Primary și refuză scrierile pentru a evita inconsistențele.

RAC

Mon, 01 Jan 0001 00:00:00 +0000

RAC (Real Application Clusters) este tehnologia Oracle care permite mai multor instante ale bazei de date sa acceseze simultan acelasi storage partajat. Daca un nod se defecteaza, celelalte continua sa serveasca cererile fara intrerupere — failover-ul este transparent pentru aplicatii.

Cum functioneaza #

Un cluster RAC este compus din doua sau mai multe servere (noduri) conectate printr-o retea privata de mare viteza (interconnect) si storage partajat (de obicei ASM — Automatic Storage Management). Fiecare nod ruleaza propria instanta Oracle, dar toate acceseaza aceleasi datafile-uri.

Ragged hierarchy

Mon, 01 Jan 0001 00:00:00 +0000

O ragged hierarchy (ierarhie dezechilibrată) este o structură ierarhică în care nu toate ramurile ating aceeași adâncime. Unele niveluri intermediare lipsesc pentru anumite entități.

Exemplu concret #

Într-o ierarhie cu trei niveluri Top Group → Group → Client:

Unii clienți au toate cele trei niveluri (ierarhie completă)
Unii clienți au un Group dar niciun Top Group
Unii clienți nu au nici Group nici Top Group (clienți direcți)

Rezultatul este o structură cu “goluri” care cauzează probleme în rapoartele de agregare: linii cu NULL, totaluri împărțite, drill-down-uri incomplete.

Range Partitioning

Mon, 01 Jan 0001 00:00:00 +0000

Range Partitioning (partiționare pe intervale) este o strategie de partiționare a tabelelor în care rândurile sunt distribuite în partiții diferite pe baza valorii unei coloane relative la intervale predefinite. Coloana de partiționare este aproape întotdeauna o dată în data warehouse-uri.

Cum funcționează #

Fiecare partiție este definită cu o clauză VALUES LESS THAN care stabilește limita superioară a intervalului. Oracle atribuie automat fiecare rând partiției corecte pe baza valorii coloanei de partiționare. Dacă un rând are data_vendita = '2025-03-15', este inserat în partiția al cărei interval include acea dată.

Redo Log

Mon, 01 Jan 0001 00:00:00 +0000

Redo Log este mecanismul prin care Oracle inregistreaza fiecare modificare a datelor (INSERT, UPDATE, DELETE, DDL) inainte ca aceasta sa fie scrisa definitiv in datafile-uri. Este garantia fundamentala a durabilitatii tranzactiilor.

Cum functioneaza #

Oracle scrie modificarile in redo log-urile online secvential si continuu. Redo log-urile sunt organizate in grupuri circulare: cand un grup se umple, Oracle trece la urmatorul. Cand toate grupurile au fost folosite, Oracle revine la primul (log switch).

Relay log

Mon, 01 Jan 0001 00:00:00 +0000

Relay log-ul este un fișier de log intermediar prezent pe slave într-o arhitectură de replicare MySQL. Conține evenimentele primite din binary log-ul master-ului, în așteptarea de a fi executate local de către thread-ul SQL al slave-ului.

Cum funcționează #

Fluxul replicării MySQL trece prin relay log în trei faze:

I/O thread-ul slave-ului se conectează la master și citește binary log-urile
Evenimentele primite sunt scrise în relay log-ul local
SQL thread-ul slave-ului citește evenimentele din relay log și le execută pe baza de date locală

Această arhitectură cu două thread-uri permite decuplarea recepției datelor de aplicarea lor: slave-ul poate continua să primească evenimente de la master chiar dacă execuția locală este temporar mai lentă.

REVOKE

Mon, 01 Jan 0001 00:00:00 +0000

REVOKE este comanda SQL care elimină privilegiile sau rolurile acordate anterior cu GRANT. Este complementul indispensabil al GRANT și instrumentul principal pentru restricționarea permisiunilor atunci când un model de securitate este restructurat.

Cum funcționează #

Sintaxa urmează același tipar ca GRANT: REVOKE SELECT ON schema.tabela FROM utilizator sau REVOKE rol FROM utilizator. În Oracle, revocarea unui rol precum DBA elimină dintr-o singură lovitură toate privilegiile de sistem incluse în acel rol. Înainte de a executa un REVOKE critic, este esențial să se verifice că utilizatorul păstrează privilegiile necesare pentru funcțiile sale.

RMAN

Mon, 01 Jan 0001 00:00:00 +0000

RMAN (Recovery Manager) este instrumentul nativ Oracle pentru backup, restore si recovery al bazei de date. Este o utilitate de linie de comanda care gestioneaza toate operatiunile de protectie a datelor in mod integrat cu baza de date.

Ce face #

Backup: complet, incremental, doar archived log-uri
Restore: recuperarea datafile-urilor, tablespace-urilor sau a intregii baze de date
Recovery: aplicarea redo log-urilor pentru a aduce baza de date la un punct specific in timp
Duplicate: crearea de copii ale bazei de date, inclusiv baze de date standby pentru Data Guard

RMAN si Data Guard #

Pentru crearea unei baze de date standby, RMAN permite DUPLICATE ... FOR STANDBY FROM ACTIVE DATABASE — o copie directa prin retea de la primar la standby, fara nevoia de backup-uri intermediare pe banda sau disc. Comanda transfera toate datafile-urile si controlfile-urile si le configureaza automat pentru replicare.

ROI

Mon, 01 Jan 0001 00:00:00 +0000

ROI (Return on Investment) este metrica care măsoară randamentul unei investiții raportând beneficiul net la costul suportat, exprimat ca procent. Un ROI de 200% înseamnă că fiecare euro investit a generat doi euro retur.

Cum funcționează #

Se calculează ca: (Beneficiu - Cost) / Cost × 100. În contextul proiectelor IT cu componente AI, calculul ROI trebuie să includă nu doar costurile de implementare ci și cele de mentenanță, training al echipei, guvernanță și gestionare a erorilor modelului.

ROLE

Mon, 01 Jan 0001 00:00:00 +0000

În PostgreSQL, ROLE este singura entitate de securitate. Nu există o distincție între “utilizator” și “rol”: totul este un ROLE. Un ROLE cu atributul LOGIN se comportă ca un utilizator; fără LOGIN, este un container de privilegii atribuibil altor ROLE-uri.

Cum funcționează #

CREATE USER mario este pur și simplu o scurtătură pentru CREATE ROLE mario WITH LOGIN. ROLE-urile pot deține obiecte, moșteni privilegii de la alte ROLE-uri prin atributul INHERIT, și fi utilizate pentru a construi ierarhii de permisiuni. Un ROLE “funcțional” (fără LOGIN) grupează privilegii; ROLE-urile “utilizator” (cu LOGIN) le moștenesc.

RPO

Mon, 01 Jan 0001 00:00:00 +0000

RPO (Recovery Point Objective) este cantitatea maxima de date pe care o organizatie si-o poate permite sa piarda in caz de defectiune sau dezastru. Se masoara in timp: un RPO de 1 ora inseamna acceptarea pierderii a cel mult ultimei ore de tranzactii.

Cum se determina #

RPO-ul depinde de strategia de backup si replicare:

Strategie	RPO tipic
Backup nocturn pe banda	12-24 ore
Backup + archived log-uri pe storage remote	1-4 ore
Data Guard asincron (MaxPerformance)	Cateva secunde
Data Guard sincron (MaxAvailability)	Zero

RPO vs RTO #

RPO si RTO sunt complementare dar distincte:

RTO

Mon, 01 Jan 0001 00:00:00 +0000

RTO (Recovery Time Objective) este timpul maxim acceptabil pentru restaurarea serviciului dupa o defectiune sau un dezastru. Se masoara din momentul defectiunii pana in momentul in care sistemul redevine operational.

Cum se determina #

RTO-ul depinde de strategia de recuperare si de infrastructura disponibila:

Strategie	RTO tipic
Restore din backup pe banda	4-12 ore
Restore din backup pe disc	1-4 ore
Data Guard cu switchover manual	1-5 minute
Data Guard cu Fast-Start Failover	10-30 secunde

RTO vs RPO #

RTO: cat timp dureaza repornirea (priveste inainte)
RPO: cate date poti pierde (priveste inapoi)

Sunt metrici independente. Un restore din backup poate avea RTO=2 ore si RPO=24 ore. Un Data Guard sincron poate avea RTO=30 secunde si RPO=0.

SCAN Listener

Mon, 01 Jan 0001 00:00:00 +0000

SCAN Listener (Single Client Access Name) este componenta Oracle RAC care ofera un singur nume DNS pentru accesul la cluster. Aplicatiile se conecteaza la SCAN name fara a fi nevoie sa cunoasca nodurile individuale: listener-ul distribuie automat conexiunile intre nodurile active.

Cum functioneaza #

SCAN este un nume DNS care se rezolva la trei adrese IP virtuale (VIP), distribuite intre nodurile clusterului. Cand un client se conecteaza la SCAN name, DNS-ul returneaza una dintre cele trei IP-uri, iar listener-ul de pe acel IP redirectioneaza conexiunea catre nodul cel mai potrivit in functie de serviciul solicitat si de sarcina.

SCD

Mon, 01 Jan 0001 00:00:00 +0000

SCD (Slowly Changing Dimension) se refera la un set de tehnici folosite in data warehouse pentru gestionarea modificarilor in datele tabelelor dimensionale de-a lungul timpului.

Tipurile principale #

Tipul 1: suprascrierea valorii anterioare. Nicio istorie conservata
Tipul 2: inserarea unui rand nou cu date de valabilitate (data inceput, data sfarsit). Conserva toata istoria
Tipul 3: adaugarea unei coloane pentru valoarea anterioara. Conserva doar ultima modificare

De ce conteaza #

Intr-o baza de date tranzactionala, cand un client isi schimba adresa se actualizeaza inregistrarea. Intr-un data warehouse acest lucru ar insemna pierderea istoriei: toate vanzarile anterioare ar aparea asociate noii adrese.

Schema

Mon, 01 Jan 0001 00:00:00 +0000

O Schemă într-o bază de date relațională este un namespace logic care grupează obiecte precum tabele, vizualizări, funcții și secvențe. Funcționează ca un container organizațional în cadrul unei baze de date.

Cum funcționează #

În PostgreSQL, schema prestabilită este public. Pentru a accesa un obiect dintr-o altă schemă este necesar prefixul: schema1.tabela. Privilegiul USAGE pe o schemă este prerequisit pentru accesarea oricărui obiect din ea — fără USAGE, nici măcar un GRANT SELECT pe tabele nu funcționează.

Scope

Mon, 01 Jan 0001 00:00:00 +0000

Scope-ul (domeniul) unui proiect definește perimetrul a ceea ce proiectul trebuie să realizeze: funcționalități incluse, livrabile așteptate, constrângeri și limite convenite cu stakeholderii. Tot ce este în scope se face; tot ce este în afara, nu.

Cum funcționează #

Scope-ul se definește în fazele inițiale ale proiectului prin documente precum Statement of Work sau Project Charter. Orice cerere de modificare ulterioară trebuie să treacă printr-un proces formal de gestionare a schimbărilor pentru a evalua impactul asupra termenelor, bugetului și resurselor.

Scope Creep

Mon, 01 Jan 0001 00:00:00 +0000

Scope Creep este expansiunea progresivă și adesea necontrolată a scopului unui proiect față de ceea ce fusese definit inițial. Cerințe noi, modificări ale specificațiilor și funcționalități suplimentare se acumulează fără o ajustare corespunzătoare a bugetului și a termenelor.

Cum funcționează #

Într-un proiect software, scope creep-ul începe de obicei cu cereri aparent mici: “hai să adăugăm și acest câmp”, “ar fi util și această funcție”. Fiecare modificare individuală pare rezonabilă, dar efectul cumulativ este devastator. Specificațiile devin o țintă mobilă, echipa nu reușește niciodată să atingă o baseline stabilă, iar proiectul intră într-un ciclu infinit de revizuiri.

Scrum

Mon, 01 Jan 0001 00:00:00 +0000

Scrum este un framework agil pentru gestionarea proiectelor care organizează munca în iterații cu durată fixă numite sprinturi (de obicei 2 săptămâni). Definește trei roluri (Product Owner, Scrum Master, Development Team) și patru ceremonii (Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective).

Cum funcționează #

Fiecare sprint începe cu o planificare, continuă cu standup-uri zilnice pentru sincronizare, și se termină cu o review (ce s-a făcut) și o retrospectivă (cum să îmbunătățim procesul). Timeboxing-ul este principiul fundamental: fiecare ceremonie are o durată maximă nenegociabilă.

secure-file-priv

Mon, 01 Jan 0001 00:00:00 +0000

secure-file-priv este o variabilă de sistem MySQL care controlează unde instrucțiunile LOAD DATA INFILE, SELECT INTO OUTFILE și funcția LOAD_FILE() pot opera pe filesystem-ul serverului.

Cum funcționează #

Variabila acceptă trei valori: o cale specifică (ex. /var/lib/mysql-files/), care limitează operațiunile pe fișiere la acel director; un șir gol (""), care nu impune nicio restricție; sau NULL, care dezactivează complet operațiunile pe fișiere. Valoarea poate fi setată doar în fișierul de configurare (my.cnf) și necesită restart al serviciului pentru a fi modificată — nu poate fi schimbată la runtime.

Self-parenting

Mon, 01 Jan 0001 00:00:00 +0000

Self-parenting-ul este o tehnică de dimensional modeling folosită pentru a echilibra ierarhiile dezechilibrate (ragged hierarchies). Principiul este simplu: o entitate care nu are un nivel ierarhic superior devine propriul părinte la acel nivel.

Cum funcționează #

Într-o ierarhie cu trei niveluri Top Group → Group → Client:

Un Client fără Group folosește propriul nume/ID ca Group
Un Group fără Top Group folosește propriul nume/ID ca Top Group

Rezultatul este o tabelă dimensională fără NULL-uri în coloanele ierarhice, cu toate nivelurile întotdeauna populate.

Sequential Scan

Mon, 01 Jan 0001 00:00:00 +0000

Sequential Scan (Seq Scan) este operația prin care PostgreSQL citește o tabelă de la început până la sfârșit, bloc cu bloc, fără a folosi vreun index. Este echivalentul PostgreSQL al Full Table Scan din Oracle.

Când este normal #

Pe tabele mici (câteva mii de rânduri), sequential scan-ul este adesea opțiunea cea mai eficientă. Citirea unei tabele întregi secvențial este mai rapidă decât lookup-urile pe un index când tabela încape în câteva pagini. Optimizer-ul alege sequential scan-ul când estimează că este mai ieftin decât un index scan.

SGA

Mon, 01 Jan 0001 00:00:00 +0000

SGA (System Global Area) este zona de memorie partajată principală a Oracle Database. Conține structurile de date fundamentale: buffer cache (pagini de date citite de pe disc), shared pool (planuri de execuție și dicționar de date), redo log buffer și large pool.

Cum funcționează #

Dimensiunea SGA este controlată de parametrul SGA_TARGET sau SGA_MAX_SIZE. Oracle alocă SGA la pornirea instanței în memoria partajată a sistemului de operare. Parametrii kernel Linux shmmax și shmall trebuie dimensionați pentru a permite alocarea completă a SGA.

shared_buffers

Mon, 01 Jan 0001 00:00:00 +0000

shared_buffers este parametrul care controlează dimensiunea zonei de memorie partajată pe care PostgreSQL o folosește ca cache pentru blocurile de date citite de pe disc. De fiecare dată când PostgreSQL citește o pagină de date (8 KB), o păstrează în shared_buffers pentru citirile ulterioare.

Cum funcționează #

PostgreSQL alocă memoria pentru shared_buffers la pornirea serviciului. Toate procesele backend partajează această zonă de memorie. Când un proces are nevoie de un bloc de date, caută mai întâi în shared_buffers. Dacă îl găsește (cache hit), citirea este imediată. Dacă nu (cache miss), trebuie să citească de pe disc — o operație cu ordine de mărime mai lentă.

Single-primary

Mon, 01 Jan 0001 00:00:00 +0000

Single-primary este modul de operare cel mai frecvent al MySQL Group Replication, în care un singur nod din cluster — primary-ul — acceptă operații de scriere. Celelalte noduri (secondary) sunt read-only (read_only=ON, super_read_only=ON) și primesc modificările prin replicarea sincronă a grupului.

Cum funcționează #

Parametrul group_replication_single_primary_mode=ON activează acest mod. Primary-ul este singurul nod cu read_only=OFF. Dacă primary-ul este oprit sau devine inaccesibil, clusterul declanșează o alegere automată și unul dintre secondary devine noul primary în câteva secunde.

Smart Working

Mon, 01 Jan 0001 00:00:00 +0000

Smart Working-ul (lucru agil) este un model organizațional care permite angajatului să lucreze de oriunde, combinând zile la birou și zile la distanță, cu program flexibil și evaluare bazată pe rezultate în loc de prezență.

Cum funcționează #

Modelul tipic este 80/20: 80% la distanță, 20% la birou. Zilele la birou servesc pentru workshopuri, review-uri de proiect și team building — nu pentru a încălzi scaunul. Compania furnizează echipament pentru postul de lucru de acasă (monitor, scaun ergonomic, căști) și o contribuție pentru conectivitate.

Snapshot (Oracle)

Mon, 01 Jan 0001 00:00:00 +0000

Snapshot in Oracle este o captura punctuala a statisticilor de performanta ale bazei de date stocata in repository-ul AWR. Implicit Oracle genereaza un snapshot la fiecare 60 de minute si le pastreaza timp de 8 zile.

Cum functioneaza #

Fiecare snapshot inregistreaza sute de metrici: wait events, statistici SQL, metrici de memorie (SGA, PGA), I/O per datafile, statistici de sistem. Compararea a doua snapshot-uri genereaza raportul AWR, care arata ce s-a schimbat intre cele doua momente.

Split-brain

Mon, 01 Jan 0001 00:00:00 +0000

Split-brain-ul este o condiție critică care apare când un cluster de baze de date se împarte în două sau mai multe partiții care nu pot comunica între ele, iar fiecare partiție continuă să accepte scrieri independent. Rezultatul sunt date divergente imposibil de reconciliat automat.

Cum funcționează #

Într-un cluster cu 3 noduri, dacă rețeaua dintre Nodul 1 și Nodurile 2-3 se întrerupe, fără protecția quorum-ului ambele părți ar putea continua să accepte scrieri. Când rețeaua se restabilește, clusterul s-ar găsi cu două versiuni diferite ale acelorași date. Mecanismul de quorum previne acest scenariu: doar partiția cu majoritatea nodurilor (quorum) poate continua să funcționeze.

SQL Injection

Mon, 01 Jan 0001 00:00:00 +0000

SQL Injection este una dintre cele mai răspândite și periculoase vulnerabilități în aplicațiile web. Apare când input-urile furnizate de utilizator sunt inserate direct în interogările SQL fără validare sau parametrizare, permițând unui atacator să modifice logica interogării.

Cum funcționează #

Atacatorul inserează fragmente de cod SQL în câmpurile de input ale aplicației (formulare de autentificare, câmpuri de căutare, parametri URL). Dacă aplicația concatenează aceste input-uri direct în interogările SQL, codul malițios este executat de baza de date cu privilegiile utilizatorului aplicativ. În combinație cu privilegiul FILE al MySQL-ului și un secure-file-priv neconfigurat, atacatorul poate citi fișiere de sistem sau scrie fișiere arbitrare pe server.

SST

Mon, 01 Jan 0001 00:00:00 +0000

SST (State Snapshot Transfer) este mecanismul prin care un nod Galera care se alătură clusterului (sau care a fost offline prea mult timp) primește o copie completă a întregului set de date de la un nod donator.

Cum funcționează #

Când un nod se alătură clusterului și gap-ul de tranzacții lipsă depășește dimensiunea gcache-ului, clusterul inițiază un SST. Nodul donator creează un snapshot complet al bazei de date și îl transferă nodului receptor. Metodele disponibile sunt: mariabackup (nu blochează donatorul), rsync (rapid dar blochează donatorul pe citire), și mysqldump (lent și blocant).

Stakeholder

Mon, 01 Jan 0001 00:00:00 +0000

Un Stakeholder este orice persoană, grup sau organizație cu un interes direct sau indirect în rezultatul unui proiect. Include clienți, sponsori, utilizatori finali, echipe de dezvoltare, management și furnizori externi.

Cum funcționează #

În project management, stakeholderii sunt identificați, clasificați după nivelul de influență și interes, și gestionați cu strategii de comunicare diferențiate. Un stakeholder cu influență și interes ridicate (precum CTO) necesită implicare activă; unul cu influență scăzută necesită doar actualizări periodice.

Star schema

Mon, 01 Jan 0001 00:00:00 +0000

Star schema (schema stea) este cel mai utilizat model de date în data warehouse. Își primește numele de la forma sa: o tabelă centrală de fapte (fact table) conectată la mai multe tabele dimensionale care o înconjoară, ca razele unei stele.

Structură #

Fact table în centru: conține măsurile numerice și cheile externe către dimensiuni
Dimension tables în jurul ei: conțin atributele descriptive (cine, ce, unde, când) cu structură denormalizată

Dimensiunile într-un star schema sunt tipic denormalizate — toate atributele într-o singură tabelă plată, fără ierarhii normalizate. Acest lucru simplifică interogările și îmbunătățește performanța agregărilor.

Swappiness

Mon, 01 Jan 0001 00:00:00 +0000

Swappiness (vm.swappiness) este un parametru al kernelului Linux care controlează cât de agresiv mută sistemul pagini de memorie din RAM în swap pe disc. Valoarea variază de la 0 (swap doar în cazuri extreme) la 100 (swap agresiv). Valoarea implicită este 60.

Cum funcționează #

Cu valoarea implicită de 60, Linux începe să facă swap când presiunea pe memorie este încă relativ scăzută. Pentru un server de baze de date dedicat, acest lucru este inacceptabil: SGA trebuie să rămână în RAM, întotdeauna. Valoarea recomandată pentru Oracle este 1 — nu 0, care ar dezactiva complet swap-ul și ar putea declanșa OOM killer-ul.

Switchover

Mon, 01 Jan 0001 00:00:00 +0000

Switchover-ul este o operatiune planificata in Oracle Data Guard care inverseaza rolurile intre baza de date primary si standby. Primary-ul devine standby, standby-ul devine primary. Nicio data nu se pierde, nicio tranzactie nu esueaza — este o tranzitie curata si controlata.

Switchover vs Failover #

Distinctia este fundamentala:

	Switchover	Failover
Cand	Planificat (mentenanta, migrare)	Urgenta (defectiune a primary-ului)
Pierdere de date	Zero	Posibila (depinde de mod)
Reversibilitate	Da, cu un alt switchover	Nu, standby-ul devine primary permanent
Timp	Minute (de obicei 1-3)	Secunde pana la minute

Cum se executa #

Cu Data Guard Broker, switchover-ul este o singura comanda:

System Privilege

Mon, 01 Jan 0001 00:00:00 +0000

Un System Privilege în Oracle este o autorizare care permite executarea operațiunilor globale pe baza de date, independent de un obiect specific. Exemple tipice includ CREATE TABLE, CREATE SESSION, ALTER SYSTEM, CREATE USER și DROP ANY TABLE.

Cum funcționează #

Privilegiile de sistem se acordă cu GRANT și se revocă cu REVOKE. Pot fi atribuite direct unui utilizator sau unui rol. Rolul predefinit DBA include peste 200 de privilegii de sistem, motiv pentru care atribuirea sa utilizatorilor aplicativi este o practică periculoasă.

systemd

Mon, 01 Jan 0001 00:00:00 +0000

systemd este sistemul de inițializare și managerul de servicii implicit pe distribuțiile Linux moderne (CentOS/RHEL 7+, Ubuntu 16.04+, Debian 8+). În contextul bazelor de date, este mecanismul care pornește, oprește și monitorizează instanțele MySQL sau MariaDB.

Cum funcționează #

Fiecare serviciu este definit de un fișier unit (ex. mysqld.service) care specifică comanda de pornire, fișierul de configurare, dependențele și comportamentul în caz de crash. Într-un setup multi-instanță, se creează fișiere unit separate pentru fiecare instanță (ex. mysqld-app2.service, mysqld-reporting.service), fiecare cu propriul --defaults-file care indică spre un my.cnf diferit.

Tablespace

Mon, 01 Jan 0001 00:00:00 +0000

Un Tablespace este unitatea logică de organizare a stocării în Oracle Database. Fiecare tablespace este compus din unul sau mai multe fișiere de date (datafile) fizice pe disc, iar fiecare obiect al bazei de date (tabelă, index, partiție) rezidă într-un tablespace.

Cum funcționează #

Oracle separă gestionarea logică (tablespace) de cea fizică (datafile). Un DBA poate crea tablespace-uri dedicate pentru scopuri diferite: unul pentru datele active, unul pentru indexuri, unul pentru arhivă. Aceasta permite distribuirea sarcinii de I/O pe discuri diferite și aplicarea de politici de gestionare diferențiate (ex. read-only pentru datele istorice).

THP

Mon, 01 Jan 0001 00:00:00 +0000

THP (Transparent Huge Pages) este o funcție a kernelului Linux care promovează automat paginile de memorie de la 4 KB la 2 MB în fundal, fără configurare explicită. Spre deosebire de Huge Pages statice, sunt gestionate de procesul kernel khugepaged.

Cum funcționează #

Când sunt active (implicit always), kernelul încearcă să compacteze paginile normale în pagini mari în fundal. Procesul khugepaged lucrează continuu pentru a găsi și uni grupuri de pagini contigue, cauzând micro-înghețări imprevizibile în timpul operațiunilor de compactare.

Timeboxing

Mon, 01 Jan 0001 00:00:00 +0000

Timeboxing este o tehnică de gestionare a timpului care constă în atribuirea unui interval temporal fix și nenegociabil unei activități. Când timpul expiră, activitatea se încheie — indiferent dacă a fost finalizată sau nu.

Cum funcționează #

Se definește durata maximă (15 minute pentru un standup, 1 oră pentru o ședință de design, 2 săptămâni pentru un sprint) și constrângerea se respectă. Timeboxul forțează persoanele să se concentreze pe esențial, evitând discuțiile interminabile și perfecționismul paralizant.

Transport Lag

Mon, 01 Jan 0001 00:00:00 +0000

Transport lag este intarzierea intre momentul in care baza de date primary genereaza un redo log si momentul in care acel redo log este primit de baza de date standby intr-o configuratie Oracle Data Guard. Este unul dintre cei mai importanti indicatori pentru evaluarea sanatatii replicarii.

Cum se masoara #

Transport lag-ul se monitorizeaza printr-un query pe view-ul V$DATAGUARD_STATS sau prin Data Guard Broker:

Unified Audit

Mon, 01 Jan 0001 00:00:00 +0000

Unified Audit (Oracle Unified Auditing) este sistemul de audit centralizat introdus în Oracle Database 12c care înlocuiește mecanismele de audit tradiționale cu o singură infrastructură unificată. Toate evenimentele de audit converg în vizualizarea UNIFIED_AUDIT_TRAIL.

Cum funcționează #

Unified Audit se bazează pe audit policies: reguli declarative care specifică ce acțiuni să fie monitorizate (DDL, DML, autentificări, operațiuni administrative). Politicile se creează cu CREATE AUDIT POLICY, se activează cu ALTER AUDIT POLICY ... ENABLE și pot fi aplicate utilizatorilor specifici sau global. Înregistrările de audit sunt scrise într-o coadă internă și apoi persistate în tabela de sistem.

Unix Socket

Mon, 01 Jan 0001 00:00:00 +0000

Un Unix Socket (sau socket de domeniu Unix) este un endpoint de comunicare care permite la două procese de pe același sistem de operare să facă schimb de date fără a trece prin stiva de rețea TCP/IP. În MySQL, este metoda de conectare implicită când te conectezi la localhost.

Cum funcționează #

Când un client MySQL se conectează specificând -h localhost, clientul nu folosește TCP. Folosește fișierul socket Unix (de obicei /var/run/mysqld/mysqld.sock) pentru a comunica direct cu procesul serverului MySQL. Această comunicare se desfășoară integral în kernel, fără overhead de rețea, și e mai rapidă decât o conexiune TCP chiar și pe același host.

VACUUM

Mon, 01 Jan 0001 00:00:00 +0000

VACUUM este comanda PostgreSQL care recuperează spațiul ocupat de dead tuples (rânduri moarte) și îl face disponibil pentru inserări noi. Nu returnează spațiu sistemului de operare, nu reorganizează tabela și nu compactează nimic — marchează paginile ca rescriptibile.

Cum funcționează #

VACUUM tabela scanează tabela, identifică dead tuple-urile care nu mai sunt vizibile niciunei tranzacții și marchează spațiul lor ca reutilizabil. Este o operațiune ușoară care nu blochează scrierile și poate rula în paralel cu interogările normale. VACUUM FULL în schimb rescrie fizic întreaga tabelă cu lock exclusiv — de folosit foarte rar și doar în urgențe.

Vendor Lock-in

Mon, 01 Jan 0001 00:00:00 +0000

Vendor Lock-in este situația în care o companie devine dependentă de un furnizor extern până la punctul în care schimbarea devine extrem de costisitoare sau complex din punct de vedere tehnic. În contextul IT, apare când codul, arhitectura sau cunoașterea sistemului sunt în mâinile furnizorului, nu ale clientului.

Cum funcționează #

Lock-in-ul se instaurează gradual: furnizorul scrie codul cu convențiile proprii, folosește tehnologii proprietare sau nedocumentate, iar echipa internă nu este implicată în dezvoltare. Când furnizorul pleacă — din proprie voință sau prin concediere — ia cu el know-how-ul. Clientul rămâne cu un software pe care nu-l înțelege, nu știe să-l întrețină și nu-l poate evolua fără a reangaja același furnizor sau a o lua de la zero.

Version Control

Mon, 01 Jan 0001 00:00:00 +0000

Version Control (controlul versiunilor) este un sistem care înregistrează fiecare modificare a fișierelor unui proiect, menținând un istoric complet al cine a schimbat ce, când și de ce. Git este cel mai utilizat sistem de version control din lume.

Cum funcționează #

Fiecare modificare se înregistrează ca “commit” cu un mesaj descriptiv, un autor și un timestamp. Sistemul menține întreaga istorie a proiectului: poți reveni la orice versiune anterioară, compara versiuni diferite și înțelege evoluția codului în timp. Cu Git, fiecare dezvoltator are o copie completă a istoriei pe propriul computer.

Wait Event

Mon, 01 Jan 0001 00:00:00 +0000

Wait Event este un indicator de diagnostic al Oracle Database care identifica motivul pentru care o sesiune asteapta in loc sa lucreze activ. De fiecare data cand un proces nu poate continua — pentru ca asteapta un bloc de pe disc, un lock, un raspuns din retea sau un tur de CPU — Oracle inregistreaza un wait event specific.

Cele mai comune #

Wait Event	Semnificatie
`db file sequential read`	Citire un singur bloc — tipica accesului prin index
`db file scattered read`	Citire multi-bloc — tipica full table scan-urilor
`log file sync`	Asteptarea commit-ului in redo log
`enq: TX - row lock contention`	Conflict de lock pe rand
`direct path read`	Citire directa (ocolind buffer cache-ul)

La ce servesc #

Wait event-urile sunt baza metodologiei de diagnostic Oracle. Analizand ce evenimente domina DB time-ul (prin AWR sau ASH) se identifica imediat natura problemei: I/O, contention, CPU sau retea.

WSREP

Mon, 01 Jan 0001 00:00:00 +0000

WSREP (Write Set Replication) este API-ul și protocolul pe care Galera Cluster îl folosește pentru replicarea sincronă multi-master. Fiecare tranzacție este capturată ca “write set” (set de modificări la nivel de rând) și replicată pe toate nodurile clusterului înainte de commit.

Cum funcționează #

Când un nod execută o tranzacție, WSREP o interceptează la momentul commit-ului, o împachetează ca write set și o trimite tuturor nodurilor clusterului prin protocolul de comunicare de grup. Fiecare nod execută un proces de certification: verifică dacă tranzacția nu intră în conflict cu alte tranzacții concurente. Dacă certification-ul are succes, toate nodurile aplică tranzacția. Dacă eșuează, tranzacția este anulată pe nodul care a inițiat-o.

Yes-And

Mon, 01 Jan 0001 00:00:00 +0000

Yes-And (Da-Și) este o tehnică de comunicare originară din teatrul de improvizație, aplicată în project management pentru a transforma discuțiile conflictuale în conversații constructive. Principiul este simplu: în loc să negi propunerea interlocutorului cu “Nu, dar…”, o accepți cu “Da, și…” adăugând propria contribuție.

Cum funcționează #

Când cineva propune o idee, răspunsul “Nu” declanșează o reacție defensivă și blochează conversația. Răspunsul “Da, și…” recunoaște validitatea propunerii și o extinde, menținând dialogul deschis. Nu înseamnă să fii de acord cu totul — înseamnă să construiești pe propunerea celuilalt înainte de a o redirecționa.

ZDM

Mon, 01 Jan 0001 00:00:00 +0000

ZDM (Zero Downtime Migration) este instrumentul pe care Oracle il pune la dispozitie pentru automatizarea migrarilor bazelor de date Oracle catre OCI (Oracle Cloud Infrastructure) sau catre baze de date on-premises de versiune superioara. Numele este putin optimist — downtime-ul nu este zero, dar este redus la minim.

Cum functioneaza #

ZDM este in esenta un orchestrator care combina tehnologii Oracle existente intr-un flux automatizat unic. Suporta doua moduri: