Oracle DBA: Controlli Quotidiani con Output Reali

Quando si gestisce un ambiente Oracle, la stabilità e la performance del database sono cruciali per la continuità operativa. Ho passato anni a monitorare e ottimizzare istanze Oracle in contesti enterprise, dove anche un breve downtime può avere ripercussioni significative. L’approccio reattivo, in cui si interviene solo quando il problema è già esploso, è insostenibile. È per questo che ho affinato una lista di controlli quotidiani essenziali, pensati per identificare tempestivamente anomalie e prevenire disservizi. Questi controlli, eseguiti regolarmente, offrono una fotografia chiara dello stato di salute del database e permettono di agire proattivamente, garantendo che le applicazioni che dipendono da Oracle funzionino senza interruzioni. L’obiettivo non è solo mantenere il database online, ma assicurare che operi al massimo delle sue capacità, supportando i carichi di lavoro critici dell’organizzazione.

Testato su: Oracle Database 19c · SQL*Plus · 23 Settembre 2026

Prerequisiti / Ambiente di test

Per eseguire i controlli descritti, avrai bisogno di un utente DBA con i permessi adeguati (es. SYSDBA) e l’accesso al server database. I comandi sono stati testati su un’istanza Oracle Database 19c, con accesso tramite SQL*Plus. È consigliabile eseguire questi controlli in un ambiente di test o sviluppo prima di applicarli direttamente in produzione, per familiarizzare con gli output e i potenziali effetti collaterali.

1. Stato Istanza e Listener

Il primo passo è verificare che l’istanza Oracle sia attiva e che il listener sia in ascolto. Senza un’istanza attiva, il database non è disponibile. Senza un listener, nessuna connessione esterna può essere stabilita. Leggi anche: Oracle Listener: Configurazione e Troubleshooting

Per controllare lo stato dell’istanza, connettiti a SQL*Plus come SYSDBA e usa il comando STATUS.

SQL> SELECT INSTANCE_NAME, STATUS, DATABASE_STATUS FROM V$INSTANCE;

Output tipico:

INSTANCE_NAME    STATUS       DATABASE_STATUS
---------------- ----------- -----------------
ORCL             OPEN         ACTIVE

Per verificare lo stato del listener, esegui il comando lsnrctl status dal prompt del sistema operativo.

lsnrctl status

Output tipico (parte rilevante):

LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 23-SEP-2026 10:30:00

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Start Date                23-SEP-2026 09:00:00
Uptime                    0 days 1 hr. 30 min. 0 sec
...
Services Summary...
Service "orcl" has 1 instance(s).
  Instance "orcl", status READY, has 1 handler(s) for this service...
The command completed successfully

2. Spazio Disco e Tablespace

L’esaurimento dello spazio nei tablespace è una causa comune di blocchi e performance degradate. Monitorare lo spazio disponibile è fondamentale per prevenire interruzioni. Questo controllo dovrebbe essere eseguito quotidianamente, soprattutto in ambienti con carichi di lavoro elevati o crescita rapida dei dati. Leggi anche: Hugging Face Speech-to-Speech: Guida Pratica

SQL> SELECT
  df.tablespace_name,
  TRUNC(df.bytes / (1024 * 1024)) AS total_mb,
  TRUNC(SUM(fs.bytes) / (1024 * 1024)) AS free_mb,
  TRUNC((SUM(fs.bytes) / df.bytes) * 100) AS free_percent
FROM
  dba_data_files df,
  dba_free_space fs
WHERE
  df.file_id = fs.file_id (+)
GROUP BY
  df.tablespace_name, df.bytes
ORDER BY
  free_percent;

Output tipico:

TABLESPACE_NAME         TOTAL_MB    FREE_MB FREE_PERCENT
-------------------- ---------- ---------- ------------
SYSAUX                     1000        150           15
USERS                       500        300           60
SYSTEM                      700        600           85
TEMP                        200        200          100
UNDOTBS1                   1000       1000          100

