Glossario on Ivan Luminaria

Additive Measure

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

Una additive measure (misura additiva) è un valore numerico in una fact table che può essere legittimamente sommato lungo qualsiasi dimensione: per cliente, per prodotto, per periodo, per zona.

Come funziona #

Le misure nelle fact table si classificano in tre categorie:

Additive: possono essere sommate lungo tutte le dimensioni (es. importo vendita, quantità, costo). Sono le più comuni e le più utili
Semi-additive: possono essere sommate lungo alcune dimensioni ma non lungo il tempo (es. saldo di un conto: sommabile per filiale, non per mese)
Non-additive: non possono essere sommate in alcun modo (es. percentuali, rapporti, medie precalcolate)

A cosa serve #

Le misure additive sono il cuore di ogni fact table perché permettono le aggregazioni che il business richiede: totali per periodo, per regione, per prodotto. La regola chiave: memorizzare sempre i valori atomici (il dettaglio), mai gli aggregati. Da un importo per riga di fattura puoi ottenere il totale mensile; dal totale mensile non puoi ricostruire le singole righe.

AI Manager

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

L’AI Manager è il ruolo professionale che governa l’introduzione e l’utilizzo dell’intelligenza artificiale all’interno di un progetto o un’organizzazione. Non è chi usa l’AI — è chi decide dove, come e con quali precauzioni integrarla nelle architetture esistenti.

Come funziona #

L’AI Manager risponde a domande che nessun modello può rispondere: dove l’AI genera valore reale e dove genera solo entusiasmo? Quanto costa mantenerla, non solo implementarla? Cosa succede quando il modello sbaglia? Come si integra con le architetture mission-critical senza comprometterne la stabilità?

ANALYZE

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

ANALYZE è il comando PostgreSQL che raccoglie statistiche sulla distribuzione dei dati nelle tabelle e le salva nel catalogo pg_statistic (leggibile tramite la vista pg_stats). L’optimizer usa queste statistiche per stimare la cardinalità — quante righe restituirà ogni operazione — e scegliere il piano di esecuzione più efficiente.

Cosa raccoglie #

Le statistiche raccolte da ANALYZE includono:

Most common values: i valori più frequenti per ogni colonna e la loro percentuale
Istogrammi di distribuzione: come sono distribuiti i valori rimanenti
Numero di valori distinti: quanti valori unici ha ogni colonna
Percentuale di NULL: quante righe hanno valore NULL per ogni colonna

La qualità di queste statistiche dipende dal numero di campioni raccolti, controllato dal parametro default_statistics_target.

Anonymous User

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

L’Anonymous User (utente anonimo) è un account MySQL/MariaDB con username vuoto (''@'localhost') che viene creato automaticamente durante l’installazione. Non ha nome e spesso non ha password.

Come funziona #

Quando un utente si connette, MySQL cerca la corrispondenza più specifica nella tabella mysql.user. L’utente anonimo ''@'localhost' è più specifico di 'mario'@'%' per una connessione da localhost, perché 'localhost' batte '%' nella gerarchia di specificità. Di conseguenza, Mario che si connette da locale viene autenticato come utente anonimo e perde tutti i suoi privilegi.

ASH

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

ASH (Active Session History) è un componente di Oracle Database che campiona lo stato di ogni sessione attiva una volta al secondo e conserva i dati in un buffer circolare in memoria (vista V$ACTIVE_SESSION_HISTORY).

Come funziona #

Ogni secondo Oracle registra per ogni sessione attiva:

SQL in esecuzione (SQL_ID)
Wait event corrente
Programma e modulo chiamante
Piano di esecuzione utilizzato (SQL_PLAN_HASH_VALUE)

I dati più vecchi vengono scaricati automaticamente nelle tabelle AWR (DBA_HIST_ACTIVE_SESS_HISTORY) e conservati per il periodo configurato.

Authentication Plugin

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

Un Authentication Plugin è il modulo che MySQL o MariaDB usa per verificare le credenziali di un utente al momento della connessione. Ogni utente nel sistema è associato a un plugin specifico che determina come la password viene hashata, trasmessa e verificata.

Come funziona #

I plugin principali sono: mysql_native_password (default in MySQL 5.7 e MariaDB), che usa un hash SHA1 doppio; caching_sha2_password (default in MySQL 8.0+), che usa SHA-256 con caching per migliorare sicurezza e performance. Quando un client si connette, deve supportare il plugin dell’utente a cui sta tentando di autenticarsi.

Autovacuum

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

L’Autovacuum è un daemon di PostgreSQL che esegue automaticamente VACUUM e ANALYZE sulle tabelle quando il numero di dead tuples supera una soglia calcolata come: threshold + scale_factor × n_live_tup. Con i default (threshold=50, scale_factor=0.2), su una tabella con 10 milioni di righe si attiva dopo 2 milioni di dead tuples.

Come funziona #

Il daemon controlla periodicamente pg_stat_user_tables e lancia un worker per ogni tabella che supera la soglia. Il numero massimo di worker simultanei è controllato da autovacuum_max_workers (default 3). Il parametro autovacuum_vacuum_cost_delay controlla quanto il vacuum rallenta sé stesso per non sovraccaricare l’I/O.

AWR

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

AWR (Automatic Workload Repository) è un componente integrato nel database Oracle che raccoglie automaticamente statistiche sulle performance del sistema a intervalli regolari (di default ogni 60 minuti) e le conserva per un periodo configurabile.

Come funziona #

AWR cattura snapshot periodici che includono:

Statistiche delle sessioni e dei wait event
Metriche SQL (top SQL per tempo di esecuzione, I/O, CPU)
Statistiche sulle strutture di memoria (SGA, PGA)
Statistiche I/O per datafile e tablespace

A cosa serve #

Il report AWR è lo strumento principale per diagnosticare problemi di performance in Oracle. Confrontando due snapshot è possibile identificare:

B-Tree

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

Il B-Tree (Balanced Tree) è la struttura dati più comune per gli indici nei database relazionali ed è il tipo di indice predefinito in PostgreSQL, MySQL e Oracle. Mantiene i dati ordinati in una struttura ad albero bilanciato che garantisce tempi di ricerca logaritmici.

Come funziona #

Un B-Tree organizza le chiavi in nodi ordinati, con ogni nodo che contiene puntatori ai nodi figli. La ricerca parte dalla radice e scende verso le foglie, dimezzando lo spazio di ricerca ad ogni livello. Per una tabella di 6 milioni di righe, un B-Tree richiede tipicamente 3-4 livelli di profondità, quindi 3-4 letture di pagina per trovare un valore.

Bicicletta Pieghevole

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

Una Bicicletta Pieghevole è una bicicletta progettata per ripiegarsi in dimensioni compatte (tipicamente 60×55×25 cm) in pochi secondi, diventando trasportabile come un bagaglio. La Brompton è il modello più noto, con meccanismo di piegatura in 10-20 secondi.

Come funziona #

Un sistema di cerniere e sganci rapidi permette di piegare telaio, manubrio e pedali in un pacchetto compatto. Una volta ripiegata, si porta in ufficio sotto la scrivania, si sale in metro o si mette nel bagagliaio. Nella versione elettrica, combina i vantaggi della pedalata assistita con la portabilità totale.

Binary log

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

Il binary log (o binlog) è un registro sequenziale in formato binario in cui MySQL scrive tutti gli eventi che modificano i dati: INSERT, UPDATE, DELETE e operazioni DDL. I file sono numerati progressivamente (mysql-bin.000001, mysql-bin.000002, ecc.) e gestiti tramite un file indice.

Come funziona #

Da MySQL 8.0 il binary log è abilitato di default tramite il parametro log_bin. MySQL crea un nuovo file binlog quando il server si avvia, quando il file corrente raggiunge max_binlog_size, o quando si esegue FLUSH BINARY LOGS. Supporta tre formati di registrazione: STATEMENT (registra le istruzioni SQL), ROW (registra le modifiche riga per riga) e MIXED (scelta automatica).

Bloat

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

Il Bloat è l’accumulo di spazio morto all’interno di una tabella o di un indice PostgreSQL, causato da dead tuples non ancora rimossi dal VACUUM. Una tabella con il 50% di bloat occupa il doppio dello spazio necessario e costringe le scansioni sequenziali a leggere il doppio delle pagine.

Come funziona #

Il bloat si misura confrontando la dimensione effettiva della tabella con la dimensione attesa basata sulle righe vive. L’estensione pgstattuple fornisce il campo dead_tuple_percent. Un bloat sopra il 20-30% è un segnale di allarme; sopra il 50% è un’emergenza.

Branch

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

Un Branch (ramo) è una linea di sviluppo indipendente in un repository Git. Ogni branch contiene una copia del codice su cui si può lavorare senza influenzare il branch principale (main) o il lavoro di altri sviluppatori.

Come funziona #

Quando uno sviluppatore crea un branch (es. fix/issue-234-errore-calcolo), Git crea un puntatore alla versione corrente del codice. Da quel momento, le modifiche fatte sul branch restano isolate. Al termine del lavoro, le modifiche vengono proposte al team tramite Pull Request e, dopo approvazione, unite (merged) nel branch principale.

Brompton

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

La Brompton è una bicicletta pieghevole prodotta a Londra dal 1975, considerata il riferimento mondiale nella categoria. Si piega in 10-20 secondi raggiungendo dimensioni di circa 58×56×27 cm — abbastanza compatta da stare sotto una scrivania o nel bagagliaio di un’utilitaria.

Come funziona #

Il meccanismo brevettato permette di piegare la bici in tre movimenti: telaio, manubrio e sella. Nella versione elettrica (Brompton Electric), un motore nel mozzo anteriore fornisce pedalata assistita fino a 25 km/h con un’autonomia di 40-70 km. La batteria è rimovibile e si ricarica in 4 ore.

BYOL

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

BYOL (Bring Your Own License) è un programma Oracle che consente alle aziende di trasferire le licenze software acquistate per l’infrastruttura on-premises verso Oracle Cloud Infrastructure (OCI), senza dover acquistare nuove licenze cloud.

Come funziona #

Quando un’azienda ha già licenze Oracle — tipicamente Enterprise Edition con opzioni come RAC, Data Guard o Partitioning — può “portarle con sé” nella migrazione a OCI. Il contratto di supporto (Software Update License & Support) viene mantenuto, e le licenze vengono associate alle risorse cloud invece che ai server fisici.

Carbon Footprint

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

