Raportul de luni dimineața: patru ore de lag pe replica MySQL
Cum am redus lag-ul de replicare MySQL de la patru ore la treizeci de secunde: GTID, parallel replication cu LOGICAL_CLOCK și monitorizare reală cu pt-heartbeat.


Cum am redus lag-ul de replicare MySQL de la patru ore la treizeci de secunde: GTID, parallel replication cu LOGICAL_CLOCK și monitorizare reală cu pt-heartbeat.

Upgrade MySQL Community 8.0.34→8.0.45 pe RHEL 8: view-uri invalide, GTID, verificarea replicii și pașii corecți de patching. Workflow real, cu query-urile folosite.

Cum am redus timpii de căutare de la 90 de secunde la sub un secundă pe un arhiv Oracle de 30 de ani, alegând indexul potrivit pentru fiecare pattern de căutare.

Oracle 26ai introduce CREATE ASSERTION, constrângerea cross-tabel pe care SQL-92 o promitea de decenii. Sintaxă, comparație cu trigger-e și cazuri reale din asigurări.

Un full scan pe 1,3 miliarde de rânduri a saturat swap-ul pe două noduri MySQL. Diagnostic cu performance_schema, reconfigurare buffere per-thread și rolling restart fără downtime.

Ce nu include un Data Warehouse tehnic funcțional: ownership, calitate continuă, TDE Oracle 19c, Data Catalog. Un caz real din sectorul asigurărilor.


Ce nu include un Data Warehouse tehnic funcțional: ownership, calitate continuă, TDE Oracle 19c, Data Catalog. Un caz real din sectorul asigurărilor.

Bus matrix Kimball pentru alinierea data marts izolate: conformed dimensions, procese de business și vânzări comparabile. Caz real grup asigurări.

Range partitioning pe fact table de 800 milioane rânduri: de la query-uri trimestriale de 12 minute la 40 de secunde. Implementare lunară, exchange.

Ragged hierarchy în data warehouse: echilibrarea ierarhiilor dezechilibrate cu tehnica self-parenting. Drill-down corect pe clienți și grupuri.

SCD Tip 2 în data warehouse: istorizare dimensiuni cu chei surogat și date de valabilitate. Caz real: dimensiune clienți care evoluează în timp.

Data warehouse: granularitatea fact table determină ce întrebări poți răspunde. Greșeli frecvente în granularitate și impactul pe modelul dimensional.

Povestea Three Amigos de la UML și RUP: cum Booch, Rumbaugh și Jacobson, din rivali, au unificat object-oriented modeling. Și ce a rămas astăzi.

Management proiect: 5 reguli observate în echipele care rezistă sub presiune. Psychological safety, bus factor, outcome vs output, knowledge transfer.

AI Manager: rolul care guvernează impactul inteligenței artificiale asupra arhitecturilor, proceselor și oamenilor. Reflecții din 30 ani de IT.

Plăți la 60-90-120 zile în consultanța IT italiană: comparație cu regulile europene. DSO, directiva 2011/7/UE și strategii pentru freelanceri IT.

Pendulare în Roma: Brompton electrică vs mașină. 18 minute vs 50, 35€ de parcare economisiți. Alegerea mobilității sustenabile, date reale.

Smart working în consultanța IT: analiză economică și strategică a muncii la distanță. Cifre reale, KPI, prezenteism și productivitate vs birou.

Management proiect cu AI și GitHub: transformarea unui proiect haotic în workflow măsurabil cu issue tracking, code review și inteligență artificială.

Cum am redus timpii de căutare de la 90 de secunde la sub un secundă pe un arhiv Oracle de 30 de ani, alegând indexul potrivit pentru fiecare pattern de căutare.

Oracle 26ai introduce CREATE ASSERTION, constrângerea cross-tabel pe care SQL-92 o promitea de decenii. Sintaxă, comparație cu trigger-e și cazuri reale din asigurări.

Diagnostic ghidat al ORA-00205 în plină urgență nocturnă: faza MOUNT, control file, SPFILE, redo log. Metodă practică pentru DBA Oracle de gardă.

Șapte ani de Oracle văzuți prin enumerări: de la CHECK-ul 19c la SQL Domains 23ai, până la Assertions 26ai. O migrare în sectorul asigurări.

Oracle nu a avut niciodată ENUM nativ. CHECK constraints, lookup tables și SQL Domains 23ai: trei drumuri, un caz real banking, și ce va veni cu 26ai.

Migrare Oracle 19c on-premises la OCI: 2 TB cu RAC și Data Guard. Licensing BYOL, Data Pump, cutover peste noapte — cronică reală.

Oracle 19c pe Linux: tuning kernel pentru performanță reală. Huge Pages, THP, swappiness, I/O scheduler, ulimit — cifre înainte/după.

Replică logică PostgreSQL explicată prin întrebările unui coleg: migrare cross-versiune, CDC spre data warehouse, configurare pas cu pas.

PostgreSQL ENUM vs CHECK vs tabel lookup: ALTER TYPE ADD VALUE nu costă nimic, eliminarea unei valori costă o migrare. Trei drumuri, un caz telco real.

PostgreSQL: cum găsești și elimini indecșii nefolosiți cu pg_stat_user_indexes. Caz real: tabel cu 15 indecși, 8 nefolosiți niciodată.

PostgreSQL pg_stat_statements: extensia de diagnosticare query de instalat prima. Găsește cele trei query-uri care consumă 80% din resurse.

PostgreSQL VACUUM și autovacuum: diagnostic bloat pe bază de date 200 GB, citirea pg_stat_user_tables și tuning fără a dezactiva nimic.

PostgreSQL ROLE: utilizatorii și rolurile sunt același obiect. Model mental, GRANT, NOINHERIT și construirea unui utilizator read-only mentenabil.

Optimizare PostgreSQL: LIKE '%valoare%' generează full scan. Folosirea pg_trgm și index GIN pentru a transforma căutarea wildcard în lookup rapid.

Cum am redus lag-ul de replicare MySQL de la patru ore la treizeci de secunde: GTID, parallel replication cu LOGICAL_CLOCK și monitorizare reală cu pt-heartbeat.

Upgrade MySQL Community 8.0.34→8.0.45 pe RHEL 8: view-uri invalide, GTID, verificarea replicii și pașii corecți de patching. Workflow real, cu query-urile folosite.

Un full scan pe 1,3 miliarde de rânduri a saturat swap-ul pe două noduri MySQL. Diagnostic cu performance_schema, reconfigurare buffere per-thread și rolling restart fără downtime.

MySQL ENUM vs CHECK constraint vs tabelă lookup: trei căi pentru modelarea unei enumerări. Avantaje, limite și caz real de tracking expedieri.

MySQL 8.0 pre-upgrade assessment: dimensiuni, creștere, timpi de backup și restore cu information_schema. Cifre reale pentru planificare.

Backup MySQL: mysqldump vs mydumper vs mysqlpump pe bază de date de 60 GB. Timpi reali dump și restore, paralelism și decizie arhitecturală.

MySQL binary log: gestionare, retenție și point-in-time recovery. Caz real de server cu discul la 95% și 180 GB de binlog în șase luni.
Începe să scrii pentru a căuta…
Selectează un rezultat pentru previzualizare