Table Function DISPLAY_JOURNAL – Swiss Army Knife (strumento versatile per molte situazioni)

Table Functions: DISPLAY_JOURNAL – un vero Swiss Army Knife

Le funzioni di tabella di IBM iSeries sono come coltellini svizzeri per i dati. Possono essere utilizzate per una varietà di attività, come la manipolazione dei dati, l’interrogazione dei dati e la creazione di report. Sono particolarmente utili per eseguire operazioni complesse che sarebbero altrimenti difficili o impossibili da eseguire con SQL standard.

La funzione di tabella SQL DISPLAY_JOURNAL su IBM iSeries, in particolare, è uno strumento potente per l’analisi e la gestione di transazioni e eventi di sistema.

Essa permette agli utenti di visualizzare e interrogare i dati registrati nei journal di sistema, che sono log dettagliati di tutte le operazioni eseguite.

Questa funzione è particolarmente utile in ambienti complessi e multiutente, dove è fondamentale tracciare le modifiche ai dati e monitorare l’attività del sistema.

vedi anche:

Esempi reali e significativi dove DISPLAY_JOURNAL può essere di grande aiuto

  1. Auditing e Compliance: In ambienti regolamentati, dove è necessario mantenere un registro dettagliato delle attività per conformità normativa, DISPLAY_JOURNAL può essere utilizzato per raccogliere informazioni su chi ha eseguito quali operazioni e quando. Questo è fondamentale per l’audit interno o esterno, la revisione dei controlli interni, e per soddisfare i requisiti normativi.
  2. Analisi di Sicurezza: Per identificare potenziali violazioni della sicurezza o attività sospette, come l’accesso non autorizzato a dati sensibili o la modifica di record critici. DISPLAY_JOURNAL può aiutare a rintracciare l’origine di tali attività, fornendo dettagli sugli utenti coinvolti, l’orario delle operazioni e la natura delle modifiche.
  3. Risoluzione dei Problemi e Debugging: In caso di errori o problemi nei dati, DISPLAY_JOURNAL permette di tracciare indietro le operazioni fino a trovare la causa dell’errore. Ad esempio, se un record è stato erroneamente modificato o eliminato, puoi utilizzare il journal per capire cosa è successo e chi è stato coinvolto.
  4. Analisi del Carico di Lavoro e Ottimizzazione delle Prestazioni: Analizzando le transazioni e le operazioni registrate, è possibile ottenere informazioni sul carico di lavoro sul sistema. Questo può aiutare a identificare i colli di bottiglia, i periodi di picco di attività e le aree che potrebbero beneficiare di ottimizzazione o aggiornamento delle risorse.
  5. Ripristino di Dati: In situazioni dove i dati sono stati accidentalmente modificati o eliminati, DISPLAY_JOURNAL può fornire informazioni essenziali per il ripristino. Ad esempio, se un record è stato cancellato, è possibile utilizzare i dati del journal per ricostruirlo.
  6. Monitoraggio delle Modifiche in Tempo Reale: In un ambiente multiutente, dove le modifiche ai dati avvengono frequentemente, DISPLAY_JOURNAL può essere utilizzato per monitorare le modifiche in tempo reale o quasi reale, permettendo una risposta rapida a eventuali problemi o modifiche non autorizzate.
  7. Statistiche e Analisi delle Tendenze: Analizzando i dati del journal su periodi più lunghi, è possibile identificare tendenze e pattern nel comportamento degli utenti o nell’uso del sistema. Questo può essere utile per la pianificazione delle risorse, per migliorare l’usabilità del sistema o per guidare decisioni di business.

In ognuno di questi scenari, l’abilità di DISPLAY_JOURNAL di fornire una visione dettagliata e cronologica delle operazioni di sistema è di inestimabile valore.

Tuttavia, è importante notare che l’analisi del journal richiede una comprensione tecnica adeguata e, in alcuni casi, può richiedere l’elaborazione e l’interpretazione di grandi quantità di dati.

Descrizione tecnica della Table Function DISPLAY_JOURNAL

Nota: questa è una descrizione generica e i parametri e le colonne effettive possono variare in base alla configurazione del sistema e alla versione del software.