Il Carbon Footprint (impronta di carbonio) è la quantità totale di gas serra — principalmente CO₂ — emessi direttamente o indirettamente da un’attività, un prodotto o un individuo, espressa in tonnellate di CO₂ equivalente.

Come funziona #

Per il pendolarismo urbano, il calcolo è diretto: un’auto ferma nel traffico di Roma produce in media 120-150 g di CO₂ per chilometro. Nel traffico congestionato anche di più, perché il motore gira al minimo consumando senza muoversi. Una bicicletta produce zero emissioni dirette.

CDC

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

CDC (Change Data Capture) è una tecnica per intercettare le modifiche ai dati (INSERT, UPDATE, DELETE) nel momento in cui avvengono e propagarle verso altri sistemi in tempo reale o quasi reale. A differenza degli approcci batch tradizionali (ETL periodici), il CDC cattura i cambiamenti in modo continuo e incrementale.

Come funziona #

L’approccio più diffuso è il log-based CDC: un componente esterno legge i log delle transazioni del database (binary log in MySQL, WAL in PostgreSQL, redo log in Oracle) e converte gli eventi in un flusso di dati consumabile da altri sistemi. Strumenti come Debezium, Maxwell e Canal implementano questo approccio per MySQL leggendo direttamente i binary log.

Chiave surrogata

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

La chiave surrogata (surrogate key) è un identificativo numerico sequenziale generato internamente dal data warehouse, senza alcun significato di business. È distinta dalla chiave naturale — quella che arriva dal sistema sorgente (es. il codice cliente, il numero di matricola).

Perché serve #

Nella SCD Tipo 2, lo stesso cliente può avere più righe nella tabella dimensionale — una per ogni versione storica. La chiave naturale (cliente_id) non è più univoca, quindi serve un identificativo che distingua ogni singola versione: la chiave surrogata (cliente_key).

Churn

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

Il churn di una tabella è la misura di quanto i suoi dati cambiano dopo l’inserimento. Una tabella con alto churn subisce frequenti UPDATE e DELETE; una tabella con basso churn è prevalentemente append-only (solo INSERT).

Come funziona #

In PostgreSQL, ogni UPDATE crea una nuova versione della riga (a causa del modello MVCC) e la vecchia versione diventa una dead tuple. Le DELETE creano anch’esse dead tuples. Più alto è il churn, più lavoro devono fare VACUUM e gli indici per mantenere le performance. Un indice GIN su una tabella ad alto churn può degradare significativamente le performance di scrittura.

COALESCE

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

COALESCE è una funzione SQL standard che accetta una lista di espressioni e restituisce la prima che non è NULL. Se tutte le espressioni sono NULL, restituisce NULL.

Sintassi #

COALESCE(espressione1, espressione2, espressione3, ...)

Equivale a una catena di CASE WHEN:

CASE WHEN espressione1 IS NOT NULL THEN espressione1
 WHEN espressione2 IS NOT NULL THEN espressione2
 WHEN espressione3 IS NOT NULL THEN espressione3
 ELSE NULL END

Uso nelle gerarchie #

Nel contesto delle ragged hierarchies, COALESCE viene spesso usata per riempire i livelli mancanti:

Code Review

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

La Code Review è la pratica per cui un collega esamina il codice scritto da un altro sviluppatore prima che venga incorporato nel branch principale. Su GitHub avviene dentro le Pull Request.

Come funziona #

Lo sviluppatore apre una Pull Request con le sue modifiche. Un reviewer assegnato esamina il diff del codice, lascia commenti, suggerisce miglioramenti e alla fine approva o richiede modifiche. Il processo è asincrono: non servono riunioni, il review avviene sullo strumento. Solo dopo l’approvazione il codice viene fuso nel branch principale.

Compliance

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

La Compliance (conformità normativa) è l’aderenza di un’organizzazione alle leggi, ai regolamenti e agli standard di settore applicabili alla sua attività. Nel contesto AI, include GDPR, regolamenti bancari (SOX, PCI-DSS), normative sanitarie e policy interne sull’uso dei dati.

Come funziona #

La compliance si verifica attraverso audit, controlli documentali e monitoraggio continuo. Per i progetti AI, richiede la tracciabilità dei dati usati per il training, la documentazione delle decisioni automatizzate e la capacità di spiegare come il modello è arrivato a un determinato output (explainability).

CTAS

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

CTAS (Create Table As Select) è un comando SQL Oracle che crea una nuova tabella e la popola in un’unica operazione con i risultati di una SELECT. È la tecnica standard per migrare dati da una struttura all’altra su tabelle di grandi dimensioni.

Come funziona #

Il comando combina DDL e DML: crea la tabella con la struttura derivata dalla SELECT e inserisce i dati in un unico passaggio. Con l’hint PARALLEL e la modalità NOLOGGING, la copia di centinaia di GB può completarsi in poche ore. Dopo la copia, si rinomina la tabella originale, si rinomina la nuova, e il downtime è limitato ai pochi secondi del rename.

Cutover

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

Il cutover è il momento in cui un sistema di produzione viene spostato dalla vecchia infrastruttura alla nuova. È la fase più visibile di una migrazione — quella che tutti ricordano, nel bene o nel male.

Anatomia di un cutover #

Un cutover ben pianificato segue un runbook dettagliato con passi numerati, tempi stimati, criteri di successo e procedure di rollback per ogni passo. I componenti tipici:

Daily Standup

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

Il Daily Standup è una riunione quotidiana breve (massimo 15 minuti) in cui ogni membro del team risponde a tre domande: cosa ho fatto ieri, cosa farò oggi, c’è qualcosa che mi blocca. Lo scopo è sincronizzare il team, non risolvere problemi.

Come funziona #

Ogni persona ha circa due minuti per il proprio aggiornamento. I problemi vengono segnalati ma non discussi: la risoluzione avviene dopo, tra le persone coinvolte. Il vincolo temporale è ciò che rende lo standup efficace — senza di esso, degenera in una riunione di status da 45 minuti.

Data Governance

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

La Data Governance è l’insieme di politiche, processi, ruoli e standard che un’organizzazione adotta per garantire che i propri dati siano accurati, sicuri, conformi alle normative e utilizzati in modo coerente.

Come funziona #

Definisce chi è responsabile dei dati (data owner, data steward), quali regole di qualità applicare, come classificare i dati per sensibilità e come tracciare la loro provenienza (data lineage). In un contesto AI, include anche la verifica della provenienza e qualità dei dati usati per il training dei modelli.

Data Guard

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

Data Guard è la tecnologia Oracle che mantiene una o più copie sincronizzate (standby) di un database di produzione (primario). Lo standby riceve e applica continuamente i redo log generati dal primario, rimanendo allineato in tempo reale o quasi.

Come funziona #

Il primario genera redo log con ogni transazione. Questi log vengono trasmessi allo standby via rete, dove vengono applicati in due modi possibili:

Data Warehouse

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

Un Data Warehouse (DWH) è un sistema di archiviazione dati progettato specificamente per l’analisi, il reporting e il supporto alle decisioni aziendali. A differenza dei database operazionali (OLTP), un DWH raccoglie dati da molteplici fonti, li trasforma e li organizza in strutture ottimizzate per le interrogazioni analitiche.

Come funziona #

I dati vengono estratti dai sistemi sorgente (gestionali, CRM, ERP), trasformati attraverso processi ETL che li puliscono, normalizzano e arricchiscono, e infine caricati nel DWH. Il modello dati tipico è lo star schema: una fact table centrale con le misure numeriche collegata a tabelle dimensionali che descrivono il contesto (tempo, cliente, prodotto, geografia).

Dead Tuple

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

Un Dead Tuple è una riga in una tabella PostgreSQL che è stata aggiornata (UPDATE) o cancellata (DELETE) ma non è ancora stata rimossa fisicamente. Resta nelle pagine dati, occupando spazio su disco e rallentando le scansioni.

Come funziona #

Quando PostgreSQL esegue un UPDATE, non sovrascrive la riga originale: crea una nuova versione e marca la vecchia come “morta”. La vecchia riga resta fisicamente nella pagina dati finché il VACUUM non la pulisce. I dead tuples sono il prezzo del modello MVCC — necessari per garantire l’isolamento transazionale.

DEFAULT PRIVILEGES

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

DEFAULT PRIVILEGES è un meccanismo PostgreSQL che permette di definire in anticipo i privilegi che verranno assegnati automaticamente a tutti gli oggetti futuri creati in uno schema. Si configura con il comando ALTER DEFAULT PRIVILEGES.

Come funziona #

Il comando ALTER DEFAULT PRIVILEGES IN SCHEMA schema1 GRANT SELECT ON TABLES TO srv_monitoraggio fa sì che ogni nuova tabella creata in schema1 sia automaticamente leggibile da srv_monitoraggio. Senza questa configurazione, le tabelle future richiederebbero un GRANT manuale ogni volta.

default_statistics_target

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

default_statistics_target è il parametro PostgreSQL che definisce il numero di campioni raccolti dal comando ANALYZE per costruire le statistiche di ogni colonna. Il valore di default è 100.

Come funziona #

PostgreSQL campiona un certo numero di valori per ogni colonna e li usa per costruire due strutture:

Most common values (MCV): la lista dei valori più frequenti, con le rispettive frequenze
Istogramma: la distribuzione dei valori rimanenti, divisa in bucket di uguale popolazione

Il parametro default_statistics_target determina quanti elementi avranno queste strutture. Con il valore 100 (default), l’istogramma avrà 100 bucket e la lista MCV conterrà fino a 100 valori.

Direttiva 2011/7/UE

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

La Direttiva 2011/7/UE è la normativa europea sui ritardi di pagamento nelle transazioni commerciali. Stabilisce regole chiare: termine standard di 30 giorni, massimo 60 tra imprese (con accordo esplicito), 30 per la PA, e interessi di mora automatici al tasso BCE + 8%.

Come funziona #

La direttiva è stata recepita in Italia con il D.Lgs. 231/2002 (modificato nel 2012). Sulla carta le regole ci sono: 30 giorni standard, interessi automatici, compenso forfettario di 40€ per fattura pagata in ritardo. Nella pratica italiana è come se non esistessero — il DSO medio italiano è 80 giorni, ben oltre il massimo di 60.

Drill-down

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

Il drill-down è l’operazione di navigazione nei report che permette di passare da un livello aggregato a un livello di maggiore dettaglio, scendendo lungo una gerarchia.

Come funziona #

In una gerarchia Top Group → Group → Client:

Si parte dal livello più alto: fatturato totale per Top Group
Si clicca su un Top Group per vedere i suoi Group (drill-down di primo livello)
Si clicca su un Group per vedere i singoli Client (drill-down di secondo livello)