Un valore free_percent basso per tablespace critici come SYSAUX o USERS richiede attenzione immediata.

3. Backup e Alert Log

La validità dei backup è la garanzia di poter recuperare il database in caso di disastro. L’alert log è il diario del database, dove vengono registrati errori critici, startup/shutdown, e altre informazioni vitali. Controllare entrambi quotidianamente è una pratica di sicurezza indispensabile. Leggi anche: Oracle RMAN: Backup e Recovery in Produzione (Guida 2026)

Per lo stato dei backup recenti (usando RMAN):

SQL> SELECT
  session_key,
  input_type,
  status,
  TO_CHAR(start_time, 'YYYY-MM-DD HH24:MI:SS') AS start_time,
  TO_CHAR(end_time, 'YYYY-MM-DD HH24:MI:SS') AS end_time,
  elapsed_seconds/60 AS minutes_elapsed
FROM
  V$RMAN_BACKUP_JOB_DETAILS
WHERE
  start_time > SYSDATE - 1
ORDER BY
  start_time DESC;

Output tipico:

SESSION_KEY INPUT_TYPE STATUS          START_TIME          END_TIME            MINUTES_ELAPSED
----------- ---------- --------------- ------------------- ------------------- ---------------
12345       DB FULL    COMPLETED       2026-09-22 23:00:00 2026-09-23 01:30:00           150

Per l’alert log, la sua posizione è definita dal parametro DIAGNOSTIC_DEST. Puoi leggere gli ultimi messaggi con un comando tail o grep.

tail -f $ORACLE_BASE/diag/rdbms/orcl/orcl/trace/alert_orcl.log | grep -i "ORA-"

Cerca errori ORA- o messaggi critical, fatal, error.

4. Sessioni Attive e Blocchi

Sessioni bloccate o con tempi di esecuzione lunghi possono indicare colli di bottiglia o problemi a livello applicativo. Identificarli tempestivamente permette di intervenire prima che impattino un vasto numero di utenti.

Per visualizzare le sessioni attive e i relativi eventi di attesa:

SQL> SELECT
  s.sid,
  s.serial#,
  s.username,
  s.program,
  s.status,
  s.state,
  sw.event,
  sw.seconds_in_wait
FROM
  V$SESSION s,
  V$SESSION_WAIT sw
WHERE
  s.sid = sw.sid
  AND s.status = 'ACTIVE'
  AND s.username IS NOT NULL
ORDER BY
  sw.seconds_in_wait DESC;

Output tipico:

SID    SERIAL# USERNAME PROGRAM                   STATUS   STATE            EVENT                               SECONDS_IN_WAIT
----- -------- -------- ------------------------- -------- ---------------- ----------------------------------- ---------------
123      45678 APP_USER  JDBC Thin Client          ACTIVE   WAITING          SQL*Net message from client                     5
124      90123 APP_BATCH BATCH_JOB                 ACTIVE   WAITING          db file sequential read                       120

Per identificare i blocchi:

SQL> SELECT
  l.session_id AS blocking_sid,
  s.serial# AS blocking_serial#,
  s.username AS blocking_user,
  s.program AS blocking_program,
  l.locked_mode AS lock_mode,
  o.object_name,
  o.object_type,
  (SELECT sid FROM V$SESSION WHERE blocking_session = l.session_id) AS blocked_sid
FROM
  V$LOCK l
  JOIN V$SESSION s ON l.session_id = s.sid
  JOIN DBA_OBJECTS o ON l.id1 = o.object_id
WHERE
  l.block = 1;

Output tipico:

BLOCKING_SID BLOCKING_SERIAL# BLOCKING_USER BLOCKING_PROGRAM          LOCK_MODE OBJECT_NAME OBJECT_TYPE BLOCKED_SID
------------ ---------------- ------------- ------------------------- --------- ----------- ----------- -----------
123          45678            APP_USER      JDBC Thin Client          3         TABELLA_DATI TABLE          124

Errori comuni e troubleshooting