Inoltre, il livello di dettaglio delle informazioni disponibili può dipendere dalle impostazioni di journaling del sistema e dalle autorizzazioni dell’utente che esegue la query.

Parametri

La funzione DISPLAY_JOURNAL() ha due parametri obbligatori e un parametro opzionale:

  • LIBRARY – Il nome della libreria che contiene il journal.
  • JOURNAL – Il nome del journal.
  • OPTIONS – Un’opzione che indica quali colonne del journal devono essere restituite.

I valori possibili per l’opzione OPTIONS sono i seguenti:

  • ‘ALL’ – Restituisce tutte le colonne del journal.
  • ‘RCD’ – Restituisce solo le colonne JOURNAL_DATE, JOURNAL_TIME, JOURNAL_TYPE, JOURNAL_OBJECT, JOURNAL_USER e JOURNAL_PROGRAM.
  • ‘TIMESTAMP’ – Restituisce tutte le colonne del journal, inclusa la colonna JOURNAL_TIMESTAMP.

Informazioni restituite

DISPLAY_JOURNAL, nella sua forma di funzione di tabella su IBM iSeries, permette di interrogare i dati di un journal in un formato tabellare.

Quando viene eseguito:

SELECT * FROM TABLE(DISPLAY_JOURNAL('MYLIB', 'MYJRN', 'ALL')) AS JOURNAL_DATA

si sta richiedendo tutte le colonne disponibili per gli eventi registrati nel journal specificato.

Di seguito le colonne tipiche che potrebbero presentarsi in risposta a tale query:

Ricordare che le colonne effettive possono variare in base alla configurazione del sistema e alla versione del software e può dipendere dalle impostazioni di journaling del sistema e dalle autorizzazioni dell’utente che esegue la query.

  1. ENTRY_TIMESTAMP: Data e ora dell’evento registrato.
  2. SEQUENCE_NUMBER: Numero sequenziale univoco per ogni voce nel journal.
  3. JOURNAL_CODE: Codice che identifica la categoria di journaling (es. trasferimento dati, modifiche ai file).
  4. JOURNAL_CODE: Codice che identifica la categoria di journaling (es. trasferimento dati, modifiche ai file). I valori comuni includono:
    • R: per le operazioni relative ai file record.
    • C: per i cambiamenti di configurazione.
    • J: per le transazioni di journaling.
  5. JOURNAL_ENTRY_TYPE: Tipo specifico di voce del journal (es. aggiunta, cancellazione, modifica).((*) vedi dettagli successivi)
  6. COUNT_OR_RRN: Numero di record relativi all’evento o relative record number.
  7. ENTRY_DATA: Dati effettivi associati all’evento del journal ((**) vedi dettagli successivi).
  8. NULL_VALUE_INDICATORS: Indicatori per valori nulli nei dati dell’evento.
  9. “OBJECT”: Nome dell’oggetto associato all’evento (es. file, programma).
  10. OBJECT_TYPE: Tipo dell’oggetto (es. file, coda di messaggi).
  11. OBJECT_TYPE_INDICATOR: Indicatore del tipo di oggetto.
  12. FILE_TYPE_INDICATOR: Indicatore specifico per il tipo di file.
  13. JOURNAL_IDENTIFIER: Identificativo univoco del journal.
  14. CURRENT_USER: Utente attualmente connesso o responsabile dell’evento.
  15. JOB_NAME: Nome del lavoro che ha generato l’evento.
  16. JOB_USER: Utente associato al lavoro.
  17. JOB_NUMBER: Numero identificativo del lavoro.
  18. THREAD: Identificativo del thread relativo all’evento.
  19. PROGRAM_NAME: Nome del programma associato all’evento.
  20. PROGRAM_LIBRARY: Libreria in cui risiede il programma.
  21. PROGRAM_LIBRARY_ASP_DEVICE: Dispositivo ASP della libreria del programma.
  22. PROGRAM_LIBRARY_ASP_NUMBER: Numero ASP della libreria del programma.
  23. COMMIT_CYCLE: Identifica il ciclo di commit durante il quale si è verificato l’evento.
  24. NESTED_COMMIT_LEVEL: Livello di commit annidato per la transazione.
  25. XID: Transaction ID per transazioni distribuite.
  26. LUW: Unità di lavoro logica (Logical Unit of Work).
  27. REMOTE_PORT: Porta remota associata all’evento.
  28. REMOTE_ADDRESS: Indirizzo remoto associato all’evento.
  29. SYSTEM_NAME: Nome del sistema su cui si è verificato l’evento.
  30. SYSTEM_SEQUENCE_NUMBER: Numero di sequenza a livello di sistema.
  31. REFERENTIAL_CONSTRAINT: Indica se l’evento è associato a un vincolo referenziale.
  32. “TRIGGER”: Indica se l’evento è stato attivato da un trigger.
  33. IGNORE_ON_APPLY: Indica se l’evento deve essere ignorato durante l’applicazione.
  34. MINIMIZED_ENTRY_DATA: Dati dell’evento in forma minimizzata.
  35. MINIMIZED_ON_FIELD_BOUNDARY: Indica se la minimizzazione dei dati avviene sui limiti del campo.
  36. INDICATOR_FLAG: Bandiera indicatrice per varie condizioni.
  37. RECEIVER_NAME: Nome del ricevitore del journal.
  38. RECEIVER_LIBRARY: Libreria del ricevitore del journal.
  39. RECEIVER_ASP_DEVICE: Dispositivo ASP del ricevitore.
  40. RECEIVER_ASP_NUMBER: Numero ASP del ricevitore.
  41. ARM_NUMBER: Numero ARM (Auxiliary Storage Pool Mirror).
  42. OBJECT_ASP_DEVICE: Dispositivo ASP dell’oggetto.
  43. OBJECT_ASP_NUMBER: Numero ASP dell’oggetto.
  44. PARENT_FILE_ID: Identificativo del file padre.
  45. OBJECT_FILE_ID: Identificativo del file oggetto.
  46. RELATIVE_DIRECTORY_FILE_ID: ID del file nella directory relativa.
  47. OBJECT_FILE_NAME: Nome del file oggetto.
  48. PATH_NAME: Percorso dell’oggetto nel file system.
  49. DLO_NAME: Nome del Document Library Object.
  50. FOLDER_PATH: Percorso della cartella.
  51. SYSLOG_EVENT: Evento syslog associato.
  52. SYSLOG_FACILITY: Facility syslog associata.
  53. SYSLOG_SEVERITY: Gravità dell’evento syslog.
  54. SYSLOG_PRIORITY: Priorità dell’evento syslog

(*) Più in  profondità: dettagli informazione JOURNAL_ENTRY_TYPE