L’operazione inversa — risalire dal dettaglio all’aggregato — si chiama drill-up (o roll-up).

DSO

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

Il DSO (Days Sales Outstanding) è la metrica che misura il numero medio di giorni che un’azienda impiega per incassare i propri crediti dopo l’emissione della fattura. È l’indicatore principale della velocità di pagamento in un mercato.

Come funziona #

Si calcola come: (Crediti commerciali / Fatturato) × Giorni del periodo. Un DSO di 30 significa che in media i clienti pagano entro un mese. In Italia il DSO medio è di 80 giorni secondo l’European Payment Report — quasi tre volte la media del nord Europa (24-27 giorni).

ETL

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

ETL (Extract, Transform, Load) è il processo fondamentale attraverso cui i dati vengono spostati dai sistemi sorgente (database operazionali, file, API) al data warehouse.

Le tre fasi #

Extract: estrazione dei dati dai sistemi sorgente. Può essere completa (full load) o incrementale (solo i dati nuovi o modificati)
Transform: pulizia, validazione, standardizzazione e arricchimento dei dati. Qui si applicano le regole di business, le lookup sulle dimensioni, i calcoli derivati
Load: caricamento dei dati trasformati nelle tabelle del data warehouse (fact e dimension)

Perché è critico #

L’ETL è la parte meno visibile ma più critica di un data warehouse. Se i dati vengono estratti in modo incompleto, trasformati con regole errate o caricati senza controlli, tutto ciò che sta sopra — report, dashboard, decisioni — sarà sbagliato.

Exchange Partition

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

L’Exchange Partition è un’operazione DDL di Oracle che permette di scambiare istantaneamente il contenuto di una partizione con quello di una tabella non partizionata. Non viene spostato nemmeno un byte di dati — l’operazione modifica solo i puntatori nel data dictionary.

Come funziona #

Il comando ALTER TABLE ... EXCHANGE PARTITION ... WITH TABLE ... modifica i metadati nel data dictionary in modo che i segmenti fisici della partizione e della tabella di staging si scambino. La tabella di staging diventa la partizione e viceversa. L’operazione dura meno di un secondo indipendentemente dal volume dei dati, perché non implica alcun movimento fisico.

Execution Plan

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

Execution plan (piano di esecuzione) è la sequenza di operazioni che il database sceglie per risolvere una query SQL. Quando scrivi una SELECT con JOIN, filtri WHERE e ordinamenti, l’optimizer valuta decine di strategie possibili e ne sceglie una basandosi sulle statistiche disponibili.

Come funziona #

Il piano è rappresentato come un albero di nodi: ogni nodo è un’operazione (scan, join, sort, aggregate) che riceve dati dai nodi figli e li passa al nodo padre. In PostgreSQL si visualizza con EXPLAIN (piano stimato) o EXPLAIN ANALYZE (piano reale con tempi effettivi e conteggi righe).

Facilitatore

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

Il Facilitatore è la persona incaricata di guidare lo svolgimento di una riunione. Non è chi decide — è chi garantisce che la decisione venga presa in modo ordinato, nei tempi previsti e con il contributo di tutti i partecipanti.

Come funziona #

Il facilitatore tiene il tempo, gestisce i turni di parola, taglia le discussioni fuori tema (“lo segno nel parking lot, ne parliamo dopo”) e si assicura che lo standup non superi i 15 minuti. Il ruolo può essere fisso o a rotazione nel team.

Fact table

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

La fact table (tabella dei fatti) è la tabella centrale di uno star schema nel data warehouse. Contiene le misure numeriche — importi, quantità, conteggi, durate — e le chiavi esterne che la collegano alle tabelle dimensionali.

Struttura #

Ogni riga della fact table rappresenta un evento o una transazione di business: una vendita, un sinistro, una spedizione, un accesso. Le colonne si dividono in due categorie:

Float Finanziario

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

Il Float Finanziario è la liquidità che un’azienda genera dalla differenza tra i tempi di incasso dai propri clienti (più brevi) e i tempi di pagamento ai propri fornitori (più lunghi). È di fatto un prestito a costo zero ottenuto a spese dei fornitori.

Come funziona #

Una società di consulenza incassa dal cliente finale a 30 giorni ma paga i propri consulenti a 90 giorni. La differenza di 60 giorni genera un float: per ogni 100.000€ di fatturato mensile, l’azienda dispone di ~200.000€ di liquidità gratuita che può investire o usare come capitale circolante.

FLUSH PRIVILEGES

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

FLUSH PRIVILEGES è un comando MySQL/MariaDB che forza il server a ricaricare in memoria le tabelle dei privilegi dal database mysql. Rende immediatamente effettive le modifiche ai permessi.

Come funziona #

MySQL mantiene in memoria una cache delle tabelle dei grant (mysql.user, mysql.db, mysql.tables_priv). Quando si usano CREATE USER e GRANT, MySQL aggiorna sia le tabelle che la cache automaticamente. Ma se si modificano le tabelle dei grant direttamente con INSERT, UPDATE o DELETE, la cache non viene aggiornata. FLUSH PRIVILEGES forza il reload della cache dalle tabelle.

Full Table Scan

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

Full Table Scan (o TABLE ACCESS FULL) è un’operazione in cui il database legge tutti i blocchi dati di una tabella, dall’inizio alla fine, senza passare per alcun indice.

Come funziona #

Oracle richiede blocchi dal disco (o dalla cache) in sequenza, usando letture multi-blocco (db file scattered read). Ogni riga della tabella viene esaminata, indipendentemente dal fatto che soddisfi o meno i criteri della query.

GIN Index

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

Un GIN Index (Generalized Inverted Index) è un tipo di indice PostgreSQL progettato per indicizzare valori composti: array, documenti JSONB, testo con trigrammi e ricerche full-text. A differenza del B-Tree, un GIN crea un mapping inverso: da ogni elemento (parola, trigramma, chiave JSON) ai record che lo contengono.

Come funziona #

Per ogni valore distinto nel dato indicizzato, il GIN mantiene una lista di puntatori alle righe che contengono quel valore. Nel caso di pg_trgm, il testo viene scomposto in trigrammi (sequenze di 3 caratteri) e ogni trigramma viene indicizzato. Una ricerca LIKE '%ABC%' viene tradotta in un’intersezione di trigrammi, evitando la scansione sequenziale.

Grain

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

Il grain (grana, granularità) è il livello di dettaglio di una fact table nel data warehouse. Definisce cosa rappresenta una singola riga: una transazione, un riepilogo giornaliero, un totale mensile, una riga di fattura.

Come funziona #

La scelta del grain è la prima decisione nella progettazione di una fact table. Ogni altra scelta — misure, dimensioni, ETL — discende da essa:

GRANT

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

GRANT è il comando SQL usato per assegnare privilegi a un utente o ruolo su oggetti specifici del database. In MySQL e MariaDB, i privilegi vengono assegnati alla coppia 'utente'@'host', non solo al nome utente.

Come funziona #

La sintassi base è GRANT <privilegi> ON <database>.<tabella> TO 'utente'@'host'. I privilegi possono essere granulari (SELECT, INSERT, UPDATE, DELETE) o globali (ALL PRIVILEGES). In MySQL 8, GRANT non crea più utenti implicitamente: serve prima un CREATE USER esplicito, poi il GRANT. In MySQL 5.7 e MariaDB, GRANT con IDENTIFIED BY crea l’utente e assegna i privilegi in un solo comando.

Group Replication

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

Group Replication è il meccanismo nativo di MySQL per creare cluster ad alta disponibilità con replica sincrona tra più nodi. A differenza della replica classica (asincrona, master-slave), Group Replication garantisce che ogni transazione sia confermata dalla maggioranza dei nodi prima di essere considerata committata.

Come funziona #

I nodi comunicano tramite un protocollo di gruppo (GCS — Group Communication System) che gestisce il consenso distribuito. Ogni nodo mantiene una copia completa dei dati. Le transazioni vengono certificate dal gruppo: se non ci sono conflitti, vengono applicate su tutti i nodi. Se c’è un conflitto, la transazione viene annullata sul nodo che l’ha originata.

GTID

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

GTID (Global Transaction Identifier) è un identificativo univoco assegnato automaticamente a ogni transazione committata su un server MySQL. Il formato è server_uuid:transaction_id — ad esempio 3E11FA47-71CA-11E1-9E33-C80AA9429562:23.

Come funziona #

Quando il GTID è abilitato (gtid_mode = ON), ogni transazione riceve un identificativo che la rende tracciabile su qualsiasi server del cluster di replica. Lo slave sa esattamente quali transazioni ha già eseguito e quali deve ancora ricevere, senza bisogno di specificare manualmente posizioni di binlog (file + offset).

Hash Join

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

Hash join è una strategia di join progettata per grandi volumi di dati. Funziona in due fasi: prima costruisce una struttura dati in memoria, poi la usa per trovare le corrispondenze in modo efficiente.

Come funziona #

Il database legge la tabella più piccola (build side) e costruisce una hash table in memoria, indicizzando le righe per la colonna di join. Poi scansiona la tabella più grande (probe side) e per ogni riga cerca la corrispondenza nella hash table con un lookup O(1).

Hot Desk

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

L’Hot Desk (hot desking) è un modello di organizzazione degli spazi di lavoro in cui le scrivanie non sono assegnate a singoli dipendenti. Chi viene in ufficio occupa una postazione libera, tipicamente prenotabile tramite un sistema digitale.

Come funziona #

Invece di 50 postazioni fisse per 50 dipendenti, l’azienda predispone 15-20 postazioni condivise (hot desk) attrezzate con monitor, docking station e connettività. I dipendenti prenotano la postazione nei giorni in cui devono essere in ufficio, usando le altre giornate in smart working.

Huge Pages

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

Le Huge Pages sono pagine di memoria da 2 MB, contro i 4 KB standard di Linux. Per un’SGA Oracle da 64 GB, passare da pagine da 4 KB (16,7 milioni di pagine) a Huge Pages da 2 MB (32.768 pagine) riduce di 500 volte il numero di entry nella Page Table.

Come funziona #

Si configurano tramite il parametro kernel vm.nr_hugepages in /etc/sysctl.d/. Il numero necessario si calcola dividendo la dimensione della SGA per 2 MB e aggiungendo un margine dell'1,5%. Dopo il riavvio dell’istanza Oracle, la SGA viene allocata nelle Huge Pages, verificabile da /proc/meminfo.

I/O Scheduler

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

