DBA Oracle interno o esterno: il conto delle ore che servono davvero

Un amministratore di database (DBA) Oracle interno a tempo pieno conviene quando il lavoro sui database è quotidiano e costante. Quando invece arriva a ondate, fra aggiornamenti, migrazioni, chiusure ed emergenze, spesso rende di più un servizio esterno, oppure una formula mista: una persona interna per l’ordinario e un supporto esterno per progetti, picchi e sostituzioni. Il conto si fa sulle ore reali, sulla continuità e sul rischio di dipendere da una sola persona, non sul solo stipendio.

Scenario tipico. Un’azienda assume un DBA esperto. Nei mesi normali il lavoro sul database occupa una parte della settimana: controlli delle copie, qualche interrogazione lenta da sistemare, utenze da gestire. Il resto del tempo va su attività che con il database c’entrano poco. Poi arrivano insieme la migrazione su un nuovo server e un problema in produzione, e la stessa persona lavora dodici ore al giorno per settimane, da sola, perché nessun altro in azienda sa mettere le mani su quell’ambiente. Il problema non è la persona. È che il carico di lavoro su Oracle non è costante, mentre il costo di un dipendente lo è.

Che cosa fa un DBA Oracle, in pratica?

Il DBA tiene in salute il database su cui lavorano gestionale, contabilità, logistica. La documentazione di Oracle elenca i suoi compiti: pianificare e creare i database, gestire utenze e privilegi, fare le copie, ottimizzare le prestazioni, installare gli aggiornamenti rilasciati ogni trimestre. Nella vita di un’azienda questi compiti si dividono in tre gruppi.

• Ordinario: spazio, utenze, elaborazioni pianificate, registri degli errori, patch, controllo delle copie.
• Progetti: aggiornamenti di versione, migrazioni, nuovi ambienti, integrazioni con altri sistemi.
• Imprevisti: rallentamenti improvvisi, blocchi, dati danneggiati, verifiche di sicurezza o delle licenze.

Una sola persona raramente è esperta allo stesso livello in tutto: prestazioni, copie e continuità, sicurezza, licenze, migrazioni.

Perché il lavoro su Oracle arriva a ondate?

Perché segue calendari che non dipendono dall’azienda.

• Le patch: Oracle pubblica le correzioni cumulative ogni trimestre e, da fine maggio 2026, aggiornamenti di sicurezza anche negli altri mesi. Ognuna va provata in collaudo e applicata in produzione.
• Le scadenze del supporto: quando una versione esce dalla copertura, l’aggiornamento diventa un progetto con una data, come spiegato per i database Oracle fuori supporto.
• I progetti: un cambio di server o il passaggio al cloud concentrano settimane di lavoro intenso, come nelle migrazioni con fermi ridotti.
• Il calendario dell’azienda: chiusure di bilancio, picchi stagionali, inventari.
• Gli imprevisti: un database con blocchi corrotti non avvisa prima.

Quali costi pesano oltre allo stipendio?

Il confronto corretto non è tra stipendio e canone. È tra due modi di coprire lo stesso lavoro, ciascuno con le sue voci.

La tabella non dice che una soluzione vince sull’altra. Dice che entrambe hanno costi nascosti, e che vanno messi sul tavolo tutti.

Quando conviene un servizio esterno?

• Pochi database critici, con lavoro concentrato in alcuni periodi dell’anno.
• Progetti a termine, come una migrazione o un aggiornamento di versione: assumere per sei mesi di lavoro intenso raramente ha senso.
• Più sedi o più società che hanno bisogno di una copertura omogenea senza costruire un gruppo interno.
• Aziende in crescita che hanno bisogno di competenza Oracle seria ma non ancora di una figura dedicata.
• Nessun sostituto interno: se oggi un’assenza lascia il database scoperto, la continuità è già un problema.

Quando conviene un DBA interno?

• Il lavoro quotidiano è costante e riempie davvero una posizione a tempo pieno.
• Le istanze sono molte, con sviluppo interno continuo e bisogno di presenza quotidiana accanto agli sviluppatori.
• Le regole interne o del settore chiedono che determinati accessi siano riservati a dipendenti.
• Il database è il cuore del prodotto che l’azienda vende, non solo del suo gestionale.

La formula mista funziona?

Spesso è la più solida. La persona interna gestisce l’ordinario e conosce le applicazioni. Il supporto esterno interviene su progetti, picchi, sostituzioni, e porta una revisione periodica dell’ambiente: un secondo sguardo su configurazioni, copie e sicurezza. Così il DBA interno non resta solo nei momenti critici, e l’azienda non dipende per intero né da una persona né da un fornitore.