La colonna JOURNAL_ENTRY_TYPE contiene la codifica delle tipologie di eventi che possono essere registrati in un journal su un sistema IBM iSeries. Tuttavia, l’interpretazione specifica può variare a seconda della configurazione del sistema e dell’uso specifico dei journal.

  1. BC: Backup Change – Questo tipo di voce di journal viene utilizzato durante le operazioni di backup per registrare le modifiche ai dati che si verificano mentre il backup è in corso. L’obiettivo è garantire l’integrità dei dati durante il processo di backup, consentendo di tenere traccia delle modifiche che avvengono durante l’operazione di backup.
  2. CB: Change Before – Indica un cambiamento nei dati prima che l’operazione venga eseguita. Utilizzato nelle operazioni di aggiornamento per registrare lo stato dei dati prima della modifica.
  3. CG: Change After for Group Commit – Registrare le modifiche ai dati dopo un commit di gruppo.
  4. CH: Change After – Registra le modifiche effettuate ai dati dopo l’operazione.
  5. CM: Commit Cycle Marker – Indica il punto in cui un ciclo di commit è stato completato.
  6. CR: Create Object – Registra la creazione di un nuovo oggetto.
  7. DL: Delete – Questo tipo di voce indica la cancellazione di un oggetto, come un file o un record, dal sistema. È utilizzato per tracciare le operazioni di eliminazione, consentendo di avere una cronistoria delle azioni di cancellazione eseguite su determinati oggetti nel sistema.
  8. EC: Encoded Vector Index – Utilizzato per le operazioni sugli indici vettoriali codificati.
  9. EF: End of File – Indica la fine di un file o un oggetto.
  10. EJ: End Journal – Indica la fine del journaling per un oggetto o un file.
  11. IT: Incomplete Transaction – Transazione incompleta, spesso usata per identificare transazioni che non sono state completate correttamente.
  12. JF: Journal File – Riferito alla registrazione di un file.
  13. JM: Journal Marker – Un segnaposto o un marcatore all’interno del flusso del journal.
  14. PR: Prepare – Preparazione per una transazione, solitamente parte del processo di commit.
  15. PT: Partial Transaction – Indica una transazione parziale, usata per transazioni che non sono state completate.
  16. PX: Proxy – Rappresenta un’azione proxy, come un’operazione eseguita per conto di un’altra.
  17. RD: Delete Record – Indica la cancellazione di un record.
  18. SB: Start Before – Indica l’inizio di un’operazione prima che venga eseguita.
  19. SC: Start Commit – Segna l’inizio di un ciclo di commit.
  20. SQ: Sequence Number – Relativo alla gestione dei numeri di sequenza in un journal.
  21. UB: Update Before – Registra lo stato di un oggetto o di un record prima di un aggiornamento.
  22. UP: Update After – Registra lo stato di un oggetto o di un record dopo un aggiornamento.
  23. XP: Exception – Indica una condizione eccezionale o un’operazione relativa a gestione delle eccezioni.

(**) Più in  profondità: dettagli informazione ENTRY_DATA

La colonna ENTRY_DATA nella funzione DISPLAY_JOURNAL su IBM iSeries contiene informazioni specifiche sull’operazione registrata nel journal.

Questi dati sono spesso unici per ogni tipo di evento e possono variare notevolmente a seconda del tipo di operazione eseguita (come inserimento, aggiornamento, eliminazione, ecc.) e del tipo di oggetto coinvolto (ad esempio, file, record, dati di configurazione).

Alcuni esempi delle informazioni che potrebbero presentarsi nella colonna ENTRY_DATA

1. Inserimento Record: Quando un nuovo record viene inserito in un file di database, la colonna ENTRY_DATA potrebbe contenere i valori effettivi del record inserito. Ad esempio, se è stato inserito un record in un file con campi per nome, età e indirizzo, la colonna ENTRY_DATA potrebbe contenere una stringa come “Mario, 30, Via Roma 123”.

2. Aggiornamento Record: In caso di un’operazione di aggiornamento, la colonna ENTRY_DATA potrebbe contenere i valori sia prima che dopo la modifica. Ad esempio, se un campo “stato” viene modificato da “attivo” a “inattivo”, la colonna ENTRY_DATA potrebbe mostrare qualcosa come “attivo -> inattivo”.

3. Eliminazione Record: Per un’operazione di eliminazione, ENTRY_DATA potrebbe contenere i valori del record che è stato eliminato, simile a un inserimento, ma in questo caso rappresenta il dato rimosso.

4. Transazioni: In caso di eventi legati a transazioni, come un rollback, la colonna ENTRY_DATA potrebbe contenere informazioni sulle modifiche annullate dalla transazione.

5. Dati Binari: Per alcuni tipi di oggetti o operazioni, la colonna ENTRY_DATA potrebbe contenere dati binari o in un formato non immediatamente leggibile, che rappresentano informazioni interne o specifiche del sistema.

È importante notare che il formato e il contenuto esatto della colonna ENTRY_DATA possono essere complessi e dipendono dal contesto specifico dell’operazione di journaling. Inoltre,

interpretare correttamente questi dati richiede una buona comprensione della struttura dei dati del file o dell’oggetto a cui si fa riferimento e delle operazioni eseguite su di essi.

In alcuni casi, potrebbe essere necessario utilizzare strumenti o programmi specifici per decodificare o interpretare i dati presenti in questa colonna.

Alcuni esempi di utilizzo

Individuare quali sono gli archivi coinvolti in aggiornamenti complessi