L’I/O Scheduler è il componente del kernel Linux che gestisce la coda delle richieste di lettura e scrittura verso i dispositivi a blocchi (dischi). Decide l’ordine di esecuzione delle richieste per ottimizzare il throughput e minimizzare la latenza.

Come funziona #

Linux offre diversi scheduler: cfq (Completely Fair Queuing, per desktop), deadline/mq-deadline (per server e database), noop/none (per SSD/NVMe). Per Oracle la raccomandazione è deadline, che serve le richieste minimizzando i seek del disco. Si configura via /sys/block/sdX/queue/scheduler e si rende permanente via GRUB.

Interessi di Mora

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

Gli Interessi di Mora sono gli interessi che maturano automaticamente su ogni fattura pagata in ritardo rispetto al termine contrattuale. In base al D.Lgs. 231/2002 (recepimento della Direttiva UE 2011/7/UE), il tasso è pari al tasso BCE + 8 punti percentuali, senza bisogno di messa in mora formale.

Come funziona #

Dal giorno successivo alla scadenza della fattura, gli interessi maturano automaticamente. Il creditore ha diritto anche a un compenso forfettario di 40€ per ogni fattura pagata in ritardo, per le spese di recupero. Non serve inviare una diffida — il diritto nasce dalla legge.

INTO OUTFILE

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

INTO OUTFILE è una clausola SQL di MySQL che permette di esportare il risultato di una query direttamente in un file sul filesystem del server database. È il metodo nativo per generare file CSV, TSV o con separatori personalizzati.

Come funziona #

La clausola si aggiunge alla fine di una SELECT e specifica il percorso del file di destinazione. I parametri FIELDS TERMINATED BY, ENCLOSED BY e LINES TERMINATED BY controllano il formato dell’output. Il file viene creato dall’utente di sistema MySQL (non dall’utente che esegue la query), quindi deve trovarsi in una directory con i permessi corretti.

Issue Tracker

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

Un Issue Tracker è un sistema per registrare, assegnare, prioritizzare e monitorare bug, richieste di funzionalità e task di progetto. Su GitHub è integrato direttamente nel repository del codice.

Come funziona #

Ogni problema o richiesta viene creata come “issue” con titolo, descrizione, label di categoria/priorità e assegnazione a uno sviluppatore. Le issue possono essere collegate ai branch e alle Pull Request: quando una PR che referenzia un’issue viene fusa, l’issue si chiude automaticamente. Questo crea una tracciabilità completa dal problema alla soluzione.

IST

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

IST (Incremental State Transfer) è il meccanismo con cui un nodo Galera che rientra nel cluster dopo un’assenza breve riceve solo le transazioni mancanti, senza dover scaricare l’intero dataset.

Come funziona #

Quando un nodo si riconnette al cluster, il donatore verifica se le transazioni mancanti sono ancora disponibili nel proprio gcache (Galera cache). Se il gap è coperto dal gcache, viene eseguito un IST: solo le transazioni mancanti vengono inviate al nodo, che le applica e torna in stato Synced. Se il gap supera il gcache, Galera ricade su un SST completo.

Kimball

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

Kimball si riferisce a Ralph Kimball e alla sua metodologia di progettazione dei data warehouse, descritta nel libro The Data Warehouse Toolkit (prima edizione 1996, terza edizione 2013).

L’approccio #

La metodologia Kimball si basa su tre pilastri:

Dimensional modeling: organizzare i dati in star schema con fact table e dimension table, ottimizzati per le query analitiche
Bottom-up: costruire il DWH partendo dai singoli data mart dipartimentali, integrandoli progressivamente tramite dimensioni conformi (conformed dimensions)
Bus architecture: un framework per garantire coerenza tra i data mart attraverso dimensioni e fatti condivisi

Le Slowly Changing Dimensions #

Kimball ha definito la classificazione delle SCD (Slowly Changing Dimensions) nei tipi da 0 a 7, che è diventata lo standard de facto nel settore. Il Tipo 2 — con chiavi surrogate e date di validità — è il più usato per tracciare la storia delle dimensioni.

Knowledge Transfer

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

Il Knowledge Transfer (trasferimento di conoscenza) è il processo attraverso cui competenze, informazioni e know-how vengono trasferiti da chi li possiede a chi ne ha bisogno — tra colleghi, tra team, o tra persone e sistemi di documentazione.

Come funziona #

Può essere formale (documentazione, sessioni di training, wiki) o informale (pair programming, mentoring, affiancamento). L’AI può accelerare il knowledge transfer generando documentazione a partire dal codice, dai commit e dalle issue — non perfetta, ma sufficiente per non perdere conoscenza quando qualcuno lascia il progetto.

KPI

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

KPI (Key Performance Indicator) è una metrica quantificabile usata per valutare il successo di un’attività, un progetto o un’organizzazione rispetto a obiettivi predefiniti. Nel contesto del lavoro da remoto, i KPI sostituiscono la presenza fisica come indicatore di produttività.

Come funziona #

Un KPI efficace è specifico, misurabile e legato a un obiettivo concreto. Nella consulenza IT: ticket chiusi, codice rilasciato, SLA rispettati, clienti soddisfatti. Non “ore alla scrivania” — perché le ore non misurano il valore prodotto, misurano solo il tempo trascorso.

Least Privilege

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

Il Least Privilege (principio del privilegio minimo) è un principio fondamentale della sicurezza informatica: ogni utente, processo o sistema deve avere solo i permessi strettamente necessari per svolgere la propria funzione, niente di più.

Come funziona #

In ambito database, il principio si applica assegnando privilegi granulari: SELECT se l’utente deve solo leggere, SELECT + INSERT + UPDATE se deve anche scrivere, mai ALL PRIVILEGES se non strettamente necessario. Combinato con il modello utente@host di MySQL, il principio può essere applicato anche in base all’origine della connessione.

Lift-and-Shift

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

Lift-and-Shift (rehosting) è una strategia di migrazione che consiste nello spostare un sistema da un ambiente all’altro — tipicamente da on-premise a cloud — senza modificarne l’architettura, il codice applicativo o la configurazione. Si prende il sistema così com’è e lo si “solleva e sposta”.

Come funziona #

L’infrastruttura viene replicata nell’ambiente di destinazione: stesse macchine virtuali, stessi database, stessi middleware. Il vantaggio è la velocità: non c’è riscrittura del codice, non c’è redesign architetturale. Il rischio è portarsi dietro tutti i problemi dell’ambiente originale, incluse inefficienze e debito tecnico.

Local Index

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

Un Local Index è un indice Oracle creato su una tabella partizionata, che viene automaticamente partizionato con la stessa chiave e gli stessi limiti della tabella. Ogni partizione della tabella ha una corrispondente partizione di indice.

Come funziona #

Quando si crea un indice con la clausola LOCAL, Oracle crea una partizione di indice per ogni partizione della tabella. Se la tabella ha 100 partizioni mensili, l’indice avrà 100 partizioni corrispondenti. Le operazioni DDL su una partizione (DROP, TRUNCATE, SPLIT) invalidano solo la partizione di indice corrispondente, non l’intero indice.

MERGE

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

MERGE è un’istruzione SQL che combina le operazioni di INSERT e UPDATE (e opzionalmente DELETE) in un unico statement. Se il record esiste lo aggiorna, se non esiste lo inserisce. È spesso chiamata informalmente “upsert”.

Sintassi Oracle #

MERGE INTO tabella_destinazione d
USING tabella_sorgente s ON (d.chiave = s.chiave)
WHEN MATCHED THEN UPDATE SET
 d.campo = s.campo
WHEN NOT MATCHED THEN INSERT (chiave, campo)
 VALUES (s.chiave, s.campo);

Uso nel data warehouse #

Nel contesto ETL, il MERGE è il meccanismo base per caricare le tabelle dimensionali:

Mobilità Sostenibile

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

La Mobilità Sostenibile è un approccio ai trasporti urbani che privilegia l’uso di mezzi a basso impatto ambientale — bicicletta, trasporto pubblico, veicoli elettrici, car sharing — rispetto all’auto privata a combustione interna.

Come funziona #

Si basa su un cambio di paradigma: invece di costruire più strade per più auto, si investe in infrastrutture ciclabili, trasporto pubblico efficiente e incentivi per la mobilità attiva. Città come Amsterdam, Copenhagen e Monaco dimostrano che il modello funziona su larga scala.

MVCC

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

MVCC (Multi-Version Concurrency Control) è il modello di concorrenza usato da PostgreSQL per gestire l’accesso simultaneo ai dati. Ogni UPDATE crea una nuova versione della riga e segna la vecchia come “morta”; ogni DELETE marca la riga come non più visibile. Le letture non bloccano le scritture e viceversa.

Come funziona #

Ogni transazione vede uno snapshot consistente del database al momento del suo inizio. Le righe modificate da altre transazioni non ancora committate sono invisibili. Questo elimina la necessità di lock esclusivi sulle letture, permettendo alta concorrenza — ma genera “spazzatura” sotto forma di dead tuples che devono essere puliti dal VACUUM.

mydumper

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

mydumper è un tool open source di backup logico per MySQL e MariaDB che implementa il parallelismo reale: non solo tra tabelle diverse, ma anche all’interno della stessa tabella, dividendola in chunk basati sulla primary key.

Come funziona #

mydumper si connette al server MySQL, acquisisce una snapshot consistente con FLUSH TABLES WITH READ LOCK (o --trx-consistency-only per evitare lock globali su InnoDB), poi distribuisce il lavoro tra thread multipli. Ogni tabella grande viene spezzata in chunk — per default basati sui range della primary key — e ogni chunk viene esportato da un thread separato.

mysqlbinlog

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

mysqlbinlog è l’utility da riga di comando fornita con MySQL per leggere e decodificare il contenuto dei file binary log. È l’unico strumento in grado di convertire il formato binario dei binlog in output leggibile o in istruzioni SQL rieseguibili.

Come funziona #

mysqlbinlog legge i file binlog e produce output in formato testo. Supporta diversi filtri:

Per intervallo temporale: --start-datetime e --stop-datetime per limitare l’output a una finestra temporale
Per database: --database per filtrare gli eventi di un database specifico
Per posizione: --start-position e --stop-position per selezionare eventi specifici

Con il formato ROW, il flag --verbose decodifica le modifiche riga per riga in formato pseudo-SQL commentato, altrimenti l’output è un blob binario illeggibile.

mysqldump

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

mysqldump è l’utility di backup logico inclusa di serie in ogni installazione di MySQL e MariaDB. Produce un file SQL contenente tutte le istruzioni (CREATE TABLE, INSERT) necessarie per ricostruire completamente schema e dati di un database.

