DBADati e Oracle

Aggiornare il database Oracle: le decisioni e il calendario della direzione

Il passaggio alla nuova versione di Oracle è un progetto di direzione prima che tecnico: inventario, budget, fornitori del gestionale, criteri di accettazione, finestra di fermo e chi dà il via la sera del passaggio.

Redazione Strategic 22 settembre 2026 6 min di lettura

Copertina: «Aggiornare Oracle: il calendario della direzione», Dati e Oracle

Aggiornare il database Oracle su cui gira il gestionale è una decisione di direzione prima che un lavoro tecnico: tocca il budget di due o tre esercizi, i contratti con il fornitore del gestionale, le licenze, le finestre in cui l’azienda accetta di fermarsi e la responsabilità di dire «si procede» la sera del passaggio. Per chi usa la versione 19c, oggi la più diffusa, il supporto principale scade a fine 2029 e la nuova versione di lungo periodo è la 26ai. Il tempo c’è, ma le parti lente del progetto non dipendono dal database: se la direzione fissa ora inventario, calendario e criteri, il fermo si concentra in una finestra breve, scelta dall’azienda.

Quanto tempo resta?

Le date della politica di supporto di Oracle, versione per versione, sono riassunte nell’analisi dell’Osservatorio su Oracle fuori supporto, insieme a ciò che rischia chi resta senza patch. Per la pianificazione contano tre punti: la 19c ha il supporto principale fino a dicembre 2029 e poi un supporto esteso a pagamento; la 21c lo perde già a luglio 2027, senza estensioni; per la 19c, dal 1° maggio 2027, il supporto esclude il software di terze parti legato a Java 8 su alcune piattaforme, come AIX, HP-UX, Solaris e Windows.

Perché decidere adesso e non nel 2029?

Perché le parti lente del progetto non dipendono dal database. Il fornitore del gestionale deve dichiarare la compatibilità con la nuova versione. Server e sistema operativo possono andare rinnovati. Le prove coinvolgono gli utenti, che hanno le proprie scadenze. Il budget segue il ciclo annuale.

Rimandare concentra tutto a ridosso della scadenza, quando anche fornitori applicativi e specialisti hanno meno disponibilità, e trasforma l’Extended Support, che ha un costo, da ponte scelto a strada obbligata.

Che cosa cambia con la nuova versione?

Il cambiamento principale riguarda l’architettura. Dalla versione 21c Oracle non supporta più l’architettura tradizionale, detta non-CDB: 26ai funziona solo con l’architettura multitenant, in cui un database contenitore (CDB) ospita uno o più database collegabili (PDB). Chi oggi usa 19c nella forma tradizionale deve convertirlo durante l’aggiornamento.

Le conseguenze da conoscere prima:

Licenze. Secondo la documentazione Oracle, dopo la conversione si possono usare fino a tre PDB per contenitore senza la licenza Multitenant; dal quarto in poi serve.
Nessun ritorno automatico. La documentazione avverte che, una volta avviata la conversione con lo strumento AutoUpgrade, non si torna allo stato precedente: prima servono una copia completa e prove accurate.
Percorsi. L’aggiornamento diretto a 26ai è supportato solo da 19c e da 21c. Da versioni più vecchie, come 11g, 12c o 18c, si passa prima per una versione intermedia.
Nuove funzioni. 26ai porta nel database strumenti pensati per l’intelligenza artificiale, come la ricerca vettoriale, utili quando si collegano assistenti AI ai dati aziendali; prima di usarli se ne verificano le condizioni di licenza. Come si progettano questi collegamenti in sicurezza è il tema dell’area agenti AI e integrazioni.

Come si riduce il fermo?

Il fermo che gli utenti percepiscono è quello del passaggio finale, il cutover: il momento in cui le applicazioni si spostano sul database aggiornato. La durata dipende dalla dimensione del database, dalla tecnica scelta e da quanto è stato provato prima. Le strade principali sono quattro.

Tecnica	Come funziona	Che cosa richiede
Aggiornamento sul posto	Il database si aggiorna nella finestra concordata	Una prova generale su una copia per misurare i tempi
Aggiornamento su un nuovo ambiente	Si prepara il nuovo server, si allinea una copia e si passa	Nuovi server o cloud, allineamento dei dati fino al passaggio
Aggiornamento a rotazione con Data Guard	Si aggiorna prima la copia di riserva, poi si scambiano i ruoli	Nella Enterprise Edition la procedura automatizzata richiede l’opzione Active Data Guard, a pagamento
Replica con GoldenGate	Il nuovo database resta allineato fino al passaggio	GoldenGate è un prodotto con licenza separata

Per tutte vale la stessa regola: il piano di ritorno si scrive prima e si prova. Si stabilisce in anticipo il punto oltre il quale non si torna indietro e chi ha l’autorità di dire «si procede» o «si rinvia». La tecnica della replica continua è approfondita nell’articolo sul passaggio con replica continua e cutover.

Che cosa decide la direzione?

Inventario e priorità: quali database, con quali applicazioni, in quale ordine di importanza.
Calendario: finestre di fermo nei periodi di minore attività, lontano da chiusure contabili e picchi di vendita.
Budget: ore di lavoro, prove, eventuali server e sistema operativo, licenze aggiuntive, Extended Support come eventuale ponte.
Fornitori applicativi: date di compatibilità con 26ai, messe per iscritto.
Criteri di accettazione: quali operazioni devono funzionare prima di considerare riuscito il passaggio, decisi da chi usa i sistemi ogni giorno.
Chi dà il via: la persona che, la sera del passaggio, conferma o rinvia.
Comunicazione: chi avvisa utenti, clienti e fornitori della finestra di fermo.

Uno scenario tipico: un’azienda manifatturiera ha il gestionale su 19c in architettura tradizionale, con un database per la produzione e uno per i report. Nel 2026 fa l’inventario e chiede al fornitore del gestionale la data di compatibilità. Nel 2027 aggiorna una copia di prova e la usa per un’intera chiusura mensile. Il passaggio in produzione avviene durante la chiusura estiva dello stabilimento, dopo una prova generale cronometrata e con il piano di ritorno pronto.

In sintesi

Aggiornare il database è una decisione di direzione: budget, fornitori, licenze, finestre e via libera.
Le parti lente del progetto non dipendono dal database: per questo si decide anni prima della scadenza del supporto.
26ai, rilascio di lungo periodo, ha il Premier fino a dicembre 2031 e funziona solo con l’architettura multitenant.
La conversione da non-CDB non si annulla una volta avviata: servono copia completa e prove.
Il fermo si riduce con la prova generale e, dove serve, con tecniche che possono richiedere licenze aggiuntive.
Calendario, budget, fornitori, criteri di accettazione e via libera sono decisioni della direzione.

Domande frequenti

Come si stima il budget prima di avere un preventivo?

Partendo dall’inventario: numero di database, dimensioni, applicazioni collegate, server da rinnovare, opzioni a licenza già in uso. Con questi dati si fissa una cifra di massima per l’esercizio delle prove e una per quello del passaggio, da confermare dopo la prova generale su una copia. Il costo di un eventuale supporto esteso va messo accanto, come alternativa da confrontare.

Il passaggio a 26ai richiede nuove licenze?

Con un contratto di supporto attivo, la politica di Oracle comprende il diritto alle nuove versioni principali. Vanno però verificate le opzioni già usate o da usare, per esempio la licenza Multitenant oltre i tre PDB, Active Data Guard o GoldenGate.

Quanto dura il fermo?

Dipende dalla dimensione del database, dalla tecnica scelta e dalle prove fatte. L’unico modo affidabile per saperlo è una prova generale cronometrata su una copia, prima di fissare la finestra.

E se il gestionale non è ancora compatibile con 26ai?

Si prepara tutto il resto: inventario, conversione pianificata, prove su una copia. Intanto si chiede al fornitore una data scritta e si valuta per tempo se l’Extended Support serve come ponte.

Inventario, prove generali, calendario e passaggio con un piano di ritorno sono il lavoro che la divisione Oracle & Database Engineering svolge per aggiornamenti di versione e migrazioni, in outsourcing o accanto al team interno, con fermi pianificati e ridotti al minimo.