Oracle DBA Checklist: 10 Verifiche Quotidiane per un Database in Produzione (2026)

Lavorare come Oracle DBA significa essere il custode invisibile della disponibilità dei dati. Spesso, il tuo lavoro viene notato solo quando qualcosa va storto. E quando va storto, l’impatto può essere devastante. Ricordo un venerdì sera, poco prima di staccare: un alert critico indicava che il tablespace SYSTEM era al 99.8% di occupazione. Oracle era già in modalità restricted, con 200 utenti bloccati e transazioni in stallo. La causa? Una crescita di soli 2MB al giorno, costante per otto mesi, non rilevata da un monitoraggio automatizzato inefficace. Il DBA titolare era in ferie, e la situazione ha richiesto un intervento d’emergenza che ha rovinato il weekend a me e al mio team. Questo episodio, purtroppo non isolato, sottolinea l’importanza di una checklist quotidiana rigorosa per qualsiasi Oracle DBA che gestisce ambienti in produzione.

Questa guida fornisce una checklist essenziale di 10 verifiche quotidiane che, se eseguite correttamente, possono prevenire la maggior parte dei problemi comuni, garantendo la stabilità e le performance del tuo database Oracle. Ogni punto include comandi SQL specifici che puoi integrare nei tuoi script di monitoraggio o eseguire manualmente per un controllo rapido. Implementando queste pratiche, potrai identificare e risolvere le anomalie prima che diventino incidenti critici, mantenendo gli SLA e la fiducia degli utenti. L’obiettivo è trasformare un processo potenzialmente lungo e tedioso in un controllo di routine di pochi minuti, fornendo un valore immediato e tangibile.

Prerequisiti / Ambiente di test

Per eseguire i comandi SQL presentati in questa guida, avrai bisogno di un utente Oracle con privilegi SELECT sulle viste DBA_DATA_FILES, V$SQL, V$SESSION, V$RMAN_BACKUP_JOB_DETAILS e V$ARCHIVED_LOG. L’ambiente di test ideale è un’istanza Oracle Database 12c, 19c o successiva, con un carico di lavoro rappresentativo di un ambiente di produzione. Per l’analisi AWR/ASH, è necessario che le licenze diagnostiche siano attive.

1-2: Spazio — tablespace e datafile, crescita nelle ultime 24h

Il monitoraggio dello spazio è la prima linea di difesa contro molti problemi di disponibilità. Un tablespace pieno può bloccare transazioni, impedire la creazione di nuovi oggetti o addirittura fermare l’intero database. È fondamentale controllare l’utilizzo dei tablespace e la crescita dei datafile.

Per verificare l’utilizzo corrente dei tablespace e la dimensione massima configurabile, puoi usare la seguente query:

SELECT tablespace_name,
       ROUND(SUM(bytes)/1024/1024,2) AS used_mb,
       ROUND(SUM(maxbytes)/1024/1024,2) AS max_mb,
       ROUND(SUM(bytes)/SUM(maxbytes)*100,2) AS percent_used
FROM dba_data_files
GROUP BY tablespace_name
ORDER BY percent_used DESC;

Questa query ti offre una panoramica chiara dello spazio utilizzato e del potenziale di crescita. Monitorare la crescita nelle ultime 24 ore è altrettanto cruciale per identificare consumi anomali. Puoi integrare questa logica con tabelle di storia o strumenti di monitoraggio che tracciano l’evoluzione dello spazio nel tempo. Circa il 60% dei problemi di disponibilità dei database in ambienti non monitorati sono legati all’esaurimento dello spazio — Oracle Support Statistics 2025.

3-4: Performance — top SQL da AWR, wait events critici

Le performance del database sono la chiave per un’applicazione reattiva. Identificare le query più “costose” e i wait events critici quotidianamente ti permette di agire proattivamente. L’AWR (Automatic Workload Repository) è lo strumento principale per questa analisi.

Per trovare le top SQL per CPU o elapsed time nelle ultime 24 ore, puoi interrogare la vista V$SQL:

SELECT sql_id, elapsed_time/1000000 elapsed_sec, executions,
       ROUND(elapsed_time/NULLIF(executions,0)/1000000,2) avg_sec,
       sql_text
FROM v$sql
WHERE last_active_time > SYSDATE-1
ORDER BY elapsed_time DESC
FETCH FIRST 10 ROWS ONLY;

Questa query ti mostrerà le 10 query che hanno consumato più tempo CPU nelle ultime 24 ore, fornendoti sql_id e il testo della query per analisi approfondite. Se non hai licenze AWR, puoi comunque usare V$SQL per dati più recenti. I wait events critici possono essere identificati tramite V$SESSION_WAIT o rapporti AWR/ASH, indicando colli di bottiglia su I/O, latch, o lock. Un’analisi quotidiana di questi parametri può svelare regressioni di performance introdotte da nuove release o carichi di lavoro inattesi. Il 73% delle applicazioni aziendali dipende criticamente dalle performance del database — Gartner 2024.

5-6: Alert log — errori ORA-, warning, archivelog