Come funziona #

mysqldump si connette al server MySQL e legge le tabelle una alla volta, generando le istruzioni SQL corrispondenti in output. L’operazione è rigorosamente single-threaded: una tabella dopo l’altra, una riga dopo l’altra. Il file prodotto può essere compresso esternamente (gzip, zstd) ma lo strumento stesso non offre compressione nativa.

mysqlpump

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

mysqlpump è l’utility di backup logico introdotta da Oracle in MySQL 5.7 come evoluzione di mysqldump. La differenza principale è il supporto per il parallelismo a livello di tabella e la compressione nativa dell’output (zlib, lz4, zstd).

Come funziona #

mysqlpump può dumpare più tabelle contemporaneamente usando thread paralleli, configurabili con --default-parallelism. La compressione viene applicata direttamente durante il dump, senza bisogno di pipe esterne verso gzip. Supporta anche il dump selettivo di utenti e account MySQL.

Nested Loop

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

Nested loop è la strategia di join più semplice: per ogni riga della tabella esterna, il database cerca le righe corrispondenti nella tabella interna. Funziona come un doppio ciclo for annidato — da qui il nome.

Come funziona #

L’optimizer sceglie una tabella come “esterna” (outer) e una come “interna” (inner). Per ogni riga della tabella esterna, esegue una ricerca nella tabella interna sulla colonna di join. Se la tabella interna ha un indice sulla colonna di join, ogni ricerca è un accesso diretto via B-tree. Senza indice, ogni ricerca diventa un sequential scan completo.

NOLOGGING

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

NOLOGGING è una modalità Oracle che disabilita la generazione di redo log durante operazioni di caricamento massivo. Le operazioni completano molto più velocemente, ma i dati non sono recuperabili tramite redo in caso di crash prima di un backup.

Come funziona #

Quando un segmento (tabella, indice, partizione) è in modalità NOLOGGING, le operazioni bulk come CTAS, INSERT /*+ APPEND */ e ALTER TABLE MOVE non scrivono redo log per i blocchi dati. Su una copia di 380 GB, questo elimina la generazione di altrettanti GB di redo, evitando di saturare l’area di archivelog e riducendo i tempi da giorni a ore.

Object Privilege

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

Un Object Privilege in Oracle è un’autorizzazione che permette di eseguire operazioni su un oggetto specifico del database: una tabella, una vista, una sequenza o una procedura PL/SQL. Esempi tipici includono SELECT ON schema.tabella, INSERT ON schema.tabella e EXECUTE ON schema.procedura.

Come funziona #

Gli object privileges si assegnano con GRANT specificando l’operazione e l’oggetto target: GRANT SELECT ON app_owner.clienti TO srv_report. Possono essere assegnati a singoli utenti o a ruoli. A differenza dei system privileges, operano su un singolo oggetto e non conferiscono poteri globali sul database.

OCI

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

OCI (Oracle Cloud Infrastructure) è la piattaforma cloud di Oracle, lanciata nella sua seconda generazione nel 2018. A differenza di altri cloud provider, OCI è progettata nativamente per i workload Oracle Database e offre vantaggi significativi in termini di licensing e performance.

Perché OCI per Oracle Database #

Il vantaggio principale riguarda il licensing. Su OCI, Oracle riconosce le proprie OCPU (Oracle CPU) con un rapporto 1:1 ai fini del conteggio delle licenze. Su altri cloud provider come AWS o Azure, il rapporto vCPU-licenze è meno favorevole e il rischio di audit è concreto.

OLAP

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

OLAP (Online Analytical Processing) indica un approccio all’elaborazione dei dati orientato all’analisi multidimensionale: aggregazioni, drill-down, confronti temporali, slice-and-dice su grandi volumi di dati storici.

OLAP vs OLTP #

Caratteristica	OLAP	OLTP
Scopo	Analisi e reporting	Transazioni operative
Modello dati	Star schema, denormalizzato	3NF, normalizzato
Query tipica	Aggregazioni su milioni di righe	Lettura/scrittura di poche righe
Utenti	Analisti, management	Applicazioni, operatori
Aggiornamento	Batch (ETL periodico)	Real-time

Operazioni OLAP #

Le operazioni fondamentali dell’analisi OLAP sono:

Outsourcing

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

L’Outsourcing è la pratica di affidare lo sviluppo, la manutenzione o la gestione di sistemi IT a fornitori esterni all’azienda. Può riguardare progetti completi (sviluppo di un software custom) o servizi continuativi (gestione dell’infrastruttura, supporto applicativo).

Come funziona #

L’azienda cliente definisce i requisiti e stipula un contratto con un fornitore esterno che si impegna a realizzare il progetto. I modelli contrattuali più comuni sono: a corpo (prezzo fisso per risultato definito), a tempo e materiali (giornate-uomo fatturate), o ibridi. Il fornitore mette a disposizione un team di consulenti che lavorano sul progetto, spesso con rotazione periodica del personale.

Parking Lot

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

Il Parking Lot è una lista visibile — su una lavagna, un documento condiviso o la chat — dove il facilitatore annota gli argomenti che emergono durante una riunione ma che non possono essere discussi nel tempo disponibile. Gli argomenti vengono “parcheggiati” e affrontati dopo la riunione con le sole persone coinvolte.

Come funziona #

Quando durante uno standup qualcuno solleva un problema complesso, il facilitatore dice: “Lo segno nel parking lot, ne parliamo dopo.” L’argomento non viene ignorato — viene solo spostato nel contesto giusto, dove può essere affrontato senza far perdere tempo a chi non è coinvolto.

Partita IVA

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

La Partita IVA è il codice di identificazione fiscale assegnato ai lavoratori autonomi e alle imprese in Italia per le operazioni soggette a IVA. Nella consulenza IT, “lavorare a partita IVA” significa operare come libero professionista, fatturando i propri servizi direttamente al cliente.

Come funziona #

Il consulente a partita IVA emette fattura al cliente al termine del periodo di lavoro. Il pagamento avviene secondo i termini contrattuali — che in Italia sono tipicamente 60-90-120 giorni fine mese. Nel frattempo, il consulente sostiene tutte le spese (contributi INPS, tasse, affitto, utenze) con liquidità propria.

Partition Pruning

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

Il Partition Pruning è il meccanismo con cui Oracle, durante l’esecuzione di una query su una tabella partizionata, identifica ed esclude automaticamente le partizioni che non possono contenere dati rilevanti per il predicato della query.

Come funziona #

Quando una query include un predicato sulla colonna di partizione (es. WHERE data_movimento BETWEEN ...), Oracle consulta i metadati delle partizioni e determina quali partizioni contengono dati nell’intervallo richiesto. Solo quelle partizioni vengono lette. Nel piano di esecuzione appare come PARTITION RANGE SINGLE o PARTITION RANGE ITERATOR.

Pedalata Assistita

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

La Pedalata Assistita è un sistema di propulsione elettrica montato su una bicicletta che amplifica la forza della pedalata del ciclista tramite un motore elettrico. Il motore si attiva solo quando si pedala e si disattiva sopra i 25 km/h (limite europeo).

Come funziona #

Un sensore rileva la forza e la cadenza della pedalata e attiva il motore elettrico proporzionalmente. Più pedali forte, più il motore aiuta. Il risultato è che salite come il Celio a Roma diventano un leggero dosso, e si arriva a destinazione senza sudare — un dettaglio cruciale per chi deve presentarsi in ufficio.

Pendolarismo

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

Il Pendolarismo (commuting) è lo spostamento quotidiano tra casa e luogo di lavoro. Nelle grandi città italiane come Roma, il pendolarismo medio assorbe 2-4 ore al giorno, con costi diretti (carburante, parcheggio, mezzi pubblici) e indiretti (stress, stanchezza, produttività persa).

Come funziona #

Un consulente IT che vive a 30 km dall’ufficio a Roma può impiegare 1h15-2h30 solo per l’andata. Su 220 giorni lavorativi, sono 47-89 ore perse al mese — fino a due settimane lavorative passate in auto senza produrre nulla.

pg_stat_statements

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

pg_stat_statements è un’estensione di PostgreSQL — inclusa nella distribuzione ufficiale ma non attiva di default — che tiene traccia delle statistiche di esecuzione di tutte le query SQL che passano dal server. Le query vengono normalizzate (i valori letterali sostituiti con parametri) per raggruppare le esecuzioni dello stesso pattern.

Come funziona #

L’estensione richiede di essere caricata come shared library all’avvio del server tramite il parametro shared_preload_libraries. Una volta attiva, registra per ogni query: numero di esecuzioni, tempo totale e medio, righe restituite, blocchi letti da disco e da cache. Il parametro pg_stat_statements.max controlla quante query distinte vengono tracciate (default 5000).

pg_trgm

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

pg_trgm è un’estensione di PostgreSQL che implementa la ricerca basata su trigrammi — sequenze di tre caratteri consecutivi estratte dal testo. Abilita l’uso di indici GIN e GiST per accelerare ricerche LIKE '%valore%' e ILIKE, che altrimenti richiederebbero scansioni sequenziali.

Come funziona #

L’estensione scompone ogni stringa in trigrammi: ad esempio, “hello” diventa {" h", " he", “hel”, “ell”, “llo”, “lo “}. Un indice GIN con operator class gin_trgm_ops indicizza questi trigrammi. Quando si esegue un LIKE '%ell%', PostgreSQL cerca i trigrammi corrispondenti nell’indice invece di scansionare l’intera tabella.

PITR

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

PITR (Point-in-Time Recovery) è una tecnica di ripristino che permette di riportare un database a un qualsiasi momento nel tempo, non solo al momento del backup. Si basa sulla combinazione di un backup completo e dei log delle transazioni (binary log in MySQL, WAL in PostgreSQL, redo log in Oracle).

Come funziona #

Il processo si articola in due fasi:

Presenteismo

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

Il Presenteismo è la cultura organizzativa che misura il valore del lavoro in base alla presenza fisica del dipendente in ufficio, indipendentemente dalla qualità e quantità dei risultati prodotti. È il presupposto che “se ti vedo alla scrivania, stai lavorando.”

Come funziona #

In un’organizzazione presenteista, essere in ufficio dalle 9 alle 18 è più importante di chiudere i task. Arrivare tardi è un problema anche se hai prodotto più di tutti. Lavorare da casa è sospetto anche se i risultati sono eccellenti. Il controllo si basa sulla vista, non sulle metriche.

