Edizioni, metriche, costi e remediation: la guida per SAM, procurement e IT
Se in azienda gestisci, acquisti o negozi licenze Oracle Database, questa guida ti aiuta a capire come funziona davvero il licensing: dove si nascondono gli sprechi che nessuno controlla finché non è troppo tardi, e come ridurre il rischio di compliance prima che un audit chieda di mettere a budget l’acquisto di nuove licenze a prezzo pieno e con supporto.
Oracle Database è uno dei motori di database (DBMS) più diffusi nelle aziende di ogni dimensione – secondo il DB-Engines Ranking è al primo posto assoluto per popolarità da oltre dieci anni e si conferma tale anche nella classifica di luglio 2026 – ma è anche uno dei prodotti software con il modello di licenza più esposto al rischio di audit, per due ragioni distinte: da un lato la difficoltà di calcolare correttamente il fabbisogno di licenze (metriche, core factor, minimi), dall’altro il rischio che vengano attivate funzionalità non licenziate.
Su quest’ultimo punto: non è raro che un’organizzazione scopra, solo in fase di audit Oracle, di avere attivato – magari per errore o per un test – funzionalità che generano un obbligo di licenza mai preventivato. In questo articolo ripercorriamo la logica delle licenze Oracle Database: edizioni, metriche di licenza, Options e Management Packs, prezzi di listino, rischi tipici e possibili strade di remediation.
La prima cosa da sapere quando si deve licenziare Oracle Database è l’edizione acquistata, cioè la versione del software scelta: questa determina quali funzionalità del motore sono incluse, quali limiti hardware si applicano e come viene calcolata la licenza.
Oggi, per i nuovi acquisti, la scelta a livello enterprise è sostanzialmente tra due edizioni, che si distinguono soprattutto per i vincoli hardware che impongono. Il primo vincolo riguarda i socket, cioè il numero di processori fisici installabili sul server: un server con 2 socket può ospitare al massimo 2 CPU fisiche, a prescindere da quanti core ciascuna contenga al suo interno.
Il secondo vincolo riguarda i thread di CPU, ovvero i flussi di elaborazione che il database può gestire in parallelo in un dato momento: qui non si tratta di un limite hardware del server, ma di un limite imposto dal software stesso, che resta valido indipendentemente da quanti core o thread fisici siano effettivamente disponibili sulla macchina.
Questi vincoli si riflettono direttamente anche nel modo in cui le due edizioni vengono licenziate. Enterprise Edition si licenzia per core, applicando il Core Factor (core × Core Factor = licenze Processor): più core ha il server, più licenze servono. Standard Edition 2, invece, si licenzia per socket occupato, senza applicare alcun Core Factor: conta solo quanti socket fisici sono popolati, non quanti core contengono – per questo motivo, a parità di socket, aumentare i core su un server SE2 non fa aumentare il costo della licenza.
In alternativa alla metrica Processor, entrambe le edizioni possono anche essere licenziate a Named User Plus (NUP), la metrica basata sul numero di utenti/device autorizzati, ciascuna con il proprio minimo di utenti per server o per processore (10 NUP/server per SE2, 25 NUP/Processor per EE). Riprenderemo nel dettaglio sia il Core Factor sia la metrica NUP nelle prossime due sezioni.
Con SE2, il rischio di attivazione accidentale di funzionalità a pagamento è quasi nullo, perché non esiste alcuna feature extra preinstallata e disattivata: il rischio residuo riguarda soprattutto il rispetto dei limiti hardware e del minimo di utenti. Con Enterprise Edition, invece, il rischio è doppio: funzionalità extra già installate che possono essere attivate involontariamente e un calcolo scorretto del Processor o dei Named User Plus. Il nodo, in quest’ultimo caso, è non riuscire a contare correttamente gli utenti reali, oppure vederne crescere il numero nel tempo. In questi casi servono acquisti aggiuntivi di NUP, e se si supera il punto di pareggio di 50 NUP/Processor conviene passare alla metrica Processor.
Oltre a SE2 ed EE, esistono altre edizioni di nicchia, meno rilevanti per la maggior parte delle aziende ma da conoscere per evitare confusione nel listino. Personal Edition è una Enterprise Edition pensata per lo sviluppo single-user. Mobile Server gestisce la sincronizzazione dei dati con dispositivi mobili. NoSQL Database Enterprise Edition, nonostante il nome, è un prodotto separato, non relazionale, con licenza indipendente. C’è infine Oracle AI Database Free (ex Express Edition, XE): gratuita, ma con limiti tecnici fissi – 2 CPU, 2 GB di RAM e 12 GB di storage – pensata per sviluppo, test e workload molto piccoli.
Come anticipato, entrambe le edizioni si possono licenziare con due metriche alternative: Processor o Named User Plus. Vediamole nel dettaglio.
Metrica Processor
Si usa quando gli utenti non sono quantificabili (accesso web, terze parti, partner) o sono troppo numerosi per essere contati singolarmente. Il modello si basa sul numero di core e socket presenti nel server dove è installato il software Oracle, concentrandosi sulla potenza di calcolo complessiva disponibile invece che sul numero di utenti individuali.
Il calcolo per Enterprise Edition è: core totali × Core Factor = licenze Processor, sempre arrotondando per eccesso. Il Core Factor è un coefficiente specifico per tipo di CPU, pubblicato da Oracle nella tabella ufficiale (Processor Core Factor Table) e periodicamente aggiornato: ad esempio, nel tempo Oracle ha aggiunto coefficienti dedicati a famiglie di chip come Intel Xeon Platinum 81XX e Gold 61XX (fattore 0,5) o i processori Ampere Altra/AltraMax e AmpereOne (fattore 0,25).
Si usa quando utenti e device sono identificabili e numerabili con precisione — basi utenti interne, stabili e contenute. Named User Plus è definito come un individuo autorizzato a usare i programmi installati su uno o più server, indipendentemente dal fatto che stia effettivamente usando il programma in un dato momento; un dispositivo non presidiato da un operatore umano viene conteggiato come Named User Plus aggiuntivo se può accedere al programma.
Un punto spesso sottovalutato riguarda il multiplexing: se si utilizza hardware o software di multiplexing (un TP monitor, un web server), gli utenti da conteggiare vanno misurati al front-end, non dietro l’intermediario tecnico — quindi anche mille utenti che passano attraverso un’unica connessione applicativa devono, in linea di principio, essere conteggiati singolarmente.
Come già anticipato, entrambe le edizioni impongono un minimo di NUP: 10 licenze per server per Standard Edition 2, 25 licenze per Processor per Enterprise Edition. In ogni caso, se il numero reale di utenti supera il minimo, si paga per gli utenti reali; se è inferiore, si paga comunque il minimo. Esempio: 18 utenti + 4 device = 22 NUP (sotto al minimo EE, si paga comunque 25).
Enterprise Edition può essere estesa con due famiglie di moduli aggiuntivi a pagamento:
Il punto critico è come si licenziano: con la stessa metrica della licenza base (Processor o NUP), sullo stesso perimetro dell’intero server, non solo dove la funzionalità è effettivamente usata. Nella pratica, è sufficiente una singola query con un hint che richiama, ad esempio, Advanced Compression, lanciata anche solo per un test, per generare comunque l’obbligo di licenza: conta l’attivazione, non l’intenzione né la durata d’uso.
Ed è proprio questo il meccanismo che genera la maggior parte delle esposizioni scoperte in audit: funzionalità enterprise attivate per errore, per un test o per un default di configurazione mai disattivato, che restano “accese” per mesi o anni senza che nessuno se ne accorga. In sede di audit, Oracle utilizza dati come l’Automatic Workload Repository (AWR) e script proprietari per identificare quali funzionalità sono state usate – anche una sola volta, anche in una query di test – e “non sapevamo fosse attivata” non viene considerata una difesa valida.
Va inoltre ricordato che il minimo NUP per processore si applica anche a Options e Packs: un server da 16 core con Partitioning attivo richiede comunque almeno 200 NUP di Partitioning, anche se solo pochi utenti la utilizzano davvero
Ogni voce del listino Oracle ha un prezzo per Processor e un prezzo per Named User Plus, coerenti con il minimo di 25 NUP per processore di Enterprise Edition. Alcuni riferimenti indicativi dal listino pubblico (listino prezzi in USD disponibile alla pagina Oracle Corporate Pricing)
Questi sono prezzi di listino: la spesa reale dipende dallo sconto negoziale e dal perimetro effettivamente licenziato, ma è anche la base su cui Oracle calcola l’esposizione economica in caso di audit – quindi non va sottovalutato, considerando che c’è anche il costo del supporto.
C’è però un secondo tema di costo, distinto dall’esposizione da audit, ma altrettanto concreto: lo shelfware, cioè le licenze regolarmente acquistate ma di fatto non utilizzate – Options attivate “per sicurezza” all’avvio di un progetto e mai più disattivate, Management Pack abilitati per un test di qualche anno fa. Ogni licenza di questo tipo continua a generare un canone di supporto annuo (tipicamente il 22% del prezzo di listino) a fronte di zero valore reale.
Le stime di esperti collocano lo shelfware tipico tra il 18% e il 30% delle licenze installate in un’azienda, e non è raro trovare casi concreti di risparmi a cinque cifre semplicemente disattivando Pack non più utilizzati. Per questo motivo, accanto al tema della compliance, ha senso trattare l’ottimizzazione dei costi come un esercizio ricorrente e non solo come una risposta a un audit: una baseline periodica dell’installato serve tanto a difendersi da un audit quanto a individuare spesa che si può semplicemente eliminare.
Tutto quanto descritto sopra – edizioni, metriche, Options, Packs, minimi – ha un prerequisito comune: sapere con esattezza cosa è realmente installato, dove, su quale hardware e con quali funzionalità attivate. È un esercizio tutt’altro che banale in ambienti enterprise con decine o centinaia di istanze Oracle distribuite tra data center on-premise, ambienti virtualizzati e cloud.
Come consulenti SAM (Software Asset Management), il nostro lavoro parte proprio da qui: costruiamo la baseline dell’installato Oracle dell’azienda — server, core, edizioni, Options e Packs effettivamente attivi — per fotografare la posizione reale rispetto ai diritti contrattuali.
Per farlo utilizziamo la tecnologia Flexera che permette di rilevare in modo automatizzato l’installato, riconoscere le feature e le Options attivate a livello di istanza e confrontare l’usage reale con l’entitlement contrattuale. Solo a partire da questa baseline è possibile stimare correttamente l’esposizione, capire quali remediation sono percorribili e affrontare un eventuale audit – o una negoziazione di rinnovo – con dati alla mano invece che con stime approssimative.
Con la baseline in mano, le strade percorribili si riducono a poche opzioni concrete. A differenza di Oracle Java, per Oracle Database non esiste quasi mai un equivalente “gratuito” a cui migrare in tempi brevi, e ciascuna di queste strade comporta un impatto operativo o economico diretto sul perimetro Oracle:
Nella maggior parte dei casi, parlare di “sostituzione” del database non è realistico nel breve termine: è un progetto enorme, spesso non compatibile con i tempi di un audit o di una scadenza contrattuale. Ha più senso ragionare in termini di esposizione economica e leva negoziale:
Un dato che vale la pena tenere presente: nella pratica – secondo esperti del settore – si osservano sconti reali sul prezzo di listino nell’ordine del 25-85%. La negoziazione è spesso la leva più efficace per ridurre l’esposizione, prima ancora di qualsiasi intervento tecnico di remediation.
Su questo fronte possiamo supportare anche nella fase negoziale: la conoscenza diretta dei contratti Oracle – struttura degli ordini, clausole di re-pricing su supporto e shelfware, condizioni di un ULA – è spesso ciò che fa la differenza tra accettare la prima proposta di rinnovo e ottenere condizioni realmente allineate all’uso effettivo.
Lo stesso vale, con logiche di licensing diverse ma la stessa disciplina negoziale, anche per Oracle Java: dal gennaio 2023 Oracle ha infatti sostituito i vecchi modelli per processore e Named User Plus con la Java SE Universal Subscription, un abbonamento calcolato sul numero totale di dipendenti dell’azienda, a prescindere da quanti utilizzino effettivamente Java – un cambiamento che ha reso queste trattative ancora più delicate e sempre più spesso presenti sullo stesso tavolo di rinnovo insieme al Database.
Nota: alcuni minimi e coefficienti citati (Core Factor, minimi NUP) sono soggetti a revisione periodica da parte di Oracle. Prima di prendere decisioni contrattuali o di remediation, verificare sempre l’ultima versione pubblicata della Processor Core Factor Table e delle policy di licensing sul sito Oracle.
Approfondimenti
I NOSTRI UFFICI
I NOSTRI UFFICI
PADOVA
Via Arnaldo Fusinato 42, 35137
MILANO
Viale Enrico Forlanini 23, 20134
ROMA
Viale Giorgio Ribotta 11, 00144
Copyright © 2025 WEGG S.r.l. • P.I 03447430285 • C.F. 02371140233 • REA 311023
Azienda Certificata ISO 9001:2015 – ITA / ISO 9001:2015 – EN