Per indagare su quali sono gli archivi coinvolti negli aggiornamenti di procedure complesse, è possibile utilizzare le informazioni del journal per identificare le tabelle che vengono modificate durante l’esecuzione della procedura.

Ad esempio, se si vuole indagare sugli aggiornamenti eseguiti da un particolare programma ‘MYPGM’ è possibile utilizzare la seguente query:

SELECT OBJECT, JOURNAL_ENTRY_TYPE, COUNT(*)
FROM TABLE(DISPLAY_JOURNAL('MYLIB', 'MYJRN', 'ALL')) AS JOURNAL_DATA
WHERE PROGRAM = 'MYPGM'
AND ENTRY_TIMESTAMP BETWEEN '2024-01-05 00:00:00.000' and '2024-01-05 23:59:59.9999' 
GROUP BY OBJECT, JOURNAL_ENTRY_TYPE
ORDER BY 1, 2;

In questa query vengono conteggiati, per ogni archivio (OBJECT) quanti entry sono presenti nel Journal raggruppati per tipo operazione (JOURNAL_ENTRY_TYPE).

Individuare tutti gli archivi coinvolti in una particolare operazione

Scenario: in un parco programmi molto esteso e in funzione da molti anni non sempre si hanno le conoscenze di tutti i dettagli degli archivi coinvolti negli aggiornamenti. In una situazione del genere potrebbe essere di grande aiuto avere l’elenco di tutti gli archivi interessati da particolari operazioni (ad es. chiusura contabile del mese, consolidamento fatturazione, aggiornamento contabile di un cliente, ecc.). In questi casi, utilizzando uno user specifico (diverso da quelli abituali, in modo da individuarlo precisamente nel journal) si potrebbe eseguire la sola operazione interessata e poi indagare sul journal tutti gli archivi coinvolti.

Il comando tipo che potrebbe essere utilizzato è il seguente:

select OBJECT,  JOURNAL_ENTRY_TYPE, count(*)
from TABLE(DISPLAY_JOURNAL('MYLIB', 'MYJRN','ALL')) AS JOURNAL_DATA
WHERE ENTRY_TIMESTAMP BETWEEN  '2024-01-09 00:00:00.000' and '2024-01-09 23:59:59.9999'
  AND JOB_USER ='USERTEST'
group by OBJECT, JOURNAL_ENTRY_TYPE order by 1,2;

In questo modo si ottengono tutti gli archivi interessati dalle operazioni svolte dall’utente ‘USERTEST’ nell’arco temporale interessato (ENTRY_TIMESTAMP).

Individuare distribuzione temporale degli inserimenti in un particolare achivio

Per indagare sulla distribuzione temporale, ad esempio nell’arco di un mese, delle modifiche in un particolare archivio è possibile utilizzare una query del tipo:

SELECT SUBSTRING(CHAR(ENTRY_TIMESTAMP), 1, 10), count(*)
FROM TABLE(DISPLAY_JOURNAL('MYLIB', 'MYJRN', 'ALL')) AS JOURNAL_DATA
WHERE OBJECT = 'MYFILE'
AND ENTRY_TIMESTAMP BETWEEN  '2023-12-01 00:00:00.000' and '2023-12-31 23:59:59.9999' 
GROUP BY SUBSTRING(CHAR(ENTRY_TIMESTAMP), 1, 10)
ORDER BY 1;

In questa query vengono conteggiati, per ogni giorno del mese considerato, quanti entry sono presenti nel Journal relativi all’archivio (OBJECT) ‘MYFILE’.

Analizzare gli ENTRY_TYPE di una elaborazione

Per indagare sui ti pi di operazioni effettuate un una determinata elaborazione si può utilizzare una query del tipo seguente:

WITH TABLE_ET (ENTRY_TYPE, DESCRIPTION)
        as (values ('BC', 'Backup Change'), ('CB', 'Change Before'),
           ('CG', 'Change After for Group Commit'), ('CH', 'Change After'),
	   ('CM', 'Commit Cycle Marker'), ('CR', 'Create Object'),
	   ('DL', 'Delete'), ('EC', 'Encoded Vector Index'),
	   ('EF', 'End of File'), ('EJ', 'End Journal'),
	   ('IT', 'Incomplete Transaction'), ('JF', 'Journal File'),
	   ('JM', 'Journal Marker'), ('PR', 'Prepare'),
	   ('PT', 'Partial Transaction'), ('PX', 'Proxy'),
	   ('RD', 'Delete Record'), ('SB', 'Start Before'),
	   ('SC', 'Start Commit'), ('SQ', 'Sequence Number'),
	   ('UB', 'Update Before'), ('UP', 'Update After'),
	   ('XP', 'Exception'))
select COALESCE(OBJECT,'null'), JOURNAL_ENTRY_TYPE, TABLE_ET.DESCRIPTION, count(*) "COUNT"
from TABLE(DISPLAY_JOURNAL('NEWDWHF', 'DWHJRN','ALL')) AS JOURNAL_DATA
LEFT OUTER JOIN TABLE_ET
  ON JOURNAL_ENTRY_TYPE = TABLE_ET.ENTRY_TYPE
 WHERE ENTRY_TIMESTAMP BETWEEN  '2024-01-07 00:00:00.000' and '2024-01-07 23:59:59.9999'
group by OBJECT, JOURNAL_ENTRY_TYPE, TABLE_ET.DESCRIPTION order by 1,2;

Di seguito un esempio di risultato ottenuto:

OBJECT                          ET DESCRIPTION_ENTRY_TYPE     COUNT
DWHJRN1466DWHFILE               RD Delete Record                    1
DWHJRN1466DWHFILE               XP Exception                        1
DWHJRN1467DWHFILE               RD Delete Record                    1
DWHJRN1467DWHFILE               XP Exception                        1
GCSDAT1701DWHFILE   GCSDAT1701  CB Change Before                    1
GCSDAT1701DWHFILE   GCSDAT1701  UB Update Before              1050324
GCSDAT1701DWHFILE   GCSDAT1701  UP Update After               1050324
GISDAT1701DWHFILE   GISDAT1701  PT Partial Transaction              3
GISDAT1701DWHFILE   GISDAT1701  UB Update Before                    3
GISDAT1701DWHFILE   GISDAT1701  UP Update After                     3
XX_DWH_LOGDWHFILE   XX_DWH_LOG  PT Partial Transaction              5
SDATSEMSVCDWHFILE   SDATSEMSVC  UB Update Before                    1
SDATSEMSVCDWHFILE   SDATSEMSVC  UP Update After                     3
SDAT001701DWHFILE               CG Change After for Group Commit    1
SDAT001701DWHFILE               EF End of File                      1
SDAT001701DWHFILE               JF Journal File                     1
SDAT001701DWHFILE   SDAT001701  CH Change After                     1
SDAT001701DWHFILE   SDAT001701  EJ End Journal                      1
SDAT001701DWHFILE   SDAT001701  IT Incomplete Transaction           1
SDAT001701DWHFILE   SDAT001701  JM Journal Marker                   1
SDAT001701DWHFILE   SDAT001701  PX Proxy                            3
SDATEMSVCRDWHFILE   SDATEMSVCR  PX Proxy                            3
null                            CM Commit Cycle Marker              1
null                            EC Encoded Vector Index             1
null                            PR Prepare                          1
null                            SB Start Before                     3
null                            SQ Sequence Number                  3

Conclusioni

La funzione di tabella SQL DISPLAY_JOURNAL su IBM iSeries è uno strumento potente per l’analisi e la gestione di transazioni e eventi di sistema.

Essa permette agli utenti di visualizzare e interrogare i dati registrati nei journal di sistema, che sono log dettagliati di tutte le operazioni eseguite.

Questa funzione è particolarmente utile in ambienti complessi e multiutente, dove è fondamentale tracciare le modifiche ai dati e monitorare l’attività del sistema.

Tenere presente che l’implementazione e le funzionalità effettive potrebbero variare a seconda della versione del sistema operativo iSeries e del database DB2. È sempre buona norma fare riferimento alla documentazione ufficiale IBM per avere informazioni più precise e dettagliate

Articoli simili