Pull Request

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

Una Pull Request (PR) è una richiesta formale di incorporare le modifiche da un branch di sviluppo nel branch principale del repository. È il meccanismo centrale di collaborazione su GitHub e piattaforme simili.

Come funziona #

Lo sviluppatore lavora su un branch dedicato (es. fix/issue-234-errore-calcolo), completa le modifiche, e apre una PR. La PR mostra il diff del codice, permette ai colleghi di commentare riga per riga, richiedere modifiche o approvare. Solo dopo l’approvazione il codice viene unito (merged) nel branch principale. Questo garantisce che il codice “buono” resti sempre buono.

Quorum

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

Il quorum è il numero minimo di nodi che devono essere d’accordo per considerare il cluster operativo. In un cluster a 3 nodi, il quorum è 2 (la maggioranza). Se un nodo si disconnette, gli altri due riconoscono di essere la maggioranza e continuano a operare normalmente.

Come funziona #

Galera Cluster utilizza un protocollo di comunicazione di gruppo che verifica continuamente quanti nodi sono raggiungibili. Il calcolo è semplice: quorum = (numero totale nodi / 2) + 1. Con 3 nodi il quorum è 2, con 5 nodi è 3. I nodi che perdono il quorum passano allo stato Non-Primary e rifiutano le scritture per evitare inconsistenze.

RAC

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

RAC (Real Application Clusters) è la tecnologia Oracle che consente a più istanze del database di accedere contemporaneamente allo stesso storage condiviso. Se un nodo si guasta, gli altri continuano a servire le richieste senza interruzione — il failover è trasparente per le applicazioni.

Come funziona #

Un cluster RAC è composto da due o più server (nodi) collegati tra loro da una rete privata ad alta velocità (interconnect) e da uno storage condiviso (tipicamente ASM — Automatic Storage Management). Ogni nodo esegue la propria istanza Oracle, ma tutti accedono agli stessi datafile.

Ragged hierarchy

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

Una ragged hierarchy (gerarchia sbilanciata) è una struttura gerarchica in cui non tutti i rami raggiungono la stessa profondità. Alcuni livelli intermedi sono assenti per determinate entità.

Esempio concreto #

In una gerarchia a tre livelli Top Group → Group → Client:

Alcuni clienti hanno tutti e tre i livelli (gerarchia completa)
Alcuni clienti hanno un Group ma nessun Top Group
Alcuni clienti non hanno né Group né Top Group (clienti diretti)

Il risultato è una struttura con “buchi” che causa problemi nei report di aggregazione: righe con NULL, totali spezzati, drill-down incompleti.

Range Partitioning

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

Il Range Partitioning (partizionamento per intervallo) è una strategia di partizionamento delle tabelle in cui le righe vengono distribuite in partizioni diverse in base al valore di una colonna rispetto a intervalli predefiniti. La colonna di partizionamento è quasi sempre una data nei data warehouse.

Come funziona #

Ogni partizione è definita con una clausola VALUES LESS THAN che stabilisce il limite superiore dell’intervallo. Oracle assegna automaticamente ogni riga alla partizione corretta in base al valore della colonna di partizionamento. Se una riga ha data_vendita = '2025-03-15', viene inserita nella partizione il cui intervallo include quella data.

Redo Log

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

Redo Log è il meccanismo con cui Oracle registra ogni modifica ai dati del database (INSERT, UPDATE, DELETE, DDL) prima che venga scritta definitivamente nei datafile. È la garanzia fondamentale di durabilità delle transazioni.

Come funziona #

Oracle scrive le modifiche nei redo log online in modo sequenziale e continuo. I redo log sono organizzati in gruppi circolari: quando un gruppo si riempie, Oracle passa al successivo. Quando tutti i gruppi sono stati usati, Oracle torna al primo (log switch).

Relay log

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

Il relay log è un file di log intermedio presente sullo slave in un’architettura di replica MySQL. Contiene gli eventi ricevuti dal binary log del master, in attesa di essere eseguiti localmente dal thread SQL dello slave.

Come funziona #

Il flusso della replica MySQL passa attraverso il relay log in tre fasi:

L’I/O thread dello slave si connette al master e legge i binary log
Gli eventi ricevuti vengono scritti nel relay log locale
Il SQL thread dello slave legge gli eventi dal relay log e li esegue sul database locale

Questa architettura a due thread permette di disaccoppiare la ricezione dei dati dalla loro applicazione: lo slave può continuare a ricevere eventi dal master anche se l’esecuzione locale è temporaneamente rallentata.

REVOKE

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

REVOKE è il comando SQL che rimuove privilegi o ruoli precedentemente assegnati con GRANT. È il complemento indispensabile del GRANT e lo strumento principale per restringere i permessi quando un modello di sicurezza viene ristrutturato.

Come funziona #

La sintassi segue lo stesso schema del GRANT: REVOKE SELECT ON schema.tabella FROM utente oppure REVOKE ruolo FROM utente. In Oracle, revocare un ruolo come DBA rimuove in un colpo solo tutti i system privileges inclusi in quel ruolo. Prima di eseguire un REVOKE critico, è fondamentale verificare che l’utente mantenga i privilegi necessari per le sue funzioni.

RMAN

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

RMAN (Recovery Manager) è lo strumento nativo di Oracle per il backup, il restore e il recovery del database. È un’utility a riga di comando che gestisce tutte le operazioni di protezione dei dati in modo integrato con il database.

Cosa fa #

Backup: completi, incrementali, dei soli archived log
Restore: ripristino di datafile, tablespace o dell’intero database
Recovery: applicazione dei redo log per portare il database a un punto nel tempo specifico
Duplicate: creazione di copie del database, inclusi database standby per Data Guard

RMAN e Data Guard #

Per la creazione di un database standby, RMAN permette il DUPLICATE ... FOR STANDBY FROM ACTIVE DATABASE — una copia diretta via rete dal primario allo standby, senza bisogno di backup intermedi su nastro o disco. Il comando trasferisce tutti i datafile, i controlfile e li configura automaticamente per la replica.

ROI

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

Il ROI (Return on Investment) è la metrica che misura il rendimento di un investimento rapportando il beneficio netto al costo sostenuto, espresso come percentuale. Un ROI del 200% significa che ogni euro investito ne ha generati due di ritorno.

Come funziona #

Si calcola come: (Beneficio - Costo) / Costo × 100. Nel contesto dei progetti IT con componenti AI, il calcolo del ROI deve includere non solo i costi di implementazione ma anche quelli di manutenzione, training del team, governance e gestione degli errori del modello.

ROLE

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

In PostgreSQL, ROLE è l’unica entità di sicurezza. Non esiste una distinzione tra “utente” e “ruolo”: tutto è un ROLE. Un ROLE con l’attributo LOGIN si comporta come un utente; senza LOGIN, è un contenitore di privilegi assegnabile ad altri ROLE.

Come funziona #

CREATE USER mario è semplicemente uno shortcut per CREATE ROLE mario WITH LOGIN. I ROLE possono possedere oggetti, ereditare privilegi da altri ROLE tramite l’attributo INHERIT, e essere utilizzati per costruire gerarchie di permessi. Un ROLE “funzionale” (senza LOGIN) raggruppa i privilegi; i ROLE “utente” (con LOGIN) li ereditano.

RPO

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

RPO (Recovery Point Objective) è la quantità massima di dati che un’organizzazione può permettersi di perdere in caso di guasto o disastro. Si misura in tempo: un RPO di 1 ora significa che si accetta di perdere al massimo l’ultima ora di transazioni.

Come si determina #

L’RPO dipende dalla strategia di backup e replica:

Strategia	RPO tipico
Backup notturno su nastro	12-24 ore
Backup + archived log su storage remoto	1-4 ore
Data Guard asincrono (MaxPerformance)	Pochi secondi
Data Guard sincrono (MaxAvailability)	Zero

RPO vs RTO #

RPO e RTO sono complementari ma distinti:

RTO

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

RTO (Recovery Time Objective) è il tempo massimo accettabile per ripristinare il servizio dopo un guasto o un disastro. Si misura dal momento del guasto al momento in cui il sistema torna operativo.

Come si determina #

L’RTO dipende dalla strategia di recovery e dall’infrastruttura disponibile:

Strategia	RTO tipico
Restore da backup su nastro	4-12 ore
Restore da backup su disco	1-4 ore
Data Guard con switchover manuale	1-5 minuti
Data Guard con Fast-Start Failover	10-30 secondi

RTO vs RPO #

RTO: quanto tempo ci vuole per ripartire (guarda avanti)
RPO: quanti dati puoi perdere (guarda indietro)

Sono metriche indipendenti. Un restore da backup può avere RTO=2 ore e RPO=24 ore. Un Data Guard sincrono può avere RTO=30 secondi e RPO=0.

SCAN Listener

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

Lo SCAN Listener (Single Client Access Name) è il componente di Oracle RAC che fornisce un unico nome DNS per l’accesso al cluster. Le applicazioni si connettono allo SCAN name senza dover conoscere i singoli nodi: il listener distribuisce automaticamente le connessioni tra i nodi attivi.

Come funziona #

Lo SCAN è un nome DNS che risolve a tre indirizzi IP virtuali (VIP), distribuiti tra i nodi del cluster. Quando un client si connette allo SCAN name, il DNS restituisce uno dei tre IP, e il listener su quell’IP redirige la connessione al nodo più appropriato in base al servizio richiesto e al carico.

SCD

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

SCD (Slowly Changing Dimension) indica un insieme di tecniche usate nel data warehouse per gestire i cambiamenti nei dati delle tabelle dimensionali nel corso del tempo.

I tipi principali #

Tipo 1: sovrascrittura del valore precedente. Nessuna storia conservata
Tipo 2: inserimento di una nuova riga con date di validità (data inizio, data fine). Conserva tutta la storia
Tipo 3: aggiunta di una colonna per il valore precedente. Conserva solo l’ultimo cambiamento

Perché serve #

In un database transazionale, quando un cliente cambia indirizzo si aggiorna il record. In un data warehouse questo significherebbe perdere la storia: tutte le vendite precedenti risulterebbero associate al nuovo indirizzo.

Schema

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

Uno Schema in un database relazionale è un namespace logico che raggruppa oggetti come tabelle, viste, funzioni e sequenze. Funziona come un contenitore organizzativo all’interno di un database.

Come funziona #

In PostgreSQL, lo schema predefinito è public. Per accedere a un oggetto in un altro schema serve il prefisso: schema1.tabella. Il privilegio USAGE su uno schema è prerequisito per accedere a qualsiasi oggetto al suo interno — senza USAGE, nemmeno un GRANT SELECT sulle tabelle funziona.