• Listener non avviato: Se lsnrctl status fallisce o il listener non è in stato READY, prova a riavviarlo con lsnrctl start o lsnrctl stop seguito da lsnrctl start. Verifica il file listener.log per errori specifici.
• Tablespace quasi pieno: Se un tablespace è al limite, puoi aggiungere un nuovo datafile (ALTER TABLESPACE USERS ADD DATAFILE '/path/to/datafile.dbf' SIZE 100M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED;) o ridimensionare un datafile esistente se non è al massimo (ALTER DATABASE DATAFILE '/path/to/datafile.dbf' RESIZE 500M;).
• Backup fallito: Controlla i log di RMAN e i log del sistema operativo. Spesso, la causa è spazio insufficiente, problemi di permessi o configurazione errata. Assicurati che l’utente Oracle abbia i permessi di scrittura sulla destinazione del backup.
• Sessioni bloccate: Identifica la sessione bloccante e l’oggetto bloccato. Spesso, un commit o rollback mancante è la causa. Se necessario, termina la sessione bloccante con ALTER SYSTEM KILL SESSION 'sid,serial#'; ma fai attenzione, potrebbe causare un rollback lungo e impattare altre transazioni. Consulta sempre l’applicazione prima di terminare una sessione.

FAQ — Domande Frequenti

Con quale frequenza dovrei eseguire questi controlli?

Idealmente, questi controlli dovrebbero essere eseguiti all’inizio di ogni giornata lavorativa. Per ambienti particolarmente critici o con carichi di lavoro elevati, alcuni controlli (come lo stato delle sessioni o l’utilizzo dello spazio) potrebbero beneficiare di monitoraggio più frequente, anche ogni poche ore. L’automatizzazione tramite script e tool di monitoraggio è fortemente consigliata per alleggerire il carico del DBA.

Posso automatizzare questi controlli?

Assolutamente sì. La maggior parte di questi comandi SQL e shell può essere inserita in script (es. Bash, Python) e schedulata tramite cron su Linux o Task Scheduler su Windows. Gli output possono essere reindirizzati a file di log o inviati via email per una revisione rapida. Strumenti di monitoraggio professionali come Oracle Enterprise Manager (OEM) o soluzioni di terze parti offrono dashboard complete e alert automatici.

Cosa fare se trovo un problema grave?

In caso di problemi gravi (es. istanza down, tablespace critici pieni, backup falliti), la prima azione è consultare la documentazione interna per le procedure di troubleshooting e escalation. Se non esiste una procedura specifica, investiga l’alert log, i trace file e i log del sistema operativo. Contatta il team di sviluppo o i fornitori dell’applicazione se il problema sembra legato al codice o alla configurazione dell’applicazione. La comunicazione tempestiva è fondamentale.

Questi controlli sono sufficienti per la sicurezza?

No, questi controlli si concentrano sulla disponibilità e performance del database. La sicurezza del database richiede un set di controlli e pratiche molto più ampio, inclusa la gestione degli utenti e dei privilegi, il patching regolare, la crittografia dei dati, l’auditing e il monitoraggio delle attività sospette. Questo set di controlli è un punto di partenza per la gestione operativa, non un sostituto di una strategia di sicurezza completa. Oracle Database Security Guide

Conclusioni con takeaway operativi

Implementare una routine di controlli quotidiani su Oracle è una pratica non negoziabile per ogni DBA che miri alla proattività e alla stabilità del sistema. Gli output reali forniti in questa guida sono il punto di partenza per costruire la tua checklist personalizzata. Ricorda che l’automazione è un tuo alleato prezioso, ma la supervisione umana resta insostituibile per interpretare gli alert e prendere decisioni informate. Un database ben monitorato è un database resiliente, capace di supportare le esigenze operative più stringenti e di prevenire disastri prima che si manifestino pienamente.

Fonti

• Oracle Database Security Guide 19c
• SQL*Plus User’s Guide and Reference 19c
• Oracle Database Administrator’s Guide 19c

Aggiornato: Settembre 2026