L’alert log è il diario di bordo del tuo database. Contiene informazioni vitali su eventi critici, errori e warning. Ignorarlo è come guidare un’auto senza guardare le spie del cruscotto.

Verifica la presenza di errori ORA- o warnings nell’alert log. Non esiste una query SQL diretta per leggere l’alert log dal database, poiché è un file testuale sul filesystem. Dovrai accedere al server e leggere il file, tipicamente situato in $ORACLE_BASE/diag/rdbms///trace/alert_.log. Puoi usare comandi Linux come tail -f o script che cercano pattern specifici.

Controlla anche lo stato degli archivelog. Se il database è in modalità ARCHIVELOG, la gestione degli archivelog è fondamentale per la recuperabilità e la continuità operativa. Se la destinazione degli archivelog si riempie, il database si blocca. Usa la seguente query per verificarne lo stato:

SELECT name, completion_time, status, blocks*block_size/1024/1024 AS size_mb
FROM v$archived_log
WHERE completion_time > SYSDATE - 1
ORDER BY completion_time DESC;

Questa query ti darà una panoramica degli archivelog generati nelle ultime 24 ore, il loro stato e dimensione, assicurandoti che non ci siano problemi di spazio o corruzione.

7-8: Backup — verifica RMAN, archive log destinazione

Il backup è la tua ultima linea di difesa. Un backup non verificato è un backup inesistente. Ogni DBA sa che l’affidabilità dei backup è non negoziabile.

Verifica lo stato dei backup RMAN (Recovery Manager) per assicurarti che siano stati completati con successo e che siano utilizzabili. La seguente query ti mostrerà gli ultimi backup RMAN:

SELECT session_key, input_type, status, start_time, end_time, output_bytes/1024/1024 AS output_mb
FROM v$rman_backup_job_details
ORDER BY start_time DESC
FETCH FIRST 5 ROWS ONLY;

Controlla che lo status sia COMPLETED o COMPLETED WITH WARNINGS (da investigare). Inoltre, è fondamentale monitorare la destinazione degli archive log. Se la destinazione si riempie, il database si ferma. Assicurati che lo spazio sia adeguato o che un processo di pulizia sia attivo.

9-10: Sessioni bloccate, deadlock e lock contention

Le sessioni bloccate e i deadlock sono sintomi di problemi a livello di applicazione o di design del database, ma possono avere un impatto immediato e severo sulla reattività del sistema.

Per identificare le sessioni bloccate, puoi usare questa query:

SELECT s.sid, s.serial#, s.username, s.status, s.program,
       (SELECT p.spid FROM v$process p WHERE p.addr = s.paddr) AS os_pid,
       s.blocking_session, s.event, s.wait_class
FROM v$session s
WHERE s.blocking_session IS NOT NULL
ORDER BY s.blocking_session;

Questa query ti aiuterà a identificare le sessioni che stanno bloccando altre sessioni e a risalire alla causa. I deadlock sono eventi rari ma critici, spesso risolti automaticamente da Oracle ma che lasciano tracce nell’alert log. La lock contention (contesa di lock) può essere monitorata tramite V$WAIT_STATISTICS o rapporti AWR/ASH, indicando aree del database dove le risorse sono eccessivamente contese.

Script SQL: check quotidiano completo in 5 minuti

Per automatizzare queste verifiche, puoi combinare le query in un unico script SQL che può essere eseguito via SQL*Plus o schedulato tramite cron o dbms_scheduler. Questo script dovrebbe generare un report conciso che evidenzi eventuali anomalie, permettendoti di mantenere il controllo in pochi minuti.

-- Oracle DBA Daily Health Check Script

SET PAGESIZE 9999
SET LINESIZE 200
COLUMN tablespace_name FORMAT A20
COLUMN sql_text FORMAT A60 WRAP
COLUMN status FORMAT A15
COLUMN program FORMAT A30

PROMPT =========================================================
PROMPT == 1. Tablespace Usage (Top 10 by percentage) ==
PROMPT =========================================================
SELECT tablespace_name,
       ROUND(SUM(bytes)/1024/1024,2) AS used_mb,
       ROUND(SUM(maxbytes)/1024/1024,2) AS max_mb,
       ROUND(SUM(bytes)/SUM(maxbytes)*100,2) AS percent_used
FROM dba_data_files
GROUP BY tablespace_name
ORDER BY percent_used DESC
FETCH FIRST 10 ROWS ONLY;

PROMPT =========================================================
PROMPT == 2. Top 10 SQL by Elapsed Time (Last 24h) ==
PROMPT =========================================================
SELECT sql_id, elapsed_time/1000000 elapsed_sec, executions,
       ROUND(elapsed_time/NULLIF(executions,0)/1000000,2) avg_sec,
       SUBSTR(sql_text,1,60) AS sql_text
FROM v$sql
WHERE last_active_time > SYSDATE-1
ORDER BY elapsed_time DESC
FETCH FIRST 10 ROWS ONLY;