Scope

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

Lo Scope (ambito) di un progetto definisce il perimetro di ciò che il progetto deve realizzare: funzionalità incluse, deliverable attesi, vincoli e confini concordati con gli stakeholder. Tutto ciò che è dentro lo scope si fa; tutto ciò che è fuori, no.

Come funziona #

Lo scope viene definito nelle fasi iniziali del progetto attraverso documenti come lo Statement of Work o il Project Charter. Ogni richiesta di modifica successiva deve passare attraverso un processo formale di change management per valutarne l’impatto su tempi, costi e risorse.

Scope Creep

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

Lo Scope Creep è l’espansione progressiva e spesso non controllata dell’ambito di un progetto rispetto a quanto definito inizialmente. Nuovi requisiti, modifiche alle specifiche e funzionalità aggiuntive si accumulano senza un corrispondente adeguamento di budget e tempistiche.

Come funziona #

In un progetto software, lo scope creep inizia tipicamente con richieste apparentemente piccole: “aggiungiamo anche questo campo”, “sarebbe utile anche questa funzione”. Ogni singola modifica sembra ragionevole, ma l’effetto cumulativo è devastante. Le specifiche diventano un bersaglio mobile, il team non riesce mai a raggiungere una baseline stabile, e il progetto entra in un ciclo infinito di revisioni.

Scrum

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

Scrum è un framework agile per la gestione di progetti che organizza il lavoro in iterazioni a durata fissa chiamate sprint (tipicamente 2 settimane). Definisce tre ruoli (Product Owner, Scrum Master, Development Team) e quattro cerimonie (Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective).

Come funziona #

Ogni sprint inizia con una pianificazione, prosegue con standup quotidiani per la sincronizzazione, e termina con una review (cosa è stato fatto) e una retrospettiva (come migliorare il processo). Il timebox è il principio fondamentale: ogni cerimonia ha una durata massima non negoziabile.

secure-file-priv

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

secure-file-priv è una variabile di sistema MySQL che controlla dove le istruzioni LOAD DATA INFILE, SELECT INTO OUTFILE e la funzione LOAD_FILE() possono operare sul filesystem del server.

Come funziona #

La variabile accetta tre valori: un percorso specifico (es. /var/lib/mysql-files/), che limita le operazioni su file a quella directory; una stringa vuota (""), che non impone alcuna restrizione; oppure NULL, che disabilita completamente le operazioni su file. Il valore è impostabile solo nel file di configurazione (my.cnf) e richiede un riavvio del servizio per essere modificato — non è cambiabile a runtime.

Self-parenting

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

Il self-parenting è una tecnica di dimensional modeling usata per bilanciare le gerarchie sbilanciate (ragged hierarchies). Il principio è semplice: un’entità che non ha un livello gerarchico superiore diventa il proprio genitore a quel livello.

Come funziona #

In una gerarchia a tre livelli Top Group → Group → Client:

Un Client senza Group usa il proprio nome/ID come Group
Un Group senza Top Group usa il proprio nome/ID come Top Group

Il risultato è una tabella dimensionale senza NULL nelle colonne gerarchiche, con tutti i livelli sempre popolati.

Sequential Scan

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

Il Sequential Scan (Seq Scan) è l’operazione con cui PostgreSQL legge una tabella dall’inizio alla fine, blocco per blocco, senza utilizzare alcun indice. È l’equivalente PostgreSQL del Full Table Scan di Oracle.

Quando è normale #

Su tabelle piccole (poche migliaia di righe), il sequential scan è spesso la scelta più efficiente. Leggere una tabella intera in sequenza è più veloce che fare lookup su un indice quando la tabella sta in poche pagine. L’optimizer sceglie il sequential scan quando stima che sia più economico di un index scan.

SGA

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

La SGA (System Global Area) è l’area di memoria condivisa principale di Oracle Database. Contiene le strutture dati fondamentali: buffer cache (pagine dati lette da disco), shared pool (piani di esecuzione e dizionario dati), redo log buffer e large pool.

Come funziona #

La dimensione della SGA è controllata dal parametro SGA_TARGET o SGA_MAX_SIZE. Oracle alloca la SGA all’avvio dell’istanza in memoria condivisa del sistema operativo. I parametri kernel Linux shmmax e shmall devono essere dimensionati per permettere l’allocazione completa della SGA.

shared_buffers

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

shared_buffers è il parametro che controlla la dimensione dell’area di memoria condivisa usata da PostgreSQL come cache per i blocchi dati letti dal disco. Ogni volta che PostgreSQL legge una pagina dati (8 KB), la conserva in shared_buffers per le letture successive.

Come funziona #

PostgreSQL alloca la memoria per shared_buffers all’avvio del servizio. Tutti i processi backend condividono questa area di memoria. Quando un processo ha bisogno di un blocco dati, cerca prima in shared_buffers. Se lo trova (cache hit), la lettura è immediata. Se non lo trova (cache miss), deve leggere dal disco — un’operazione ordini di grandezza più lenta.

Single-primary

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

Single-primary è la modalità operativa più comune di MySQL Group Replication, in cui un solo nodo del cluster — il primary — accetta operazioni di scrittura. Gli altri nodi (secondary) sono in sola lettura (read_only=ON, super_read_only=ON) e ricevono le modifiche tramite la replica sincrona del gruppo.

Come funziona #

Il parametro group_replication_single_primary_mode=ON attiva questa modalità. Il primary è l’unico nodo con read_only=OFF. Se il primary viene fermato o diventa irraggiungibile, il cluster esegue un’elezione automatica e uno dei secondary diventa il nuovo primary in pochi secondi.

Smart Working

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

Lo Smart Working (lavoro agile) è un modello organizzativo che permette al dipendente di lavorare da qualsiasi luogo, combinando giornate in ufficio e giornate da remoto, con orari flessibili e valutazione basata sui risultati invece che sulla presenza.

Come funziona #

Il modello tipico è 80/20: 80% remoto, 20% in presenza. I giorni in ufficio servono per workshop, review di progetto e team building — non per scaldare la sedia. L’azienda fornisce attrezzatura per la postazione domestica (monitor, sedia ergonomica, cuffie) e un contributo per la connettività.

Snapshot (Oracle)

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

Snapshot in Oracle è un’istantanea delle statistiche di performance del database catturata in un preciso momento e conservata nel repository AWR. Di default Oracle genera uno snapshot ogni 60 minuti e li conserva per 8 giorni.

Come funziona #

Ogni snapshot registra centinaia di metriche: wait event, statistiche SQL, metriche di memoria (SGA, PGA), I/O per datafile, statistiche di sistema. Il confronto tra due snapshot genera il report AWR, che mostra cosa è cambiato tra i due istanti.

Split-brain

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

Lo split-brain è una condizione critica che si verifica quando un cluster database si divide in due o più partizioni che non possono comunicare tra loro, e ciascuna partizione continua ad accettare scritture indipendentemente. Il risultato sono dati divergenti impossibili da riconciliare automaticamente.

Come funziona #

In un cluster a 3 nodi, se la rete tra il Nodo 1 e i Nodi 2-3 si interrompe, senza protezione dal quorum entrambe le parti potrebbero continuare ad accettare scritture. Quando la rete si ripristina, il cluster si troverebbe con due versioni diverse degli stessi dati. Il meccanismo di quorum previene questo scenario: solo la partizione con la maggioranza dei nodi (quorum) può continuare ad operare.

SQL Injection

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

La SQL Injection è una delle vulnerabilità più diffuse e pericolose nelle applicazioni web. Si verifica quando input forniti dall’utente vengono inseriti direttamente nelle query SQL senza validazione o parametrizzazione, permettendo a un attaccante di modificare la logica della query.

Come funziona #

L’attaccante inserisce frammenti di codice SQL nei campi di input dell’applicazione (form di login, campi di ricerca, parametri URL). Se l’applicazione concatena questi input direttamente nelle query SQL, il codice malevolo viene eseguito dal database con i privilegi dell’utente applicativo. In combinazione con il privilegio FILE di MySQL e un secure-file-priv non configurato, l’attaccante può leggere file di sistema o scrivere file arbitrari sul server.

SST

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

SST (State Snapshot Transfer) è il meccanismo con cui un nodo Galera che si unisce al cluster (o che è rimasto offline troppo a lungo) riceve una copia completa dell’intero dataset da un nodo donatore.

Come funziona #

Quando un nodo si unisce al cluster e il gap di transazioni mancanti supera la dimensione del gcache, il cluster avvia un SST. Il nodo donatore crea un’istantanea completa del database e la trasferisce al nodo ricevente. I metodi disponibili sono: mariabackup (non blocca il donatore), rsync (veloce ma blocca il donatore in lettura), e mysqldump (lento e bloccante).

Stakeholder

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

Uno Stakeholder è qualsiasi persona, gruppo o organizzazione che ha un interesse diretto o indiretto nel risultato di un progetto. Include committenti, sponsor, utenti finali, team di sviluppo, management e fornitori esterni.

Come funziona #

Nel project management, gli stakeholder vengono identificati, classificati per livello di influenza e interesse, e gestiti con strategie di comunicazione differenziate. Uno stakeholder ad alta influenza e alto interesse (come il CTO) richiede coinvolgimento attivo; uno a bassa influenza richiede solo aggiornamenti periodici.

Star schema

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

Lo star schema (schema a stella) è il modello di dati più usato nel data warehouse. Prende il nome dalla sua forma: una tabella centrale dei fatti (fact table) collegata a più tabelle dimensionali che le stanno intorno, come i raggi di una stella.

Struttura #

Fact table al centro: contiene le misure numeriche e le foreign key verso le dimensioni
Dimension tables intorno: contengono gli attributi descrittivi (chi, cosa, dove, quando) con struttura denormalizzata

Le dimensioni nello star schema sono tipicamente denormalizzate — tutti gli attributi in una sola tabella piatta, senza gerarchie normalizzate. Questo semplifica le query e migliora le performance delle aggregazioni.

Swappiness

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

La Swappiness (vm.swappiness) è un parametro del kernel Linux che controlla quanto aggressivamente il sistema sposta pagine di memoria dalla RAM allo swap su disco. Il valore va da 0 (swap solo in caso estremo) a 100 (swap aggressivo). Il default è 60.

Come funziona #