Come si fa il conto, in pratica?

1. Contare le ore dell’ultimo anno, dividendole fra ordinario, progetti e imprevisti. Le fonti sono le richieste di assistenza, i calendari, i progetti chiusi.
2. Scrivere i tempi sopportabili. L’RTO (Recovery Time Objective) è il tempo massimo di fermo accettabile; l’RPO (Recovery Point Objective) è quanti dati, misurati in tempo, si possono perdere. Poi chiedersi chi interviene di notte, in agosto, durante una migrazione.
3. Elencare le competenze necessarie e segnare quali sono coperte oggi.
4. Mettere a confronto il costo completo delle due strade, con le voci della tabella.
5. Leggere il contratto del servizio esterno prima di decidere: tempi di intervento, orari, documentazione, accessi, uscita.

Che cosa chiedere a un fornitore di DBA esterni?

• Chi lavora sul database, con quali ruoli, e chi sostituisce chi.
• Tempi di intervento scritti, distinti per gravità e per fascia oraria.
• Accessi nominativi e tracciati, con un accordo di riservatezza e la chiusura degli accessi a fine incarico. Se il fornitore tratta dati personali per conto dell’azienda, serve un contratto conforme all’art. 28 del GDPR.
• Documentazione consegnata: configurazioni, procedure, verbali delle prove di ripristino.
• Licenze rispettate: nessuna funzione a pagamento usata senza copertura, nemmeno per una diagnosi veloce.
• Uscita ordinata: che cosa riceve l’azienda se un giorno cambia fornitore.

Per le aziende soggette alla NIS2 c’è un motivo in più: il D.Lgs. 138/2024 chiede di curare la sicurezza dei rapporti con i fornitori diretti (art. 24, comma 2, lettera d), e un DBA esterno è un fornitore con accessi molto ampi.

In sintesi

• Il lavoro su Oracle arriva a ondate; il costo di un dipendente è costante.
• Un DBA interno conviene con lavoro quotidiano costante, molte istanze o vincoli di governance.
• Un servizio esterno conviene con pochi database critici, progetti a termine e nessun sostituto interno.
• La formula mista unisce la conoscenza delle applicazioni e la copertura dei picchi.
• Il conto si fa su ore reali, tempi sopportabili, competenze e continuità.
• Con un fornitore esterno contano tempi scritti, accessi tracciati, documentazione consegnata e uscita ordinata.

Domande frequenti

Un DBA esterno può lavorare accanto al team interno?

Sì. Si stabilisce per iscritto chi fa che cosa: per esempio l’ordinario al team interno, progetti, patch e sostituzioni all’esterno. Le procedure comuni evitano che due persone intervengano sulla stessa cosa senza saperlo.

Un DBA esterno può vedere i dati dell’azienda?

Per amministrare un database servono accessi ampi, e proprio per questo si regolano prima di cominciare: accordo di riservatezza, utenze nominative e tracciate, connessioni concordate con l’IT, nessuna copia dei dati fuori dall’azienda senza autorizzazione. Con dati personali serve anche il contratto previsto dall’art. 28 del GDPR.

Chi risponde se il servizio esterno sbaglia?

Lo stabilisce il contratto: attività comprese, tempi, responsabilità, limiti. Per questo il perimetro si scrive prima di cominciare, e ogni intervento in produzione si fa con una copia verificata e un rientro previsto.

Se si decide di assumere, come si valuta un candidato DBA?

Con un colloquio tecnico e una prova sul lavoro reale, condotti da chi amministra database. Titoli e anni di esperienza da soli dicono poco su come una persona gestisce una migrazione o un’emergenza.

Amministrare database Oracle in outsourcing o accanto al team interno è il lavoro della nostra divisione Oracle & Database Engineering, che valuta il carico reale prima di proporre un intervento puntuale o una gestione continuativa. Per chi sceglie di assumere, la definizione del ruolo e la valutazione tecnica dei candidati fanno parte del nostro lavoro su ruoli critici e successione.

Fonti

• Oracle, Database Administrator’s Guide 19c, «Tasks of a Database Administrator»
• Oracle, Critical Security Patch Update Advisory, May 2026, pubblicato il 28 maggio 2026
• Oracle, Lifetime Support Policy: Oracle Technology Products
• D.Lgs. 4 settembre 2024, n. 138, art. 24, Normattiva
• Regolamento (UE) 2016/679 (GDPR), art. 28, EUR-Lex