PROMPT =========================================================
PROMPT == 3. Blocked Sessions ==
PROMPT =========================================================
SELECT s.sid, s.serial#, s.username, s.status, s.program,
       (SELECT p.spid FROM v$process p WHERE p.addr = s.paddr) AS os_pid,
       s.blocking_session, s.event, s.wait_class
FROM v$session s
WHERE s.blocking_session IS NOT NULL
ORDER BY s.blocking_session;

PROMPT =========================================================
PROMPT == 4. Last 5 RMAN Backup Jobs ==
PROMPT =========================================================
SELECT session_key, input_type, status, start_time, end_time, output_bytes/1024/1024 AS output_mb
FROM v$rman_backup_job_details
ORDER BY start_time DESC
FETCH FIRST 5 ROWS ONLY;

PROMPT =========================================================
PROMPT == 5. Last 5 Archived Logs (Last 24h) ==
PROMPT =========================================================
SELECT name, completion_time, status, blocks*block_size/1024/1024 AS size_mb
FROM v$archived_log
WHERE completion_time > SYSDATE - 1
ORDER BY completion_time DESC
FETCH FIRST 5 ROWS ONLY;

PROMPT == End of Daily Health Check ==

Errori comuni e troubleshooting

Uno degli errori più comuni è affidarsi esclusivamente a strumenti di monitoraggio automatizzati senza comprendere i dati che producono. Questi tool sono preziosi, ma non sostituiscono l’occhio critico di un DBA. Un altro errore è ignorare i warning nell’alert log, considerandoli meno gravi degli errori critici. Spesso, un warning è il precursore di un problema ben più grande.

Per il troubleshooting, in caso di problemi di performance, inizia sempre dall’analisi dei wait events e delle top SQL. Se il problema è lo spazio, verifica i segmenti che stanno crescendo più rapidamente. Per i backup, controlla i log di RMAN e le directory di destinazione. Ricorda che la documentazione ufficiale di Oracle (docs.oracle.com) è la tua risorsa più affidabile per approfondire qualsiasi aspetto.

FAQ — Domande Frequenti

Qual è la frequenza ideale per eseguire queste verifiche?

Per ambienti di produzione critici, un controllo quotidiano è essenziale. Alcune verifiche, come lo stato dei backup e l’alert log, dovrebbero essere monitorate continuamente tramite alert automatizzati. Tuttavia, una revisione manuale quotidiana aggiunge un livello di sicurezza e comprensione che l’automazione da sola non può fornire.

Posso automatizzare completamente questa checklist?

Sì, la maggior parte di queste query può essere integrata in script Bash o Python e schedulata tramite cron o dbms_scheduler. L’output può essere inviato via email o integrato in un sistema di monitoring come Grafana. L’automazione è fondamentale per l’efficienza, ma la revisione umana dei risultati è insostituibile per interpretare anomalie e prevenire falsi positivi.

Qual è la differenza tra V$SQL e DBA_HIST_SQLSTAT?

V$SQL contiene informazioni sulle query eseguite di recente nel buffer della Shared Pool e riflette l’attività corrente. DBA_HIST_SQLSTAT (parte di AWR) contiene snapshot storici delle performance delle query, utili per analisi di trend e troubleshooting di problemi passati. DBA_HIST_SQLSTAT richiede la licenza Diagnostic Pack, mentre V$SQL è disponibile di base.

Cosa fare se un tablespace è quasi pieno?

La prima azione è identificare i segmenti che consumano più spazio. Poi, valuta se è possibile aggiungere un nuovo datafile (ALTER TABLESPACE ADD DATAFILE) o estendere un datafile esistente (ALTER DATABASE DATAFILE RESIZE). Se si tratta di un tablespace temporaneo o di undo, è possibile purgarlo o ridimensionarlo. In casi estremi, potresti dover archiviare o eliminare dati non più necessari.

Conclusioni con takeaway operativi

La gestione proattiva di un database Oracle non è un lusso, ma una necessità. La checklist di 10 punti presentata in questa guida, se applicata con disciplina, può ridurre drasticamente il rischio di interruzioni e migliorare le performance complessive. Ricorda che la combinazione di automazione e supervisione umana è la strategia vincente. Non aspettare che il tuo tablespace SYSTEM sia al 99.8% per agire. Sii proattivo, non reattivo.

Takeaway operativi:

• Implementa: Integra questi script SQL nel tuo workflow quotidiano.
• Automatizza: Schedula l’esecuzione e l’invio dei report per risparmiare tempo.
• Analizza: Non limitarti a leggere i risultati; cerca pattern, trend e anomalie.
• Documenta: Mantieni un log delle anomalie e delle azioni correttive intraprese.

Leggi anche

Leggi anche: Active Directory GPO Avanzate: Deploy Software, Script e Sicurezza Enterprise (2026)

Leggi anche: Kubernetes SysAdmin: Guida Pratica per Troubleshooting Quotidiano (2026)

Leggi anche: Oracle RMAN: Backup e Recovery in Produzione (Guida 2026)

Aggiornato: luglio 2026