Con il valore di default 60, Linux inizia a swappare quando la pressione sulla memoria è ancora relativamente bassa. Per un server database dedicato, questo è inaccettabile: l’SGA deve restare in RAM, sempre. Il valore raccomandato per Oracle è 1 — non 0, che disabiliterebbe completamente lo swap e potrebbe causare OOM killer.

Switchover

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

Lo switchover è un’operazione pianificata di Oracle Data Guard che inverte i ruoli tra il database primary e lo standby. Il primary diventa standby, lo standby diventa primary. Nessun dato viene perso, nessuna transazione va in errore — è un passaggio pulito e controllato.

Switchover vs Failover #

La distinzione è fondamentale:

	Switchover	Failover
Quando	Pianificato (manutenzione, migrazione)	Emergenza (guasto del primary)
Perdita dati	Zero	Possibile (dipende dalla modalità)
Reversibilità	Sì, con un altro switchover	No, lo standby diventa primary in modo permanente
Tempo	Minuti (tipicamente 1-3)	Secondi-minuti

Come si esegue #

Con Data Guard Broker, lo switchover è un singolo comando:

System Privilege

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

Un System Privilege in Oracle è un’autorizzazione che permette di eseguire operazioni globali sul database, indipendentemente da uno specifico oggetto. Esempi tipici includono CREATE TABLE, CREATE SESSION, ALTER SYSTEM, CREATE USER e DROP ANY TABLE.

Come funziona #

I system privileges si assegnano con GRANT e si revocano con REVOKE. Possono essere assegnati direttamente a un utente o a un ruolo. Il ruolo predefinito DBA include oltre 200 system privileges, motivo per cui assegnarlo a utenti applicativi è una pratica pericolosa.

systemd

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

systemd è il sistema di init e il gestore dei servizi predefinito nelle distribuzioni Linux moderne (CentOS/RHEL 7+, Ubuntu 16.04+, Debian 8+). In ambito database, è il meccanismo che avvia, ferma e monitora le istanze MySQL o MariaDB.

Come funziona #

Ogni servizio è definito da un file unit (es. mysqld.service) che specifica il comando di avvio, il file di configurazione, le dipendenze e il comportamento in caso di crash. In un setup multi-istanza, si creano unit file separati per ogni istanza (es. mysqld-app2.service, mysqld-reporting.service), ciascuno con il proprio --defaults-file che punta a un my.cnf diverso.

Tablespace

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

Un Tablespace è l’unità logica di organizzazione dello storage in Oracle Database. Ogni tablespace è composto da uno o più datafile fisici sul disco, e ogni oggetto del database (tabella, indice, partizione) risiede in un tablespace.

Come funziona #

Oracle separa la gestione logica (tablespace) da quella fisica (datafile). Un DBA può creare tablespace dedicati per scopi diversi: uno per i dati attivi, uno per gli indici, uno per l’archivio. Questo permette di distribuire il carico I/O su dischi diversi e di applicare politiche di gestione differenziate (es. read-only per i dati storici).

THP

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

Le THP (Transparent Huge Pages) sono una funzione del kernel Linux che promuove automaticamente le pagine di memoria da 4 KB a 2 MB in background, senza configurazione esplicita. A differenza delle Huge Pages statiche, sono gestite dal processo kernel khugepaged.

Come funziona #

Quando attive (default always), il kernel tenta di compattare le pagine normali in pagine grandi in background. Il processo khugepaged lavora continuamente per trovare e unire gruppi di pagine contigue, causando micro-freeze imprevedibili durante le operazioni di compattazione.

Timeboxing

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

Il Timeboxing è una tecnica di gestione del tempo che consiste nell’assegnare un intervallo temporale fisso e non negoziabile a un’attività. Quando il tempo scade, l’attività si chiude — indipendentemente dal fatto che sia stata completata o meno.

Come funziona #

Si definisce la durata massima (15 minuti per uno standup, 1 ora per una riunione di design, 2 settimane per uno sprint) e si rispetta il vincolo. Il timebox forza le persone a concentrarsi sull’essenziale, evitando discussioni infinite e perfezionismo paralizzante.

Transport Lag

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

Il transport lag è il ritardo tra il momento in cui il database primary genera un redo log e il momento in cui quel redo log viene ricevuto dal database standby in una configurazione Oracle Data Guard. È uno degli indicatori più importanti per valutare la salute della replica.

Come si misura #

Il transport lag si monitora con una query sulla vista V$DATAGUARD_STATS o tramite Data Guard Broker:

Unified Audit

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

Unified Audit (Oracle Unified Auditing) è il sistema di audit centralizzato introdotto in Oracle Database 12c che sostituisce i meccanismi di audit tradizionali con un’unica infrastruttura unificata. Tutti gli eventi di audit convergono nella vista UNIFIED_AUDIT_TRAIL.

Come funziona #

Unified Audit si basa su audit policy: regole dichiarative che specificano quali azioni monitorare (DDL, DML, login, operazioni amministrative). Le policy si creano con CREATE AUDIT POLICY, si attivano con ALTER AUDIT POLICY ... ENABLE e possono essere applicate a utenti specifici o globalmente. I record di audit vengono scritti in una coda interna e poi persistiti nella tabella di sistema.

Unix Socket

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

Un Unix Socket (o socket di dominio Unix) è un endpoint di comunicazione che permette a due processi sullo stesso sistema operativo di scambiarsi dati senza passare attraverso lo stack di rete TCP/IP. In ambito MySQL, è il metodo di connessione predefinito quando ci si collega a localhost.

Come funziona #

Quando un client MySQL si connette specificando -h localhost, il client non usa TCP. Usa il file socket Unix (tipicamente /var/run/mysqld/mysqld.sock) per comunicare direttamente con il processo del server MySQL. Questa comunicazione avviene interamente nel kernel, senza overhead di rete, ed è più veloce di una connessione TCP anche sullo stesso host.

VACUUM

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

VACUUM è il comando PostgreSQL che recupera lo spazio occupato dai dead tuples (righe morte) e lo rende disponibile per nuovi inserimenti. Non restituisce spazio al sistema operativo, non riorganizza la tabella e non compatta nulla — segna le pagine come riscrivibili.

Come funziona #

VACUUM tabella scansiona la tabella, identifica i dead tuples non più visibili a nessuna transazione e ne marca lo spazio come riutilizzabile. È un’operazione leggera che non blocca le scritture e può girare in parallelo con le query normali. VACUUM FULL invece riscrive fisicamente l’intera tabella con lock esclusivo — da usare rarissimamente e solo in emergenza.

Vendor Lock-in

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

Il Vendor Lock-in è la situazione in cui un’azienda diventa dipendente da un fornitore esterno al punto che cambiarlo diventa estremamente costoso o tecnicamente complesso. Nel contesto IT, si verifica quando il codice, l’architettura o la conoscenza del sistema sono nelle mani del fornitore e non del cliente.

Come funziona #

Il lock-in si instaura gradualmente: il fornitore scrive il codice con le proprie convenzioni, usa tecnologie proprietarie o non documentate, e il team interno non viene coinvolto nello sviluppo. Quando il fornitore se ne va — per scelta o per licenziamento — porta via con sé il know-how. Il cliente resta con un software che non capisce, non sa manutenere e non può evolvere senza ri-ingaggiare lo stesso fornitore o ricominciare da zero.

Version Control

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

Il Version Control (controllo versione) è un sistema che registra ogni modifica ai file di un progetto, mantenendo una cronologia completa di chi ha cambiato cosa, quando e perché. Git è il sistema di version control più usato al mondo.

Come funziona #

Ogni modifica viene registrata come “commit” con un messaggio descrittivo, un autore e un timestamp. Il sistema mantiene l’intera storia del progetto: è possibile tornare a qualsiasi versione precedente, confrontare versioni diverse e capire l’evoluzione del codice nel tempo. Con Git, ogni sviluppatore ha una copia completa della storia sul proprio computer.

Wait Event

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

Wait Event è un indicatore diagnostico di Oracle Database che identifica il motivo per cui una sessione è in attesa anziché lavorare attivamente. Ogni volta che un processo non può procedere — perché attende un blocco dal disco, un lock, una risposta dalla rete o un turno di CPU — Oracle registra un wait event specifico.

I più comuni #

Wait Event	Significato
`db file sequential read`	Lettura singolo blocco — tipica di accessi via indice
`db file scattered read`	Lettura multi-blocco — tipica di full table scan
`log file sync`	Attesa del commit su redo log
`enq: TX - row lock contention`	Conflitto su lock di riga
`direct path read`	Lettura diretta (bypass buffer cache)

A cosa servono #

I wait event sono la base della metodologia diagnostica Oracle. Analizzando quali eventi dominano il DB time (tramite AWR o ASH) si identifica immediatamente la natura del problema: I/O, contention, CPU o rete.

WSREP

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

WSREP (Write Set Replication) è l’API e il protocollo che Galera Cluster utilizza per la replica sincrona multi-master. Ogni transazione viene catturata come “write set” (insieme di modifiche a livello di riga) e replicata su tutti i nodi del cluster prima del commit.

Come funziona #

Quando un nodo esegue una transazione, WSREP la intercetta al momento del commit, la impacchetta come write set e la invia a tutti i nodi del cluster tramite il protocollo di comunicazione di gruppo. Ogni nodo esegue un processo di certification: verifica che la transazione non sia in conflitto con altre transazioni concorrenti. Se la certification ha successo, tutti i nodi applicano la transazione. Se fallisce, la transazione viene annullata sul nodo che l’ha originata.

Yes-And

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

Yes-And (Sì-E) è una tecnica di comunicazione originaria del teatro di improvvisazione, applicata al project management per trasformare le discussioni conflittuali in conversazioni costruttive. Il principio è semplice: invece di negare la proposta dell’interlocutore con “No, però…”, si accoglie con “Sì, e…” aggiungendo il proprio contributo.

Come funziona #

Quando qualcuno propone un’idea, la risposta “No” attiva una reazione difensiva e blocca la conversazione. La risposta “Sì, e…” riconosce la validità della proposta e la estende, mantenendo il dialogo aperto. Non significa essere d’accordo su tutto — significa costruire sulla proposta dell’altro prima di ridirezionarla.

ZDM

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

ZDM (Zero Downtime Migration) è lo strumento che Oracle fornisce per automatizzare le migrazioni di database Oracle verso OCI (Oracle Cloud Infrastructure) o verso database on-premises di versione superiore. Il nome è un po’ ottimistico — il downtime non è zero, ma è ridotto al minimo.

Come funziona #

ZDM è essenzialmente un orchestratore che combina tecnologie Oracle esistenti sotto un unico flusso automatizzato. Supporta due modalità: