IBM Tivoli Netcool/OMNIbus: Guida all`amministrazione

annuncio pubblicitario
Tivoli Netcool/OMNIbus
®
Versione 7 Release 3
Guida all’amministrazione
SC13-4178-00
Tivoli Netcool/OMNIbus
®
Versione 7 Release 3
Guida all’amministrazione
SC13-4178-00
Nota
Prima di utilizzare queste informazioni ed il prodotto supportato, leggere le informazioni contenute in “Informazioni
particolari” a pagina 351.
Questa edizione si riferisce alla versione 7, release 3 di IBM Tivoli Netcool/OMNIbus (numero prodotto 5724-S44) e
a tutte le release e modifiche successive, se non diversamente indicato nelle nuove edizioni.
© Copyright International Business Machines Corporation 1994, 2009.
Indice
Informazioni su questa pubblicazione
vii
A chi è rivolto questo manuale . . . . . . . . vii
Contenuto di questa pubblicazione . . . . . . vii
Pubblicazioni . . . . . . . . . . . . . viii
Accesso facilitato. . . . . . . . . . . . . ix
Addestramento tecnico Tivoli . . . . . . . . . x
Informazioni sul supporto . . . . . . . . . . x
Convenzioni utilizzate in questa pubblicazione . . . x
Capitolo 1. Configurazione
dell’ObjectServer . . . . . . . . . . . 1
Elaborazione degli avvisi nell’ObjectServer . . . . 1
Utilizzo delle proprietà e delle opzioni della riga
comandi dell’ObjectServer . . . . . . . . . . 1
Proprietà e opzioni della riga comandi
dell’ObjectServer . . . . . . . . . . . . 3
Esecuzione dell’ObjectServer in modalità sicura . . 19
Aggiornamenti degli strumenti client utilizzando
IDUC . . . . . . . . . . . . . . . . 21
Specifica dell’intervallo di aggiornamento IDUC 21
Specifica della porta IDUC . . . . . . . . 21
Configurazione dell’ObjectServer per il supporto
multiculturale . . . . . . . . . . . . . 22
Archiviazione e checkpoint dei dati . . . . . . 23
Archiviazione dei dati mediante memstore . . . 23
Introduzione al checkpoint . . . . . . . . 24
Programma di utilità per la verifica del
checkpoint nco_check_store . . . . . . . . 25
Modifica dei limiti flessibili e rigidi del memstore
table_store . . . . . . . . . . . . . . 26
Invio di avvisi all’ObjectServer utilizzando
nco_postmsg . . . . . . . . . . . . . . 27
Proprietà e opzioni della riga comandi di
nco_postmsg . . . . . . . . . . . . . 31
Esempi di nco_postmsg e istruzioni INSERT
risultanti . . . . . . . . . . . . . . 34
Capitolo 2. Configurazione di un server
proxy . . . . . . . . . . . . . . . 37
Avvio del server proxy . . . . . . . . .
Avvio di un server proxy mediante il controllo
processi . . . . . . . . . . . . .
Avvio di un server proxy mediante i servizi
(Windows). . . . . . . . . . . . .
Avvio manuale del server proxy . . . . .
Opzioni di riga comandi e proprietà del server
proxy . . . . . . . . . . . . . .
Connessione al server proxy . . . . . . . .
Esecuzione del server proxy in modalità sicura .
. 37
. 37
. 38
. 38
. 38
. 41
. 41
Capitolo 3. Utilizzo di Netcool/OMNIbus
Administrator per configurare
ObjectServer . . . . . . . . . . . . 45
© Copyright IBM Corp. 1994, 2009
Informazioni preliminari su Netcool/OMNIbus
Administrator . . . . . . . . . . . . . 45
Considerazioni sul supporto multiculturale . . . 45
Avvio di Netcool/OMNIbus Administrator . . . 46
Connessione a un ObjectServer . . . . . . . 49
Connessione a un agent del processo . . . . . 50
Utilizzo dei componenti di Tivoli
Netcool/OMNIbus . . . . . . . . . . . 52
Connessioni SSL (Secure Sockets Layer) . . . . 52
Selezione degli oggetti ObjectServer da
configurare . . . . . . . . . . . . . 53
Impostazione delle preferenze in
Netcool/OMNIbus Administrator . . . . . . 54
Come uscire da Netcool/OMNIbus
Administrator . . . . . . . . . . . . 57
Gestione dell’autorizzazione con utenti, gruppi,
ruoli e filtri limitazioni . . . . . . . . . . 58
Configurazione dei ruoli . . . . . . . . . 58
Configurazione dei gruppi . . . . . . . . 63
Configurazione degli utenti . . . . . . . . 66
Configurazione dei filtri limitazioni . . . . . 70
Configurazione di menu, strumenti e prompt . . . 72
Personalizzazione dei menu . . . . . . . . 73
Configurazione degli strumenti . . . . . . . 77
Configurazione dei prompt . . . . . . . . 80
Configurazione di automazioni . . . . . . . . 84
Configurazione dei trigger . . . . . . . . 85
Configurazione delle procedure. . . . . . . 96
Configurazione dei segnali . . . . . . . . 104
Configurazione dell’aspetto dell’elenco eventi . . 107
Creazione e modifica di conversioni . . . . . 107
Eliminazione di conversioni . . . . . . . 108
Creazione e modifica dei colori per la severità
degli eventi per elenchi eventi Windows . . . 108
Creazione e modifica di visuali di colonne. . . 109
Eliminazione di visuali di colonne . . . . . 110
Creazione e modifica di classi . . . . . . . 110
Eliminazione di classi. . . . . . . . . . 111
Configurazione di database, file, proprietà,
connessioni e canali ObjectServer . . . . . . . 111
Configurazione dei database . . . . . . . 111
Visualizzazione e modifica delle proprietà
ObjectServer . . . . . . . . . . . . . 116
Configurazione dei file ObjectServer . . . . . 117
Monitoraggio delle connessioni all’ObjectServer 120
Configurazione di canali . . . . . . . . 120
Utilizzo dell’interfaccia interattiva SQL in modalità
GUI . . . . . . . . . . . . . . . . 120
Capitolo 4. SQL ObjectServer . . . . 123
Interfaccia interattiva SQL . . . . . . . .
Avvio dell’interfaccia interattiva SQL . . .
Esecuzione di comandi SQL nell’interfaccia
interattiva SQL . . . . . . . . . . .
. 123
. 124
. 126
iii
Esecuzione dell’interfaccia interattiva SQL in
modalità sicura . . . . . . . . . . . .
Codifica delle password negli script nco_sql
UNIX . . . . . . . . . . . . . . .
Come uscire dall’interfaccia interattiva SQL . .
Creazione, modifica ed eliminazione di oggetti
ObjectServer. . . . . . . . . . . . . .
Database . . . . . . . . . . . . . .
Tabelle . . . . . . . . . . . . . .
Indici . . . . . . . . . . . . . . .
Viste . . . . . . . . . . . . . . .
Filtri limitazioni . . . . . . . . . . .
File . . . . . . . . . . . . . . . .
Parole riservate . . . . . . . . . . . . .
Blocchi di creazione SQL . . . . . . . . .
Operatori. . . . . . . . . . . . . .
Funzioni . . . . . . . . . . . . . .
Espressioni . . . . . . . . . . . . .
Condizioni . . . . . . . . . . . . .
Ricerca e manipolazione dei dati utilizzando l’SQL
dell’ObjectServer . . . . . . . . . . . .
Inserimento di una nuova riga di dati in una
tabella (comando INSERT) . . . . . . . .
Aggiornamento dei dati nelle colonne di tabella
(comando UPDATE) . . . . . . . . . .
Eliminazione di righe di dati da una tabella
(comando DELETE) . . . . . . . . . .
Richiamo di dati da una tabella o da una vista
(comando SELECT) . . . . . . . . . .
Informazioni di registrazione nei file
ObjectServer (comando WRITE INTO) . . . .
Visualizzazione dei dettagli relativi alle colonne
di una tabella o di una vista (comando
DESCRIBE) . . . . . . . . . . . . .
Aggiunta o aggiornamento dei dati relativi allo
stato dei servizi (comando SVC) . . . . . .
Invio di notifiche IDUC a client IDUC (comando
IDUC FLUSH) . . . . . . . . . . . .
Modifica delle impostazioni predefinite e correnti
dell’ObjectServer (comando ALTER SYSTEM) . .
Impostazione del database predefinito (comandi
SET DATABASE e USE DATABASE) . . . . .
Verifica della sintassi SQL (comando CHECK
STATEMENT) . . . . . . . . . . . . .
Creazione, modifica ed eliminazione di utenti,
gruppi e ruoli . . . . . . . . . . . . .
Creazione di un utente (comando CREATE
USER) . . . . . . . . . . . . . . .
Modifica dei dettagli di un utente esistente
(comando ALTER USER) . . . . . . . .
Eliminazione di un utente (comando DROP
USER) . . . . . . . . . . . . . . .
Creazione di un gruppo (comando CREATE
GROUP) . . . . . . . . . . . . . .
Modifica dei dettagli di un gruppo esistente
(comando ALTER GROUP) . . . . . . . .
Eliminazione di un gruppo (comando DROP
GROUP) . . . . . . . . . . . . . .
Creazione di un ruolo (comando CREATE
ROLE). . . . . . . . . . . . . . .
iv
129
129
129
130
130
132
140
142
143
145
147
148
148
154
160
160
Modifica della descrizione di un ruolo
(comando ALTER ROLE) . . . . . . . .
Utilizzo dei ruoli per assegnare autorizzazioni
agli utenti . . . . . . . . . . . . .
Eliminazione di un ruolo (comando DROP
ROLE). . . . . . . . . . . . . . .
Creazione, esecuzione ed eliminazione di
procedure . . . . . . . . . . . . . .
Procedure SQL . . . . . . . . . . . .
Procedure esterne . . . . . . . . . . .
Esecuzione di procedure. . . . . . . . .
Eliminazione di procedure . . . . . . . .
Configurazione dell’automazione utilizzando
trigger. . . . . . . . . . . . . . . .
Creazione, modifica ed eliminazione di gruppi
di trigger . . . . . . . . . . . . . .
Creazione, modifica ed eliminazione di trigger
Automazioni di Tivoli Netcool/OMNIbus standard
Automazione per SAE (Service Affected Event)
Esempi di automazione . . . . . . . . .
177
177
184
184
184
193
194
195
195
195
197
220
226
227
161
162
162
163
164
168
168
169
170
170
171
172
172
173
174
175
175
175
176
176
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Capitolo 5. Configurazione della
notifica eventi accelerati . . . . . . 231
Configurazione di un probe per contrassegnare
eventi per l’accelerazione . . . . . . . . .
Configurazione di un gateway per la notifica
eventi accelerati . . . . . . . . . . . .
Configurazione della tabella alerts.status per la
ricezione dell’indicatore per la notifica eventi
accelerati . . . . . . . . . . . . . . .
Configurazione di canali per trasmettere dati
evento . . . . . . . . . . . . . . . .
Creazione e modifica di canali. . . . . . .
Operazioni di copia e incolla sui canali . . . .
Eliminazione di un canale . . . . . . . .
Invio di messaggi ai destinatari dei canali . . .
Disconnessione dei client AEN (Accelerated
Event Notification) . . . . . . . . . .
Arresto dei client AEN (Accelerated Event
Notification) . . . . . . . . . . . . .
Configurazione di trigger per supportare la notifica
eventi accelerati . . . . . . . . . . . .
232
232
233
233
234
237
237
238
238
239
240
Capitolo 6. Utilizzo del controllo
processi per gestire processi e
procedure esterne . . . . . . . . . 241
Come si collegano gli agent del processo . . .
Componenti del controllo processi . . . . .
Agent del processo . . . . . . . . .
Processi . . . . . . . . . . . . .
Servizi. . . . . . . . . . . . . .
Programmi di utilità del controllo processi .
Creazione e avvio di un sistema di rete per il
controllo processi . . . . . . . . . . .
Prima di configurare il controllo processi . .
Creazione di gruppi di utenti UNIX per il
sistema per il controllo processi . . . . .
Requisiti degli account Windows per il sistema
per il controllo processi . . . . . . . .
.
.
.
.
.
.
241
242
242
243
243
244
. 244
. 245
. 245
. 246
Configurazione delle informazioni sulle
comunicazioni del server per gli agent del
processo . . . . . . . . . . . . . .
Aggiornamento del file di configurazione
predefinito del controllo processi . . . . . .
Avvio manuale degli agent del processo . . .
Avvio automatico degli agent del processo su
UNIX . . . . . . . . . . . . . . .
Avvio automatico degli agent del processo su
Windows . . . . . . . . . . . . . .
Gestione della configurazione del sistema per il
controllo processi . . . . . . . . . . .
Configurazione e gestione del controllo processi
dalla riga comandi . . . . . . . . . . .
Definizione di processi, servizi e host per il
controllo processi . . . . . . . . . . .
Gestione del controllo processi utilizzando
programmi di utilità . . . . . . . . . .
Utilizzo di Netcool/OMNIbus Administrator per
gestire il controllo processi . . . . . . . . .
Connessione a un agent del processo . . . .
Visualizzazione e configurazione delle
informazioni relative allo stato per un agent del
processo . . . . . . . . . . . . . .
Visualizzazione dei processi e dei servizi per un
agent del processo. . . . . . . . . . .
Configurazione di servizi per un agent del
processo . . . . . . . . . . . . . .
Configurazione dei processi . . . . . . .
Come copiare e incollare un servizio o un
processo tra host dell’agent del processo . . .
Esecuzione di un’azione esterna . . . . . .
Arresto di un agent del processo . . . . . .
Utilizzo del controllo processi per eseguire
procedure esterne nelle automazioni. . . . . .
246
247
247
254
255
256
256
256
267
275
275
277
278
279
282
287
288
289
289
Capitolo 7. Ottimizzazione delle
prestazioni . . . . . . . . . . . . 291
Migliori pratiche per l’ottimizzazione delle
prestazioni . . . . . . . . . . . .
Linee guida per le query SQL . . . . . .
Regole di ottimizzazione per query SQL .
Linee guide relative all’indicizzazione . .
Esempi di utilizzo di indici con query SQL
Esempio di utilizzo di indici con trigger o
procedure . . . . . . . . . . .
Migliori pratiche per la creazione di trigger .
.
.
.
.
.
.
.
.
.
.
291
299
299
301
303
.
.
. 304
. 305
Appendice A. Tabelle
dell’ObjectServer . . . . . . . . . . 311
Tabelle Alerts . . . . . . . .
Tabella alerts.status . . . . .
Tabella alerts.details . . . . .
Tabella alerts.journal . . . . .
Tabella alerts.iduc_messages . .
Tabella alerts.application_types .
Tabella master.class_membership .
Tabelle di servizio . . . . . . .
Tabella service.status . . . . .
Tabelle del catalogo di sistema . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
311
311
318
319
320
320
321
321
321
322
Tabella catalog.memstores . . . . . . .
Tabella catalog.databases . . . . . . .
Tabella catalog.tables . . . . . . . . .
Tabella catalog.base_tables . . . . . . .
Tabella catalog.views . . . . . . . . .
Tabella catalog.files . . . . . . . . .
Tabella catalog.restrictions . . . . . . .
Tabella catalog.columns . . . . . . . .
Tabella catalog.primitive_signals . . . . .
Tabella catalog.primitive_signal_parameters .
Tabella catalog.trigger_groups . . . . . .
Tabella catalog.triggers . . . . . . . .
Tabella catalog.database_triggers . . . . .
Tabella catalog.signal_triggers . . . . . .
Tabella catalog.temporal_triggers . . . . .
Tabella catalog.procedures . . . . . . .
Tabella catalog.sql_procedures . . . . . .
Tabella catalog.external_procedures . . . .
Tabella catalog.procedure_parameters . . .
Tabella catalog.connections . . . . . . .
Tabella catalog.properties . . . . . . .
Tabella catalog.security_permissions . . . .
Tabella catalog.profiles . . . . . . . .
Tabella catalog.indexes . . . . . . . .
Tabelle di statistiche . . . . . . . . . .
Tabella catalog.profiles . . . . . . . .
Tabella master.stats . . . . . . . . .
Tabella catalog.trigger_stats. . . . . . .
Tabella catalog.channel_stats . . . . . .
Tabelle di supporto degli strumenti client . . .
Tabella alerts.resolutions. . . . . . . .
Tabella alerts.conversions . . . . . . .
Tabella alerts.col_visuals. . . . . . . .
Tabella alerts.colors . . . . . . . . .
Tabelle degli strumenti desktop . . . . . .
Tabella tools.actions . . . . . . . . .
Tabella tools.action_access . . . . . . .
Tabella tools.menus . . . . . . . . .
Tabella tools.menu_items . . . . . . .
Tabella tools.prompt_defs . . . . . . .
Tabella tools.menu_defs . . . . . . . .
Tabelle dell’ObjectServer desktop . . . . . .
Tabella master.national . . . . . . . .
Tabella master.servergroups . . . . . .
Tabelle di sicurezza per compatibilità con versioni
precedenti . . . . . . . . . . . . .
Tabelle di IDUC . . . . . . . . . . .
Tabella iduc_system.channel . . . . . .
Tabella iduc_system.channel_interest . . .
Tabella iduc_system.channel_summary . . .
Tabella iduc_system.channel_summary_cols .
Tabella iduc_system.iduc_stats. . . . . .
Tabelle SAE (Service Affected Event) . . . .
Tabella precision.service_affecting_event . .
Tabella precision.service_details . . . . .
Tabella precision.entity_service . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
322
322
323
323
324
324
325
325
325
326
326
326
327
328
328
328
328
329
329
330
330
330
331
332
332
332
333
334
335
335
335
336
336
337
338
338
339
339
339
340
340
341
341
342
.
.
.
.
.
.
.
.
.
.
.
342
342
342
343
343
343
344
344
344
344
345
Indice
v
Appendice B. Pulsanti helper,
espressioni variabili e comandi SQL
in strumenti, automazioni ed elenchi
eventi transitori . . . . . . . . . . 347
vi
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Informazioni particolari . . . . . . . 351
Marchi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 353
Indice analitico. . . . . . . . . . . 355
Informazioni su questa pubblicazione
Tivoli Netcool/OMNIbus è un sistema di gestione livello di servizio (SLM, service
level management) che offre un monitoraggio centralizzato, in tempo reale, di reti
e domini IT complessi.
IBM Tivoli Netcool/OMNIbus - Guida all’amministrazione fornisce informazioni
dettagliate su strumenti amministrativi, funzioni e funzionalità di Tivoli
Netcool/OMNIbus. Inoltre, è destinato ad essere utilizzato come guida di
riferimento per assistere l’utente nella progettazione e configurazione
dell’ambiente.
A chi è rivolto questo manuale
Questa pubblicazione è rivolta agli amministratori responsabili della
configurazione di Tivoli Netcool/OMNIbus.
Contenuto di questa pubblicazione
Questa pubblicazione contiene le seguenti sezioni:
v Capitolo 1, “Configurazione dell’ObjectServer”, a pagina 1
Descrive come configurare l’ObjectServer, che è il repository centrale dei dati.
v Capitolo 2, “Configurazione di un server proxy”, a pagina 37
Descrive come configurare un server proxy per ridurre il numero di connessioni
probe a un ObjectServer.
v Capitolo 3, “Utilizzo di Netcool/OMNIbus Administrator per configurare
ObjectServer”, a pagina 45
Descrive come utilizzare Netcool/OMNIbus Administrator per configurare e
gestire gli ObjectServer.
v Capitolo 4, “SQL ObjectServer”, a pagina 123
Descrive le strutture dati dell’ObjectServer e la sintassi dell’SQL ObjectServer.
v Capitolo 5, “Configurazione della notifica eventi accelerati”, a pagina 231
Descrive come configurare Tivoli Netcool/OMNIbus per AEN (Accelerated
Event Notification) per eventi che potrebbero presentare un rischio per il
sistema.
v Capitolo 6, “Utilizzo del controllo processi per gestire processi e procedure
esterne”, a pagina 241
Descrive i componenti, la configurazione e i programmi di utilità di gestione
associati al sistema per il controllo processi di Tivoli Netcool/OMNIbus. Include
inoltre informazioni sulla configurazione e gestione del controllo processi
utilizzando programmi di utilità dei comandi e Netcool/OMNIbus
Administrator.
v Capitolo 7, “Ottimizzazione delle prestazioni”, a pagina 291
Descrive come monitorare e ottimizzare le prestazioni di Tivoli
Netcool/OMNIbus.
v Appendice A, “Tabelle dell’ObjectServer”, a pagina 311
Contiene le informazioni sulle tabelle di database dell’ObjectServer.
© Copyright IBM Corp. 1994, 2009
vii
v Appendice B, “Pulsanti helper, espressioni variabili e comandi SQL in strumenti,
automazioni ed elenchi eventi transitori”, a pagina 347
Fornisce informazioni di riferimento sui comandi SQL comuni, le espressioni
variabili e i pulsanti helper che sono utilizzati in strumenti, automazioni ed
elenchi eventi transitori.
Pubblicazioni
In questa sezione sono elencate le pubblicazioni nella libreria Tivoli
Netcool/OMNIbus e i documenti correlati. Nella sezione viene descritto anche
come accedere alle pubblicazioni Tivoli in linea e come ordinare le pubblicazioni
Tivoli.
Libreria Tivoli Netcool/OMNIbus
I seguenti documenti sono disponibili nella libreria Tivoli Netcool/OMNIbus:
v IBM Tivoli Netcool/OMNIbus - Guida all’installazione e alla distribuzione, SC13-4177
Include le procedure di installazione e di aggiornamento per Tivoli
Netcool/OMNIbus, e descrive come configurare la sicurezza e le comunicazioni
tra i componenti. La pubblicazione include anche degli esempi di architetture
Tivoli Netcool/OMNIbus e descrive come implementarle.
v IBM Tivoli Netcool/OMNIbus - Guida all’amministrazione, SC13-4178
Descrive come eseguire le attività amministrative tramite il controllo processi, gli
strumenti della riga comandi e la GUI Administrator di Tivoli
Netcool/OMNIbus. La pubblicazione contiene anche delle descrizioni e degli
esempi delle automazioni e della sintassi SQL dell’ObjectServer.
v IBM Tivoli Netcool/OMNIbus - Guida all’amministrazione e guida per l’utente di Web
GUI, SC13-4179
Descrive come eseguire attività di visualizzazione eventi e amministrative
tramite Tivoli Netcool/OMNIbus Web GUI.
v IBM Tivoli Netcool/OMNIbus User’s Guide, SC23-9683
Fornisce una panoramica degli strumenti del desktop e descrive le attività
dell’operatore correlate alla gestione eventi utilizzando tali strumenti.
v IBM Tivoli Netcool/OMNIbus - Guida a probe e gateway, SC13-4180
Contiene informazioni di introduzione e di riferimento su probe e gateway,
compresi la sintassi del file di regole dei probe e i comandi gateway.
v IBM Tivoli Monitoring for Tivoli Netcool/OMNIbus Agent - Guida per l’utente,
SC13-4183
Descrive come installare l’agent di monitoraggio integrità per Tivoli
Netcool/OMNIbus e contiene informazioni di riferimento sull’agent.
v IBM Tivoli Netcool/OMNIbus - Guida di riferimento a Event Integration Facility,
SC13-4182
Descrive come sviluppare adattatori eventi personalizzati in base all’ambiente di
rete e alle esigenze specifiche dell’azienda. Questa pubblicazione descrive inoltre
come filtrare gli eventi all’origine.
Accesso alla terminologia in linea
Il Glossario software Tivoli include le definizioni per molti termini tecnici relativi al
software Tivoli. Il Glossario software Tivoli è disponibile nel seguente sito Web della
libreria software Tivoli:
viii
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
http://publib.boulder.ibm.com/tividd/glossary/tivoliglossarymst.htm
Il sito Web relativo alla terminologia IBM raggruppa la terminologia proveniente
dalle librerie di prodotti IBM in un’ubicazione dedicata. È possibile accedere al sito
Web relativo alla terminologia al seguente indirizzo Web:
http://www.ibm.com/software/globalization/terminology
Accesso alle pubblicazioni in linea
IBM invia le pubblicazioni per questo prodotto e per tutti gli altri prodotti Tivoli,
non appena queste diventano disponibili e a ogni loro aggiornamento, al sito Web
del centro informazioni del software Tivoli:
http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp
Nota: Se si stampano documenti PDF su un formato foglio diverso da quello
lettera, impostare l’opzione nella finestra File → Stampa che consente ad Adobe®
Reader di stampare pagine in formato lettera sul tipo di foglio utilizzato.
Come ordinare le pubblicazioni
È possibile ordinare molte pubblicazioni Tivoli in linea nel seguente sito Web:
http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss
È possibile inoltre ordinare per telefono chiamando uno di questi numeri:
v Negli Stati Uniti: 800-879-2755
v In Canada: 800-426-4968
In altri paesi, contattare il rappresentante account software per ordinare
pubblicazioni Tivoli. Per individuare il numero di telefono del proprio
rappresentante locale, attenersi alla seguente procedura:
1. Andare al seguente sito Web:
http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss
2. Selezionare il proprio paese dall’elenco e fare clic su Go. Viene visualizzata la
pagina Welcome to the IBM Publications Center per il proprio paese.
3. Nella parte sinistra della pagina, fare clic su About this site per visualizzare
una pagina informativa che include il numero di telefono del proprio
rappresentante locale.
Accesso facilitato
Le funzioni di accesso facilitato consentono agli utenti con disabilità fisica, come ad
esempio con problemi motori o con problemi alla vista, di utilizzare correttamente
i prodotti software.
Con questo prodotto, è possibile utilizzare tecnologie di supporto per l’ascolto e la
navigazione nell’interfaccia. È inoltre possibile utilizzare la tastiera invece del
mouse per adoperare alcune delle funzioni della GUI (Graphical User Interface).
Informazioni su questa pubblicazione
ix
Addestramento tecnico Tivoli
Per informazioni sull’addestramento tecnico Tivoli, fare riferimento al seguente sito
Web relativo alla formazione IBM Tivoli:
http://www.ibm.com/software/tivoli/education
Informazioni sul supporto
In caso di un problema con il software IBM, si desidera risolverlo rapidamente.
IBM fornisce le seguenti modalità per consentire all’utente di ottenere il supporto
necessario:
In linea
Andare al sito IBM Software Support all’indirizzo http://www.ibm.com/
software/support/probsub.html e seguire le istruzioni.
IBM Support Assistant
IBM Support Assistant (ISA) è un workbench gratuito del livello di servizio
software locale che consente di risolvere domande e problemi correlati ai
prodotti software IBM. ISA fornisce accesso rapido a informazioni correlate
al supporto, nonché strumenti del livello di servizio per la determinazione
dei problemi. Per installare il software ISA, andare all’indirizzo
http://www.ibm.com/software/support/isa.
Convenzioni utilizzate in questa pubblicazione
Questa pubblicazione utilizza diverse convenzioni per azioni e termini speciali e
per percorsi e comandi dipendenti dal sistema operativo.
Convenzioni del carattere tipografico
Questa pubblicazione utilizza le seguenti convenzioni del carattere tipografico:
Grassetto
v Comandi in caratteri minuscoli e comandi con una combinazione di
caratteri maiuscoli e minuscoli altrimenti difficili da distinguere dal testo
circostante
v Controlli dell’interfaccia (caselle di spunta, pulsanti, pulsanti di opzione,
pulsanti di selezione ciclica, campi, cartelle, icone, caselle di elenco,
elementi all’interno delle caselle di elenco, elenchi a più colonne,
contenitori, scelte del menu, nomi del menu, schede, fogli proprietà),
etichette (come ad esempio Suggerimento: e Considerazioni sul sistema
operativo:)
v Parole chiave e parametri nel testo
Corsivo
v Citazioni (esempi: titoli di pubblicazioni, dischetti e CD)
v Termini definiti nel testo (esempio: una linea non commutata viene
definita una linea point-to-point)
v Enfasi sulle parole e sulle lettere (esempio di parole: ″Utilizzo della
parola che per introdurre una frase limitativa.″; esempio di lettere:
″L’indirizzo LUN deve iniziare con la lettera L.″)
v Nuovi termini nel testo (tranne in un elenco di definizioni): una vista è
un frame nell’area di lavoro che contiene dati
x
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
v Variabili e valori che è necessario fornire: ... dove nomeutente
rappresenta....
Spaziatura fissa
v Esempi e esempi di codice
v Nomi di file, parole chiave di programmazione e altri elementi
difficilmente distinguibili dal testo circostante
v Testo del messaggio e richieste rivolte all’utente
v Testo che deve essere immesso dall’utente
v Valori per argomenti o opzioni comando
Variabili e percorsi dipendenti dal sistema operativo
Questa pubblicazione utilizza le convenzioni UNIX® per la specifica delle variabili
di ambiente e la notazione di directory.
Quando si utilizza la riga comandi di Windows®, sostituire $variabile con
%variabile% per le variabili di ambiente e sostituire ogni barra (/) con una barra
retroversa (\) nei percorsi di directory. Ad esempio, nei sistemi UNIX, la variabile
di ambiente $NCHOME specifica il percorso della directory home di Netcool. Nei
sistemi Windows, la variabile di ambiente %NCHOME% specifica il percorso della
directory home di Netcool. I nomi delle variabili di ambiente non sono sempre
uguali in ambienti Windows e UNIX. Ad esempio, %TEMP% in ambienti Windows
equivale a $TMPDIR in ambienti UNIX.
Se si utilizza la shell bash in un sistema Windows, è possibile utilizzare le
convenzioni UNIX.
Nomi di directory specifici del sistema operativo
Dove i file Tivoli Netcool/OMNIbus sono identificati in base all’ubicazione nella
directory arch in NCHOME, arch è una variabile che rappresenta la directory del
sistema operativo in uso, come indicato nella tabella seguente.
Tabella 1. Nomi di directory per la variabile arch
Nome directory rappresentato da arch
Sistema operativo
aix5
Sistemi AIX
hpux11
Sistemi basati su HP-UX PA-RISC
hpux11hpia
Sistemi basati su HP-UX Integrity
linux2x86
Sistemi Linux® Red Hat e SUSE
linux2s390
Linux per System z
solaris2
Sistemi Solaris
win32
Sistemi Windows
Informazioni su questa pubblicazione
xi
xii
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Capitolo 1. Configurazione dell’ObjectServer
Per archiviare e gestire informazioni sugli avvisi in un’installazione di Tivoli
Netcool/OMNIbus, è necessario almeno un ObjectServer. È possibile configurare
l’ObjectServer utilizzandone le proprietà e le opzioni della riga comandi; inoltre, è
possibile configurare l’ObjectServer perché accetti solo connessioni sicure. Infine, è
anche possibile configurare il supporto IDUC (Insert, Delete, Update, or Control), il
supporto multiculturale e il failover e il failback automatizzati.
Elaborazione degli avvisi nell’ObjectServer
Gli avvisi vengono memorizzati come righe o voci nella tabella alerts.status
dell’ObjectServer. Ogni avviso ha un campo Identificativo che identifica in maniera
univoca l’origine del problema. L’identificativo viene generato dal probe in base
alla specifica presente nel file di regole di probe.
Quando un avviso viene inoltrato all’ObjectServer, nella tabella alerts.status viene
cercato un campo Identificativo corrispondente. Se non viene trovata alcuna voce
con lo stesso identificativo, viene inserita una nuova voce di avviso. La voce
contiene informazioni dettagliate sul problema. Ad esempio, il campo
FirstOccurrence indica l’ora in cui si è verificato per la prima volta il problema.
Se viene rilevata una voce con lo stesso identificativo, si verifica la deduplicazione.
L’ObjectServer conferma la ricorrenza della voce duplicata aumentando un
conteggio della voce esistente. Per impostazione predefinita, l’ObjectServer
aggiorna il campo LastOccurrence della voce esistente con l’ora del nuovo avviso e
incrementa il campo Tally.
Nota: Nella V7.0 o successiva, il trigger Deduplicazione ha la precedenza
sull’impostazione di aggiornamento alla deduplicazione nel probe, se il trigger fa
riferimento esplicitamente al campo Identificativo.
L’ObjectServer può inoltre rispondere automaticamente ad avvisi specificati
utilizzando l’automazione.
È possibile esportare informazioni di avviso in altre applicazioni tramite un
gateway ed è possibile utilizzare un gateway di ObjectServer bidirezionale per
fornire il supporto di failover a un altro ObjectServer.
Utilizzo delle proprietà e delle opzioni della riga comandi
dell’ObjectServer
L’ObjectServer legge il proprio file delle proprietà quando viene avviato. Se in
questo file una proprietà non è specificata, viene utilizzato il valore predefinito fino
a quando non viene sovrascritto con un’opzione della riga comandi.
Informazioni sul file delle proprietà dell’ObjectServer
L’ubicazione predefinita del file delle proprietà è $NCHOME/omnibus/etc/
servername.props. Nel file delle proprietà dell’ObjectServer, una proprietà e il
valore corrispondente sono separati dai due punti (:). I valori stringa sono racchiusi
tra virgolette singole; ad esempio:
© Copyright IBM Corp. 1994, 2009
1
Name: 'NCOMS'
Ciascuna proprietà ObjectServer ha un valore predefinito. In un file delle proprietà
che non è stato modificato, tutte le proprietà sono impostate sui valori predefiniti.
Nella parte superiore del file, si trova un elenco delle proprietà con i relativi valori
predefiniti, i tipi di dati e le descrizioni; tali informazioni vengono fornite come
riferimento. Queste proprietà vengono impostate come commento aggiungendo il
simbolo # all’inizio della riga. Sotto l’elenco delle proprietà impostate come
commento, si trova un altro elenco di proprietà con i relativi valori predefiniti, che
viene fornito a scopo di modifica, se necessario.
Nota: Se si esegue l’ObjectServer nella codifica UTF-8 su Windows, è necessario
salvare anche il file delle proprietà dell’ObjectServer nella codifica UTF-8.
Specifica delle proprietà ObjectServer
È possibile modificare le impostazioni per le proprietà ObjectServer in uno dei
seguenti modi:
v Aprire il file delle proprietà e modificare il valore delle proprietà obbligatorie.
Modificare le voci che si trovano sotto l’elenco delle proprietà impostato come
commento. Quando si apportano modifiche alle proprietà nel file delle proprietà,
le modifiche diventano effettive solo dopo aver riavviato l’ObjectServer.
v Eseguire il comando ALTER SYSTEM SET dall’interfaccia interattiva SQL.
v Dall’interfaccia di Netcool/OMNIbus Administrator, utilizzare il pulsante di
menu System e l’opzione Properties per visualizzare le proprietà e modificarne i
valori.
Quando si utilizza il comando ALTER SYSTEM SET o Netcool/OMNIbus
Administrator per modificare le proprietà dell’ObjectServer, le modifiche ad
alcune proprietà diventano effettive solo dopo aver riavviato l’ObjectServer. Per
informazioni sulla visualizzazione delle proprietà che richiedono un riavvio
dell’ObjectServer, vedere l’elenco di suggerimenti riportato di seguito.
Ogni volta che si modificano i valori delle proprietà ObjectServer utilizzando il
comando ALTER SYSTEM SET oppure Netcool/OMNIbus Administrator, viene
aggiunto un elenco di proprietà in fondo al file delle proprietà per riflettere le
modifiche apportate. Pertanto, all’interno di un file possono esserci più voci per
una proprietà. In questi casi, l’ultima voce in ordine tempo ha la precedenza sulle
voci meno recenti.
Suggerimenti per visualizzare informazioni sulle proprietà ObjectServer:
v È possibile eseguire query nella tabella catalog.properties per visualizzare
informazioni sulle proprietà ObjectServer. Ad esempio, per richiamare un elenco
di proprietà che non è possibile modificare, immettere la seguente query
nell’interfaccia interattiva SQL:
select PropName from catalog.properties where IsModifyable=FALSE;
v Le modifiche apportate ad alcune proprietà ObjectServer diventano effettive solo
dopo aver riavviato l’ObjectServer. Per richiamare un elenco di queste proprietà,
immettere la seguente query:
select PropName from catalog.properties where IsImmediate=FALSE;
v È anche possibile visualizzare informazioni sulle proprietà ObjectServer
dall’interfaccia di Netcool/OMNIbus Administrator.
2
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Specifica delle opzioni della riga comandi dell’ObjectServer
Quando si esegue l’ObjectServer utilizzando il comando nco_objserv, è possibile
specificare una serie di opzioni della riga comandi. È possibile sovrascrivere il
valore predefinito e il valore del file delle proprietà modificando il valore della
proprietà dalla riga comandi.
Le opzioni della riga comandi per l’ObjectServer utilizzano il seguente formato:
nco_objserv [ -option [ value ] ... ]
In questo comando, -option indica l’opzione della riga comandi, mentre value indica
il valore sul quale impostare l’opzione. Non è necessario specificare un valore per
ogni opzione.
È possibile aggiungere opzioni della riga comandi ai comandi nco_objserv nel file
di configurazione dell’agent del processo.
Concetti correlati
“Richiamo di dati da una tabella o da una vista (comando SELECT)” a pagina 164
Attività correlate
“Visualizzazione e modifica delle proprietà ObjectServer” a pagina 116
“Definizione di processi, servizi e host per il controllo processi” a pagina 256
Riferimenti correlati
“Modifica delle impostazioni predefinite e correnti dell’ObjectServer (comando
ALTER SYSTEM)” a pagina 170
“Tabella catalog.properties” a pagina 330
Proprietà e opzioni della riga comandi dell’ObjectServer
Utilizzare le proprietà o le opzioni della riga comandi dell’ObjectServer per
configurare impostazioni per l’ObjectServer. Per evitare errori, è preferibile
aggiungere quante più proprietà possibili al file delle proprietà piuttosto che
utilizzare le opzioni della riga comandi.
Suggerimento: È possibile codificare i valori stringa in un file delle proprietà
utilizzando la codifica dei valori delle proprietà.
Le proprietà e le opzioni della riga comandi dell’ObjectServer sono descritte nella
seguente tabella:
Capitolo 1. Configurazione dell’ObjectServer
3
Tabella 2. Proprietà e opzioni della riga comandi dell’ObjectServer
Proprietà
Opzione di riga comandi
Descrizione
ActingPrimary TRUE | FALSE
N/D
Questa proprietà viene utilizzata in una
configurazione di failover in cui l’ObjectServer
primario e quello di backup sono connessi
mediante un gateway ObjectServer
bidirezionale, che viene utilizzato per replicare i
dati evento tra i due ObjectServer. La proprietà
viene aggiornata solo mediante automazioni e
non deve essere aggiornata manualmente nel file
delle proprietà.
Vedere la colonna Descrizione.
ActingPrimary è impostata su TRUE
nell’ObjectServer di backup per tutto il periodo
di tempo in cui l’ObjectServer di backup funge
da server primario. In tutti gli altri casi,
nell’ObjectServer di backup questa proprietà è
impostata su FALSE.
ActingPrimary è sempre impostata su TRUE
nell’ObjectServer primario.
AlertSecurityModel integer
-alertsecuritymodel integer
Questa proprietà determina se la sicurezza a
livello di riga del gruppo è applicata nell’elenco
eventi. Per impostazione predefinita, la
sicurezza a livello di riga del gruppo è
disabilitata (0). In questo caso:
v I membri del gruppo Normal possono
modificare una riga assegnata a se stessi o
all’utente nobody.
v I membri del gruppo Administrator possono
modificare una riga assegnata a se stessi,
all’utente nobody oppure a un membro del
gruppo Normal.
Se la proprietà AlertSecurityModel è abilitata
(1), solo gli utenti membri del gruppo
proprietario della riga possono modificare la
riga. In questo caso, i membri del gruppo
Normal o Administrator possono modificare
una riga assegnata a un gruppo di cui fanno
parte.
Un membro del gruppo System può sempre
modificare qualsiasi riga.
Per ulteriori informazioni sul sistema e sui
gruppi predefiniti, consultare IBM Tivoli
Netcool/OMNIbus - Guida all’installazione e alla
distribuzione.
AllowConnections TRUE |
FALSE
4
-disallowconnections
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Specifica se gli utenti non root possono
connettersi all’ObjectServer. Se FALSE, non è
consentita nessuna nuova connessione
all’ObjectServer. L’impostazione predefinita è
TRUE.
Tabella 2. Proprietà e opzioni della riga comandi dell’ObjectServer (Continua)
Proprietà
Opzione di riga comandi
Descrizione
AllowISQL TRUE | FALSE
-disallowisql
Specifica se è possibile connettersi
all’ObjectServer utilizzando l’interfaccia
interattiva SQL. Se FALSE, nessun utente può
connettersi utilizzando nco_sql. L’impostazione
predefinita è TRUE.
Se TRUE, può essere abilitata per ciascun utente
che utilizza Netcool/OMNIbus Administrator.
AllowISQLWrite TRUE |
FALSE
-disallowisqlwrite
Specifica se è possibile apportare modifiche
all’ObjectServer utilizzando l’interfaccia
interattiva SQL. Se FALSE, nessun utente può
modificare l’ObjectServer utilizzando nco_sql.
L’impostazione predefinita è TRUE.
Se TRUE, può essere abilitata per ciascun utente
che utilizza Netcool/OMNIbus Administrator.
AllowTimedRefresh TRUE |
FALSE
-allowtimedrefresh TRUE |
FALSE
Questa proprietà determina se l’utente può
abilitare un aggiornamento a tempo nella scheda
Aggiorna della finestra Preferenze Elenco
eventi. Se TRUE, le preferenze dell’elenco eventi
possono essere impostate per consentire
l’aggiornamento delle informazioni sugli avvisi
a intervalli specificati anziché attendere la
notifica degli aggiornamenti dall’ObjectServer.
L’impostazione predefinita è FALSE.
Se FALSE, la casella di spunta
dell’aggiornamento a tempo è visualizzata in
grigio nella scheda Aggiorna della finestra
Preferenze Elenco eventi e l’aggiornamento a
tempo è disabilitato.
Auto.Debug TRUE | FALSE
-autodebug TRUE | FALSE
Se TRUE, il debug dell’automazione è abilitato.
L’impostazione predefinita è FALSE.
Auto.Enabled TRUE | FALSE
-autoenabled TRUE | FALSE
Se TRUE, le automazioni sono abilitate.
L’impostazione predefinita è TRUE.
Auto.StatsInterval integer
-autostatsinterval integer
Specifica l’intervallo in secondi al quale il
sistema di automazione raccoglie le statistiche.
L’impostazione predefinita è 60.
Le statistiche vengono raccolte a meno che
l’opzione della riga comandi -autoenabled non
sia impostata su FALSE, condizione che
disabilita tutte le automazioni.
Capitolo 1. Configurazione dell’ObjectServer
5
Tabella 2. Proprietà e opzioni della riga comandi dell’ObjectServer (Continua)
Proprietà
Opzione di riga comandi
Descrizione
BackupObjectServer TRUE |
FALSE
-backupserver
Fornisce la funzione di failback con i client
desktop, i probe, il server proxy e il gateway
ObjectServer. L’impostazione predefinita è
FALSE; si presuppone che i client desktop, i
probe, il server proxy e i gateway siano connessi
a un ObjectServer primario. Quando TRUE, i
client desktop, i probe, il server proxy e i
gateway riconoscono di essere connessi
all’ObjectServer di backup in una coppia di
failover. In tal caso, i client desktop, i probe, il
server proxy e i gateway verificheranno
automaticamente il ripristino dell’ObjectServer
primario nella coppia di failover e si
riconnetteranno all’Objectserver primario
(failback) quando questo viene riavviato.
ClientHeartbeatDisable TRUE
| FALSE
-clienthbdisable TRUE | FALSE
Disabilita il sistema di heartbeat di un client se
impostata su TRUE. In tal modo, un client
connesso entra in timeout se l’ObjectServer è
occupato: ad esempio, durante un’automazione
o una risincronizzazione del gateway.
L’impostazione FALSE predefinita abilita
l’heartbeat e impedisce inutili timeout del client.
Se l’ObjectServer è attivo, ma non occupato,
questa impostazione fa sì che l’ObjectServer
invii un messaggio pop up a un client connesso,
con i dettagli del tipo di elaborazione in corso.
ClientHeartbeatRate integer
-clienthbrate integer
Imposta la frequenza, in secondi, dell’heartbeat
di un client. Questa frequenza definisce il tempo
che un client deve attendere per ottenere una
risposta dall’ObjectServer prima di entrare in
timeout. L’impostazione predefinita è 10.
ConfigCryptoAlg string
N/D
Specifica l’algoritmo crittografico da utilizzare
per decodificare i valori stringa (incluse le
password) codificati con il programma di utilità
nco_aes_crypt e successivamente memorizzate
nel file delle proprietà. Impostare il valore string
nel modo seguente:
v In modalità FIPS 140-2, utilizzare AES_FIPS.
v In modalità non FIPS 140–2, è possibile
utilizzare AES_FIPS o AES. Utilizzare AES
solo se occorre mantenere la compatibilità con
password che sono state codificate tramite gli
strumenti forniti in versioni precedenti a
Tivoli Netcool/OMNIbus V7.2.1.
Il valore specificato deve essere identico al
valore utilizzato durante l’esecuzione di
nco_aes_crypt con l’impostazione -c, per
codificare i valori stringa.
Utilizzare questa proprietà insieme alla
proprietà ConfigKeyFile.
6
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 2. Proprietà e opzioni della riga comandi dell’ObjectServer (Continua)
Proprietà
Opzione di riga comandi
Descrizione
ConfigKeyFile string
N/D
Specifica il percorso e il nome del file chiave
contenente la chiave utilizzata per decodificare i
valori stringa codificati (incluse le password) nel
file delle proprietà.
La chiave viene utilizzata durante il runtime per
decodificare i valori stringa codificati con il
programma di utilità nco_aes_crypt. Il file
chiave specificato deve essere identico al file
utilizzato per codificare i valori stringa durante
l’esecuzione di nco_aes_crypt con l’impostazione
-k.
Utilizzare questa proprietà insieme alla
proprietà ConfigCryptoAlg.
Connections integer
-connections integer
Imposta il numero massimo di connessioni
disponibili per gateway, probe e client desktop.
Il valore massimo è 1024. L’impostazione
predefinita è 30. Il sistema può utilizzare un
massimo di due connessioni.
DeleteLogFile string
-DELETES string
Il percorso e il nome del file di log in cui
vengono registrati tutti i comandi ’delete’ se la
registrazione delle eliminazioni è abilitata.
Per impostazione predefinita, le eliminazioni
vengono registrate nel file $NCHOME/omnibus/
log/servername_deletes_file.logn.
DeleteLogging TRUE | FALSE
-DELETE_LOGGING TRUE |
FALSE
Quando TRUE, la registrazione delle
eliminazioni è abilitata. L’impostazione
predefinita è FALSE.
DeleteLogLevel integer
-DELETES_LEVEL integer
Il livello di registrazione determina la quantità
di informazioni che viene inviata la file di log
delle eliminazioni. Le possibili impostazioni
sono:
v <0: nessuna registrazione
v 0: tipo di client (ID applicazione; ad esempio,
ctisql per nco_sql) ed SQL eseguito. Questo
è il livello di registrazione predefinito.
v 1: ora, ID utente, tipo di client ed SQL
eseguito.
Capitolo 1. Configurazione dell’ObjectServer
7
Tabella 2. Proprietà e opzioni della riga comandi dell’ObjectServer (Continua)
Proprietà
Opzione di riga comandi
Descrizione
DeleteLogSize integer
-DELETES_SIZE integer
La dimensione massima del file di log delle
eliminazioni. Quando il file di log
servername_deletes_file.log1 raggiunge la
dimensione specificata, viene rinominato in
servername_deletes_file.log2 e viene creato
un nuovo file di log,
servername_deletes_file.log1. Quando il
nuovo file raggiunge la dimensione massima, il
file meno recente viene eliminato e il processo si
ripete.
L’output di un singolo comando di eliminazione
non viene mai suddiviso tra un file di log e
l’altro. Pertanto, i file di log possono essere più
grandi della dimensione specificata.
La dimensione del file di log predefinito è 1024
KB.
DTMaxTopRows integer
-dtmaxtoprows integer
Il numero massimo di righe che un
amministratore può specificare quando si
utilizza il Builder delle viste per limitare il
numero di righe che un elenco eventi può
visualizzare. Il valore predefinito è 100.
GWDeduplication integer
-gwdeduplication integer
Questa proprietà controlla il funzionamento
quando c’è un tentativo di reinserire un evento
esistente nell’ObjectServer. I valori possibili
sono:
0: quando impostata su questo valore
(predefinito):
v Se il client non è un gateway, il numero nel
campo Tally viene incrementato.
v I campi LastOccurrence, Summary e AlertKey
vengono aggiornati con i nuovi valori, mentre
i campi StateChange e InternalLast vengono
aggiornati con l’ora corrente.
v Se la nuova severità è maggiore di 0 (chiaro)
e quella vecchia era 0, anche l’avviso viene
aggiornato con il nuovo valore della severità.
1: se il client è un gateway, il nuovo evento
sostituisce quello vecchio.
2: se il client è un gateway, il nuovo evento
viene ignorato.
3: quando è impostata su questo valore:
v Per tutti i client, il numero nel campo Tally
viene incrementato.
v I campi LastOccurrence, Summary e AlertKey
vengono aggiornati con i nuovi valori e i
campi StateChange e InternalLast vengono
aggiornati con l’ora corrente.
v Se la nuova severità è maggiore di 0 (chiaro)
e quella vecchia era 0, anche l’avviso viene
aggiornato con il nuovo valore della severità.
8
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 2. Proprietà e opzioni della riga comandi dell’ObjectServer (Continua)
Proprietà
Opzione di riga comandi
Descrizione
Granularity integer
-granularity integer
Controlla l’intervallo di aggiornamento, in
secondi, di broadcast IDUC a desktop e
gateway. Riducendo questo valore si incrementa
la frequenza di aggiornamento per i client.
L’intervallo predefinito è 60 secondi.
N/D
-help
Visualizza la guida relativa alle opzioni della
riga comandi ed esce.
Iduc.ListeningHostname string
-listeninghostname string
Imposta un nome host per i client da utilizzare
per individuare l’ObjectServer. Sui sistemi su cui
si utilizza DNS, il nome restituito da una
macchina internamente potrebbe non essere
quello utilizzato sulla rete.
Ad esempio, un computer che si chiama sfo
potrebbe in realtà essere identificato sulla rete
come sfo.bigcorp.org. Per consentire ai client di
connettersi all’ObjectServer su sfo, impostare la
proprietà su sfo.bigcorp.org.
L’impostazione predefinita è il nome del
computer locale, così come viene riportato dal
comando hostname.
Iduc.ListeningPort integer
-listeningport integer
Imposta la porta per la connessione di
comunicazione IDUC. Questa è la porta sulla
quale l’ObjectServer invia aggiornamenti a
ciascun elenco eventi e gateway. Se non viene
specificata, la porta IDUC viene selezionata
dall’ObjectServer in maniera casuale dai numeri
di porta non utilizzati disponibili.
L’impostazione predefinita è 0, ossia utilizzare
la successiva porta disponibile.
È anche possibile specificare la porta nel file
/etc/services sulla macchina host.
LogFilePoolSize integer
-logfilepoolsize integer
Specifica il numero di file di log da utilizzare se
il sistema di registrazione scrive in un pool di
file. Questa proprietà funziona solo quando la
proprietà LogFileUsePool è impostata su TRUE.
La dimensione del pool può essere compresa tra
2 e 99.
L’impostazione predefinita è 10.
Questa opzione è supportata solo su sistemi
operativi Windows.
Capitolo 1. Configurazione dell’ObjectServer
9
Tabella 2. Proprietà e opzioni della riga comandi dell’ObjectServer (Continua)
Proprietà
Opzione di riga comandi
LogFileUsePool TRUE | FALSE -logfileusepool
Descrizione
Specifica se utilizzare un pool di file di log per
la registrazione dei messaggi.
Se impostata su TRUE, il sistema di
registrazione apre il numero di file specificati
per il pool all’avvio e li mantiene aperti per la
durata della relativa esecuzione. Per definire il
numero di file del pool, utilizzare la proprietà
LogFilePoolSize. Quando un file del pool
raggiunge la dimensione massima (specificata
dalla proprietà MaxLogFileSize), il sistema di
registrazione scrive nel file successivo. Quando
tutti i file del pool hanno raggiunto la
dimensione massima, il sistema di registrazione
tronca il primo file del pool ed inizia di nuovo a
scrivere in quel file. I file nel pool vengono
denominati utilizzando il formato
servername.log_ID, dove ID è un numero a due
cifre a partire da 01, fino al numero massimo
specificato per la proprietà LogFilePoolSize.
Quando il sistema di registrazione inizia ad
utilizzare un pool di file, il sistema scrive nel
numero file più basso disponibile,
indipendentemente dal file in cui stava
scrivendo quando è stato eseguito l’ultima volta.
L’impostazione predefinita è FALSE. Quando
impostata su FALSE, il file servername.log
predefinito viene rinominato in
servername.log_OLD e un nuovo file di log viene
avviato quando si raggiunge la dimensione
massima. Se il file non può essere rinominato,
ad esempio a causa di un blocco di lettura sul
file _OLD e la proprietà LogFileUseStdErr è
impostata su FALSE, il sistema di registrazione
inizia automaticamente a utilizzare un pool di
file di log.
Questa opzione è supportata solo su sistemi
operativi Windows.
10
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 2. Proprietà e opzioni della riga comandi dell’ObjectServer (Continua)
Proprietà
Opzione di riga comandi
Descrizione
LogFileUseStdErr TRUE |
FALSE
-logfileusestderr
Specifica se utilizzare stderr come flusso di
output per registrare messaggi.
L’impostazione predefinita è TRUE. Se questa
impostazione è TRUE e l’ObjectServer viene
eseguito dalla riga comandi, i messaggi vengono
registrati nella console se l’ObjectServer non può
scrivere nel file di log predefinito. Se questa
impostazione è TRUE e l’ObjectServer è in
esecuzione come servizio Windows, i messaggi
vengono scritti in un file che si chiama
%NCHOME%\omnibus\log\nco_objserv*.err se
l’ObjectServer non può scrivere nel file di log
predefinito.
Se impostata su FALSE e l’ObjectServer non può
scrivere nel file di log predefinito, i messaggi
vengono scritti in un pool di file di log, così
come impostato dalla proprietà LogFileUsePool.
Nota: L’impostazione della proprietà
LogFileUsePool ha la precedenza
sull’impostazione di LogFileUseStdErr.
Questa opzione è supportata solo su sistemi
operativi Windows.
MaxLogFileSize integer
-maxlogfilesize integer
Specifica la dimensione massima che il file di
log può raggiungere, in KB. L’impostazione
predefinita è 1024 KB.
Quando raggiunge la dimensione specificata, il
file servername.log viene rinominato in
servername.log_OLD e viene avviato un nuovo
file di log. Quando il nuovo file raggiunge la
dimensione massima, viene rinominato e il
processo inizia di nuovo.
MessageLevel string
-messagelevel string
Specifica il livello di registrazione dei messaggi.
I valori possibili sono: debug, info, warn, error e
fatal. Il livello predefinito è warn.
I messaggi registrati ai singoli livelli sono i
seguenti:
v fatal: solo fatal
v error: fatal ed error
v warn: fatal, error e warn
v info: fatal, error, warn e info
v debug: fatal, error, warn, info e debug
Suggerimento: Il valore di string può essere in
maiuscolo, minuscolo oppure in maiuscolo e in
minuscolo.
Capitolo 1. Configurazione dell’ObjectServer
11
Tabella 2. Proprietà e opzioni della riga comandi dell’ObjectServer (Continua)
Proprietà
Opzione di riga comandi
Descrizione
MessageLog string
-messagelog string
Specifica il percorso in cui vengono registrati i
messaggi. Il percorso predefinito è
$NCHOME/omnibus/log/NCOMS.log.
Su Windows, se il sistema non può scrivere nel
file di log specificato (ad esempio, a seguito di
un errore irreversibile) scrive l’errore in un file
che si chiama %NCHOME%\omnibus\log\
nco_objserv*.err.
Nota: L’ObjectServer deve essere in esecuzione
come servizio; in caso contrario, non può
scrivere errori in un file.
N/D
-name string
Imposta il nome dell’ObjectServer, che deve
essere univoco. Questo è il nome configurato
dall’editor del server. L’impostazione predefinita
è NCOMS.
OldTimeStamp TRUE | FALSE
-oldtimestamp TRUE | FALSE
Specifica il formato data/ora da utilizzare nel
file di log.
Impostare il valore su TRUE per visualizzare il
formato data/ora utilizzato in Tivoli
Netcool/OMNIbus V7.2.1 oppure in una
versione precedente. Ad esempio,
gg/MM/AAAA hh:mm:ss AM o
gg/MM/AAAA hh:mm:ss PM quando la locale
è impostata su en_GB in un computer Solaris 9.
Impostare il valore su FALSE per visualizzare il
formato ISO 8601 nel file di log. Ad esempio:
AAAA-MM-GGThh:mm:ss, dove T separa la
data e l’ora e hh è nel formato di 24 ore.
L’impostazione predefinita è FALSE.
PA.Name string
-pa string
Imposta il nome dell’agent del controllo
processi. Questo nome deve essere composto da
un massimo di 29 lettere maiuscole e non può
iniziare con un numero intero. Quando si
esegue una procedura esterna da
un’automazione, l’ObjectServer può avviare un
processo esterno. Per avviare il processo,
l’ObjectServer contatta un agent del controllo
processi. Il nome predefinito per l’agent del
controllo processi è NCO_PA.
PA.Password string
-papassword string
Specifica la password per l’utente che si
connette a un agent del controllo processi per
eseguire procedure esterne nelle automazioni.
L’impostazione predefinita è ''.
Nota: Se si eseguono procedure esterne, il
daemon del controllo processi deve essere in
grado di autenticare l’utente. Pertanto, una
combinazione valida, che può essere autenticata
dal daemon, deve essere specificata nei valori di
string per le proprietà PA.Username e
PA.Password. In caso contrario, la connessione
all’agent del controllo processi e la procedura
esterna in esecuzione non riusciranno.
12
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 2. Proprietà e opzioni della riga comandi dell’ObjectServer (Continua)
Proprietà
Opzione di riga comandi
Descrizione
PA.Username string
-pausername string
Specifica il nome utente per connettersi a un
agent del controllo processi per eseguire
procedure esterne nelle automazioni. È
necessario specificare un valore quando l’agente
del controllo processi è in esecuzione in
modalità sicura. L’impostazione predefinita è
root.
Su Windows, specificare il nome utente di un
account locale, un account di dominio o un
account UPN valido.
Su UNIX, qualsiasi utente che richiede accesso
al sistema per il controllo processi deve essere
membro di un gruppo di utenti UNIX
(ncoadmin è il predefinito) che viene identificato
come gruppo amministrativo per questo scopo.
Se si utilizza il framework PAM (Pluggable
Authentication Modules) per l’autenticazione,
non è necessario che gli utenti siano membri di
un gruppo di utenti UNIX, ad esempio
ncoadmin, per ottenere l’accesso al sistema per
il controllo accessi.
PasswordEncryption string
-pwdenc string
Definisce lo schema di codifica utilizzato per
codificare le password utente memorizzate
nell’ObjectServer. I valori sono:
v DES: codifica Data Encryption Standard. Solo
i primi otto caratteri di una password
codificata con lo schema DES sono
importanti.
v AES: codifica Advanced Encryption Standard
(AES128). Solo i primi 16 caratteri di una
password codificata con lo schema AES128
sono importanti. In modalità FIPS 140–2, è
necessario specificare l’opzione AES.
L’impostazione predefinita è DES.
Capitolo 1. Configurazione dell’ObjectServer
13
Tabella 2. Proprietà e opzioni della riga comandi dell’ObjectServer (Continua)
Proprietà
Opzione di riga comandi
Descrizione
PasswordFormat string
-pwdformat string
Definisce i requisiti per le password utente e
funziona solo quando la proprietà
RestrictPasswords è impostata su TRUE.
È necessario specificare il valore string della
proprietà PasswordFormat (o -pwdformat) sotto
forma di una serie di valori interi separati dai
due punti (:), dove ciascun valore definisce un
requisito password. Il formato è:
min_len:alpha_num:digit_num:punct_num
Dove:
v min_len è la lunghezza della password.
v alpha_num è il numero minimo di caratteri
alfabetici.
v digit_num è il numero minimo di caratteri
numerici.
v punct_num è il numero minimo di segni di
punteggiatura.
Il valore predefinito di 8:1:1:0 indica che una
password deve essere lunga almeno 8 caratteri e
contenere almeno 1 carattere alfabetico e almeno
un carattere numerico. La password non deve
contenere segni di punteggiatura.
ProfileStatsInterval integer
-profilestatsinterval integer
Specifica l’intervallo in secondi al quale il
profiler scrive informazioni nel file di log dei
profili. L’impostazione predefinita è 60 secondi.
Profile TRUE | FALSE
-profile
Controlla la creazione profili dell’ObjectServer.
Se TRUE, la quantità di tempo necessaria ai
client per eseguire l’SQL viene registrata nella
tabella catalog.profiles. L’impostazione
predefinita è TRUE.
Anche le statistiche del profilo vengono
registrate nel file $NCHOME/omnibus/log/
servername_profiler_report.logn a ogni
intervallo di statistiche profili.
Props.CheckNames TRUE |
FALSE
N/D
Se TRUE, l’ObjectServer non viene eseguito se
una delle proprietà specificate non è valida.
L’impostazione predefinita è TRUE.
N/D
-propsfile string
Imposta il nome del file delle proprietà
dell’ObjectServer. Il nome predefinito è
servername.props, dove il servername viene
definito dall’opzione -name.
14
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 2. Proprietà e opzioni della riga comandi dell’ObjectServer (Continua)
Proprietà
Opzione di riga comandi
Descrizione
RegexpLibrary string
-regexplib string
Definisce quale libreria di espressioni regolari
utilizzare per l’ObjectServer. I possibili valori
sono: NETCOOL e TRE.
Il valore predefinito di NETCOOL è utile per
elaborare caratteri a byte singolo e fornisce
prestazioni di sistema ottimali.
Per consentire l’uso della sintassi estesa delle
espressioni regolari su lingue con caratteri a
byte singolo e a più byte, impostare il valore su
TRE. Questa impostazione comporta un calo
delle prestazioni del sistema.
RestrictionFiltersAND TRUE |
FALSE
-restrictfiltersand
Controlla in che modo vengono concatenati i
filtri limitazioni utente e i filtri limitazioni
gruppo. Questa proprietà viene impostata per il
sistema e non per il singolo utente e le
modifiche apportate all’impostazione di questa
proprietà diventano effettive solo dopo aver
riavviato l’ObjectServer.
I valori per questa proprietà sono i seguenti:
v TRUE: tutti i filtri limitazioni vengono
combinati utilizzando l’operatore AND.
L’impostazione predefinita è TRUE. Esempio:
user_rf AND group1 AND group2
v FALSE: tutti i filtri limitazioni vengono
combinati utilizzando l’operatore OR.
Esempio:
user_rf OR group1 OR group2
RestrictionUpdateCheck TRUE
| FALSE
-norestrictionupdatecheck
Se FALSE, gli utenti ai quali sono applicati filtri
limitazioni possono aggiornare avvisi che non
verranno visualizzati nella loro vista dopo
l’aggiornamento. L’impostazione predefinita è
TRUE.
RestrictPasswords TRUE |
FALSE
-restrictpasswords TRUE |
FALSE
Se l’impostazione è TRUE, le password devono
essere conformi alle seguenti limitazioni:
v La password deve consistere di almeno otto
caratteri.
v La password deve contenere almeno un
carattere numerico.
v La password deve contenere almeno un
carattere alfabetico.
L’impostazione predefinita è FALSE.
Capitolo 1. Configurazione dell’ObjectServer
15
Tabella 2. Proprietà e opzioni della riga comandi dell’ObjectServer (Continua)
Proprietà
Opzione di riga comandi
Descrizione
RestrictProxySQL TRUE |
FALSE
-restrictproxysql
Se TRUE, le connessioni da un server proxy
sono limitate nei comandi SQL dell’ObjectServer
che possono essere eseguiti. Le uniche
modifiche che è possibile apportare ai dati
dell’ObjectServer sono inserimenti nelle tabelle
alerts.status e alerts.details. L’impostazione
predefinita è FALSE.
Se FALSE, le connessioni da un server proxy
possono eseguire un qualsiasi comando SQL
dell’ObjectServer.
Sec.AuditLevel string
-secauditlevel string
Specifica il livello di verifica della sicurezza
eseguito. I valori possibili sono debug, info,
warn e error. L’impostazione predefinita è warn.
I livelli debug e info generano messaggi per
autenticazioni riuscite e non riuscite, mentre i
livelli warn e error generano messaggi solo per
le autenticazioni non riuscite.
Sec.AuditLog string
-secauditlog string
Specifica il file in cui vengono scritte le
informazioni di verifica. L’impostazione
predefinita è $NCHOME/omnibus/log/servername/
audit.log.
Sec.ExternalAuthentication
string
-authenticate string
Controlla quale modulo di autenticazione viene
utilizzato per autenticare gli utenti. I valori
sono:
v none: utilizzare questo valore per eseguire
l’autenticazione sulla base di nomi utente e
password memorizzati nell’ObjectServer.
Questa impostazione disabilita
l’autenticazione esterna.
v LDAP: utilizzare questo valore per autenticare
esternamente utenti le cui credenziali sono
memorizzate in un repository LDAP
(Lightweight Directory Access Protocol).
v PAM: utilizzare questo valore per autenticare
utenti utilizzando il framework PAM Tivoli
Netcool/OMNIbus fornito o per autenticare
utenti esternamente utilizzando
configurazioni PAM di terze parti (ad
esempio, la configurazione PAM del sistema
operativo oppure una impostata per utilizzare
credenziali LDAP).
In UNIX e Linux, l’impostazione predefinita è
PAM. Su Windows, l’impostazione predefinita è
none.
SecureMode TRUE | FALSE
16
-secure
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Imposta la modalità sicurezza dell’ObjectServer.
Se TRUE, l’ObjectServer autentica le richieste di
connessione del probe, del gateway e del server
proxy con un nome utente e una password.
Altre richieste di connessione client vengono
sempre autenticate con un nome utente e una
password.
Tabella 2. Proprietà e opzioni della riga comandi dell’ObjectServer (Continua)
Proprietà
Opzione di riga comandi
Descrizione
Store.LocalizedSort TRUE |
FALSE
-storelocalesort
Definisce se l’ordinamento localizzato è abilitato
o disabilitato.
L’impostazione predefinita è FALSE, ovvero
l’ordinamento localizzato è disabilitato a favore
della libreria C standard (libc). Ad esempio, Å
verrà considerata una variante di A e i due
caratteri saranno disposti l’uno accanto all’altro.
Utilizzare questa impostazione predefinita per
ottenere prestazioni del sistema ottimali.
Impostare il valore su TRUE per abilitare
l’ordinamento localizzato. Ad esempio, in una
locale danese, Å verrà considerata una lettera
separata e viene collocata subito dopo la Z.
Questa impostazione comporta un calo delle
prestazioni del sistema.
Store.
LocalizedSortCaseSensitive
string
-storecasesort string
Controlla la distinzione maiuscolo/minuscolo
nell’ordinamento localizzato. Questa proprietà è
applicabile solo quando Store.LocalizedSort è
TRUE.
I valori sono:
v OFF: l’ordinamento non rispetta la distinzione
maiuscolo/minuscolo e le lettere maiuscole e
quelle minuscole vengono ordinate in base ai
rispettivi pesi di ordinamento terziario.
v UPPERFIRST: i caratteri maiuscoli vengono
disposti prima dei caratteri minuscoli. Ad
esempio, Account viene disposto prima di
account.
v LOWERFIRST: i caratteri minuscoli vengono
disposti prima dei caratteri maiuscoli. Ad
esempio, account viene disposto prima di
Account.
L’impostazione è OFF.
UniqueLog TRUE | FALSE
-uniquelog
Se TRUE, il file di log viene denominato in
maniera univoca accodando l’ID processo
dell’ObjectServer al nome del file di log
predefinito. Ad esempio, se l’ObjectServer
NCOMS è in esecuzione come processo 1234, il
file di log viene denominato
NCHOME/omnibus/log/ NCOMS.1234.log.
L’impostazione predefinita è FALSE.
Se la proprietà MessageLog viene impostata su
stderr o stdout, la proprietà UniqueLog verrà
ignorata.
Capitolo 1. Configurazione dell’ObjectServer
17
Tabella 2. Proprietà e opzioni della riga comandi dell’ObjectServer (Continua)
Proprietà
Opzione di riga comandi
N/D
Windows
-utf8enabled TRUE | FALSE
Descrizione
Controlla la codifica di dati passati alle
applicazioni o generati a questa applicazione su
Windows.
Impostare il valore di -utf8enabled su TRUE per
eseguire l’applicazione nella codifica UTF-8. Il
valore predefinito è FALSE, che consente
l’utilizzo della codepage predefinita del sistema.
Importante: Sebbene la proprietà UTF8Enabled
sia disponibile, un tentativo di abilitare la
codifica UTF-8 impostando questa proprietà su
TRUE non avrà alcun effetto. Per utilizzare la
codifica UTF-8 in Windows, è necessario
utilizzare sempre l’opzione della riga comandi
-utf8enabled.
Nota: Quando l’esecuzione ha luogo nella
codifica UTF-8, non impostare la proprietà
OldTimeStamp su TRUE.
WTPasswordCheck string
-wtpasswordcheck string
Controlla il modo in cui le password vengono
verificate dall’ObjectServer quando vengono
ricevute dai client.
Questa proprietà è utile quando gli utenti
dell’ObjectServer vengono autenticati
esternamente. I possibili valori per la proprietà
sono:
v plain: si presuppone che le password siano in
testo semplice. Applicabile ai soli client
Netcool/Webtop 1.3.
v encrypted: si presuppone che le password
siano in un formato codificato. Applicabile ai
soli client Netcool/Webtop 1.3.
v default: si presuppone che inizialmente le
password siano in testo semplice. Se la
verifica dell’ObjectServer non riesce, si
presuppone che le password siano in un
formato codificato. Applicabile ai soli client
Netcool/Webtop 1.3.
v allplain: si presuppone che le password siano
in testo semplice. Se l’accesso con la password
in testo semplice non riesce, non viene
eseguito un secondo tentativo. Applicabile a
client diversi da Netcool/Webtop 1.3.
v allencrypted: si presuppone che le password
siano in un formato codificato e che vengano
decodificate prima dell’autenticazione. Se
l’accesso con la password decodificata non
riesce, non viene eseguito un secondo
tentativo. Applicabile a client diversi da
Netcool/Webtop 1.3.
N/D
-version
Visualizza informazioni sulla versione per
l’ObjectServer ed esce.
Nota: Il comando nco_objserv include proprietà avanzate che devono essere
utilizzate unicamente sotto il controllo del IBM Software Support. Queste proprietà
18
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
non sono documentate.
Esecuzione dell’ObjectServer in modalità sicura
È possibile eseguire l’ObjectServer in modalità sicura. Quando si specifica l’opzione
della riga comandi -secure, l’ObjectServer autentica le connessioni probe, gateway e
server proxy richiedendo un nome utente e una password.
Quando viene inviata una richiesta di connessione, l’ObjectServer invia un
messaggio di autenticazione. Il probe, il gateway o il server proxy deve rispondere
con la combinazione corretta di nome utente e password.
Se non si specifica l’opzione -secure, le richieste di connessione di probe, gateway e
server proxy non vengono autenticate.
Nota: Le connessioni di altri client, ad esempio l’elenco eventi e l’interfaccia
interattiva SQL, vengono sempre autenticate.
Quando si effettua una connessione a un ObjectServer sicuro:
v È necessario che nel file delle proprietà di ciascun probe o server proxy che
effettua una connessione, le proprietà AuthUserName e AuthPassword siano
specificate.
v È necessario che per ciascun gateway unidirezionale che utilizza un file delle
proprietà, i valori delle proprietà Gate.Writer.Username, Gate.Writer.Password,
Gate.Reader.Username e Gate.Reader.Password siano specificati. È necessario
che per ciascun gateway bidirezionale che utilizza un file delle proprietà i valori
delle proprietà Gate.ObjectServerA.Username, Gate.ObjectServerA.Password,
Gate.ObjectServerB.Username e Gate.ObjectServerB.Password siano specificati.
È necessario che per ciascun gateway che utilizza un file di configurazione, i
valori per i comandi AUTH_USER e AUTH_PASSWORD nel file di
configurazione del gateway siano specificati.
Se la combinazione nome utente e password non è corretta, l’ObjectServer invia un
messaggio di errore e rifiuta la connessione.
È possibile scegliere un qualsiasi nome utente valido per la proprietà
AuthUserName, Gate.Writer.Username, Gate.Reader.Username,
Gate.ObjectServerA.Username o Gate.ObjectServerB.Username oppure per il
comando AUTH_USER.
I dettagli di codifica della password per l’esecuzione in modalità FIPS 140–2 e non
FIPS 140–2 sono descritti nella seguente tabella:
Capitolo 1. Configurazione dell’ObjectServer
19
Tabella 3. Codifica della password in modalità FIPS 140–2 e non FIPS 140–2
Modalità
Azione
Modalità FIPS
140–2
In modalità FIPS 140–2, è possibile specificare le password in testo
semplice o in formato codificato. La codifica delle password può
avvenire tramite codifica dei valori di proprietà, nel modo seguente:
1. Se non si dispone ancora di una chiave per la codifica della
password, crearne una eseguendo il programma di utilità
nco_keygen, situato in $NCHOME/omnibus/bin.
2. Eseguire il programma di utilità nco_aes_crypt per codificare la
password con la chiave generata dal programma di utilità
nco_keygen. Anche il programma di utilità nco_aes_crypt si trova in
$NCHOME/omnibus/bin. Tenere presente che è necessario specificare
AES_FIPS come algoritmo da utilizzare per la codifica della
password.
3. Aprire il file delle proprietà a cui si desidera aggiungere la
password codificata e specificare l’output codificato per
l’impostazione AuthPassword.
Nota: È inoltre necessario impostare la proprietà ConfigKeyFile sul
file chiave specificato durante l’esecuzione di nco_aes_crypt e
impostare la proprietà ConfigCryptoAlg sull’algoritmo di codifica
utilizzato.
Modalità non
FIPS 140–2
In modalità non FIPS 140–2, è possibile specificare le password in testo
semplice o in formato codificato. Tuttavia, il client trasmette sempre
informazioni di accesso codificate, indipendentemente dalla codifica
password utilizzata nel file delle proprietà. La codifica delle password
può avvenire tramite il programma di utilità nco_g_crypt o tramite la
codifica dei valori di proprietà, nel modo seguente:
v Per codificare una password tramite il programma di utilità
nco_g_crypt, eseguire il comando nel modo seguente:
$NCHOME/omnibus/bin/nco_g_crypt plaintext_password
In questo comando, plaintext_password rappresenta il formato non
codificato della password. Il programma di utilità nco_g_crypt
acquisisce la password non codificata e visualizza una versione
codificata. Aprire il file delle proprietà a cui si desidera aggiungere la
password codificata e specificare l’output codificato per
l’impostazione AuthPassword.
v Per codificare una password utilizzando una codifica dei valori di
proprietà, è necessaria una chiave generata con il programma di
utilità nco_keygen. È quindi possibile eseguire nco_aes_crypt per
codificare la password con la chiave. Tenere presente che è possibile
specificare AES_FIPS o AES come algoritmo per la codifica della
password. Utilizzare AES solo se occorre mantenere la compatibilità
con password che sono state codificate con gli strumenti forniti in
versioni precedenti a Tivoli Netcool/OMNIbus V7.2.1.
Aprire il file a cui si desidera aggiungere la password codificata e
specificare l’output codificato per l’impostazione AuthPassword.
Nota: È inoltre necessario impostare la proprietà ConfigKeyFile sul
file chiave specificato durante l’esecuzione di nco_aes_crypt e
impostare la proprietà ConfigCryptoAlg sull’algoritmo di codifica
utilizzato.
Una password codificata con nco_g_crypt viene specificata allo stesso modo di una
password non codificata al momento della connessione all’ObjectServer.
L’ObjectServer rileva automaticamente una password codificata ed esegue la
codifica necessaria per verificare la password durante l’autenticazione.
20
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Attenzione: Le password codificate con nco_g_crypt possono essere utilizzate allo
stesso modo delle password non codificate per accedere all’ObjectServer. Di
conseguenza, è necessario impostare le autorizzazioni appropriate sui file
contenenti le password codificate per impedire l’accesso non autorizzato. In
alternativa, è necessario codificare ulteriormente con nco_aes_crypt le password
che sono state codificate con nco_g_crypt e impostare in modo appropriato le
autorizzazioni sul file chiave.
Per ulteriori informazioni sull’utilizzo della codifica dei valori delle proprietà,
consultare IBM Tivoli Netcool/OMNIbus - Guida all’installazione e alla distribuzione.
Per ulteriori informazioni sull’esecuzione di probe e gateway in modalità sicura,
consultare IBM Tivoli Netcool/OMNIbus - Guida a probe e gateway.
Riferimenti correlati
“Esecuzione del server proxy in modalità sicura” a pagina 41
“Opzioni di riga comandi e proprietà del server proxy” a pagina 38
Aggiornamenti degli strumenti client utilizzando IDUC
Ogni volta che un elenco eventi viene aggiornato, una notevole quantità di dati
viene trasmessa tra l’ObjectServer e un client desktop. Per impedire che
l’ObjectServer si sovraccarichi con richieste di aggiornamenti degli elenchi eventi,
l’ObjectServer invia un prompt al client desktop ogni volta che occorre un
aggiornamento. Il desktop, quindi, richiede i dati aggiornati all’ObjectServer.
Questo prompt viene inviato al desktop attraverso un link di comunicazione che
utilizza il protocollo di comunicazione IDUC (Insert, Delete, Update or Control). Il
prompt indica al desktop di aggiornare le visualizzazioni di tutti gli elenchi eventi.
Il protocollo IDUC aggiorna i gateway nello stesso modo.
Il client desktop si collega all’ObjectServer utilizzando la porta definita dal file
delle interfacce per stabilire il link di comunicazione IDUC. Il desktop riceve il
numero del socket della connessione IDUC su cui riceverà le richieste di
aggiornamento da parte dell’ObjectServer.
Specifica dell’intervallo di aggiornamento IDUC
L’intervallo di aggiornamento è controllato dalla proprietà Granularity
dell’ObjectServer o dall’opzione della riga comandi -granularity, che per
impostazione predefinita è impostata su 60 secondi. Il valore predefinito va bene
per la maggior parte dei sistemi. Se viene ridotto, si migliora il tempo di risposta
degli strumenti client, ma si incrementa notevolmente il traffico di rete e il carico
dell’ObjectServer.
Specifica della porta IDUC
Per impostazione predefinita, quando viene avviato un ObjectServer, viene scelto
un numero di porta disponibile per la connessione IDUC. È anche possibile
specificare la porta IDUC da utilizzare. È necessario specificare la porta IDUC
quando si accede a un ObjectServer protetto da un firewall.
Su UNIX, è possibile definire queste porte aggiornando il file /etc/services. Su
Windows, aggiornare il file %SystemRoot%\system32\drivers\etc\services.
Il file services contiene una voce per ciascun ObjectServer nel seguente formato:
nco_servername nnnn/tcp
Capitolo 1. Configurazione dell’ObjectServer
21
In questa voce, servername è il nome dell’ObjectServer, mentre nnnn è il numero
della porta.
Di seguito viene riportato un esempio di voci per gli ObjectServer NCOMS e
DENCO:
nco_NCOMS 7070/tcp
nco_DENCO 7071/tcp
La porta può essere impostata su un qualsiasi numero non utilizzato che non sia
compreso nell’intervallo 1-1024, che generalmente è riservato al sistema.
Quando il file /etc/services è gestito da NIS (Network Information Service), è
necessario creare la voce nel file dei servizi NIS, quindi copiare la configurazione
aggiornata su tutte le macchine.
È anche possibile utilizzare l’opzione -listeningport sulla riga comandi
dell’ObjectServer per specificare la porta IDUC.
Configurazione dell’ObjectServer per il supporto multiculturale
Tivoli Netcool/OMNIbus supporta una vasta gamma di codifiche di caratteri a
byte singolo o a più byte da utilizzare in diverse locali.
Le seguenti proprietà di ObjectServer sono rilevanti per l’elaborazione dei caratteri
a più byte:
v Store.LocalizedSort: utilizzare questa proprietà per abilitare l’ordinamento
localizzato. Per ottenere prestazioni ottimali, l’ordinamento localizzato è
disabilitato per impostazione predefinita.
v Store.LocalizedSortCaseSensitive: utilizzare questa proprietà per controllare la
distinzione tra maiuscole e minuscole nell’ordinamento localizzato.
v RegexpLibrary: utilizzare questa proprietà per abilitare l’uso della libreria di
espressioni regolari estese POSIX 1003.2 (TRE). La librerie di espressioni regolari
estese NETCOOL è abilitata per impostazione predefinita per motivi di
prestazioni.
È possibile impostare questa proprietà in uno dei seguenti modi:
v Impostare le proprietà nel file delle proprietà dell’ObjectServer
$NCHOME/omnibus/etc/servername.props, dove servername è il nome specificato
per l’ObjectServer in fase di creazione.
v Modificare le impostazioni dalla riga comandi quando si avvia l’ObjectServer
con il comando nco_objserv. L’opzione di riga comandi per la proprietà
Store.LocalizedSort è -storelocalesort. L’opzione di riga comandi per la proprietà
Store.LocalizedSortCaseSensitive è -storecasesort. L’opzione di riga comandi
per la proprietà RegexpLibrary è -regexplib.
Nota: Se il nome utente e la password vengono verificati rispetto ad un’origine di
autenticazione esterna, è necessario controllare se anche tale origine supporta i
caratteri a più byte. Se i caratteri a più byte non sono supportati, è necessario
specificare nomi utente e password utilizzando caratteri ASCII.
I nomi dei seguenti oggetti di ObjectServer sono limitati a caratteri ASCII, devono
iniziare con una lettera o con un carattere di sottolineatura e possono contenere
lettere, cifre e caratteri di sottolineatura:
v Memstore
22
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
v
v
v
v
v
Database
Tabelle
Colonne
Filtri limitazioni
Privilegi
v
v
v
v
v
v
v
Gruppi trigger
Trigger
Segnali
Procedure
Parametri
Variabili
Proprietà
v Oggetti file
I nomi degli oggetti file sono limitati ai caratteri ASCII specificati mentre i nomi
percorso sono limitati ai caratteri supportati dal sistema operativo. La codifica
caratteri utilizzata per creare i file è la codifica utilizzata dall’ObjectServer;
questa modifica potrebbe essere diversa da quella del client.
Per ulteriori informazioni sul supporto multiculturale per Tivoli
Netcool/OMNIbus, consultare IBM Tivoli Netcool/OMNIbus - Guida all’installazione e
alla distribuzione.
Riferimenti correlati
“Proprietà e opzioni della riga comandi dell’ObjectServer” a pagina 3
Archiviazione e checkpoint dei dati
I dati dell’ObjectServer vengono archiviati in memoria per consentirne un rapido
accesso. L’ObjectServer supporta la persistenza dei dati utilizzando checkpoint e
log per copiare su disco i dati presenti in memoria. In tal modo, è possibile
ripristinare i dati dopo un arresto pianificato o imprevisto.
Archiviazione dei dati mediante memstore
I memstore sono contenitori gestiti dall’ObjectServer, che conservano in memoria
dati e tabelle dell’ObjectServer.
L’ObjectServer utilizza i memstore descritti nella seguente tabella:
Tabella 4. Memstore
Nome del memstore
Tipo di archiviazione
Descrizione
MASTER_STORE
Persistente
Utilizzato per archiviare descrizioni
interne di dati dell’ObjectServer.
TABLE_STORE
Persistente
Utilizzato per archiviare informazioni
per il desktop, compresa la tabella
alerts.status.
TEMP_STORE
Temporaneo
Utilizzato per archiviare dati che non
occorre siano persistenti. Le tabelle di
sistema che contengono informazioni
di configurazione vengono archiviate
in questo memstore e ricreate
all’avvio.
Capitolo 1. Configurazione dell’ObjectServer
23
Tabella 4. Memstore
(Continua)
Nome del memstore
Tipo di archiviazione
Descrizione
VIRTUAL_STORE
Virtuale
Utilizzato principalmente per
catalogare dati che cambiano
rapidamente; ad esempio, i dati
relativi ai client connessi.
È possibile modificare il memstore table_store utilizzando il programma di utilità
nco_store_resize.
Riferimenti correlati
“Modifica dei limiti flessibili e rigidi del memstore table_store” a pagina 26
Introduzione al checkpoint
L’ObjectServer supporta la persistenza dei dati utilizzando checkpoint e log per
copiare su disco i dati presenti in memoria. In tal modo, è possibile ripristinare i
dati dopo un arresto pianificato o imprevisto.
I seguenti tipi di file vengono conservati su disco:
v File di checkpoint, che contengono i dati per le intere tabelle
v Log di risposta, che contengono le modifiche apportate alle tabelle a partire
dall’ultimo checkpoint
Ogni 60 secondi, ha luogo un checkpoint e tutti i dati persistenti vengono copiati
nei file di checkpoint. Tra un checkpoint e l’altro, i dati nuovi e quelli modificati
vengono scritti nei file di log di risposta.
I checkpoint hanno luogo anche tutte le volte in cui viene eseguito un arresto
pianificato dell’ObjectServer.
Creazione di file di checkpoint
I file di checkpoint vengono generati per ciascun memstore persistente.
Suggerimento: Solo i memstore persistenti vengono sottoposti al checkpoint.
I file di checkpoint vengono denominati come mostrato di seguito:
v $NCHOME/omnibus/db/servername/storename.chk0
v $NCHOME/omnibus/db/servername/storename.chk1
Per ogni memstore persistente vengono generati anche log di risposta. I file di
risposta vengono denominati come mostrato di seguito:
v $NCHOME/omnibus/db/servername/storename.log0
v $NCHOME/omnibus/db/servername/storename.log1
Il processo di checkpoint scrive in maniera alternata nei file .chk0 e .chk1. Se
durante un arresto imprevisto uno dei file si danneggia, i dati presenti nell’altro
file di checkpoint e nei log di risposta vengono utilizzati per rigenerare le tabelle
di database in memoria. Quando ciascun checkpoint viene avviato, il processo di
registrazione passa al file di log alternativo. Il vecchio file di log viene eliminato
prima dell’avvio del checkpoint successivo.
24
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Quando ha luogo un arresto pianificato dell’ObjectServer (perché viene eseguito il
comando ALTER SYSTEM SHUTDOWN), per ciascun memstore persistente viene
creato un file .tab. Questo file viene denominato storename.tab.
Ad esempio, il file .tab per l’archivio principale nell’ObjectServer NCOMS viene
denominato:
$NCHOME/omnibus/db/NCOMS/MASTER_STORE.tab
Il formato di questi file è specifico dell’hardware e del sistema operativo su cui
sono stati creati.
Ripristino dei dati durante l’avvio dell’ObjectServer
Quando l’ObjectServer viene riavviato dopo un arresto pianificato, il database
viene ricostruito utilizzando i file .tab.
Quando l’ObjectServer viene riavviato dopo un arresto imprevisto, il database
viene ricostruito utilizzando i file di checkpoint (.chk) e i file di log di risposta
(.log).
Programma di utilità per la verifica del checkpoint
nco_check_store
Il programma di utilità nco_check_store verifica se i file di checkpoint sono validi.
È stato concepito per l’uso da parte delle automazioni e può essere utilizzato solo
per verificare archivi ObjectServer che non sono attualmente in uso.
Il programma di utilità nco_check_store indica la validità dei file di checkpoint con
i seguenti codici di ritorno:
v 0: esito positivo. I file di checkpoint sono validi.
v 1: esito negativo. I file di checkpoint non sono validi e non devono essere
utilizzati.
È anche possibile utilizzare il programma di utilità nco_check_store dalla riga
comandi. Quando richiamato dalla riga comandi, è necessario impostare il livello
di registrazione dei messaggi su info per visualizzare lo stato e i risultati della
verifica.
Nota: Non eseguire nco_check_store quando l’ObjectServer è in esecuzione.
Le opzioni della riga comandi per nco_check_store sono descritte nella seguente
tabella:
Tabella 5. Opzioni della riga comandi per il programma di utilità di verifica del checkpoint
Opzione di riga comandi
Descrizione
-help
Visualizza la guida relativa alle opzioni della riga
comandi ed esce.
-memstoredatadirectory string
Specifica il percorso del database ObjectServer.
L’impostazione predefinita è $NCHOME/omnibus/db.
Capitolo 1. Configurazione dell’ObjectServer
25
Tabella 5. Opzioni della riga comandi per il programma di utilità di verifica del
checkpoint (Continua)
Opzione di riga comandi
Descrizione
-messagelevel string
Specifica il livello di registrazione dei messaggi. I valori
possibili sono: debug, info, warn, error e fatal. Il livello
predefinito è error.
I messaggi registrati ai singoli livelli sono i seguenti:
v fatal: solo fatal
v error: fatal ed error
v warn: fatal, error e warn
v info: fatal, error, warn e info
v debug: fatal, error, warn, info e debug
Suggerimento: Il valore di string può essere in
maiuscolo, minuscolo oppure in maiuscolo e in
minuscolo.
-messagelog string
Specifica il percorso in cui vengono registrati i messaggi.
L’impostazione predefinita è stderr.
-server string
Specifica il nome del database ObjectServer da verificare.
Il valore predefinito è NCOMS.
-version
Visualizza le informazioni di versione sul programma di
utilità per la verifica del checkpoint ed esce.
Esempio di utilizzo
Per utilizzare nco_check_store da un’automazione per verificare che i file di
backup creati dall’ObjectServer siano validi, impostare l’opzione della riga comandi
-memstoredatadirectory sulla directory che contiene il backup.
Modifica dei limiti flessibili e rigidi del memstore table_store
Se le dimensioni del database degli avvisi aumentano notevolmente, è possibile
ricevere il seguente messaggio:
Region soft limit exceeded
Questo messaggio indica che il memstore table_store, in cui vengono memorizzati i
dati della tabella avvisi, ha raggiunto la dimensione massima. È possibile utilizzare
il comando ALTER MEMSTORE per modificare il limite flessibile. Ad esempio, in
nco_sql, immettere:
ALTER MEMSTORE table_store SET SOFT LIMIT 500 M;
Il valore del limite flessibile non può essere maggiore di quello del limite rigido,
che è possibile modificare utilizzando il programma di utilità nco_store_resize.
Questo programma di utilità consente di modificare il limite rigido per il memstore
table_store relativo all’ObjectServer specificato.
Nota: Prima di eseguire il programma di utilità nco_store_resize, è necessario
eseguire il backup dell’ObjectServer utilizzando il comando ALTER SYSTEM
BACKUP, quindi arrestare l’ObjectServer.
Le opzioni della riga comandi per il programma di utilità nco_store_resize sono
descritte nella seguente tabella:
26
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 6. Opzioni della riga comandi del programma di utilità per il ridimensionamento dei
memstore
Opzione di riga comandi
Descrizione
-help
Visualizza la guida relativa alle opzioni della riga
comandi ed esce.
-messagelevel string
Specifica il livello di registrazione dei messaggi. I valori
possibili sono: debug, info, warn, error e fatal. Il livello
predefinito è error.
I messaggi registrati ai singoli livelli sono i seguenti:
v fatal: solo fatal
v error: fatal ed error
v warn: fatal, error e warn
v info: fatal, error, warn e info
v debug: fatal, error, warn, info e debug
Suggerimento: Il valore di string può essere in
maiuscolo, minuscolo oppure in maiuscolo e in
minuscolo.
-messagelog string
Specifica il percorso in cui vengono registrati i messaggi.
L’impostazione predefinita è stderr.
-newhardlimit integer
Specifica il nuovo limite rigido per il memstore, in MB.
L’impostazione predefinita è 500 MB.
-server string
Specifica il nome dell’ObjectServer per il quale la
dimensione del memstore verrà incrementata.
L’impostazione predefinita è NCOMS.
-version
Visualizza le informazioni di versione sul programma di
utilità per la verifica del checkpoint ed esce.
Riferimenti correlati
“Modifica delle impostazioni predefinite e correnti dell’ObjectServer (comando
ALTER SYSTEM)” a pagina 170
Invio di avvisi all’ObjectServer utilizzando nco_postmsg
È possibile inviare un avviso direttamente a un ObjectServer utilizzando il
programma di utilità nco_postmsg. Questo programma di utilità accetta coppie
nome-valore per i dati di avviso e crea un’istruzione SQL INSERT, che viene
utilizzata per inserire una nuova riga di dati in una tabella di database specificata
nell’ObjectServer.
È possibile eseguire nco_postmsg dalla riga comandi oppure è possibile sviluppare
script o automazioni che utilizzano il comando nco_postmsg per inviare avvisi
all’ObjectServer. La frequenza di esecuzione può variare da poche volte al giorno
dalla riga comandi a poche volte al secondo se eseguito da uno script. È anche
possibile eseguire più istanze del programma di utilità nco_postmsg
contemporaneamente. Di seguito sono riportati alcuni esempi di utilizzo del
programma di utilità nco_postmsg:
v È possibile utilizzare nco_postmsg per inviare singoli avvisi all’ObjectServer a
scopo di diagnostica o di verifica; ad esempio, durante la configurazione del
sistema oppure quando si risolvono problemi relativi alla consegna degli avvisi.
v È possibile utilizzare nco_postmsg per inviare avvisi che indicano l’inizio e la
fine di un periodo di manutenzione.
Capitolo 1. Configurazione dell’ObjectServer
27
v È possibile utilizzare nco_postmsg quando nell’ObjectServer occorre un feedback
da una automazione esterna. Ad esempio, si supponga di ricevere un avviso che
causa l’esecuzione di una automazione esterna. Quest’ultima genera uno script
che esegue un’azione il cui esito, positivo o negativo, deve essere registrato
nell’ObjectServer. In tal caso, è possibile includere un comando nco_postmsg
nello script per inserire un nuovo avviso con lo stato dell’azione e, in aggiunta,
configurare automazioni nell’ObjectServer per elaborare il nuovo avviso.
Il programma di utilità nco_postmsg viene installato con la funzione Supporto
probe di Tivoli Netcool/OMNIbus, pertanto può essere distribuito separatamente
da altre funzioni di Tivoli Netcool/OMNIbus, su uno o più host. Per questo
programma di utilità è disponibile un file delle proprietà chiamato
nco_postmsg.props.
Il programma di utilità nco_postmsg può stabilire una connessione sicura
all’ObjectServer utilizzando SSL sia in modalità FIPS 140-2 che in quella non FIPS
140-2.
Per inviare un avviso a un ObjectServer, immettere il seguente comando:
$NCHOME/omnibus/bin/nco_postmsg [ -option [ value ] ... ]
″column_name=column_value″ ...
In questo comando:
v -option è l’opzione della riga comandi nco_postmsg mentre value è il valore sul
quale impostare l’opzione. Non è necessario specificare un valore per ogni
opzione.
v column_name è un nome di colonna valido nella tabella di database in cui si
desidera inserire l’avviso, mentre column_value è il valore di dati corrispondente
che si desidera inserire. Ciascuna coppia nome-valore per
column_name=column_value deve essere racchiusa tra doppie virgolette, come
mostrato nella sintassi per il comando. Inoltre, column_value deve essere
racchiuso tra virgolette singole se si tratta di un valore stringa.
Nota: Se si invia un avviso alla tabella alerts.status, la coppia nome-valore per il
campo relativo all’identificativo è obbligatoria. Per informazioni su come
impostare un valore per la colonna relativa all’identificativo, consultare il
documento IBM Tivoli Netcool/OMNIbus Integration Best Practices, disponibile
all’indirizzo https://www-304.ibm.com/jct01003c/software/brandcatalog/
portal/opal/details?catalog.label=1TW10NC10.
Suggerimento: Quando si specifica column_value, utilizzare un tipo di dati
appropriato per il campo dell’ObjectServer. È possibile utilizzare
Netcool/OMNIbus Administrator per verificare i tipi di dati assegnati ai campi
nelle tabelle di database oppure è possibile utilizzare il comando DESCRIBE SQL
dell’ObjectServer.
Esecuzione di nco_postmsg nella codifica UTF-8
È possibile eseguire il programma di utilità nco_postmsg nella codifica UTF-8
utilizzando l’opzione della riga comandi -utf8enabled. Tuttavia, non è possibile
specificare le coppie nome-valore direttamente dalla riga comandi ed è, invece,
necessario aggiungere coppie nome-valore a un file di testo. Nel file di testo, è
necessario specificare ciascuna coppia nome-valore in una riga a parte e
racchiudere il valore tra virgolette singole se si tratta di un valore stringa. Il file di
28
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
testo deve essere nella codifica UTF-8 e può contenere dati solo per un unico
avviso. Anche il file delle proprietà nco_postmsg.props deve essere nella codifica
UTF-8.
La sintassi per eseguire nco_postmsg nella codifica UTF-8 è:
$NCHOME/omnibus/bin/nco_postmsg [ -option [ value ] ... ] -utf8enabled TRUE
< file_name.txt
In questo comando:
v -option è una delle opzioni della riga comandi nco_postmsg (diversa da
-utf8enabled), mentre value è il valore sul quale impostare l’opzione.
v file_name.txt è il file che contiene le coppie nome-valore.
Elaborazione degli errori
Quando il programma di utilità nco_postmsg viene eseguito, legge il proprio file
delle proprietà, convalida eventuali opzioni della riga comandi che sono state
specificate, quindi crea l’istruzione INSERT utilizzando le coppie nome-valore che
sono state specificate. Gli avvisi vengono inviati all’ObjectServer purché le coppie
nome-valore specificate e le opzioni della riga comandi immesse siano valide.
Eventuali errori che si verificano vengono classificati nel modo seguente:
Errori che causano la scrittura dell’avviso corrente in un file di cache.
Se si verifica un errore di comunicazione perché l’ObjectServer non è attivo
oppure impiega troppo tempo nel rispondere, il programma di utilità
nco_postmsg salva l’avviso in un file di cache chiamato nco_postmsg.cache,
quindi esce. Qualsiasi avviso successivo generato quando c’è un errore di
comunicazione viene anch’esso scritto nel file di cache. Quando il file di
cache raggiunge la dimensione massima, il file viene rinominato con un
suffisso _old e viene creato un nuovo file nco_postmsg.cache. Se esiste già
un file di nome nco_postmsg.cache_old, viene eliminato durante il
processo di ridenominazione e il suo contenuto andrà perso.
Suggerimento: Il limite di tempo di risposta dell’ObjectServer viene
impostato mediante la proprietà Ipc.Timeout di nco_postmsg e la
dimensione massima del file di cache viene impostata mediante la
proprietà MaxCacheFileSize.
La volta successiva in cui il programma di utilità nco_postmsg viene
eseguito e può connettersi all’ObjectServer, vengono inviati avvisi
all’ObjectServer nell’ordine seguente:
1. Avvisi nel file nco_postmsg.cache_old (se ne esiste uno). Gli avvisi
vengono inviati a partire da quello più vecchio in ordine di tempo.
Quando è vuoto, il file viene eliminato.
2. Avvisi nel file nco_postmsg.cache. Quando è vuoto, il file viene troncato
a 0 byte.
3. L’avviso corrente, che è stato generato quando è stato eseguito il
programma di utilità nco_postmsg.
Errori che causano l’eliminazione dell’avviso corrente.
Gli avvisi vengono eliminati a causa delle seguenti condizioni:
v Errori della riga comandi: è stato specificato un percorso del file delle
proprietà non valido oppure è stata specificata sintassi non valida per le
coppie nome-valore.
Capitolo 1. Configurazione dell’ObjectServer
29
v Errori di autenticazione: l’autenticazione con l’ObjectServer non è
riuscita a causa di credenziali di accesso non valide, di un nome
dell’ObjectServer non valido o di errori SSL.
v Errori del database: l’autorizzazione di scrittura della tabella di database
non è stata impostata, il nome della tabella di database non è valido
oppure si è verificato un errore di sintassi nell’istruzione INSERT
costruita.
v Errori di file: si è verificato un errore durante la scrittura della voce nel
file di cache oppure si sono verificati errori di sintassi nel file delle
proprietà.
Tutti gli errori vengono scritti in un file di log.
Altre note
v Gli utenti di nco_postmsg sono soggetti al sistema di autorizzazione
dell’ObjectServer, quindi devono disporre di autorizzazioni di inserimento nelle
tabelle di database in cui vengono scritti i dati.
v Se non impostata nel file delle proprietà, una password viene richiesta quando il
programma di utilità nco_postmsg viene eseguito dalla riga comandi.
v Se il programma di utilità nco_postmsg inserisce dati nella tabella alerts.status,
imposta il valore delle colonne FirstOccurrence e LastOccurrence sull’ora UNIX
o POSIX corrente, a meno che i valori di queste colonne non vengano specificati
esplicitamente nella riga comandi oppure in uno script.
v Se si specifica un valore per la colonna Class quando si esegue nco_postmsg,
una coppia nome-valore viene aggiunta all’istruzione INSERT. Se non si specifica
nessun valore per la colonna Class, l’ObjectServer assegna la classe predefinita di
0 (zero) all’avviso.
v È possibile configurare più istanze del programma di utilità nco_postmsg per
memorizzare nella cache avvisi per lo stesso file utilizzando la proprietà
CacheFile.
v Qualora dovesse verificarsi un errore di comunicazione durante l’invio di avvisi
da un file di cache alla tabella alerts.status, gli avvisi vengono mantenuti nel file
di cache. Il programma di utilità nco_postmsg prova a inviare di nuovo gli
avvisi la volta successiva in cui viene eseguito. Pertanto, potrebbe accadere che
un avviso venga inviato più di una volta, nel qual caso, il valore del campo
Tally non verrà incrementato correttamente.
Concetti correlati
Capitolo 3, “Utilizzo di Netcool/OMNIbus Administrator per configurare
ObjectServer”, a pagina 45
Riferimenti correlati
“Visualizzazione dei dettagli relativi alle colonne di una tabella o di una vista
(comando DESCRIBE)” a pagina 168
Appendice A, “Tabelle dell’ObjectServer”, a pagina 311
30
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Proprietà e opzioni della riga comandi di nco_postmsg
Il programma di utilità nco_postmsg contiene una serie di proprietà e opzioni della
riga comandi per inviare avvisi all’ObjectServer. È possibile eseguire questo
comando dalla directory $NCHOME/omnibus/bin.
Il file delle proprietà di nco_postmsg è $NCHOME/omnibus/etc/nco_postmsg.props.
In un file delle proprietà non modificato, tutte le proprietà sono impostate su
valori predefiniti e vengono impostate come commento inserendo il simbolo del
cancelletto (#) all’inizio della riga. Per sovrascrivere un valore predefinito,
modificarne l’impostazione nel file delle proprietà e rimuovere il simbolo del
cancelletto (#). Se si modifica un’impostazione sulla riga comandi, entrambi il
valore predefinito e l’impostazione nel file delle proprietà vengono sovrascritti.
Le proprietà e le opzioni della riga comandi per nco_postmsg sono descritte nella
seguente tabella:
Tabella 7. Proprietà e opzioni della riga comandi di nco_postmsg
Proprietà
Opzione di riga
comandi
CacheFile string
-cachefile string
Descrizione
Specifica il nome e il percorso completi del file di cache in
cui vengono memorizzati gli avvisi quando non possono
essere inviati all’ObjectServer a causa di un errore di
comunicazione. L’impostazione predefinita è
$NCHOME/omnibus/var/nco_postmsg.cache.
Quando il file di cache raggiunge la dimensione massima,
specificata mediante la proprietà MaxCacheFileSize, il file
nco_postmsg.cache viene rinominato
nco_postmsg.cache_old e viene creato un nuovo file
nco_postmsg.cache.
CacheFileWarnThreshold
integer
N/D
Fa sì che un messaggio di avvertenza venga scritto nel file
di log quando la dimensione del file nco_postmsg.cache
supera un valore percentuale specificato. Si noti che
questa impostazione non ha alcun effetto sul file
nco_postmsg.cache_old. L’impostazione predefinita è 90%.
L’intervallo è compreso tra 10% e 99%.
ConfigCryptoAlg string
N/D
Specifica l’algoritmo crittografico da utilizzare per
decodificare i valori stringa (incluse le password)
codificati con il programma di utilità nco_aes_crypt e
successivamente memorizzate nel file delle proprietà.
Impostare il valore string nel modo seguente:
v In modalità FIPS 140-2, utilizzare AES_FIPS.
v In modalità non FIPS 140–2, è possibile utilizzare
AES_FIPS o AES. Utilizzare AES solo se occorre
mantenere la compatibilità con password che sono state
codificate tramite gli strumenti forniti in versioni
precedenti a Tivoli Netcool/OMNIbus V7.2.1.
Il valore specificato deve essere identico al valore
utilizzato durante l’esecuzione di nco_aes_crypt con
l’impostazione -c, per codificare i valori stringa.
Utilizzare questa proprietà insieme alla proprietà
ConfigKeyFile.
L’impostazione predefinita è AES.
Capitolo 1. Configurazione dell’ObjectServer
31
Tabella 7. Proprietà e opzioni della riga comandi di nco_postmsg (Continua)
Proprietà
Opzione di riga
comandi
ConfigKeyFile string
N/D
Descrizione
Specifica il percorso e il nome del file chiave contenente la
chiave utilizzata per decodificare i valori stringa codificati
(incluse le password) nel file delle proprietà.
La chiave viene utilizzata durante il runtime per
decodificare i valori stringa codificati con il programma di
utilità nco_aes_crypt. Il file chiave specificato deve essere
identico al file utilizzato per codificare i valori stringa
durante l’esecuzione di nco_aes_crypt con l’impostazione
-k.
Utilizzare questa proprietà insieme alla proprietà
ConfigCryptoAlg.
N/D
-help
Visualizza la guida relativa alle opzioni della riga
comandi ed esce.
Ipc.Timeout integer
-ipctimeout integer
Imposta il tempo, in secondi, che il programma di utilità
nco_postmsg attende per ricevere una risposta
dall’ObjectServer, durante il tentativo di inviare avvisi.
L’impostazione predefinita è 60 secondi.
Se questo periodo di tempo viene superato (oppure
l’ObjectServer non è attivo), si verifica un errore di
comunicazione e l’avviso viene inviato al file di cache.
MaxCacheFileSize integer
-maxcachefilesize
integer
Imposta la dimensione massima del file di cache, in KB.
L’impostazione predefinita è 10240 KB.
Se impostata su 0 (zero), nessun file di cache viene creato
o utilizzato.
MessageLevel string
-messagelevel string
Specifica il livello di registrazione dei messaggi. I valori
possibili sono: debug, info, warn, error e fatal. Il livello
predefinito è warn.
I messaggi registrati ai singoli livelli sono i seguenti:
v fatal: solo fatal
v error: fatal ed error
v warn: fatal, error e warn
v info: fatal, error, warn e info
v debug: fatal, error, warn, info e debug
Suggerimento: Il valore di string può essere in maiuscolo,
minuscolo oppure in maiuscolo e in minuscolo.
MessageLog string
-messagelog string
Specifica l’ubicazione in cui vengono registrati i messaggi.
I messaggi possono essere registrati in un file di log o in
stderr.
L’impostazione predefinita è $NCHOME/omnibus/log/
nco_postmsg.log.
32
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 7. Proprietà e opzioni della riga comandi di nco_postmsg (Continua)
Proprietà
Opzione di riga
comandi
Name string
-name string
Descrizione
Specifica un nome client per il programma di utilità
nco_postmsg. Questo nome viene utilizzato come
descrizione dell’applicazione quando nco_postmsg si
connette all’ObjectServer. L’impostazione predefinita è
nco_postmsg.
Il valore della proprietà Name determina anche il nome
del file delle proprietà, il cui formato è il seguente:
$NCHOME/omnibus/etc/name.props.
Suggerimento: È possibile utilizzare la proprietà Name
per distinguere i vari client nco_postmsg che inviano
avvisi all’ObjectServer e per mantenere i singoli file delle
proprietà per ciascun client.
Password string
-password string
Specifica la password per l’utente che si connette
all’ObjectServer. L’impostazione predefinita è ''.
Props.CheckNames TRUE |
FALSE
N/D
Fa sì che il programma di utilità nco_postmsg venga
arrestato se una delle proprietà specificate non è valida.
L’impostazione predefinita è TRUE.
PropsFile string
-propsfile string
Specifica il nome e il percorso completi del file delle
proprietà per il programma di utilità nco_postmsg.
L’impostazione predefinita è $NCHOME/omnibus/etc/
nco_postmsg.props.
Server string
-server string
Imposta il nome dell’ObjectServer a cui il programma di
utilità nco_postmsg si connette e invia un avviso.
L’impostazione predefinita è NCOMS.
SSLServerCommonName
string1,...
N/D
Specifica un elenco di nomi comuni separati da una
virgola da utilizzare se il programma di utilità
nco_postmsg si connette all’ObjectServer utilizzando SSL.
L’impostazione predefinita è ''.
Table string
-table string
Imposta il nome della tabella di database in cui
l’istruzione INSERT aggiunge i dati di avviso.
L’impostazione predefinita è alerts.status.
UserName string
-username string
Specifica il nome utente utilizzato per l’autenticazione al
momento della connessione all’ObjectServer. Il nome
utente predefinito è quello utilizzato per accedere al
computer.
oppure
-user string
N/D
Windows
-utf8enabled TRUE |
FALSE
N/D
-version
Controlla la codifica di dati passati alle applicazioni o
generati a questa applicazione su Windows.
Impostare il valore di -utf8enabled su TRUE per eseguire
l’applicazione nella codifica UTF-8. Il valore predefinito è
FALSE, che consente l’utilizzo della codepage predefinita
del sistema.
Importante: Sebbene la proprietà UTF8Enabled sia
disponibile, un tentativo di abilitare la codifica UTF-8
impostando questa proprietà su TRUE non avrà alcun
effetto. Per utilizzare la codifica UTF-8 in Windows, è
necessario utilizzare sempre l’opzione della riga comandi
-utf8enabled.
Visualizza le informazioni sulla versione per il
programma di utilità ed esce.
Capitolo 1. Configurazione dell’ObjectServer
33
Esempi di nco_postmsg e istruzioni INSERT risultanti
Il programma di utilità nco_postmsg accetta input da opzioni della riga comandi,
script o un file di testo e genera una istruzione INSERT SQL dell’ObjectServer che
viene inviata a un ObjectServer. Di seguito viene fornito un esempio di comandi
nco_postmsg e delle risultanti istruzioni INSERT.
Esempio 1
Questo esempio scrive un avviso nell’ObjectServer NCOMS predefinito e nella
tabella alerts.status predefinita. Il nome utente e la password per l’autenticazione
con NCOMS non sono stati impostati nel file delle proprietà nco_postmsg, ma
vengono specificati dalla riga comandi.
Il comando nco_postmsg immesso è:
nco_postmsg -user root -password "" "Identifier='example 1'" "Severity=3"
"Manager='nco_postmsg'" "Summary='An event occurred'"
L’istruzione INSERT risultante che viene inviata alla tabella alerts.status in
NCOMS è:
insert into alerts.status (Identifier,Severity,Manager,Summary,FirstOccurrence,LastOccurrence)
values ('example 1',3,'nco_postmsg','an event occurred',1255341764,1255341764);
Dal momento che le coppie nome-valore non sono state specificate in maniera
esplicita per FirstOccurrence e LastOccurrence nel comando nco_postmsg,
FirstOccurrence e LastOccurrence vengono impostate automaticamente sull’ora
UNIX corrente nell’istruzione INSERT inviata alla tabella alerts.status.
Esempio 2
Questo esempio scrive un avviso nella tabella alerts.status di un ObjectServer che
si chiama PRESLEY. Il programma di utilità nco_postmsg si autentica con
l’ObjectServer utilizzando il nome utente myname e una password codificata, che
sono specificati nel file delle proprietà nco_postmsg.
In questo caso, si presuppone che sia stata utilizzata la codifica dei valori delle
proprietà per codificare la password nel file delle proprietà in modo che la
password non possa essere letta senza una chiave. Le impostazioni del file delle
proprietà per le credenziali di accesso, inclusa la codifica delle password, vengono
private del commento e completate nel modo seguente:
ConfigCryptoAlg: 'AES_FIPS'
ConfigKeyFile: '/dir/subdir/secret.txt'
...
Password: '@44:Kris2m3QLsy+dZYNt3/jptl8cd7c6Fmboaj+E6XrNw8=@'
UserName: 'myname'
Il comando nco_postmsg immesso è:
nco_postmsg –server PRESLEY "Identifier='example 2'" "Node='London'"
L’istruzione INSERT risultante che viene inviata alla tabella alerts.status in
PRESLEY è la seguente:
insert into alerts.status (Identifier,Node,FirstOccurrence,LastOccurrence)
values ('example 2','London',1255341764,1255341764);
34
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Esempio 3
Questo esempio inserisce un avviso nella tabella mydb.mytable nell’ObjectServer
NCOMS predefinito. In questo caso, si presuppone che un nome utente e una
password siano specificati nel file delle proprietà nco_postmsg.
Il comando nco_postmsg immesso è:
nco_postmsg –table mydb.mytable "Identifier='example 3'" "Occurrence=1234567890"
"Summary='write into my table'"
L’istruzione INSERT risultante che viene inviata alla tabella mydb.mytable in
NCOMS è la seguente:
insert into mydb.mytable (Identifier,Occurrence,Summary)
values ('example 3',1234567890,'write into my table');
Esempio 4
Questo esempio mostra come eseguire il programma di utilità nco_postmsg nella
codifica UTF-8.
Il programma di utilità nco_postmsg si autentica con l’ObjectServer utilizzando il
nome utente myname e una password, che sono specificati nel file delle proprietà
nco_postmsg.props nel modo seguente:
Password: 'secret'
UserName: 'myname'
Questo file delle proprietà deve essere salvato nella codifica UTF-8.
Un file di testo, my_data.txt, viene creato con le seguenti coppie nome-valore per
l’avviso da inviare all’ObjectServer:
Identifier='example 2'
Node='London'
Questo file di testo deve essere salvato nella codifica UTF-8.
Per eseguire nco_postmsg nella codifica UTF-8 e scrivere un avviso alla tabella
alerts.status di un ObjectServer denominato PRESLEY (presumibilmente anch’esso
in esecuzione nella codifica UTF-8), il comando immesso è:
nco_postmsg –server PRESLEY -utf8enabled TRUE < /file_path/my_data.txt
L’istruzione INSERT risultante che viene inviata alla tabella alerts.status in
PRESLEY è la seguente:
insert into alerts.status (Identifier,Node,FirstOccurrence,LastOccurrence)
values ('example 2','London',1255341764,1255341764);
Capitolo 1. Configurazione dell’ObjectServer
35
36
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Capitolo 2. Configurazione di un server proxy
L’ObjectServer riceve informazioni di avviso dai probe. In una configurazione
standard, gli avvisi vengono inoltrati direttamente all’ObjectServer. È possibile
configurare un server proxy per ridurre il numero di connessioni probe con un
ObjectServer.
Quando molti probe inoltrano informazioni di avviso direttamente all’ObjectServer,
e vengono stabilite anche molte connessioni desktop allo stesso ObjectServer, le
prestazioni potrebbero subire un peggioramento.
Un server proxy fornisce un buffer per ridurre il numero di connessioni dirette
all’ObjectServer principale. Più connessioni probe stabilite con il server proxy
vengono messe in multiplex e inoltrate tramite una singola connessione
all’ObjectServer.
Nella seguente figura viene illustrata la modalità di comunicazione tra i probe e il
server proxy.
Multiple event streams
ObjectServer
NCOMS
Single event stream
Proxy Server
NCO_PROXY
Probes
Figura 1. Architettura server proxy di esempio
Avvio del server proxy
È possibile avviare automaticamente il server proxy utilizzando il controllo
processi in UNIX e Windows e anche utilizzando i servizi su Windows. È inoltre
possibile avviare manualmente il server proxy dalla riga comandi. In generale,
utilizzare il controllo processi per avviare il server proxy.
Avvio di un server proxy mediante il controllo processi
In UNIX e Windows, è possibile avviare un server proxy come processo
utilizzando il controllo processi. Il server proxy deve essere definito come processo
o parte di un servizio.
Concetti correlati
Capitolo 6, “Utilizzo del controllo processi per gestire processi e procedure
esterne”, a pagina 241
© Copyright IBM Corp. 1994, 2009
37
Avvio di un server proxy mediante i servizi (Windows)
In Windows, è possibile installare ed eseguire il server proxy come servizio
Windows. Quando il servizio è impostato su automatico, il server proxy viene
avviato all’avvio del computer.
È necessario installare manualmente e configurare il server proxy da eseguire come
servizio in un host Windows.
Avvio manuale del server proxy
Utilizzare il comando nco_proxyserv per avviare il server proxy manualmente.
Dalla riga comandi, immettere il comando appropriato per il sistema operativo:
Tabella 8. Avvio del server proxy dalla riga comandi
Sistema operativo
Comando
UNIX
$NCHOME/omnibus/bin/nco_proxyserv [ -name proxyname] [-server servername]
Windows
%NCHOME%\omnibus\bin\nco_proxyserv [ -name proxyname] [-server servername]
In entrambi i comandi, proxyname è il nome del server proxy e servername è il nome
dell’ObjectServer. Se non si specifica l’opzione di riga comandi -name, il nome del
server proxy predefinito è NCO_PROXY. Se non si specifica l’opzione di riga
comandi -server, il server proxy esegue il buffer delle connessioni per l’ObjectServer
NCOMS.
È possibile avviare il server proxy con ulteriori opzioni di riga comandi.
Opzioni di riga comandi e proprietà del server proxy
Il server proxy legge il proprio file delle proprietà quando viene avviato. Se in
questo file una proprietà non è specificata, viene utilizzato il valore predefinito fino
a quando non viene sovrascritto eseguendo un’opzione della riga comandi.
L’ubicazione predefinita del file delle proprietà è $NCHOME/omnibus/etc/
proxyserver.props.
Nel file delle proprietà, una proprietà e il suo valore corrispondente sono separati
dai due punti (:). I valori stringa sono racchiusi tra apici, ad esempio:
ServerName: "NCO_PROXY"
Suggerimento: È possibile codificare i valori stringa in un file delle proprietà
utilizzando la codifica del valore della proprietà.
Le opzioni di riga comandi per il server proxy utilizzano il seguente formato:
nco_proxyserv [ -option [ value ] ... ]
In questo comando, l’opzione -option è l’opzione di riga comandi e value è il valore
su cui si imposta l’opzione. Non è necessario specificare un valore per ogni
opzione.
Se non si specifica un file delle proprietà quando viene avviato un server proxy,
viene utilizzato il file predefinito. Utilizzare l’opzione di riga comandi -propsfile
per specificare il percorso completo e il nome file di un file delle proprietà
alternativo.
38
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Nella seguente tabella solo elencate le proprietà del server proxy e le opzioni di
riga comandi.
Tabella 9. Opzioni di riga comandi e proprietà del server proxy
Proprietà
Opzione di riga comandi
Descrizione
AuthPassword string
N/D
La password è associata al nome utente
utilizzato per autenticare il server proxy quando
si collega a un ObjectServer in esecuzione in
modalità sicura. L’impostazione predefinita è ''.
In modalità FIPS 140–2, è possibile specificare la
password in testo semplice o codificarla con il
programma di utilità nco_aes_crypt. Se le
password vengono codificate tramite
nco_aes_crypt in modalità FIPS 140–2, è
necessario specificare AES_FIPS come algoritmo
di codifica.
Quando non si utilizza la modalità FIPS 140–2, è
possibile codificare la password con il
programma di utilità nco_g_crypt o
nco_aes_crypt. Se le password vengono
codificate tramite nco_aes_crypt in modalità
non-FIPS 140–2, è possibile specificare AES_FIPS
o AES come algoritmo di codifica. Utilizzare
AES solo se occorre mantenere la compatibilità
con password che sono state codificate con gli
strumenti forniti in versioni precedenti a Tivoli
Netcool/OMNIbus V7.2.1.
AuthUserName string
N/D
Il nome utente utilizzato per autenticare il
server proxy quando si collega a un
ObjectServer in esecuzione in modalità sicura.
L’impostazione predefinita è root.
ConfigCryptoAlg string
N/D
Specifica l’algoritmo crittografico da utilizzare
per decodificare i valori stringa (incluse le
password) codificati con il programma di utilità
nco_aes_crypt e successivamente memorizzate
nel file delle proprietà. Impostare il valore string
nel modo seguente:
v In modalità FIPS 140-2, utilizzare AES_FIPS.
v In modalità non FIPS 140–2, è possibile
utilizzare AES_FIPS o AES. Utilizzare AES
solo se occorre mantenere la compatibilità con
password che sono state codificate tramite gli
strumenti forniti in versioni precedenti a
Tivoli Netcool/OMNIbus V7.2.1.
Il valore specificato deve essere identico al
valore utilizzato durante l’esecuzione di
nco_aes_crypt con l’impostazione -c, per
codificare i valori stringa.
Utilizzare questa proprietà insieme alla
proprietà ConfigKeyFile.
Capitolo 2. Configurazione di un server proxy
39
Tabella 9. Opzioni di riga comandi e proprietà del server proxy (Continua)
Proprietà
Opzione di riga comandi
Descrizione
ConfigKeyFile string
N/D
Specifica il percorso e il nome del file chiave
contenente la chiave utilizzata per decodificare i
valori stringa codificati (incluse le password) nel
file delle proprietà.
La chiave viene utilizzata durante il runtime per
decodificare i valori stringa codificati con il
programma di utilità nco_aes_crypt. Il file
chiave specificato deve essere identico al file
utilizzato per codificare i valori stringa durante
l’esecuzione di nco_aes_crypt con l’impostazione
-k.
Utilizzare questa proprietà insieme alla
proprietà ConfigCryptoAlg.
ConnectionRatio integer
-ratio integer
Impostare il rapporto tra le connessioni in
entrata dai probe e le connessioni in uscita in un
ObjectServer. Il valore predefinito 10 crea un
rapporto pari a 10:1 tra le connessioni in entrata
e in uscita.
N/D
-help
Visualizza le opzioni di riga comandi supportate
ed esce.
N/D
-logfile string
Imposta il nome del file in cui il server proxy
scrive i messaggi, inclusi gli errori. Per
impostazione predefinita, il file è
$NCHOME/omnibus/log/servername.log, dove
servername è definito dall’opzione -name.
MaxConnections integer
-max integer
Imposta il numero massimo di connessioni
disponibili per i probe. Il valore minimo (e
predefinito) è 30 e il valore massimo è 250.
NetworkTimeout integer
-networktimeout integer
Specifica il tempo, in secondi, dopo cui un
tentativo di accesso o una connessione
all’ObjectServer scade, se si verifica un errore di
rete. Dopo il periodo di tempo specificato, il
server proxy tenta di ricollegarsi
all’ObjectServer. Se la connessione non riesce
dopo un secondo periodo di timeout, il server
proxy tenta di collegarsi a un ObjectServer di
backup, se disponibile. L’impostazione
predefinita è 20.
OldTimeStamp TRUE | FALSE
-oldtimestamp TRUE | FALSE
Specifica il formato data/ora da utilizzare nel
file di log.
Impostare il valore su TRUE per visualizzare il
formato data/ora utilizzato in Tivoli
Netcool/OMNIbus V7.2.1 oppure in una
versione precedente. Ad esempio,
gg/MM/AAAA hh:mm:ss AM o
gg/MM/AAAA hh:mm:ss PM quando la locale
è impostata su en_GB in un computer Solaris 9.
Impostare il valore su FALSE per visualizzare il
formato ISO 8601 nel file di log. Ad esempio:
AAAA-MM-GGThh:mm:ss, dove T separa la
data e l’ora e hh è nel formato di 24 ore.
L’impostazione predefinita è FALSE.
40
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 9. Opzioni di riga comandi e proprietà del server proxy (Continua)
Proprietà
Opzione di riga comandi
Descrizione
N/D
-propsfile string
Imposta il nome del file delle proprietà del
server proxy. Il nome predefinito è
$NCHOME/omnibus/etc/servername.props, dove
servername è definito dall’opzione -name.
RemoteServer string
-server string
Imposta il nome dell’ObjectServer a cui si
collega il server proxy. L’impostazione
predefinita è NCOMS.
SecureMode TRUE | FALSE
-secure
Imposta la modalità di sicurezza del server
proxy. Se abilitato, il server proxy autentica le
richieste di connessione probe con un nome
utente e una password. Se disabilitato
(l’impostazione predefinita), i probe possono
collegarsi al server proxy senza un nome utente
e una password.
ServerName string
-name string
Imposta il nome del server proxy. Questo è il
nome configurato dall’editor del server.
L’impostazione predefinita è NCO_PROXY.
N/D
-version
Visualizza le informazioni sulla versione sul
server proxy ed esce.
Riferimenti correlati
“Esecuzione del server proxy in modalità sicura”
“Esecuzione dell’ObjectServer in modalità sicura” a pagina 19
Connessione al server proxy
Per collegare i probe al server proxy, specificare il nome del server proxy nella
proprietà Server nel file delle proprietà dei probe oppure utilizzare l’opzione di
riga comandi -server.
Tutti gli avvisi vengono quindi inviati al server proxy.
Esecuzione del server proxy in modalità sicura
È possibile eseguire il server proxy in modalità sicura. Quando si specifica la
proprietà SecureMode dell’opzione di riga comandi -secure, il server proxy
autentica le connessioni probe richiedendo un nome utente e una password.
Quando viene inviata una richiesta di connessione, il server proxy emette un
messaggio di autenticazione. Il probe deve rispondere con il nome utente e la
password corretti.
Se non si specifica l’opzione -secure, le richieste di connessione probe non vengono
autenticate.
Quando si stabilisce una connessione a un server proxy sicuro, ogni probe deve
avere una proprietà AuthUserName e una proprietà AuthPassword specificate nel
relativo file delle proprietà. Se la combinazione di nome utente e password non è
corretta, il server proxy emette un messaggio di errore.
È possibile scegliere qualsiasi nome utente valido per la proprietà AuthUserName.
Capitolo 2. Configurazione di un server proxy
41
I dettagli di codifica della password per l’esecuzione in modalità FIPS 140–2 e non
FIPS 140–2 sono descritti nella seguente tabella.
Tabella 10. Codifica della password in modalità FIPS 140–2 e non FIPS 140–2
Modalità
Azione
Modalità FIPS
140–2
In modalità FIPS 140–2, è possibile specificare le password in testo
semplice o in formato codificato. La codifica delle password può
avvenire tramite codifica dei valori di proprietà, nel modo seguente:
1. Se non si dispone ancora di una chiave per la codifica della
password, crearne una eseguendo il programma di utilità
nco_keygen, situato in $NCHOME/omnibus/bin.
2. Eseguire il programma di utilità nco_aes_crypt per codificare la
password con la chiave generata dal programma di utilità
nco_keygen. Anche il programma di utilità nco_aes_crypt si trova in
$NCHOME/omnibus/bin. Tenere presente che è necessario specificare
AES_FIPS come algoritmo da utilizzare per la codifica della
password.
3. Aprire il file delle proprietà a cui si desidera aggiungere la
password codificata e specificare l’output codificato per
l’impostazione AuthPassword.
Nota: È inoltre necessario impostare la proprietà ConfigKeyFile sul
file chiave specificato durante l’esecuzione di nco_aes_crypt e
impostare la proprietà ConfigCryptoAlg sull’algoritmo di codifica
utilizzato.
Modalità non
FIPS 140–2
In modalità non FIPS 140–2, è possibile specificare le password in testo
semplice o in formato codificato. Tuttavia, il client trasmette sempre
informazioni di accesso codificate, indipendentemente dalla codifica
password utilizzata nel file delle proprietà. La codifica delle password
può avvenire tramite il programma di utilità nco_g_crypt o tramite la
codifica dei valori di proprietà, nel modo seguente:
v Per codificare una password tramite il programma di utilità
nco_g_crypt, eseguire il comando nel modo seguente:
$NCHOME/omnibus/bin/nco_g_crypt plaintext_password
In questo comando, plaintext_password rappresenta il formato non
codificato della password. Il programma di utilità nco_g_crypt
acquisisce la password non codificata e visualizza una versione
codificata. Aprire il file delle proprietà a cui si desidera aggiungere la
password codificata e specificare l’output codificato per
l’impostazione AuthPassword.
v Per codificare una password utilizzando una codifica dei valori di
proprietà, è necessaria una chiave generata con il programma di
utilità nco_keygen. È quindi possibile eseguire nco_aes_crypt per
codificare la password con la chiave. Tenere presente che è possibile
specificare AES_FIPS o AES come algoritmo per la codifica della
password. Utilizzare AES solo se occorre mantenere la compatibilità
con password che sono state codificate con gli strumenti forniti in
versioni precedenti a Tivoli Netcool/OMNIbus V7.2.1.
Aprire il file a cui si desidera aggiungere la password codificata e
specificare l’output codificato per l’impostazione AuthPassword.
Nota: È inoltre necessario impostare la proprietà ConfigKeyFile sul
file chiave specificato durante l’esecuzione di nco_aes_crypt e
impostare la proprietà ConfigCryptoAlg sull’algoritmo di codifica
utilizzato.
Se l’ObjectServer è in esecuzione in modalità sicura, perché il server proxy possa
collegarsi all’ObjectServer, nel file delle proprietà del server proxy devono essere
42
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
presenti le proprietà AuthUserName e AuthPassword. Se la combinazione di nome
utente e password non è corretta, l’ObjectServer emette un messaggio di errore. Il
valore di AuthPassword può essere in testo semplice o codificato, come descritto
nella seguente tabella.
Attenzione: Le password codificate con nco_g_crypt possono essere utilizzate
nello stesso modo delle password non codificate per accedere all’ObjectServer. Di
conseguenza, è necessario impostare le autorizzazioni appropriate sui file
contenenti le password codificate per impedire l’accesso non autorizzato. In
alternativa, è necessario codificare ulteriormente con nco_aes_crypt le password
che sono state codificate con nco_g_crypt e impostare in modo appropriato le
autorizzazioni sul file chiave.
Per ulteriori informazioni sulle proprietà dei probe, vedere IBM Tivoli
Netcool/OMNIbus - Guida a probe e gateway.
Capitolo 2. Configurazione di un server proxy
43
44
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per
configurare ObjectServer
L’ObjectServer archivia, gestisce ed elabora avvisi e dati relativi allo stato che
vengono raccolti da applicazioni esterne quali, ad esempio, probe e gateway. È
possibile utilizzare Netcool/OMNIbus Administrator per configurare oggetti
ObjectServer e per configurare il controllo processi.
È possibile utilizzare Netcool/OMNIbus Administrator per configurare i seguenti
oggetti ObjectServer:
v Utenti, gruppi, ruoli e filtri limitazioni
v Menu degli elenchi eventi
v
v
v
v
v
v
v
v
v
Strumenti e prompt
Gruppi di trigger e trigger
Procedure
Segnali definiti dall’utente
Colori per indicare la severità degli avvisi degli elenchi eventi (solo per gli
elenchi eventi Windows)
Conversioni
Classi
Visuali di colonne
Database, file e proprietà ObjectServer
v Canali per la notifica eventi accelerati
Informazioni preliminari su Netcool/OMNIbus Administrator
Netcool/OMNIbus Administrator fornisce un’interfaccia visiva da cui è possibile
gestire gli ObjectServer e configurare il controllo processi.
Prerequisiti: Netcool/OMNIbus Administrator richiede l’installazione di Java™
Runtime Environment (JRE) versione 5.0 sul sistema.
Considerazioni sul supporto multiculturale
Tivoli Netcool/OMNIbus supporta una vasta gamma di codifiche di caratteri a
byte singolo o a più byte da utilizzare nelle diverse locale.
Se i nomi utente e le password vengono specificati in caratteri a più byte e queste
credenziali devono essere verificate sulla base di origini di autenticazione esterne,
queste origini devono supportare anche i caratteri a più byte. Se i caratteri a più
byte non sono supportati, i nomi utente e le password devono essere specificati
utilizzando caratteri ASCII.
Quando si utilizza Netcool/OMNIbus Administrator, è necessario assicurarsi che la
codifica della serie di caratteri di ciascun ObjectServer da gestire abbia una voce
corrispondente nel file $NCHOME/omnibus/java/jars/csemap.dat. Questo file fornisce
un’associazione tra le convenzioni di denominazione della codifica delle serie di
caratteri Sybase e JRE. Se la codifica della serie di caratteri di un ObjectServer
manca in csemap.dat, è necessario aggiungere a questo file un’associazione
utilizzando il seguente formato:
© Copyright IBM Corp. 1994, 2009
45
Sybase_encoding Java_encoding
Ad esempio:
ascii_7 ASCII
Per ulteriori informazioni sul supporto multiculturale, consultare IBM Tivoli
Netcool/OMNIbus - Guida all’installazione e alla distribuzione.
Avvio di Netcool/OMNIbus Administrator
Per avviare Netcool/OMNIbus Administrator, è necessario eseguire il programma
di utilità nco_config.
Per avviare Netcool/OMNIbus Administrator dalla riga comandi:
1. Immettere il comando specifico del proprio sistema operativo:
Tabella 11. Avvio di Netcool/OMNIbus Administrator
Opzione
Descrizione
UNIX
$NCHOME/omnibus/bin/nco_config [ -option value ... ]
Windows
%NCHOME%\omnibus\bin\nco_config.vbs [ -option value ... ]
In questo comando, -option è un’opzione della riga comandi valida, mentre
value è il valore sul quale configurare l’opzione.
2. Se questa è la prima volta che si avvia Netcool/OMNIbus Administrator
oppure se il file delle impostazioni delle comunicazioni ($NCHOME/etc/omni.dat
su UNIX e %NCHOME%\ini\sql.ini su Windows) è stato modificato dall’ultima
volta che Netcool/OMNIbus Administrator è stato avviato, viene eseguita la
Import Connections Wizard. Questa procedura guidata consente di scegliere gli
ObjectServer e gli agent del processo che si desidera configurare utilizzando
Netcool/OMNIbus Administrator.
Suggerimento: Dopo aver avviato Netcool/OMNIbus Administrator, è
possibile selezionare File → Import in qualsiasi momento per importare nuove
informazioni relative alle comunicazioni dal file omni.dat (sql.ini su
Windows). Per ulteriori informazioni sulla configurazione delle comunicazioni
dei componenti, consultare IBM Tivoli Netcool/OMNIbus - Guida all’installazione e
alla distribuzione.
Proprietà e opzioni della riga comandi di Netcool/OMNIbus
Administrator
Netcool/OMNIbus Administrator contiene una serie di proprietà e di opzioni della
riga comandi per la configurazione del componente.
Il file delle proprietà predefinito di Netcool/OMNIbus Administrator è
$NCHOME/omnibus/etc/nco_config.props (%NCHOME%\omnibus\etc\nco_config.props
su Windows). Il file delle proprietà predefinito viene letto ogni volta che si avvia
Netcool/OMNIbus Administrator; tuttavia, è possibile utilizzare l’opzione della
riga comandi -propsfile per specificare un file delle proprietà alternativo.
È possibile utilizzare il file delle proprietà come modello e modificarlo per scopi
diversi. Ad esempio, è possibile utilizzare file delle proprietà diversi per accedere a
ObjectServer diversi.
Le proprietà e le opzioni della riga comandi per nco_config (nco_config.vbs su
Windows) sono descritte nella seguente tabella:
46
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 12. Proprietà e opzioni della riga comandi di Netcool/OMNIbus Administrator
Proprietà
Opzione di riga
comandi
Descrizione
audit.active 0 | 1
-auditlogactive 0 | 1
Determina se la registrazione delle verifiche è abilitata.
L’impostazione predefinita è 1; la registrazione delle
verifiche è abilitata.
audit.file.max.count integer
-auditfilecount integer
Il numero massimo di file di log di verifica di
Netcool/OMNIbus Administrator.
L’impostazione predefinita è 4.
audit.file.max.size integer
-auditfilesize integer
La dimensione file massima (in byte) per i file di log di
verifica di Netcool/OMNIbus Administrator.
L’impostazione predefinita è 10000.
audit.file.name string
-auditfile string
Il percorso completo del file di log di verifica di
Netcool/OMNIbus Administrator.
L’impostazione predefinita è $NCHOME/omnibus/log/
nco_config_audit.log.
N/D
-help
Visualizza la guida relativa alle opzioni della riga
comandi ed esce.
java.security.policy string
-policyfile string
Il percorso completo del file politica di sicurezza Java.
log.console.active 0 | 1
-logtoconsole 0 | 1
Determina se inviare le informazioni di registrazione alla
shell comandi.
L’impostazione predefinita è 1; le informazioni di
registrazione vengono inviate alla shell comandi.
log.directory.name string
-logdir string
L’ubicazione in cui viene salvato il file di log di sistema di
Netcool/OMNIbus Administrator.
L’impostazione predefinita è NCHOME/omnibus/log.
log.file.max.count integer
-logfilecount integer
Il numero massimo di file di log di sistema di
Netcool/OMNIbus Administrator.
L’impostazione predefinita è 4.
log.file.max.size integer
-logfilesize integer
La dimensione file massima (in byte) per i file di log di
sistema di Netcool/OMNIbus Administrator.
L’impostazione predefinita è 10000.
log.file.name string
-logfile string
Il nome del file di log di sistema di Netcool/OMNIbus
Administrator.
L’impostazione predefinita è nco_config_system.log.
Suggerimento: Per cambiare la directory in cui viene
memorizzato il file, utilizzare la proprietà
log.directory.name o l’opzione -logdir.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
47
Tabella 12. Proprietà e opzioni della riga comandi di Netcool/OMNIbus Administrator (Continua)
Proprietà
Opzione di riga
comandi
messagelevel string
-messagelevel string
Descrizione
Specifica il livello di registrazione messaggi per la
registrazione delle verifiche e di sistema. I valori possibili
sono: FATAL, ERROR, WARN, INFO e DEBUG. Il livello
predefinito è ERROR.
I messaggi che vengono registrati ai singoli livelli
vengono elencati di seguito:
FATAL - solo FATAL.
ERROR - FATAL e ERROR.
WARN - FATAL, ERROR e WARN.
INFO - FATAL, ERROR, WARN e INFO.
DEBUG - FATAL, ERROR, WARN, INFO e DEBUG.
Nota: Il valore string deve essere indicato con lettere
maiuscole.
nco_jdbc.timeout integer
-jdbctimeout integer
Il timeout di Java Database Connectivity (JDBC), in
secondi.
L’impostazione predefinita è 600.
N/D
-propsfile string
Il percorso completo del file delle proprietà di
Netcool/OMNIbus Administrator.
L’impostazione predefinita è $NCHOME/omnibus/etc/
nco_config.props (%NCHOME%\omnibus\etc\
nco_config.props su Windows).
server string
-server string
system.create.conversion 0 | 1 -createconversion 0 | 1
Il nome dell’ObjectServer al quale si sta eseguendo la
connessione.
Configura il sistema in modo che crei automaticamente la
conversione per gli utenti che si creano.
L’impostazione predefinita è 1, ossia le conversioni
vengono create automaticamente.
system.conversion.type string
-conversiontype string
Crea una conversione tra l’ID utente e il nome utente o
nome completo di ciascun nuovo utente che si crea. I
valori possibili sono fullname e username.
L’impostazione predefinita è fullname, ossia viene creata
una conversione tra l’ID utente e il nome completo.
user.name string
-user string
Il nome utente di accesso di Netcool/OMNIbus
Administrator.
user.password string
-password string
La password di accesso di Netcool/OMNIbus
Administrator.
N/D
-version
Visualizza le informazioni sulla versione, quindi esce.
48
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Elaborazione delle proprietà e della riga comandi
Ciascuna proprietà nel file delle proprietà di Netcool/OMNIbus Administrator ha
un valore predefinito. In un file delle proprietà non modificato, le proprietà sono
elencate con i relativi valori predefiniti, impostate come commento con il simbolo
del cancelletto (#) all’inizio della riga. Una proprietà e il valore corrispondente
sono separati da un carattere di due punti (:).
È possibile modificare i valori delle proprietà utilizzando un editor di testo. Per
sovrascrivere il valore predefinito, modificare un’impostazione nel file delle
proprietà e rimuovere il segno del cancelletto (#).
Se si modifica un’impostazione sulla riga comandi, entrambi il valore predefinito e
l’impostazione nel file delle proprietà vengono sovrascritti. Per semplificare il
comando che si immette per eseguire nco_config, aggiungere quante più proprietà
possibili al file delle proprietà anziché utilizzare le opzioni della riga comandi.
Connessione a un ObjectServer
Dopo aver avviato Netcool/OMNIbus Administrator, è necessario connettersi
all’ObjectServer che si desidera configurare.
Per connettersi a un ObjectServer:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Reports nel riquadro sinistro.
Figura 2. Pulsanti dei menu Navigator e Reports
2. Fare clic su OS. Si apre la finestra ObjectServer Report. Questa finestra
visualizza tutti gli ObjectServer che sono stati selezionati l’ultima volta che è
stata eseguita la Import Connections Wizard.
3. Fare clic con il tasto destro del mouse sull’ObjectServer al quale si desidera
connettersi. Dal menu pop up, effettuare una delle seguenti azioni:
v Fare clic su Connect As se si esegue la connessione per la prima volta o se si
desidera immettere informazioni di connessione aggiornate. Viene chiesto di
specificare un nome utente e una password per l’ObjectServer.
Se si seleziona la casella di spunta Always use for this connection, il nome
utente e la password vengono salvati e vengono automaticamente riutilizzati
per le connessioni a questo ObjectServer. Se si seleziona la casella di spunta
Use as default, i valori specificati per il nome utente e la password vengono
inseriti automaticamente la volta successiva in cui viene visualizzata la
finestra di connessione. Se si selezionano entrambe le caselle di spunta, i
valori specificati per Always use for this connection avranno la precedenza.
Queste impostazioni durano l’intera sessione dell’applicazione.
v Fare clic su Connect per utilizzare le informazioni di connessione specificate
precedentemente.
4. Fare clic su OK.
Risultati
Il riquadro al centro è la finestra di configurazione dell’ObjectServer. In questa area
di lavoro è possibile visualizzare, modificare e gestire oggetti ObjectServer.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
49
Figura 3. Netcool/OMNIbus Administrator - finestra di configurazione ObjectServer
Attività correlate
“Selezione degli oggetti ObjectServer da configurare” a pagina 53
Connessione a un agent del processo
Per poter stabilire una connessione a un agent del processo, è innanzitutto
necessario assicurarsi che l’agent del processo sia stato avviato.
Per connettersi a un agent del processo:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Reports nel riquadro sinistro.
Figura 4. Pulsanti dei menu Navigator e Reports
2. Fare clic su PA. Si apre il riquadro Process Agent Report, in cui sono riportati
tutti gli agent del processo selezionati l’ultima volta che è stata eseguita la
Import Connections Wizard.
Suggerimento: Dopo aver avviato Netcool/OMNIbus Administrator, è
possibile fare clic su File → Import in qualsiasi momento per importare nuove
informazioni relative alle comunicazioni dal file omni.dat (sql.ini su
Windows). Per ulteriori informazioni sulla configurazione delle comunicazioni
dei componenti, consultare IBM Tivoli Netcool/OMNIbus - Guida all’installazione e
alla distribuzione.
50
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
3. Fare clic con il tasto destro del mouse sull’agent del processo. Dal menu pop
up, effettuare una delle seguenti azioni:
v Fare clic su Connect As se si esegue la connessione per la prima volta o se si
desidera immettere informazioni di connessione aggiornate. Si apre la
finestra Process Agent Security. Completare questa finestra nel modo
seguente:
Username
Immettere il nome utente utilizzato per accedere all’agent del
processo.
Su UNIX, qualsiasi utente che desidera accedere all’agent del
processo deve essere membro di un gruppo di utenti UNIX che viene
identificato con un gruppo di amministratori per questo scopo. Su
Windows, l’utente deve essere un utente valido con un account locale
o di dominio.
Password
Immettere la password utilizzata per accedere all’agent del processo.
Always use for this connection
Selezionare questa casella di spunta per indicare che il nome utente e
la password specificati devono essere salvati per essere riutilizzati
automaticamente nei successivi tentativi di connessione a questo
agent del processo. Queste impostazioni durano per la lunghezza
della sessione dell’applicazione.
Use as default
Selezionare questa casella di spunta se si desidera che i valori
specificati per il nome utente e la password vengano compilati
automaticamente alla successiva visualizzazione di questa finestra.
Queste impostazioni durano per la lunghezza della sessione
dell’applicazione.
Nota: Se si selezionano entrambe queste caselle di spunta,
l’impostazione Always use for this connection ha la precedenza.
v Fare clic su Connect per utilizzare le informazioni di connessione specificate
precedentemente.
4. Fare clic su OK.
Si apre la finestra Service/Process Details. Questa finestra contiene
informazioni relative ai processi ed ai servizi configurati in questo agent del
processo.
Concetti correlati
Capitolo 6, “Utilizzo del controllo processi per gestire processi e procedure
esterne”, a pagina 241
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
51
Utilizzo dei componenti di Tivoli Netcool/OMNIbus
Dalla barra dei pulsanti nel riquadro sinistro della finestra Netcool/OMNIbus
Administrator, è necessario selezionare i componenti che si desidera visualizzare o
configurare.
v Selezionare il pulsante di menu Reports, quindi fare clic su Host, OS o PA.
Selezionare un ObjectServer da configurare dalla finestra ObjectServer Report
oppure un agent del processo da configurare dalla finestra PA Report.
v Selezionare il pulsante di menu Navigator per visualizzare i componenti in base
al nome host, quindi selezionare il componente che si desidera configurare.
La seguente figura mostra i pulsanti di menu utilizzati per selezionare un
componente.
Figura 5. Pulsanti dei menu Navigator e Reports
Quando si seleziona un componente, si apre il riquadro o la finestra associata
nell’area di visualizzazione sulla destra. I pulsanti della barra degli strumenti e le
voci di menu disponibili nella finestra Netcool/OMNIbus Administrator variano a
seconda della selezione effettuata.
Connessioni SSL (Secure Sockets Layer)
Se Netcool/OMNIbus Administrator si connette a un ObjectServer oppure a un
agent del processo mediante una connessione SSL codificata, nella parte inferiore
della finestra, nell’angolo in basso a sinistra, è visualizzata un’icona che raffigura
un lucchetto .
Per informazioni sull’utilizzo di SSL con Tivoli Netcool/OMNIbus, consultare IBM
Tivoli Netcool/OMNIbus - Guida all’installazione e alla distribuzione.
Convalida dei certificati server
Quando Tivoli Netcool/OMNIbus è configurato per la comunicazione SSL,
l’ObjectServer e l’agent del processo presentano i relativi certificati server al client
Netcool/OMNIbus Administrator, su richiesta, per stabilire una connessione.
Se viene rilevata una mancata corrispondenza tra il nome comune definito nel
certificato del server e il nome server che il client Netcool/OMNIbus Administrator
utilizza per identificarsi e connettersi al server, si apre una finestra Certificate
Validation in cui è possibile scegliere se accettare o rifiutare il certificato server. Se
il certificato non è valido, non verranno stabilite connessioni.
La finestra Certificate Validation fornisce un motivo per la richiesta di convalida e
presenta un numero di opzioni. Completare la finestra nel modo seguente:
1. Selezionare una delle opzioni per accettare o rifiutare il certificato:
v Accept this certificate permanently: selezionare questa opzione per accettare
in maniera definitiva come valido questo certificato. In tal modo, non verrà
più richiesto di accettare questo certificato durante la sessione corrente e
quelle successive di Netcool/OMNIbus Administrator.
52
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Importante: Prima di accettare il certificato, fare clic su Examine Certificate
per esaminare il contenuto del certificato nella finestra Certificate Details.
Dopo un attento esame, fare clic su OK per ritornare alla finestra Certificate
Validation.
v Accept this certificate temporarily for this session: selezionare questa
opzione per accettare il certificato solo per la sessione corrente, dopo aver
esaminato il certificato utilizzando il pulsante Examine Certificate. Pertanto,
nel corso della sessione non verrà più richiesto di convalidare il certificato.
v Do not accept this certificate: selezionare questa opzione per rifiutare il
certificato e annullare la connessione tra il server e il client.
2. Fare clic su OK per continuare con il processo di connessione. Fare clic su
Cancel (oppure sul pulsante Close nella barra del titolo) per rifiutare il
certificato, indipendentemente dall’opzione selezionata al passo 1 a pagina 52.
Risultati
Se si è scelto di accettare il certificato in maniera definitiva, il nome comune e la
chiave pubblica del certificato vengono registrati nel seguente file:
userdir/.netcool/nco_config_settings/user_allowed_certs.properties
In questo percorso file, userdir rappresenta la directory home dell’utente.
Il file user_allowed_certs.properties è un file di sistema e non può essere
modificato dagli utenti. Durante i successivi tentativi di connessione, questo file
viene letto e utilizzato per identificare qualsiasi nome comune che è stato
precedentemente accettato.
È possibile cancellare il contenuto del file delle proprietà specificando il seguente
argomento della riga comandi:
mode.clear.certs ″true″
Per ulteriori informazioni sui certificati SSL, consultare IBM Tivoli Netcool/OMNIbus
- Guida all’installazione e alla distribuzione.
Selezione degli oggetti ObjectServer da configurare
Sul lato sinistro della finestra Netcool/OMNIbus Administrator è disponibile una
serie di pulsanti di menu per selezionare l’oggetto ObjectServer che si desidera
configurare.
Questi pulsanti di menu sono i seguenti:
v User
v Menu
v Automation
v Visual
v System
Risultati
La seguente figura mostra questi pulsanti:
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
53
Figura 6. Pulsanti dei menu User, Menu, Automation, Visual e System
Fare clic su ciascun pulsante di menu per ottenere una serie di oggetti correlati che
è possibile configurare. I pulsanti della barra degli strumenti e le voci di menu
disponibili nella finestra Netcool/OMNIbus Administrator variano a seconda della
selezione effettuata.
Utilizzo degli oggetti
Quando si utilizza un oggetto, sono disponibili vari modi per selezionare
un’opzione: la barra dei menu, la barra degli strumenti e un menu pop up. Ad
esempio, se si desidera creare un utente, è necessario selezionare innanzitutto il
pulsante di menu User, quindi fare clic su Users per aprire il riquadro Users.
Successivamente, è possibile effettuare una delle seguenti azioni per creare l’utente:
v Fare clic su Item → Add User.
v Dalla barra degli strumenti, fare clic su Add User.
v Dal riquadro Users, fare clic con il tasto destro del mouse, quindi fare clic su
Add User dal menu pop up.
Se si stanno modificando o eliminando oggetti, è possibile eseguire una serie
equivalente di azioni. Se si stanno modificando oggetti, è possibile fare doppio
clic sull’oggetto per aprire la finestra pertinente per la modifica.
Suggerimento: È anche possibile utilizzare comandi SQL con cui interagire e
configurare l’ObjectServer.
Impostazione delle preferenze in Netcool/OMNIbus
Administrator
È possibile impostare le preferenze in Netcool/OMNIbus Administrator ordinando
le tabelle dei risultati, impostando la visualizzazione delle colonne utilizzando le
viste e selezionando le righe da visualizzare utilizzando i filtri. È anche possibile
copiare e incollare, configurare la colorazione per la sintassi dell’editor e
selezionare un browser Web per visualizzare la guida in linea.
Ordinamento delle tabelle dei risultati
Molte finestre di Netcool/OMNIbus Administrator (tra cui le finestre Host Report,
PA Report, ObjectServer Report, i risultati SQL e le tabelle di database)
visualizzano informazioni sotto forma di tabelle dei risultati.
È possibile fare clic sul titolo di una colonna per ordinare le righe della tabella in
base ai valori di quella colonna. Fare clic su più voci per selezionare un ordine
ascendente o discendente, indicati dalle frecce su e giù che si trovano accanto al
titolo della colonna.
54
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Impostazione dell’aspetto di visualizzazione delle colonne
utilizzando le viste
È possibile modificare il modo in cui le colonne verranno visualizzate nelle tabelle
dei risultati, nelle finestre Host Report, PA Report e ObjectServer Report, oltre che
nei risultati SQL e nelle tabelle di database.
Per nascondere una colonna, fare clic con il tasto destro del mouse sull’intestazione
della colonna e fare clic su Hide Column.
Per allineare una colonna, fare clic con il tasto destro del mouse sull’intestazione
della colonna e fare clic su Align Column. Successivamente, fare clic su Left, Right
oppure su Center.
Per selezionare quali colonne visualizzare da un elenco di tutte le colonne:
1. Fare clic con il tasto destro del mouse sull’intestazione della colonna e fare clic
su Table Columns. Si apre la finestra Column Settings.
2. Selezionare le colonne che si desidera visualizzare nella finestra corrente. È
possibile fare clic su un nome di colonna per selezionarla o deselezionarla.
Viene visualizzato un segno di graduazione accanto alle colonne selezionate per
la visualizzazione. Fare clic su Close per salvare le impostazioni.
Selezione di righe da visualizzare utilizzando filtri
È possibile modificare la selezione di righe da visualizzare nei risultati delle
tabelle, che includono le finestre Host Report, PA Report e ObjectServer Report, i
risultati SQL e le tabelle di database, creando condizioni di filtro.
Per creare un filtro:
1. Fare clic con il tasto destro del mouse sull’intestazione della colonna alla quale
si desidera applicare un filtro, quindi fare clic su Filter On. Si apre la finestra
Filter.
2. Selezionare la colonna, l’operazione del filtro e il valore per la condizione.
Nella finestra Filter, è possibile:
v Fare clic su OK per creare il filtro e chiudere la finestra
v Fare clic su Apply per creare il filtro e lasciare aperta la finestra
v Fare clic su Cancel per chiudere la finestra senza creare un filtro
Per creare un filtro in base ai valori contenuti in una determinata cella di tabella:
1. Fare clic sul tasto destro del mouse e selezionare l’icona del filtro. Viene
visualizzato un menu con il nome di colonna e il valore corrispondenti e una
selezione di operatori equals o not equals.
2. Selezionare la condizione appropriata per il filtro.
viene
Quando si applica un filtro a una tabella dei risultati, l’icona del filtro
visualizzata nella barra di stato. Per ciascuna colonna alla quale si applica un filtro,
l’icona viene visualizzata anche nell’intestazione della colonna.
Per visualizzare tutte le condizioni di filtro che sono state applicate alla tabella,
fare clic con il tasto destro del mouse sull’intestazione di colonna e fare clic su
Filter Details. La finestra Filter Settings visualizza tutte le condizioni di filtro
attualmente applicate alla tabella.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
55
Per rimuovere tutti i filtri, fare clic con il tasto destro del mouse sull’intestazione di
colonna e fare clic su See All Values.
Operazioni di copia e incolla
È possibile utilizzare le funzioni Copy e Paste del menu Edit su alcuni tipi di
informazioni. Ad esempio, è possibile copiare uno strumento dell’ObjectServer
esistente, incollarlo, quindi modificarlo per creare un nuovo strumento.
È
v
v
v
v
possibile copiare e incollare i seguenti elementi:
Utenti (solo nello stesso ObjectServer)
Filtri limitazioni
Menu e voci di menu
Strumenti
v
v
v
v
v
v
v
Prompt
Trigger
Procedure
Segnali definiti dall’utente
Colori
Visuali di colonne
File ObjectServer
v Database
v Tabelle
v Processi (sotto il controllo processi)
v Servizi (sotto il controllo processi)
Configurazione dei colori per elementi della sintassi negli editor
SQL predefiniti
È possibile immettere la sintassi SQL in alcune finestre di Netcool/OMNIbus
Administrator (ad esempio, quando si creano o si modificano trigger). Per
impostazione predefinita, Netcool/OMNIbus Administrator fornisce una funzione
di colorazione per evidenziare i diversi elementi di sintassi. Lo schema di colori
per la sintassi predefinito può essere modificato.
Per modificare lo schema di colori per la sintassi predefinito:
1. Dalla finestra Netcool/OMNIbus Administrator, fare clic su Tools → Editor
Options. Si apre la finestra Highlight Details.
2. Completare questa finestra nel modo seguente:
Element
Selezionare l’elemento di sintassi per il quale si desidera visualizzare o
modificare il colore.
Color
Questo campo visualizza il colore attualmente selezionato per
l’elemento. Fare clic sul pulsante accanto a questo campo per
selezionare un nuovo colore. È possibile scegliere il colore utilizzando i
relativi valori dei campioni, HSB o RGB.
Use Default
Selezionare questa casella di spunta per utilizzare il colore predefinito
per l’elemento selezionato.
3. Salvare o annullare le modifiche nel modo seguente:
OK
56
Fare clic su questo pulsante per salvare i dettagli del colore e chiudere
la finestra.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Selezione di un browser Web per visualizzare la guida in linea
In Netcool/OMNIbus Administrator, è necessario selezionare un browser Web con
il quale visualizzare la guida in linea. La guida in linea viene distribuita
utilizzando IBM® Eclipse Help System, sul quale sono supportati numerosi
browser.
Per un elenco dei browser Web per la guida in linea supportati, consultare IBM
Tivoli Netcool/OMNIbus - Guida all’installazione e alla distribuzione.
Per selezionare il browser Web per la visualizzazione della guida in linea:
1. Da Netcool/OMNIbus Administrator, selezionare Tools → Configure Tools. Si
apre la finestra Choose Tool.
2. Selezionare Browser. Si apre la finestra External Program.
3. Completare questa finestra nel modo seguente:
Tool name
Questo campo visualizza il tipo di strumento che si sta configurando.
Executable
Immettere il percorso completo e il nome del programma eseguibile per
il tipo di strumento. In alternativa, fare clic sul pulsante a destra del
campo per eseguire la ricerca e selezionare il programma eseguibile.
Arguments
Immettere qualsiasi argomento della riga comandi da eseguire con
questo programma eseguibile.
Run time environment
Selezionare l’ambiente di runtime.
Nota: Il campo Run time environment non è disponibile se si sta configurando
un browser Web.
4. Salvare o annullare le modifiche nel modo seguente:
Fare clic su questo pulsante per salvare i dettagli del programma
esterno e chiudere la finestra.
OK
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Come uscire da Netcool/OMNIbus Administrator
Per uscire da Netcool/OMNIbus Administrator, fare clic su File → Exit.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
57
Gestione dell’autorizzazione con utenti, gruppi, ruoli e filtri limitazioni
L’autorizzazione è la verifica dei diritti di visualizzazione e di modifica delle
informazioni.
L’accesso agli oggetti ObjectServer viene controllato attraverso gruppi (raccolte di
utenti) e ruoli (raccolte di autorizzazioni di sistema e dell’oggetto) assegnati ai
gruppi. Le autorizzazioni controllano l’accesso agli oggetti e ai dati
nell’ObjectServer. Combinando una o più autorizzazioni nei ruoli, è possibile
gestire l’accesso in maniera rapida ed efficace.
Gli amministratori possono autorizzare o negare azioni sul sistema e sui singoli
oggetti assegnando autorizzazioni ai ruoli e assegnando o revocando ruoli ai
gruppi di utenti appropriati. È possibile utilizzare Netcool/OMNIbus
Administrator per assegnare o revocare autorizzazioni per gli utenti di un sistema
Tivoli Netcool/OMNIbus.
Ad esempio, la creazione di automazioni richiede la conoscenza delle operazioni di
Tivoli Netcool/OMNIbus e il modo in cui un determinato ObjectServer è
configurato. In genere, si preferisce non offrire a tutti gli utenti la possibilità di
creare o modificare automazioni. Una soluzione consiste nel creare un ruolo
denominato AutoAdmin, con autorizzazioni per creare e modificare trigger, gruppi
di trigger, file, procedure SQL, procedure esterne e segnali. Successivamente, è
possibile assegnare questo ruolo a un gruppo di amministratori che creeranno e
aggiorneranno i trigger.
Per impostare un’autorizzazione di Tivoli Netcool/OMNIbus, configurare gli
oggetti di sicurezza nell’ordine seguente:
1. Ruoli: assegnare autorizzazioni ai ruoli.
2. Gruppi: assegnare uno o più ruoli a ciascun gruppo. I ruoli assegnati
determinano le azioni che i membri del gruppo possono eseguire sugli oggetti
del database.
3. Utenti: aggiungere utenti ai gruppi. È necessario assegnare ciascun utente a uno
o più gruppi.
Risultati
È possibile creare raggruppamenti logici, ad esempio superutenti o amministratori
di sistema, raggruppamenti fisici come il NOC di Londra o di New York, oppure
qualsiasi altro raggruppamento per semplificare la configurazione della sicurezza.
Configurazione dei ruoli
I ruoli sono raccolte di autorizzazioni che è possibile assegnare a utenti e gruppi.
Tivoli Netcool/OMNIbus fornisce alcuni ruoli predefiniti e consente di creare ruoli
personalizzati per l’associazione con utenti e gruppi. I ruoli predefiniti sono
descritti nella seguente tabella.
58
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 13. Ruoli predefiniti
Nome ruolo
Descrizione
CatalogUser
Questo ruolo include autorizzazioni per visualizzare
informazioni su sistema, strumenti, sicurezza e tabelle del
database desktop.
Tale ruolo fornisce una base per le autorizzazioni di Tivoli
Netcool/OMNIbus. Tale ruolo non fornisce autorizzazioni
sufficienti per utilizzare alcuna applicazione di Tivoli
Netcool/OMNIbus.
Questo ruolo deve essere assegnato a tutti i gruppi.
AlertsUser
Questo ruolo include le seguenti autorizzazioni:
v Visualizzare, aggiornare ed eliminare voci nella tabella
alerts.status
v Visualizzare, inserire ed eliminare voci nella tabella
alerts.journal
v Visualizzare ed eliminare voci nella tabella alerts.details
Questo ruolo, in combinazione con il ruolo CatalogUser,
consente di visualizzare e modificare avvisi, creare filtri e
viste ed eseguire strumenti standard nell’elenco eventi.
AlertsProbe
Questo ruolo include autorizzazioni per inserire e
aggiornare le voci nella tabella alerts.status e per inserire le
voci nella tabella alerts.details.
Questo ruolo, in combinazione con il ruolo CatalogUser,
fornisce le autorizzazioni necessarie ad un probe per
generare gli avvisi nell’ObjectServer. Tali autorizzazioni
devono essere concesse a qualsiasi utente che esegua
un’applicazione probe.
AlertsGateway
Questo ruolo include autorizzazioni per inserire, aggiornare
ed eliminare voci nelle tabelle alerts.status, alerts.details,
alerts.journal, alerts.conversions, alerts.col_visuals,
alerts.colors, nelle tabelle tools desktop e nelle tabelle nel
database transfer. Il database transfer viene utilizzato
internamente dal gateway ObjectServer bidirezionale per
sincronizzare le informazioni sulla sicurezza tra
ObjectServer.
Questo ruolo include anche autorizzazioni per selezionare,
inserire, aggiornare ed eliminare voci nella tabella
master.servergroups, nonché autorizzazioni per generare i
seguenti segnali: gw_counterpart_down,
gw_counterpart_up, gw_resync_start e gw_resync_finish.
Questo ruolo, in combinazione con il ruolo CatalogUser,
fornisce le autorizzazioni necessarie ad un gateway per
generare gli avvisi nell’ObjectServer. Tali autorizzazioni
devono essere concesse a qualsiasi utente che esegua
un’applicazione gateway.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
59
Tabella 13. Ruoli predefiniti (Continua)
Nome ruolo
Descrizione
DatabaseAdmin
Questo ruolo include autorizzazioni per creare database e
file e per creare tabelle nei database alerts, tools e
service. Include inoltre le autorizzazioni per modificare o
eliminare le tabelle alerts.status, alerts.details e
alerts.journal e per creare ed eliminare indici in tali tabelle.
Questo ruolo, in combinazione con il ruolo CatalogUser,
fornisce le autorizzazioni necessarie per creare strutture di
dati relazionali nell’ObjectServer.
AutoAdmin
Questo ruolo include autorizzazioni per creare gruppi
trigger, file, procedure SQL, procedure esterne e segnali
utente. Tale ruolo include inoltre autorizzazioni per creare,
modificare ed eliminare trigger nei gruppi trigger
predefiniti e per modificare o eliminare gruppi trigger
predefiniti.
Questo ruolo, in combinazione con il ruolo CatalogUser,
fornisce le autorizzazioni per creare automazioni
nell’ObjectServer.
ToolsAdmin
Questo ruolo include autorizzazioni per eliminare, inserire
e aggiornare tutte le tabelle di strumenti.
Questo ruolo, in combinazione con il ruolo CatalogUser,
fornisce le autorizzazioni per creare e modificare strumenti
che possono essere eseguiti dal desktop e da
Netcool/OMNIbus Administrator.
DesktopAdmin
Questo ruolo include autorizzazioni per aggiornare tutti i
cataloghi desktop per inserire, aggiornare ed eliminare
colori, elementi visivi, menu, classi, risoluzioni e
conversioni.
Tale ruolo, in combinazione con il ruolo CatalogUser,
fornisce le autorizzazioni per personalizzare il desktop.
60
SecurityAdmin
Questo ruolo, in combinazione con il ruolo CatalogUser,
include le autorizzazioni per modificare utenti, gruppi e
ruoli tramite Netcool/OMNIbus Administrator o
l’interfaccia interattiva SQL. Tale ruolo include inoltre
autorizzazioni per impostare proprietà ed eliminare
connessioni utente.
ISQL
Questo ruolo, in combinazione con il ruolo CatalogUser,
include le autorizzazioni per visualizzare i dati
dell’ObjectServer tramite l’interfaccia interattiva SQL.
ISQLWrite
Questo ruolo, in combinazione con il ruolo CatalogUser,
include le autorizzazioni per visualizzare e modificare i dati
dell’ObjectServer tramite l’interfaccia interattiva SQL.
SuperUser
Questo ruolo dispone di tutte le autorizzazioni disponibili.
Non è possibile modificare il ruolo SuperUser.
Public
Questo ruolo è assegnato a tutti gli utenti. Per impostazione
predefinita, al ruolo Public non è assegnata alcuna
autorizzazione. È possibile modificare ma non eliminare il
ruolo Public.
ChannelAdmin
Questo ruolo include autorizzazioni per configurare canali
per la notifica eventi accelerati.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 13. Ruoli predefiniti (Continua)
Nome ruolo
Descrizione
ChannelUser
Questo ruolo include autorizzazioni per ricevere e agire
sulle notifiche per eventi accelerati trasmessi sui canali.
I ruoli determinano i tipi di attività che gli utenti membri del gruppo possono
eseguire. Ad esempio, se si assegna a un gruppo il ruolo AlertsUser, agli utenti
appartenenti a quel gruppo vengono concesse autorizzazioni per:
v Visualizzare, aggiornare ed eliminare voci nella tabella alerts.status
v Visualizzare, inserire ed eliminare voci nella tabella alerts.journal
v Visualizzare ed eliminare voci nella tabella alerts.details
Concetti correlati
“Configurazione dei gruppi” a pagina 63
“Configurazione degli utenti” a pagina 66
Creazione e modifica di ruoli
Utilizzare i ruoli per assegnare autorizzazioni a utenti che sono membri di un
determinato gruppo.
Per creare o modificare un ruolo:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
User.
2. Fare clic su Roles. Si apre il riquadro Roles.
3. Per aggiungere un ruolo, fare clic su Add Role nella barra degli strumenti. Si
apre la finestra Role Details.
4. Per modificare un ruolo, selezionare il ruolo da modificare, quindi fare clic su
Edit Role nella barra degli strumenti. Si apre la finestra Role Details.
5. Definire un nuovo ruolo nel modo seguente:
Role Name
Immettere un nome univoco per il ruolo. Se si sta modificando un
ruolo, non è possibile modificarne il nome.
Suggerimento: Quando si creano oggetti dell’ObjectServer, i relativi
nomi devono iniziare con una lettera maiuscola o minuscola, seguita da
lettere maiuscole o minuscole, numeri o caratteri di sottolineatura (_),
per una lunghezza massima di 40 caratteri. Per i nomi di utenti, gruppi e
ruoli, è possibile specificare qualsiasi stringa di testo che può includere spazi e
la cui lunghezza non deve superare i 64 caratteri. I nomi degli oggetti
dell’ObjectServer rispettano la distinzione maiuscolo/minuscolo.
Role ID
Specificare un identificativo numerico univoco per questo ruolo. Se si
sta modificando un ruolo, non è possibile modificare l’ID ruolo.
6. Dalla scheda Details, immettere una descrizione per il ruolo oppure aggiornare
la descrizione.
7. Dalla scheda Permissions, assegnare o revocare le assegnazioni al ruolo nel
modo seguente:
Add permission
Fare clic su questo pulsante per concedere le autorizzazioni a questo
ruolo. Si apre la finestra Permission Objects. Completare questa finestra
nel modo seguente:
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
61
Object Type
Selezionare il tipo di oggetto al quale si desidera concedere o
revocare le autorizzazioni.
Available Objects
Il contenuto di questo elenco dipende dal tipo di oggetto
selezionato. L’elenco Available Objects visualizza gli oggetti
per i quali non sono state concesse le autorizzazioni. Per
concedere le autorizzazioni ad uno o più oggetti, utilizzare i
pulsanti freccia per spostare gli oggetti nell’elenco Selected
Objects.
Per spostare tutti gli oggetti nell’elenco Selected Objects, fare
clic su >>. Per spostare un singolo oggetto o più oggetti
nell’elenco Selected Objects, selezionare ciascun oggetto e
quindi fare clic su >. È possibile utilizzare il tasto MAIUSC per
selezioni consecutive oppure il tasto CTRL per selezioni non
consecutive.
Selected Objects
Questo elenco visualizza gli oggetti per i quali sono state
concesse le autorizzazioni. Per revocare le autorizzazioni per
uno o più oggetti, utilizzare i pulsanti freccia per spostare gli
oggetti nell’elenco Available Objects.
Per spostare tutti gli oggetti nell’elenco Available Objects, fare
clic su <<. Per spostare un singolo oggetto o più oggetti
nell’elenco Available Objects, selezionare ciascun oggetto e
quindi fare clic su <. È possibile utilizzare il tasto MAIUSC per
selezioni consecutive oppure il tasto CTRL per selezioni non
consecutive.
Suggerimento: È possibile aggiungere più autorizzazioni
dell’oggetto selezionando ciascun tipo di oggetto richiesto
singolarmente dall’elenco Object Type e quindi aggiungere
l’oggetto all’elenco Selected Objects.
OK
Fare clic su questo pulsante per salvare le autorizzazioni
configurate per il ruolo e chiudere la finestra Permission
Objects.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza
salvare le modifiche.
Quando si ritorna alla scheda Permissions nella finestra Role Details, la
struttura di autorizzazioni viene aggiornata con le modifiche. Il nodo
parent mostra l’oggetto principale e i nodi child nidificati mostrano
oggetti secondari associati. È possibile espandere questi oggetti
secondari per visualizzare le autorizzazioni SQL associate; ad esempio,
ALTER, DELETE e DROP. Selezionare la casella di spunta associata
all’autorizzazione SQL per assegnare tale autorizzazione al ruolo.
Deselezionare la casella di spunta per revocare l’autorizzazione.
Delete permission
Dalla struttura di autorizzazioni, selezionare un nodo parent o child per
il quale si desidera revocare le autorizzazioni e poi fare clic su questo
pulsante. Il nodo viene eliminato dalla struttura.
8. Salvare o annullare le modifiche nel modo seguente:
62
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Fare clic su questo pulsante per salvare i dettagli della regola e
chiudere la finestra. Le nuove regole vengono aggiunte al pannello
Roles.
OK
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Eliminazione di ruoli
Per eliminare un ruolo:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
User.
2. Fare clic su Roles. Si apre il riquadro Roles.
3. Selezionare il ruolo che si desidera eliminare e fare clic su Delete nella barra
degli strumenti. Il ruolo viene eliminato. Se questo ruolo è stato assegnato a un
gruppo, il ruolo viene rimosso dal gruppo.
Configurazione dei gruppi
Utilizzare i gruppi per organizzare gli utenti di Tivoli Netcool/OMNIbus in unità
con obiettivi funzionali comuni. Tutti i membri di un gruppo dispongono delle
autorizzazioni che sono state assegnate ai ruoli del gruppo.
Tivoli Netcool/OMNIbus fornisce alcuni gruppi predefiniti e consente di creare
gruppi personalizzati. I gruppi predefiniti sono descritti nella seguente tabella.
Tabella 14. Gruppi predefiniti
Nome gruppo
Descrizione
Probe
A questo gruppo vengono assegnati i ruoli CatalogUser,
AlertsUser e AlertsProbe.
Gateway
A questo gruppo vengono assegnati i ruoli CatalogUser,
AlertsUser e AlertsGateway.
ISQL
A questo gruppo è assegnato il ruolo ISQL.
ISQLWrite
A questo gruppo è assegnato il ruolo ISQLWrite.
Public
A questo gruppo è assegnato il ruolo Public. Tutti gli utenti
sono membri di questo gruppo.
Normal
A questo gruppo sono assegnati i ruoli CatalogUser,
AlertsUser e ChannelUser. Questo gruppo non può essere
eliminato o rinominato.
Administrator
A questo gruppo sono assegnati i ruoli CatalogUser,
AlertsUser, ToolsAdmin, DesktopAdmin, ChannelUser e
ChannelAdmin. Questo gruppo non può essere eliminato o
rinominato.
System
A questo gruppo sono assegnati i ruoli CatalogUser,
AlertsUser, ToolsAdmin, DesktopAdmin, AlertsProbe,
AlertsGateway, DatabaseAdmin, AutoAdmin,
SecurityAdmin, ISQL, ISQLWrite, SuperUser, ChannelUser e
ChannelAdmin. Questo gruppo non può essere eliminato o
rinominato.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
63
Concetti correlati
“Configurazione dei ruoli” a pagina 58
“Configurazione degli utenti” a pagina 66
Creazione e modifica di gruppi
Per creare o modificare un gruppo:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
User.
2. Fare clic su Groups. Si apre il riquadro Groups.
3. Per aggiungere un gruppo, fare clic su Add Group nella barra degli strumenti.
Si apre la finestra Group Details.
4. Per modificare un gruppo, selezionare il gruppo da modificare, quindi fare clic
su Edit Group nella barra degli strumenti. Si apre la finestra Group Details.
5. Definire il gruppo nel modo seguente:
Group Name
Immettere un nome univoco per il gruppo. Se si sta modificando un
gruppo, non è possibile modificarne il nome.
Suggerimento: Quando si creano oggetti dell’ObjectServer, i relativi
nomi devono iniziare con una lettera maiuscola o minuscola, seguita da
lettere maiuscole o minuscole, numeri o caratteri di sottolineatura (_),
per una lunghezza massima di 40 caratteri. Per i nomi di utenti, gruppi e
ruoli, è possibile specificare qualsiasi stringa di testo che può includere spazi e
la cui lunghezza non deve superare i 64 caratteri. I nomi degli oggetti
dell’ObjectServer rispettano la distinzione maiuscolo/minuscolo.
Group ID
Specificare un identificativo numerico univoco per il gruppo. Se si sta
modificando un gruppo, non è possibile modificare l’ID gruppo.
Description
Immettere una descrizione valida per il gruppo o aggiornare la
descrizione.
6. Dalla scheda Roles, specificare i ruoli che si desidera assegnare al gruppo.
Quando si assegna un ruolo a un gruppo di utenti, qualsiasi utente aggiunto a
quel gruppo acquisisce le autorizzazioni di sicurezza concesse al ruolo.
Completare la scheda nel modo seguente:
Available Roles
Questo elenco visualizza le regole disponibili che è possibile assegnare
al gruppo. Per assegnare una o più di queste regole, utilizzare i
pulsanti freccia per spostare le regole nell’elenco Applied Roles.
Per spostare tutte le regole nell’elenco Applied Roles, fare clic su >>.
Per spostare una singola regola o più regole nell’elenco Applied Roles,
selezionare ciascuna regola e quindi fare clic su >. È possibile utilizzare
il tasto MAIUSC per selezioni consecutive oppure il tasto CTRL per
selezioni non consecutive.
Applied Roles
Questo elenco visualizza le regole già assegnate al gruppo. Per
annullare l’assegnazione di regole, utilizzare i pulsanti freccia per
spostare le regole nell’elenco Available Roles.
Per spostare tutte le regole nell’elenco Available Roles, fare clic su <<.
Per spostare una singola regola o più regole nell’elenco Available
64
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Roles, selezionare ciascuna regola e quindi fare clic su <. È possibile
utilizzare il tasto MAIUSC per selezioni consecutive oppure il tasto
CTRL per selezioni non consecutive.
Add new role
Fare clic su questo pulsante se si desidera creare una nuova regola che
può quindi essere assegnata a questo gruppo. Si apre la finestra Role
Details. Completare questa finestra e salvare le modifiche.
Quando si ritorna alla scheda Roles, la nuova regola verrà aggiunta
all’elenco Available Roles. È possibile quindi aggiungere questa regola
al gruppo.
7. Dalla scheda Restriction Filters, specificare i filtri limitazioni che si desidera
assegnare al gruppo. È possibile utilizzare filtri limitazioni per impedire al
gruppo di utenti di visualizzare o modificare determinate righe di tabelle
ObjectServer. Completare la scheda nel modo seguente:
All Restriction Filters
Questo elenco visualizza i filtri limitazioni disponibili che sono stati
configurati. Per assegnare un filtro limitazioni al gruppo, selezionare la
riga del filtro limitazioni e quindi fare clic su Add Restriction Filter. Il
filtro limitazioni selezionato viene trasferito all’elenco Assigned
Restriction Filters.
Se non è stato configurato alcun filtro limitazioni in precedenza oppure
se si desidera creare un nuovo filtro limitazioni e assegnarlo al gruppo,
fare clic su New Restriction Filter. Si apre la finestra Restriction Filter
Details. Completare questa finestra e salvare le modifiche.
Quando si ritorna alla scheda Restriction Filters, il nuovo filtro
limitazioni verrà aggiunto all’elenco All Restriction Filters. È possibile
quindi aggiungere questo filtro limitazioni al gruppo.
Assigned Restriction Filters
Questo elenco visualizza i filtri limitazioni assegnati al gruppo. Per
annullare l’assegnazione di un filtro limitazioni, la riga del filtro
limitazioni e quindi fare clic su Remove Restriction Filter. Il filtro
limitazioni selezionato viene trasferito all’elenco All Restriction Filters.
8. Dalla scheda Users, specificare gli utenti che si desidera aggiungere come
membri del gruppo. Completare la scheda nel modo seguente:
Non members
Questo elenco visualizza gli utenti disponibili che è possibile assegnare
come membri del gruppo. Per assegnare uno o più di questi utenti,
utilizzare i pulsanti freccia per spostare gli utenti nell’elenco Members.
Per spostare tutti gli utenti nell’elenco Members, fare clic su >>. Per
spostare un singolo utente o più utenti nell’elenco Members,
selezionare ciascun utente e quindi fare clic su >. È possibile utilizzare
il tasto MAIUSC per selezioni consecutive oppure il tasto CTRL per
selezioni non consecutive.
Members
Questo elenco visualizza gli utenti già assegnati al gruppo. Per
annullare l’assegnazione di utenti, utilizzare i pulsanti freccia per
spostare gli utenti nell’elenco Non members.
Per spostare tutti gli utenti nell’elenco Non members, fare clic su <<.
Per spostare un singolo utente o più utenti nell’elenco Non members,
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
65
selezionare ciascun utente e quindi fare clic su <. È possibile utilizzare
il tasto MAIUSC per selezioni consecutive oppure il tasto CTRL per
selezioni non consecutive.
Add new user
Fare clic su questo pulsante se si desidera creare un nuovo utente che
può quindi essere assegnato a questo gruppo. Si apre la finestra User
Details. Completare questa finestra e salvare le modifiche.
Quando si ritorna alla scheda Users, il nuovo utente verrà aggiunto
all’elenco Non members. È possibile quindi aggiungere questo utente al
gruppo.
9. Salvare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per salvare i dettagli del gruppo e chiudere
la finestra. I nuovi gruppi vengono aggiunti al pannello Groups.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Attività correlate
“Creazione e modifica di ruoli” a pagina 61
“Creazione e modifica di filtri limitazioni” a pagina 71
“Creazione e modifica di utenti” a pagina 67
Eliminazione di gruppi
Non è possibile eliminare i gruppi Normal, Administrator e System.
Per eliminare un gruppo:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
User.
2. Fare clic su Groups. Si apre il riquadro Groups.
3. Selezionare il gruppo che si desidera eliminare e fare clic su Delete nella barra
degli strumenti. Il gruppo viene eliminato.
Configurazione degli utenti
È possibile creare e modificare gli utenti di Tivoli Netcool/OMNIbus e organizzare
questi utenti in gruppi. È possibile assegnare ruoli ai gruppi di utenti per
controllare l’accesso agli oggetti ObjectServer.
Tivoli Netcool/OMNIbus fornisce una serie di account utente predefiniti. Gli utenti
predefiniti sono descritti nella seguente tabella.
Tabella 15. Utenti predefiniti
66
Nome utente
Descrizione
root
Questo utente viene creato con una stringa vuota come
password per impostazione predefinita. È possibile
reimpostare la password utilizzando Netcool/OMNIbus
Administrator o il comando SQL ALTER USER
dell’ObjectServer.
nobody
Questo utente è disabilitato e non può essere utilizzato per
accedere all’ObjectServer. La proprietà di ciascun avviso
nella tabella alerts.status viene assegnata ad un utente
quando la riga viene inserita. Per impostazione predefinita,
i probe assegnano delle righe all’utente nobody.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Concetti correlati
“Configurazione dei gruppi” a pagina 63
“Configurazione dei ruoli” a pagina 58
Creazione e modifica di utenti
Quando si configurano utenti, è necessario assegnarli a uno o più gruppi di cui
acquisiranno i ruoli. Ciò determina le autorizzazioni degli utenti.
Per creare o modificare un utente:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
User.
2. Fare clic su Users. Si apre il riquadro Users.
3. Per aggiungere un utente, fare clic su Add User nella barra degli strumenti. Si
apre la finestra User Details.
4. Per modificare un utente, selezionare l’utente da modificare, quindi fare clic su
Edit User nella barra degli strumenti. Si apre la finestra User Details.
5. Definire l’utente nel modo seguente:
Username
Immettere un nome univoco per l’utente. Se l’utente deve essere
autenticato esternamente, ad esempio, in un repository LDAP
(Lightweight Directory Access Protocol) oppure mediante PAM
(Pluggable Authentication Modules), il nome immesso in questo campo
deve essere identico al nome archiviato nel repository di autenticazione
esterno. Se si sta modificando un utente, è impossibile modificarne il
nome.
Suggerimento: Quando si creano oggetti dell’ObjectServer, i relativi
nomi devono iniziare con una lettera maiuscola o minuscola, seguita da
lettere maiuscole o minuscole, numeri o caratteri di sottolineatura (_),
per una lunghezza massima di 40 caratteri. Per i nomi di utenti, gruppi e
ruoli, è possibile specificare qualsiasi stringa di testo che può includere spazi e
la cui lunghezza non deve superare i 64 caratteri. I nomi degli oggetti
dell’ObjectServer rispettano la distinzione maiuscolo/minuscolo.
User ID
Specificare un identificativo numerico univoco per l’utente. Deve essere
impostato in modo da corrispondere all’UID UNIX, dove possibile. Se
si sta modificando un utente, è impossibile modificare l’ID utente.
L’identificativo per l’utente root è 0. L’identificativo per l’utente nobody
è 65534. Gli identificativi per gli altri utenti possono essere impostati su
qualsiasi valore compreso tra 1 e 2147483647.
Full Name
Immettere il nome completo dell’utente.
Create Conversion
Selezionare questa casella di spunta se si desidera creare una
conversione per l’utente. In tal modo, viene visualizzato il nome utente
o il nome completo dell’utente nell’elenco eventi di Tivoli
Netcool/OMNIbus. Il nome mostrato viene determinato dal valore
della proprietà system.conversion.type nel file delle proprietà di
Netcool/OMNIbus Administrator NCHOME/omnibus/etc/
nco_config.props. Questa proprietà crea una conversione tra l’ID
utente e il nome utente o il nome completo di ciascun utente appena
creato.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
67
6. Dalla scheda Groups, specificare i gruppi a cui l’utente dovrebbe appartenere.
Completare la scheda nel modo seguente:
Unassigned Groups
Questo elenco visualizza i gruppi disponibili ai quali è possibile
assegnare l’utente. Per assegnare un utente a uno o più di questi
gruppi, utilizzare i pulsanti freccia per spostare i gruppi nell’elenco
Assigned Groups.
Per spostare tutti i gruppi nell’elenco Assigned Groups, fare clic su >>.
Per spostare un singolo gruppo o più gruppi nell’elenco Assigned
Groups, selezionare ciascun gruppo e quindi fare clic su >. È possibile
utilizzare il tasto MAIUSC per selezioni consecutive oppure il tasto
CTRL per selezioni non consecutive.
Nota: Se non si aggiunge l’utente ad un gruppo, l’utente non avrà
alcuna autorizzazione.
Assigned Groups
Questo elenco visualizza i gruppi ai quali è assegnato l’utente. Per
annullare l’assegnazione di gruppi, utilizzare i pulsanti freccia per
spostare i gruppi nell’elenco Unassigned Groups.
Per spostare tutti i gruppi nell’elenco Unassigned Groups, fare clic su
<<. Per spostare un singolo gruppo o più gruppi nell’elenco
Unassigned Groups, selezionare ciascun gruppo e quindi fare clic su <.
È possibile utilizzare il tasto MAIUSC per selezioni consecutive oppure
il tasto CTRL per selezioni non consecutive.
Add new group
Fare clic su questo pulsante se si desidera creare un nuovo gruppo al
quale è possibile assegnare l’utente. Si apre la finestra Group Details.
Completare questa finestra e salvare le modifiche.
Quando si ritorna alla scheda Groups nella finestra User Details, il
nuovo gruppo verrà aggiunto all’elenco Unassigned Groups. È
possibile quindi assegnare l’utente a questo gruppo.
7. Dalla scheda Restriction Filters, specificare eventuali filtri limitazioni che si
desidera applicare all’utente. È possibile utilizzare filtri limitazioni per impedire
all’utente di visualizzare o modificare determinate righe delle tabelle
ObjectServer. Completare la scheda nel modo seguente:
All Restriction Filters
Questo elenco visualizza i filtri limitazioni disponibili che sono stati
configurati. Per assegnare un filtro limitazioni all’utente, selezionare la
riga del filtro limitazioni e quindi fare clic su Add Restriction Filter. Il
filtro limitazioni selezionato viene trasferito all’elenco Assigned
Restriction Filters.
Se non è stato configurato alcun filtro limitazioni in precedenza oppure
se si desidera creare un nuovo filtro limitazioni e assegnarlo all’utente,
fare clic su New Restriction Filter. Si apre la finestra Restriction Filter
Details. Completare questa finestra e salvare le modifiche.
Quando si ritorna alla scheda Restriction Filters, il nuovo filtro
limitazioni verrà aggiunto all’elenco All Restriction Filters. È possibile
quindi aggiungere questo filtro limitazioni all’utente.
Assigned Restriction Filters
Questo elenco visualizza i filtri limitazioni assegnati all’utente. Per
annullare l’assegnazione di un filtro limitazioni, la riga del filtro
68
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
limitazioni e quindi fare clic su Remove Restriction Filter. Il filtro
limitazioni selezionato viene trasferito all’elenco All Restriction Filters.
8. Dalla scheda Settings, specificare i dettagli di autenticazione per l’utente e
rendere attivo l’utente sul sistema.
Password
Immettere una password facoltativa per l’utente. Al posto dei caratteri
immessi per la password vengono visualizzati gli asterischi (*).
Se l’utente deve essere autenticato esternamente, la password viene
archiviata in un repository esterno e quindi lasciare questo campo
vuoto.
Verify Se nel campo Password è stata immessa una password, immetterla di
nuovo in questo campo.
Change
Fare clic su questo pulsante per reimpostare la password dell’utente.
Deve quindi essere immessa di nuovo nei campi Password e Verify.
Questo pulsante è visibile solo quando si modifica un utente.
External Authentication
Selezionare questa casella di spunta per autenticare esternamente
l’utente. Deselezionare questa casella di spunta per archiviare il nome
utente e la password associata nell’ObjectServer e per eseguire
l’autenticazione dell’ObjectServer.
User Type
Questo campo di sola lettura indica il tipo di utente. Viene impostato
automaticamente in base ai gruppi ai quali appartiene l’utente.
User Enabled
Selezionare questa casella di spunta per attivare l’account utente e
consentire l’accesso a Tivoli Netcool/OMNIbus. I nuovi account utente
vengono attivati per impostazione predefinita.
Deselezionare questa casella di spunta per creare l’account utente senza
attivarlo. È possibile operare questa scelta se si desidera negare
l’accesso all’utente finché non gli vengono assegnate tutte le
autorizzazioni appropriate.
9. Salvare o annullare le modifiche nel modo seguente:
Fare clic su questo pulsante per salvare i dettagli dell’utente e chiudere
la finestra. I nuovi utenti vengono aggiunti al pannello Users.
OK
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Attività correlate
“Creazione e modifica di gruppi” a pagina 64
“Creazione e modifica di filtri limitazioni” a pagina 71
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
69
Eliminazione di utenti
Per eliminare un utente:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
User.
2. Fare clic su Users. Si apre il riquadro Users.
3. Selezionare l’utente che si desidera eliminare e fare clic su Delete nella barra
degli strumenti. L’utente viene eliminato.
Visualizzazione delle connessioni utente all’ObjectServer
È possibile visualizzare i dettagli relativi alle connessioni di qualsiasi utente
connesso all’ObjectServer.
Per visualizzare le connessioni utente:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
User.
2. Fare clic su Users. Si apre il riquadro Users, in cui viene riportata una riga per
ciascun utente configurato sul sistema.
viene mostrata a sinistra del nome utente. Il
Un’icona che indica lo stato
colore dell’icona illustra lo stato di connessione dell’utente nel modo seguente:
v Il colore verde indica che l’utente è connesso.
v Il colore blu indica che l’utente è abilitato, ma non connesso.
v Il colore grigio indica che l’utente non è abilitato.
Dal pannello Users è possibile visualizzare i dettagli di connessione per
qualsiasi utente selezionato attualmente collegato all’ObjectServer. Ad esempio,
se si desidera visualizzare quanti utenti sono attualmente connessi come root e
i relativi dettagli di connessione, è possibile selezionare la riga per l’utente
root. Fare clic con il pulsante destro del mouse sulla riga selezionata e poi fare
clic su See connections dal menu pop-up. Si apre il pannello ObjectServer
Connections. Un filtro rapido dinamico viene applicato automaticamente alla
colonna Login Name così che vengano visualizzate solo le applicazioni a cui è
viene visualizzata
connesso l’utente selezionato. L’icona Filtro rapido
nell’intestazione di colonna Login Name per indicare che è stato applicato un
filtro a quel nome. È possibile rimuovere questo filtro per mostrare tutte le
connessioni per tutti gli utenti facendo clic su Connessioni sotto il pulsante di
menu System.
Attività correlate
“Monitoraggio delle connessioni all’ObjectServer” a pagina 120
Configurazione dei filtri limitazioni
È possibile utilizzare i filtri limitazioni per impedire agli utenti di visualizzare o
modificare determinate righe delle tabelle ObjectServer.
È possibile assegnare filtri limitazioni ai singoli utenti oppure a una raccolta di
utenti in un gruppo. Dopo aver applicato un filtro limitazioni a uno o più utenti, il
filtro limitazioni controlla i dati che gli utenti possono visualizzare e modificare
nelle applicazioni client Tivoli Netcool/OMNIbus, nonché i dati che gli utenti
possono modificare nelle istruzioni INSERT, UPDATE e DELETE. È possibile
assegnare a un utente o a un gruppo un solo filtro limitazioni per singola tabella
ObjectServer.
70
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Ad esempio, è possibile creare un filtro limitazioni per la tabella alerts.status che
impedisca agli operatori che si trovano a Londra di visualizzare gli avvisi originati
dal centro operativo di New York.
Creazione e modifica di filtri limitazioni
Per creare o modificare un filtro limitazioni:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
User.
2. Fare clic su Restriction Filters. Si apre il riquadro Restriction Filters.
3. Per aggiungere un filtro limitazioni, fare clic su Add Restriction Filter nella
barra degli strumenti. Si apre la finestra Restriction Filter Details.
4. Per modificare un filtro limitazioni, selezionare il filtro limitazioni da
modificare, quindi fare clic su Edit Restriction Filter nella barra degli
strumenti. Si apre la finestra Restriction Filter Details.
5. Completare questa finestra nel modo seguente:
Name Immettere un nome univoco per il filtro limitazioni.
Suggerimento: Quando si creano oggetti dell’ObjectServer, i relativi
nomi devono iniziare con una lettera maiuscola o minuscola, seguita da
lettere maiuscole o minuscole, numeri o caratteri di sottolineatura (_),
per una lunghezza massima di 40 caratteri. Per i nomi di utenti, gruppi e
ruoli, è possibile specificare qualsiasi stringa di testo che può includere spazi e
la cui lunghezza non deve superare i 64 caratteri. I nomi degli oggetti
dell’ObjectServer rispettano la distinzione maiuscolo/minuscolo.
Database
Selezionare il database per il quale si sta creando il filtro limitazioni.
Table
Selezionare la tabella per la quale si sta creando il filtro limitazioni.
Condition
Immettere la condizione SQL (istruzione WHERE) per il filtro
limitazione. Ad esempio: Tally > 100 AND Severity >=4
Questa condizione di esempio impedisce a un utente o a un gruppo, al
quale viene applicato il filtro limitazioni, di visualizzare gli avvisi
nell’elenco eventi se si verificano più di 100 volte e hanno una severità
superiore o uguale a 4.
È possibile utilizzare i pulsanti dell’helper SQL per consentire la
creazione della condizione di filtro, come descritto nella seguente
tabella.
Tabella 16. Pulsanti per la creazione di condizioni di filtro
Pulsante
Descrizione
Fare clic su questo pulsante per selezionare un nome della
colonna di tabella da aggiungere al comando. Il nome
colonna viene sostituito per il corrispondente valore di riga
dell’elenco eventi durante l’esecuzione dello strumento.
Fare clic su questo pulsante per selezionare da un elenco di
conversioni disponibili.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
71
Tabella 16. Pulsanti per la creazione di condizioni di filtro (Continua)
Pulsante
Descrizione
Fare clic su questo pulsante per visualizzare un elenco di
parole chiave che completano l’SQL immesso.
Suggerimento: In alternativa, è possibile immettere uno o
più caratteri e quindi premere Ctrl+F1 per ottenere una
finestra di dialogo con un elenco di parole chiave che
potrebbero eventualmente corrispondere alla voce
desiderata. Selezionare la parola chiave richiesta e fare clic
su OK per completare la voce. Se una sola parola chiave
corrisponde ai caratteri immessi, la parola chiave viene
completata automaticamente. Se si preme Ctrl+F1 dopo
l’immissione di una parola chiave correlata al database, la
finestra di dialogo fornisce un elenco di possibili database
ObjectServer da cui è possibile effettuare una selezione. Se
si preme Ctrl+F1 dopo l’immissione di un nome database
seguito da un punto (ad esempio: alerts.), è possibile
premere di nuovo Ctrl+F1 per visualizzare e effettuare una
selezione da un elenco di tabelle del database.
Fare clic su questo pulsante per controllare la validità della
sintassi SQL immessa.
OK
Fare clic su questo pulsante per salvare il filtro limitazioni e chiudere la
finestra. I nuovi filtri limitazioni vengono aggiunti al pannello
Restriction Filters.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Attività correlate
“Creazione e modifica di conversioni” a pagina 107
Eliminazione di filtri limitazioni
Non è possibile eliminare filtri limitazioni che al momento risultano assegnati a un
utente oppure a un gruppo.
Per eliminare un filtro limitazioni:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
User.
2. Fare clic su Restriction Filters. Si apre il riquadro Restriction Filters.
3. Selezionare il filtro limitazioni che si desidera eliminare e fare clic su Delete
nella barra degli strumenti. Il filtro limitazioni viene eliminato.
Configurazione di menu, strumenti e prompt
È possibile configurare menu, strumenti e prompt per il desktop di Tivoli
Netcool/OMNIbus (elenco eventi e Conductor).
Ciascun menu consiste di un nome di menu e di un elenco di voci di menu. Le
voci di menu sono strumenti, separatori e menu secondari. I menu secondari
vengono utilizzati all’interno dei menu per raggruppare insieme due o più voci di
menu.
Gli strumenti consentono di controllare le funzioni di gestione degli avvisi in Tivoli
Netcool/OMNIbus. A ciascun strumento è associata un’istruzione SQL (effetto
72
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
interno), un eseguibile (effetto esterno) o entrambi. È possibile associare strumenti a
una o più classi di avviso e raggruppare strumenti nei menu degli strumenti.
Uno strumento può includere una finestra di prompt o un menu pop up per
consentire all’utente di immettere informazioni.
Personalizzazione dei menu
Utilizzare Netcool/OMNIbus Administrator per personalizzare i menu del desktop
di Tivoli Netcool/OMNIbus per l’elenco eventi e Conductor.
È possibile personalizzare un menu in uno dei seguenti modi:
v Aggiungere strumenti, menu secondari e separatori a un menu
v Modificare le voci di menu
v Modificare l’ordine delle voci di menu
v Rimuovere strumenti, menu secondari o separatori da un menu
Dopo aver personalizzato un menu, è possibile visualizzarne in anteprima la
struttura per vedere come verrà visualizzato nell’elenco eventi o in Conductor.
La seguente tabella mostra i menu che è possibile personalizzare.
Tabella 17. Menu dell’elenco eventi personalizzabili
Nome del menu in Netcool/OMNIbus
Administrator - finestra Menus
Nome del menu nel desktop di Tivoli
Netcool/OMNIbus
AlertsMenu
Il menu Alerts e il menu pop-up nell’elenco
eventi, quando viene selezionato un avviso.
MainEventListMenu
Il menu Tools per la finestra menu della
casella di monitoraggio Event List.
SubEventListMenu
Il menu Tools per qualsiasi finestra
dell’elenco eventi.
ConductorMenu
Il menu Tools in Conductor
Aggiunta di strumenti, di menu secondari e di separatori a un
menu
È possibile aggiungere a un menu del desktop strumenti, menu secondari e
separatori come voci di menu.
Per aggiungere a un menu uno strumento, un menu secondario o un separatore:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Menu.
2. Fare clic su Menus. Si apre il riquadro Menus.
Suggerimento: È possibile fare doppio clic sul menu per visualizzare strumenti
e voci di menu esistenti. È anche possibile fare clic sul simbolo a forma di
cerchio (su UNIX) o sul simbolo più (+) (su Windows) che si trova alla sinistra
di un menu.
3. Dalla struttura ad albero, selezionare il menu al quale si desidera aggiungere
una voce di menu, quindi fare clic su Add Item nella barra degli strumenti. Si
apre la finestra Menu Item Details.
4. Completare questa finestra nel modo seguente:
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
73
Menu Item Type
Se si sta aggiungendo una voce di menu, selezionare il tipo di voce di
menu che si desidera aggiungere al menu selezionato. Se si sta
modificando uno strumento o un menu secondario, questo campo è di
sola lettura.
Nota: Se si sta aggiungendo un separatore, questa è la sola voce
obbligatoria all’interno di questa finestra.
Tool
Selezionare lo strumento che si desidera aggiungere. Se si sta
modificando uno strumento, è possibile scegliere di selezionare un altro
strumento da questo elenco a discesa.
Nota: Questo campo è disponibile solo per gli strumenti.
Se si desidera creare un nuovo strumento che può quindi essere
aggiunto come voce di menu all’interno del menu selezionato, fare clic
su Add Tool. Si apre la finestra Tool Details. Completare questa finestra
e salvare le modifiche. Quando si ritorna alla finestra Menu Item
Details, lo strumento sarà disponibile per la selezione nell’elenco a
discesa Tool.
Se si desidera modificare le impostazioni dello strumento selezionato,
fare clic su Edit Tool. Si apre la finestra Tool Details. Completare questa
finestra e salvare le modifiche. Si ritorna alla finestra Menu Item
Details.
Title
Se si sta aggiungendo o modificando uno strumento o un menu
secondario, accettare il testo predefinito (se fornito) in questo campo o
immettere un altro titolo. Includere una e commerciale (&) nel titolo se
si desidera creare un mnemonico. Questo testo verrà visualizzato come
nome della voce di menu all’interno del menu.
Nota: Se si sta aggiungendo uno strumento, il campo Title assume
come valore predefinito il nome dello strumento selezionato. Tuttavia,
se si seleziona successivamente uno strumento differente, la voce
iniziale del campo Title resterà immodificata finché non viene
aggiornata manualmente.
5. Salvare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per salvare i dettagli della voce di menu e
chiudere la finestra. Il pannello Menus viene aggiornato per riflettere le
modifiche apportate. Le modifiche si riflettono anche nell’elenco eventi
pertinente o nel menu Conductor al successivo avvio del desktop o alla
risincronizzazione dell’elenco eventi con l’ObjectServer.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Operazioni successive
Suggerimento: Se al menu selezionato è stato aggiunto un menu secondario, è ora
necessario aggiungere voci di menu al menu secondario. Selezionare il menu
secondario nel riquadro Menus, quindi seguire le procedure 3 a pagina 73, 4 a
pagina 73 e 5 per ciascuna delle voci di menu da aggiungere.
74
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Attività correlate
“Creazione e modifica di strumenti” a pagina 77
Modifica di voci di menu
È possibile modificare il titolo di strumenti e menu secondari inclusi nei menu
dell’elenco eventi e di Conductor. È anche possibile sostituire uno strumento con
un altro strumento e modificare la definizione dello strumento.
Per modificare una voce di menu:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Menu.
2. Fare clic su Menus. Si apre il riquadro Menus.
3. Dalla struttura ad albero, selezionare lo strumento o il menu secondario che si
desidera modificare, quindi fare clic su Edit Item nella barra degli strumenti. Si
apre la finestra Menu Item Details.
4. Modificare la voce di menu nel modo seguente:
Menu Item Type
Se si sta aggiungendo una voce di menu, selezionare il tipo di voce di
menu che si desidera aggiungere al menu selezionato. Se si sta
modificando uno strumento o un menu secondario, questo campo è di
sola lettura.
Nota: Se si sta aggiungendo un separatore, questa è la sola voce
obbligatoria all’interno di questa finestra.
Tool
Selezionare lo strumento che si desidera aggiungere. Se si sta
modificando uno strumento, è possibile scegliere di selezionare un altro
strumento da questo elenco a discesa.
Nota: Questo campo è disponibile solo per gli strumenti.
Se si desidera creare un nuovo strumento che può quindi essere
aggiunto come voce di menu all’interno del menu selezionato, fare clic
su Add Tool. Si apre la finestra Tool Details. Completare questa finestra
e salvare le modifiche. Quando si ritorna alla finestra Menu Item
Details, lo strumento sarà disponibile per la selezione nell’elenco a
discesa Tool.
Se si desidera modificare le impostazioni dello strumento selezionato,
fare clic su Edit Tool. Si apre la finestra Tool Details. Completare questa
finestra e salvare le modifiche. Si ritorna alla finestra Menu Item
Details.
Title
Se si sta aggiungendo o modificando uno strumento o un menu
secondario, accettare il testo predefinito (se fornito) in questo campo o
immettere un altro titolo. Includere una e commerciale (&) nel titolo se
si desidera creare un mnemonico. Questo testo verrà visualizzato come
nome della voce di menu all’interno del menu.
Nota: Se si sta aggiungendo uno strumento, il campo Title assume
come valore predefinito il nome dello strumento selezionato. Tuttavia,
se si seleziona successivamente uno strumento differente, la voce
iniziale del campo Title resterà immodificata finché non viene
aggiornata manualmente.
5. Salvare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per salvare i dettagli della voce di menu e
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
75
chiudere la finestra. Il pannello Menus viene aggiornato per riflettere le
modifiche apportate. Le modifiche si riflettono anche nell’elenco eventi
pertinente o nel menu Conductor al successivo avvio del desktop o alla
risincronizzazione dell’elenco eventi con l’ObjectServer.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Attività correlate
“Creazione e modifica di strumenti” a pagina 77
Modifica dell’ordine delle voci di menu
È possibile riordinare le voci di un menu per migliorare i workflow degli utenti.
Per modificare l’ordine delle voci di menu del desktop:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Menu.
2. Fare clic su Menus. Si apre il riquadro Menus.
3. Per ciascuna voce di menu da riposizionare, selezionare la voce di menu e
spostarla nella posizione desiderata utilizzando uno dei seguenti metodi:
v Per spostare una voce all’inizio del menu, selezionare Move To Top dal
menu Item, dalla barra degli strumenti o dal menu pop up che viene
visualizzato quando si fa clic con il tasto destro del mouse sulla voce.
v Per spostare la voce di una posizione verso l’alto, selezionare Move Up dal
menu Item, dalla barra degli strumenti o dal menu pop up che viene
visualizzato quando si fa clic con il tasto destro del mouse sulla voce.
v Per spostare la voce di una posizione verso il basso, selezionare Move Down
dal menu Item, dalla barra degli strumenti o dal menu pop up che viene
visualizzato quando si fa clic con il tasto destro del mouse sulla voce.
v Per spostare una voce alla fine del menu, selezionare Move To Bottom dal
menu Item, dalla barra degli strumenti o dal menu pop up che viene
visualizzato quando si fa clic con il tasto destro del mouse sulla voce.
Le voci di menu riposizionate vengono visualizzate nel nuovo ordine la volta
successiva in cui il desktop viene avviato oppure quando l’elenco eventi viene
risincronizzato con l’ObjectServer.
Rimozione di strumenti, menu secondari o separatori da un
menu
Per rimuovere una voce di menu dal desktop:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Menu.
2. Fare clic su Menus. Si apre il riquadro Menus.
3. Selezionare la voce di menu che si desidera rimuovere. Per i menu secondari, è
possibile selezionare per la rimozione una singola voce oppure è possibile
selezionare il nome del menu secondario per eliminare il menu secondario e il
suo contenuto.
4. Dalla barra degli strumenti, fare clic su Delete.
Risultati
La voce di menu viene rimossa dal desktop la volta successiva in cui il desktop
viene avviato oppure l’elenco eventi viene risincronizzato con l’ObjectServer.
76
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Visualizzazione in anteprima della struttura dei menu
personalizzati
È possibile visualizzare in anteprima i menu personalizzati per vedere come
verranno visualizzati nel desktop.
Per visualizzare un’anteprima dei menu:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Menu.
2. Fare clic su Menus. Si apre il riquadro Menus.
3. Dalla barra degli strumenti, fare clic su Show Menu Structure. Si apre la
finestra di anteprima con i menu elencati in orizzontale. È possibile fare clic su
ciascun nome di menu per espanderne il contenuto.
Risultati
Nota: I nomi dei menu così come vengono visualizzati in Netcool/OMNIbus
Administrator differiscono da quelli indicati sul desktop.
Configurazione degli strumenti
Gli strumenti consentono agli operatori di gestire avvisi nell’elenco eventi. È
possibile creare strumenti che gli operatori possono utilizzare per eseguire comandi
SQL sull’ObjectServer oppure per eseguire comandi esterni che avviano
un’applicazione locale, un file batch oppure uno script.
È possibile associare a uno strumento un’istruzione SQL, comandi eseguibili o
entrambi. Uno strumento può anche includere una finestra di prompt o un menu
pop up per consentire agli operatori di immettere o selezionare informazioni.
È possibile aggiungere strumenti ai menu degli elenchi eventi e associare strumenti
alle classi avviso. Questi strumenti sono disponibili nei menu solo quando gli
avvisi delle classi associate sono selezionati nell’elenco eventi.
Nota: È possibile utilizzare il programma di utilità nco_elct in uno strumento per
aprire un elenco eventi temporaneo, personalizzato. Ad esempio, è possibile aprire
un elenco eventi e applicare un filtro per visualizzare tutti gli avvisi critici di un
determinato ObjectServer. Per informazioni su nco_elct, consultare IBM Tivoli
Netcool/OMNIbus User’s Guide.
Attività correlate
“Aggiunta di strumenti, di menu secondari e di separatori a un menu” a pagina 73
Creazione e modifica di strumenti
Quando si crea uno strumento, esso viene aggiunto al database degli strumenti. Gli
strumenti che vengono visualizzati nel riquadro Tools sono link alle voci contenute
in questo database.
Per creare o modificare uno strumento:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di
menu Menu.
2. Fare clic su Tools. Si apre il riquadro Tools.
3. Per aggiungere uno strumento, fare clic su Add Tool nella barra degli
strumenti. Si apre la finestra Tool Details.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
77
4. Per modificare uno strumento, selezionare lo strumento da modificare, quindi
fare clic su Edit Tool nella barra degli strumenti. Si apre la finestra Tool
Details.
5. Definire lo strumento nel modo seguente:
Name Immettere un nome univoco per lo strumento. Se si sta modificando
uno strumento, non è possibile modificarne il nome.
Enabled
Selezionare questa casella di spunta per attivare lo strumento e
renderlo disponibile per l’utilizzo da parte degli operatori.
Deselezionare questa casella di spunta per creare lo strumento senza
attivarlo attualmente o per rendere lo strumento non disponibile.
6. Dalla scheda SQL, immettere un qualsiasi comando SQL che deve essere
eseguito sull’ObjectServer quando si seleziona lo strumento per l’uso.
Completare la scheda nel modo seguente:
Enabled
Selezionare questa casella di spunta per specificare che i comandi SQL
immessi devono essere eseguiti quando viene utilizzato lo strumento.
Execute for each selected row
Selezionare questa casella di spunta per specificare che i comandi SQL
devono essere eseguiti una volta per ciascuna riga in una selezione di
riga dell’elenco eventi.
SQL Commands
Immettere i comandi SQL che devono essere eseguiti quando viene
utilizzato lo strumento.
È possibile utilizzare i pulsanti dell’helper SQL mostrati a destra di
questo campo per costruire i comandi SQL.
Suggerimento: È possibile includere un prompt in un’istruzione SQL
così che, all’avvio dello strumento, venga visualizzata una finestra di
prompt o un menu pop-up affinché gli utenti immettano o selezionino
le informazioni.
7. Dalla scheda Executable, immettere un qualsiasi comando esterno che deve
essere eseguito quando si seleziona lo strumento per l’uso. Completare la
scheda nel modo seguente:
Enabled
Selezionare questa casella di spunta per specificare che i comandi
eseguibili immessi devono essere eseguiti quando viene utilizzato lo
strumento.
Execute for each selected row
Selezionare questa casella di spunta per specificare che i comandi
eseguibili devono essere eseguiti una volta per ciascuna riga in una
selezione di riga dell’elenco eventi.
Redirect output
Selezionare questa casella di spunta per specificare che, durante
l’esecuzione dei comandi, si deve effettuare l’eco dell’output tramite
una finestra di sola lettura. Deselezionare questa casella di spunta per
eliminare l’output.
Redirect errors
Selezionare questa casella di spunta per specificare che, durante
l’esecuzione dei comandi, si deve effettuare l’eco di tutti i messaggi di
78
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
errore tramite una finestra di sola lettura. Deselezionare questa casella
di spunta per eliminare i messaggi di errore.
Executable Commands
Immettere i comandi che devono essere eseguiti quando viene
utilizzato questo strumento.
È possibile utilizzare i pulsanti dell’helper SQL mostrati a destra di
questo campo per costruire i comandi eseguibili.
Suggerimento: È possibile includere un prompt in un comando
esterno così che, all’avvio dello strumento, venga visualizzata una
finestra di prompt o un menu pop-up per affinché gli utenti
immettano o selezionino le informazioni.
8. Dalla scheda Journal, specificare le impostazioni di journal che devono essere
applicate quando si seleziona lo strumento per l’uso. Completare la scheda nel
modo seguente:
Force Journal Entry
Selezionare questa casella di spunta per imporre agli utenti di
immettere il testo del journal prima dell’esecuzione dello strumento.
Questo testo viene accodato al journal dell’avviso o degli avvisi
selezionati quando viene utilizzato lo strumento.
Execute for each selected row
Selezionare questa casella di spunta per immettere le informazioni del
journal una volta per ciascuna riga in una selezione di riga dell’elenco
eventi.
Voce Journal
Immettere il testo per la voce del journal.
È possibile utilizzare i pulsanti dell’helper mostrati a destra di questo
campo per costruire il testo del journal.
Suggerimento: È possibile includere un prompt in una voce del
journal così che, all’avvio dello strumento, venga visualizzata una
finestra di prompt o un menu pop-up affinché gli utenti immettano o
selezionino le informazioni.
9. Dalla scheda Access, specificare le classi avviso a cui si applica lo strumento e
i gruppi di utenti autorizzati a utilizzare lo strumento. Completare la scheda
nel modo seguente:
Class Access
Selezionare le classi avviso per le quali è possibile utilizzare lo
strumento. Per selezionare tutte le classi avviso, fare clic su Tick All
subito a destra di questo elenco. Per deselezionare tutte le selezioni,
fare clic su Tick None subito a destra di questo elenco. È inoltre
possibile selezionare singolarmente ciascuna casella di spunta
obbligatoria.
Group Access
Selezionare il gruppo utenti che può utilizzare questo strumento. Per
selezionare tutti i gruppi, fare clic su Tick All subito a destra di
questo elenco. Per deselezionare tutte le selezioni, fare clic su Tick
None subito a destra di questo elenco. È inoltre possibile selezionare
singolarmente ciascuna casella di spunta obbligatoria.
10. Dalla scheda Platform, specificare le piattaforme dei sistemi operativi sulle
quali lo strumento sarà disponibile. Completare la scheda nel modo seguente:
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
79
Available Platforms
Selezionare le caselle di spunta per i sistemi operativi sui quali sarà
disponibile lo strumento. Per selezionare tutti i sistemi operativi, fare
clic su Tick All a destra di questo elenco. Per deselezionare tutte le
selezioni, fare clic su Tick None a destra di questo elenco.
Importante: Si devono sempre specificare i sistemi operativi su cui è
possibile utilizzare lo strumento. Lo strumento è disponibile solo sulle
piattaforme selezionate.
11. Dalla scheda Description, immettere una descrizione facoltativa per questo
strumento. Questa descrizione può essere utile per coloro che desiderano
comprendere il funzionamento dello strumento.
12. Salvare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per salvare i dettagli dello strumento e
chiudere la finestra. I nuovi strumenti vengono aggiunti al pannello
Strumenti.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Operazioni successive
Gli strumenti mostrati nel pannello Strumenti vengono aggiunti all’elenco eventi e
ai menu del desktop Conductor per consentire la gestione degli avvisi.
Attività correlate
“Aggiunta di strumenti, di menu secondari e di separatori a un menu” a pagina 73
“Creazione e modifica di prompt” a pagina 81
Riferimenti correlati
Appendice B, “Pulsanti helper, espressioni variabili e comandi SQL in strumenti,
automazioni ed elenchi eventi transitori”, a pagina 347
Eliminazione di strumenti
Per eliminare uno strumento:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Menu.
2. Fare clic su Tools. Si apre il riquadro Tools.
3. Selezionare lo strumento che si desidera eliminare e fare clic su Delete nella
barra degli strumenti. Lo strumento viene eliminato.
Configurazione dei prompt
Uno strumento elenco eventi può includere una finestra di prompt oppure un
menu pop up per consentire agli utenti di immettere o selezionare informazioni.
Quando si crea o si modifica uno strumento, è possibile includere un prompt in
una istruzione SQL, in un comando esterno oppure in una voce di journal.
È possibile creare i seguenti tipi di prompt:
v String: crea una finestra di prompt che accetta uno o più caratteri.
v Integer: crea una finestra di prompt che accetta un valore intero.
80
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
v Float: crea una finestra di prompt che accetta un numero a virgola mobile, che
può contenere una virgola decimale.
v Time: crea una finestra di prompt che accetta un valore temporale.
v Fixed choice: crea un menu pop up in cui vengono inserite le opzioni che si
specificano.
v Lookup: crea un menu pop up oppure un elenco a discesa in cui vengono
inseriti i valori presenti in un file specificato.
v Password: crea una finestra di prompt che accetta uno o più caratteri come
password.
v Dynamic choice: crea un menu pop up oppure un elenco a discesa che viene
compilato con i risultati di una query del database.
Creazione e modifica di prompt
È possibile creare prompt da utilizzare con gli strumenti.
Per creare o modificare un prompt:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di
menu Menu.
2. Fare clic su Prompts. Si apre il riquadro Prompts.
3. Per aggiungere un prompt, fare clic su Add Prompt nella barra degli
strumenti. Si apre la finestra Prompt Details. I campi di questa finestra
variano a seconda del tipo di prompt da creare o modificare.
4. Per modificare un prompt, selezionare lo strumento da modificare, quindi fare
clic su Edit Prompt nella barra degli strumenti. Si apre la finestra Prompt
Details. I campi di questa finestra variano a seconda del tipo di prompt da
creare o modificare.
5. Per creare o modificare un prompt string, completare la finestra nel modo
seguente:
Name Immettere un nome univoco per il prompt. Questo nome deve essere
conforme alle convenzioni di denominazione dell’ObjectServer. Se si
sta modificando un prompt, non è possibile modificarne il nome.
Prompt
Immettere il testo del prompt che deve essere visualizzato quando lo
strumento richiede le informazioni all’utente.
Selezionare String per creare una finestra di prompt che accetta uno o
più caratteri.
Type
Default
Immettere un valore predefinito per la visualizzazione del prompt.
6. Per creare o modificare un prompt integer, completare la finestra nel modo
seguente:
Name Immettere un nome univoco per il prompt. Questo nome deve essere
conforme alle convenzioni di denominazione dell’ObjectServer. Se si
sta modificando un prompt, non è possibile modificarne il nome.
Prompt
Immettere il testo del prompt che deve essere visualizzato quando lo
strumento richiede le informazioni all’utente.
Type
Selezionare Integer per creare una finestra di prompt che accetta un
valore intero.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
81
Default
Immettere un valore predefinito per la visualizzazione del prompt.
7. Per creare o modificare un prompt float, completare la finestra nel modo
seguente:
Name Immettere un nome univoco per il prompt. Questo nome deve essere
conforme alle convenzioni di denominazione dell’ObjectServer. Se si
sta modificando un prompt, non è possibile modificarne il nome.
Prompt
Immettere il testo del prompt che deve essere visualizzato quando lo
strumento richiede le informazioni all’utente.
Type
Selezionare Float per creare una finestra di prompt che accetta un
numero a virgola mobile, che può contenere una virgola decimale.
Default
Immettere un valore predefinito per la visualizzazione del prompt.
8. Per creare o modificare un prompt time, completare la finestra nel modo
seguente:
Name Immettere un nome univoco per il prompt. Questo nome deve essere
conforme alle convenzioni di denominazione dell’ObjectServer. Se si
sta modificando un prompt, non è possibile modificarne il nome.
Prompt
Immettere il testo del prompt che deve essere visualizzato quando lo
strumento richiede le informazioni all’utente.
Selezionare Time per creare una finestra di prompt che accetti un
valore temporale. Per un prompt del valore temporale, l’impostazione
predefinita è la visualizzazione dell’ora corrente.
9. Per creare o modificare un prompt fixed choice, completare la finestra nel
modo seguente:
Type
Name Immettere un nome univoco per il prompt. Questo nome deve essere
conforme alle convenzioni di denominazione dell’ObjectServer. Se si
sta modificando un prompt, non è possibile modificarne il nome.
Prompt
Immettere il testo del prompt che deve essere visualizzato quando lo
strumento richiede le informazioni all’utente.
Type
Selezionare Fixed Choice per creare un menu pop-up popolato con
opzioni specificate dall’utente.
Options
Utilizzare questo campo per specificare le opzioni di menu per
includere il menu pop-up. Per creare una nuova opzione, fare clic
nell’elenco Add option e immettere un nome per l’opzione nella
casella visualizzata nell’elenco Options. Fare clic al di fuori della
casella per completare la voce. È anche possibile modificare
un’opzione esistente facendo clic sulla voce nell’elenco Options e poi
facendo clic su Edit option. Per eliminare un’opzione, fare clic sulla
voce e poi fare clic su Delete option.
10. Per creare o modificare un prompt lookup, completare la finestra nel modo
seguente:
Name Immettere un nome univoco per il prompt. Questo nome deve essere
conforme alle convenzioni di denominazione dell’ObjectServer. Se si
sta modificando un prompt, non è possibile modificarne il nome.
82
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Prompt
Immettere il testo del prompt che deve essere visualizzato quando lo
strumento richiede le informazioni all’utente.
Selezionare Lookup per creare un menu pop-up o un elenco a discesa
popolato dai valori in un file specificato dall’utente.
Type
Immettere il percorso e il nome del file il cui contenuto deve essere
utilizzato per popolare il menu pop-up o l’elenco a discesa associato
al prompt. In alternativa, fare clic su Browse per aprire una finestra di
selezione file, navigare nell’ubicazione appropriata e selezionare il file.
11. Per creare o modificare un prompt password, completare la finestra nel modo
seguente:
File
Name Immettere un nome univoco per il prompt. Questo nome deve essere
conforme alle convenzioni di denominazione dell’ObjectServer. Se si
sta modificando un prompt, non è possibile modificarne il nome.
Prompt
Immettere il testo del prompt che deve essere visualizzato quando lo
strumento richiede le informazioni all’utente.
Selezionare Password per creare una finestra di prompt che accetta
uno o più caratteri come password. Per un prompt della password, i
caratteri della password vengono visualizzati come asterischi quando
l’utente completa il prompt.
12. Per creare o modificare un prompt dynamic choice, completare la finestra nel
modo seguente:
Type
Name Immettere un nome univoco per il prompt. Questo nome deve essere
conforme alle convenzioni di denominazione dell’ObjectServer. Se si
sta modificando un prompt, non è possibile modificarne il nome.
Prompt
Immettere il testo del prompt che deve essere visualizzato quando lo
strumento richiede le informazioni all’utente.
Selezionare Dynamic Choice per creare un menu pop-up o un elenco a
discesa popolato dai risultati di una query di database.
Type
Database
Selezionare un database dall’elenco a discesa.
Table
Selezionare una tabella nel database selezionato dall’elenco a discesa.
Show Selezionare un nome colonna dall’elenco a discesa. Ciò definisce la
colonna utilizzata per popolare il menu del prompt.
Assign
Selezionare un nome colonna dall’elenco a discesa. Ciò definisce la
colonna utilizzata per restituire un valore al comando SQL.
Where Immettere una condizione di ricerca SQL. Ad esempio:
Colname=’Severity’.
Order By
Selezionare un nome colonna dall’elenco a discesa. Definisce la
colonna mediante la quale vengono ordinate le voci nel menu del
prompt. Utilizzare le opzioni Ascending e Descending per specificare
le direzioni di ordinamento.
13. Salvare o annullare le modifiche nel modo seguente:
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
83
OK
Fare clic su questo pulsante per salvare i dettagli del prompt e
chiudere la finestra. I nuovi prompt vengono aggiunti al pannello
Prompts.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Operazioni successive
I prompt visualizzati nel pannello Prompts possono essere aggiunti agli strumenti
configurati per consentire agli operatori di gestire gli avvisi nell’elenco eventi.
Quando uno strumento di questo tipo viene eseguito, viene visualizzata una
finestra di prompt o un menu pop-up per immettere o selezionare le informazioni.
Concetti correlati
“Convenzioni di denominazione per oggetti ObjectServer” a pagina 127
Attività correlate
“Creazione e modifica di strumenti” a pagina 77
Eliminazione di prompt
Per eliminare un prompt:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Menu.
2. Fare clic su Prompts. Si apre il riquadro Prompts.
3. Selezionare il prompt che si desidera eliminare e fare clic su Delete nella barra
degli strumenti. Il prompt viene eliminato.
Configurazione di automazioni
È possibile utilizzare un’automazione per rilevare modifiche nell’ObjectServer e per
eseguire risposte automatizzate a queste modifiche. Ciò consente all’ObjectServer
di elaborare avvisi senza richiedere ad un operatore di eseguire l’azione.
Ad esempio, gli avvisi di rete spesso includono il messaggio Link Down, per
indicare che c’è un problema nella rete. Quando il problema viene risolto,
l’ObjectServer riceve un altro segnale che include il messaggio Link Up. Utilizzando
un’automazione correttamente configurata, l’ObjectServer può associare in maniera
automatica i due avvisi, riconoscere che il messaggio Link Up indica che il
problema è stato risolto ed eliminare entrambi gli avvisi.
È anche possibile utilizzare l’automazione per gestire la deduplicazione, che riduce
la quantità di dati conservati nell’ObjectServer eliminando gli eventi duplicati.
Netcool/OMNIbus include numerose automazioni standard.
I trigger costituiscono la base del sottosistema di automazione dell’ObjectServer. I
trigger eseguono in maniera automatica un’azione trigger oppure vengono attivati
quando l’ObjectServer rileva un incidente associato a un trigger. In un trigger è
possibile eseguire comandi SQL e richiamare procedure in risposta alla modifica.
Anche i segnali e le procedure fanno parte del sottosistema di automazione. È
possibile associare trigger ai segnali in modo che l’ObjectServer possa rispondere
automaticamente quando viene generato un segnale. Le procedure sono
programmi eseguibili che vengono creati per eseguire operazioni comuni e che è
possibile eseguire in un trigger o dall’interfaccia interattiva SQL.
84
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Concetti correlati
“Interfaccia interattiva SQL” a pagina 123
Riferimenti correlati
“Esecuzione di procedure” a pagina 194
“Automazioni di Tivoli Netcool/OMNIbus standard” a pagina 220
Configurazione dei trigger
Ci sono tre tipi di trigger: trigger di database, trigger di segnale e trigger
temporali. I trigger di database vengono attivati quando si verifica un incidente del
database. I trigger di segnale vengono attivati quando viene generato un segnale di
sistema oppure un segnale definito dall’utente. I trigger temporali vengono attivati
ripetutamente in base alla frequenza specificata.
Ogni trigger deve appartenere a un gruppo di trigger, che è una raccolta di trigger
correlati. È possibile abilitare o disabilitare con una singola azione tutti i trigger di
un determinato gruppo di trigger.
Suggerimento: È possibile creare e modificare trigger dalle finestre di
Netcool/OMNIbus Administrator predefinite oppure da un editor di testo a
propria scelta.
Creazione e modifica di gruppi di trigger
Quando si crea un trigger, occorre assegnarlo a un gruppo di trigger. È possibile
creare gruppi di trigger prima di creare i trigger (come azione separata) oppure
durante la creazione dei trigger. Questa attività descrive come creare gruppi di
trigger in un’azione separata.
Per creare o modificare un gruppo di trigger:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Automation.
2. Fare clic su Trigger Groups. Si apre il riquadro Trigger Groups.
3. Per aggiungere un gruppo di trigger, fare clic su Add Trigger Group nella
barra degli strumenti. Si apre la finestra Trigger Group Details.
4. Per modificare un gruppo di trigger, selezionare il gruppo di trigger da
modificare, quindi fare clic su Edit Trigger Group nella barra degli strumenti.
Si apre la finestra Trigger Group Details.
5. Completare i campi nel modo seguente:
Group Name
Immettere un nome univoco per il gruppo trigger. Se si sta modificando
un gruppo trigger, non è possibile modificarne il nome.
Suggerimento: Quando si creano oggetti dell’ObjectServer, i relativi
nomi devono iniziare con una lettera maiuscola o minuscola, seguita da
lettere maiuscole o minuscole, numeri o caratteri di sottolineatura (_),
per una lunghezza massima di 40 caratteri. Per i nomi di utenti, gruppi e
ruoli, è possibile specificare qualsiasi stringa di testo che può includere spazi e
la cui lunghezza non deve superare i 64 caratteri. I nomi degli oggetti
dell’ObjectServer rispettano la distinzione maiuscolo/minuscolo.
Enabled
Selezionare questa casella di spunta per attivare il gruppo trigger.
Deselezionare questa casella di spunta per creare il gruppo trigger
senza attivarlo attualmente o per rendere il trigger non disponibile.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
85
Quando un gruppo trigger non è disponibile, anche tutti i trigger del
gruppo non sono disponibili all’utilizzo. È possibile anche rendere
disponibili o non disponibili singoli trigger durante la loro creazione o
modifica.
6. Salvare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per salvare i dettagli del gruppo trigger e
chiudere la finestra. I nuovi gruppi trigger vengono aggiunti al
pannello Trigger Groups.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Attività correlate
“Creazione e modifica di trigger di database”
“Creazione e modifica di trigger di segnale” a pagina 88
“Creazione e modifica di trigger temporali” a pagina 91
Creazione e modifica di trigger di database
Un trigger di database viene attivato quando ha luogo una modifica nel database.
Ad esempio, è possibile creare un trigger per eseguire un’azione ogni volta che ha
luogo un inserimento nella tabella alerts.status.
Per creare o modificare un trigger di database:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di
menu Automation.
2. Fare clic su Triggers. Si apre il riquadro Triggers.
Questo riquadro elenca tutti i trigger di database, di segnale e temporali che
sono stati configurati.
Suggerimento: Per visualizzare solo un tipo di trigger, fare clic su Show
Database Triggers Only, Show Temporal Triggers Only o Show Signal
Triggers Only nella barra degli strumenti.
3. Per aggiungere un trigger di database, fare clic su Add Database Trigger nella
barra degli strumenti. Si apre la finestra Database Trigger Details.
4. Per modificare un trigger di database, selezionare il trigger di database da
modificare, quindi fare clic su Edit Trigger nella barra degli strumenti. Si apre
la finestra Database Trigger Details.
5. Definire o modificare i dettagli di configurazione di un trigger come descritto
di seguito:
Name Immettere un nome trigger univoco. Se si sta modificando un trigger,
non è possibile modificarne il nome.
Suggerimento: Quando si creano oggetti dell’ObjectServer, i relativi
nomi devono iniziare con una lettera maiuscola o minuscola, seguita
da lettere maiuscole o minuscole, numeri o caratteri di sottolineatura
(_), per una lunghezza massima di 40 caratteri. Per i nomi di utenti,
gruppi e ruoli, è possibile specificare qualsiasi stringa di testo che può
includere spazi e la cui lunghezza non deve superare i 64 caratteri. I nomi
degli oggetti dell’ObjectServer rispettano la distinzione
maiuscolo/minuscolo.
Group Selezionare il gruppo del trigger al quale si desidera assegnare il
trigger.
86
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Add new trigger group
Fare clic su questo pulsante se si desidera creare un nuovo gruppo
trigger al quale è possibile assegnare il trigger. Si apre la finestra
Trigger Group Details. Completare questa finestra e salvare le
modifiche.
Quando si ritorna alla finestra Database Trigger Details, viene
visualizzato il nuovo gruppo trigger come gruppo trigger attualmente
selezionato.
6. Completare la scheda Settings nel modo seguente:
Selezionare il database ObjectServer e la tabella di database che
determina l’attivazione del trigger.
On
Priority
Selezionare una priorità che determina l’ordine in cui vene attivato
l’ObjectServer quando questa modifica di database comporta
l’attivazione di più trigger. È possibile selezionare i numeri da 1 a 20,
dove 1 rappresenta la priorità massima.
Pre database action/Post database action
Fare clic su Pre database action per indicare che l’azione trigger deve
essere eseguita prima che si verifichi la modifica del database che ha
provocato l’attivazione del trigger. Fare clic su Post database action
per indicare che l’azione trigger deve essere eseguita dopo che si
verifica la modifica del database che ha provocato l’attivazione del
trigger.
Ad esempio, è possibile fare clic su Pre database action per valutare
un nome utente prima di eliminare una riga nella tabella alerts.status.
Nel trigger, è possibile rilevare se all’utente è consentita l’eliminazione
dalla tabella alerts.status e, in caso contrario, impedire l’attuazione
della modifica del database. Se si fa clic su Post database action, la
modifica del database viene sempre apportata.
Delete/Insert/Reinsert/Update
Utilizzare queste opzioni per specificare il tipo di modifica di database
che si deve verificare.
Row/Statement
Fare clic su Row per impostare l’attivazione del trigger una volta per
ciascuna riga che corrisponde alla condizione del trigger. Fare clic su
Statement per impostare l’attivazione del trigger una volta
indipendentemente dal numero di righe corrispondenti nella tabella.
Debug
Selezionare questa casella di spunta per inviare informazioni di debug
al log di messaggi dell’ObjectServer ogni volta che viene attivato il
trigger.
Enabled
Selezionare questa casella di spunta per attivare il trigger e renderlo
disponibile per l’utilizzo. Deselezionare questa casella di spunta per
creare il trigger senza attivarlo attualmente o per rendere il trigger
non disponibile. Un trigger disabilitato non viene attivato quando si
verifica una modifica del database.
7. Dalla scheda When, specificare una clausola WHEN facoltativa che consenta
di verificare, prima che l’azione venga eseguita, se una determinata
condizione viene soddisfatta. Se la condizione non viene soddisfatta, l’azione
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
87
non viene eseguita. È possibile utilizzare i pulsanti dell’helper visualizzati alla
destra del campo per creare la clausola WHEN.
8. Dalla scheda Action, immettere i comandi SQL per il trigger.
Il corpo di un trigger contiene una serie di comandi SQL e i costrutti di
programmazione che modificano i dati nell’ObjectServer. Il corpo di un trigger
viene racchiuso all’interno delle parole chiave BEGIN e END. Ciascuna
istruzione, tranne l’ultima, deve essere separata da un punto e virgola (;).
È possibile , se lo si desidera, definire (dichiarare) le variabili locali da
utilizzare in un trigger. Una variabile locale è un segnaposto per i valori
utilizzati durante l’esecuzione del trigger. Le dichiarazioni della variabile
locale in un trigger devono essere separate dai due punti (;).
Il corpo del trigger possiede la seguente sintassi:
[ DECLARE variable_declaration;...[;] ]
BEGIN
trigger_statement_list
END;
È possibile utilizzare i pulsanti dell’helper SQL mostrati a destra del pannello
dell’editor SQL per costruire i comandi SQL.
9. Dalla scheda Comment, immettere un commento di testo facoltativo per il
trigger. Questo commento può essere utile per coloro che desiderano
comprendere il funzionamento del trigger.
10. Salvare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per salvare i dettagli del trigger e
chiudere la finestra. I nuovi trigger vengono aggiunti al pannello
Triggers.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Concetti correlati
“Condizioni” a pagina 160
Attività correlate
“Creazione e modifica di gruppi di trigger” a pagina 85
Riferimenti correlati
“Creazione di trigger di database (comando CREATE TRIGGER)” a pagina 198
“Migliori pratiche per la creazione di trigger” a pagina 305
Appendice B, “Pulsanti helper, espressioni variabili e comandi SQL in strumenti,
automazioni ed elenchi eventi transitori”, a pagina 347
Creazione e modifica di trigger di segnale
I trigger di segnale vengono attivati quando viene generato un segnale di sistema
oppure un segnale definito dall’utente. I segnali di sistema vengono generati
automaticamente dall’ObjectServer quando rileva modifiche al sistema. I segnali
definiti dall’utente vengono creati, generati ed eliminati in maniera esplicita.
Ad esempio, è possibile creare un trigger di segnale per inviare una e-mail a un
operatore quando l’ObjectServer viene avviato o arrestato, poiché viene generato
un segnale di sistema quando si verifica questo evento.
Per creare o modificare un trigger di segnale:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di
menu Automation.
88
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
2. Fare clic su Triggers. Si apre il riquadro Triggers.
Questa finestra elenca tutti i trigger di database, di segnale e temporali che
sono stati configurati.
Suggerimento: Per visualizzare solo un tipo di trigger, fare clic su Show
Database Triggers Only, Show Temporal Triggers Only o Show Signal
Triggers Only nella barra degli strumenti.
3. Per aggiungere un trigger di segnale, fare clic su Add Signal Trigger nella
barra degli strumenti. Si apre la finestra Signal Trigger Details.
4. Per modificare un trigger di segnale, selezionare il trigger di segnale da
modificare, quindi fare clic su Edit Trigger nella barra degli strumenti. Si apre
la finestra Signal Trigger Details.
5. Definire o modificare i dettagli di configurazione di un trigger come descritto
di seguito:
Name Immettere un nome trigger univoco. Se si sta modificando un trigger,
non è possibile modificarne il nome.
Suggerimento: Quando si creano oggetti dell’ObjectServer, i relativi
nomi devono iniziare con una lettera maiuscola o minuscola, seguita
da lettere maiuscole o minuscole, numeri o caratteri di sottolineatura
(_), per una lunghezza massima di 40 caratteri. Per i nomi di utenti,
gruppi e ruoli, è possibile specificare qualsiasi stringa di testo che può
includere spazi e la cui lunghezza non deve superare i 64 caratteri. I nomi
degli oggetti dell’ObjectServer rispettano la distinzione
maiuscolo/minuscolo.
Group Selezionare il gruppo del trigger al quale si desidera assegnare il
trigger.
Add New Trigger Group
Fare clic su questo pulsante se si desidera creare un nuovo gruppo
trigger al quale è possibile assegnare il trigger. Si apre la finestra
Trigger Group Details. Completare questa finestra e salvare le
modifiche.
Quando si ritorna alla finestra Signal Trigger Details, il nuovo gruppo
trigger viene mostrato come gruppo trigger attualmente selezionato.
6. Completare la scheda Settings nel modo seguente:
Signal Selezionare il segnale che deve attivare il trigger.
Priority
Selezionare una priorità che determina l’ordine in cui vene attivato
l’ObjectServer quando questo segnale comporta l’attivazione di più
trigger. È possibile selezionare i numeri da 1 a 20, dove 1 rappresenta
la priorità massima.
Debug
Selezionare questa casella di spunta per inviare informazioni di debug
al log di messaggi dell’ObjectServer ogni volta che viene attivato il
trigger.
Enabled
Selezionare questa casella di spunta per attivare il trigger e renderlo
disponibile per l’utilizzo. Deselezionare questa casella di spunta per
creare il trigger senza attivarlo attualmente o per rendere il trigger
non disponibile. Un trigger disabilitato non viene attivato quando
viene generato un segnale associato.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
89
7. Dalla scheda When, specificare una clausola WHEN facoltativa che consenta
di verificare, prima che l’azione venga eseguita, se una determinata
condizione viene soddisfatta. Se la condizione non viene soddisfatta, l’azione
non viene eseguita. È possibile utilizzare i pulsanti dell’helper visualizzati alla
destra del campo per creare la clausola WHEN.
8. Dalla scheda Evaluate, se si desidera, creare una serie di risultati temporanea
da una singola istruzione SELECT da elaborare durante l’azione trigger
definita nella scheda Action. Completare la scheda nel modo seguente:
Bind As
Immettere il nome della tabella temporanea in cui archiviare la serie
di risultati.
SQL editor panel
Immettere l’istruzione utilizzando il formato:
EVALUATE SELECT_cmd
È possibile utilizzare i pulsanti dell’helper SQL mostrati a destra del
campo per costruire l’istruzione.
9. Dalla scheda Action, immettere i comandi SQL per il trigger.
Il corpo di un trigger contiene una serie di comandi SQL e i costrutti di
programmazione che modificano i dati nell’ObjectServer. Il corpo di un trigger
viene racchiuso all’interno delle parole chiave BEGIN e END. Ciascuna
istruzione, tranne l’ultima, deve essere separata da un punto e virgola (;).
È possibile , se lo si desidera, definire (dichiarare) le variabili locali da
utilizzare in un trigger. Una variabile locale è un segnaposto per i valori
utilizzati durante l’esecuzione del trigger. Le dichiarazioni della variabile
locale in un trigger devono essere separate dai due punti (;).
Il corpo del trigger possiede la seguente sintassi:
[ DECLARE variable_declaration;...[;] ]
BEGIN
trigger_statement_list
END;
È possibile utilizzare i pulsanti dell’helper SQL mostrati a destra del pannello
dell’editor SQL per costruire i comandi SQL.
10. Dalla scheda Comment, immettere un commento di testo facoltativo per il
trigger. Questo commento può essere utile per coloro che desiderano
comprendere il funzionamento del trigger.
11. Salvare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per salvare i dettagli del trigger e
chiudere la finestra. I nuovi trigger vengono aggiunti al pannello
Triggers.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
90
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Concetti correlati
“Configurazione dei segnali” a pagina 104
“Condizioni” a pagina 160
Attività correlate
“Creazione e modifica di gruppi di trigger” a pagina 85
Riferimenti correlati
“Creazione di trigger di segnale (comando CREATE TRIGGER)” a pagina 202
“Segnali di sistema e relativi attributi” a pagina 207
“Migliori pratiche per la creazione di trigger” a pagina 305
Appendice B, “Pulsanti helper, espressioni variabili e comandi SQL in strumenti,
automazioni ed elenchi eventi transitori”, a pagina 347
Creazione e modifica di trigger temporali
I trigger temporali vengono attivati ripetutamente in base alla frequenza
specificata.
Ad esempio, è possibile utilizzare un trigger temporale per eliminare tutte le righe
con stato chiaro (Severity = 0) dalla tabella alerts.status che non sono state
modificate entro un determinato periodo di tempo.
Per creare o modificare un trigger temporale:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di
menu Automation.
2. Fare clic su Triggers. Si apre il riquadro Triggers.
Questo riquadro elenca tutti i trigger di database, di segnale e temporali che
sono stati configurati.
Suggerimento: Per visualizzare solo un tipo di trigger, fare clic su Show
Database Triggers Only, Show Temporal Triggers Only o Show Signal
Triggers Only nella barra degli strumenti.
3. Per aggiungere un trigger temporale, fare clic su Add Temporal Trigger nella
barra degli strumenti. Si apre la finestra Temporal Trigger Details.
4. Per modificare un trigger temporale, selezionare il trigger temporale da
modificare, quindi fare clic su Edit Trigger nella barra degli strumenti. Si apre
la finestra Temporal Trigger Details.
5. Definire o modificare i dettagli di configurazione di un trigger nel modo
seguente:
Name Immettere un nome trigger univoco. Se si sta modificando un trigger,
non è possibile modificarne il nome.
Suggerimento: Quando si creano oggetti dell’ObjectServer, i relativi
nomi devono iniziare con una lettera maiuscola o minuscola, seguita
da lettere maiuscole o minuscole, numeri o caratteri di sottolineatura
(_), per una lunghezza massima di 40 caratteri. Per i nomi di utenti,
gruppi e ruoli, è possibile specificare qualsiasi stringa di testo che può
includere spazi e la cui lunghezza non deve superare i 64 caratteri. I nomi
degli oggetti dell’ObjectServer rispettano la distinzione
maiuscolo/minuscolo.
Group Selezionare il gruppo del trigger al quale si desidera assegnare il
trigger.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
91
Add New Trigger Group
Fare clic su questo pulsante se si desidera creare un nuovo gruppo
trigger al quale è possibile assegnare il trigger. Si apre la finestra
Trigger Group Details. Completare questa finestra e salvare le
modifiche.
Quando si ritorna alla finestra Temporal Trigger Details, viene
aggiunto il nuovo gruppo trigger all’elenco Group. È possibile
assegnare il trigger a questo gruppo trigger.
6. Completare la scheda Settings nel modo seguente:
Every Definire quando si deve attivare il trigger. Specificare un valore
numerico e selezionare hours, minutes o seconds dall’elenco a
discesa.
Priority
Selezionare una priorità che determina in quale l’ObjectServer
vengono attivati i trigger quando vi sono più trigger a questa
frequenza. È possibile selezionare i numeri da 1 a 20, dove 1
rappresenta la priorità massima.
Debug
Selezionare questa casella di spunta per inviare informazioni di debug
al log di messaggi dell’ObjectServer ogni volta che viene attivato il
trigger.
Enabled
Selezionare questa casella di spunta per attivare il trigger e renderlo
disponibile per l’utilizzo. Deselezionare questa casella di spunta per
creare il trigger senza attivarlo attualmente o per rendere il trigger
non disponibile. Un trigger disabilitato non viene attivato.
7. Dalla scheda When, specificare una clausola WHEN facoltativa che consenta
di verificare, prima che l’azione venga eseguita, se una determinata
condizione viene soddisfatta. Se la condizione non viene soddisfatta, l’azione
non viene eseguita. È possibile utilizzare i pulsanti dell’helper visualizzati alla
destra del campo per creare la clausola WHEN.
8. Dalla scheda Evaluate, se si desidera, creare una serie di risultati temporanea
da una singola istruzione SELECT da elaborare durante l’azione trigger
definita nella scheda Action. Completare la scheda nel modo seguente:
Bind As
Immettere il nome della tabella temporanea in cui archiviare la serie
di risultati.
SQL editor panel
Immettere l’istruzione utilizzando il formato:
EVALUATE SELECT_cmd
È possibile utilizzare i pulsanti dell’helper SQL mostrati a destra del
pannello dell’editor SQL per costruire l’istruzione.
9. Dalla scheda Action, immettere i comandi SQL per il trigger.
Il corpo di un trigger contiene una serie di comandi SQL e i costrutti di
programmazione che modificano i dati nell’ObjectServer. Il corpo di un trigger
viene racchiuso all’interno delle parole chiave BEGIN e END. Ciascuna
istruzione, tranne l’ultima, deve essere separata da un punto e virgola (;).
È possibile , se lo si desidera, definire (dichiarare) le variabili locali da
utilizzare in un trigger. Una variabile locale è un segnaposto per i valori
92
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
utilizzati durante l’esecuzione del trigger. Le dichiarazioni della variabile
locale in un trigger devono essere separate dai due punti (;).
Il corpo del trigger possiede la seguente sintassi:
[ DECLARE variable_declaration;...[;] ]
BEGIN
trigger_statement_list
END;
È possibile utilizzare i pulsanti dell’helper SQL mostrati a destra del pannello
dell’editor SQL per costruire i comandi SQL.
10. Dalla scheda Comment, immettere un commento di testo facoltativo per il
trigger. Questo commento può essere utile per coloro che desiderano
comprendere il funzionamento del trigger.
11. Salvare o annullare le modifiche nel modo seguente:
Fare clic su questo pulsante per salvare i dettagli del trigger e
chiudere la finestra. I nuovi trigger vengono aggiunti al pannello
Triggers.
OK
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Concetti correlati
“Condizioni” a pagina 160
Attività correlate
“Creazione e modifica di gruppi di trigger” a pagina 85
Riferimenti correlati
“Creazione di trigger temporali (comando CREATE TRIGGER)” a pagina 201
“Migliori pratiche per la creazione di trigger” a pagina 305
Appendice B, “Pulsanti helper, espressioni variabili e comandi SQL in strumenti,
automazioni ed elenchi eventi transitori”, a pagina 347
Utilizzo di un editor esterno per creare e modificare trigger
Da Netcool/OMNIbus Administrator, è possibile configurare un editor di testo
esterno, quindi utilizzarlo per creare o modificare trigger.
Configurazione di un editor esterno per trigger:
Se necessario, è possibile creare e modificare trigger da un editor di testo a propria
scelta. Come prima cosa, è necessario configurare l’editor che si desidera utilizzare.
Per configurare un editor esterno:
1. Da Netcool/OMNIbus Administrator, fare clic su Tools → Configure Tools. Si
apre la finestra Choose Tool.
2. Selezionare Text Editor. Si apre la finestra External Program.
3. Completare questa finestra nel modo seguente:
Tool name
Questo campo visualizza il tipo di strumento che si sta configurando.
Executable
Immettere il percorso completo e il nome del programma eseguibile per
il tipo di strumento. In alternativa, fare clic sul pulsante a destra del
campo per eseguire la ricerca e selezionare il programma eseguibile.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
93
Arguments
Immettere qualsiasi argomento della riga comandi da eseguire con
questo programma eseguibile.
Run time environment
Selezionare l’ambiente di runtime.
4. Salvare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per salvare i dettagli del programma
esterno e chiudere la finestra.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Attività correlate
“Creazione e modifica di trigger in un editor esterno”
Creazione e modifica di trigger in un editor esterno:
È possibile utilizzare un editor esterno per creare o modificare un trigger di
database, di segnale o temporale.
Prima di iniziare
È necessario aver configurato un editor esterno da utilizzare per creare o
modificare trigger.
Per creare o modificare un trigger:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Automation.
2. Fare clic su Triggers. Si apre il riquadro Triggers. Questa finestra elenca tutti i
trigger di database, di segnale e temporali che sono stati configurati.
Suggerimento: Per visualizzare solo un tipo di trigger, fare clic su Show
Database Triggers Only, Show Temporal Triggers Only o Show Signal
Triggers Only nella barra degli strumenti.
3. Per creare un trigger, assicurarsi innanzitutto che nessuna riga sia selezionata
nel riquadro Triggers, quindi fare clic su Edit in External Editor nella barra
degli strumenti. È possibile deselezionare una riga premendo il tasto Ctrl,
quindi facendo clic sulla riga. Si apre la finestra di dialogo Select Trigger Type.
Procedere come indicato di seguito:
a. Dall’elenco Trigger Template, selezionare il modello per il tipo di trigger
che si desidera creare. Se si seleziona Database, Signal o Temporal, l’editor
esterno si apre con la sintassi standard per quel tipo di trigger. Se si
seleziona <blank>, l’editor esterno si apre senza visualizzare alcun testo.
b. Completare la sintassi per il trigger. Se si utilizza un modello, sostituire le
variabili trigger_name e group_name con valori effettivi. Inoltre, per un trigger
di segnale, sostituire la variabile signalName con un valore effettivo, mentre
per un trigger di database, sostituire la variabile database_name.table_name
con un valore effettivo. Aggiungere istruzioni specifiche del trigger, clausole
facoltative e dichiarazioni di variabili, in base alle esigenze.
Successivamente, aggiungere il corpo del trigger tra le parole chiave Begin
ed End. Il modello include commenti (preceduti da --) per l’inserimento di
testo.
94
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
c. Salvare le voci. Quando si salva, il trigger viene salvato nell’ObjectServer. Se
ci sono errori di sintassi, viene chiesto di caricare di nuovo il contenuto
dell’editor esterno.
d. Chiudere l’editor esterno.
4. Per modificare un trigger, selezionare il trigger da modificare, quindi fare clic
su Edit in External Editor nella barra degli strumenti oppure fare clic con il
tasto destro del mouse e selezionare Edit in External Editor dal menu pop up.
L’editor esterno si apre con la sintassi del trigger visualizzata. Procedere come
indicato di seguito:
a. Modificare la sintassi del trigger e salvare le modifiche. Quando si salva, il
trigger viene salvato nell’ObjectServer. Se ci sono errori di sintassi, viene
chiesto di caricare di nuovo il contenuto dell’editor esterno.
b. Chiudere l’editor esterno.
Risultati
Suggerimento: L’SQL che si immette in un editor esterno viene salvato
nell’ObjectServer come file .ed. È possibile verificare la validità della sintassi nei
file .ed e in altri file .sql dall’interfaccia interattiva SQL (in esecuzione in modalità
GUI).
Attività correlate
“Configurazione di un editor esterno per trigger” a pagina 93
“Utilizzo dell’interfaccia interattiva SQL in modalità GUI” a pagina 120
Riferimenti correlati
“Creazione di trigger di database (comando CREATE TRIGGER)” a pagina 198
“Creazione di trigger di segnale (comando CREATE TRIGGER)” a pagina 202
“Creazione di trigger temporali (comando CREATE TRIGGER)” a pagina 201
Eliminazione di gruppi di trigger
Non è possibile eliminare un gruppo di trigger che contiene trigger.
Per eliminare un gruppo di trigger:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Automation.
2. Fare clic su Trigger Groups. Si apre il riquadro Trigger Groups.
3. Selezionare il gruppo di trigger che si desidera eliminare e fare clic su Delete
nella barra degli strumenti. Il gruppo di trigger viene eliminato.
Eliminazione di trigger
Per eliminare un trigger:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Automation.
2. Fare clic su Triggers. Si apre il riquadro Triggers.
3. Selezionare il trigger che si desidera eliminare e fare clic su Delete nella barra
degli strumenti. Il trigger viene eliminato.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
95
Configurazione delle procedure
Una procedura è un oggetto SQL eseguibile che può essere richiamato per
effettuare operazioni comuni.
I tipi di procedure sono i seguenti:
v Procedure SQL, che manipolano i dati presenti in un database ObjectServer
v Procedure esterne, che eseguono un file eseguibile su un sistema locale o remoto
Suggerimento: È possibile creare e modificare procedure dalle finestre di
Netcool/OMNIbus Administrator predefinite oppure da un editor di testo esterno
a propria scelta.
Creazione e modifica di procedure SQL
I principali componenti di una procedura SQL sono i seguenti: parametri,
dichiarazioni di variabili locali e corpo della procedura.
I parametri sono valori che una procedura trasmette o riceve. Occorre dichiarare i
parametri al momento della creazione e specificare quali valori trasmettere come
parametri quando si esegue la procedura.
Le variabili locali vengono dichiarate prima del corpo della procedura e possono
essere utilizzate per definire valori utilizzati quando la procedura viene eseguita.
Per creare o modificare una procedura SQL:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Automation.
2. Fare clic su Procedures. Si apre il riquadro Procedures.
3. Per aggiungere una procedura SQL, fare clic su Add SQL Procedure nella barra
degli strumenti. Si apre la finestra SQL Procedure Details.
4. Per modificare una procedura SQL, selezionare la procedura SQL da
modificare, quindi fare clic su Edit Procedure nella barra degli strumenti. Si
apre la finestra SQL Procedure Details.
5. Completare questa finestra nel modo seguente:
Name Immettere un nome univoco per la procedura. Se si sta modificando
una procedura, non è possibile modificarne il nome.
Suggerimento: Quando si creano oggetti dell’ObjectServer, i relativi
nomi devono iniziare con una lettera maiuscola o minuscola, seguita da
lettere maiuscole o minuscole, numeri o caratteri di sottolineatura (_),
per una lunghezza massima di 40 caratteri. Per i nomi di utenti, gruppi e
ruoli, è possibile specificare qualsiasi stringa di testo che può includere spazi e
la cui lunghezza non deve superare i 64 caratteri. I nomi degli oggetti
dell’ObjectServer rispettano la distinzione maiuscolo/minuscolo.
Parameters
Quest’area visualizza i parametri creati per entrare a far parte della
procedura o esserne esclusi.
È possibile utilizzare le frecce su e giù a destra della casella di elenco
per modificare l’ordine di un qualsiasi parametro selezionato. È
possibile anche fare clic su Remove parameter a destra della casella di
elenco per rimuovere qualsiasi parametro selezionato dall’elenco.
96
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Per creare un parametro, utilizzare i campi In/Out, Name e Data Type,
la casella di spunta Array (se necessario) e il pulsante Add parameter
to the list .
In/Out
Selezionare una modalità per il parametro in corso di creazione.
Ciascun parametro di procedura possiede una modalità, che
può essere in, out, o in out. A seconda della modalità scelta per
i parametri, è possibile utilizzarli secondo modalità differenti.
Name Immettere un nome per il parametro in fase di creazione. I
nomi dei parametri devono essere univoci nella procedura.
Suggerimento: Quando si creano oggetti dell’ObjectServer, i
relativi nomi devono iniziare con una lettera maiuscola o
minuscola, seguita da lettere maiuscole o minuscole, numeri o
caratteri di sottolineatura (_), per una lunghezza massima di 40
caratteri. Per i nomi di utenti, gruppi e ruoli, è possibile specificare
qualsiasi stringa di testo che può includere spazi e la cui lunghezza
non deve superare i 64 caratteri. I nomi degli oggetti
dell’ObjectServer rispettano la distinzione maiuscolo/
minuscolo.
Data Type
Selezionare il tipo di dati che il parametro può trasmettere o
escludere dalla procedura. Il tipo di dati può essere qualsiasi
tipo di dati ObjectServer valido tranne VARCHAR o INCR.
Array Se si seleziona la modalità in dall’elenco a discesa In/Out, è
possibile selezionare questa casella di spunta per trasmettere un
array del tipo di dati nella procedura.
Add parameter to the list
Una volta completati i campi In/Out, Name e Data Type e la
casella di spunta facoltativa Array, fare clic su questo pulsante
per aggiungere il parametro all’elenco di parametri.
Actions
Immettere i comandi SQL per questa procedura. Il corpo di una
procedura contiene una serie di comandi SQL e costrutti di
programmazione che modificano i dati nell’ObjectServer. Il corpo di
una procedura viene racchiuso all’interno delle parole chiave BEGIN e
END. Ciascuna istruzione, tranne l’ultima, deve essere separata da un
punto e virgola (;).
È possibile , se lo si desidera, definire (dichiarare) le variabili locali da
utilizzare in una procedura. Una variabile locale è un segnaposto per i
valori utilizzati durante l’esecuzione della procedura. Le dichiarazioni
della variabile locale in una procedura devono essere separate dai due
punti (;).
È possibile utilizzare i pulsanti dell’helper SQL mostrati a destra del
pannello dell’editor SQL per costruire i comandi SQL.
6. Salvare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per salvare la procedura SQL e chiudere la
finestra. Le nuove procedure SQL vengono aggiunte al pannello
Procedure.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
97
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Operazioni successive
Dopo aver creato una procedura nell’ObjectServer, è possibile eseguirla
dall’interfaccia interattiva SQL (iSQL) oppure in un trigger utilizzando il comando
EXECUTE PROCEDURE.
Riferimenti correlati
“Creazione di procedure SQL (comando CREATE PROCEDURE)” a pagina 185
“Esecuzione di procedure” a pagina 194
“Specifica dei tipi di dati per le colonne” a pagina 133
Appendice B, “Pulsanti helper, espressioni variabili e comandi SQL in strumenti,
automazioni ed elenchi eventi transitori”, a pagina 347
Esempio: Procedura SQL
Questo esempio di procedura SQL genera un report sul numero totale di avvisi
ricevuti (e deduplicati) per un determinato nodo.
Nella finestra SQL Procedure Details, viene creata la procedura SQL node_report
con le seguenti voci:
Tabella 18. Voci per la procedura SQL node_report nella finestra SQL Procedure Details
Campo
Voce
Name
node_report
Parameters
in node_name Char(255)
Questa voce di sola lettura dell’elenco Parameters viene creata da voci specificate nei
campi In/Out, Name, Data Type e Length nell’area Parameters. Ad esempio:
v In/Out: in
v Name: node_name
v Data Type: Char
v Length: 255
Actions
declare
tally_total integer;
begin
set tally_total = 0;
for each row tmprow in alerts.status where tmprow.Node = node_name
begin
set tally_total = tally_total + tmprow.Tally;
end;
write into node_report_file values ( 'Total tally for node ', node_name,
' = ', tally_total );
end
Il comando SQL per creare il file ObjectServer node_report_file e il testo SQL
completo della stessa procedura node_report è il seguente:
create file node_report_file '/tmp/node_report';
create procedure node_report( node_name char(255) )
declare
tally_total integer;
begin
set tally_total = 0;
98
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
for each row tmprow in alerts.status where tmprow.Node = node_name
begin
set tally_total = tally_total + tmprow.Tally;
end;
write into node_report_file values ( 'Total tally for node ', node_name,
' = ', tally_total );
end;
Creazione e modifica di procedure esterne
È possibile creare procedure esterne per eseguire un programma eseguibile su un
sistema locale o remoto.
Per creare o modificare una procedura esterna:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Automation.
2. Fare clic su Procedures. Si apre il riquadro Procedures.
3. Per aggiungere una procedura esterna, fare clic su Add External Procedure
nella barra degli strumenti. Si apre la finestra External Procedure Details.
4. Per modificare una procedura esterna, selezionare la procedura esterna da
modificare, quindi fare clic su Edit Procedure nella barra degli strumenti. Si
apre la finestra External Procedure Details.
5. Completare questa finestra nel modo seguente:
Name Immettere un nome univoco per la procedura. Se si sta modificando
una procedura, non è possibile modificarne il nome.
Suggerimento: Quando si creano oggetti dell’ObjectServer, i relativi
nomi devono iniziare con una lettera maiuscola o minuscola, seguita da
lettere maiuscole o minuscole, numeri o caratteri di sottolineatura (_),
per una lunghezza massima di 40 caratteri. Per i nomi di utenti, gruppi e
ruoli, è possibile specificare qualsiasi stringa di testo che può includere spazi e
la cui lunghezza non deve superare i 64 caratteri. I nomi degli oggetti
dell’ObjectServer rispettano la distinzione maiuscolo/minuscolo.
Parameters
Quest’area visualizza i parametri creati per la procedura. Questi
parametri possono essere variabili del tipo di base, array dei valori del
tipo di base o righe delle tabelle con nome.
È possibile utilizzare le frecce su e giù a destra della casella di elenco
per modificare l’ordine di un qualsiasi parametro selezionato. È
possibile anche fare clic su Remove parameter a destra della casella di
elenco per rimuovere qualsiasi parametro selezionato dall’elenco.
Per creare un parametro, utilizzare i campi In/Out, Name e Data Type,
la casella di spunta Array e il pulsante Add parameter to the list .
In/Out
La modalità in viene selezionata per impostazione predefinita.
Non è possibile modificare questo valore poiché i parametri di
procedura esterna sono sempre parametri IN. È possibile
utilizzare un parametro IN nelle espressioni per consentire il
calcolo di un valore, ma non è possibile assegnare un valore al
parametro.
Name Immettere un nome per il parametro in fase di creazione. I
nomi dei parametri devono essere univoci nella procedura.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
99
Suggerimento: Quando si creano oggetti dell’ObjectServer, i
relativi nomi devono iniziare con una lettera maiuscola o
minuscola, seguita da lettere maiuscole o minuscole, numeri o
caratteri di sottolineatura (_), per una lunghezza massima di 40
caratteri. Per i nomi di utenti, gruppi e ruoli, è possibile specificare
qualsiasi stringa di testo che può includere spazi e la cui lunghezza
non deve superare i 64 caratteri. I nomi degli oggetti
dell’ObjectServer rispettano la distinzione maiuscolo/
minuscolo.
Data Type
Selezionare il tipo di dati che il parametro può trasmettere nella
procedura. Il tipo di dati può essere qualsiasi tipo di dati
ObjectServer valido tranne VARCHAR o INCR.
Array Selezionare questa casella di spunta per trasferire un array del
tipo di dati selezionato nella procedura.
Add parameter to the list
Dopo aver completato i campi In/Out, Name, e Data Type e la
casella di spunta Array, fare clic su questo pulsante per
aggiungere il parametro all’elenco di parametri.
Executable
Immettere il percorso completo per il comando da eseguire. È possibile
fare clic su Browse per consentire l’individuazione e la selezione del
file.
Arguments
Immettere qualsiasi argomento della riga comandi per il comando da
eseguire.
Host
Immettere il nome dell’host su cui eseguire la procedura. Il nome del
computer che ha eseguito l’accesso viene visualizzato per impostazione
predefinita.
User ID
Specificare l’ID utente (UNIX) con il quale eseguire il programma
eseguibile.
Group ID
Specificare l’ID gruppo (UNIX) con il quale eseguire il programma
eseguibile.
6. Salvare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per salvare la procedura esterna e chiudere
la finestra. Le nuove procedure esterne vengono aggiunte al pannello
Procedure.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Operazioni successive
Dopo aver creato una procedura nell’ObjectServer, è possibile eseguirla
dall’interfaccia interattiva SQL (iSQL) oppure in un trigger utilizzando il comando
EXECUTE PROCEDURE.
100
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Nota: Per eseguire una procedura esterna, è necessario che un daemon dell’agent
del controllo processi (nco_pad) sia in esecuzione sull’host sul quale è memorizzato
il file eseguibile.
Concetti correlati
Capitolo 6, “Utilizzo del controllo processi per gestire processi e procedure
esterne”, a pagina 241
Riferimenti correlati
“Specifica dei tipi di dati per le colonne” a pagina 133
“Esecuzione di procedure” a pagina 194
Esempio: Procedura esterna
Questo esempio di procedura esterna richiama un programma che si chiama
nco_mail, che invia e-mail relative ad avvisi critici non riconosciuti.
Nella finestra External Procedure Details, viene creata la procedura esterna
send_email con le seguenti voci:
Tabella 19. Voci per la procedura esterna send_email nella finestra External Procedure
Details
Campo
Voce
Name
send_email
Parameters
in
in
in
in
in
in
node Char(255)
severity Integer
subject Char(255)
email Char(255)
summary Char(255)
hostname Char(255)
Queste voci di sola lettura nell’elenco Parameters vengono create
da voci specificate nei campi In/Out, Name, Data Type e Length
dell’area Parameters. Ad esempio, per in node Char(255), le voci
sono:
v In/Out: in
v Name: node
v Data Type: Char
v Length: 255
Executable
$NCHOME/omnibus/utils/nco_mail
Arguments
’\’’+node+’\’’, severity,’\’’+subject+’\’’,’\’’+email+’\’’,’\
’’+summary+’\’’
Host
localhost
Il testo SQL completo della stessa procedura send_email è il seguente:
create or replace procedure send_email
(in node character(255), in severity integer, in subject character(255),
in email character(255), in summary character(255), in hostname character(255))
executable '$NCHOME/omnibus/utils/nco_mail'
host 'localhost'
user 0
group 0
arguments '\'' + node + '\'', severity, '\'' + subject + '\'',
'\'' + email + '\'', '\'' + summary + '\'';
Inoltre, questo esempio mostra come trasmettere stringhe di testo a un eseguibile.
Le stringhe devono essere racchiuse tra virgolette di cui è necessario eseguire
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
101
l’escape inserendo barre retroverse. Tutte le virgolette contenute in questo esempio
sono virgolette singole.
Utilizzo di un editor esterno per creare e modificare procedure
Da Netcool/OMNIbus Administrator, è possibile configurare un editor di testo
esterno, quindi utilizzarlo per creare o modificare procedure.
Configurazione di un editor esterno per le procedure:
Se necessario, è possibile creare e modificare procedure da un editor esterno a
propria scelta. Come prima cosa, è necessario configurare l’editor che si desidera
utilizzare.
Per configurare un editor esterno:
1. Da Netcool/OMNIbus Administrator, selezionare Tools → Configure Tools. Si
apre la finestra Choose Tool.
2. Selezionare Text Editor. Si apre la finestra External Program.
3. Completare questa finestra nel modo seguente:
Tool name
Questo campo visualizza il tipo di strumento che si sta configurando.
Executable
Immettere il percorso completo e il nome del programma eseguibile per
il tipo di strumento. In alternativa, fare clic sul pulsante a destra del
campo per eseguire la ricerca e selezionare il programma eseguibile.
Arguments
Immettere qualsiasi argomento della riga comandi da eseguire con
questo programma eseguibile.
Run time environment
Selezionare l’ambiente di runtime.
4. Salvare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per salvare i dettagli del programma
esterno e chiudere la finestra.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Attività correlate
“Creazione e modifica di procedure in un editor esterno”
Creazione e modifica di procedure in un editor esterno:
È possibile utilizzare un editor esterno per creare o modificare una procedura SQL
o esterna.
Prima di iniziare
È necessario aver configurato un editor esterno da utilizzare per creare o
modificare procedure.
Per creare o modificare una procedura:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Automation.
102
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
2. Fare clic su Procedures. Si apre il riquadro Procedures.
3. Per creare una procedura, assicurarsi che nessuna riga sia selezionata nel
riquadro Procedures, quindi fare clic su Edit in External Editor nella barra
degli strumenti. È possibile deselezionare una riga premendo il tasto Ctrl,
quindi facendo clic sulla riga. Si apre la finestra di dialogo Select Procedure
Type. Procedere come indicato di seguito:
a. Dall’elenco Procedure Template, selezionare il modello per il tipo di
procedura che si desidera creare. Se si seleziona SQL o External, l’editor
esterno si apre con la sintassi standard per quel tipo di procedura. Se si
seleziona <blank>, l’editor esterno si apre senza visualizzare alcun testo.
b. Completare la sintassi per la procedura. Se si utilizza un modello, sostituire
la variabile procedure_name con un valore effettivo. Inoltre, per una
procedura esterna, sostituire le variabili executableName, hostName, userID e
groupID con valori effettivi. Aggiungere istruzioni o altre dichiarazioni
specifiche della procedura, in base alle specifiche esigenze. Il modello
potrebbe includere commenti (preceduti da --) per l’inserimento di testo.
c. Salvare le voci. Quando si salva, la procedura viene salvata
nell’ObjectServer. Se ci sono errori di sintassi, viene chiesto di caricare di
nuovo il contenuto dell’editor esterno.
d. Chiudere l’editor esterno.
4. Per modificare una procedura, selezionare la procedura da modificare, quindi
fare clic su Edit in External Editor nella barra degli strumenti oppure fare clic
con il tasto destro del mouse e selezionare Edit Procedure in External Editor
dal menu pop up. L’editor esterno si apre con la sintassi della procedura
visualizzata. Procedere come indicato di seguito:
a. Modificare la sintassi della procedura e salvare le modifiche. Quando si
salva, la procedura viene salvata nell’ObjectServer. Se ci sono errori di
sintassi, viene chiesto di caricare di nuovo il contenuto dell’editor esterno.
b. Chiudere l’editor esterno.
Risultati
Suggerimento: L’SQL che si immette in un editor esterno viene salvato
nell’ObjectServer come file .ed. È possibile verificare la validità della sintassi nei
file .ed e in altri file .sql dall’interfaccia interattiva SQL (in esecuzione in modalità
GUI).
Attività correlate
“Configurazione di un editor esterno per le procedure” a pagina 102
“Utilizzo dell’interfaccia interattiva SQL in modalità GUI” a pagina 120
Riferimenti correlati
“Creazione di procedure esterne (comando CREATE PROCEDURE)” a pagina 193
“Creazione di procedure SQL (comando CREATE PROCEDURE)” a pagina 185
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
103
Eliminazione di procedure
Non è possibile eliminare una procedura se utilizzata in un trigger.
Per eliminare una procedura:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Automation.
2. Fare clic su Procedures. Si apre il riquadro Procedures.
3. Selezionare la procedura che si desidera eliminare e fare clic su Delete nella
barra degli strumenti. La procedura viene eliminata.
Configurazione dei segnali
I segnali sono eventi che hanno luogo nell’ObjectServer che possono essere rilevati
o in base ai quali intervenire con una specifica azione. I segnali fanno parte del
sottosistema di automazione.
I tipi di segnali sono i seguenti:
v Segnali di sistema
v Segnali definiti dall’utente
Un ObjectServer genera automaticamente segnali di sistema quando si verificano
determinate variazioni nel sistema; ad esempio, durante l’avvio del sistema o nel
caso di un errore di connessione. Non è possibile creare o modificare questi
segnali. È possibile associare trigger a segnali di sistema per creare risposte
automatiche a incidenti nell’ObjectServer.
I segnali definiti dall’utente sono segnali definiti dall’utente stesso. È possibile
utilizzare Netcool/OMNIbus Administrator per creare segnali definiti dall’utente.
Attività correlate
“Creazione e modifica di trigger di segnale” a pagina 88
Creazione e modifica di segnali definiti dall’utente
A differenza dei segnali di sistema, che sono predefiniti e non possono essere
configurati, i segnali definiti dall’utente devono essere creati o eliminati in maniera
esplicita.
Per creare o modificare un segnale definito dall’utente:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Automation.
2. Fare clic su User Defined Signals. Si apre il riquadro User Defined Signals.
3. Per aggiungere un segnale definito dall’utente, fare clic su Add User Defined
Signal nella barra degli strumenti. Si apre la finestra User Defined Signal
Details.
4. Per modificare un segnale definito dall’utente, selezionare il segnale definito
dall’utente da modificare, quindi fare clic su Edit User Defined Signal nella
barra degli strumenti. Si apre la finestra User Defined Signal Details.
5. Completare questa finestra nel modo seguente:
Signal Name
Immettere un nome univoco per il segnale. Se si sta modificando un
segnale, non è possibile modificarne il nome.
Suggerimento: Quando si creano oggetti dell’ObjectServer, i relativi
nomi devono iniziare con una lettera maiuscola o minuscola, seguita da
104
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
lettere maiuscole o minuscole, numeri o caratteri di sottolineatura (_),
per una lunghezza massima di 40 caratteri. Per i nomi di utenti, gruppi e
ruoli, è possibile specificare qualsiasi stringa di testo che può includere spazi e
la cui lunghezza non deve superare i 64 caratteri. I nomi degli oggetti
dell’ObjectServer rispettano la distinzione maiuscolo/minuscolo.
Comment
Immettere un commento di testo per il segnale. Ad esempio, è possibile
aggiungere un commento per indicare quale trigger viene attivato
quando viene generato il segnale.
Parameters
Quest’area visualizza i parametri che comprendono il segnale definito
dall’utente.
L’ordine in cui vengono visualizzati i parametri deve corrispondere
all’ordine in cui essi vengono visualizzati nel comando RAISE SIGNAL
per il trigger. È possibile utilizzare le frecce su e giù a destra della
casella di elenco per modificare l’ordine di un qualsiasi parametro
selezionato. È possibile anche fare clic su Remove parameter a destra
della casella di elenco per rimuovere qualsiasi parametro selezionato
dall’elenco.
Per creare un parametro, utilizzare i campi Name e Data Type e il
pulsante Add parameter to the list .
Name Immettere un nome per il parametro in fase di creazione. I nomi dei
parametri devono essere univoci all’interno del segnale.
Data Type
Selezionare il tipo di dati che il parametro può trasmettere nel segnale.
Il tipo di dati può essere qualsiasi tipo di dati ObjectServer valido
tranne VARCHAR o INCR.
Data Length
Solo per il tipo di dati Char, immettere la lunghezza del parametro.
Add parameter to the list
Dopo aver completato i campi Name, Data Type, e, se necessario, Data
Length, fare clic su questo pulsante per aggiungere il parametro al
relativo elenco.
6. Salvare o annullare le modifiche nel modo seguente:
Fare clic su questo pulsante per salvare il segnale definito dall’utente e
chiudere la finestra. I nuovi segnali definiti dall’utente vengono
aggiunti al pannello User Defined Signals.
OK
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Risultati
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
105
Esempio: Segnale definito dall’utente e trigger
Questo esempio mostra il segnale definito dall’utente chiamato illegal_delete e il
trigger di database DETECT_AN_ILLEGAL_DELETE in cui viene utilizzato. Il trigger di
database utilizza il segnale per il trap di eliminazioni che hanno luogo al di fuori
del normale orario di ufficio.
Nella finestra User Defined Signal Details, il segnale definito dall’utente
illegal_delete viene creato con le seguenti voci:
Tabella 20. Voci per il segnale definito dall’utente illegal_delete nella finestra User Defined
Signal Details
Campo
Voce
Signal Name
illegal_delete
Comment
Da utilizzare con il trigger DETECT_AN_ILLEGAL_DELETE.
Parameters
user_name Char(20)
row_summary Char(20)
Queste voci di sola lettura nell’elenco Parameters vengono create
da voci specificate nei campi Name, Data Type e Data Length
nell’area Parameters. Ad esempio, per user_name Char(20), le voci
sono:
v Name: user_name
v Data Type: Char
v Data Length: 20
Nel seguente testo SQL per il trigger di database di pre-inserimento
DETECT_AN_ILLEGAL_DELETE, il comando raise signal è riportato in grassetto:
create trigger DETECT_AN_ILLEGAL_DELETE
group default_triggers
priority 1
before delete on alerts.status
for each row
begin
if( ( (hourofday() > 17) and (minuteofhour() > 30) ) or (hourofday() < 9) ) then
raise signal ILLEGAL_DELETE %user.user_name, old.Summary;
cancel;
end if;
end;
Questo trigger attiva il segnale definito dall’utente illegal_delete. Normalmente,
il segnale prodotto viene quindi rilevato e viene intrapresa l’azione necessaria, ad
esempio da un altro trigger.
Eliminazione di segnali definiti dall’utente
Non è possibile eliminare un segnale definito dall’utente se utilizzato da un trigger
di segnale.
Per eliminare un segnale definito dall’utente:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Automation.
2. Fare clic su User Defined Signals. Si apre il riquadro User Defined Signals.
3. Selezionare il segnale definito dall’utente che si desidera eliminare e fare clic su
Delete nella barra degli strumenti. Il segnale definito dall’utente viene
eliminato.
106
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Configurazione dell’aspetto dell’elenco eventi
Conversioni, colori, visuali di colonne e classi determinano il modo in cui le
informazioni degli avvisi vengono visualizzate nell’elenco eventi.
Creazione e modifica di conversioni
Le conversioni sono associate alle colonne della tabella alerts.status
dell’ObjectServer e associano valori interi per le colonne a stringhe. Le conversioni
configurate in Netcool/OMNIbus Administrator vengono utilizzate nell’elenco
eventi per convertire valori interi in stringhe per assicurarne la leggibilità.
Ad esempio, per le severità degli eventi esistono conversioni predefinite. Se un
evento presenta una severità 4, nell’elenco eventi viene visualizzato il testo Major
per la severità di questo evento.
Per creare o modificare una conversione:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Visual.
2. Fare clic su Conversions. Si apre il riquadro Conversions.
Per visualizzare le conversioni esistenti per una colonna, fare doppio clic sul
nome della colonna. È anche possibile fare clic sul simbolo a forma di cerchio
(su UNIX) o sul simbolo più (+) (su Windows) che si trova alla sinistra del
nome della colonna.
3. Per aggiungere una conversione, fare clic su Add Conversion nella barra degli
strumenti. Si apre la finestra Conversion Details.
4. Per modificare una conversione, selezionare la conversione che si desidera
modificare, quindi fare clic su Edit Conversion nella barra degli strumenti. Si
apre la finestra Conversion Details.
5. Completare questa finestra nel modo seguente:
Column
Selezionare il nome della colonna che contiene i dati da convertire.
Value Specificare il valore interno da convertire.
Conversion
Immettere la stringa per visualizzare il valore.
6. Salvare o annullare le modifiche nel modo seguente:
Fare clic su questo pulsante per salvare la conversione e chiudere la
finestra. Le nuove conversioni vengono aggiunte al pannello
Conversions.
OK
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
107
Eliminazione di conversioni
Per eliminare una conversione:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Visual.
2. Fare clic su Conversions. Si apre il riquadro Conversions.
3. Selezionare la conversione che si desidera eliminare e fare clic su Delete nella
barra degli strumenti. La conversione viene eliminata.
Creazione e modifica dei colori per la severità degli eventi per
elenchi eventi Windows
Negli elenchi eventi vengono utilizzati colori diversi per indicare i vari livelli di
severità degli eventi. È possibile visualizzare, creare e modificare i colori per la
severità utilizzati negli elenchi eventi Windows. È possibile selezionare colori
diversi per gli avvisi riconosciuti e per quelli non riconosciuti.
Per creare o modificare i colori per la severità degli eventi negli elenchi eventi
Windows:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Visual.
2. Fare clic su Colors. Si apre il riquadro Colors.
3. Per aggiungere un colore per la severità, fare clic su Add Color Definition
nella barra degli strumenti. Si apre la finestra Color Details.
4. Per modificare un colore per la severità, selezionare il colore da modificare,
quindi fare clic su Edit Color Definition nella barra degli strumenti. Si apre la
finestra Color Details.
5. Completare questa finestra nel modo seguente:
Severity
Se si sta creando un nuovo colore, specificare il valore della severità
degli avvisi.
Conversion
Questo campo visualizza la conversione di questa severità degli avvisi
(se ne esiste una). Le conversioni vengono utilizzate per tradurre valori
interi in stringhe per la leggibilità. Ad esempio, la conversione
predefinita per una severità pari a 4 è Major.
Unacknowledged
Quest’area visualizza il colore per la severità degli avvisi quando non
viene riconosciuto nell’elenco eventi. I colori predefiniti della severità
degli avvisi per gli avvisi non riconosciuti sono:
v 0 - Green
v 1 - Violet
v 2 - Blue
v 3 - Yellow
v 4 - Orange
v 5 - Red
Fare clic sul pulsante Show color picker per selezionare il colore
relativo agli avvisi non riconosciuti di questa severità. Dalla finestra di
dialogo Color Picker che ne risulta, scegliere un colore mediante i
relativi valori dei campioni, HSB e RGB e poi fare clic su OK.
108
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Acknowledged
Quest’area visualizza il colore per la severità degli avvisi quando viene
riconosciuto nell’elenco eventi. I colori predefiniti della severità degli
avvisi per gli avvisi riconosciuti sono:
v 0 - Dark Green
v 1 - Dark Violet
v 2 - Dark Blue
v 3 - Dark Yellow
v 4 - Dark Orange
v 5 - Dark Red
Fare clic sul pulsante Show color picker per selezionare il colore
relativo agli avvisi riconosciuti di questa severità. Dalla finestra di
dialogo Color Picker che ne risulta, scegliere un colore mediante i
relativi valori dei campioni, HSB e RGB e poi fare clic su OK.
6. Salvare o annullare le modifiche nel modo seguente:
Fare clic su questo pulsante per salvare i dettagli del colore e chiudere
la finestra. I nuovi colori di severità vengono aggiunti al pannello
Colors.
OK
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Creazione e modifica di visuali di colonne
L’aspetto visivo dell’elenco eventi è definito dalle impostazioni delle visuali di
colonne. Per ciascuna colonna nell’elenco eventi, è possibile impostare il testo del
titolo, la larghezza massima e quella predefinita, nonché l’allineamento del titolo e
dei dati.
Per creare o modificare una visuale di colonna:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Visual.
2. Fare clic su Column Visuals. Si apre il riquadro Column Visuals.
3. Per aggiungere una visuale di colonna, fare clic su Add Column Visual nella
barra degli strumenti. Si apre la finestra Column Visual Details.
4. Per modificare una visuale di colonna, selezionare la visuale di colonna da
modificare, quindi fare clic su Edit Column Visual nella barra degli strumenti.
Si apre la finestra Column Visual Details.
5. Completare questa finestra nel modo seguente:
Column
Se si sta creando un elemento visivo di una nuova colonna, selezionare
la colonna per la quale si sta aggiungendo l’elemento visivo.
Immettere il titolo che si desidera visualizzare come intestazione della
colonna negli elenchi eventi di Tivoli Netcool/OMNIbus.
Title
Default
Specificare la lunghezza predefinita della colonna (in caratteri).
Maximum
Specificare la larghezza massima della colonna (in caratteri).
Title
Selezionare l’allineamento del titolo della colonna.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
109
Column
Selezionare l’allineamento delle informazioni presenti nella colonna.
6. Salvare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per salvare i dettagli dell’elemento visivo
della colonna e chiudere la finestra. Gli elementi visivi delle nuove
colonne vengono aggiunti al pannello Column Visuals.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Eliminazione di visuali di colonne
Per eliminare una visuale di colonna:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Visual.
2. Fare clic su Column Visuals. Si apre il riquadro Column Visuals.
3. Selezionare la visuale di colonna che si desidera eliminare e fare clic su Delete
nella barra degli strumenti. La visuale di colonna viene eliminata.
Creazione e modifica di classi
Gli eventi nell’ObjectServer dispongono di una classe che viene assegnata dal
probe. Ciascuna classe può essere associata a un menu dello strumento elenco
eventi che contiene strumenti utili per gli eventi di quella classe.
Per creare o modificare una classe:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Visual.
2. Fare clic su Classes. Si apre il riquadro Classes.
3. Per aggiungere una classe, fare clic su Add Class nella barra degli strumenti. Si
apre la finestra Class Details.
4. Per modificare una classe, selezionare la classe da modificare, quindi fare clic
su Edit Class nella barra degli strumenti. Si apre la finestra Class Details.
5. Completare questa finestra nel modo seguente:
Identifier
Se si sta creando una nuova classe, specificare l’identificativo della
classe. Il probe assegna un identificativo classe agli avvisi
nell’ObjectServer.
IBM definisce gli identificativi della classe per particolari tipi di
dispositivi. Se si desidera riservare una serie di classi del tipo di
dispositivo, contattare il supporto IBM. È disponibile anche
un’intervallo da 88000 a 89000 riservata agli utenti, a disposizione di
tutti i clienti.
Name Immettere un’etichetta per il tipo di dispositivo da associare al numero
della classe.
6. Salvare o annullare le modifiche nel modo seguente:
OK
110
Fare clic su questo pulsante per salvare i dettagli della classe e chiudere
la finestra. Le nuove classi vengono aggiunte al pannello Classes.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Eliminazione di classi
Per eliminare una classe:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Visual.
2. Fare clic su Classes. Si apre il riquadro Classes.
3. Selezionare la classe che si desidera eliminare e fare clic su Delete nella barra
degli strumenti. La classe viene eliminata.
Configurazione di database, file, proprietà, connessioni e canali
ObjectServer
È possibile configurare i seguenti componenti di sistema ObjectServer: strutture di
database, file, proprietà, connessioni e canali ObjectServer.
Un database è una raccolta strutturata di dati organizzata in modo da consentire
un rapido accesso alle informazioni richieste. Un database relazionale utilizza
tabelle come contenitori logici per archiviare questi dati in righe e colonne.
Un file ObjectServer fornisce un modo per registrare o riportare informazioni sugli
eventi ObjectServer.
Le proprietà ObjectServer controllano il funzionamento dell’ObjectServer.
Le connessioni all’ObjectServer possono essere visualizzate e gestite.
I canali vengono utilizzati per definire il tipo di dati evento da trasmettere in
notifiche eventi accelerati e i destinatari dei dati.
Concetti correlati
Capitolo 5, “Configurazione della notifica eventi accelerati”, a pagina 231
Configurazione dei database
La configurazione dei database comporta la creazione e la gestione di tabelle di
database e delle colonne contenute nelle tabelle.
È possibile creare ed eliminare database, nonché creare, eliminare e modificare
tabelle di database e le relative colonne.
Limitazione: Non è possibile apportare modifiche ai database di sistema. Infatti, in
Netcool/OMNIbus Administrator, accanto ai database di sistema è visualizzata
un’icona che raffigura un lucchetto.
Concetti correlati
“Database inizializzati dal sistema” a pagina 131
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
111
Creazione di database
È possibile utilizzare Netcool/OMNIbus Administrator per creare e gestire
database ObjectServer.
Per creare un database ObjectServer:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic su Databases. Si apre il riquadro Databases, Tables and Columns.
È possibile visualizzare e configurare informazioni di tabella e di colonna per
ciascuno dei database non di sistema non elencati. Utilizzare la scheda Data
View per visualizzare i dati contenuti nella tabella. Utilizzare la scheda
Column Definitions per visualizzare informazioni relative alle colonne di
tabella, ad esempio i tipi di dati e gli attributi.
Per aggiornare qualsiasi tipo di informazione visualizzata, fare clic sull’icona
relativa alla tabella o al database selezionato al momento, oppure fare clic sul
pulsante della barra degli strumenti Refresh.
3. Dalla barra degli strumenti, fare clic su Create Database. Si apre la finestra
Database Details.
4. Completare questa finestra nel modo seguente:
Name Immettere un nome univoco per il database.
Suggerimento: Quando si creano oggetti dell’ObjectServer, i relativi
nomi devono iniziare con una lettera maiuscola o minuscola, seguita da
lettere maiuscole o minuscole, numeri o caratteri di sottolineatura (_),
per una lunghezza massima di 40 caratteri. Per i nomi di utenti, gruppi e
ruoli, è possibile specificare qualsiasi stringa di testo che può includere spazi e
la cui lunghezza non deve superare i 64 caratteri. I nomi degli oggetti
dell’ObjectServer rispettano la distinzione maiuscolo/minuscolo.
OK
Fare clic su questo pulsante per salvare il database e chiudere la
finestra. I nuovi database vengono aggiunti all’ObjectServer e al
pannello Databases, Tables and Columns.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Operazioni successive
È ora possibile aggiungere tabelle al database.
Attività correlate
“Creazione di tabelle”
Creazione di tabelle
Una tabella presenta un numero fisso di colonne, ciascuna delle quali contiene un
determinato tipo di dati. Il nome di ogni singola colonna è univoco per la tabella.
Una tabella contiene zero o più righe di dati nel formato definito dall’elenco di
colonne della tabella. Il nome completo della tabella include il nome del database e
il nome della tabella, separati da un punto.
Ad esempio, la tabella status nel database degli avvisi è identificata come
alerts.status.
Per creare una tabella:
112
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic su Databases. Si apre il riquadro Databases, Tables and Columns.
3. Selezionare il database in cui creare la tabella.
4. Dalla barra degli strumenti, fare clic su Create Table. Si apre la finestra Table
Details.
5. Completare questa finestra nel modo seguente:
Name Immettere il nome della tabella.
Suggerimento: Quando si creano oggetti dell’ObjectServer, i relativi
nomi devono iniziare con una lettera maiuscola o minuscola, seguita da
lettere maiuscole o minuscole, numeri o caratteri di sottolineatura (_),
per una lunghezza massima di 40 caratteri. Per i nomi di utenti, gruppi e
ruoli, è possibile specificare qualsiasi stringa di testo che può includere spazi e
la cui lunghezza non deve superare i 64 caratteri. I nomi degli oggetti
dell’ObjectServer rispettano la distinzione maiuscolo/minuscolo.
Selezionare uno dei seguenti tipi di tabella:
Type
v Persistent: Quando viene riavviato l’ObjectServer, viene ricreata una
tabella persistente con tutti i dati.
v Virtual: Quando viene riavviato l’ObjectServer, viene ricreata una
tabella virtuale con la stessa descrizione della tabella ma senza dati.
Table area
Quest’area elenca i dettagli per tutte le colonne della tabella. È possibile
utilizzare le frecce su e giù a destra per modificare l’ordine di una
colonna selezionata nella tabella.
Add column
Fare clic su questo pulsante se si desidera aggiungere una nuova
colonna alla tabella. Si apre la finestra Column Details. Completare
questa finestra e salvare le modifiche.
Quando si ritorna alla finestra Table Details, viene aggiunta la nuova
colonna al relativo elenco.
Edit column
Fare clic su questo pulsante se si desidera modificare i dettagli di una
colonna selezionata. Si apre la finestra Column Details. Modificare i
dettagli e salvare le modifiche.
Quando si ritorna alla finestra Table Details, gli aggiornamenti ai
dettagli della colonna vengono riportati nell’elenco delle colonne.
Delete column
Fare clic su questo pulsante se si desidera eliminare una colonna
selezionata dalla tabella. Non è richiesta alcuna conferma per
l’eliminazione.
6. Salvare o annullare le modifiche nel modo seguente:
Fare clic su questo pulsante per salvare i dettagli della tabella e
chiudere la finestra. Vengono aggiunte nuove tabelle al pannello
Databases, Tables and Columns.
OK
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
113
Risultati
Suggerimento: È possibile utilizzare la scheda Data View della finestra Databases,
Tables and Columns per visualizzare dati di tabelle, nonché utilizzare la scheda
Column Definitions per visualizzare informazioni dettagliate sulle colonne nella
tabella.
Attività correlate
“Aggiunta e modifica di colonne di tabella”
Aggiunta e modifica di colonne di tabella
Per aggiungere o modificare una colonna di tabella:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic su Databases. Si apre il riquadro Databases, Tables and Columns.
3. Selezionare la tabella in cui si desidera aggiungere o modificare la colonna.
4. Fare clic sulla scheda Column Definitions.
5. Per aggiungere una colonna, fare clic su Add Column nella barra degli
strumenti. Si apre la finestra Column Details.
6. Per modificare una colonna, selezionare la colonna da modificare, quindi fare
clic su Edit Column nella barra degli strumenti. Si apre la finestra Column
Details.
7. Completare questa finestra nel modo seguente:
Column Name
Immettere il nome della colonna. Se si sta modificando una colonna, è
impossibile modificarne il nome.
Suggerimento: Quando si creano oggetti dell’ObjectServer, i relativi
nomi devono iniziare con una lettera maiuscola o minuscola, seguita da
lettere maiuscole o minuscole, numeri o caratteri di sottolineatura (_),
per una lunghezza massima di 40 caratteri. Per i nomi di utenti, gruppi e
ruoli, è possibile specificare qualsiasi stringa di testo che può includere spazi e
la cui lunghezza non deve superare i 64 caratteri. I nomi degli oggetti
dell’ObjectServer rispettano la distinzione maiuscolo/minuscolo.
Data Type
Selezionare un tipo di dati per la colonna. Il tipo di dati determina le
modalità con cui l’ObjectServer elabora i dati nella colonna. Se si sta
modificando la colonna, è impossibile modificare il tipo di dati. È
possibile effettuare la selezione tra i seguenti tipi di dati:
v Integer: Numero intero con segno a 32 bit
v UTC: Ora memorizzata sotto forma di numero di secondi dalla
mezzanotte del 1 gennaio 1970
v VarChar: Stringa di caratteri a dimensione variabile, fino a 8192 byte
di lunghezza
v Incr: Numero intero auto incrementale senza segno a 32 bit che può
essere aggiornato solo dal sistema
v Char: Stringa di caratteri a dimensione fissa fino a 8192 byte di
lunghezza
v Unsigned: Numero intero senza segno a 32 bit
v Boolean: TRUE o FALSE
v Real: Numero con virgola mobile con segno a 64 bit
114
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
v Integer64: Numero intero con segno a 64 bit
v Unsigned64: Numero intero senza segno a 64 bit
Length
Questo campo è disponibile solo quando si seleziona VarChar o Char
dall’elenco Data Type. Specificare la lunghezza della colonna.
Primary Key
Selezionare questa casella di spunta per indicare che la colonna è una
chiave primaria. La colonna o le colonne della chiave primaria
identificano in modo univoco ciascuna riga. Una colonna della chiave
primaria deve avere un valore predefinito.
No Modify
Selezionare questa casella di spunta per indicare che gli utenti non
possono modificare i dati in questa colonna.
No Default
Selezionare questa casella di spunta per indicare che si deve specificare
un valore per qualsiasi colonna in qualsiasi comando INSERT.
8. Salvare o annullare le modifiche nel modo seguente:
Apply Se si desidera aggiungere più colonne senza uscire dalla finestra
Column Details, fare clic su questo pulsante per salvare i dettagli della
colonna dopo l’aggiunta di ogni serie di voci.
Una volta immessi i valori per l’ultima colonna che si desidera
aggiungere attualmente, fare clic su questo pulsante per salvare i
dettagli della colonna e chiudere la finestra. Vengono aggiunte nuove
colonne al pannello Databases, Tables and Columns.
OK
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Risultati
Nota: Il numero massimo di colonne in una tabella è 512, ad eccezione delle
colonne gestite dal sistema. La dimensione massima di una riga per una tabella,
data dalla somma della lunghezza delle colonne nella riga, è 64 KB.
Suggerimento: È possibile utilizzare la scheda Data View della finestra Databases,
Tables and Columns per visualizzare i dati delle tabelle.
Eliminazione di database
Non è possibile eliminare i database di sistema, accanto ai quali è visualizzata
un’icona che raffigura un lucchetto.
Attenzione: Quando si elimina un database che contiene dati di tabelle, le tabelle
vengono dapprima svuotate, poi eliminate.
Per eliminare un database:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic su Databases. Si apre il riquadro Databases, Tables and Columns.
3. Selezionare il database che si desidera eliminare e fare clic su Drop Database
nella barra degli strumenti. Il database viene rimosso dall’ObjectServer.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
115
Eliminazione di tabelle
Non è possibile eliminare le tabelle dei database di sistema.
Per eliminare una tabella:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic su Databases. Si apre il riquadro Databases, Tables and Columns.
3. Selezionare il database che contiene la tabella da eliminare.
4. Selezionare la tabella che si desidera eliminare e fare clic su Drop Table nella
barra degli strumenti. Tutti i dati vengono rimossi dalla tabella, dopo di che la
tabella viene eliminata dal database.
Eliminazione di colonne di tabella
Non è consentito eliminare le colonne chiave primaria o le colonne delle tabelle di
sistema.
Attenzione: L’eliminazione di una colonna richiede l’esecuzione di un numero
considerevole di azioni preliminari per identificare e rimuovere eventuali
dipendenze esterne dalla colonna. Questo processo comporta la ricerca di
riferimenti alla colonna nei trigger, nelle procedure, nelle viste, nei filtri limitazioni,
nei file delle regole di probe e nei file delle associazioni di gateway. Inoltre, è bene
ricordare che se si elimina una colonna da cui dipendono trigger, procedure, viste
o filtri limitazioni, vengono eliminati anche questi oggetti dipendenti e
un’avvertenza viene scritta nel file di log dell’ObjectServer.
Per eliminare una tabella di colonna dopo aver verificato che non esistono
dipendenze esterne:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic su Databases. Si apre il riquadro Databases, Tables and Columns.
3. Selezionare la tabella contenente la colonna da eliminare.
4. Fare clic sulla scheda Column Definitions.
5. Selezionare la colonna che si desidera eliminare e fare clic su Drop Column
nella barra degli strumenti. La colonna viene rimossa dalla tabella.
Riferimenti correlati
“Eliminazione di una colonna” a pagina 137
Visualizzazione e modifica delle proprietà ObjectServer
Le proprietà ObjectServer consentono di determinare il funzionamento
dell’ObjectServer. È possibile visualizzare e modificare proprietà ObjectServer
utilizzando Netcool/OMNIbus Administrator. Non è possibile aggiungere
proprietà ObjectServer; è unicamente possibile modificare quelle esistenti.
L’ubicazione predefinita del file delle proprietà ObjectServer è
$NCHOME/omnibus/etc/servername.props. L’ObjectServer legge il file delle proprietà
al suo avvio.
Importante: È necessario avere dimestichezza con le proprietà ObjectServer per
poterle modificare. Una configurazione errata può influire negativamente sulle
prestazioni e sulla funzionalità del sistema.
Per modificare il valore di una proprietà ObjectServer:
116
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic su Properties. Si apre il riquadro ObjectServer Properties.
Suggerimento: Le proprietà di sola lettura presentano il testo false nella
colonna Editable.
3. Per modificare una proprietà, selezionare la colonna da modificare, quindi fare
clic su Edit Property nella barra degli strumenti. Si apre la finestra Property
Details.
4. Completare questa finestra nel modo seguente:
Name Il nome univoco allocato alla proprietà ObjectServer viene visualizzata
qui. Non è possibile modificare questo valore.
Description
Una descrizione della proprietà ObjectServer viene visualizzata qui.
Non è possibile modificare questo valore.
Value Modificare il valore della proprietà in base alle esigenze.
5. Salvare o annullare le modifiche nel modo seguente:
Fare clic su questo pulsante per salvare i dettagli della proprietà e
chiudere la finestra. Il valore aggiornato viene riportato nel pannello
ObjectServer Properties.
OK
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Risultati
Suggerimento: Le modifiche apportate ad alcune proprietà dell’ObjectServer
diventano effettive solo dopo aver riavviato l’ObjectServer. Queste proprietà
presentano il testo false nel colonna Immediate.
Riferimenti correlati
“Proprietà e opzioni della riga comandi dell’ObjectServer” a pagina 3
Configurazione dei file ObjectServer
I file ObjectServer sono oggetti di archiviazione definiti dagli utenti, che
contengono dati di log o di report.
Un file ObjectServer è un file logico al quale corrispondono uno o più file (serie di
file) sul file system fisico. È possibile definire le dimensioni dei file ObjectServer e
il numero di file fisici in una serie.
Sequenza di creazione dei file ObjectServer
Ciascun file di una serie di file viene indicato da un numero accodato al nome file
(o all’estensione file, se presente).
Ad esempio, se si crea un file denominato logfile nella directory /log e si
specifica che la sua dimensione massima è 20 KB e che il numero massimo di file
nella serie è 3, viene creata e utilizzata la seguente sequenza di file:
1. Quando si fa clic su OK per creare il file, l’ObjectServer crea un file vuoto
denominato logfile1 nella directory /log.
2. L’ObjectServer scrive i dati nel file logfile1 fino a quando il file non supera la
dimensione file massima (20 KB).
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
117
3. L’ObjectServer rinomina logfile1 in logfile2. Successivamente, crea un nuovo
file logfile1 e scrive in questo file fino a quando il file non supera la
dimensione massima.
4. L’ObjectServer rinomina il file logfile2 in logfile3 e rinomina il file logfile1
in logfile2. Successivamente, crea un nuovo file logfile1 e scrive in questo
file fino a quando il file non supera la dimensione massima.
5. L’ObjectServer elimina il file meno recente (logfile3). Successivamente,
rinomina logfile2 in logfile3 e rinomina logfile1 in logfile2. Crea un
nuovo file denominato logfile1 e scrive in questo file fino a quando il file in
questione non supera la dimensione massima.
Questa sequenza si ripete fino a quando il file non viene modificato o rimosso.
Creazione e modifica di file ObjectServer
Un file ObjectServer fornisce un modo per registrare o riportare informazioni sugli
eventi ObjectServer.
Ad esempio, è possibile creare un trigger che scriva una voce in un file
ObjectServer ogni volta che un utente stabilisce una connessione a un ObjectServer.
Per creare o modificare un file ObjectServer:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic su Log Files. Si apre il riquadro Log Files.
3. Per aggiungere un file, fare clic su Add Log File nella barra degli strumenti. Si
apre la finestra File Details.
4. Per modificare i dettagli di un file, selezionare il file da modificare, quindi fare
clic su Edit Log File nella barra degli strumenti. Si apre la finestra File Details.
5. Completare questa finestra nel modo seguente:
Name Immettere un nome univoco per il file ObjectServer; ad esempio, un
nome che fornisca un significato sull’utilizzo. Si noti che questo non è il
nome file come se fosse creato sul file system; a tale scopo, utilizzare il
campo Full File Path. Se si sta modificando un file, non è possibile
modificarne il nome.
Suggerimento: Quando si creano oggetti dell’ObjectServer, i relativi
nomi devono iniziare con una lettera maiuscola o minuscola, seguita da
lettere maiuscole o minuscole, numeri o caratteri di sottolineatura (_),
per una lunghezza massima di 40 caratteri. Per i nomi di utenti, gruppi e
ruoli, è possibile specificare qualsiasi stringa di testo che può includere spazi e
la cui lunghezza non deve superare i 64 caratteri. I nomi degli oggetti
dell’ObjectServer rispettano la distinzione maiuscolo/minuscolo.
Full File Path
Immettere il percorso completo e il nome file del file fisico; ad esempio,
/opt/netcool/omnibus/log/status.log.
Nota: Un numero viene automaticamente accodato al nome file sul file
system.
Enabled
Selezionare questa casella di spunta per attivare il file ObjectServer. Se
non viene attivato, il file esisterà sul file system, ma non è possibile
scrivervi. È possibile specificare le informazioni del file ObjectServer e
quindi attivarlo in un secondo momento.
118
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Unlimited File Size
Selezionare questa casella di spunta se si desidera che le informazioni
vengano scritte in un singolo file con una dimensione illimitata. Se si
sceglie questa impostazione, i campi Max. Size e Max. Files non
vengono visualizzati nella finestra.
Quando questa casella di spunta non è selezionata, le informazioni
possono essere scritte in un singolo file o in un pool di file in cui in
ciascuno si scriverà singolarmente al raggiungimento della dimensione
massima specificata. Se si sceglie questa impostazione, si devono
specificare i valori associati nei campi Max. Size e Max. Files.
Truncate
Fare clic su questo pulsante per cancellare tutte le informazioni scritte
nel file fisico. Questa operazione non elimina il file. Nelle situazioni in
cui esistono più file fisici in una serie, viene troncato solo il file in cui
attualmente si sta scrivendo sul file system.
Nota: Questo pulsante è visibile solo quando si stanno modificando i
dettagli del file.
Max. Size
Specificare la dimensione massima del file ObjectServer e quindi
selezionare un’unità di misurazione. La dimensione minima del file è di
1 KB e quella massima è di 4 GB.
Nota: È possibile che il sistema operativo imponga ulteriori limitazioni
sulla dimensione massima di un singolo file.
Max. Files
Il numero massimo di file ObjectServer da creare.
6. Salvare o annullare le modifiche nel modo seguente:
Fare clic su questo pulsante per salvare i dettagli del file e chiudere la
finestra. I nuovi dettagli del file vengono aggiunti al pannello Log Files.
OK
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Concetti correlati
“Sequenza di creazione dei file ObjectServer” a pagina 117
Eliminazione di file ObjectServer
Non è possibile eliminare un file se utilizzato, ad esempio, in un trigger.
Per eliminare un file ObjectServer:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic su Log Files. Si apre il riquadro Log Files.
3. Selezionare il file ObjectServer che si desidera eliminare e fare clic su Delete
nella barra degli strumenti. Il file ObjectServer viene eliminato. L’ObjectServer
non scriverà più informazioni in questo file.
Risultati
Quando si elimina un file, si elimina solo il file ObjectServer; i file fisici creati nel
file system non vengono rimossi.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
119
Monitoraggio delle connessioni all’ObjectServer
È possibile visualizzare tutte le connessioni correnti all’ObjectServer e disconnettere
una o più di queste connessioni. Per disconnettere una connessione
all’ObjectServer, è necessario disporre dell’autorizzazione ALTER SYSTEM DROP
CONNECTION.
Per visualizzare e disconnettere connessioni all’ObjectServer:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic su Connections. Si apre il riquadro ObjectServer Connections, in cui è
riportata una riga di informazioni per ciascuna applicazione attualmente
connessa all’ObjectServer.
3. Selezionare le righe relative alle applicazioni che si desidera disconnettere. È
possibile utilizzare il tasto Maiusc per selezioni consecutive oppure il tasto Ctrl
per selezioni non consecutive.
4. Fare clic su Disconnect nella barra degli strumenti. Viene richiesto di volta in
volta di confermare la disconnessione per ciascuna delle applicazioni
selezionate.
5. Fare clic su Yes per ciascuna applicazione da disconnettere oppure fare clic su
No per annullare una disconnessione.
Attività correlate
“Visualizzazione delle connessioni utente all’ObjectServer” a pagina 70
Configurazione di canali
Il sistema AEN (Accelerated Event Notification) consente di accelerare gli eventi
con priorità alta per garantire che l’esecuzione dei sistemi possa continuare senza
interruzione. Utilizzare canali per definire il tipo di evento dati da includere nelle
notifiche eventi dati accelerati e i destinatari di questi dati evento.
Concetti correlati
Capitolo 5, “Configurazione della notifica eventi accelerati”, a pagina 231
“Configurazione di canali per trasmettere dati evento” a pagina 233
Attività correlate
“Creazione e modifica di canali” a pagina 234
“Operazioni di copia e incolla sui canali” a pagina 237
“Eliminazione di un canale” a pagina 237
“Invio di messaggi ai destinatari dei canali” a pagina 238
“Disconnessione dei client AEN (Accelerated Event Notification)” a pagina 238
“Arresto dei client AEN (Accelerated Event Notification)” a pagina 239
Utilizzo dell’interfaccia interattiva SQL in modalità GUI
È possibile utilizzare l’interfaccia interattiva SQL per configurare l’ObjectServer
inoltrando comandi SQL.
Nota: Solo gli utenti che sono membri di un gruppo cui è stato assegnato il ruolo
ISQL possono accedere a un ObjectServer utilizzando l’interfaccia interattiva SQL.
Solo gli utenti che sono membri di un gruppo cui è stato assegnato il ruolo
ISQLWrite possono aggiornare i dati di un ObjectServer utilizzando l’interfaccia
interattiva SQL.
Per aprire l’interfaccia interattiva SQL in modalità GUI:
120
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic su SQL. Si apre il riquadro SQL.
3. Completare questa finestra nel modo seguente:
Editor SQL
Utilizzare il campo di testo e i pulsanti in quest’area per immettere i
comandi. Immettere SQL nel campo di testo e utilizzare un punto e
virgola per separare più comandi. È possibile utilizzare i pulsanti
dell’helper SQL e quelli aggiuntivi per agevolare la creazione di
comandi SQL.
Quando si immettono dei comandi SQL all’interno dei pannelli
dell’editor SQL di Tivoli Netcool/OMNIbus, è possibile immettere uno
o più caratteri e successivamente premere Ctrl+F1 per ottenere una
finestra di dialogo con un elenco di parole chiave che potrebbero
corrispondere alla voce utilizzata. Selezionare la parola chiave richiesta
e fare clic su OK per completare la voce. Se una sola parola chiave
corrisponde ai caratteri immessi, la parola chiave viene completata
automaticamente. Se si preme Ctrl+F1 dopo l’immissione di una parola
chiave correlata al database, la finestra di dialogo fornisce un elenco di
possibili database ObjectServer da cui è possibile effettuare una
selezione. Se si preme Ctrl+F1 dopo l’immissione di un nome database
seguito da un punto (ad esempio: alerts.), è possibile premere di
nuovo Ctrl+F1 per visualizzare e effettuare una selezione da un elenco
di tabelle del database.
La seguente tabella descrive i pulsanti dell’helper.
Tabella 21. Pulsanti dell’interfaccia interattiva SQL
Pulsante
Descrizione
Fare clic su questo pulsante per selezionare un comando SQL
dal menu pop-up. In base al comando selezionato, completare
la finestra risultante nel modo seguente:
v Seleziona: selezionare il database e la tabella su cui eseguire
il comando SELECT. Quindi, scegliere le colonne di tabella da
selezionare.
v Inserisci: selezionare il database e la tabella su cui eseguire il
comando INSERT. Quindi, selezionare le colonne di tabella in
cui inserire dei valori. Per ciascuna colonna selezionata,
immettere il valore da inserire. Per istruzioni insert, è
necessario includere la chiave primaria. Le chiavi primarie
sono indicate da un asterisco (*).
v Aggiorna: selezionare il database e la tabella su cui eseguire
il comando. Quindi, selezionare le colonne di tabella da
aggiornare. Per ciascuna colonna selezionata, immettere il
nuovo valore. Per istruzioni update, è necessario escludere la
chiave primaria. Le chiavi primarie sono indicate da un
asterisco (*).
Nota: Per inserimenti e aggiornamenti alla tabella
alerts.status, le eventuali conversioni esistenti vengono
visualizzate negli elenchi a discesa.
v Elimina: selezionare la tabella da eliminare.
v Utilizza: selezionare il database da utilizzare.
v Servizio: selezionare un nome servizio e un valore. I valori
possono essere Buono, Marginale o Non valido.
Capitolo 3. Utilizzo di Netcool/OMNIbus Administrator per configurare ObjectServer
121
Tabella 21. Pulsanti dell’interfaccia interattiva SQL (Continua)
Pulsante
Descrizione
Fare clic su questo pulsante per selezionare un nome della
colonna di tabella da aggiungere al comando. Il nome colonna
viene sostituito per il corrispondente valore di riga dell’elenco
eventi durante l’esecuzione dello strumento. Quando viene
anteposto il simbolo @, il nome colonna viene sostituito con il
corrispondente valore di riga dell’elenco eventi durante
l’esecuzione. Tale valore può essere utilizzato in un filtro
limitazioni o in una query SQL, ad esempio: RemoteNodeAlias =
'@LocalNodeAlias'
Fare clic su questo pulsante per selezionare da un elenco di
conversioni disponibili. Fare doppio clic per aggiungere la
conversione.
Fare clic su questo pulsante per cancellare i comandi SQL
immessi.
Fare clic su questo pulsante per visualizzare un elenco di parole
chiave che completano l’SQL immesso.
Fare clic su questo pulsante per controllare la validità della
sintassi SQL immessa.
Fare clic su questo pulsante per individuare un file di tipo .sql
o .ed e controllare la validità della relativa sintassi. Una volta
completata l’operazione, vengono visualizzati i risultati.
Quando si utilizza un editor esterno per creare o modificare
trigger e procedure, tali elementi vengono salvati come file .ed.
Fare clic su questo pulsante per inoltrare i comandi SQL.
Una volta completato il comando SQL, fare clic su Submit.
History
Questo elenco a discesa fornisce una cronologia dei comandi SQL
immessi. È possibile selezionare un comando immesso in precedenza
dall’elenco. È possibile anche cancellare l’elenco dei comandi immessi
in precedenza facendo doppio clic sull’elenco e selezionando Clear
History.
Result View
Una volta immesso il comando, viene visualizzata una
rappresentazione visiva della tabella su cui è stato eseguito il comando
SQL in questa tabella.
Console View
Una cronologia del comando viene visualizzata in questa scheda.
Concetti correlati
Capitolo 4, “SQL ObjectServer”, a pagina 123
Attività correlate
“Creazione e modifica di conversioni” a pagina 107
122
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Capitolo 4. SQL ObjectServer
L’ObjectServer fornisce un’interfaccia SQL per definire e manipolare oggetti di
database relazionali, ad esempio tabelle e viste.
I comandi SQL dell’ObjectServer includono:
v Comandi DDL (Data Definition Language) per creare, modificare e cancellare
oggetti del database
v Comandi DML (Data Manipulation Language) per ricercare e manipolare dati
negli oggetti di database esistenti
v Comandi di sistema per modificare la configurazione di un ObjectServer
v Comandi per il controllo delle sessioni per modificare impostazioni nelle sessioni
client
v Comandi di sicurezza per controllare l’accesso degli utenti agli oggetti di
database
L’ObjectServer fornisce anche comandi di linguaggi procedurali che forniscono
costrutti di programmazione per definire azioni che hanno luogo quando si
verificano gli incidenti specificati e le condizioni definite vengono soddisfatte. È
possibile utilizzare procedure e trigger per creare automazioni per consentire
l’elaborazione automatica degli eventi.
È possibile utilizzare l’interfaccia interattiva SQL per collegarsi a un ObjectServer
ed eseguire comandi SQL dell’ObjectServer.
Suggerimento: Molte delle attività effettuate eseguendo comandi SQL
dell’ObjectServer dall’interfaccia interattiva SQL possono essere eseguite anche
dall’interfaccia di Netcool/OMNIbus Administrator.
Attività correlate
“Utilizzo dell’interfaccia interattiva SQL in modalità GUI” a pagina 120
Interfaccia interattiva SQL
È possibile utilizzare l’interfaccia interattiva SQL (chiamata nco_sql su UNIX e isql
su Windows) per collegarsi a un ObjectServer e utilizzare comandi SQL per
configurare e interagire con l’ObjectServer.
Quando si esegue l’interfaccia SQL interattiva, è possibile eseguire attività quali, ad
esempio, la creazione di una nuova tabella di database oppure l’arresto
dell’ObjectServer.
Nota: Solo gli utenti che sono membri di un gruppo cui è stato assegnato il ruolo
ISQL possono collegarsi a un ObjectServer utilizzando l’interfaccia interattiva SQL.
Solo gli utenti che sono membri di un gruppo cui è stato assegnato il ruolo
ISQLWrite possono modificare i dati di un ObjectServer utilizzando l’interfaccia
interattiva SQL. Questi ruoli sono predefiniti in Tivoli Netcool/OMNIbus.
© Copyright IBM Corp. 1994, 2009
123
Concetti correlati
“Configurazione dei ruoli” a pagina 58
“Configurazione dei gruppi” a pagina 63
“Utilizzo dei ruoli per assegnare autorizzazioni agli utenti” a pagina 177
Avvio dell’interfaccia interattiva SQL
Prima di avviare l’interfaccia interattiva SQL, è necessario connettersi a un
ObjectServer come specifico utente.
Per avviare l’interfaccia interattiva SQL:
Eseguire il comando nco_sql su UNIX e il comando isql su Windows, nel modo
seguente:
Opzione
Descrizione
UNIX
$NCHOME/omnibus/bin/nco_sql -server servername -user username
Windows
%NCHOME%\omnibus\bin\isql -S servername -U username
In questi comandi, servername è il nome dell’ObjectServer, mentre username è un
nome utente valido. Se non si specifica il nome di un ObjectServer, viene utilizzato
il nome predefinito NCOMS. Se non si specifica un nome utente, il nome utente
predefinito è quello dell’utente che esegue il comando. È necessario immettere una
password valida per l’utente, quando viene visualizzato il prompt oppure
specificando l’opzione della riga comandi -password (-P su Windows).
Nota: Su Windows, è necessario specificare il nome dell’ObjectServer e il nome
utente.
Risultati
Attenzione: È bene ricordare che specificando la password sulla riga comandi, si
rende visibile la password. Se non si specifica una password, viene chiesto di
fornirne una.
Diverse opzioni della riga comandi sono disponibili per l’uso con questi comandi.
Opzioni della riga comandi per avviare l’interfaccia interattiva
SQL
Quando si utilizza il comando nco_sql o isql per avviare l’interfaccia interattiva
SQL, è possibile specificare numerose opzioni della riga comandi per modificare la
configurazione. È possibile eseguire il comando nco_sql o isql dalla directory
$NCHOME/omnibus/bin.
Le opzioni della riga comandi per l’interfaccia interattiva SQL sono descritte nella
seguente tabella:
Tabella 22. Opzioni della riga comandi per i comandi nco_sql e isql
124
Opzione
Descrizione
-help
Visualizza le informazioni della guida relative alle opzioni
della riga comandi ed esce.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 22. Opzioni della riga comandi per i comandi nco_sql e isql (Continua)
Opzione
Descrizione
-networktimeout integer
Specifica il tempo, in secondi, dopo cui un tentativo di
accesso o una connessione all’ObjectServer entrerà in
timeout, nel caso in cui si verifichi un errore di rete. Dopo
il periodo di timeout specificato, l’interfaccia interattiva
SQL tenta di riconnettersi all’ObjectServer. Se la
connessione non riesce dopo un secondo periodo di
timeout, l’interfaccia interattiva SQL tenterà di connettersi a
un ObjectServer di backup, se disponibile. Per impostazione
predefinita, non viene specificato nessun timeout.
-l logintimeout e -t timeout su
Windows
Su Windows, -l specifica il valore di timeout massimo
consentito quando si esegue la connessione al server,
mentre -t specifica il numero di secondi prima che un
comando entri in timeout. Se non si specifica un valore di
timeout, un comando viene eseguito in modo indefinito.
Ciò influisce sui comandi inoltrati da isql, non sul tempo di
connessione. Il timeout predefinito per registrarsi in isql è
60 secondi.
Nota: Il comando nco_sql esegue nco_get_login_token per
ottenere un token di accesso, quindi esegue l’interfaccia
interattiva SQL (isql) con questo token. Il timeout di rete
specificato viene assegnato a entrambi i valori binari
nco_get_login_token e isql al momento dell’avvio. Se si
esegue nco_sql con -secure, non impostare il timeout su un
valore maggiore di 14 secondi perché un token di accesso
sicuro è valido solo per 15 secondi. Un timeout maggiore
può essere utilizzato con l’opzione -nosecure.
-nosecure
Se specificata, le informazioni di accesso non vengono
codificate quando vengono trasmesse tra i componenti.
-password password
Specifica la password per l’utente.
-P password su Windows
Su Windows, se si sta utilizzando una password vuota, ad
esempio quella predefinita dell’ObjectServer NCOMS,
l’opzione -P deve essere specificata come ultima voce. Ad
esempio:
″%NCHOME%\omnibus\bin\isql″ -U root -S NCOMS -i
update71to72.sql -P
Attenzione: La password è visibile se viene specificata
nella riga comandi. Se non viene specificata, viene richiesto
di fornire la password.
-secure
Se specificata, le informazioni di accesso vengono codificate
automaticamente quando vengono trasmesse tra i
componenti.
Si tratta dell’impostazione predefinita per tutte le release
supportate di Tivoli Netcool/OMNIbus.
-server servername
-S servername su Windows
-user username
-U username su Windows
Specifica il nome dell’ObjectServer al quale connettersi.
L’impostazione predefinita è NCOMS.
Specifica il nome di un utente di Tivoli Netcool/OMNIbus.
L’impostazione predefinita è il nome dell’utente che esegue
il comando.
Nota: L’interfaccia interattiva SQL non consente l’uso di
spazi nei nomi utente.
Capitolo 4. SQL ObjectServer
125
Dopo la connessione, è possibile immettere comandi SQL dell’ObjectServer.
Concetti correlati
“Esecuzione dell’interfaccia interattiva SQL in modalità sicura” a pagina 129
Attività correlate
“Esecuzione di comandi SQL nell’interfaccia interattiva SQL”
Esecuzione di comandi SQL nell’interfaccia interattiva SQL
Dopo aver stabilito la connessione all’interfaccia interattiva SQL con un nome
utente e una password, viene visualizzato un prompt numerato. Immettere dal
prompt comandi SQL dell’ObjectServer.
Il prompt viene visualizzato come:
1>
Durante l’immissione di testo:
v I comandi possono essere divisi su più righe.
v I comandi non vengono elaborati fino a quando non si immette la parola chiave
go in lettere minuscole all’inizio di una nuova riga e si preme Invio.
Nota: Il programma di utilità nco_sql non permette l’uso di spazi prima della
parola chiave go. Ad esempio, se si esegue nco_sql in maniera non interattiva da
uno script e si utilizza uno spazio per il rientro della parola chiave go, le
istruzioni SQL non funzioneranno.
v È possibile eseguire più comandi, separati da un punto e virgola (;), con un solo
comando go.
v La lunghezza dei comandi non può superare i 4094 caratteri.
Inoltre:
v Per annullare un comando, immettere reset all’inizio di una nuova riga oppure
premere Ctrl+C in un punto qualsiasi della riga. Tutti i comandi che non sono
stati eseguiti vengono eliminati.
v Per eseguire l’editor predefinito (così come definito dalla variabile di ambiente
EDITOR) nel programma di utilità nco_sql, immettere vi all’inizio di una nuova
riga.
v Per leggere un file, immettere :r filename all’inizio di una nuova riga. Non
includere il comando go nel file. Immettere, invece, il comando go all’inizio di
una nuova riga.
v Per eseguire un comando di un sistema operativo, immettere !! seguito dal
comando (ad esempio, !!ls) all’inizio di una nuova riga.
Notazione della sintassi SQL
Una notazione della sintassi SQL viene utilizzata per descrivere i comandi SQL
dell’ObjectServer che è possibile eseguire dall’interfaccia interattiva SQL.
Un esempio di notazione della sintassi per la creazione di tabelle è il seguente:
CREATE TABLE [database_name.]table_name
PERSISTENT | VIRTUAL
(column_name data_type [ PRIMARY KEY | NODEFAULT | NOMODIFY | HIDDEN ],...
[, PRIMARY KEY(column_name,...) ] );
Suggerimento: Quando si immette un comando SQL, è necessario specificare le
parole chiave nell’ordine elencato nelle descrizioni della sintassi.
126
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
La seguente tabella descrive la notazione della sintassi utilizzata per comandi SQL.
Tabella 23. Notazione della sintassi SQL
Sintassi
Descrizione
{ a | b }
Nella notazione della sintassi SQL, le parentesi graffe
racchiudono due o più opzioni alternative obbligatorie,
separate da una barra verticale.
[ ]
Nella notazione della sintassi SQL, le parentesi quadre
racchiudono una clausola o un elemento facoltativo. Più
elementi o clausole sono separati da una barra verticale.
|
Nella notazione della sintassi SQL, le barre verticali
separano due o più elementi di sintassi alternativi.
...
Nella notazione della sintassi SQL, i puntini di sospensione
indicano che l’elemento precedente può essere ripetuto. Se
non diversamente indicato, la ripetizione è illimitata.
,...
Nella notazione della sintassi SQL, i puntini di sospensione
preceduti da una virgola indicano che l’elemento
precedente può essere ripetuto e ciascun elemento ripetuto
viene separato dall’ultimo con una virgola. Se non
diversamente indicato, la ripetizione è illimitata.
a
Nella notazione della sintassi SQL, un elemento sottolineato
indica una opzione predefinita.
( )
Nella notazione della sintassi SQL, le parentesi che
vengono visualizzate nella sintassi delle istruzioni fanno
parte della sintassi e, se non diversamente indicato, devono
essere immesse come mostrato.
Nella sintassi:
v Le parole chiave SQL sono riportate in maiuscolo; ad esempio, CREATE, TABLE
e PERSISTENT. Tuttavia, le parole chiave SQL non rispettano la distinzione
maiuscolo/minuscolo e possono essere visualizzate in maiuscolo, minuscolo
oppure in maiuscolo e minuscolo insieme.
v I valori delle variabili vengono rappresentati in corsivo. Ad esempio,
database_name richiede l’immissione di un nome di database effettivo, table_name
richiede l’immissione di un nome di tabella effettivo, column_name richiede
l’immissione di un nome di colonna effettivo, mentre data_type richiede
l’immissione di un tipo di dati effettivo.
Convenzioni di denominazione per oggetti ObjectServer
Quando si immettono comandi SQL, è necessario applicare le convenzioni di
denominazione definite per gli ObjectServer.
Il nome di un ObjectServer deve essere composto da un massimo di 29 lettere
maiuscole e non può iniziare con un numero intero.
Quando si crea un oggetto ObjectServer, è necessario assegnargli un nome univoco
per quel tipo di oggetto. I nomi degli oggetti ObjectServer devono iniziare con una
lettera maiuscola o minuscola, seguita da lettere maiuscole o minuscole, numeri o
caratteri di sottolineatura (_), per un totale massimo di 40 caratteri.
Nota: Per quanto riguarda i nomi degli utenti, dei gruppi e dei ruoli, è possibile
specificare una qualsiasi stringa di testo racchiusa tra virgolette e la cui lunghezza
non superi il limite massimo di 64 caratteri.
Capitolo 4. SQL ObjectServer
127
I nomi degli oggetti ObjectServer e gli identificativi rispettano la distinzione
maiuscolo/minuscolo.
Specifica dei percorsi nell’interfaccia interattiva SQL
Alcuni comandi SQL richiedono l’immissione di nomi di percorso.
Ad esempio, su UNIX, è possibile creare un file immettendo il seguente comando:
create file TESTFILE01 ’/tmp/testfile01’;
Su Windows, è necessario eseguire l’escape con il carattere barra retroversa nei
percorsi file; in caso contrario, i percorsi non verranno interpretati correttamente.
Ad esempio, è possibile creare un file ObjectServer su Windows utilizzando il
seguente comando:
create file TESTFILE01 ’c:\\temp\\testfile01.txt’;
È anche possibile utilizzare il separatore di percorso UNIX quando si specificano
percorsi su Windows. Il seguente percorso UNIX, ad esempio, viene interpretato
correttamente su Windows:
create file TESTFILE01 'c:/temp/testfile01.txt';
Utilizzo di file di testo per l’input e l’output
È possibile reindirizzare file di testo utilizzando l’interfaccia interattiva SQL.
Questa operazione è molto utile quando occorre eseguire attività ripetitive.
Il file di testo deve contenere solo comandi SQL e deve terminare con la parola
chiave go; in caso contrario, i comandi non verranno elaborati.
Ad esempio, per eseguire i comandi SQL in un file di testo denominato
my_SQL_file.txt da una riga comandi UNIX, immettere il seguente comando:
nco_sql -server OS1 -username myuser -password mypass < my_SQL_file.txt
È anche possibile indirizzare l’output a un file. Ad esempio:
nco_sql -server OS1 -username myuser -password mypass< my_SQL_file.txt >
output.txt
Esempio: Sessione dell’interfaccia interattiva SQL su UNIX
Questo esempio mostra una sessione dell’interfaccia interattiva SQL su UNIX, per
eseguire nco_sql e immettere comandi.
nco_sql -server OS1 -username myuser -password mypass
1> select * from alerts.status;
2> go
Vengono visualizzati i risultati del comando.
128
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Esecuzione dell’interfaccia interattiva SQL in modalità sicura
Quando un ObjectServer viene eseguito in modalità sicura, richiede che i client, ad
esempio probe, desktop, gateway e l’interfaccia interattiva SQL, si colleghino
utilizzando nomi utente e password validi. Le informazioni di accesso vengono
codificate in maniera automatica quando vengono trasmesse tra i componenti, allo
scopo di vanificare possibili tentativi di snooping.
L’interfaccia interattiva SQL viene eseguita in modalità sicura a meno che non si
specifichi l’opzione della riga comandi -nosecure quando si avvia l’interfaccia
interattiva SQL.
Quando si esegue l’interfaccia interattiva SQL in modalità sicura, essa utilizza il
programma di utilità nco_get_login_token per codificare i relativi dati di accesso
per la trasmissione. Il programma di utilità produce un token che può essere
utilizzato solo una volta per accedere all’ObjectServer. Il token ha un limite di
tempo al termine del quale scade e non è più valido.
Attività correlate
“Avvio dell’interfaccia interattiva SQL” a pagina 124
Codifica delle password negli script nco_sql UNIX
È possibile utilizzare il programma di utilità nco_sql_crypt per codificare password
di accesso in testo semplice in modo che non vengano esposte negli script UNIX
che eseguono nco_sql. Questa operazione può essere eseguita solo in modalità non
FIPS 140–2.
In modalità FIPS 140–2, lasciare le password in testo semplice negli script oppure
utilizzare il programma di utilità nco_aes_crypt con l’opzione -d per decodificare
tutti i dati sensibili prima dell’uso.
Per codificare e utilizzare una password in testo semplice in modalità non FIPS
140–2:
1. Immettere il seguente comando:
$NCHOME/omnibus/bin/nco_sql_crypt plaintext_password
In questo comando, plaintext_password rappresenta il formato non codificato
della password. Il programma di utilità nco_sql_crypt visualizza una versione
codificata della password.
2. Copiare la password codificata nello script.
Risultati
Le password codificate utilizzando il programma di utilità nco_sql_crypt, vengono
decodificate dall’ObjectServer quando viene stabilita la connessione.
Come uscire dall’interfaccia interattiva SQL
Per uscire dall’interfaccia interattiva SQL:
Effettuare l’azione appropriata per il sistema operativo in uso:
Opzione
Descrizione
UNIX
Premere Ctrl+D oppure immettere quit o exit all’inizio di una nuova riga.
Windows
Immettere quit o exit all’inizio di una nuova riga.
Capitolo 4. SQL ObjectServer
129
La connessione all’ObjectServer viene chiusa e si ritorna al prompt del sistema
operativo.
Creazione, modifica ed eliminazione di oggetti ObjectServer
L’ObjectServer archivia, gestisce ed elabora dati evento raccolti da applicazioni
esterne quali, ad esempio, probe e gateway. Le strutture (o oggetti) di archiviazione
predefinite vengono create sulla base di file di definizioni SQL.
È possibile utilizzare comandi DDL (Data Definition Language) per creare,
modificare ed eliminare oggetti ObjectServer. La seguente tabella elenca i singoli
oggetti e i comandi DDL che possono essere utilizzati.
Tabella 24. Oggetti ObjectServer e comandi DDL associati
Oggetto ObjectServer
Comandi DDL consentiti
DATABASE
CREATE DATABASE
DROP DATABASE
TABLE
CREATE TABLE
ALTER TABLE
DROP TABLE
INDEX
CREATE INDEX
DROP INDEX
VIEW
CREATE VIEW
DROP VIEW
RESTRICTION FILTER
CREATE RESTRICTION FILTER
DROP RESTRICTION FILTER
FILE
CREATE FILE
ALTER FILE
DROP FILE
Database
Un database è una raccolta strutturata di dati organizzata in modo da consentire
un rapido accesso alle informazioni desiderate. Un database relazionale utilizza le
tabelle come contenitori logici per archiviare questi dati in righe e colonne.
È possibile creare ed eliminare database utilizzando l’SQL dell’ObjectServer.
Creazione di un database
Utilizzare il comando CREATE DATABASE per creare un database.
Sintassi
CREATE DATABASE database_name;
Il nome del database deve essere univoco all’interno dell’ObjectServer e conforme
alle convenzioni di denominazione dell’ObjectServer.
Un database è sempre persistente.
130
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Esempio
create database mydb;
Concetti correlati
“Convenzioni di denominazione per oggetti ObjectServer” a pagina 127
Eliminazione di un database
Utilizzare il comando DROP DATABASE per eliminare un database esistente.
Non è possibile eliminare un database se contiene oggetti. Inoltre, non è possibile
eliminare i database di sicurezza e dei cataloghi, perché sono database inizializzati
dal sistema.
Sintassi
DROP DATABASE database_name;
Esempio
drop database mydb;
Concetti correlati
“Database inizializzati dal sistema”
Database inizializzati dal sistema
Quando si inizializza un ObjectServer, vengono creati numerosi database
predefiniti.
La seguente tabella descrive i database inizializzati dal sistema.
Tabella 25. Database inizializzati dal sistema
Nome del database
Tipo di database
Descrizione
security
Sistema
Contiene informazioni relative al
sistema di sicurezza, che includono
utenti, ruoli, gruppi e autorizzazioni.
catalog
Sistema
Contiene i metadati relativi agli
oggetti ObjectServer.
alerts
Utente
Contiene informazioni relative allo
stato degli avvisi, inoltrate
all’ObjectServer da probe e gateway.
service
Utente
Utilizzato per supportare IBM Tivoli
Composite Application Manager for
Internet Service Monitoring.
custom
Utente
Può essere utilizzato per tabelle
aggiunte dagli utenti.
persist
Sistema
Registra informazioni interne relative
allo stato dell’ObjectServer.
transfer
Sistema
Utilizzato internamente dai gateway
unidirezionali e bidirezionali
ObjectServer per sincronizzare
informazioni relative alla sicurezza
tra un ObjectServer e l’altro.
Capitolo 4. SQL ObjectServer
131
Tabella 25. Database inizializzati dal sistema (Continua)
Nome del database
Tipo di database
Descrizione
master
Utente
Utilizzato per compatibilità con
precedenti release di Tivoli
Netcool/OMNIbus. Le tabelle del
database principale supportano
inoltre l’architettura degli
ObjectServer desktop.
Per dettagli sull’architettura degli
ObjectServer desktop, consultare IBM
Tivoli Netcool/OMNIbus - Guida
all’installazione e alla distribuzione.
tools
Utente
Utilizzato per la compatibilità con le
precedenti release di Tivoli
Netcool/OMNIbus.
iduc_system
Utente
Contiene tutte le tabelle di supporto
dell’applicazione IDUC necessarie per
la notifica eventi accelerati, l’invio di
messaggi informativi e il richiamo di
comandi.
precision
Utente
Utilizzato da IBM Tivoli Network
Manager IP Edition per implementare
l’applicazione SAE (Service-Affected
Event).
Limitazione: I database di sistema sono gestiti dall’ObjectServer. È possibile
visualizzarne i dati, ma non modificarli.
Concetti correlati
“Configurazione dei database” a pagina 111
Riferimenti correlati
Appendice A, “Tabelle dell’ObjectServer”, a pagina 311
Tabelle
La principale struttura di archiviazione dell’ObjectServer è la tabella.
Una tabella presenta un numero fisso di colonne, ciascuna delle quali contiene un
determinato tipo di dati. Il nome di ogni singola colonna è univoco per la tabella.
Una tabella contiene zero o più righe di dati nel formato definito dall’elenco di
colonne della tabella.
Il nome completo della tabella include il nome del database e il nome della tabella,
separati da un punto. Ad esempio, la tabella status nel database degli avvisi è
identificata come alerts.status.
132
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Creazione di una tabella
Utilizzare il comando CREATE TABLE per creare una tabella.
Sintassi
CREATE TABLE [database_name.]table_name
PERSISTENT | VIRTUAL
(column_name data_type [ PRIMARY KEY | NODEFAULT | NOMODIFY | HIDDEN],...
[, PRIMARY KEY(column_name,...) ] );
Il nome della tabella deve essere univoco all’interno del database e conforme alle
convenzioni di denominazione dell’ObjectServer.
Il tipo di archiviazione è PERSISTENT o VIRTUAL. Una tabella persistente viene
ricreata, completa di tutti i dati, quando l’ObjectServer viene riavviato. Una tabella
virtuale viene ricreata con la stessa descrizione di tabella, ma senza dati, quando
l’ObjectServer viene riavviato.
Quando si definiscono colonne, è necessario specificare il nome di colonna e il tipo
di dati, ed è anche possibile specificare proprietà facoltative.
Il numero massimo di colonne in una tabella è 512, ad eccezione delle colonne
gestite dal sistema. La dimensione massima di una riga per una tabella, data dalla
somma della lunghezza delle colonne nella riga, è 64 KB.
Esempio
create table mydb.mytab persistent
(col1 integer primary key, col2 varchar(20));
Concetti correlati
“Convenzioni di denominazione per oggetti ObjectServer” a pagina 127
Specifica dei tipi di dati per le colonne:
A ciascun valore di colonna nell’ObjectServer è associato un tipo di dati. Il tipo di
dati determina il modo in cui l’ObjectServer elabora i dati nella colonna.
Ad esempio, l’operatore più (+) aggiunge valori numerici interi o concatena valori
stringa, ma non opera sui valori booleani.
Quando si crea una tabella utilizzando il comando CREATE TABLE, è necessario
specificare un tipo di dati per ciascuna colonna che si definisce. I tipi di dati
supportati dall’ObjectServer sono elencati nella seguente tabella:
Tabella 26. Tipi di dati dell’ObjectServer
Tipo SQL
Descrizione
Valore predefinito
ID ObjectServer per
il tipo di dati
INTEGER
Numero intero con
segno a 32 bit.
0
0
INCR
Numero intero auto
incrementale senza
segno a 32 bit. Si
applica soltanto alle
colonne di tabella e
può essere
aggiornato solo dal
sistema.
1
5
Capitolo 4. SQL ObjectServer
133
Tabella 26. Tipi di dati dell’ObjectServer (Continua)
Tipo SQL
Descrizione
Valore predefinito
ID ObjectServer per
il tipo di dati
UNSIGNED
Numero intero senza
segno a 32 bit.
0
12
BOOLEAN
TRUE o FALSE.
FALSE
13
REAL
Numero a virgola
mobile con segno a
64 bit.
0,0
14
TIME
Ora, memorizzata
sotto forma di
numero di secondi a
partire dalla
mezzanotte del 1
gennaio 1970. Si
tratta dello standard
internazionale UTC
(Coordinated
Universal Time).
Thu Jan 1 01:00:00
1970
1
CHAR(integer)
Stringa di caratteri a ’’
dimensione fissa,
lunga fino a integer
caratteri, (8192 byte è
la lunghezza
massima).
10
Il tipo char è identico
nel funzionamento al
tipo varchar, ma
garantisce prestazioni
migliori per gli
aggiornamenti di
massa che
modificano la
lunghezza della
stringa.
VARCHAR(integer)
Stringa di caratteri a ’’
lunghezza variabile,
lunga fino a integer
caratteri, (8192 byte è
la lunghezza
massima).
2
Il tipo varchar
utilizza uno spazio di
archiviazione minore
rispetto al tipo char e
le prestazioni sono
migliori per le
operazioni di
deduplicazione,
scansione,
inserimento ed
eliminazione.
INTEGER64
134
Numero intero con
segno a 64 bit.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
0
16
Tabella 26. Tipi di dati dell’ObjectServer (Continua)
Tipo SQL
Descrizione
Valore predefinito
ID ObjectServer per
il tipo di dati
UNSIGNED64
Numero intero senza
segno a 64 bit.
0
17
Nota: Nell’elenco eventi, è possibile visualizzare solo colonne di tipo CHAR,
VARCHAR, INCR, INTEGER e TIME. Non aggiungere colonne di qualsiasi altro
tipo alla tabella alerts.status.
Riferimenti correlati
“Creazione di una tabella” a pagina 133
“Tabella alerts.status” a pagina 311
“Creazione di un segnale definito dall’utente” a pagina 204
Specifica di proprietà facoltative per le colonne:
È possibile specificare proprietà facoltative per le colonne che si definiscono
quando si crea una tabella.
Le proprietà di colonna facoltative sono descritte nella seguente tabella:
Tabella 27. Proprietà di colonna
Proprietà di colonna
Descrizione
PRIMARY KEY
La colonna viene creata come chiave primaria. La colonna o
le colonne chiave primaria identificano in modo univoco
ciascuna riga. Una colonna chiave primaria deve avere un
valore predefinito e non può essere nascosta.
NODEFAULT
Il valore di questa colonna deve essere specificato nel
comando INSERT iniziale. Utilizzare il comando INSERT
per inserire una nuova riga di dati in una tabella esistente.
NOMODIFY
Il valore di questa colonna non può essere modificato dopo
il comando INSERT iniziale.
HIDDEN
I dati non vengono scritti o letti da una colonna nascosta
quando si inserisce o si seleziona una riga. Il nome della
colonna deve essere specificato in maniera esplicita per
inserirvi o selezionarvi dati. Le colonne nascoste
contengono informazioni di sistema o informazioni che non
sono applicabili alla maggior parte degli utenti.
Nel comando CREATE TABLE, la sintassi per specificare quali colonne sono le
chiavi primarie, è la seguente:
(column_name data_type [ PRIMARY KEY | NODEFAULT | NOMODIFY | HIDDEN ],...
[, PRIMARY KEY(column_name,...) ] );
Sulla base di questa sintassi, è possibile creare colonne come chiavi primarie in uno
dei seguenti modi:
v Specificare la proprietà di colonna PRIMARY KEY come parte di una definizione
di colonna.
v Specificare una o più colonne che costituiscono la chiave primaria includendo un
elenco di colonne separate da virgole nella clausola PRIMARY KEY dopo le
definizioni di colonna.
Capitolo 4. SQL ObjectServer
135
Riferimenti correlati
“Creazione di una tabella” a pagina 133
“Inserimento di una nuova riga di dati in una tabella (comando INSERT)” a pagina
162
Modifica di una tabella
Utilizzare il comando ALTER TABLE per modificare le caratteristiche di una tabella
esistente e delle relative colonne. È possibile aggiungere, eliminare e modificare
colonne.
Limitazione: Non è possibile modificare le tabelle di sistema, le quali contengono
metadati relativi agli oggetti ObjectServer.
Sintassi
ALTER TABLE [database_name.]table_name
ADD [COLUMN] column_name data_type [ NODEFAULT | NOMODIFY | HIDDEN ]
DROP [COLUMN] column_name
ALTER [COLUMN] column_name SET NOMODIFY { TRUE | FALSE }
ALTER [COLUMN] column_name SET HIDDEN { TRUE | FALSE }
ALTER [COLUMN] column_name SET NODEFAULT { TRUE | FALSE }
ALTER [COLUMN] column_name SET WIDTH value;
È possibile specificare più di una impostazione ADD, DROP o ALTER in un
singolo comando ALTER TABLE.
Esempio
alter table mytab add col3 real;
Concetti correlati
“Tabelle di sistema” a pagina 139
Aggiunta di una colonna:
Per aggiungere una colonna a una tabella esistente, utilizzare l’impostazione ADD
COLUMN con il comando ALTER TABLE.
In questo comando, la sintassi per aggiungere colonne è la seguente:
ADD [COLUMN] column_name data_type [ NODEFAULT | NOMODIFY | HIDDEN ]
Quando si aggiungono colonne, è necessario specificare il nome e il tipo di dati
delle colonne. È anche possibile specificare proprietà facoltative.
Non è possibile aggiungere chiavi primarie a una tabella esistente.
Riferimenti correlati
“Modifica di una tabella”
“Specifica dei tipi di dati per le colonne” a pagina 133
“Specifica di proprietà facoltative per le colonne” a pagina 135
136
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Eliminazione di una colonna:
Per eliminare colonne da una tabella esistente, utilizzare l’impostazione DROP
COLUMN con il comando ALTER TABLE.
In questo comando, la sintassi per eliminare colonne è la seguente:
DROP [COLUMN] column_name
Non è possibile eliminare una colonna se si tratta di una chiave primaria.
L’eliminazione di una colonna richiede l’esecuzione di un numero considerevole di
azioni preliminari per identificare e rimuovere eventuali dipendenze esterne dalla
colonna. È necessario ricercare i possibili riferimenti alla colonna nei trigger, nelle
procedure, nelle viste e nei filtri limitazioni eseguendo query nelle tabelle di
database pertinenti. È anche necessario eseguire ricerche nei file delle regole di
probe e nei file di associazioni gateway per trovare eventuali riferimenti alla
colonna.
Attenzione: Se si elimina una colonna da cui dipendono trigger, procedure, viste,
filtri limitazioni o indici, vengono eliminati anche questi oggetti dipendenti e
un’avvertenza viene scritta nel file di log dell’ObjectServer. Per evitare che trigger,
procedure, viste o filtri limitazioni vengano inavvertitamente eliminati, leggere le
seguenti linee guida per la rimozione di colonne. Dal momento che gli indici sono
collegati direttamente alle colonne, essi vengono sempre eliminati quando le
colonne cui sono associati vengono rimosse.
Le seguenti linee guida si basano su di uno scenario di esempio in cui si desidera
eliminare la colonna Country dall’ObjectServer:
1. Connettersi all’ObjectServer (ad esempio, OWL) utilizzando l’interfaccia
interattiva SQL, come mostrato nella tabella riportata di seguito. Il nome utente
viene acquisito per impostazione predefinita, ma occorre specificare la
password.
Tabella 28. Avvio dell’interfaccia interattiva SQL
Opzione
Descrizione
UNIX
Immettere:
$NCHOME/omnibus/bin/nco_sql -server OWL
Windows
Immettere:
%NCHOME%\omnibus\bin\isql -S OWL
2. Eseguire il backup dell’ObjectServer in una ubicazione temporanea (ad
esempio, /tmp/mybackup) utilizzando il comando ALTER SYSTEM BACKUP.
Questa misura cautelativa assicura la possibilità di ripristinare il sistema
qualora fosse necessario.
1> alter system backup '/tmp/mybackup';
2> go
3. Elencare i dettagli dei trigger, così come memorizzati nella tabella
catalog.triggers:
1> describe catalog.triggers;
2> go
Sullo schermo vengono visualizzati il tipo di chiave, il nome, il tipo di dati e la
lunghezza di ciascuna colonna della tabella.
Capitolo 4. SQL ObjectServer
137
4. Richiamare i nomi di tutti i trigger che fanno riferimento alla colonna Country
nel corpo del trigger:
1> select TriggerName from catalog.triggers where CodeBlock like 'Country';
2> go
Vengono visualizzati i nomi di tutti i trigger coinvolti.
5. Annotare tutti i trigger elencati e rimuovere i riferimenti alla colonna Country
modificando ciascun trigger. È possibile effettuare questa operazione dalla
finestra Trigger Details (scheda Action) in Netcool/OMNIbus Administrator.
6. Ripetere i passi 3-5 per identificare altri possibili oggetti che fanno riferimento
alla colonna Country e per rimuovere tutte le istanze del riferimento. La tabella
riportata di seguito elenca le tabelle di database in cui occorre eseguire la
ricerca, le istruzioni SELECT pertinenti e le finestre di Netcool/OMNIbus
Administrator che è possibile utilizzare per modificare l’oggetto.
Tabella 29. Tabelle del catalogo di sistema in cui eseguire la ricerca, istruzioni SELECT e finestre di
Netcool/OMNIbus Administrator
Finestra
Netcool/OMNIbus
Administrator
Tipo di oggetto
Nome della tabella
Istruzione SELECT
Procedure
catalog.sql_procedures
select ProcedureName from
catalog.sql_procedures where
CodeBlock like 'Country';
Finestra SQL Procedure
Details
Filtri limitazioni
catalog.restrictions
select RestrictionName from
catalog.restrictions where
ConditionText like 'Country';
Finestra Restriction
Filter Details
Viste
catalog.views
select ViewName from
catalog.views where CreationText
like 'Country';
7. Eseguire la ricerca nei file delle regole di probe $NCHOME/omnibus/probes/arch/
*.rules e rimuovere eventuali riferimenti alla colonna.
8. Eseguire la ricerca nei file di associazione di gateway $NCHOME/omnibus/gates/
objserv_type/objserv_type.map, dove type rappresenta uni o bi. Rimuovere
eventuali riferimenti alla colonna.
9. Dopo aver rimosso tutti i riferimenti, eliminare la colonna Country utilizzando
la sintassi ALTER TABLE ... DROP COLUMN.
Concetti correlati
“Richiamo di dati da una tabella o da una vista (comando SELECT)” a pagina 164
Riferimenti correlati
“Modifica delle impostazioni predefinite e correnti dell’ObjectServer (comando
ALTER SYSTEM)” a pagina 170
“Visualizzazione dei dettagli relativi alle colonne di una tabella o di una vista
(comando DESCRIBE)” a pagina 168
“Modifica di una tabella” a pagina 136
138
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Modifica di una colonna:
Per modificare le colonne di una tabella esistente, utilizzare l’impostazione ALTER
COLUMN con il comando ALTER TABLE.
In questo comando, la sintassi per modificare le colonne è la seguente:
ALTER
ALTER
ALTER
ALTER
[COLUMN]
[COLUMN]
[COLUMN]
[COLUMN]
column_name
column_name
column_name
column_name
SET
SET
SET
SET
NOMODIFY { TRUE | FALSE }
HIDDEN { TRUE | FALSE }
NODEFAULT { TRUE | FALSE }
WIDTH value
Utilizzare le seguenti linee guida per modificare le proprietà di una colonna:
v Per modificare le proprietà NOMODIFY, HIDDEN e NODEFAULT di una colonna
esistente, impostare la proprietà appropriata su TRUE o FALSE. Una colonna
chiave primaria deve avere un valore predefinito e non può essere nascosta.
v Per modificare la larghezza di una colonna con un tipo di dati varchar,
utilizzare la proprietà WIDTH e specificare l’impostazione value come lunghezza in
byte. Non è possibile modificare la larghezza delle chiavi primarie.
Riferimenti correlati
“Specifica di proprietà facoltative per le colonne” a pagina 135
“Modifica di una tabella” a pagina 136
Eliminazione di una tabella
Utilizzare il comando DROP TABLE per eliminare una tabella esistente.
Non è possibile eliminare una tabella se vi fanno riferimento altri oggetti, ad
esempio i trigger, o se contiene dati. Non è possibile eliminare tabelle di sistema, le
quali contengono metadati relativi agli oggetti ObjectServer.
Sintassi
DROP TABLE [database_name.]table_name;
Esempio
Per eliminare tutte le righe di una tabella:
delete from mytab;
Per eliminare la tabella:
drop table mytab;
Concetti correlati
“Tabelle di sistema”
Tabelle di sistema
Le tabelle di sistema sono tabelle speciali gestite dall’ObjectServer e contengono
metadati relativi agli oggetti ObjectServer.
Le tabelle di sistema vengono identificate dal nome del database catalog. Ad
esempio, la tabella catalog.columns contiene i metadati relativi a tutte le colonne
delle tabelle nell’ObjectServer.
È possibile visualizzare le informazioni contenute nelle tabelle di sistema
utilizzando i comandi SELECT e DESCRIBE, ma non è possibile aggiungere,
modificare o eliminare tabelle di sistema o il loro contenuto utilizzando l’SQL
dell’ObjectServer.
Capitolo 4. SQL ObjectServer
139
Concetti correlati
“Richiamo di dati da una tabella o da una vista (comando SELECT)” a pagina 164
Riferimenti correlati
“Visualizzazione dei dettagli relativi alle colonne di una tabella o di una vista
(comando DESCRIBE)” a pagina 168
“Tabelle del catalogo di sistema” a pagina 322
Indici
È possibile utilizzare gli indici per migliorare le prestazioni del database
ObjectServer. L’uso di indici ben progettati può ridurre o eliminare la necessità di
scansioni di tabelle complete durante l’esecuzione di query SQL, per un più veloce
recupero dei dati.
Riferimenti correlati
“Linee guide relative all’indicizzazione” a pagina 301
Creazione di un indice
Utilizzare il comando CREATE INDEX per creare un indice su una tabella di
database.
Suggerimento: Sono disponibili linee guida per le query SQL e l’indicizzazione
per determinare quali colonne indicizzare e quale tipo di indice creare per una
colonna.
Sintassi
CREATE INDEX index_name
ON database_name.table_name
[USING { HASH | TREE }] (column_name);
Il valore index_name deve essere univoco all’interno dell’ObjectServer e conforme
alle convenzioni di denominazione dell’ObjectServer. Per agevolare l’identificazione
e garantire l’univocità, si consiglia l’uso di una convenzione di denominazione per
gli indici; ad esempio, column_nameIdx o column_nameIndex, dove column_name è il
nome della colonna.
Il nome di tabella specificato dopo la parola chiave ON deve essere un nome di
database completo; ad esempio, alerts.status.
Limitazione: Non è possibile creare indici sulle colonne delle tabelle di sistema.
Queste tabelle contengono metadati relativi ad oggetti ObjectServer e sono
memorizzate nel database dei cataloghi.
Utilizzare l’impostazione USING facoltativa per creare un indice struttura ad
albero o hash. Se omesso, un indice hash viene creato per impostazione predefinita.
L’uso di un indice hash è appropriato solo con query SQL che denotano
uguaglianze. Inoltre, è possibile aggiungere un indice struttura ad albero per le
query ordinate.
Limitazione: Non è possibile creare un indice hash su un singolo campo della
chiave primaria. Non è possibile creare un indice struttura ad albero su colonne
con valori di dati booleani.
È necessario specificare il nome della singola colonna da indicizzare.
140
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Esempio
create index SeverityIdx on alerts.status (Severity);
create index ExpireTimeIdx on alerts.status using tree (ExpireTime);
Concetti correlati
“Convenzioni di denominazione per oggetti ObjectServer” a pagina 127
Riferimenti correlati
“Linee guida per le query SQL” a pagina 299
“Linee guide relative all’indicizzazione” a pagina 301
“Tabelle del catalogo di sistema” a pagina 322
Eliminazione di un indice
Utilizzare il comando DROP INDEX per rimuovere un indice ridondante in una
tabella di database.
Sintassi
DROP INDEX index_name;
Il valore index_name è il nome univoco per l’indice da eliminare.
Nota: Se una colonna indicizzata viene rimossa, l’indice viene automaticamente
eliminato.
Esempio
drop index SeverityIdx;
Visualizzazione dei dettagli degli indici
Per determinare quali sono le colonne attualmente indicizzate, è possibile
esaminare il contenuto della tabella catalog.indexes dall’interfaccia di
Netcool/OMNIbus Administrator oppure utilizzare il comando SELECT.
Per visualizzare i dettagli degli indici nella tabella catalog.indexes, effettuare una
delle seguenti operazioni:
v Dalla finestra Netcool/OMNIbus Administrator:
1. Selezionare il pulsante di menu System.
2. Fare clic su Databases. Si apre il riquadro Databases, Tables and Columns.
3. Selezionare catalog.indexes.
4. Fare clic sulla scheda Data View nel riquadro Databases, Tables and
Columns per visualizzare i dati della tabella.
v Dall’interfaccia interattiva SQL, immettere il seguente comando:
select * from catalog.indexes;
Concetti correlati
“Interfaccia interattiva SQL” a pagina 123
“Richiamo di dati da una tabella o da una vista (comando SELECT)” a pagina 164
Attività correlate
“Avvio di Netcool/OMNIbus Administrator” a pagina 46
Riferimenti correlati
“Tabella catalog.indexes” a pagina 332
Capitolo 4. SQL ObjectServer
141
Viste
Una vista è una tabella virtuale progettata da righe e colonne selezionate di una
tabella reale, che consente di visualizzare e manipolare con facilità sottoserie di
dati di tabelle.
Ad esempio, se si desidera che un gruppo di utenti visualizzi solo determinate
colonne di una tabella, è possibile creare una vista che contenga solo quelle
colonne. È anche possibile avere colonne virtuali, create utilizzando espressioni su
colonne nella tabella sottostante.
Nota: Le viste sono state concepite principalmente per uso interno. Non utilizzare
viste nelle automazioni.
Concetti correlati
“Espressioni” a pagina 160
Creazione di una vista
Utilizzare il comando CREATE VIEW per creare una vista.
Sintassi
CREATE [ OR REPLACE ] VIEW [database_name.]view_name
[ (view_column_name,...) ]
[ TRANSIENT | PERSISTENT ]
AS SELECT_cmd;
Se vi è una possibilità che esista già una vista con lo stesso nome di quella che si
desidera creare, utilizzare le parole chiave OR REPLACE facoltative. Se la vista
esiste, viene sostituita da quella che si sta creando. Se non esiste, ne viene creata
una nuova.
Il nome della vista deve essere univoco all’interno del database e conforme alle
convenzioni di denominazione dell’ObjectServer. Alla creazione di viste si
applicano anche le seguenti limitazioni:
v Se non si specifica il nome di un database, la vista viene creata nel database
degli avvisi.
v Non è possibile creare una vista di una vista.
v Non è possibile creare una vista di nessuna delle tabelle del database dei
cataloghi.
È possibile specificare un tipo di archiviazione dati TRANSIENT o PERSISTENT, a
seconda delle proprie esigenze di archiviazione dati. Una vista temporanea viene
eliminata quando il client che l’ha creata si disconnette. Una vista persistente viene
sottoposta al mirroring su disco. Quando l’ObjectServer viene riavviato, la vista
viene ricreata.
SELECT_cmd è un qualsiasi comando SELECT (inclusi i comandi SELECT di
aggregazione) con le seguenti limitazioni:
v È necessario specificare tutti i nomi delle colonne in maniera esplicita, anziché
utilizzare un carattere jolly (*), nell’elenco di selezione.
v Se si includono colonne virtuali, non è possibile aggiornarle.
v Se non si specifica il nome di un database, quello predefinito è alerts.
v Non è possibile specificare una clausola GROUP BY.
v È possibile avere solo una sottoquery contenente una clausola WHERE in una
istruzione SELECT di aggregazione.
142
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
v Non è possibile utilizzare colonne virtuali in una istruzione SELECT di
aggregazione.
v Se si crea una vista di aggregazione, non è possibile eseguire su di essa un
comando SELECT di aggregazione.
Esempio
create view alerts.myview persistent as select Severity, LastOccurrence, Summary
from alerts.status order by Severity, LastOccurrence;
Concetti correlati
“Convenzioni di denominazione per oggetti ObjectServer” a pagina 127
“Richiamo di dati da una tabella o da una vista (comando SELECT)” a pagina 164
Eliminazione di una vista
Utilizzare il comando DROP VIEW per eliminare una vista esistente.
Non è possibile eliminare una vista se vi fanno riferimento altri oggetti.
Sintassi
DROP VIEW [database_name.]view_name;
Se non si specifica un nome di database, la vista viene eliminata dal database degli
avvisi.
Esempio
drop view myview;
Filtri limitazioni
Un filtro limitazioni fornisce un modo per limitare le righe che vengono
visualizzate quando un utente visualizza una tabella.
Dopo aver assegnato il filtro limitazioni a un utente oppure a un gruppo, il filtro
limitazioni controlla i dati che possono essere visualizzati e modificati dalle
applicazioni client e modificati nei comandi INSERT, UPDATE e DELETE. Vengono
restituite solo le righe che soddisfano i criteri specificati nella condizione del filtro
limitazioni.
È possibile assegnare a un utente o a un gruppo un solo filtro limitazioni per
tabella. Se si applicano più filtri limitazioni a un utente oppure a un gruppo, i dati
che ne risultano sono una combinazione di tutti i filtri limitazioni applicabili per
l’utente o il gruppo.
Riferimenti correlati
“Modifica dei dettagli di un utente esistente (comando ALTER USER)” a pagina
174
“Modifica dei dettagli di un gruppo esistente (comando ALTER GROUP)” a pagina
175
Capitolo 4. SQL ObjectServer
143
Creazione di un filtro limitazioni
Utilizzare il comando CREATE RESTRICTION FILTER per creare un filtro
limitazioni.
Sintassi
CREATE [ OR REPLACE ] RESTRICTION FILTER filter_name
ON database_name.table_name WHERE condition;
Se vi è una possibilità che esista già un filtro limitazioni con lo stesso nome di
quello che si desidera creare, utilizzare le parole chiave OR REPLACE facoltative.
Se il filtro limitazioni esiste, viene sostituito da quello che si sta creando. Se non
esiste, ne viene creato uno nuovo.
Nota: Se si desidera sostituire un filtro limitazioni esistente, è possibile modificare
solo la variabile condition. È possibile sostituire un filtro limitazioni anche nel caso
in cui sia stato assegnato a utenti oppure a gruppi.
Il nome del filtro limitazioni deve essere univoco e conforme alle convenzioni di
denominazione dell’ObjectServer.
Il nome di tabella specificato dopo la parola chiave ON deve essere un nome di
database completo; ad esempio, alerts.status.
condition consiste di una o più espressioni che restituiscono una sottoserie di righe
della tabella. Laddove applicabile, è necessario specificare nomi di tabella completi
all’interno della clausola WHERE e in qualsiasi istruzione SELECT nella
condizione. Utilizzare il formato database_name.table_name per specificare un nome
di tabella completo.
Un filtro limitazioni è sempre persistente e viene ricreato quando l’ObjectServer
viene riavviato.
Esempio
create restriction filter myfilter on alerts.status where Severity = 5;
Suggerimento: È anche possibile creare filtri limitazioni nel Builder dei filtri.
Concetti correlati
“Convenzioni di denominazione per oggetti ObjectServer” a pagina 127
“Condizioni” a pagina 160
Eliminazione di un filtro limitazioni
Utilizzare il comando DROP RESTRICTION FILTER per eliminare un filtro
limitazioni esistente.
Non è possibile eliminare un filtro limitazioni nel caso in cui sia stato assegnato a
utenti oppure a gruppi.
Sintassi
DROP RESTRICTION FILTER filter_name;
Esempio
drop restriction filter myfilter;
144
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
File
I file ObjectServer sono oggetti di archiviazione definiti dall’utente per i dati di log
o di report.
Un file ObjectServer è un file logico al quale corrispondono uno o più file (serie di
file) sul file system fisico. È possibile definire le dimensioni dei file ObjectServer e
il numero di file fisici in una serie.
Creazione di un file
Utilizzare il comando CREATE FILE per creare un file ObjectServer.
Sintassi
CREATE [ OR REPLACE ] FILE file_name 'path_to_physical_file'
[ MAXFILES number_files ]
[ MAXSIZE file_size { GBYTES | MBYTES | KBYTES | BYTES } ];
Se vi è una possibilità che esista già un file ObjectServer con lo stesso nome di
quello che si desidera creare, utilizzare le parole chiave OR REPLACE facoltative.
Se il file Objectserver non esiste, ne viene creato uno nuovo. Se il file ObjectServer
esiste, viene sostituito da quello che si sta creando.
Nota: Se non si utilizzano le parole chiave OR REPLACE, è necessario specificare
un file fisico che ancora non esiste. Se si utilizzano le parole chiave OR REPLACE
e il file fisico esiste già, quest’ultimo viene sovrascritto se non vi è alcun file
ObjectServer associato ad esso.
Il nome del file deve essere univoco e conforme alle convenzioni di denominazione
dell’ObjectServer.
path_to_physical_file è il nome e il percorso completi del file corrispondente sul file
system fisico, ad esempio, /log/out.log. Sulle piattaforme Windows, è necessario
eseguire l’escape utilizzando il carattere barra retroversa (\) (ad esempio:
c:\\tmp\\testfile.txt) oppure utilizzare il percorso UNIX equivalente (ad
esempio: c:/tmp/testfile.txt).
È anche possibile impostare MAXFILES per specificare il numero di file della serie
di file. Il valore predefinito è 1. Se si imposta MAXFILES su un valore maggiore di
1, quando il primo file supera la dimensione massima, viene creato un nuovo file.
Quando quest’ultimo supera la dimensione massima, viene creato un altro file
nuovo e questo processo si ripete fino a quando non si raggiunge il numero
massimo di file all’interno della serie. Il file meno recente viene quindi eliminato e
il processo si ripete.
Nota: Un numero, che inizia con 1 e che viene incrementato sulla base del numero
di file presenti nella serie di file, viene sempre accodato al nome file specificato (o
all’estensione file, se presente).
Se si desidera, è possibile impostare MAXSIZE per specificare la dimensione file
massima. Dopo aver scritto nel file un record che soddisfa o supera quella
dimensione, viene creato un nuovo file. L’impostazione predefinita è 0. Se
impostata su 0, non vi è alcuna dimensione file massima, pertanto la serie di file
consiste sempre di un unico file.
La dimensione file minima è 1 KB. La dimensione massima è 4 GB.
Se l’ObjectServer viene riavviato, i nuovi dati vengono accodati al file esistente.
Capitolo 4. SQL ObjectServer
145
Esempio
create file logit '/log/logfile'
maxfiles 3
maxsize 20 KBytes;
Se si esegue questo comando di esempio, viene creata e utilizzata la seguente
sequenza di file:
1. L’ObjectServer crea nella directory /log un file vuoto che si chiama logfile1.
2. L’ObjectServer scrive dati nel file logfile1 fino a quando il file non supera la
dimensione file massima (20 KB).
3. L’ObjectServer rinomina logfile1 in logfile2. Successivamente, crea un nuovo
file denominato logfile1 e scrive in questo file fino a quando il file non supera
la dimensione massima.
4. L’ObjectServer rinomina il file logfile2 in logfile3 e rinomina il file logfile1
in logfile2. Successivamente, crea un nuovo file denominato logfile1 e scrive
in questo file fino a quando il file non supera la dimensione massima.
5. L’ObjectServer elimina il file meno recente (logfile3). Successivamente,
rinomina logfile2 in logfile3 e rinomina logfile1 in logfile2. Crea un
nuovo file denominato logfile1 e vi scrive fino a quando questo file non
supera la dimensione massima.
Questa sequenza si ripete fino a quando il file non viene modificato o rimosso.
Concetti correlati
“Convenzioni di denominazione per oggetti ObjectServer” a pagina 127
Modifica di un file
Utilizzare il comando ALTER FILE per modificare la configurazione di un file
ObjectServer esistente.
Sintassi
ALTER FILE file_name
TRUNCATE |
SET ENABLED { TRUE | FALSE };
L’impostazione TRUNCATE cancella qualsiasi informazione che è stata scritta sul
file fisico. Quando esiste più di un file fisico, il file in cui si sta scrivendo viene
troncato; gli altri file della serie vengono eliminati.
L’impostazione ENABLED attiva e disattiva la registrazione. Se TRUE, un
comando WRITE INTO scrive dati nel file. Se FALSE, i comandi WRITE INTO
vengono ignorati e non viene scritto nulla nel file. Disabilitare un file è utile
quando si desidera interrompere temporaneamente la registrazione, ma non si
desidera eliminare il file configurato.
Esempio
alter file logit truncate;
Riferimenti correlati
“Informazioni di registrazione nei file ObjectServer (comando WRITE INTO)” a
pagina 168
146
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Eliminazione di un file
Utilizzare il comando DROP FILE per eliminare un file ObjectServer esistente.
Non è possibile eliminare un file se utilizzato, ad esempio, in un trigger.
Sintassi
DROP FILE file_name;
Eliminando un file si elimina il file ObjectServer; i file fisici creati sul file system
non vengono rimossi.
Esempio
drop file logit;
Parole riservate
Nell’ObjectServer, alcune parole sono riservate come parole chiave ObjectServer o
SQL.
Le seguenti parole riservate non possono essere utilizzate per indicare nomi di
oggetti nell’SQL dell’ObjectServer:
Tabella 30. Parole riservate ObjectServer
ACTCMD
ADD
AFTER
ALL
ALTER
AND
ANY
APR[IL]
ARGUMENTS
ARRAY
AS
ASC
ASSIGN
AUG[UST]
AUTHORIZE |
AUTHORISE
AVERAGE | AVG
BACKUP
BEFORE
BEGIN
BETWEEN
BIDIRECTIONAL
BINARY
BIND
BOOL[EAN]
BREAK
BY
CACHE
CALL
CANCEL
CASE
CHAR[ACTER]
CHECK
CHECKPOINTING
COLUMN
COMMENT
COMMIT
CONN[ECTION]
COUNT
CREATE
CURRENT
DATABASE
DATE[TIME]
DEBUG
DEC[EMBER]
DECLARE
DEFERRED
DELAYED
DELETE
DESC
DESCENT
DESCRIBE
DETACHED
DISABLE
DIST
DISTINCT
DO
DOUBLE
DROP
EACH
EDGE
ELSE
ELSEIF
EMPTY
END
ENCRYPTED
EVALUATE
EVENT
EVERY
EVTFT
EXECUTABLE
EXEC[UTE]
EXTENSION
EXTERNAL
FALSE
FANP
FEB[RUARY]
FILE
FILTER
FLUSH
FOR
FORMAT
FRI[DAY]
FROM
FULL
GET
GETIDUC
GRANT
GROUP
HARD
HAVING
HIDDEN
HOST
HOURS
ID
IDUC
IF
IMMEDIATE
IN
INCLUDING
INCR
INCREMENT
INITIAL
INSERT
INT[EGER]
INT[EGER]64
INTO
ISQL
JAN[UARY]
JOIN
JUL[Y]
JUN[E]
LEAVE
LIKE
LIMIT
LINK
Capitolo 4. SQL ObjectServer
147
Tabella 30. Parole riservate ObjectServer (Continua)
LOAD
LOCK[PH]
LOGIN
MAR[CH]
MAX
MAXFILES
MAXSIZE
MAY
MEMSTORE
MESSAGE
METRIC
MIN
MINUTES
MON[DAY]
NAMING
NEXT
NO
NODEFAULT
NOMODIFY
NOT
NOTIFY
NOV[EMBER]
OCT[OBER]
OF
ON
ONCE
ONLY
OPTION
OR
ORDER
OUT
PAM
PASSWORD
PERSISTENT
PRIMARY
PRIORITY
PRIVILEGE
PROCEDURE
PROP[S]
PROTECT
PUBLISH
QUERY
RAISE
REAL
REGISTER
REINSERT
REMOVE
REPLACE
RESTRICTION
RESYNC
RETRY
REVOKE
ROLE
ROW
ROWOF
SAT[URDAY]
SAVE
SECONDS
SELECT
SELF
SEND
SEP[TEMBER]
SESSION
SET
SHORT
SHOW
SIGNAL
SKIP
SNDMSG
SOFT
SQL
STATEMENT
STORE
SUBSCRIBE
SUM
SUN[DAY]
SVC
SYNC
SYSTEM
TABLE
TEMPORAL
TEMP[ORARY]
THEN
THU[RSDAY]
TIME
TO
TOKEN
TOP
TRANS[ACTION]
TRANSIENT
TRIGGER
TRUE
TRUNCATE
TUE[SDAY]
TYPEOF
UNIDIRECTIONAL
UNION
UNIQUE
UNLOAD
UNREGISTER
UNSIGNED
UNSIGNED64
UNSUBSCRIBE
UNTIL
UPDATE
UPDATING
USE
USER
UTC
VALUES
VARCHAR[ACTER]
VERBOSE
VIA
VIEW
VIRTUAL
WAIT
WED[NESDAY]
WHEN
WHERE
WIDTH
WITH
WORK
WRITE
YES
XST
Blocchi di creazione SQL
Utilizzare i seguenti blocchi di creazione per manipolare dati nei comandi SQL
dell’ObjectServer: operatori, funzioni, espressioni e condizioni.
Operatori
È possibile utilizzare gli operatori per calcolare valori da elementi dati.
Un operatore elabora (aggiunge, sottrae e così via) uno o più elementi dati. Gli
elementi dati in base ai quali viene eseguito il calcolo, sono gli operandi. Insieme,
operatori e operandi formano le espressioni. Nell’espressione 7 + 3, il simbolo più
(+) è l’operatore, mentre i numeri 7 e 3 sono gli operandi.
Gli operatori possono essere unari o binari. Gli operatori unari agiscono su un solo
operando. Ad esempio, l’operatore meno (-) può essere utilizzato per indicare
negazione. Gli operatori binari agiscono su due operandi. Ad esempio, lo stesso
operatore meno (-) può essere utilizzato per sottrarre un operando da un altro
operando.
148
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Alcuni operatori come l’operatore più (+), ad esempio, sono polimorfici ed è
possibile assegnare loro un significato diverso in contesti diversi. Ad esempio, è
possibile utilizzare l’operatore più (+) per aggiungere due numeri (7+3) o per
concatenare due stringhe (’The ObjectServer ’ + ’started’).
Gli operatori utilizzati nell’SQL dell’ObjectServer si dividono nelle seguenti
categorie:
v Operatori aritmetici e stringa
v Operatori di confronto binario
v Operatori di confronto elenco
v Operatori logici
Concetti correlati
“Espressioni” a pagina 160
Operatori aritmetici e stringa
Utilizzare operatori aritmetici per aggiungere, sottrarre, moltiplicare e dividere
operandi numerici nelle espressioni. Utilizzare operatori stringa per manipolare
stringhe di caratteri (tipi di dati VARCHAR e CHAR).
La seguente tabella descrive gli operatori aritmetici supportati dall’ObjectServer:
Tabella 31. Operatori aritmetici
Operatore
Descrizione
+
Operatori unari che indicano SELECT * FROM london.status WHERE
un operando positivo o
Severity = -1;
negativo.
*
/
+
-
Esempio
Operatori binari utilizzati per SELECT * FROM london.status WHERE Tally
moltiplicare (*) o dividere (/) * Severity > 10;
due operandi.
Operatori binari utilizzati per SELECT * FROM london.status WHERE
aggiungere (+) o sottrarre (-) Severity = Old_Severity - 1;
due operandi.
La seguente tabella descrive l’operatore stringa supportato dall’ObjectServer:
Tabella 32. Operatore stringa
Operatore
Descrizione
Esempio
+
Operatore binario utilizzato
UPDATE mydb.mystatus SET Location = Node
per concatenare due stringhe. + NodeAlias;
Operatori di confronto binario
Utilizzare gli operatori di confronto binario per confrontare valori stringa e
numerici per determinare uguaglianze e disuguaglianze.
La seguente tabella descrive gli operatori di confronto supportati dall’ObjectServer:
Tabella 33. Operatori di confronto
Operatore
Descrizione
Esempio
=
Verifica le uguaglianze.
SELECT * FROM london.status WHERE
Severity = 3;
Capitolo 4. SQL ObjectServer
149
Tabella 33. Operatori di confronto (Continua)
Operatore
Descrizione
Esempio
!=
Verifica le disuguaglianze.
SELECT * FROM london.status WHERE
Severity <> 1;
Verifica i valori maggiore di
(>), minore di (<), maggiore
o uguale a (>=) oppure
minore o uguale a (<=).
SELECT * FROM london.status WHERE
Severity > 5;
<>
<
>
<=
>=
%=
%!=
%<>
%<
%>
%<=
%>=
Questi operatori eseguono
confronti di stringhe
rispettando la distinzione
maiuscolo/minuscolo. Nei
confronti con distinzione
maiuscolo/minuscolo ASCII
standard, le lettere maiuscole
vengono prima di quelle
minuscole.
Verifica l’uguaglianza (%=) o SELECT * FROM london.status WHERE
la disuguaglianza (%!=, %<>) Location %= 'New York';
tra stringhe, senza rispettare
la distinzione
maiuscolo/minuscolo. Per
essere considerate uguali, le
stringhe devono contenere
tutte gli stessi caratteri, nello
stesso ordine, ma non
necessariamente con lo stesso
uso delle maiuscole.
SELECT * FROM london.status WHERE
Confronta la relazione
site_code %< 'UK3';
lessicografica tra due
stringhe, senza rispettare la
distinzione
maiuscolo/minuscolo.
Questo confronto determina
se le stringhe vengono prima
(%<) o dopo (%>) altre
stringhe da un punto di vista
alfabetico. È anche possibile
trovare stringhe che sono
minori o uguali a (%<=) o
maggiori o uguali ad (%>=)
altre stringhe.
Ad esempio, aaa viene prima
di AAB perché da un punto di
vista alfabetico aaa è minore
di (viene prima) AAB quando
non si opera alcuna
distinzione
maiuscolo/minuscolo.
150
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 33. Operatori di confronto (Continua)
Operatore
Descrizione
Esempio
[NOT] LIKE
L’operatore LIKE esegue
confronti di stringhe. La
stringa successiva
all’operatore LIKE, che può
essere il risultato di
un’espressione regolare, è il
modello con il quale viene
confrontata l’espressione di
colonna. Un’espressione
regolare può includere il
modello che soddisfa la
sintassi descritta in IBM
Tivoli Netcool/OMNIbus User’s
Guide.
SELECT * FROM london.status WHERE
Summary LIKE 'down';
Il risultato è tutte le righe in cui Summary
contiene la sottostringa down.
La parola chiave NOT
inverte il risultato del
confronto.
Gli operatori di confronto LIKE e NOT LIKE consentono il confronto tra la
corrispondenza di modelli di espressioni regolari e l’espressione di colonna. Le
espressioni regolari sono sequenze di atomi che si compongono di caratteri normali
e metacaratteri. Un atomo è un singolo carattere o un modello di uno o più
caratteri tra parentesi. I caratteri normali includono lettere maiuscole, lettere
minuscole e numeri. I metacaratteri sono caratteri non alfabetici che hanno un
significato speciale nelle espressioni regolari. L’ObjectServer supporta due tipi di
librerie di espressioni regolari:
v NETCOOL: utilizzare questa libreria predefinita per l’elaborazione di caratteri a
byte singolo.
v TRE: questa libreria consente l’utilizzo della sintassi per espressioni regolari
estese POSIX 1003.2 e fornisce supporto per lingue con caratteri a byte singolo e
a più byte.
Per ulteriori informazioni su queste librerie e per le descrizioni dei formati di
sintassi delle espressioni regolari ed esempi di utilizzo, consultare IBM Tivoli
Netcool/OMNIbus User’s Guide.
Operatori di confronto elenco
Utilizzare gli operatori di confronto elenco per confrontare un valore con un elenco
di valori.
Le condizioni che adottano gli operatori di confronto elenco utilizzano gli operatori
di confronto binario con gli operatori logici (ANY, ALL, IN o NOT IN).
La sintassi di un’espressione di confronto elenco è:
expression comparison_operator { ANY | ALL } ( expression,... )
oppure
expression [ NOT ] IN ( expression,... )
Se si utilizza la parola chiave ANY, la condizione di confronto elenco assume il
valore TRUE se il confronto tra l’espressione sul lato sinistro e le espressioni sul
lato destro restituisce TRUE per uno qualsiasi dei valori. Se si utilizza la parola
Capitolo 4. SQL ObjectServer
151
chiave ALL, la condizione di confronto elenco assume il valore TRUE se il
confronto tra l’espressione sul lato sinistro e le espressioni sul lato destro restituisce
TRUE per tutti i valori.
Un confronto IN restituisce gli stessi risultati di un confronto =ANY. Un confronto
NOT IN restituisce gli stessi risultati di un confronto <>ANY.
Limitazione: Gli operatori ANY e ALL non sono supportati nelle sottoquery.
Esempio
La seguente query restituisce le righe in cui Severity - 1 è uguale al valore di
Old_Severity o al numero 5.
select * from mystatus where Severity - 1 IN (Old_Severity, 5)
Concetti correlati
“Operatori di confronto binario” a pagina 149
“Operatori logici”
Operatori logici
È possibile utilizzare operatori logici su valori booleani per creare espressioni che
vengono risolte in TRUE o FALSE.
L’ObjectServer supporta i seguenti operatori:
v NOT
v AND
v OR
È possibile combinare confronti utilizzando gli operatori logici.
Le tabelle di veridicità riportate di seguito mostrano i risultati di operazioni
logiche su valori booleani. Nelle tabelle di veridicità di esempio, A e B
rappresentano un valore o un’espressione qualsiasi.
Una espressione NOT è TRUE solo se il suo input è FALSE, come mostrato nella
seguente tabella:
Tabella 34. Tabella di veridicità per l’operatore NOT
A
NOT A
FALSE
TRUE
TRUE
FALSE
Una espressione AND è ″true″ solo se tutti i suoi input sono TRUE, come mostrato
nella seguente tabella:
Tabella 35. Tabella di veridicità per l’operatore AND
152
A
B
A AND B
FALSE
FALSE
FALSE
FALSE
TRUE
FALSE
TRUE
FALSE
FALSE
TRUE
TRUE
TRUE
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Una espressione OR è TRUE se uno qualsiasi dei suoi input è TRUE, come
mostrato nella seguente tabella:
Tabella 36. Tabella di veridicità per l’operatore OR
A
B
A OR B
FALSE
FALSE
FALSE
FALSE
TRUE
TRUE
TRUE
FALSE
TRUE
TRUE
TRUE
TRUE
Esempio
La seguente query combina confronti utilizzando operatori logici:
SELECT * from alerts.status where Node = 'node1' and Severity > 4 and
Summary like 'alert on .*'
Esempio
La seguente query restituisce tutte le righe della tabella t1 in cui il valore per col1
non è uguale a 0:
select * from t1 where NOT(col1 = 0);
Precedenza degli operatori
Se un’espressione contiene più operatori, l’ObjectServer utilizza la precedenza degli
operatori per determinare l’ordine in cui valutare l’espressione.
Gli operatori vengono valutati secondo un ordine preciso: vengono valutati prima
gli operatori con la precedenza più alta, poi quelli con la precedenza più bassa. Ad
esempio, l’operatore binario più (+) ha una precedenza più bassa rispetto
all’operatore di moltiplicazione (*). Nell’espressione 3 + 5 * 2, il risultato è 13, in
quanto viene eseguita innanzitutto la moltiplicazione tra i numeri 5 e 2, dopo di
che viene eseguita l’addizione tra il risultato della moltiplicazione (10) e il numero
3.
Utilizzare le parentesi in un’espressione per modificare l’ordine in cui vengono
valutati gli elementi. Il contenuto delle parentesi viene sempre valutato prima di
qualsiasi altra informazione presente all’esterno delle parentesi. Nell’espressione (3
+ 5) * 2, il risultato è 16 perché viene eseguita innanzitutto l’addizione tra i
numeri 3 e 5, dopo di che viene eseguita la moltiplicazione tra il risultato
dell’addizione (8) e il numero 2.
Se gli operatori hanno la stessa precedenza, vengono valutati in ordine da sinistra
verso destra. La seguente tabella mostra l’ordine di precedenza di tutti gli
operatori ObjectServer.
Tabella 37. Precedenza degli operatori
Precedenza più alta
Unario + Aritmetico * /
Binario + Operatori di confronto (inclusi gli operatori di confronto elenco)
NOT
Capitolo 4. SQL ObjectServer
153
Tabella 37. Precedenza degli operatori (Continua)
AND
OR
Precedenza più bassa
Funzioni
Una funzione elabora uno o più elementi dati in un comando SQL e restituisce un
valore.
La notazione della sintassi per una funzione è:
function(
operand,...)
Suggerimento: Le parentesi sono facoltative se non ci sono operandi nella
funzione.
La seguente tabella descrive le funzioni supportate dall’ObjectServer:
Tabella 38. Funzioni ObjectServer
Funzione
Descrizione
Esempio
array_len(array)
Restituisce il numero di elementi in
un array. Questa funzione può essere
utilizzata solo nelle procedure o nei
trigger.
Se l’array myarray ha dieci elementi,
array_len(myarray) restituisce 10.
ceil(real)
Accetta un argomento di tipo real e
restituisce il valore integrale più
piccolo che non sia minore
dell’argomento.
ceil(2.01) restituisce 3.000000
dayasnum(time)
Accetta un argomento di tipo time ed select dayasnum(LastOccurrence) from mytab;
estrae il giorno della settimana come
Domenica è 0, lunedì è 1 e così via.
numero intero. Se non si specifica
nessun argomento, si presuppone che
l’argomento sia la data corrente.
dayname(time)
Accetta un argomento di tipo time e
restituisce il nome del giorno. Se non
si specifica nessun argomento, si
presuppone che l’argomento sia la
data corrente.
select dayname(LastOccurrence) from mytab;
L’output è Monday, Tuesday e così via.
dayofmonth(time)
Accetta un argomento di tipo time ed select dayofmonth(LastOccurrence) from mytab;
estrae il giorno del mese come
numero intero. Se non si specifica
nessun argomento, si presuppone che
l’argomento sia la data corrente.
dayofweek(time)
Accetta un argomento di tipo time ed select dayofweek(LastOccurrence) from mytab;
estrae il giorno della settimana come
A differenza di dayasnum, domenica è 1, lunedì è 2
numero intero. Se non si specifica
nessun argomento, si presuppone che e così via.
l’argomento sia la data corrente.
154
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 38. Funzioni ObjectServer (Continua)
Funzione
Descrizione
Esempio
getdate()
Non accetta alcun argomento e
restituisce la data e l’ora correnti
come valore UTC (Coordinated
Universal Time) (il numero di
secondi a partire dal primo gennaio
1970).
Per restituire tutte le righe nella tabella
alerts.status inserite da più di dieci minuti:
getenv(string)
Restituisce il valore della variabile di
ambiente specificata come stringa.
getenv('NCHOME') restituisce un nome di directory,
ad esempio, /opt/netcool.
get_prop_value(string)
Restituisce il valore della proprietà
get_prop_value('Name') restituisce il nome
ObjectServer specificata come stringa. dell’ObjectServer, ad esempio, NCOMS.
getservername()
Non accetta alcun argomento e
restituisce il nome dell’ObjectServer
come stringa.
hourofday(time)
Accetta un argomento di tipo time ed select hourofday(LastOccurrence) from mytab;
estrae l’ora del giorno come numero
intero. Se non si specifica nessun
argomento, si presuppone che
l’argomento sia l’orario corrente.
instance_of(class,
parent_class)
Restituisce TRUE se class è una
sottoclasse di parent_class oppure se
sono uguali, utilizzando la gerarchia
definita nella tabella
master.class_membership. In caso
contrario, restituisce FALSE.
select Summary, Severity from alerts.status
where LastOccurrence < getdate - 600;
select LastOccurrence from alerts.status
where ServerName = getservername();
select Node, Summary, AlertGroup,
Server from alerts.status
where instance_of(Class, 'DB2') = true;
Le variabili class e parent_class
possono essere una stringa o un
numero intero.
is_env_set(string)
Quando la variabile di ambiente NCHOME è
Restituisce 1 se la variabile di
ambiente specificata è impostata, 0 in impostata, is_env_set('NCHOME') restituisce 1.
caso contrario.
log_2(real)
Accetta un argomento di tipo real
positivo e restituisce il logaritmo con
base 2.
lower(string)
Converte un argomento di tipo string lower('LIMA') restituisce lima
in caratteri minuscoli.
ltrim(string)
Rimuove gli spazi a sinistra di una
stringa.
minuteofhour(time)
Accetta un argomento di tipo time ed select minuteofhour(LastOccurrence) from
mytab;
estrae il minuto dell’ora come
numero intero. Se non si specifica
nessun argomento, si presuppone che
l’argomento sia l’orario corrente.
mod(int1,int2)
Restituisce il resto di tipo integer di
int1 diviso per int2.
monthasnum(time)
Accetta un argomento di tipo time ed select monthasnum(LastOccurrence) from mytab;
estrae il mese dell’anno come numero
Gennaio è 0, febbraio è 1 e così via.
intero. Se non si specifica nessun
argomento, si presuppone che
l’argomento sia la data corrente.
log_2(4.0) restituisce 2.000000
ltrim(' tree') restituisce tree.
mod(12,5) restituisce 2
Capitolo 4. SQL ObjectServer
155
Tabella 38. Funzioni ObjectServer (Continua)
Funzione
Descrizione
Esempio
monthname(time)
Accetta un argomento di tipo time e
restituisce il nome del mese. Se non
si specifica nessun argomento, si
presuppone che l’argomento sia la
data corrente.
select monthname(LastOccurrence) from mytab;
Accetta un argomento di tipo time ed
estrae il mese dell’anno come numero
intero. Se non si specifica nessun
argomento, si presuppone che
l’argomento sia la data corrente.
select monthofyear(LastOccurrence) from
mytab;
Verifica l’esistenza di una coppia
nome-valore.
nvp_exists(ExtendedAttr, 'Region')
monthofyear(time)
nvp_exists(
string_nameval_pairs,
string_name)
Utilizzata con attributi estesi.
string
nvp_get(string
name_value_pairs,
string key)
Richiama il valore di name in una
coppia valore-nome.
L’output è January, February e così via.
A differenza di monthasnum, gennaio è 1, febbraio
è 2 e così via.
Restituisce TRUE se ’Region’ è presente negli
attributi estesi come nome di una coppia
nome-valore. Se il nome non esiste, la funzione
restituirà FALSE.
nvp_get(ExtendedAttr, 'Region')
Restituisce l’attributo ’Region’.
Se il nome è presente nell’attributo, la
funzione restituisce il valore.
Se name_value_pairs non è valido,
viene restituita la stringa vuota e
viene registrato un errore.
Se key non è presente, viene restituita
la stringa vuota (’’).
Se ci sono più voci per il nome, viene
restituita la prima.
string
nvp_set(string
name_value_pairs,
string key,
any value)
ExtendedAttr = nvp_set(ExtendedAttr,
Sostituisce o aggiunge una coppia
nome-valore a una stringa di coppia 'Region', 'EMEA');
nome-valore. Restituisce una nuova
stringa di coppia nome-valore con la Imposta l’attributo ’Region’ negli attributi estesi.
nuova coppia nome-valore aggiunta o
sostituita.
Aggiunge o sostituisce chiavi da una
stringa di coppia nome-valore e
restituisce la nuova stringa di coppia
nome-valore. Viene memorizzata una
data in secondi a partire dal 1970,
ossia il formato epoca UNIX.
Se name_value_pairs non è una stringa
valida (ossia non è una stringa vuota
o contiene voci che non sono
conformi al formato corretto), viene
restituito $key=″$value″ e viene
registrato un errore.
Se ci sono più voci per la chiave,
viene sostituita solo la prima.
power(real1, real2)
156
Accetta due argomenti di tipo real e
restituisce real1 elevato alla potenza
di real2.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
power(2.0, 3.0) restituisce 8.000000
Tabella 38. Funzioni ObjectServer (Continua)
Funzione
Descrizione
Esempio
rtrim(string)
Rimuove gli spazi alla destra di una
stringa.
rtrim('tree ') restituisce tree.
secondofminute(time)
Accetta un argomento di tipo time ed select secondofminute(LastOccurrence) from
estrae il secondo del minuto come
mytab;
numero intero. Se non si specifica
nessun argomento, si presuppone che
l’argomento sia l’orario corrente.
split_multibyte(
string_message,
int_chunk_no,
int_chunk_len)
Vedere l’esempio riportato dopo questa tabella.
Restituisce la stringa a più byte
completa strout composta al massimo
di int_chunk_len byte, a partire dal
byte (int_chunk_no -1) * int_chunk_len
del messaggio di stringa.
Se a causa della suddivisione un
carattere a più byte risulterà
incompleto nella stringa di
destinazione, la funzione restituisce la
stringa completa con la massima
estensione possibile. La successiva
chiamata alla funzione (sempre che
int_chunk_len sia come nella chiamata
precedente) avrà inizio dal carattere
che non è stato possibile estrarre
completamente.
La funzione suddividerà una stringa
a più byte in stringhe più piccole che
contengono solo caratteri a più byte
completi. Questa soluzione è stata
concepita essenzialmente per
memorizzare stringhe di grandi
dimensioni in più campi di database
di dimensioni inferiori.
La int_chunk_len in tutte le chiamate
alla funzione split sulla stessa
stringa deve essere la stessa.
substr(string_message,
int_startpos, int_len)
Estrae una sottostringa, partendo
dalla posizione specificata nel
secondo parametro, per il numero di
caratteri specificati dal terzo
parametro. La stringa viene
indicizzata da 1.
substr('abcdefg', 2, 3) restituisce bcd, partendo
dal secondo carattere, restituendo i successivi 3
caratteri.
to_char(argument [,
conversion_spec])
Converte l’argomento in una stringa.
L’argomento può essere di qualsiasi
tipo di dati, ad eccezione del tipo
string.
to_char(73) restituisce 73
to_char(FirstOccurrence) restituisce una stringa
quale, ad esempio, Thu Dec 11 16:02:05 2003
Se l’argomento è di tipo time, è
possibile fornire un secondo
argomento che consiste di una
specifica di conversione per
formattare l’output. Questo formato è
determinato dalla funzione POSIX
strptime. Il formato predefinito è %a
%b %d %T %Y.
Capitolo 4. SQL ObjectServer
157
Tabella 38. Funzioni ObjectServer (Continua)
Funzione
Descrizione
Esempio
to_int(argument)
Converte l’argomento in un numero
intero. L’argomento può essere di
qualsiasi tipo di dati, ad eccezione
del tipo integer.
to_int(’73’) restituisce 73
Questa funzione elimina
dall’argomento tutti gli spazi iniziali,
quindi esegue la scansione della
restante stringa. La scansione si
interrompe quando rileva un
carattere che non può essere
convertito in un carattere decimale
oppure quando raggiunge la fine
della stringa. Quando la scansione si
interrompe, la funzione converte i
caratteri nel loro valore decimale
oppure restituisce 0 se non è riuscita
a trovare caratteri che possano essere
convertiti in valori decimali.
to_int(’3F’) restituisce 3
to_int(’UK’) restituisce 0
to_int(’F3’) restituisce 0
to_real(argument)
to_real('7.3') restituisce 7.300000
Converte l’argomento in un numero
reale a 64 bit. L’argomento può essere
di qualsiasi tipo di dati, ad eccezione to_real('3F') restituisce 3.000000
del tipo real.
to_real('UK') restituisce 0
Questa funzione elimina
dall’argomento tutti gli spazi iniziali, to_real(’F3’) restituisce 0
quindi esegue la scansione della
restante stringa. La scansione si
interrompe quando rileva un
carattere che non può essere
convertito in un carattere decimale
oppure quando raggiunge la fine
della stringa. Quando la scansione si
interrompe, la funzione converte i
caratteri nel loro valore decimale
oppure restituisce 0 se non è riuscita
a trovare caratteri che possano essere
convertiti in valori decimali.
to_time(argument [,
conversion_spec])
Converte l’argomento in un tipo di
dati time. L’argomento può essere di
qualsiasi tipo di dati, ad eccezione
del tipo time.
to_date(argument [,
conversion_spec])
Se l’argomento è di tipo string, è
possibile fornire un secondo
argomento che consiste di una
specifica di conversione per
formattare l’output. Questo formato è
determinato dalla funzione POSIX
strptime. Il formato predefinito è %a
%b %d %T %Y.
158
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
update mytab set my_utc_col = to_time('Thu
Dec 11 16:00:00 2003')
Tabella 38. Funzioni ObjectServer (Continua)
Funzione
Descrizione
Esempio
to_unsigned(argument)
Converte l’argomento in un numero
intero a 64 bit senza segno.
L’argomento può essere di qualsiasi
tipo di dati, ad eccezione del tipo
integer senza segno.
to_unsigned(’73’) restituisce 73
Questa funzione elimina
dall’argomento tutti gli spazi iniziali,
quindi esegue la scansione della
restante stringa. La scansione si
interrompe quando rileva un
carattere che non può essere
convertito in un carattere decimale
oppure quando raggiunge la fine
della stringa. Quando la scansione si
interrompe, la funzione converte i
caratteri nel loro valore decimale
oppure restituisce 0 se non è riuscita
a trovare caratteri che possano essere
convertiti in valori decimali.
to_unsigned(73) restituisce 73
to_unsigned(’UK’) restituisce 0
to_unsigned(’F3’) restituisce 0
upper(string)
Converte un argomento di tipo string upper('Vancouver') restituisce VANCOUVER
in caratteri maiuscoli.
year(time)
Accetta un argomento di tipo time ed select year(LastOccurrence) from mytab;
estrae l’anno come numero intero. Se
non si specifica nessun argomento, si
presuppone che l’argomento sia la
data corrente.
Esempio: Utilizzo di split_multi-byte
for each row res_filter in catalog.restrictions where
res_filter.RestrictionName = rf_users.RestrictionName
begin
-- Populate master.profile with the new row.
-- Cut up the filter text into 255 byte chunks
update master.profiles set HasRestriction = 1,
Restrict1 = split_multibyte( res_filter.ConditionText,
Restrict2 = split_multibyte( res_filter.ConditionText,
Restrict3 = split_multibyte( res_filter.ConditionText,
Restrict4 = split_multibyte( res_filter.ConditionText,
Where UID = rf_users.GranteeID;
end;
1,
2,
3,
4,
255),
255),
255),
255)
In questo esempio:
A Restrict1 vengono assegnati al massimo 255 byte di res.filter.ConditionText a
partire dal byte 1
A Restrict2 vengono assegnati al massimo 255 byte di res.filter.ConditionText a
partire dal byte (2-1) * 255
A Restrict1 vengono assegnati al massimo 255 byte di res.filter.ConditionText a
partire dal byte (3-1) * 255
A Restrict1 vengono assegnati al massimo 255 byte di res.filter.ConditionText a
partire dal byte (4-1) * 255
Capitolo 4. SQL ObjectServer
159
Riferimenti correlati
“Tabella alerts.status” a pagina 311
“Tabella master.class_membership” a pagina 321
Espressioni
Un’espressione è una combinazione sintattica di valori e di operazioni creata per
calcolare nuovi valori. Le espressioni possono essere semplici o complesse.
Espressioni semplici
Un’espressione semplice è un valore di una costante o di una variabile, un nome di
una colonna o un riferimento di una variabile. Può essere una delle seguenti entità:
v Una stringa racchiusa tra virgolette ('Node XB1')
v Un numero (9)
v Un nome di colonna (Severity)
v Una proprietà ObjectServer (ServerName)
v Una variabile di ambiente (NCHOME)
v Una variabile che contiene un valore temporaneo in una procedura oppure in un
trigger
Espressioni complesse
Un’espressione complessa viene creata da espressioni semplici combinate
utilizzando operatori (Severity - 1) e funzioni SQL (get_prop_value(ServerName)).
È possibile combinare espressioni semplici o complesse con altre espressioni
semplici o complesse per creare espressioni sempre più complesse, ad esempio
-(Severity + Tally).
Nota: Le espressioni complesse sono soggette a vincoli relativi ai tipi di dati. Ad
esempio, l’espressione 5 * 'Node XB1' non è valida, in quanto non è possibile
moltiplicare un numero intero per una stringa.
Riferimenti correlati
“Specifica dei tipi di dati per le colonne” a pagina 133
Condizioni
Una condizione è una combinazione di espressioni e di operatori che acquisiscono
il valore TRUE o FALSE.
È possibile utilizzare condizioni per ricercare, filtrare e verificare le righe in:
v Filtri limitazioni
v La clausola WHERE dei comandi SELECT, UPDATE e DELETE
v La clausola HAVING del comando SELECT GROUP BY
v La clausola WHEN nei trigger
v Le istruzioni IF THEN ELSE, CASE WHEN e FOR EACH ROW nelle procedure
e nei trigger
Le condizioni possono contenere operatori di confronto (Severity < 3), operatori
logici (NOT(Is_Enabled)) e operatori di confronto elenco (Severity IN ANY(0,5)).
Nel seguente elenco vengono riportate le condizioni valide:
160
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
TRUE | FALSE
( condition )
NOT condition
condition AND condition
condition OR condition
expression operator expression
expression operator ANY ( expression, ... )
expression operator ALL ( expression, ... )
expression[ NOT ] IN( subquery )
expression operator ANY ( subquery )
expression [ NOT ] IN ( expression, ... )
expression [ NOT ] LIKE regexp_pattern
expression [ NOT ] LIKE ANY ( regexp_pattern, ... )
expression [ NOT ] LIKE ALL ( regexp_pattern, ... )
Nota: Gli operatori ANY e ALL non sono supportati nelle sottoquery.
È possibile combinare condizioni per creare condizioni sempre più complesse.
Esempio
(Severity > 4) AND (Node = 'node%')
Il seguente esempio mostra l’uso di una condizione in una sottoquery:
select * from alerts.status where Serial in (select Serial from alerts.journal);
Concetti correlati
“Operatori di confronto binario” a pagina 149
“Operatori di confronto elenco” a pagina 151
“Operatori logici” a pagina 152
“Espressioni” a pagina 160
Riferimenti correlati
“Creazione di trigger di database (comando CREATE TRIGGER)” a pagina 198
Ricerca e manipolazione dei dati utilizzando l’SQL dell’ObjectServer
È possibile utilizzare comandi DML (Data Manipulation Language) per ricercare e
manipolare dati negli oggetti di database esistenti
L’SQL dell’ObjectServer fornisce i seguenti comandi per manipolare dati.
Tabella 39. Oggetti ObjectServer e comandi DML associati
Oggetto ObjectServer
Comandi DML consentiti
TABLE
SELECT
INSERT
UPDATE
DELETE
DESCRIBE
SVC
VIEW
SELECT
DESCRIBE
SVC
Capitolo 4. SQL ObjectServer
161
Tabella 39. Oggetti ObjectServer e comandi DML associati (Continua)
Oggetto ObjectServer
Comandi DML consentiti
FILE
WRITE INTO
Suggerimento: Filtri limitazioni vengono applicati in maniera automatica nei
comandi SELECT, INSERT, UPDATE e DELETE.
Inserimento di una nuova riga di dati in una tabella (comando
INSERT)
Utilizzare il comando INSERT per inserire una nuova riga di dati in una tabella
esistente.
Sintassi
INSERT INTO [database_name.]table_name
[ (column_name,...) ] VALUES (expression,...);
È necessario specificare un valore per ogni colonna chiave primaria nella tabella.
Se si inseriscono valori per ogni colonna della riga, specificare la parola chiave
VALUES seguita da un elenco di valori di colonna separati da virgole e racchiusi
tra parentesi. Immettere i valori nell’ordine delle colonne sequenziale.
Se non si inseriscono valori per ciascuna colonna della riga, specificare l’elenco di
colonne da inserire tra parentesi separate da virgole, seguito dalla parola chiave
VALUES, seguita, a sua volta, da un elenco di valori di colonne separati da virgole
e racchiusi tra parentesi. Immettere i valori nella stessa sequenza delle colonne
specificate. In tutte le altre colonne vengono inseriti valori predefiniti.
Suggerimento: Non è possibile assegnare valori a colonne gestite dal sistema, ad
esempio Serial.
Esempio
Per inserire un avviso nella tabella mydb.mystatus specificando i valori nelle
colonne indicate, immettere:
insert into mydb.mystatus (Identifier, Severity, LastOccurrence)
values ('MasterMachineStats15', 5, getdate);
Aggiornamento dei dati nelle colonne di tabella (comando
UPDATE)
Utilizzare il comando UPDATE per aggiornare una o più colonne in una riga di
dati esistente all’interno di una tabella.
Sintassi
UPDATE [database_name.]object_name
[ VIA (value_of_primary_key_column,...) ]
SET column_name = expression,...
[ WHERE condition ];
Non è possibile aggiornare colonne gestite dal sistema (ad esempio, Serial) o
colonne per cui la proprietà NOMODIFY è impostata su TRUE. Quando la proprietà
NOMODIFY è impostata su TRUE, il valore di una colonna non può essere
modificato dopo il comando INSERT iniziale.
162
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Se occorre aggiornare una singola riga di cui si conosce il valore della chiave
primaria, specificare il valore utilizzando la clausola VIA facoltativa per migliorare
le prestazioni del comando di aggiornamento. Se c’è più di una colonna chiave
primaria, i valori devono essere specificati nell’ordine in cui vengono riportati,
separati da virgole e racchiusi tra parentesi. Le colonne che hanno valori stringa
devono essere racchiuse tra virgolette.
Se si include una clausola WHERE, vengono aggiornate solo le righe che
soddisfano i criteri specificati nella condition. Se nella clausola WHERE non è
specificata alcuna condizione, vengono aggiornate tutte le righe.
Esempi
Per impostare Severity su 0 per le righe della tabella alerts.status in cui Node è
uguale a Fred, immettere:
update alerts.status set Severity = 0 where Node = ’Fred’;
È possibile utilizzare valori di colonna nei calcoli. Nel seguente esempio, Severity
viene impostato su 0 quando un avviso è stato riconosciuto:
update status set Severity=(1-Acknowledged)*Severity;
Per ricercare righe in cui Severity è uguale a 1 e Node è uguale a Fred, quindi
impostare Severity su 0 e modificare il campo Summary nella stringa Discarded,
immettere:
update alerts.status set Severity = 0, Summary = ’Discarded’
where Severity = 1 and Node = ’Fred’;
Concetti correlati
“Condizioni” a pagina 160
Riferimenti correlati
“Inserimento di una nuova riga di dati in una tabella (comando INSERT)” a pagina
162
Eliminazione di righe di dati da una tabella (comando
DELETE)
Utilizzare il comando DELETE per eliminare una o più righe di dati da una tabella
esistente.
Sintassi
DELETE FROM [database_name.]object_name
[ VIA ('value_of_primary_key_column',...) ]
[ WHERE condition ];
Se occorre eliminare una singola riga di cui si conosce il valore della chiave
primaria, specificare il valore utilizzando la clausola VIA facoltativa per migliorare
le prestazioni del comando di eliminazione. Se c’è più di una colonna chiave
primaria, è necessario specificare i valori nell’ordine indicato, separati da virgole e
tra parentesi. Se la colonna ha un valore stringa, deve essere racchiusa tra
virgolette.
Se si include una clausola WHERE, vengono eliminate solo le righe che soddisfano
i criteri specificati in condition. Se non si specifica alcuna clausola WHERE,
vengono eliminate tutte le righe.
Capitolo 4. SQL ObjectServer
163
Esempio
Per rimuovere tutte le righe della tabella alerts.status in cui il valore del campo
Node è uguale a Fred, immettere:
delete from alerts.status where Node = ’Fred’ ;
Concetti correlati
“Condizioni” a pagina 160
Richiamo di dati da una tabella o da una vista (comando
SELECT)
Utilizzare il comando SELECT per richiamare una o più righe, o righe parziali, di
dati da una tabella o da una vista esistente e per eseguire funzioni di
raggruppamento sui dati.
È possibile utilizzare il comando SELECT per effettuare le seguenti azioni:
v Richiamare i dati che soddisfano un criterio specificato (SELECT scalare)
v Restituire un singolo valore che si basa su un calcolo su un numero di righe
(SELECT di aggregazione)
v Raggruppare tutte le righe che contengono valori identici in una o più colonne
ed eseguire funzioni di aggregazione sulle colonne (SELECT di raggruppamento)
SELECT di base (scalare)
Il comando SELECT scalare richiama colonne e righe da una tabella sulla base di
criteri specificati.
Sintassi
SELECT [ TOP num_rows ] { * | scalar_column_expr [ AS alias_name ],... }
FROM [ database_name.]object_name
[ WHERE condition ]
[ ORDER BY column_name_or_alias [ ASC | DESC ] ,... ];
Utilizzare la parola chiave TOP facoltativa per visualizzare solo le prime num_rows
righe dei risultati della query che soddisfano ai criteri di selezione. Se si include la
parola chiave TOP, è necessario includere anche una clausola ORDER BY per
ordinare le righe selezionate.
Utilizzare un asterisco (*) per richiamare tutte le colonne non nascoste nella tabella.
Altrimenti, è possibile specificare un elenco di colonne separate da una virgola che
si desidera richiamare, oppure creare virtual columns utilizzando:
v Espressioni semplici (ad esempio, Severity)
v Espressioni complesse che contengono operatori aritmetici o stringa (ad esempio,
Severity + Tally)
v Funzioni (ad esempio, getdate - 60)
Seguendo una colonna o una colonna virtuale, è possibile includere la parola
chiave AS seguita da un alias. Questo alias è un’intestazione di sostituzione per il
nome della colonna o della colonna virtuale e viene visualizzato nei risultati delle
query. Se si specifica un alias di colonna, utilizzare questo alias in qualsiasi
riferimento nella clausola ORDER BY. La lunghezza massima di un alias o nome di
colonna è 40 caratteri.
Se si include una clausola WHERE, vengono restituite solo le righe che soddisfano
i criteri specificati in condition.
164
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Utilizzare la clausola ORDER BY facoltativa per visualizzare i risultati nell’ordine
sequenziale a seconda dei valori di uno o più nomi di colonna, nell’ordine
discendente (DESC) o ascendente (ASC). Se non si specifica la clausola ORDER BY,
non viene utilizzato alcun ordine. Se è stato specificato un alias di colonna
utilizzando la parola chiave AS, utilizzare questo alias in qualsiasi riferimento
nell’elenco di colonna ORDER BY anziché nel nome di colonna corrispondente.
Esempi
Il seguente esempio seleziona tutte le righe della tabella alerts.status in cui la
severità è uguale a 4:
select * from alerts.status where Severity = 4;
Il seguente esempio seleziona tutte le righe della tabella alerts.status in cui Node
contiene la stringa terminal seguita da qualsiasi altro carattere:
select * from alerts.status where Node like 'terminal.*';
Nell’esempio precedente, la sintassi delle espressioni regolari viene utilizzata nel
confronto LIKE. Per informazioni sulla sintassi delle espressioni regolari utilizzata
nel confronto LIKE, vedere l’appendice sulle espressioni regolari in IBM Tivoli
Netcool/OMNIbus User’s Guide.
Nel seguente esempio, la colonna virtuale Severity + Tally viene popolata
mettendo insieme i valori delle due colonne:
select Severity, Severity + Tally from alerts.status;
Il seguente esempio è uguale all’esempio precedente, ad eccezione del fatto che la
colonna virtuale Severity + Tally viene rinominata in Real_Severity.
select Severity, Severity + Tally as Real_Severity from alerts.status;
Concetti correlati
“Condizioni” a pagina 160
“Espressioni” a pagina 160
“Funzioni” a pagina 154
“Operatori aritmetici e stringa” a pagina 149
SELECT di aggregazione
Un comando SELECT di aggregazione esegue un calcolo su un numero di righe e
restituisce un singolo valore.
Sintassi
SELECT aggr_expression [ AS alias_name ],...
FROM [database_name.]table_name
[ WHERE condition ];
Sono supportate le seguenti funzioni di aggregazione (rappresentate dal
aggr_expression nella sintassi):
Tabella 40. Funzioni di aggregazione
Funzione
Risultato restituito
max(scalar_column_expr)
Restituisce il valore numerico massimo per
l’espressione di colonna dalle righe che
soddisfano la condizione di SELECT.
Capitolo 4. SQL ObjectServer
165
Tabella 40. Funzioni di aggregazione (Continua)
Funzione
Risultato restituito
min(scalar_column_expr)
Restituisce il valore numerico minimo per
l’espressione di colonna dalle righe che
soddisfano la condizione di SELECT.
avg(scalar_column_expr)
Restituisce il valore numerico medio per
l’espressione di colonna dalle righe che
soddisfano la condizione di SELECT.
sum(scalar_column_expr)
Restituisce la somma (totale) dei valori
numerici per l’espressione di colonna dalla
righe che soddisfano la condizione SELECT.
count(scalar_column_expr)
Restituisce il numero totale di righe che
soddisfano la condizione di SELECT.
count(*)
dist(scalar_column_expr, value)
Restituisce il numero totale di righe per le
quali la colonna è uguale al valore
specificato. Il risultato di :
dist(scalar_column_expr, value)
è equivalente a:
SELECT count(scalar_column_expr) FROM
table_name WHERE scalar_column_expr =
value;
Dopo un’espressione di aggregazione, è possibile includere una parola chiave AS
seguita da un alias. Questo alias è un’intestazione di sostituzione per l’espressione
di aggregazione e viene visualizzato nei risultati della query.
La lunghezza massima di un alias o nome di colonna è 40 caratteri.
Se si include una clausola WHERE, vengono restituite solo le righe che soddisfano
i criteri specificati in condition.
Esempi
Il seguente esempio restituisce il valore di severità più alto, quello medio e il
numero di righe per le quali la severità è uguale a 4:
select MAX(Severity), AVG(Severity), DIST(Severity, 4) from alerts.status;
Il seguente esempio restituisce il numero di righe per le quali il valore di Node è
myhost:
select DIST(Node, 'myhost') from alerts.status;
I seguenti esempi eseguono confronti utilizzando la funzione getdate, la quale
restituisce l’ora corrente:
select MAX(getdate-LastOccurrence) from alerts.status;
select AVG((getdate-LastOccurrence)/60) as ResponseTime from alerts.status
where OwnerUID=34;
166
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Concetti correlati
“Condizioni” a pagina 160
“Funzioni” a pagina 154
Raggruppamento mediante il comando SELECT
È possibile utilizzare un comando SELECT con una clausola GROUP BY per
raggruppare in una singola riga tutte le righe che hanno valori identici in una
colonna o combinazione di colonne specificata. È anche possibile trovare il valore
aggregato per ciascun gruppo di valori di colonna.
Sintassi
SELECT [ TOP num_rows ] scalar_column_expr_and_aggr_column_expr [ AS alias_name ] ,...
FROM [database_name.]table_name
[ WHERE condition ]
GROUP BY scalar_column_expr_or_alias ,... [ HAVING condition ]
[ ORDER BY aggr_expr_or_alias [ { ASC | DESC } ] ,... ];
La sintassi di GROUP BY combina espressioni di colonna scalari ed espressioni di
aggregazione. L’uso di un asterisco (*) è consentito solo nella funzione COUNT(*) di
aggregazione.
Dopo un’espressione scalare o di aggregazione, è possibile includere la parola
chiave AS seguita da un alias. Questo alias è un’intestazione di sostituzione per
l’espressione di colonna scalare o per l’espressione di aggregazione e viene
visualizzato nei risultati delle query. È necessario specificare un alias per ogni
colonna virtuale. In tal modo, è possibile farvi riferimento nella clausola GROUP
BY. Se non si specifica un alias per un’espressione di aggregazione, non è possibile
farvi riferimento nell’espressione di aggregazione nella clausola ORDER BY.
La lunghezza massima di un alias o nome di colonna è 40 caratteri.
La clausola GROUP BY raggruppa tutte le righe che contengono dati nelle colonne
specificate e consente l’esecuzione di funzioni di aggregazione su queste colonne
sulla base di valori di colonna. Se è stato specificato un alias di colonna utilizzando
la parola chiave AS, utilizzare questo alias nell’elenco di colonne GROUP BY
anziché nell’espressione o nel nome della colonna corrispondente.
Nota: L’elenco di colonne nella clausola GROUP BY deve corrispondere all’elenco
di colonne da selezionare e non deve contenere espressioni di aggregazione.
La variabile condition che segue la parola chiave HAVING facoltativa è una o più
espressioni che restituiscono una sottoserie di righe della tabella. Diversamente da
altre condizioni nell’SQL dell’ObjectServer, quelle nella clausola HAVING possono
includere funzioni di aggregazione.
Utilizzare la clausola ORDER BY per visualizzare i risultati in ordine sequenziale a
seconda dei valori di una o più espressioni di aggregazione, sia nell’ordine
discendente (DESC) o ascendente (ASC). Se non si specifica la clausola ORDER BY,
non viene utilizzato alcun ordine. È necessario utilizzare l’alias per l’espressione di
aggregazione nella clausola ORDER BY anziché l’espressione di aggregazione
corrispondente.
Esempi
Il seguente esempio restituisce il valore di severità più alto trovato per ciascun
nodo:
Capitolo 4. SQL ObjectServer
167
select Node, max(Severity) from alerts.status group by Node;
Il seguente esempio restituisce il valore di severità più alto trovato per i singoli
nodi, ad eccezione del nodo Sun1, ordinati in base alla severità, da quella più bassa
a quella più alta:
select Node, max(Severity) as MAX_Sev from alerts.status
where Node <> 'Sun1' group by Node order by MAX_Sev;
L’alias di colonna per max(Severity), che è MAX_Sev, viene visualizzato come
intestazione nei risultati delle query.
Concetti correlati
“Condizioni” a pagina 160
Riferimenti correlati
“SELECT di base (scalare)” a pagina 164
“SELECT di aggregazione” a pagina 165
Informazioni di registrazione nei file ObjectServer (comando
WRITE INTO)
Utilizzare il comando WRITE INTO per scrivere informazioni di registrazione nei
file ObjectServer. Un file ObjectServer è un file logico al quale corrispondono uno o
più file (serie di file) sul file system fisico.
Sintassi
WRITE INTO file_name [ VALUES ] (expression, ...);
Ciascun messaggio è seguito da un ritorno a capo.
Esempio
Il seguente comando aggiunge un messaggio al file fisico associato al file
ObjectServer file1 ogni volta che un utente si connette a un database.
WRITE INTO file1 VALUES
('User', %user.user_name, 'connected to the system at', getdate );
La variabile %user.user_name utilizzata in questo esempio è disponibile soltanto
nelle procedure e nei trigger.
Concetti correlati
“File” a pagina 145
Riferimenti correlati
“Variabili utente implicite in procedure e trigger” a pagina 191
Visualizzazione dei dettagli relativi alle colonne di una tabella
o di una vista (comando DESCRIBE)
Utilizzare il comando DESCRIBE per visualizzare informazioni relative alle colonne
della tabella o della vista specificata.
Sintassi
DESCRIBE [database_name.]object_name;
L’output per questo comando include il nome della colonna, il tipo di dati
(restituito come ID ObjectServer), la lunghezza della colonna; inoltre, specifica se la
colonna è parte di una chiave primaria (1 se lo è, 0 se non lo è).
168
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Le colonne nascoste non vengono visualizzate in quanto sono gestite dal sistema e
il normale utente non ha bisogno di visualizzarle o aggiornarle.
Esempio
Utilizzare il seguente comando per visualizzare informazioni sulle colonne nella
tabella catalog.tables:
describe catalog.tables;
Sample output for the preceding command is:
ColumnName
Type
Size
Key
-------------------- --------- --------- -----------TableName
2
40
1
DatabaseName
2
40
1
Status
0
4
0
NumDependents
12
4
0
TableID
0
4
0
TableKind
0
4
0
StorageKind
0
4
0
ServerID
0
4
0
Riferimenti correlati
“Specifica dei tipi di dati per le colonne” a pagina 133
Aggiunta o aggiornamento dei dati relativi allo stato dei
servizi (comando SVC)
Utilizzare il comando SVC per aggiungere o aggiornare lo stato di un avviso di
stato di un servizio nella tabella service.status per IBM Tivoli Composite
Application Manager for Internet Service Monitoring.
Sintassi
SVC UPDATE 'name' integer;
In questo comando, name è l’elemento del profilo che genera l’avviso, mentre
integer è il relativo stato corrente. I valori validi per lo stato di un servizio sono
indicati nella tabella riportata di seguito. Se si immettono altri valori, il livello del
servizio viene impostato su 3 (stato sconosciuto).
Tabella 41. Livelli dello stato dei servizi
Numero intero
Livello dello stato del servizio
0
Buono.
1
Marginale.
2
Non valido.
3
Il livello è sconosciuto.
Esempio
svc update 'newservice' 2;
Capitolo 4. SQL ObjectServer
169
Invio di notifiche IDUC a client IDUC (comando IDUC FLUSH)
Utilizzare il comando IDUC FLUSH per inviare notifiche IDUC ai client IDUC.
Sintassi
IDUC FLUSH destination
In questo comando:
v destination = spid
v spid = integer_expression (l’ID connessione client letterale)
Esempio
create or replace trigger exmple_trigger
group default_triggers
enabled true
priority 2
on signal iduc_data_fetch
begin
for each row conn in iduc_system.iduc_stats
begin
IDUC FLUSH conn.connectionid;
end;
end;
go
Modifica delle impostazioni predefinite e correnti dell’ObjectServer
(comando ALTER SYSTEM)
Utilizzare il comando ALTER SYSTEM per modificare le impostazioni predefinite e
correnti dell’ObjectServer.
È possibile utilizzare questo comando per effettuare le seguenti azioni:
v
v
v
v
Arrestare l’ObjectServer
Impostare una o più proprietà ObjectServer
Interrompere una o più connessioni utente
Eseguire il backup dell’ObjectServer
Sintassi
ALTER SYSTEM
{
SHUTDOWN |
SET 'property_name' = value [ ... ] |
DROP CONNECTION connection_id [, ... ] |
BACKUP 'directory_name'
}
;
È possibile arrestare l’ObjectServer con il comando ALTER SYSTEM SHUTDOWN.
È possibile impostare proprietà ObjectServer con la parola chiave SET, seguita dal
nome della proprietà racchiuso tra virgolette e da un valore per la proprietà. È
possibile modificare più di una proprietà in un singolo comando. Oltre ad
aggiornare la tabella catalog.properties, le proprietà modificate vengono scritte nel
file delle proprietà.
È possibile interrompere connessioni utente con il comando ALTER SYSTEM DROP
CONNECTION. Specificare uno o più identificativi di connessione in un elenco,
170
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
separando le singole voci con una virgola. È possibile trovare gli identificativi per
tutte le connessioni correnti eseguendo query nella tabella di sistema
catalog.connections. La colonna ConnectionID contiene l’identificativo della
connessione.
È possibile eseguire il backup dell’ObjectServer con il comando ALTER SYSTEM
BACKUP. Specificare il percorso di una directory esistente in cui si desidera
eseguire il backup dei file. Questo valore deve essere racchiuso tra virgolette.
Nota: La directory non può essere quella in cui vengono memorizzati i file di dati
ObjectServer, che, per impostazione predefinita, è $NCHOME/omnibus/db/
server_name.
Il backup genera copie dei file .tab ObjectServer nella directory specificata.
Suggerimento: I trigger nel gruppo di trigger automatic_backup_system, definito
nel file automation.sql, utilizzano il comando ALTER SYSTEM BACKUP per
fornire una funzione di backup automatico. Il trigger automatic_backup è
disabilitato per impostazione predefinita; è necessario abilitarlo per poter creare
backup automaticamente. È anche possibile personalizzare questo trigger per
adattarlo all’ambiente. Ad esempio, è possibile modificare il numero di backup
salvati.
Per ripristinare l’ObjectServer nel momento temporale in cui è stato eseguito il
comando BACKUP, copiare i file .tab ObjectServer nella directory dei file di dati
ObjectServer. I file di backup possono essere utilizzati solo su un computer con lo
stesso sistema operativo del computer sul quale sono stati creati.
Esempi
alter system set 'Auto.StatsInterval' = 15 set 'AlertSecurityModel' = 1;
alter system shutdown;
Concetti correlati
“Creazione di file di checkpoint” a pagina 24
Riferimenti correlati
“Proprietà e opzioni della riga comandi dell’ObjectServer” a pagina 3
Impostazione del database predefinito (comandi SET DATABASE e
USE DATABASE)
Utilizzare il comando SET DATABASE o USE DATABASE per impostare un
database come predefinito per una sessione dell’interfaccia interattiva SQL nco_sql.
Questi due comandi eseguono la stessa funzione.
Limitazione: Non è possibile utilizzare questo comando in trigger o procedure.
Dopo aver impostato il database predefinito con il comando SET DATABASE o
USE DATABASE, è possibile specificare un oggetto senza farlo precedere dal nome
del database. L’impostazione del database predefinito è valida per la sola durata
della sessione in cui viene definita.
Sintassi
{ SET | USE } DATABASE database_name;
Capitolo 4. SQL ObjectServer
171
Nota: Il database predefinito non viene applicato nei comandi CREATE VIEW e
DROP VIEW. Se non si specifica il nome di un database in questi comandi, la vista
viene sempre creata ed eliminata nel database degli avvisi.
Esempi
use database newthings;
set database mydb;
Verifica della sintassi SQL (comando CHECK STATEMENT)
Il comando CHECK STATEMENT analizza e verifica la sintassi dei comandi SQL
racchiusi tra virgolette e restituisce un messaggio in cui si comunica che la sintassi
è corretta o una descrizione degli eventuali errori rilevati.
Sintassi
CHECK STATEMENT 'command; command; ...';
Dal momento che il comando CHECK STATEMENT non esegue comandi SQL, gli
errori di runtime non vengono rilevati. Inoltre, è possibile che vengano visualizzati
falsi errori nel caso in cui sia presente una serie di comandi che si basa sui
comandi precedentemente eseguiti.
Creazione, modifica ed eliminazione di utenti, gruppi e ruoli
È possibile utilizzare comandi SQL per organizzare raccolte di utenti in gruppi,
quindi assegnare ruoli a ciascun gruppo per controllare l’accesso agli oggetti
ObjectServer. È possibile creare, modificare ed eliminare utenti, gruppi e ruoli.
Le autorizzazioni controllano l’accesso agli oggetti e ai dati presenti
nell’ObjectServer. Combinando una o più autorizzazioni nei ruoli, è possibile
gestire l’accesso in maniera rapida ed efficace.
Ciascun utente viene assegnato a uno o più gruppi. È quindi possibile accordare ai
gruppi autorizzazioni per eseguire azioni sugli oggetti del database assegnando
uno o più ruoli al gruppo. È possibile creare raggruppamenti logici, ad esempio
superutenti o amministratori di sistema, raggruppamenti fisici come il NOC di
Londra o di New York, oppure qualsiasi altro raggruppamento per semplificare la
configurazione della sicurezza.
Ad esempio, la creazione di automazioni richiede la conoscenza delle operazioni di
Tivoli Netcool/OMNIbus e il modo in cui un determinato ObjectServer è
configurato. In genere, si preferisce non offrire a tutti gli utenti la possibilità di
creare o modificare automazioni. Una soluzione consiste nel creare un ruolo
denominato AutoAdmin, con autorizzazioni per creare e modificare trigger, gruppi
di trigger, file, procedure SQL, procedure esterne e segnali. Successivamente, è
possibile assegnare questo ruolo a un gruppo di amministratori che creeranno e
aggiorneranno i trigger.
I gruppi e i ruoli predefiniti per gli operatori di gestione della rete e gli
amministratori sono definiti nello script SQL security.sql. È anche possibile
utilizzare questo script come modello per creare gruppi e ruoli propri.
172
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Creazione di un utente (comando CREATE USER)
Utilizzare il comando CREATE USER per aggiungere un utente all’ObjectServer.
Sintassi
CREATE USER 'user_name'
[ ID identifier ]
FULL NAME 'full_user_name'
[ PASSWORD 'password' [ ENCRYPTED] ]
[ PAM { TRUE | FALSE } ];
user_name è una stringa di testo che contiene un nome utente univoco per l’utente
da aggiungere. La lunghezza di questo nome non può superare i 64 caratteri. Se
l’utente deve essere autenticato esternamente, ad esempio, in un repository LDAP
(Lightweight Directory Access Protocol) oppure mediante PAM (Pluggable
Authentication Modules), specificare il nome utente memorizzato nel repository di
autenticazione esterno.
Nota: I nomi utente rispettano la distinzione maiuscolo/minuscolo e devono essere
racchiusi tra virgolette. Eventuali spazi iniziali o finali vengono rimossi.
identifier è un numero intero che identifica in maniera univoca l’utente. Se non si
specifica un identificativo, ne viene assegnato uno automaticamente.
L’identificativo per l’utente root è 0. L’identificativo per l’utente nobody è 65534.
Gli identificativi per gli altri utenti possono essere impostati su valori compresi
nell’intervallo 1-2147483647.
full_user_name è una stringa di testo che contiene il nome completo dell’utente.
È possibile specificare la password utente utilizzando la parola chiave PASSWORD.
Il valore predefinito è una stringa vuota. Se si aggiunge la parola chiave
ENCRYPTED, si presuppone che la password venga codificata. Per un utente
autenticato esternamente non è richiesta alcuna password.
Per specificare che l’utente viene autenticato esternamente, impostare PAM su
TRUE. È inoltre necessario impostare la proprietà dell’ObjectServer
Sec.ExternalAuthentication su PAM o LDAP, come appropriato per il sistema di
autenticazione. Se PAM viene impostata su FALSE oppure
Sec.ExternalAuthentication viene impostata su none, l’utente non può essere
autenticato esternamente. Se si desidera memorizzare il nome utente e la password
associata nell’ObjectServer ed eseguire l’autenticazione dell’ObjectServer, impostare
PAM su FALSE. Per ulteriori informazioni su PAM o LDAP, consultare IBM Tivoli
Netcool/OMNIbus - Guida all’installazione e alla distribuzione.
Esempio
create user 'joe' id 1 full name 'Joseph R. User';
Riferimenti correlati
“Proprietà e opzioni della riga comandi dell’ObjectServer” a pagina 3
Capitolo 4. SQL ObjectServer
173
Modifica dei dettagli di un utente esistente (comando ALTER
USER)
Utilizzare il comando ALTER USER per modificare le impostazioni, ad esempio la
password, per l’utente specificato. Con un singolo comando ALTER USER, è
possibile modificare più impostazioni.
Sintassi
ALTER USER 'user_name'
SET PASSWORD 'password' [ AUTHORIZE PASSWORD 'old_password' ] [ ENCRYPTED ]
SET FULL NAME 'full_user_name'
SET ENABLED { TRUE | FALSE }
SET PAM { TRUE | FALSE }
ASSIGN [ RESTRICTION ] FILTER restriction_filter_name
REMOVE [ RESTRICTION ] FILTER restriction_filter_name ;
user_name è una stringa di testo che contiene il nome utente univoco dell’utente i
cui dettagli si desidera modificare. Questo nome non può essere modificato.
Utilizzare l’impostazione PASSWORD per modificare la password per l’utente
specificato. Tenere presente che non è possibile modificare la password di un
utente autenticato esternamente in un sistema LDAP. È possibile modificare la
password di un utente autenticato esternamente in un sistema PAM solo se la
configurazione del sistema PAM esterno consente questo tipo di operazione. Se è
possibile modificare la password di un utente autenticato in un sistema PAM, è
necessario utilizzare anche le parole chiave AUTHORIZE PASSWORD per
specificare la vecchia password.
Utilizzare l’impostazione ENABLED per attivare (TRUE) o disattivare (FALSE)
l’utente specificato. Un utente attivato ha accesso al sistema.
Impostare PAM su TRUE perché l’utente possa essere autenticato esternamente. È
inoltre necessario impostare la proprietà ObjectServer Sec.ExternalAuthentication
su PAM o LDAP, in modo appropriato per il sistema di autenticazione. Se PAM viene
impostata su FALSE oppure Sec.ExternalAuthentication viene impostata su none,
l’utente non può essere autenticato esternamente. Se si desidera eseguire
l’autenticazione dell’ObjectServer, impostare PAM su FALSE. Per ulteriori
informazioni su PAM o LDAP, consultare IBM Tivoli Netcool/OMNIbus - Guida
all’installazione e alla distribuzione.
Utilizzare le impostazioni ASSIGN o REMOVE RESTRICTION FILTER per
assegnare o rimuovere filtri limitazioni che si applicano all’utente. È possibile
assegnare a un utente un solo filtro limitazioni per singola tabella.
Esempio
alter user 'joe' set password 'topsecret';
Concetti correlati
“Filtri limitazioni” a pagina 143
Riferimenti correlati
“Proprietà e opzioni della riga comandi dell’ObjectServer” a pagina 3
174
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Eliminazione di un utente (comando DROP USER)
Utilizzare il comando DROP USER per eliminare l’utente specificato.
Sintassi
DROP USER 'user_name';
user_name è una stringa di testo che contiene il nome utente univoco dell’utente da
eliminare.
Esempio
drop user 'joe';
Creazione di un gruppo (comando CREATE GROUP)
Utilizzare il comando CREATE GROUP per creare un gruppo di uno o più utenti.
Sintassi
CREATE GROUP 'group_name'
[ ID identifier ]
[ COMMENT 'comment_string' ]
[ MEMBERS 'user_name', ... ] ;
group_name è una stringa di testo che contiene un nome univoco per il gruppo da
creare. La lunghezza di questo nome non può superare i 64 caratteri.
Nota: I nomi dei gruppi rispettano la distinzione maiuscolo/minuscolo e devono
essere racchiusi tra virgolette. Eventuali spazi iniziali o finali vengono rimossi.
identifier è un numero intero che identifica in maniera univoca il gruppo. Se non si
specifica un identificativo, ne viene assegnato uno automaticamente. Gli
identificativi compresi tra 0 e 7 sono riservati ai gruppi di sistema. Gli identificativi
per altri gruppi vengono impostati su valori compresi tra 8 e 2147483647.
Utilizzare l’impostazione COMMENT facoltativa per aggiungere una descrizione
del ruolo che si sta creando.
Utilizzare la parola chiave MEMBERS per specificare i nomi utente di uno o più
utenti che si desidera aggiungere come membri del gruppo.
Esempio
create group 'AutoAdmin' id 3 COMMENT 'Group to manage Automations'
members 'joe', 'bob';
Modifica dei dettagli di un gruppo esistente (comando ALTER
GROUP)
Utilizzare il comando ALTER GROUP per modificare le impostazioni utente per il
gruppo specificato. Con un singolo comando ALTER GROUP, è possibile
modificare più di una impostazione.
Sintassi
ALTER GROUP 'group_name'
SET COMMENT 'comment_string'
ASSIGN [ RESTRICTION ] FILTER restriction_filter_name
REMOVE [ RESTRICTION ] FILTER restriction_filter_name
ASSIGN MEMBERS 'user_name', ...
REMOVE MEMBERS 'user_name', ... ;
Capitolo 4. SQL ObjectServer
175
group_name è una stringa di testo che contiene il nome univoco del gruppo i cui
dettagli si desidera modificare. Non è possibile modificare questo nome.
Utilizzare l’impostazione SET COMMENT per modificare la descrizione del
gruppo.
Utilizzare l’impostazione ASSIGN o REMOVE RESTRICTION FILTER per
assegnare o rimuovere filtri limitazioni che si applicano al gruppo. È possibile
assegnare a un gruppo un solo filtro limitazioni per singola tabella.
Utilizzare l’impostazione ASSIGN o REMOVE MEMBERS per assegnare utenti
come membri del gruppo oppure rimuovere utenti dal gruppo.
Esempio
alter group 'AutoAdmin' assign members 'sue';
Concetti correlati
“Filtri limitazioni” a pagina 143
Eliminazione di un gruppo (comando DROP GROUP)
Utilizzare il comando DROP GROUP per eliminare il gruppo specificato.
Sintassi
DROP GROUP 'group_name';
group_name è una stringa di testo che contiene il nome del gruppo da eliminare.
Nota: I gruppi predefiniti Normal, Administrator e Super User forniscono
sicurezza a livello di riga del gruppo nell’elenco eventi. Questi gruppi non possono
essere eliminati o rinominati. Questi e altri gruppi predefiniti vengono creati dallo
script security.sql.
Esempio
drop group 'LondonAdmin';
Creazione di un ruolo (comando CREATE ROLE)
Utilizzare il comando CREATE ROLE per creare un ruolo, che è una raccolta di
autorizzazioni.
Sintassi
CREATE ROLE 'role_name'
[ ID identifier ]
[ COMMENT 'comment_string' ];
role_name è una stringa di testo che contiene il nome univoco del ruolo da creare.
La lunghezza di questo nome non può superare i 64 caratteri.
Nota: I nomi dei ruoli rispettano la distinzione maiuscolo/minuscolo e devono
essere racchiusi tra virgolette. Eventuali spazi iniziali o finali vengono rimossi.
identifier è un valore numerico intero che identifica in maniera univoca l’utente. Se
non si specifica un identificativo, ne viene assegnato uno automaticamente.
L’identificativo del ruolo Normal è 3, mentre quello del ruolo Administrator è 2. Il
176
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
ruolo SuperUser ha come identificativo -1 e dispone di tutte le autorizzazioni per
tutti gli oggetti. Gli identificativi per altri ruoli possono essere impostati su valori
compresi tra 13 e 2147483647.
Utilizzare l’impostazione COMMENT facoltativa per aggiungere una descrizione
del ruolo che si sta creando.
I ruoli predefiniti vengono creati dallo script security.sql.
Esempio
create role 'SuperAdmin' id 500
comment 'only users with root access should be granted this role';
Concetti correlati
“Utilizzo dei ruoli per assegnare autorizzazioni agli utenti”
Modifica della descrizione di un ruolo (comando ALTER
ROLE)
Utilizzare il comando ALTER ROLE per modificare la descrizione di un ruolo
esistente.
Sintassi
ALTER ROLE 'role_name' SET COMMENT 'comment_string';
role_name è una stringa di testo che contiene il nome univoco del ruolo da
modificare. Questo nome non può essere modificato.
Utilizzare l’impostazione COMMENT per modificare la descrizione del ruolo.
Esempio
alter role 'SuperAdmin' set comment 'enhanced description of role';
Utilizzo dei ruoli per assegnare autorizzazioni agli utenti
Dopo aver creato un ruolo, è necessario assegnare autorizzazioni al ruolo
utilizzando il comando GRANT. Successivamente, è possibile utilizzare il comando
GRANT ROLE per assegnare il ruolo a uno o più gruppi. A tutti gli utenti che
sono membri di questi gruppi vengono assegnate automaticamente le
autorizzazioni definite per quel ruolo.
Assegnazione di autorizzazioni ai ruoli (comando GRANT)
Utilizzare il comando GRANT per assegnare ai ruoli autorizzazioni di sistema e
dell’oggetto. Le autorizzazioni di sistema controllano i comandi che possono essere
eseguiti nell’ObjectServer. Le autorizzazioni dell’oggetto controllano l’accesso ai
singoli oggetti, ad esempio le tabelle.
Sintassi per assegnare autorizzazioni di sistema
GRANT system_permission,...
TO ROLE 'role_name',...
[ WITH GRANT OPTION ];
Il valore di system_permission può essere uno dei seguenti sottocomandi:
ISQL
ISQL WRITE
ALTER SYSTEM DROP CONNECTION
ALTER SYSTEM SHUTDOWN
ALTER SYSTEM BACKUP
Capitolo 4. SQL ObjectServer
177
ALTER SYSTEM SET PROPERTY
CREATE DATABASE
CREATE FILE
CREATE RESTRICTION FILTER
CREATE SQL PROCEDURE
CREATE EXTERNAL PROCEDURE
CREATE SIGNAL
CREATE TRIGGER GROUP
CREATE USER
CREATE GROUP
CREATE ROLE
ALTER USER
ALTER GROUP
ALTER ROLE
DROP USER
DROP GROUP
DROP ROLE
GRANT ROLE
REVOKE ROLE
role_name è una stringa di testo che contiene il nome univoco del ruolo o dei ruoli
ai quali assegnare le autorizzazioni.
L’opzione WITH GRANT OPTION consente ai ruoli ai quali viene assegnata
l’autorizzazione di concederla ad altri ruoli.
Suggerimento: È possibile eseguire query nella tabella
catalog.security_permissions per visualizzare informazioni sulle autorizzazioni. Ad
esempio, per visualizzare ciascuna autorizzazione di sistema, utilizzare il seguente
comando SQL: SELECT * FROM catalog.security_permissions WHERE Object =
'SYSTEM' ORDER BY Permission;
Esempio di assegnazione di autorizzazioni di sistema
grant create database to role 'DDL_Admin';
Sintassi per l’assegnazione di autorizzazioni dell’oggetto
GRANT object_permission,... ON permission_object object_name
TO ROLE 'role_name',...
[ WITH GRANT OPTION ];
È possibile assegnare una o più autorizzazioni per gli oggetti ObjectServer.
Utilizzare object_permission per definire i comandi SQL che gli utenti autorizzati
possono eseguire su un oggetto ObjectServer di tipo permission_object. object_name è
una stringa di testo che contiene il nome univoco dell’oggetto.
Il proprietario dell’oggetto (l’utente che lo ha creato) dispone delle autorizzazioni
di assegnazione e di revoca associate a quell’oggetto e può assegnare e revocare
tali assegnazioni ad altri ruoli. La tabella riportata di seguito elenca le
autorizzazioni di cui il proprietario dispone per ciascun tipo di oggetto. Il
proprietario può anche assegnare queste autorizzazioni ad altri utenti.
Tabella 42. Oggetti e autorizzazioni associate
Oggetti (permission_object)
Autorizzazioni (object_permission)
DATABASE
DROP
CREATE TABLE
CREATE VIEW
178
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 42. Oggetti e autorizzazioni associate (Continua)
Oggetti (permission_object)
Autorizzazioni (object_permission)
TABELLA
DROP
ALTER
SELECT
INSERT
UPDATE
DELETE
CREATE INDEX
DROP INDEX
VISTA
DROP
ALTER
SELECT
UPDATE
DELETE
GRUPPO DI TRIGGER
DROP
ALTER
CREATE TRIGGER
TRIGGER
DROP
ALTER
FILE
DROP
ALTER
WRITE
PROCEDURA SQL
DROP
PROCEDURA ESTERNA
ALTER
EXECUTE
SEGNALE
DROP
ALTER
RAISE
FILTRO LIMITAZIONI
DROP
ALTER
role_name è una stringa di testo che contiene il nome univoco del ruolo o dei ruoli
ai quali assegnare le autorizzazioni.
L’opzione WITH GRANT OPTION consente ai ruoli ai quali viene assegnata
l’autorizzazione di concederla ad altri ruoli.
Capitolo 4. SQL ObjectServer
179
Suggerimento: Nei comandi in cui è possibile sostituire un oggetto esistente
utilizzando la sintassi CREATE OR REPLACE, occorre l’autorizzazione ALTER per
sostituire un oggetto esistente. Alcuni oggetti possono essere modificati solo
utilizzando la sintassi CREATE OR REPLACE: ad esempio, non c’è alcun comando
ALTER VIEW, ma è possibile sostituire una vista esistente se si dispone di una
autorizzazione ALTER sulla vista.
Esempio di assegnazione di autorizzazione dell’oggetto
grant drop on database testdb to role 'DDL_Admin';
Riferimenti correlati
“Revoca di autorizzazioni ai ruoli (comando REVOKE)” a pagina 181
Eredità di autorizzazioni dell’oggetto
Quando si crea un nuovo oggetto, questo oggetto acquisisce automaticamente le
autorizzazioni che sono state assegnate all’oggetto parent.
La seguente tabella elenca il parent di ciascun oggetto ObjectServer.
Tabella 43. Eredità di autorizzazioni dell’oggetto
Oggetto parent
Oggetti child
Sistema
DATABASE
GRUPPO DI TRIGGER
FILE
PROCEDURA SQL
PROCEDURA ESTERNA
SEGNALE
FILTRO LIMITAZIONI
DATABASE
TABELLA
VISTA
TABELLA
INDICE
GRUPPO DI TRIGGER
TRIGGER
Ad esempio, se SuperAdmin dispone di un’autorizzazione CREATE_DATABASE e
LondonAdmin crea un database, per impostazione predefinita SuperAdmin
dispone di tutte le autorizzazioni dell’oggetto sul database creato da
LondonAdmin.
Se le autorizzazioni sull’oggetto parent vengono modificate dopo la creazione
dell’oggetto child, questa modifica non coinvolge le autorizzazioni sull’oggetto
child.
180
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Assegnazione di ruoli ai gruppi (comando GRANT ROLE)
Dopo aver creato ruoli come raccolte di autorizzazioni, è possibile assegnare o
revocare i ruoli ai gruppi. Utilizzare il comando GRANT ROLE per assegnare ruoli
ai gruppi.
Le assegnazioni dei ruoli diventano effettive alla successiva sessione client.
Sintassi
GRANT ROLE 'role_name',...
TO GROUP 'group_name',...;
Ciascun role_name è una stringa di testo che contiene il nome univoco di un ruolo
da assegnare.
Ogni group_name è il nome di un gruppo al quale assegnare il ruolo o i ruoli.
Esempio
grant role 'AutoAdmin' to group 'LondonAdministrators';
Riferimenti correlati
“Revoca di ruoli ai gruppi (comando REVOKE ROLE)” a pagina 183
Revoca di autorizzazioni ai ruoli (comando REVOKE)
Utilizzare il comando REVOKE per revocare ai ruoli autorizzazioni di sistema e
dell’oggetto.
Sintassi per revocare autorizzazioni di sistema
REVOKE system_permission,...
FROM ROLE 'role_name',... ;
Il seguente elenco mostra le singole system_permission che possono essere revocate a
un ruolo:
ISQL
ISQL WRITE
ALTER SYSTEM DROP CONNECTION
ALTER SYSTEM SHUTDOWN
ALTER SYSTEM BACKUP
ALTER SYSTEM SET PROPERTY
CREATE DATABASE
CREATE FILE
CREATE RESTRICTION FILTER
CREATE SQL PROCEDURE
CREATE EXTERNAL PROCEDURE
CREATE SIGNAL
CREATE TRIGGER GROUP
CREATE USER
CREATE GROUP
CREATE ROLE
ALTER USER
ALTER GROUP
ALTER ROLE
DROP USER
DROP GROUP
DROP ROLE
GRANT ROLE
REVOKE ROLE
Ogni role_name è una stringa di testo che contiene il nome univoco di un ruolo a
cui revocare l’autorizzazione.
Capitolo 4. SQL ObjectServer
181
Esempio di revoca di un’autorizzazione di sistema
revoke create table from role 'DDL_Admin';
Sintassi per la revoca di autorizzazioni dell’oggetto
REVOKE object_permission,...
ON permission_object object_name
FROM ROLE 'role_name',... ;
È possibile revocare una o più autorizzazioni per gli oggetti ObjectServer.
Utilizzare object_permission per specificare i comandi SQL che si desidera revocare
per un oggetto ObjectServer di tipo permission_object. object_name è una stringa di
testo che contiene il nome univoco dell’oggetto.
I dettagli di ciascuno oggetto e le autorizzazioni associate che è possibile revocare
sono mostrati nella tabella riportata di seguito.
Tabella 44. Oggetti e autorizzazioni associate
Oggetti (permission_object)
Autorizzazioni (object_permission)
DATABASE
DROP
CREATE TABLE
CREATE VIEW
TABELLA
DROP
ALTER
SELECT
INSERT
UPDATE
DELETE
CREATE INDEX
DROP INDEX
VISTA
DROP
ALTER
SELECT
UPDATE
DELETE
GRUPPO DI TRIGGER
DROP
ALTER
CREATE TRIGGER
TRIGGER
DROP
ALTER
FILE
DROP
ALTER
WRITE
182
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 44. Oggetti e autorizzazioni associate (Continua)
Oggetti (permission_object)
Autorizzazioni (object_permission)
PROCEDURA SQL
DROP
PROCEDURA ESTERNA
ALTER
EXECUTE
SEGNALE
DROP
ALTER
RAISE
FILTRO LIMITAZIONI
DROP
ALTER
Ogni role_name è una stringa di testo che contiene il nome univoco di un ruolo a
cui revocare l’autorizzazione.
Nota: Il comando REVOKE ROLE non si propaga all’interno della gerarchia delle
autorizzazioni. Ad esempio, se si revoca l’autorizzazione CREATE TABLE al ruolo
SuperAdmin dopo che SuperAdmin ha assegnato questa autorizzazione al ruolo
LondonAdministrators, il ruolo LondonAdministrators mantiene l’autorizzazione
CREATE TABLE.
Esempio di revoca delle autorizzazioni dell’oggetto
revoke drop on database testdb from role 'DDL_Admin';
Riferimenti correlati
“Assegnazione di autorizzazioni ai ruoli (comando GRANT)” a pagina 177
Revoca di ruoli ai gruppi (comando REVOKE ROLE)
Utilizzare il comando REVOKE ROLE per revocare ruoli ai gruppi.
Sintassi
REVOKE ROLE 'role_name',...
FROM GROUP 'group_name',... ;
Ogni role_name è una stringa di testo che contiene il nome univoco di un ruolo da
revocare.
Ogni group_name è il nome di un gruppo al quale revocare il ruolo o i ruoli.
Nota: Il comando REVOKE ROLE non si propaga all’interno della gerarchia dei
ruoli. Ad esempio, se si revoca il ruolo AutoAdmin al gruppo SuperAdmin dopo
che SuperAdmin ha assegnato il ruolo AutoAdmin al gruppo
LondonAdministrators, il gruppo LondonAdministrators mantiene il ruolo
AutoAdmin.
Esempio
revoke role 'AutoAdmin' from group 'LondonAdministrators';
Riferimenti correlati
“Assegnazione di ruoli ai gruppi (comando GRANT ROLE)” a pagina 181
Capitolo 4. SQL ObjectServer
183
Eliminazione di un ruolo (comando DROP ROLE)
Utilizzare il comando DROP ROLE per eliminare un ruolo esistente.
Sintassi
DROP ROLE 'role_name';
role_name è una stringa di testo che contiene il nome univoco del ruolo da
eliminare. Quando si elimina un ruolo, tutte le autorizzazioni del ruolo correlate
vengono eliminate.
Esempio
drop role 'AutoAdmin';
Creazione, esecuzione ed eliminazione di procedure
Una procedura è un oggetto SQL eseguibile che può essere richiamato per
effettuare operazioni comuni.
I tipi di procedure che è possibile creare sono:
v Procedure SQL, che manipolano i dati in un database ObjectServer
v Procedure esterne, che eseguono un eseguibile su un sistema remoto
Dopo aver creato una procedura nell’ObjectServer, è possibile eseguire la
procedura dall’interfaccia interattiva SQL (nco_sql). È anche possibile eseguire la
procedura in un trigger utilizzando il comando EXECUTE PROCEDURE.
Procedure SQL
Una procedura SQL è una serie di comandi SQL con parametri o frammenti di
codice, con costrutti del linguaggio di programmazione che è possibile utilizzare
per eseguire attività complesse su oggetti del database.
È possibile creare una procedura contenente una serie logica di comandi quale ad
esempio una serie di query, aggiornamenti o inserimenti, che costituiscono
un’attività.
Le procedure espandono la sintassi SQL in modo da poter:
v Trasmettere e restituire parametri a una procedura
v Creare variabili locali e assegnare loro valori
v Eseguire verifiche delle condizioni
v Eseguire operazioni di scansione di tabelle e viste
Componenti di una procedura SQL
I principali componenti di una procedura SQL sono i seguenti: parametri,
dichiarazioni di variabili locali e corpo della procedura.
I parametri sono valori che una procedura trasmette o riceve. Occorre dichiarare i
parametri della procedura al momento della creazione e specificare quali valori
trasmettere come parametri quando si esegue la procedura. La variabile che
contiene un parametro è detta parametro formale, mentre il valore del parametro
quando la procedura viene eseguita è detto parametro effettivo.
I valori che si trasmettono alla procedura devono essere dello stesso tipo di dati
della dichiarazione del parametro.
184
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
È anche possibile creare variabili locali da utilizzare nella procedura per gestire e
modificare valori temporanei nel corpo della procedura. Quando si esce dalla
procedura, le variabili e i valori locali non vengono mai conservati. Ad esempio, è
possibile creare un contatore di tipo integer come variabile locale.
Nota: Dal momento che sia i parametri che le variabili locali contengono dati che
possono cambiare, nelle procedure i parametri e le variabili locali vengono indicati
come ’variabili’.
Il corpo di una procedura contiene una serie di istruzioni che verifica le condizioni
e manipola i dati nel database.
Riferimenti correlati
“Creazione di procedure SQL (comando CREATE PROCEDURE)”
Creazione di procedure SQL (comando CREATE PROCEDURE)
Utilizzare il comando CREATE PROCEDURE per creare procedure SQL.
Questo comando definisce la struttura e l’operazione della procedura, inclusi i tipi
di parametri che questa procedura trasmette e riceve, le variabili locali, la verifica
delle condizioni, le operazioni di riga e le assegnazioni eseguite nella procedura.
Sintassi
CREATE [ OR REPLACE ] PROCEDURE procedure_name
([
[ IN | OUT | IN OUT ] parameter_name
{ parameter_type | ARRAY OF parameter_type }, ...
])
[ DECLARE variable_declaration;...[;] ]
BEGIN
procedure_body_statement;...[;]
END
Se vi è una possibilità che esista già una procedura con lo stesso nome di quella
che si desidera creare, utilizzare le parole chiave OR REPLACE facoltative. Se la
procedura esiste, viene sostituita da quella che si sta creando. Se non esiste, ne
viene creata una nuova.
procedure_name deve essere univoco all’interno dell’ObjectServer e conforme alle
convenzioni di denominazione dell’ObjectServer.
Dopo procedure_name, specificare tra parentesi ( ) i parametri che la procedura può
trasmettere o ricevere. È necessario includere parentesi dopo procedure_name anche
se la procedura non ha parametri.
Ciascun parametro di una procedura ha una modalità: IN, OUT o IN OUT. A
seconda della modalità scelta per i parametri, è possibile utilizzarli in vari modi:
v Un parametro IN è una variabile di sola lettura. È possibile utilizzare un
parametro IN nelle espressioni per consentire il calcolo di un valore, ma non è
possibile assegnare un valore al parametro. Se non si desidera modificare il
valore di una variabile nella procedura, utilizzare un parametro IN per
trasmettere il valore della variabile alla procedura. Questo parametro viene
utilizzato per impostazione predefinita se non si specifica la modalità del
parametro.
v Un parametro OUT è una variabile di sola scrittura. È possibile utilizzare un
parametro OUT per assegnare un valore al parametro, ma non è possibile
leggerlo dal corpo della procedura. Pertanto, non è possibile utilizzare questo
Capitolo 4. SQL ObjectServer
185
tipo di parametro in una espressione. I parametri OUT sono utili per trasmettere
valori calcolati in una procedura, all’esterno della procedura.
v Un parametro IN OUT è una variabile in scrittura e in lettura, con nessuna delle
limitazioni che caratterizzano un parametro IN o OUT. Questo parametro è utile
per variabili che si desidera modificare nella procedura e trasmettere all’esterno
della procedura.
parameter_name deve essere univoco all’interno della procedura e conforme alle
convenzioni di denominazione dell’ObjectServer.
parameter_type definisce il tipo di dati che il parametro può ricevere o trasmettere.
Il tipo di dati può essere un qualsiasi tipo di dati valido dell’ObjectServer, ad
eccezione di VARCHAR o INCR.
Un ARRAY OF parameter_type è un array di un qualsiasi tipo di parametro valido.
Nella sezione DECLARE facoltativa di una procedura, è possibile definire
(dichiarare) variabili locali da utilizzare in una procedura. Una variabile locale è un
segnaposto per i valori utilizzati durante l’esecuzione della procedura. Utilizzare
punti e virgola per separare le dichiarazioni delle variabili locali. I nomi delle
variabili devono essere univoci all’interno della procedura e conformi alle
convenzioni di denominazione dell’ObjectServer. variable_declaration può includere
uno dei seguenti tipi di variabili:
v Variabili semplici:
variable_name variable_type
v Variabili di array:
variable_name variable_type [ ARRAY ] [ integer ]
variable_type è un qualsiasi tipo di dati valido dell’ObjectServer, ad eccezione di
VARCHAR o INCR.
Definire la dimensione di un array specificando un valore numerico intero
maggiore di 1 tra parentesi quadre.
Nota: Le parentesi quadre in grassetto che racchiudono un valore numerico
intero sono obbligatorie per specificare la dimensione dell’array; non indicano la
notazione della sintassi per una clausola o una parola chiave facoltativa.
Il corpo di una procedura viene racchiuso all’interno delle parole chiave BEGIN e
END. È possibile utilizzare l’istruzione SET, l’istruzione IF THEN ELSE, l’istruzione
CASE WHEN, il loop FOR EACH ROW e il loop FOR nel corpo della procedura.
Esempio
Nella dichiarazione di procedura riportata di seguito, il parametro formale è la
variabile current_severity. Quando si esegue la procedura, si trasmette un
parametro effettivo.
CREATE PROCEDURE calculate_average_severity
( IN current_severity INTEGER )
Ad esempio, nella chiamata alla procedura riportata di seguito, il parametro
effettivo è il valore 5, che viene assegnato al parametro formale current_severity.
EXECUTE PROCEDURE calculate_average_severity(5);
186
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Esempio
CREATE PROCEDURE add_or_concat
( IN counter INTEGER, IN one_char_string CHAR(1))
Esempio
Nell’esempio riportato di seguito, un array di numeri interi viene trasmesso alla
procedura e utilizzato per calcolare la severità media di una sottoserie di avvisi:
CREATE PROCEDURE calculate_average_severity
( IN severity_arr ARRAY OF INTEGER)
Un array di numeri interi viene trasmesso alla procedura quando viene eseguita.
Questi numeri interi vengono assegnati a un array denominato severity_arr.
Esempio
Per creare una variabile booleana utilizzata nella procedura per indicare quando
una severità supera un determinato valore:
DECLARE SeverityTooHigh BOOLEAN;
Per creare un array di 20 valori numerici interi utilizzati nella procedura per
memorizzare i nomi dei nodi:
DECLARE NodeNameArray INTEGER [20];
Concetti correlati
“Convenzioni di denominazione per oggetti ObjectServer” a pagina 127
“Componenti di una procedura SQL” a pagina 184
“Espressioni” a pagina 160
Riferimenti correlati
“Specifica dei tipi di dati per le colonne” a pagina 133
“Come costruire un’istruzione del corpo di una procedura SQL”
Come costruire un’istruzione del corpo di una procedura SQL:
Il corpo di una procedura SQL contiene una serie di istruzioni SQL e di costrutti di
programmazione che manipolano i dati nell’ObjectServer.
Sintassi
CREATE [ OR REPLACE ] PROCEDURE procedure_name ([ procedure_parameter,... ])
[ DECLARE variable_declaration;...[;] ]
BEGIN
procedure_body_statement;...[;]
END
Questa sezione descrive solo le voci richieste per il corpo di una procedura
(procedure_body_statement), che è racchiuso tra le parole chiave BEGIN e END.
Nel corpo di una procedura, è necessario separare le singole istruzioni, ad
eccezione dell’ultima, con un punto e virgola (;).
Le istruzioni nella procedura possono includere comandi SQL e costrutti di
programmazione aggiuntivi.
In una procedura è possibile eseguire i comandi SQL elencati di seguito:
Capitolo 4. SQL ObjectServer
187
ALTER SYSTEM BACKUP
ALTER SYSTEM SET
ALTER SYSTEM DROP CONNECTION
ALTER TRIGGER
ALTER TRIGGER GROUP
ALTER USER
UPDATE
INSERT
DELETE
WRITE INTO
RAISE SIGNAL
{ EXECUTE | CALL } PROCEDURE
L’utente che crea la procedura deve disporre delle autorizzazioni appropriate per
eseguire i comandi presenti nel corpo di una procedura.
Attenzione: Non è possibile avere dipendenze circolari nelle procedure o nei
trigger; ad esempio, non è necessario creare una procedura che richiama una
procedura che a sua volta richiama la procedura originale.
È possibile utilizzare nel corpo di una procedura i seguenti costrutti di
programmazione aggiuntivi:
v
v
v
v
Istruzione di assegnazione SET
Istruzione IF THEN ELSE
Istruzione CASE WHEN
Loop FOR EACH ROW
v Loop FOR
Riferimenti correlati
“Creazione di procedure SQL (comando CREATE PROCEDURE)” a pagina 185
“Variabili utente implicite in procedure e trigger” a pagina 191
“Istruzione SET”
“Istruzione IF THEN ELSE” a pagina 189
“Istruzione CASE WHEN” a pagina 189
“Loop FOR EACH ROW” a pagina 190
“Loop FOR” a pagina 191
Istruzione SET:
Quando si costruisce il corpo di una procedura SQL, è possibile utilizzare
un’istruzione di assegnazione SET per scrivere il valore di un’espressione in una
variabile o parametro.
Sintassi
SET { parameter_name | variable_name } = expression
È possibile assegnare un valore a un parametro, a una variabile oppure a un
riferimento riga in un loop FOR EACH ROW.
expression è una qualunque espressione valida.
Nota: Il tipo di valore restituito dall’espressione deve essere compatibile con la
variabile in cui si scrive il valore.
188
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Concetti correlati
“Espressioni” a pagina 160
Riferimenti correlati
“Come costruire un’istruzione del corpo di una procedura SQL” a pagina 187
Istruzione IF THEN ELSE:
Quando si costruisce il corpo di una procedura SQL, è possibile utilizzare
l’istruzione IF THEN ELSE per eseguire una o più azioni sulla base delle
condizioni specificate.
Sintassi
IF condition THEN action_command_list
[ ELSEIF condition THEN action_command_list ]
...
[ ELSE action_command_list ]
END IF;
Se la prima condizione viene soddisfatta (TRUE), i comandi che seguono la parola
chiave THEN vengono eseguiti in sequenza fino a quando non si raggiunge
un’istruzione ELSEIF, ELSE, o END IF. Se la prima condizione non viene
soddisfatta e c’è un’istruzione ELSEIF per la quale la condizione viene soddisfatta,
i comandi che seguono l’istruzione ELSEIF vengono eseguiti fino a quando non si
raggiunge la successiva parola chiave. Se esiste un’istruzione ELSE e nessuna
condizione precedente è stata soddisfatta, le istruzioni che seguono l’istruzione
ELSE vengono eseguite fino a quando non si raggiunge l’istruzione END IF.
Concetti correlati
“Condizioni” a pagina 160
Riferimenti correlati
“Come costruire un’istruzione del corpo di una procedura SQL” a pagina 187
Istruzione CASE WHEN:
Quando si costruisce il corpo di una procedura SQL, è possibile utilizzare
l’istruzione CASE WHEN per effettuare una o più azioni in base a una condizione.
Se la condizione non viene soddisfatta, è possibile effettuare un’azione diversa.
Sintassi
CASE
WHEN condition THEN action_command_list
...
[ ELSE action_command_list ]
END CASE;
Se la prima condizione viene soddisfatta (viene valutata su TRUE), le istruzioni che
seguono la parola chiave THEN vengono eseguite in sequenza fino a quando non
si raggiunge un’istruzione WHEN, ELSE o END CASE. Se, invece, c’è un’istruzione
WHEN per la quale la condizione viene soddisfatta, le istruzioni che seguono la
parola chiave THEN vengono eseguite fino a quando non si raggiunge
un’istruzione WHEN, ELSE o END CASE. Se nessuna condizione precedente viene
soddisfatta ed esiste un’istruzione ELSE, le istruzioni che seguono l’istruzione
ELSE vengono eseguite fino a quando non si raggiunge un’istruzione END CASE.
Capitolo 4. SQL ObjectServer
189
Concetti correlati
“Condizioni” a pagina 160
Riferimenti correlati
“Come costruire un’istruzione del corpo di una procedura SQL” a pagina 187
Loop FOR EACH ROW:
Quando si costruisce il corpo di una procedura SQL, è possibile utilizzare il loop
FOR EACH ROW per eseguire azioni su una serie di righe che soddisfano una
determinata condizione.
Sintassi
FOR EACH ROW variable_name in database_name.table_name
[ WHERE condition ]
BEGIN
action_command_list;
END;
In questa istruzione, il nome della variabile viene dichiarato in maniera implicita
come riferimento di riga. Pertanto, non occorre dichiarare la variabile all’inizio
della procedura. Questo significa che eventuali modifiche apportate alle colonne
alle quali la variabile fa riferimento, influiscono direttamente sulle righe cui viene
fatto riferimento nell’ObjectServer. Quando si raggiunge l’istruzione END, la
variabile dichiarata in maniera implicita viene rimossa e non può essere utilizzata
altrove nella procedura.
Nota: Solo le tabelle di base (non le viste) possono essere aggiornate nel loop FOR
EACH ROW. Non è possibile eseguire inserimenti nella tabella da elaborare nel
loop FOR EACH ROW.
Se si include una clausola WHERE, vengono restituite solo le righe che soddisfano
i criteri specificati nella condizione.
Un comando BREAK esce dal loop corrente e inizia l’esecuzione dell’istruzione
successiva.
Un comando CANCEL interrompe l’esecuzione di una procedura.
Attenzione: Non utilizzare il comando CANCEL quando si utilizza un
ObjectServer desktop nella modalità DualWrite.
Esempio
Il seguente esempio aumenta la severità di tutti gli avvisi nella tabella alerts.status
che hanno una severità compresa tra 3 e 4.
FOR EACH ROW alert_row in alerts.status WHERE alert_row.Severity=3
BEGIN
SET alert_row.Severity = 4;
END;
Quando questa istruzione viene eseguita, l’ObjectServer legge ogni singola riga
della tabella alerts.status ed esegue una prova per stabilire se il valore nella
colonna Severity è 3. Per ciascuna riga che soddisfa questa condizione, le istruzioni
racchiuse tra BEGIN e END vengono eseguite fino a quando non vengono
elaborate tutte le righe.
190
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Concetti correlati
“Condizioni” a pagina 160
Riferimenti correlati
“Come costruire un’istruzione del corpo di una procedura SQL” a pagina 187
Loop FOR:
Quando si costruisce il corpo di una procedura SQL, è possibile utilizzare il loop
FOR per eseguire azioni un numero specifico di volte, sulla base di una variabile
contatore.
Sintassi
FOR counter = 1 to integer DO
BEGIN
action_command_list;
END;
Un comando BREAK esce dal loop corrente e inizia l’esecuzione dell’istruzione
successiva.
Un comando CANCEL interrompe l’esecuzione di una procedura.
Attenzione: Non utilizzare il comando CANCEL quando si utilizza un
ObjectServer desktop nella modalità DualWrite.
Esempio
La seguente procedura aggiorna ogni singola riga della tabella alerts.status e
imposta l’indicatore riconosciuto su TRUE:
CREATE PROCEDURE ACKNOWLEDGE_TOOL( ids ARRAY OF CHAR(255) )
DECLARE
k INTEGER;
BEGIN
FOR k = 1 TO array_len( ids ) DO
BEGIN
UPDATE alerts.status VIA ( ids[k] ) SET Acknowledged = TRUE;
END;
END;
Riferimenti correlati
“Come costruire un’istruzione del corpo di una procedura SQL” a pagina 187
Variabili utente implicite in procedure e trigger:
È possibile utilizzare variabili utente per accedere alle informazioni sugli utenti
connessi in un’espressione SQL nel corpo di un trigger o di una procedura.
Utilizzare la notazione %user per specificare variabili utente, ad esempio:
%user.attribute_name. Il simbolo % indica che si sta facendo riferimento a una
variabile implicita. La parola chiave user fa riferimento all’utente corrente.
Suggerimento: È anche possibile utilizzare il pulsante dell’helper % per selezionare
variabili %user.
La seguente tabella elenca attributi di sola lettura che sono disponibili in procedure
e trigger.
Capitolo 4. SQL ObjectServer
191
Tabella 45. Variabili utente implicite
Attributo della variabile Tipo di dati
Descrizione
%user.user_id
INTEGER
Identificativo utente dell’utente
connesso.
%user.user_name
STRING
Nome dell’utente connesso.
%user.app_name
STRING
Nome dell’applicazione connessa (ad
esempio, nco_sql).
%user.host_name
STRING
Nome dell’host connesso.
%user.connection_id
UNSIGNED
Identificativo della connessione.
Vedere “Esempio: Utilizzo di
%user.counterpart_id e
%user.connection_id”.
%user.counterpart_id
UNSIGNED
Identificativo della connessione della
controparte.
Vedere “Esempio: Utilizzo di
%user.counterpart_id e
%user.connection_id”.
%user.is_auto
BOOLEAN
Se TRUE, l’azione corrente è stata
causata dall’esecuzione di
un’automazione (ad esempio, un
trigger temporale).
%user.is_gateway
BOOLEAN
Se TRUE, l’azione corrente è stata
causata da un client gateway.
%user.is_eventlist
BOOLEAN
Se TRUE, l’azione corrente è stata
causata da un client elenco eventi.
%user.description
STRING
Nome descrittivo dell’applicazione.
Applicabile solo per probe o gateway
ObjectServer.
Esempio: Utilizzo di %user.user_name
Per fare riferimento al nome dell’utente corrente nel corpo di una procedura o di
un trigger, utilizzare la seguente sintassi:
%user.user_name
Esempio: Utilizzo di %user.counterpart_id e %user.connection_id
Per i gateway, se %user.connection_id fa riferimento a un componente writer del
gateway, %user.counterpart_id è l’ID skip del componente reader del gateway.
Questo esempio mostra come utilizzare queste variabili nel failover e nel failback
automatizzati, per disconnettere tutti i client (ad eccezione del gateway) da un
ObjectServer di backup quando viene ripristinato l’ObjectServer primario. Il
seguente codice può essere aggiunto nel trigger backup_counterpart_up:
For each row connected in catalog.connections where
(connected.ConnectionID <> %user.connection_id and
connected.ConnectionID <> %user.counterpart_id and
connected.AppName == 'GATEWAY') or
connected.AppName <> 'GATEWAY'
begin
alter system drop connection connected.ConnectionID;
end;
192
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Riferimenti correlati
Appendice B, “Pulsanti helper, espressioni variabili e comandi SQL in strumenti,
automazioni ed elenchi eventi transitori”, a pagina 347
Procedure esterne
È possibile creare procedure esterne per eseguire un programma eseguibile su un
sistema locale o remoto.
Creazione di procedure esterne (comando CREATE
PROCEDURE)
Utilizzare il comando CREATE PROCEDURE per creare procedure esterne.
Sintassi
CREATE [ OR REPLACE ] PROCEDURE procedure_name
( [ parameter_name
{ parameter_type | ARRAY OF parameter_type
| ROW OF database_name.table_name },... ] )
EXECUTABLE 'executable_name'
HOST 'host_name'
USER user_id
GROUP group_id
[ ARGUMENTS expression,... ] [;]
Se vi è una possibilità che esista già una procedura con lo stesso nome di quella
che si desidera creare, utilizzare le parole chiave OR REPLACE facoltative. Se la
procedura esiste, viene sostituita da quella che si sta creando. Se non esiste, ne
viene creata una nuova.
procedure_name deve essere univoco all’interno dell’ObjectServer e conforme alle
convenzioni di denominazione dell’ObjectServer.
Dopo procedure_name, includere la dichiarazione dei parametri tra parentesi ( ), per
specificare i parametri che è possibile trasmettere nella procedura esterna. È
necessario includere parentesi dopo procedure_name anche se la procedura non ha
parametri. Ciascun parameter_name deve essere univoco all’interno della procedura
e conforme alle convenzioni di denominazione dell’ObjectServer.
Suggerimento: I parametri delle procedure esterne sono di sola lettura. Essi
consentono di trasmettere valori di variabile in una procedura esterna. Non è
possibile restituire valori da una procedura esterna.
La variabile parameter_type definisce il tipo di dati che il parametro può trasmettere
nella procedura. Il tipo di dati può essere un qualsiasi tipo di dati valido
dell’ObjectServer, ad eccezione di VARCHAR o INCR.
executable_name è il percorso di un programma eseguibile su un file system locale o
remoto.
Suggerimento: Su Windows, è necessario eseguire l’escape con il carattere barra
retroversa nei percorsi file; in caso contrario, i percorsi non verranno interpretati
correttamente. È anche possibile utilizzare il separatore di percorso UNIX quando
si specificano percorsi su Windows.
host_name è il nome dell’host sul quale eseguire il programma eseguibile per la
procedura.
Capitolo 4. SQL ObjectServer
193
user_id è l’ID utente effettivo con il quale eseguire il programma eseguibile.
group_id è l’ID gruppo effettivo con il quale eseguire il programma eseguibile.
Gli argomenti sono quelli trasmessi all’eseguibile. Per separare gli argomenti, è
possibile utilizzare solo spazi. Ad esempio: cool tool viene interpretato come cool
tool, mentre cool'tool o cool"tool viene interpretato come cooltool.
Esempio
La seguente procedura esterna richiama il programma nco_mail, il quale invia
e-mail relative ad avvisi critici non riconosciuti:
create or replace procedure send_email
(in node character(255), in severity integer, in subject character(255),
in email character(255), in summary character(255), in hostname character(255))
executable '$NCHOME/omnibus/utils/nco_mail'
host 'localhost'
user 0
group 0
arguments '\'' + node + '\'', severity, '\'' + subject + '\'',
'\'' + email + '\'', '\'' + summary + '\'';
Questo esempio mostra anche come trasmettere stringhe di testo a un programma
eseguibile. È necessario racchiudere le stringhe tra virgolette ed effettuare l’escape
delle virgolette con barre retroverse. Tutte le virgolette contenute in questo esempio
sono virgolette singole.
Nota: Per eseguire una procedura esterna, è necessario che un daemon dell’agent
del controllo processi (nco_pad) sia in esecuzione sull’host sul quale è memorizzato
il comando eseguibile.
Concetti correlati
“Convenzioni di denominazione per oggetti ObjectServer” a pagina 127
Capitolo 6, “Utilizzo del controllo processi per gestire processi e procedure
esterne”, a pagina 241
Attività correlate
“Specifica dei percorsi nell’interfaccia interattiva SQL” a pagina 128
Riferimenti correlati
“Specifica dei tipi di dati per le colonne” a pagina 133
Esecuzione di procedure
Dopo aver creato una procedura, è necessario eseguirla utilizzando il comando
EXECUTE PROCEDURE perché le azioni indicate nella procedura abbiano luogo.
A tale scopo, utilizzare l’interfaccia interattiva SQL (nco_sql) oppure un trigger o
una procedura.
Sintassi
{ EXECUTE | CALL } [ PROCEDURE ] procedure_name
[ ( expression,... ) | ( [ expression, expression,... ] ,... ) ];
Utilizzare procedure_name per specificare la procedura da eseguire.
Ciascuna delle espressioni trasmesse come parametri effettivi deve essere risolta in
un valore assegnabile che corrisponda al tipo di parametro specificato quando la
procedura è stata creata.
194
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Nota: Se si trasmette un parametro di array, le parentesi quadre che racchiudono
l’elenco di espressioni, visualizzate in grassetto nella descrizione di sintassi
precedente, non sono facoltative.
Esempio
Per eseguire la procedura descritta in “Creazione di procedure esterne (comando
CREATE PROCEDURE)” a pagina 193, utilizzare la seguente chiamata in un
trigger:
execute send_email( critical.Node, critical.Severity, 'Netcool E-mail',
'root@localhost', critical.Summary, 'localhost');
Concetti correlati
“Componenti di una procedura SQL” a pagina 184
Riferimenti correlati
“Creazione di procedure esterne (comando CREATE PROCEDURE)” a pagina 193
Eliminazione di procedure
Utilizzare il comando DROP PROCEDURE per eliminare una procedura esistente.
Non è possibile eliminare una procedura se vi fanno riferimento altri oggetti, ad
esempio i trigger.
Sintassi
DROP PROCEDURE procedure_name;
Esempio
drop procedure testproc;
Configurazione dell’automazione utilizzando trigger
È possibile utilizzare l’automazione per rilevare modifiche nell’ObjectServer e per
eseguire risposte automatizzate a queste modifiche. Ciò consente all’ObjectServer
di elaborare avvisi senza richiedere ad un operatore di eseguire l’azione.
I trigger costituiscono la base del sistema di automazione.
Creazione, modifica ed eliminazione di gruppi di trigger
Ogni trigger appartiene a un gruppo di trigger, che è una raccolta di trigger
correlati.
Creazione di un gruppo di trigger (comando CREATE TRIGGER
GROUP)
Utilizzare il comando CREATE TRIGGER GROUP per creare un nuovo gruppo di
trigger. Quando si crea un trigger, è necessario assegnarlo a un gruppo di trigger.
Sintassi
CREATE TRIGGER GROUP trigger_group_name;
trigger_group_name deve essere univoco all’interno dell’ObjectServer e conforme alle
convenzioni di denominazione dell’ObjectServer.
Esempio
create trigger group update_database_triggers;
Capitolo 4. SQL ObjectServer
195
Concetti correlati
“Convenzioni di denominazione per oggetti ObjectServer” a pagina 127
Modifica di un gruppo di trigger (comando ALTER TRIGGER
GROUP)
Utilizzare il comando ALTER TRIGGER GROUP per abilitare o disabilitare un
gruppo di trigger esistente.
Sintassi
ALTER TRIGGER GROUP trigger_group_name | expression
SET ENABLED { TRUE | FALSE };
Un gruppo di trigger viene abilitato per impostazione predefinita.
Con questo comando è possibile specificare il nome di un gruppo di trigger
oppure un’espressione. Nel caso di un’espressione, il nome non viene valutato fino
al runtime.
Esempi
Questo esempio disabilita il gruppo di trigger update_database_triggers.
alter trigger group update_database_triggers set enabled false;
Questo esempio disabilita tutti i trigger ad eccezione di quelli dei gateway (che
appartengono al gruppo di trigger gateway_triggers) elencando singolarmente i
nomi di tutti gli atri gruppi di trigger da disabilitare.
Create trigger disable_triggers
Group gateway_triggers
Priority 1
on signal gw_counterpart_up
begin
alter trigger group trigger_group_name_1 set enabled false;
...
alter trigger group trigger_group_name_n set enabled false;
end;
Questo esempio utilizza un’espressione per disabilitare tutti i trigger ad eccezione
di quelli dei gateway che appartengono al gruppo di trigger gateway_triggers. Al
runtime, il loop FOR EACH ROW viene utilizzato per eseguire le azioni
nell’espressione, su ciascuna riga nella tabella catalog.triggers.
Create trigger disable_triggers
Group gateway_triggers
Priority 1
on signal gw_counterpart_up
begin
for each row tg in catalog.triggers where
tg.GroupName <> 'gateway_triggers'
begin
alter trigger group tg.GroupName set enabled false;
end;
end;
196
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Eliminazione di un gruppo di trigger (comando DROP TRIGGER
GROUP)
Utilizzare il comando DROP TRIGGER GROUP per eliminare un gruppo di trigger
esistente.
Sintassi
DROP TRIGGER GROUP trigger_group_name;
Non è possibile eliminare un gruppo di trigger se contiene trigger.
Esempio
drop trigger group update_database_triggers;
Creazione, modifica ed eliminazione di trigger
È possibile utilizzare trigger di database, trigger temporali e trigger di segnale
nelle automazioni.
I trigger di database
database:
v Viene eseguito un
v Viene eseguito un
v Viene eseguito un
vengono attivati se si verifica una delle seguenti modifiche al
tentativo di inserire una riga in una tabella.
tentativo di aggiornare una riga in una tabella.
tentativo di eliminare una riga da una tabella.
v Viene eseguito un tentativo di inserire una riga in una tabella, ma esiste già una
riga con lo stesso valore per la chiave primaria dell’identificativo. È possibile
utilizzare un trigger di reinserimento per deduplicare le righe nell’ObjectServer.
Nota: È possibile creare un proprio trigger di deduplicazione perché abbia luogo
un’azione diversa.
I trigger temporali vengono attivati ripetutamente in base alla frequenza
specificata.
Ad esempio, è possibile utilizzare un trigger temporale per eliminare tutte le righe
con stato chiaro (Severity = 0) dalla tabella alerts.status che non sono state
modificate entro un determinato periodo di tempo.
I trigger di segnale vengono attivati quando viene generato un segnale di sistema
predefinito oppure quando viene generato un segnale definito dall’utente
utilizzando il comando RAISE SIGNAL.
Ad esempio, è possibile inviare una e-mail a un operatore quando l’ObjectServer
viene avviato o arrestato perché sono stati generati segnali di sistema.
Per creare o configurare segnali di sistema, non occorre eseguire alcuna azione. Per
quanto riguarda i segnali definiti dall’utente, questi devono essere creati, generati
ed eliminati in maniera esplicita.
Capitolo 4. SQL ObjectServer
197
Creazione di trigger di database (comando CREATE TRIGGER)
Utilizzare il comando CREATE TRIGGER per creare trigger di database che
vengono attivati quando si verifica una modifica o un tentativo di modifica a una
tabella ObjectServer (oppure quando una modifica o un tentativo di modifica a una
vista influisce su una tabella di base).
Sintassi
CREATE [ OR REPLACE ] TRIGGER trigger_name
GROUP group_name
[ DEBUG { TRUE | FALSE } ]
[ ENABLED { TRUE | FALSE } ]
PRIORITY integer
[ COMMENT 'comment_string' ]
{ BEFORE | AFTER } { INSERT | UPDATE | DELETE | REINSERT }
ON database_name.table_name
FOR EACH { ROW | STATEMENT }
[ WHEN condition ]
[ DECLARE variable_declaration ]
BEGIN
trigger_action
END;
Se vi è una possibilità che esista già un trigger con lo stesso nome di quello che si
desidera creare, utilizzare le parole chiave OR REPLACE facoltative. Se il trigger
esiste, viene sostituito da quello che si sta creando. Se non esiste, ne viene creato
uno nuovo.
Il valore trigger_name deve essere univoco all’interno dell’ObjectServer e conforme
alle convenzioni di denominazione dell’ObjectServer.
Il valore group_name può essere un qualsiasi gruppo trigger già creato utilizzando
il comando CREATE TRIGGER GROUP.
Se DEBUG è impostato su TRUE, le informazioni di debug vengono inviate al log di
messaggi dell’ObjectServer, se il livello dei messaggi è impostato su debug.
Se ENABLED è impostato su TRUE, il trigger viene attivato quando si verifica
l’incidente associato. Altrimenti, il trigger non viene attivato quando si verifica
l’incidente.
Il valore PRIORITY di un trigger determina l’ordine in cui l’ObjectServer attiva i
trigger quando vi sono più trigger associati allo stesso incidente. La priorità può
essere compresa tra 1 e 20. Minore è il numero e maggiore è la priorità; quindi, un
trigger con priorità 2 viene attivato prima di un trigger con priorità 3. Se vengono
attivati più trigger con la stessa priorità a causa dello stesso incidente, l’ordine di
attivazione di tali trigger è indeterminato.
Utilizzare la parola chiave COMMENT facoltativa per aggiungere un commento
(comment_string) per il trigger.
La parola chiave BEFORE o AFTER specifica se il trigger viene eseguito prima o
dopo la modifica del database che ha provocato l’attivazione del trigger. Ad
esempio, è possibile creare un trigger BEFORE che valuti il nome dell’utente prima
che una riga nella tabella alerts.status venga eliminata. Nel trigger, è possibile
rilevare se l’utente è autorizzato ad eseguire eliminazioni nella tabella alerts.status
e, qualora non lo fosse, impedire che abbiano luogo modifiche del database. Con
un trigger AFTER, la modifica del database ha sempre luogo.
198
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
database_name.table_name è il nome del database e della tabella coinvolti dall’azione
trigger.
Un trigger di database viene attivato a uno dei seguenti livelli:
v FOR EACH ROW (noto come trigger a livello di riga): i trigger a livello di riga
vengono attivati una volta per ciascuna riga restituita come risultato della
modifica del database.
v FOR EACH STATEMENT (noto come trigger a livello di istruzione): i trigger a
livello di istruzione vengono generati una volta per ciascuna modifica del
database.
Nota: È possibile definire solo trigger a livello di riga per attivare inserimenti e
reinserimenti.
Nota: I trigger a livello di istruzione BEFORE vengono attivati sempre prima dei
trigger a livello di riga BEFORE, mentre i trigger a livello di istruzione AFTER
vengono attivati sempre dopo i trigger a livello di riga AFTER, indipendentemente
dalla priorità dei trigger.
Utilizzare la clausola WHEN facoltativa per verificare una particolare condizione
prima di eseguire l’azione del trigger. Se la condizione non viene soddisfatta,
l’azione trigger non viene eseguita.
È anche possibile dichiarare variabili trigger locali da utilizzare nel corpo del
trigger. Tali variabili vengono dichiarate e utilizzate nello stesso modo delle
variabili di procedura. Tuttavia, le variabili trigger sono statiche, quindi
mantengono il relativo valore tra esecuzioni del trigger.
Esempio
Un segnale di database viene generato come risultato della seguente istruzione
SQL:
DELETE FROM alerts.status WHERE Severity = 5;
Quando si esegue questa istruzione, l’ObjectServer elimina tutte le righe nella
tabella alerts.status che hanno una severità 5. Se la tabella contiene 20 righe con
questa severità e il livello è impostato su FOR EACH ROW, le 20 righe vengono
eliminate e il trigger viene attivato 20 volte. Se il level è impostato su FOR EACH
STATEMENT, il trigger viene attivato una sola volta.
Concetti correlati
“Convenzioni di denominazione per oggetti ObjectServer” a pagina 127
“Condizioni” a pagina 160
Riferimenti correlati
“Esecuzione di comandi in azioni trigger” a pagina 205
“Migliori pratiche per la creazione di trigger” a pagina 305
Capitolo 4. SQL ObjectServer
199
Variabili implicite NEW e OLD nei trigger a livello di riga:
Oltre alle variabili locali dichiarate nel trigger, i trigger a livello di riga hanno
accesso a variabili implicite i cui valori vengono impostati in maniera automatica
dal sistema.
La variabile OLD fa riferimento al valore che una colonna ha prima che si verifichi
l’incidente; la variabile NEW fa riferimento al valore della colonna dopo che si è
verificato l’incidente. È possibile utilizzare espressioni da cui leggere e assegnare
valori alle variabili di riga.
Alcune operazioni sulle variabili di riga NEW oppure OLD potrebbero non essere
accessibili o modificabili a seconda del tipo di modifica. Ad esempio, se
l’ObjectServer elimina una riga, non c’è alcuna riga NEW da leggere o modificare.
La tabella riportata di seguito mostra la disponibilità delle variabili NEW e OLD a
seconda dell’operazione del database.
Tabella 46. Disponibilità delle variabili di riga speciali
Operazione
Modalità
temporale
La variabile
NEW è
disponibile?
La variabile
La variabile
NEW è
OLD è
modificabile? disponibile?
La variabile
OLD è
modificabile?
INSERT
BEFORE
S
S
N
N
INSERT
AFTER
S
N
N
N
UPDATE
BEFORE
S
S
S
N
UPDATE
AFTER
S
N
N
N
DELETE
BEFORE
N
N
S
N
DELETE
AFTER
N
N
S
N
REINSERT
BEFORE
S
N
S
S
REINSERT
AFTER
S
N
N
N
Nota: In un trigger di post-reinserimento, è disponibile solo la variabile NEW e
questa rappresenta i dati dell’istruzione INSERT. Ad esempio, se Tally non viene
specificato nell’istruzione INSERT, new.Tally avrà un valore predefinito pari a 0
(zero).
Esempio
Il trigger di database riportato di seguito utilizza la variabile NEW per aggiornare la
colonna StateChange quando una riga nella tabella alerts.status viene modificata
perché rifletta l’ora e la data della modifica.
create trigger SetStateChange
group default_triggers
priority 1
before update on alerts.status
for each row
begin
set new.StateChange = getdate;
end;
200
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Creazione di trigger temporali (comando CREATE TRIGGER)
Utilizzare il comando CREATE TRIGGER per creare trigger temporali che vengono
attivati a una frequenza specificata.
Sintassi
CREATE [ OR REPLACE ] TRIGGER trigger_name
GROUP group_name
[ DEBUG { TRUE | FALSE } ]
[ ENABLED { TRUE | FALSE } ]
PRIORITY integer
[ COMMENT 'comment_string'
EVERY integer { HOURS | MINUTES | SECONDS }
[ EVALUATE SELECT_cmd BIND AS variable_name ]
[ WHEN condition ]
[ DECLARE variable_declaration ]
BEGIN
trigger_action
END;
Se vi è una possibilità che esista già un trigger con lo stesso nome di quello che si
desidera creare, utilizzare le parole chiave OR REPLACE facoltative. Se il trigger
esiste, viene sostituito da quello che si sta creando. Se non esiste, ne viene creato
uno nuovo.
Il valore trigger_name deve essere univoco all’interno dell’ObjectServer e conforme
alle convenzioni di denominazione dell’ObjectServer.
Il valore group_name può essere un qualsiasi gruppo trigger già creato utilizzando
il comando CREATE TRIGGER GROUP.
Se DEBUG è impostato su TRUE, le informazioni di debug vengono inviate al log di
messaggi dell’ObjectServer, se il livello dei messaggi è impostato su debug.
Se ENABLED è impostato su TRUE, il trigger viene attivato quando si verifica
l’incidente associato. Altrimenti, il trigger non viene attivato quando si verifica
l’incidente.
Il valore PRIORITY di un trigger determina l’ordine in cui l’ObjectServer attiva i
trigger quando vi sono più trigger associati allo stesso incidente. La priorità può
essere compresa tra 1 e 20. Minore è il numero e maggiore è la priorità; quindi, un
trigger con priorità 2 viene attivato prima di un trigger con priorità 3. Se vengono
attivati più trigger con la stessa priorità a causa dello stesso incidente, l’ordine di
attivazione di tali trigger è indeterminato.
Utilizzare la parola chiave COMMENT facoltativa per aggiungere un commento
(comment_string) per il trigger.
In un trigger temporale, è necessario specificare la frequenza con la quale il trigger
verrà attivato. Specificare un valore integer in secondi (l’unità di tempo
predefinita), minuti oppure ore.
Utilizzare la clausola EVALUATE facoltativa per creare una serie di risultati
temporanea da una singola istruzione SELECT da elaborare in trigger_action.
L’istruzione SELECT non può contenere una clausola ORDER BY.
Nota: La clausola EVALUATE deve qualificare completamente qualsiasi tabella,
inclusa nell’istruzione SELECT, con un nome di database. Ad esempio, la seguente
Capitolo 4. SQL ObjectServer
201
sintassi non è considerata valida: evaluate select Node from status... La sintassi
corretta è: evaluate select Node from alerts.status...
Nella maggior parte dei casi, una clausola EVALUATE può essere sostituita con
una clausola FOR EACH ROW. Utilizzare una clausola EVALUATE solo quando è
richiesta una clausola GROUP BY.
Utilizzare la clausola WHEN facoltativa per verificare una particolare condizione
prima di eseguire l’azione del trigger. Se la condizione non viene soddisfatta,
l’azione trigger non viene eseguita.
È anche possibile dichiarare variabili trigger locali da utilizzare nel corpo del
trigger. Tali variabili vengono dichiarate e utilizzate nello stesso modo delle
variabili di procedura. Tuttavia, le variabili trigger sono statiche, quindi
mantengono il relativo valore tra esecuzioni del trigger.
Esempio
Il trigger temporale riportato di seguito elimina tutte le righe con stato chiaro
(Severity = 0) dalla tabella alerts.status che non sono state modificate negli ultimi
due minuti.
create trigger DeleteClears
group my_triggers
priority 1
every 60 seconds
begin
delete from alerts.status where Severity = 0
and StateChange < (getdate - 120);
end;
Concetti correlati
“Convenzioni di denominazione per oggetti ObjectServer” a pagina 127
“Condizioni” a pagina 160
Riferimenti correlati
“Esecuzione di comandi in azioni trigger” a pagina 205
“Migliori pratiche per la creazione di trigger” a pagina 305
Creazione di trigger di segnale (comando CREATE TRIGGER)
Utilizzare il comando CREATE TRIGGER per creare un trigger di segnale che viene
attivato in risposta a incidenti che si verificano nell’ObjectServer o in risposta a un
segnale definito dall’utente.
Sintassi
CREATE [ OR REPLACE ] TRIGGER trigger_name
GROUP group_name
[ DEBUG { TRUE | FALSE } ]
[ ENABLED { TRUE | FALSE } ]
PRIORITY integer
[ COMMENT 'comment_string' ]
ON SIGNAL { system_signal_name | user_signal_name }
[ EVALUATE SELECT_cmd BIND AS variable_name ]
[ WHEN condition ]
[ DECLARE variable_declaration ]
BEGIN
trigger_action
END;
202
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Se vi è una possibilità che esista già un trigger con lo stesso nome di quello che si
desidera creare, utilizzare le parole chiave OR REPLACE facoltative. Se il trigger
esiste, viene sostituito da quello che si sta creando. Se non esiste, ne viene creato
uno nuovo.
Il valore trigger_name deve essere univoco all’interno dell’ObjectServer e conforme
alle convenzioni di denominazione dell’ObjectServer.
Il valore group_name può essere un qualsiasi gruppo trigger già creato utilizzando
il comando CREATE TRIGGER GROUP.
Se DEBUG è impostato su TRUE, le informazioni di debug vengono inviate al log di
messaggi dell’ObjectServer, se il livello dei messaggi è impostato su debug.
Se ENABLED è impostato su TRUE, il trigger viene attivato quando si verifica
l’incidente associato. Altrimenti, il trigger non viene attivato quando si verifica
l’incidente.
Il valore PRIORITY di un trigger determina l’ordine in cui l’ObjectServer attiva i
trigger quando vi sono più trigger associati allo stesso incidente. La priorità può
essere compresa tra 1 e 20. Minore è il numero e maggiore è la priorità; quindi, un
trigger con priorità 2 viene attivato prima di un trigger con priorità 3. Se vengono
attivati più trigger con la stessa priorità a causa dello stesso incidente, l’ordine di
attivazione di tali trigger è indeterminato.
Utilizzare la parola chiave COMMENT facoltativa per aggiungere un commento
(comment_string) per il trigger.
Il nome ON SIGNAL può essere il nome di un segnale di sistema o definito
dall’utente che attiva il trigger.
La clausola EVALUATE facoltativa consente di generare una serie di risultati
temporanea da una singola istruzione SELECT da elaborare in trigger_action.
L’istruzione SELECT non può contenere una clausola ORDER BY.
Nota: La clausola EVALUATE deve qualificare completamente qualsiasi tabella,
inclusa nell’istruzione SELECT, con un nome di database. Ad esempio, la seguente
sintassi non è considerata valida: evaluate select Node from status... La sintassi
corretta è: evaluate select Node from alerts.status...
Quando viene generato un segnale di sistema o definito dall’utente, gli attributi
che identificano la causa del segnale vengono associati al segnale. Questi attributi
vengono trasmessi come variabili implicite nei trigger di segnale associati.
Utilizzare la clausola WHEN facoltativa per verificare una particolare condizione
prima di eseguire l’azione del trigger. Se la condizione non viene soddisfatta,
l’azione trigger non viene eseguita.
È anche possibile dichiarare variabili trigger locali da utilizzare nel corpo del
trigger. Tali variabili vengono dichiarate e utilizzate nello stesso modo delle
variabili di procedura. Tuttavia, le variabili trigger sono statiche, quindi
mantengono il relativo valore tra esecuzioni del trigger.
Capitolo 4. SQL ObjectServer
203
Concetti correlati
“Convenzioni di denominazione per oggetti ObjectServer” a pagina 127
“Condizioni” a pagina 160
Riferimenti correlati
“Segnali di sistema e relativi attributi” a pagina 207
“Migliori pratiche per la creazione di trigger” a pagina 305
Creazione di un segnale definito dall’utente:
Utilizzare il comando CREATE SIGNAL per creare un segnale definito dall’utente.
Quando si crea un segnale, si definisce un elenco di attributi di tipi di dati.
Sintassi
CREATE [ OR REPLACE ] SIGNAL signal_name
[ (signal_attribute_name data_type,...) ]
[ COMMENT 'comment_string' ]
Il nome del segnale deve essere univoco all’interno dell’ObjectServer e conforme
alle convenzioni di denominazione dell’ObjectServer. Non è possibile creare un
segnale definito dall’utente che abbia lo stesso nome di un segnale del sistema.
Quando si definiscono attributi, specificare il nome dell’attributo e un qualsiasi
tipo di dati valido dell’ObjectServer, ad eccezione di VARCHAR o INCR.
È possibile aggiungere un commento che segue la parola chiave COMMENT
facoltativa.
Esempio
Per creare un segnale chiamato illegal_delete con due attributi del tipo stringa di
caratteri, user_name e row_summary, utilizzare il seguente comando:
CREATE SIGNAL illegal_delete( user_name char(40), row_summary char(255) );
Successivamente, è possibile creare un trigger, ad esempio il trigger di database di
pre-inserimento riportato di seguito, per eseguire il trap delle eliminazioni che
hanno luogo al di fuori del normale orario di lavoro e generare questo segnale.
create trigger DETECT_AN_ILLEGAL_DELETE
group default_triggers
priority 1
before delete on alerts.status
for each row
begin
if( ( (hourofday() > 17) and (minuteofhour() > 30) ) or (hourofday() < 9) ) then
raise signal ILLEGAL_DELETE %user.user_name, old.Summary;
cancel;
end if;
end;
Il trigger definito dall’utente riportato di seguito, che viene attivato dal trigger di
database precedente, esegue una procedura esterna per inviare una notifica sotto
forma di e-mail relativa al tentativo di eliminazione.
create trigger AFTER_HOURS_DELETE_WARNING
group default_triggers
priority 1
on signal ILLEGAL_DELETE
204
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
begin
execute MAIL_THE_BOSS( 'User ' + '%signal.user_name ' +
'attempted to remove the row ' + %signal.row_summary + ' at ' +to_char(getdate) )
end;
Concetti correlati
“Convenzioni di denominazione per oggetti ObjectServer” a pagina 127
Riferimenti correlati
“Specifica dei tipi di dati per le colonne” a pagina 133
Generazione di un segnale definito dall’utente:
Utilizzare il comando RAISE SIGNAL per generare un segnale definito dall’utente.
Sintassi
RAISE SIGNAL signal_name expression,...;
Le espressioni devono essere risolte in un valore compatibile con il tipo di dati
dell’attributo associato così come definito utilizzando il comando CREATE
SIGNAL.
Esempio
RAISE SIGNAL illegal_delete %user.user_name, old.Summary;
Eliminazione di un segnale definito dall’utente:
Utilizzare il comando DROP SIGNAL per eliminare un segnale definito dall’utente.
Non è possibile eliminare un segnale se vi fa riferimento un trigger.
Sintassi
DROP SIGNAL signal_name;
Esecuzione di comandi in azioni trigger
trigger_action contiene una serie di comandi che manipolano i dati
nell’ObjectServer.
È possibile utilizzare in un trigger i seguenti comandi SQL:
ALTER SYSTEM BACKUP
ALTER SYSTEM DROP CONNECTION
ALTER SYSTEM SET
ALTER TRIGGER
ALTER TRIGGER GROUP
ALTER USER
UPDATE
INSERT
DELETE
WRITE INTO
RAISE SIGNAL
{ EXECUTE | CALL } PROCEDURE
L’utente che crea il trigger deve disporre delle autorizzazioni appropriate per
eseguire i comandi nel corpo del trigger.
Attenzione: Non è possibile avere dipendenze circolari nei trigger o nelle
procedure; ad esempio, non è necessario creare un trigger che richiama una
procedura che a sua volta causa l’attivazione del trigger originale.
Capitolo 4. SQL ObjectServer
205
È possibile utilizzare in un trigger i seguenti costrutti di programmazione
aggiuntivi:
v L’istruzione di assegnazione SET
v L’istruzione IF THEN ELSE
v L’istruzione CASE WHEN
v Il loop FOR EACH ROW
v Il loop FOR
Riferimenti correlati
“Creazione di trigger di database (comando CREATE TRIGGER)” a pagina 198
“Istruzione SET” a pagina 188
“Istruzione IF THEN ELSE” a pagina 189
“Istruzione CASE WHEN” a pagina 189
“Loop FOR EACH ROW” a pagina 190
“Loop FOR” a pagina 191
Utilizzo di variabili di trigger nelle azioni e nelle condizioni di
trigger
È possibile utilizzare variabili di trigger per accedere a informazioni relative alle
esecuzioni, corrente e precedenti, del trigger. Utilizzare la notazione %trigger per
specificare variabili di trigger. Il simbolo % indica che si sta facendo riferimento a
una variabile implicita. La parola chiave trigger fa riferimento al trigger corrente.
Ad esempio, per fare riferimento a un precedente conteggio di righe del trigger,
utilizzare la sintassi:
%trigger.previous_rowcount
Suggerimento: È anche possibile utilizzare il pulsante % dell’helper per selezionare
variabili %trigger.
La seguente tabella elenca gli attributi di sola lettura disponibili nella clausola
WHEN e nella sezione relativa alle azioni di un trigger.
Tabella 47. Variabili di trigger implicite
Attributo del trigger
Tipo di dati
Descrizione
%trigger.previous_condition
BOOLEAN
Valore della condizione durante
l’ultima esecuzione.
%trigger.previous_rowcount
UNSIGNED
Il numero di righe restituite
dalla clausola EVALUATE
l’ultima volta che il trigger è
stato attivato.
%trigger.num_positive_rowcount UNSIGNED
Numero di attivazioni
consecutive con una o più
corrispondenze nella clausola
EVALUATE.
UNSIGNED
Numero di attivazioni
consecutive con zero
corrispondenze nella clausola
EVALUATE.
%trigger.num_zero_rowcount
206
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 47. Variabili di trigger implicite (Continua)
Attributo del trigger
Tipo di dati
Descrizione
%rowcount
UNSIGNED
Numero di righe che
corrispondono alla clausola
EVALUATE quando viene
attivato un trigger temporale.
Nota: Questa variabile non
richiede l’uso della parola chiave
trigger come prefisso. Il valore
della variabile è solo true se
selezionata come prima azione
nel corpo del trigger. Dopo di
questo, il valore è indeterminato.
Nota: In un trigger di database, l’unica variabile di trigger valida è
%trigger.previous_condition. Tutte le altre variabili di trigger forniscono il
risultato per una clausola EVALUATE, che non è supportata per i trigger di
database.
Esempio
Il trigger del segnale di sistema registra in un file il nome di ciascun utente che si
connette all’ObjectServer.
CREATE TRIGGER LogConnections
GROUP default_triggers
PRIORITY 1
ON SIGNAL connect
BEGIN
WRITE INTO file1 VALUES ('User', %user.user_name, 'has logged on.');
END;
Riferimenti correlati
Appendice B, “Pulsanti helper, espressioni variabili e comandi SQL in strumenti,
automazioni ed elenchi eventi transitori”, a pagina 347
“Variabili utente implicite in procedure e trigger” a pagina 191
Segnali di sistema e relativi attributi
Quando viene generato un segnale di sistema, vengono impostati attributi che
identificano la causa del segnale. Questi attributi vengono trasmessi come variabili
implicite nei trigger di segnale associati.
È possibile fare riferimento a variabili di segnale utilizzando la notazione %signal
nella sezione relativa all’azione di un trigger di segnale. Il simbolo % indica che si
sta facendo riferimento a una variabile implicita. La parola chiave signal fa
riferimento al segnale trasmesso al trigger. Ad esempio, per fare riferimento in un
trigger di segnale all’ora in cui è stato generato un segnale di sistema, utilizzare la
seguente sintassi:
%signal.at
Suggerimento: È anche possibile utilizzare il pulsante dell’helper % per selezionare
variabili %signal.
I segnali di sistema che possono essere generati dall’ObjectServer o dal gateway
sono i seguenti:
v “Segnale di avvio” a pagina 208
v “Segnale di arresto” a pagina 208
Capitolo 4. SQL ObjectServer
207
v
v
v
v
v
“Segnale
“Segnale
“Segnale
“Segnale
“Segnale
di connessione” a pagina 209
di disconnessione” a pagina 209
backup_failed” a pagina 210
backup_succeeded” a pagina 210
login_failed” a pagina 210
v
v
v
v
v
v
v
“Segnale
“Segnale
“Segnale
“Segnale
“Segnale
“Segnale
“Segnale
security_timeout” a pagina 211
create_object” a pagina 211
alter_object” a pagina 212
drop_object” a pagina 213
permission_denied” a pagina 213
gw_counterpart_down” a pagina 214
gw_counterpart_up” a pagina 214
v
v
v
v
v
v
“Segnale
“Segnale
“Segnale
“Segnale
“Segnale
“Segnale
iduc_missed” a pagina 215
iduc_connect” a pagina 215
iduc_disconnect” a pagina 215
iduc_data_fetch” a pagina 216
resync_lock” a pagina 216
resync_unlock” a pagina 217
v “Segnale gw_resync_start” a pagina 217
v “Segnale gw_resync_finish” a pagina 217
Suggerimento: È possibile eseguire query nelle tabelle catalog.primitive_signals e
catalog.primitive_signal_parameters per visualizzare informazioni sui segnali di
sistema. Ad esempio, per visualizzare gli attributi di ciascun segnale di sistema,
utilizzare il seguente comando SQL:
SELECT * FROM catalog.primitive_signal_parameters ORDER BY SignalName,
OrdinalPosition;
Segnale di avvio
Il segnale di avvio viene generato quando l’ObjectServer viene avviato. La
seguente tabella descrive gli attributi di questo segnale:
Tabella 48. Attributi del segnale di avvio
Attributi
Tipo di dati
Descrizione
server
string
Indica il nome dell’ObjectServer che è stato avviato.
node
string
Indica il computer sul quale l’ObjectServer è stato
avviato.
at
UTC
Indica l’ora in cui l’ObjectServer è stato avviato.
Segnale di arresto
Il segnale di arresto viene generato quando l’ObjectServer viene arrestato. La
seguente tabella descrive gli attributi di questo segnale:
Tabella 49. Attributi del segnale di arresto
208
Attributi
Tipo di dati
Descrizione
server
string
Indica il nome dell’ObjectServer che è stato arrestato.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 49. Attributi del segnale di arresto (Continua)
Attributi
Tipo di dati
Descrizione
node
string
Indica il computer sul quale l’ObjectServer è stato
arrestato.
at
UTC
Indica l’ora in cui l’ObjectServer è stato arrestato.
Segnale di connessione
Il segnale di connessione viene generato quando un client si connette
all’ObjectServer. La seguente tabella descrive gli attributi di questo segnale:
Tabella 50. Attributi del segnale di connessione
Attributi
Tipo di dati
Descrizione
process
string
Indica il tipo di processo client che si è connesso
all’ObjectServer.
description
string
Contiene, laddove disponibili, informazioni
aggiuntive sul client connesso. Ad esempio, se il
client è un probe, la descrizione contiene il nome del
probe.
username
string
Indica il nome dell’utente che si è connesso
all’ObjectServer.
node
string
Indica il nome del computer client che si è connesso
all’ObjectServer.
connectionid
int
Identifica in maniera univoca la connessione.
at
UTC
Indica l’ora in cui il client si è connesso.
Segnale di disconnessione
Il segnale di disconnessione viene generato quando un client si disconnette
dall’ObjectServer. La seguente tabella descrive gli attributi di questo segnale:
Tabella 51. Attributi del segnale di disconnessione
Attributi
Tipo di dati
Descrizione
process
string
Indica il tipo di processo che si è disconnesso
dall’ObjectServer.
description
string
Contiene, laddove disponibili, informazioni
aggiuntive sul client che si è disconnesso. Ad
esempio, se il client è un probe, la descrizione
contiene il nome del probe.
username
string
Indica il nome dell’utente che si è disconnesso
dall’ObjectServer.
node
string
Indica il nome del computer client che si è
disconnesso dall’ObjectServer.
connectionid
int
Identifica in maniera univoca la connessione.
at
UTC
Indica l’ora in cui il client si è disconnesso.
Capitolo 4. SQL ObjectServer
209
Segnale backup_failed
Il segnale backup_failed viene generato quando un tentativo di backup
dell’ObjectServer si conclude con esito negativo. La seguente tabella descrive gli
attributi di questo segnale:
Tabella 52. Attributi del segnale backup_failed
Attributi
Tipo di dati
Descrizione
error
string
Indica il motivo per il quale il tentativo di backup
non è riuscito.
at
UTC
Indica l’ora in cui è stato eseguito il tentativo di
backup.
path_prefix
string
Indica la directory in cui il backup ha tentato di
scrivere.
elapsed_time
real
Indica la quantità di tempo in cui il backup è stato
in esecuzione prima di interrompersi.
node
string
Indica il nome del computer da cui è stato eseguito
il backup.
Segnale backup_succeeded
Il segnale backup_succeeded viene generato quando il backup dell’ObjectServer
viene eseguito correttamente. La seguente tabella descrive gli attributi di questo
segnale:
Tabella 53. Attributi del segnale backup_succeeded
Attributi
Tipo di dati
Descrizione
at
UTC
Indica l’ora in cui è stato eseguito il backup.
path_prefix
string
Indica la directory in cui è stato scritto il backup.
elapsed_time
real
Indica la quantità di tempo necessaria per il
completamento del backup.
node
string
Indica il nome del computer da cui è stato eseguito
il backup.
Segnale login_failed
Il segnale login_failed viene generato quando un client non riesce ad accedere
all’ObjectServer. La seguente tabella descrive gli attributi di questo segnale:
Tabella 54. Attributi del segnale login_failed
210
Attributi
Tipo di dati
Descrizione
process
string
Indica il nome del processo che non si è potuto
connettere perché l’accesso è stato negato.
username
string
Indica il nome dell’utente che non è riuscito a
connettersi perché l’accesso è stato negato.
node
string
Indica il nome del computer client che non si è
potuto connettere perché l’accesso è stato negato.
at
UTC
Indica l’ora in cui il client non è riuscito a
connettersi perché l’accesso è stato negato.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Segnale security_timeout
Il segnale security_timeout viene generato quando un tentativo di accesso
all’ObjectServer entra in timeout. La seguente tabella descrive gli attributi di questo
segnale:
Tabella 55. Attributi del segnale security_timeout
Attributi
Tipo di dati
Descrizione
process
string
Indica il nome del processo che non è riuscito a
connettersi perché non è stato possibile convalidare
le credenziali di accesso.
username
string
Indica il nome dell’utente che non è riuscito a
connettersi perché non è stato possibile convalidare
le credenziali di accesso.
node
string
Indica il nome del computer client che non è riuscito
a connettersi perché non è stato possibile convalidare
le credenziali di accesso.
at
UTC
Indica l’ora in cui il client non è riuscito a
connettersi perché non è stato possibile convalidare
le credenziali di accesso.
Segnale create_object
Il segnale create_object viene generato quando viene creato un oggetto
nell’ObjectServer. La seguente tabella descrive gli attributi di questo segnale:
Tabella 56. Attributi del segnale create_object
Attributi
Tipo di dati
Descrizione
objecttype
string
Indica il tipo di oggetto, uno tra quelli elencati di
seguito:
v CREATE DATABASE
v CREATE TABLE
v CREATE INDEX
v CREATE TRIGGER GROUP
v CREATE TRIGGER
v CREATE PROCEDURE
v CREATE RESTRICTION FILTER
v CREATE USER SIGNAL
v CREATE FILE
v CREATE USER
v CREATE GROUP
v CREATE ROLE
parentname
string
Indica il nome dell’oggetto parent. Per i trigger, si
tratta del nome del gruppo di trigger. Per le tabelle,
si tratta del nome del database. Gli altri oggetti non
hanno un oggetto parent.
name
string
Indica il nome dell’oggetto. Ad esempio, il valore
per la tabella alerts.status è status.
username
string
Indica il nome dell’utente che ha eseguito il
comando.
Capitolo 4. SQL ObjectServer
211
Tabella 56. Attributi del segnale create_object (Continua)
Attributi
Tipo di dati
Descrizione
server
string
Indica il nome dell’ObjectServer al quale l’oggetto è
stato aggiunto.
node
string
Indica il nome del computer su cui è in esecuzione
l’ObjectServer al quale è stato aggiunto l’oggetto.
hostname
string
Indica il nome del computer client da cui è stata
eseguita la richiesta per aggiungere l’oggetto.
at
UTC
Indica l’ora in cui l’oggetto è stato aggiunto.
Segnale alter_object
Il segnale alter_object viene generato quando un oggetto nell’ObjectServer viene
modificato. La seguente tabella descrive gli attributi di questo segnale:
Tabella 57. Attributi del segnale alter_object
Attributi
Tipo di dati
Descrizione
objecttype
string
Indica il tipo di oggetto, uno tra quelli elencati di
seguito:
v ALTER TABLE
v ALTER TRIGGER GROUP
v ALTER TRIGGER
v ALTER PROCEDURE
v ALTER RESTRICTION FILTER
v ALTER USER SIGNAL
v ALTER FILE
v ALTER USER
v ALTER GROUP
v ALTER ROLE
Nota: Sono necessarie le autorizzazioni ALTER
PROCEDURE, ALTER RESTRICTION FILTER e
ALTER USER SIGNAL se il comando CREATE OR
REPLACE viene eseguito su uno di questi tipi di
oggetto e l’oggetto esiste già. È necessario disporre
dell’autorizzazione ALTER appropriata anche se non
c’è alcun comando ALTER per questi oggetti.
212
parentname
string
Indica il nome dell’oggetto parent. Per i trigger, si
tratta del nome del gruppo di trigger. Per le tabelle,
si tratta del nome del database. Gli altri oggetti non
hanno un oggetto parent.
name
string
Indica il nome dell’oggetto. Ad esempio, il valore
per la tabella alerts.status è status.
username
string
Indica il nome dell’utente che ha eseguito il
comando.
server
string
Indica il nome dell’ObjectServer in cui è stato
modificato l’oggetto.
node
string
Indica il nome del computer su cui è in esecuzione
l’ObjectServer in cui è stato modificato l’oggetto.
hostname
string
Indica il nome del computer client da cui è stata
eseguita la richiesta di modificare l’oggetto.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 57. Attributi del segnale alter_object (Continua)
Attributi
Tipo di dati
Descrizione
at
UTC
Indica l’ora in cui l’oggetto è stato modificato.
Segnale drop_object
Il segnale drop_object viene generato quando un oggetto nell’ObjectServer viene
eliminato. La seguente tabella descrive gli attributi di questo segnale:
Tabella 58. Attributi del segnale drop_object
Attributi
Tipo di dati
Descrizione
objecttype
string
Indica il tipo di oggetto, uno tra quelli elencati di
seguito:
v DROP DATABASE
v DROP TABLE
v DROP INDEX
v DROP TRIGGER GROUP
v DROP TRIGGER
v DROP PROCEDURE
v DROP RESTRICTION FILTER
v DROP USER SIGNAL
v DROP FILE
v DROP USER
v DROP GROUP
v DROP ROLE
parentname
string
Indica il nome dell’oggetto parent. Per i trigger, si
tratta del nome del gruppo di trigger. Per le tabelle,
si tratta del nome del database. Gli altri oggetti non
hanno un oggetto parent.
name
string
Indica il nome dell’oggetto. Ad esempio, il valore
per la tabella alerts.status è status.
username
string
Indica il nome dell’utente che ha eseguito il
comando.
server
string
Indica il nome dell’ObjectServer dal quale è stato
rimosso l’oggetto.
node
string
Indica il nome del computer su cui è in esecuzione
l’ObjectServer dal quale è stato rimosso l’oggetto.
hostname
string
Indica il nome del computer client da cui è stata
eseguita la richiesta di eliminare l’oggetto.
at
UTC
Indica l’ora in cui l’oggetto è stato eliminato.
Segnale permission_denied
Il segnale permission_denied viene generato quando viene negata l’autorizzazione
per eseguire un’operazione. La seguente tabella descrive gli attributi di questo
segnale:
Capitolo 4. SQL ObjectServer
213
Tabella 59. Attributi del segnale permission_denied
Attributi
Tipo di dati
Descrizione
username
string
Indica il nome dell’utente che ha eseguito la richiesta
che ha causato l’errore di autorizzazione negata.
server
string
Indica il nome dell’ObjectServer che ha generato
l’errore di autorizzazione negata.
node
string
Indica il nome del computer su cui è in esecuzione
l’ObjectServer che ha generato l’errore di
autorizzazione negata.
hostname
string
Indica il nome del computer client da cui è stata
eseguita la richiesta che ha causato l’errore di
autorizzazione negata.
at
UTC
Indica l’ora in cui si è verificato l’errore di
autorizzazione negata.
sql_cmd
string
Indica il comando SQL che ha causato l’errore di
autorizzazione negata.
Segnale gw_counterpart_down
Il gateway genera un segnale gw_counterpart_down nell’ObjectServer di backup
quando rileva che l’ObjectServer primario non è disponibile. La seguente tabella
descrive gli attributi di questo segnale:
Tabella 60. Attributi del segnale gw_counterpart_down
Attributi
Tipo di dati
Descrizione
server
string
Indica il nome dell’ObjectServer della controparte
che ha generato un errore, in una coppia
failover/failback.
node
string
Indica il nome del computer da cui è stato eseguito
l’ObjectServer della controparte.
at
UTC
Indica l’ora in cui l’ObjectServer della controparte ha
generato un errore.
gateway_name
string
Indica il nome del gateway tra l’ObjectServer
primario e quello di backup.
Segnale gw_counterpart_up
Il gateway genera un segnale gw_counterpart_up nell’ObjectServer di backup
quando rileva che l’ObjectServer primario è di nuovo disponibile. La seguente
tabella descrive gli attributi di questo segnale:
Tabella 61. Attributi del segnale gw_counterpart_up
214
Attributi
Tipo di dati
Descrizione
server
string
Indica il nome dell’ObjectServer della controparte
che è di nuovo disponibile, in una coppia
failover/failback.
node
string
Indica il nome del computer da cui è stato eseguito
l’ObjectServer della controparte.
at
UTC
Indica l’ora in cui l’ObjectServer della controparte ha
generato un errore.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 61. Attributi del segnale gw_counterpart_up (Continua)
Attributi
Tipo di dati
Descrizione
gateway_name
string
Indica il nome del gateway tra l’ObjectServer
primario e quello di backup.
Segnale iduc_missed
Il segnale iduc_missed viene generato ogni volta che un client gateway o desktop
non riesce a rispondere a un prompt IDUC dell’ObjectServer. La seguente tabella
descrive gli attributi di questo segnale:
Tabella 62. Attributi del segnale iduc_missed
Attributi
Tipo di dati
Descrizione
process
string
Indica il tipo di processo client che non è riuscito a
rispondere al prompt IDUC dell’ObjectServer.
description
string
Contiene, laddove disponibili, ulteriori informazioni
sul client.
username
string
Indica il nome dell’utente che si è connesso
all’ObjectServer.
node
string
Indica il nome del computer client che si è connesso
all’ObjectServer.
connectionid
int
Identifica in maniera univoca la connessione.
at
UTC
Indica l’ora in cui il ciclo IDUC non è stato eseguito.
missed_cycles
int
Indica il numero di cicli IDUC consecutivi che non
non sono stati eseguiti.
Segnale iduc_connect
Il segnale iduc_connect viene generato quando un client stabilisce una connessione
IDUC. La seguente tabella descrive gli attributi di questo segnale:
Tabella 63. Attributi del segnale iduc_connect
Attributi
Tipo di dati
Descrizione
process
string
Indica il tipo di processo client che si è connesso
all’ObjectServer.
description
string
Contiene, laddove disponibili, informazioni
aggiuntive sul client connesso. Ad esempio, se il
client è un probe, la descrizione contiene il nome del
probe.
username
string
Indica il nome dell’utente che si è connesso
all’ObjectServer.
node
string
Indica il nome del computer client che si è connesso
all’ObjectServer.
conn_id
int
Indica l’ID della connessione.
Segnale iduc_disconnect
Il segnale iduc_disconnect viene generato quando un client disconnette una
connessione IDUC stabilita. La seguente tabella descrive gli attributi di questo
segnale:
Capitolo 4. SQL ObjectServer
215
Tabella 64. Attributi del segnale iduc_disconnect
Attributi
Tipo di dati
Descrizione
process
string
Indica il tipo di processo client che si è disconnesso
dall’ObjectServer.
description
string
Contiene, laddove disponibili, informazioni
aggiuntive sul client che si è disconnesso. Ad
esempio, se il client è un probe, la descrizione
contiene il nome del probe.
username
string
Indica il nome dell’utente che si è disconnesso
dall’ObjectServer.
node
string
Indica il nome del computer client che si è
disconnesso dall’ObjectServer.
conn_id
int
Indica l’ID della connessione.
Segnale iduc_data_fetch
Il segnale iduc_data_fetch viene generato ogni volta che un client IDUC richiama le
relative modifiche IDUC dall’ObjectServer. La seguente tabella descrive gli attributi
di questo segnale:
Tabella 65. Attrubuti del segnale iduc_data_fetch
Attributi
Tipo di dati
Descrizione
process
string
Indica il tipo di processo client che ha richiesto
modifiche IDUC in sospeso dall’ObjectServer.
description
string
Contiene, laddove disponibili, ulteriori informazioni
sul client. Ad esempio, se il client è un probe, la
descrizione contiene il nome del probe.
username
string
Indica il nome dell’utente che si è connesso
all’ObjectServer.
node
string
Indica il nome del computer client che si è connesso
all’ObjectServer.
connectionid
int
Identifica in maniera univoca la connessione.
at
UTC
Indica l’ora in cui il client ha richiamato le modifiche
che corrispondono all’ultima notifica IDUC.
Segnale resync_lock
Il segnale resync_lock viene generato dall’ObjectServer quando il blocco di
risincronizzazione viene bloccato. La seguente tabella descrive gli attributi di
questo segnale:
Tabella 66. Attributi del segnale resync_lock
216
Attributi
Tipo di dati
Descrizione
process
string
Indica il tipo di processo client che ha bloccato il
blocco di risincronizzazione.
description
string
Contiene, laddove disponibili, informazioni
aggiuntive sul client che ha bloccato il blocco di
risincronizzazione. Ad esempio, se il client è un
probe, la descrizione contiene il nome del probe.
username
string
Indica il nome dell’utente che esegue il processo.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 66. Attributi del segnale resync_lock (Continua)
Attributi
Tipo di dati
Descrizione
node
string
Indica il nome del computer client connesso
all’ObjectServer.
at
UTC
Indica l’ora in cui è stato generato il segnale
Segnale resync_unlock
Il segnale resync_unlock viene generato dall’ObjectServer quando il blocco di
risincronizzazione viene sbloccato. La seguente tabella descrive gli attributi di
questo segnale:
Tabella 67. Attributi del segnale resync_unlock
Attributi
Tipo di dati
Descrizione
process
string
Indica il tipo di processo client che ha sbloccato il
blocco di risincronizzazione.
description
string
Contiene, laddove disponibili, informazioni
aggiuntive sul client che ha sbloccato il blocco di
risincronizzazione. Ad esempio, se il client è un
probe, la descrizione contiene il nome del probe.
username
string
Indica il nome dell’utente che esegue il processo.
node
string
Indica il nome del computer client connesso
all’ObjectServer.
at
UTC
Indica l’ora in cui è stato generato il segnale
Segnale gw_resync_start
Il segnale gw_resync_start viene avviato dal gateway per indicare l’avvio
dell’operazione di risincronizzazione. La seguente tabella descrive gli attributi di
questo segnale:
Tabella 68. Attributi del segnale gw_resync_start
Attributi
Tipo di dati
Descrizione
gateway_name
string
Indica il nome del gateway che sta avviando la
risincronizzazione.
node
string
Indica il nome host del computer sul quale è in
esecuzione il gateway.
at
UTC
Indica l’ora in cui la risincronizzazione è stata
avviata.
is_master
Boolean
Indica se l’ObjectServer locale è l’elemento principale
o secondario della risincronizzazione.
Segnale gw_resync_finish
Il segnale gw_resync_finish viene generato dal gateway per indicare la fine di
un’operazione di risincronizzazione. La seguente tabella descrive gli attributi di
questo segnale:
Capitolo 4. SQL ObjectServer
217
Tabella 69. Attributi del segnale gw_resync_finish
Attributi
Tipo di dati
Descrizione
gateway_name
string
Indica il nome del gateway che sta terminando la
risincronizzazione.
node
string
Indica il nome host del computer sul quale è in
esecuzione il gateway.
at
UTC
Indica l’ora in cui è terminata la risincronizzazione.
is_master
Boolean
Indica se l’ObjectServer locale è l’elemento principale
o secondario della risincronizzazione.
Riferimenti correlati
Appendice B, “Pulsanti helper, espressioni variabili e comandi SQL in strumenti,
automazioni ed elenchi eventi transitori”, a pagina 347
Creazione di trigger per la notifica eventi accelerati
Per supportare la notifica eventi accelerati, creare trigger di post-inserimento,
post-aggiornamento o post-reinserimento da associare alla tabella alerts.status. Nei
trigger, configurare delle condizioni per definire o identificare gli eventi accelerati
quando tali eventi vengono inseriti o aggiornati nella tabella alerts.status e per
inoltrarli ai client AEN (Accelerated Event Notification) rilevanti.
Sono disponibili due comandi SQL da utilizzare con i trigger: un comando di
traccia rapida dell’evento (o evento accelerato) (IDUC EVTFT) e un comando di
invio messaggio (IDUC SNDMSG).
Suggerimento: Potrebbe essere utile raggruppare i trigger che supportano la
notifica eventi accelerati all’interno del relativo gruppo trigger.
Concetti correlati
Capitolo 5, “Configurazione della notifica eventi accelerati”, a pagina 231
Attivazione della notifica eventi accelerati (comando IDUC EVTFT):
Utilizzare il comando IDUC EVTFT per attivare i programmi di notifica pop up
per eventi accelerati da inviare ai client e per abilitare la funzione per fare clic
nell’elenco eventi o nell’AEL (Elenco eventi attivi) di Web GUI.
Sintassi
IDUC EVTFT destination, action_type, row
Le variabili presenti in questo comando possono accettare i seguenti valori:
v destination = spid | iduc_channel
v spid = integer_expression (l’ID connessione client letterale)
v iduc_channel = string_expression (il nome del canale)
v action_type = INSERT | UPDATE | DELETE
v row = variable (il riferimento al nome di variabile di una riga nell’automazione)
Ad esempio, se è stato configurato un indicatore di eventi accelerati nel file delle
regole di probe ed è stata aggiunta una colonna per questo indicatore alla tabella
alerts.status, è possibile aggiungere una condizione in un trigger di
post-inserimento per esaminare il valore in questa colonna. Se il valore viene
soddisfatto per la notifica eventi accelerati, l’evento viene inoltrato come notifica
218
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
pop up a specifici client AEN (Accelerated Event Notification). È possibile definire
la condizione nel trigger utilizzando il seguente formato:
begin
if ( new.accelerated_event_column_name = 1 )
then
iduc evtft 'channel_name' , insert , new ;
end if;
end;
In questa sintassi, accelerated_event_column_name è il nome della colonna che
contiene l’indicatore degli eventi accelerati nella tabella alerts.status, mentre
channel_name è il nome di un canale sul quale vengono trasmessi i dati degli eventi
accelerati. Dal momento che il nome del canale rispetta la distinzione
maiuscolo/minuscolo, assicurarsi di utilizzare il formato lettere corretto nella
sintassi.
Esempio
create or replace trigger evtft_insert
group channel_triggers
priority 1
comment 'Fast track critical events from alerts.status'
after insert on alerts.status
for each row
begin
if ( new.FastTrack = 1 )
then
iduc evtft 'FastTrack' , insert , new ;
end if;
end;
Invio di messaggi a client AEN (Accelerated Event Notification) (comando IDUC
SNDMSG):
Utilizzare il comando IDUC SNDMSG per inviare messaggi informativi a un client
AEN (Accelerated Event Notification).
Sintassi
IDUC SNDMSG destination, string_expression
Le variabili presenti in questo comando possono accettare i seguenti valori:
v destination = spid | iduc_channel
v spid = integer_expression (l’ID connessione client letterale)
v iduc_channel = string_expression (nome del canale)
v string_expression = testo descrittivo da inviare come messaggio
Esempio
create trigger notify_isqlconn
group default_triggers
priority 1
on signal connect
begin
if( %signal.process = 'isql' )
then
iduc sndmsg 'notif_isql', 'ISQL Connection from ' +
%signal.node + ' from user ' +
%signal.username + ' at ' +
to_char(%signal.at)
end if;
end;
Capitolo 4. SQL ObjectServer
219
Modifica di un trigger (comando ALTER TRIGGER)
Utilizzare il comando ALTER TRIGGER per modificare le impostazioni di un
trigger esistente. Con un singolo comando ALTER TRIGGER, è possibile modificare
più di una impostazione.
Sintassi
ALTER TRIGGER trigger_name
SET PRIORITY integer
SET ENABLED { TRUE | FALSE }
SET GROUP trigger_group_name
SET DEBUG { TRUE | FALSE };
Utilizzare SET PRIORITY per modificare la priorità di un trigger e impostarla su
un valore compreso tra 1 e 20. Più piccolo è il numero, più alta è la priorità.
Utilizzare SET ENABLED TRUE per attivare un trigger o SET ENABLED FALSE
per disattivare un trigger. Se un trigger è ENABLED, viene attivato quando si
verifica l’incidente associato. Se un trigger non è ENABLED, quando si verifica
l’incidente associato, non viene attivato.
Utilizzare SET GROUP per modificare il gruppo di trigger del trigger nel nome del
gruppo specificato.
Utilizzare SET DEBUG per attivare o disattivare il debug per il trigger. Se attivato,
le informazioni di debug vengono inviate al log di messaggi dell’ObjectServer, se il
livello dei messaggi è impostato su debug.
Esempio
alter trigger mytrig set priority 1;
Eliminazione di un trigger (comando DROP TRIGGER)
Utilizzare il comando DROP TRIGGER per eliminare un trigger esistente.
Sintassi
DROP TRIGGER trigger_name;
Non è possibile eliminare un trigger se ci sono oggetti che dipendono da esso.
Esempio
drop trigger mytrig;
Automazioni di Tivoli Netcool/OMNIbus standard
Con Tivoli Netcool/OMNIbus viene fornita una serie di automazioni standard.
Queste automazioni vengono create durante l’inizializzazione del database.
Le automazioni standard si trovano nell’ubicazione: $NCHOME/omnibus/etc/
automation.sql. È possibile aprire il file automation.sql in un editor di testo e
visualizzare la sintassi di ciascuna automazione. Sono inclusi commenti per
descrivere lo scopo delle automazioni. Alcune automazioni nel file automation.sql
non sono disponibili per impostazione predefinita.
Attenzione: Non correggere le automazioni nel file automation.sql, in quanto le
modifiche a questo file potrebbero influire sull’esecuzione dell’ObjectServer.
220
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
È anche possibile utilizzare Netcool/OMNIbus Administrator per eseguire ricerche
in queste automazioni selezionando il pulsante di menu Automation dalla finestra
Netcool/OMNIbus Administrator. È possibile notare che alcuni gruppi di trigger
sono disabilitati per impostazione predefinita, mentre lo stato dei trigger che
appartengono a quei gruppi di trigger è abilitato. È necessario abilitare questi
gruppi di trigger per poter eseguire i trigger. Un esempio è il gruppo di trigger
audit_config, che consente di generare avvisi ogni volta che vengono apportate
modifiche agli oggetti ObjectServer. Questo gruppo di trigger può essere utilizzato
come meccanismo di verifica unitamente ai file di log di verifica, i quali vengono
scritti nella directory $NCHOME/omnibus/log.
Le funzioni eseguite da alcune automazioni standard includono:
v Backup dell’ObjectServer
v Aggiunta di avvisi all’ObjectServer
v Inserimento di voci di journal
v Rimozione di voci ridondanti da varie tabelle
Le automazioni standard sono elencate nella seguente tabella:
Tabella 70. Automazioni standard
Nome del trigger o della
procedura
Descrizione
audit_config_alter_class
Crea un avviso per segnalare che è stata modificata
una classe.
audit_config_alter_col_visual
Crea un avviso per segnalare che è stata modificata
una visuale di colonna.
audit_config_alter_conv
Crea un avviso per segnalare che è stata modificata
una conversione.
audit_config_alter_menu
Crea un avviso per segnalare che è stato modificato
un menu.
audit_config_alter_object
Crea un avviso per segnalare che è stato modificato
un oggetto.
audit_config_alter_prompt
Crea un avviso per segnalare che è stato modificato
un prompt.
audit_config_alter_property
Crea un avviso per segnalare che è stata modificata
una proprietà.
audit_config_alter_tool
Crea un avviso per segnalare che è stato modificato
uno strumento.
audit_config_create_class
Crea un avviso per segnalare che è stata creata una
classe.
audit_config_create_col_visual
Crea un avviso per segnalare che è stata creata una
visuale di colonna.
audit_config_create_conv
Crea un avviso per segnalare che è stata creata una
conversione.
audit_config_create_menu
Crea un avviso per segnalare che è stato creato un
menu.
audit_config_create_object
Crea un avviso per segnalare che è stato creato un
oggetto.
audit_config_create_prompt
Crea un avviso per segnalare che è stato creato un
prompt.
Capitolo 4. SQL ObjectServer
221
Tabella 70. Automazioni standard (Continua)
Nome del trigger o della
procedura
222
Descrizione
audit_config_create_tool
Crea un avviso per segnalare che è stato creato uno
strumento.
audit_config_drop_class
Crea un avviso per segnalare che è stata eliminata
una classe.
audit_config_drop_col_visual
Crea un avviso per segnalare che è stata eliminata
una visuale di colonna.
audit_config_drop_conv
Crea un avviso per segnalare che è stata eliminata
una conversione.
audit_config_drop_menu
Crea un avviso per segnalare che è stato eliminato un
menu.
audit_config_drop_object
Crea un avviso per segnalare che è stato eliminato un
oggetto.
audit_config_drop_prompt
Crea un avviso per segnalare che è stato eliminato un
prompt.
audit_config_drop_tool
Crea un avviso per segnalare che è stato eliminato
uno strumento.
audit_config_permission_denied
Crea un avviso per segnalare che è stata negata
un’autorizzazione.
automatic_backup
Esegue il backup di tutti gli archivi di memoria
dell’ObjectServer in una sequenza di ubicazioni che
dipende dal valore definito per la variabile
num_backups.
automation_disable
Disabilita le automazioni che non dovrebbero essere
in esecuzione quando l’ObjectServer è un
ObjectServer di backup.
automation_enable
Abilita le automazioni che dovrebbero essere in
esecuzione quando l’ObjectServer è un ObjectServer
primario.
backup_counterpart_down
Abilita le automazioni che dovrebbero essere in
esecuzione quando l’ObjectServer primario diventa
inattivo e l’ObjectServer di backup funge da
ObjectServer primario.
backup_counterpart_up
Disabilita le automazioni che non dovrebbero essere
in esecuzione nell’ObjectServer di backup quando
l’ObjectServer primario viene riavviato.
backup_failed
Specifica un’azione da eseguire quando
un’operazione di backup non riesce.
backup_startup
Disabilita le automazioni che non dovrebbero essere
in esecuzione quando viene avviato un ObjectServer
designato come backup.
backup_state_integrity
Assicura che sia presente solo un record nella tabella
di stato di backup annullando tutti gli eventuali
inserimenti.
backup_succeeded
Specifica un’azione da eseguire quando
un’operazione di backup riesce.
clean_details_table
Esegue operazioni di pulizia ordinarie nella tabella
alerts.details. Elimina qualsiasi voce che non si trova
nella tabella alerts.status.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 70. Automazioni standard (Continua)
Nome del trigger o della
procedura
Descrizione
clean_journal_table
Esegue operazioni di pulizia ordinarie nella tabella
alerts.journal. Elimina qualsiasi voce che non si trova
nella tabella alerts.status.
connection_watch_connect
Crea un avviso quando si connette un nuovo client. Il
nome del processo o dell’applicazione identificato dal
segnale viene confrontato con la tabella
alerts.application_types per identificare la severità
appropriata e il tipo di evento per la connessione.
Una connessione di un gateway, ad esempio, viene
gestita come risoluzione (cancellazione di una
disconnessione), mentre una connessione di un elenco
eventi è un evento di Tipo 1, che verrà risolto
mediante una disconnessione.
connection_watch_disconnect
Crea un avviso quando un client si disconnette. Il
nome del processo o dell’applicazione identificato dal
segnale viene confrontato con la tabella
alerts.application_types per identificare la severità
appropriata e il tipo di evento per la disconnessione.
La disconnessione di un gateway, ad esempio, viene
gestita come problema, mentre la disconnessione
dell’elenco eventi viene gestita come risoluzione.
dedup_status_inserts
Conteggia gli inserimenti nella tabella status
deduplicati.
deduplicate_details
Deduplica le righe nella tabella alerts.details.
deduplicate_iduc_stats
Deduplica le righe nella tabella
iduc_system.iduc_stats.
deduplication
L’elaborazione della deduplicazione per la tabella
alerts.status. Mantiene il valore tally di
deduplicazione e aggiorna i dettagli della tabella
alert.
delete_clears
Ogni 60 secondi, elimina gli avvisi con stato chiaro
inseriti da più di due minuti nella tabella
alerts.status.
details_inserts
Conteggia gli inserimenti della tabella details.
disable_inactive_users
Viene eseguita una volta al giorno per disabilitare
utenti che non si sono connessi all’ObjectServer entro
un periodo definito.
disable_user
Disabilita gli utenti quando non riescono a collegarsi
dopo n tentativi consecutivi il cui esito è stato
negativo.
disconnect_iduc_missed
Disconnette i client in tempo reale che non hanno
comunicato con l’ObjectServer per cinque periodi di
granularità.
escalate_off
Imposta il campo Flash su 0 (nessuna intermittenza) e
SuppressEscl su 0 (di cui non viene eseguita
l’escalation in questo esempio) quando un evento che
aveva precedentemente il campo Flash impostato su 1
viene riconosciuto o se l’evento viene risolto (Severity
= 0).
Capitolo 4. SQL ObjectServer
223
Tabella 70. Automazioni standard (Continua)
Nome del trigger o della
procedura
224
Descrizione
expire
Gestisce la scadenza degli avvisi. Imposta la severità
di un avviso su 0 se il valore di ExpireTime (durante
il quale l’avviso è valido) viene superato.
flash_not_ack
Imposta Flashing su (Flash = 1) per eventi che sono
stati generati da 10 minuti e che sono Critical
(Severity = 5), ma che non sono stati ancora
riconosciuti da un utente (Acknowledge = 0). Imposta
SuppressEscl su 1 come ulteriore indicazione dello
stato di escalation dell’evento.
generic_clear
Risolve (Severity = 0) tutte le righe nella tabella
alerts.status che indicano un dispositivo non attivo
(Type = 1), per le quali c’è una riga inserita
successivamente che indica che il dispositivo è
tornato attivo (Type = 2).
iduc_messages_tblclean
Esegue operazioni di pulizia ordinarie nella tabella
alerts.iduc_messages. Viene eseguita ogni 60 secondi
ed elimina messaggi emessi da oltre due minuti.
iduc_stats_insert
Inserisce una voce client nella tabella
iduc_system.iduc_stats quando viene generato il
segnale iduc_connect.
iduc_stats_update
Aggiorna il campo LastIducTime nella tabella
iduc_system.iduc_stats quando viene generato il
segnale iduc_data_fetch.
jinsert
Inserisce un record nella tabella alerts.journal. Le
automazioni che richiedono voci di journal
dovrebbero eseguire questa procedura.
journal_inserts
Conteggia gli inserimenti di tabelle di journal.
mail_on_critical
Inviare e-mail relative ad avvisi critici che dopo 30
minuti non vengono riconosciuti.
Nota: Questo strumento è specifico di UNIX, a meno
che non sia disponibile un mailer NT equivalente.
new_row
Imposta i valori predefiniti per nuovi avvisi nella
tabella alerts.status.
new_status_inserts
Conteggia i nuovi inserimenti della tabella status.
pass_deletes
Elimina dall’ObjectServer di destinazione righe che
non sono presenti nell’ObjectServer di origine dopo la
risincronizzazione.
profiler_group_report
Scrive nel file profiler_report, una riga per la
somma della quantità di tempo richiesta da ciascun
tipo diverso di applicazione durante l’ultimo periodo
di creazione profili.
profiler_report
Scrive nel file profiler_report, una riga per ciascun
client connesso con la quantità di tempo richiesta dal
singolo client durante l’ultimo periodo di creazione
profili.
profiler_toggle
Segnala che il profiler è stato attivato/disattivato.
reset_user
Reimposta il conteggio degli errori di un utente
quando esegue l’accesso correttamente.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 70. Automazioni standard (Continua)
Nome del trigger o della
procedura
Descrizione
resync_finished
Identifica quando la risincronizzazione è completa e
imposta la proprietà ActingPrimary dell’ObjectServer
di backup su FALSE per definirlo come backup.
security_watch_security_failure
Crea un avviso quando un client non riesce ad
autenticarsi.
service_insert
Elaborazione del servizio per la tabella service.status.
service_reinsert
Elaborazione del servizio per la tabella service.status.
service_update
Elaborazione del servizio per la tabella service.status.
state_change
Elaborazione delle modifiche dello stato per la tabella
alerts.status. Mantiene la data/ora dell’ObjectServer
dell’ultimo inserimento o aggiornamento di un avviso
da una qualsiasi origine.
statistics_cleanup
Elimina statistiche generate da più di un’ora.
statistics_gather
Raccoglie metriche quali, ad esempio, il numero
totale di client connessi all’ObjectServer, il numero di
client in tempo reale e il numero di nuovi inserimenti
nella tabella alerts.status, quindi inserisce le metriche
nella tabella master.stats.
Questi dati possono essere visualizzati utilizzando
Netcool/OMNIbus Administrator o nco_sql oppure
possono essere scritti in un file o possono essere
elaborati da altre automazioni.
stats_reset
Ripristina i dati delle statistiche.
system_watch_shutdown
Crea un avviso per segnalare che l’ObjectServer verrà
arrestato.
system_watch_startup
Crea un avviso per segnalare che l’ObjectServer è
stato avviato.
trigger_stats_report
Scrive nel file trigger_stats.log, la quantità di
tempo che ciascun trigger ha utilizzato nell’ultimo
periodo di creazione profili.
update_service_affecting_events
Viene eseguita a una frequenza specificata per
consentire l’eliminazione automatica di SAE (Service
Affected Event) in Network Manager IP Edition
quando vengono rimossi tutti i relativi eventi
correlati. Un SAE (Service Affected Event) è un
avviso che indica agli operatori che un servizio
cliente critico è stato interessato da uno o più eventi
di rete.
Questa automazione funziona solo con Tivoli
Netcool/OMNIbus V7 .0 o successive.
Suggerimento: L’automazione è richiesta solo se si
utilizza Network Manager IP Edition insieme alle
tabelle precision.entity_service,
precision.service_details e
precision.service_affecting_event.
Capitolo 4. SQL ObjectServer
225
Tabella 70. Automazioni standard (Continua)
Nome del trigger o della
procedura
webtop_compatibility
Descrizione
Inserisce nella tabella master.profiles gli utenti
dell’ObjectServer in modo che Web GUI (o
Netcool/Webtop) possa leggerli. Inoltre, imposta il
campo AllowISQL su ciascun utente a cui è stata
concessa l’autorizzazione per utilizzare lo strumento
SQL interattivo in Web GUI (o Netcool/Webtop).
Suggerimento: Questa automazione è disabilitata per
impostazione predefinita e dovrebbe essere abilitata
solo se si utilizza Web GUI (o Netcool/Webtop) e gli
utenti sono autorizzati a utilizzare l’SQL interattivo.
Automazione per SAE (Service Affected Event)
Un SAE (Service Affected Event) è un avviso che indica agli operatori che un
servizio clienti critico è stato influenzato da uno o più eventi di rete. I SAE (Service
Affected Event) vengono generati all’interno di IBM Tivoli Network Manager IP
Edition.
È possibile configurare Tivoli Netcool/OMNIbus per eseguire un’automazione a
una frequenza specificata per consentire la cancellazione automatica dei SAE
(Service Affected Event) Network Manager IP Edition quando vengono cancellati
tutti i relativi eventi correlati.
Per rendere operativa questa funzione per un’installazione di Network Manager IP
Edition e di Tivoli Netcool/OMNIbus, è necessario configurare Network Manager
IP Edition come descritto in IBM Tivoli Network Manager IP Edition Installation and
Configuration Guide, SC23-9498. Quando si installa Tivoli Netcool/OMNIbus,
vengono aggiunti i seguenti oggetti ObjectServer per supportare la funzionalità
SAE (Service Affected Event):
v Tabelle di database per l’utilizzo di applicazioni SAE: precision.entity_service,
precision.service_details, precision.service_affecting_events
v Il campo NmosEntityId per la tabella alerts.status
v Un gruppo di trigger sae e il trigger update_service_affecting_events
L’automazione del trigger update_service_affecting_events funziona solo con
Tivoli Netcool/OMNIbus V7 .0 o successive.
v Strumenti dell’elenco eventi per gestire SAE (Service Affected Event) su UNIX e
Windows
Dall’elenco eventi di Tivoli Netcool/OMNIbus, è possibile monitorare i SAE
(Service Affected Event) nel modo seguente:
v Per mostrare gli eventi sottostanti (ad esempio, linkDowns) associati ad un SAE
(Service Affected Event), selezionare il SAE, fare clic con il tasto destro del
mouse e selezionare Show SAE Related Events dal menu pop-up. Tutti gli
eventi associati all’evento selezionato vengono visualizzati in una nuova finestra.
v Per mostrare i SAE (Service Affected Event) a cui è correlato un evento (ad
esempio, linkDown), selezionare l’evento, fare clic con il tasto destro del mouse e
selezionare Show SAE Related Services dal menu pop-up. Un elenco di tutti i
SAE (Service Affected Event) correlati viene visualizzato in una nuova finestra.
Se, ad esempio, è stato selezionato un evento linkDown nell’elenco eventi,
questa finestra visualizza tutti i servizi interessati da tale evento linkDown.
226
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Esempi di automazione
Questa sezione contiene esempi di alcune automazioni comunemente eseguite.
Esempio: Trigger per deduplicare la tabella status
Questo trigger di database intercetta un tentativo di reinserimento nella tabella
alerts.status e incrementa il valore di tally per indicare la presenza di una nuova
riga di questo tipo nell’ObjectServer. Inoltre, imposta il campo LastOccurrence.
create or replace trigger deduplication
group default_triggers
priority 1
comment 'Deduplication processing for ALERTS.STATUS'
before reinsert on alerts.status
for each row
begin
set old.Tally = old.Tally + 1;
set old.LastOccurrence = new.LastOccurrence;
set old.StateChange = getdate();
set old.InternalLast = getdate();
set old.Summary = new.Summary;
set old.AlertKey = new.AlertKey;
if ((old.Severity = 0) and (new.Severity > 0))
then set old.Severity = new.Severity;
end if;
end;
Esempio: Trigger per deduplicare la tabella details
Questo trigger di database intercetta un tentativo di reinserimento nella tabella
alerts.details.
create or replace trigger
deduplicate_details
group default_triggers
priority 1
comment 'Deduplicate rows on alerts.details'
before reinsert on alerts.details
for each row
begin
cancel; -- Do nothing. Allow the row to be discarded
end;
Esempio: Trigger per eliminare il contenuto della tabella details
Questo trigger temporale elimina, periodicamente, tutte le voci relative ai dettagli
nella tabella alerts.details quando nella tabella alerts.status non vi è alcuna voce
corrispondente.
create or replace trigger
clean_details_table
group default_triggers
priority 1
comment 'Housekeeping cleanup of ALERTS.DETAILS' every 60 seconds
begin
delete from alerts.details
where Identifier not in (select Identifier from alerts.status);
end;
Capitolo 4. SQL ObjectServer
227
Esempio: Trigger per impostare la colonna StateChange della
tabella alerts.status
Quando si modifica una riga nella tabella alerts.status, questo trigger di database
aggiorna la colonna StateChange con le informazioni relative alla data e all’ora in
cui ha avuto luogo la modifica.
create or replace trigger state_change
group default_triggers
priority 1
comment 'State change processing for ALERTS.STATUS'
before update on alerts.status
for each row
begin
set new.StateChange = getdate;
end;
Esempio: Trigger per eliminare righe con stato chiaro
Questo trigger temporale elimina tutte le righe con stato chiaro (Severity = 0)
dalla tabella alerts.status che non sono state modificate negli ultimi due minuti.
create or replace trigger delete_clears
group default_triggers
priority 1
comment 'Delete cleared alerts over 2 minutes old every 60 seconds'
every 60 seconds
begin
delete from alerts.status where Severity = 0 and StateChange < (getdate() - 120);
end;
Esempio: Trigger per inviare notifiche e-mail per avvisi critici
Questo trigger temporale invia e-mail, richiamando una procedura esterna, nel
caso in cui un avviso critico non venga riconosciuto entro 30 minuti.
create or replace trigger mail_on_critical
group default_triggers
enabled false
priority 1
comment 'Send email about critical alerts that are
unacknowledged after 30 minutes. NOTE This tool is
UNIX specific unless an equivalent NT mailer is available.'
every 10 seconds
begin
for each row critical in alerts.status where critical.Severity = 5 and
critical.Grade < 2 and critical.Acknowledged = 0 and
critical.LastOccurrence <= ( getdate() - (60*30) )
begin
execute send_email( critical.Node, critical.Severity, 'Netcool Email',
'root@localhost', critical.Summary, 'localhost');
update alerts.status via critical.Identifier set Grade=2;
end;
end;
La procedura esterna send_email viene dichiarata come mostrato di seguito e
richiama il programma di utilità nco_mail:
create or replace procedure send_email
(in node character(255), in severity integer, in subject character(255),
in email character(255), in summary character(255), in hostname character(255))
executable '$NCHOME/omnibus/utils/nco_mail' host 'hostname' user 0 group 0
arguments '\'' + node + '\'', severity, '\'' + subject + '\'',
'\'' + email + '\'', '\'' + summary + '\'';
Inoltre, questo esempio mostra come trasmettere stringhe di testo a un eseguibile.
Le stringhe devono essere racchiuse tra virgolette di cui è necessario eseguire
l’escape inserendo barre retroverse. Tutte le virgolette contenute in questo esempio
sono virgolette singole.
228
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Esempio: Procedura per inserire una voce di journal per trigger
La procedura jinsert consente di inserire righe nella tabella alerts.journal.
Automazioni che richiedono l’inserimento di voci nel journal richiamano la
procedura e trasmettono il numero seriale della riga, l’ID utente dell’utente che
apporta la modifica (se applicabile), l’ora in cui l’azione ha avuto luogo e una
eventuale descrizione relativa all’azione da inserire nel journal.
create or replace trigger
trigger_name
group default_triggers
priority 10
before delete on alerts.status
for each row
begin
execute jinsert( old.Serial, %user.user_id, getdate(), 'string');
end;
In questa automazione, trigger_name è una variabile che rappresenta il nome del
trigger, mentre string è il testo della voce di journal.
Capitolo 4. SQL ObjectServer
229
230
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Capitolo 5. Configurazione della notifica eventi accelerati
È possibile configurare Tivoli Netcool/OMNIbus per la notifica eventi accelerati
per eventi che potrebbero presentare un rischio per il sistema. Il sistema AEN
(Accelerated Event Notification) consente di accelerare gli eventi con priorità alta
in modo che l’esecuzione dei sistemi possa continuare senza interruzione.
Quando si configura la notifica eventi accelerati, adottare le seguenti linee guida:
v Determinare le condizioni in cui si desidera accelerare gli eventi. Valutare se
utilizzare file delle regole di probe per contrassegnare eventi per l’accelerazione
o se configurare condizioni in un trigger di post-inserimento, di
post-aggiornamento o di post-reinserimento nell’ObjectServer.
Se le condizioni in cui accelerare gli eventi vengono configurate nei file delle
regole e sono complesse, potrebbe essere necessario configurare la tabella
alerts.status con una colonna dedicata per la ricezione di un indicatore che
identifichi un evento come evento accelerato.
Di solito, è possibile eseguire un trigger di post-inserimento su eventi inseriti per
determinare se soddisfano le condizioni per l’accelerazione, oppure è possibile
eseguire un trigger di post-aggiornamento su eventi aggiornati che sono stati
arricchiti con informazioni provenienti da altre origini o, ancora, è possibile
eseguire un trigger di post-reinserimento per effettuare l’escalation degli eventi
che si ripetono.
v Determinare se occorre un gateway dedicato per inoltrare eventi accelerati.
Prendere in considerazione l’uso di un gateway dedicato se si desidera eliminare
la possibilità di ritardi imprevisti causati da volumi elevati di eventi, che in
massima parte potrebbero essere non critici, oppure se si desidera inviare eventi
accelerati a un ObjectServer diverso da quello utilizzato per i normali
aggiornamenti IDUC. Se si utilizza un gateway dedicato, è necessario
configurarlo perché vengano replicati solo gli aggiornamenti e gli inserimenti
accelerati.
Inoltre, occorre utilizzare Netcool/OMNIbus Administrator per configurare la
notifica eventi accelerati, come mostrato di seguito:
v Configurare una colonna eventi dedicata per contrassegnare un evento per
l’accelerazione, se necessario.
v Configurare canali per definire il tipo di dati evento da includere nelle notifiche
eventi accelerati e i destinatari di questi dati evento.
v Configurare trigger di post-inserimento, di post-aggiornamento o di
post-reinserimento per agire sugli eventi accelerati che vengono inseriti o
aggiornati nella tabella alerts.status.
Per informazioni sul monitoraggio e sulla gestione di eventi accelerati, consultare
IBM Tivoli Netcool/OMNIbus User’s Guide.
© Copyright IBM Corp. 1994, 2009
231
Configurazione di un probe per contrassegnare eventi per
l’accelerazione
Se le condizioni per la notifica eventi accelerati sono complesse, determinare se
configurare o no le condizioni nel file delle regole di probe.
Potrebbe anche essere necessario aggiungere alla tabella alerts.status una colonna
di eventi dedicata per contrassegnare eventi per l’accelerazione e utilizzare questo
campo nel file delle regole di probe.
Il file delle regole di probe di esempio riportato di seguito descrive in che modo
un flusso di eventi può essere analizzato allo scopo di determinare quali eventi
vengono considerati con alta priorità. Nella parte superiore del file delle regole, gli
elementi (indicati dal simbolo $) sono assegnati ai campi ObjectServer (indicati dal
simbolo @). L’istruzione condizionale utilizza l’elemento $Summary per impostare
i valori AlertKey e FastTrack nella tabella alerts.status.
L’istruzione si traduce nel modo seguente: se il valore di ″Summary″ inizia con
’Port failure’, inserire il valore del numero della porta nel campo AlertKey nella
tabella alerts.status e inserire un valore 1 nel campo FastTrack nella tabella
alerts.status. In caso contrario, se il valore di ″Summary″ inizia con la stringa
’Diskspace’, inserire nel campo AlertKey della tabella alerts.status la stringa
completa ottenuta concatenando il numero e il simbolo di percentuale (%).
@Manager = "Simnet Probe"
@Class = 3300
@Node
= $Node
@Agent
= $Agent
@AlertGroup = $Group
@Summary = $Summary
@Severity = $Severity
@Identifier = $Node + $Agent + $Severity + $Group
if (nmatch($Summary, "Port failure"))
{
@AlertKey = $PortNumber
@FastTrack = 1
}
else if (nmatch($Summary, "Diskspace"))
{
@AlertKey = $PercentFull + "% full"
}
Configurazione di un gateway per la notifica eventi accelerati
È possibile scegliere di utilizzare un gateway dedicato per inoltrare eventi
accelerati per motivi di prestazioni oppure per inviare eventi a un determinato
ObjectServer. Se si utilizza un gateway dedicato, è necessario aggiornare la relativa
definizione di replica delle tabelle in modo che solo gli inserimenti e gli
aggiornamenti accelerati vengano riportati nella replica.
Per configurare un gateway ObjectServer unidirezionale per la notifica eventi
accelerati:
1. Aprire il seguente file di definizione della replica della tabella dei gateway:
$OMNIHOME/gates/objserv_uni/objserv_uni.reader.tblrep.def
2. Trovare le seguenti righe:
232
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
REPLICATE ALL FROM TABLE 'alerts.status' USING MAP 'StatusMap';
REPLICATE ALL FROM TABLE 'alerts.journal' USING MAP 'JournalMap';
REPLICATE ALL FROM TABLE 'alerts.details' USING MAP 'DetailsMap';
3. Sostituire queste tre righe con la seguente riga:
REPLICATE FT_INSERT,FT_UPDATE FROM TABLE 'alerts.status' USING MAP 'StatusMap';
4. Salvare il file.
Operazioni successive
Per un gateway bidirezionale, è necessario modificare i file corrispondenti in
maniera simile. Il file della definizione della replica della tabella dei gateway per
un gateway bidirezionale è $OMNIHOME/gates/objserv_bi/
objserv_bi.reader.tblrep.def.
Configurazione della tabella alerts.status per la ricezione
dell’indicatore per la notifica eventi accelerati
Se le regole di probe sono state configurate con un indicatore per la notifica eventi
accelerati, potrebbe essere necessario aggiungere alla tabella alerts.status una
colonna per supportare l’accelerazione degli eventi.
Ad esempio, da Netcool/OMNIbus Administrator, aggiungere una colonna con un
nome colonna FastTrack e un tipo di dati Integer.
Attività correlate
“Aggiunta e modifica di colonne di tabella” a pagina 114
Riferimenti correlati
“Modifica di una tabella” a pagina 136
Configurazione di canali per trasmettere dati evento
Quando si configura la notifica eventi accelerati, è necessario utilizzare canali per
definire il tipo di dati evento da trasmettere nelle notifiche eventi accelerati,
nonché i destinatari di questi dati. È possibile configurare più canali con diversi
dati evento e destinatari.
L’amministrazione dei canali è consentita solo agli utenti con ruolo ChannelAdmin.
I dati evento per i canali vengono ricavati dalle colonne delle tabelle presenti
nell’ObjectServer.
Suggerimento: Le colonne che si scelgono per un canale dovrebbero contenere una
quantità di dati di riepilogo sufficiente da consentire agli operatori di interpretare
agevolmente problemi critici, quando tali problemi vengono segnalati sullo
schermo come programmi di notifica pop up. Gli operatori possono quindi fare clic
nell’elenco eventi del desktop oppure su Elenco eventi attivi di Web GUI per
ottenere dettagli completi relativi all’evento e per gestirlo.
Questa funzionalità del programma di notifica pop up che permette di fare clic
nell’elenco eventi o su Elenco eventi attivi è disponibile solo per gli eventi presenti
nella tabella alerts.status.
Capitolo 5. Configurazione della notifica eventi accelerati
233
Creazione e modifica di canali
È necessario creare canali su un ObjectServer da cui verranno inoltrati gli eventi
accelerati.
Prima di iniziare
È necessario essere connessi all’ObjectServer sul quale si desidera creare un canale.
Per creare o modificare un canale:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic su Channels. Si apre il riquadro Channels.
3. Per aggiungere un canale, fare clic su Add Channel nella barra degli strumenti.
Si apre la finestra Channel Details.
4. Per modificare un canale, selezionare il canale da modificare, quindi fare clic su
Edit Channel nella barra degli strumenti. Si apre la finestra Channel Details.
5. Definire il canale nel modo seguente:
Name Immettere un nome univoco per il canale. Se si sta modificando un
canale, è impossibile modificarne il nome.
Description
Immettere il testo valido che riepiloga la funzione del canale.
6. Dalla scheda Columns, specificare quali colonne si desidera includere nella
definizione del canale. Completare la scheda nel modo seguente:
Add new Channel Columns
Fare clic su questo pulsante per aggiungere colonne al canale. Si apre la
finestra Channel Column Details. Completare questa finestra nel modo
seguente e salvare quindi le modifiche:
Table
Dall’elenco a sinistra, selezionare un database ObjectServer.
Dall’elenco a destra, selezionare una tabella in questo database.
Se si stanno modificando le colonne del canale, non è possibile
modificare il database o il nome tabella.
Limitazione: Attualmente, il supporto è disponibile solo per gli
eventi della tabella alerts.status.
Columns: Available
Questo elenco è popolato di nomi di colonne definite nella
tabella database selezionata e che è possibile assegnare al
canale. Per assegnare una o più di queste colonne, utilizzare i
pulsanti freccia per spostare le colonne nell’elenco Selected.
Per spostare tutte le colonne nell’elenco Selected, fare clic su
>>. Per spostare una singola colonna o più colonne nell’elenco
Selected, selezionare ciascuna colonna e quindi fare clic su >. È
possibile utilizzare il tasto MAIUSC per selezioni consecutive
oppure il tasto CTRL per selezioni non consecutive.
È possibile anche fare doppio clic su una colonna per spostarla
dall’elenco Available all’elenco Selected. Le colonne vengono
aggiunte alla fine dell’elenco Selected.
Columns: Selected
Questo elenco contiene le colonne che sono incluse nella
234
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
definizione del canale. Per spostare le colonne dalla definizione
del canale, utilizzare i pulsanti freccia per spostare le colone
nell’elenco Available.
Per spostare tutte le colonne nell’elenco Available, fare clic su
<<. Per spostare una singola colonna o più colonne nell’elenco
Available, selezionare ciascuna colonna e quindi fare clic su <.
È possibile utilizzare il tasto MAIUSC per selezioni consecutive
oppure il tasto CTRL per selezioni non consecutive.
È possibile anche fare doppio clic su una colonna per spostarla
dall’elenco Selected all’elenco Available.
Utilizzare i pulsanti freccia a destra dell’elenco Selected per
specificare la posizione dei dati all’interno del programma di
notifica a comparsa nel client AEN (Accelerated Event
Notification). L’elenco Selected visualizza i seguenti
contrassegni predefiniti per indicare la posizione dei dati di
colonna:
v H: Heading
v F: First Line
v S: Second Line
v M: Main Message
v N: Note
Per modificare la posizione di una colonna, selezionarla e
quindi fare clic sul pulsante freccia pertinente. Utilizzare i
pulsanti freccia nel modo seguente:
Tabella 71. Pulsanti freccia
Pulsante
Descrizione
Sposta la colonna selezionata all’inizio
dell’elenco Selected.
Sposta la colonna selezionata di una
posizione più in alto nell’elenco Selected.
Sposta la colonna selezionata di una
posizione più in basso nell’elenco Selected.
Sposta la colonna selezionata alla fine
dell’elenco Selected.
Quando si ritorna alla scheda Columns nella finestra Channel Details,
le selezioni di colonna vengono mostrate con una singola riga (non è
possibile aggiungere più di una riga).
Edit selected Channel Columns
Fare clic su questo pulsante per modificare la definizione di colonna
per il canale. Selezionare la riga nella scheda Columns e poi fare clic
sul pulsante. Si apre la finestra Channel Column Details. Modificare le
selezioni della colonna in questa finestra e quindi salvare le modifiche
per ritornare alla scheda Columns.
Delete selected Channel Columns
Utilizzare questo pulsante per eliminare una definizione di colonna per
il canale. Selezionare la riga nella tabella Columns e poi fare clic su
Delete. Quando richiesto, confermare l’eliminazione. Le modifiche
vengono riportate nella scheda Columns.
Capitolo 5. Configurazione della notifica eventi accelerati
235
7. Dalla scheda Recipients, specificare l’utente o il gruppo di utenti a cui inviare i
dati relativi al canale. Completare la scheda nel modo seguente:
Add new Channel Recipient
Fare clic su questo pulsante per specificare i destinatari delle
informazioni del canale. Si apre la finestra Channel Recipient Details.
Completare questa finestra nel modo seguente e salvare quindi le
modifiche:
isGroup
Selezionare questa casella di spunta per indicare che i
destinatari del canale sono un gruppo di utenti. Deselezionare
questa casella di spunta se il destinatario del canale è un
singolo utente.
Nome Questo elenco opera unitamente alla casella di spunta isGroup
e viene popolato con un elenco di tutti gli utenti o con un
elenco di tutti i gruppi nell’ObjectServer. Selezionare il nome
dell’utente o del gruppo che deve ricevere i dati canale.
Hostname
Immettere il nome dell’host connesso. È possibile utilizzare le
espressioni regolari per il filtro delle connessioni che
corrispondono a questo valore. Lasciare il campo vuoto per una
trovare la corrispondenza per qualsiasi nome host. Ad esempio,
immettere l’espressione regolare *test* per trovare la
corrispondenza con qualsiasi host il cui nome contenga la
stringa test.
Application Name
Immettere il nome di un’applicazione connessa all’ObjectServer.
È possibile utilizzare le espressioni regolari per il filtro delle
connessioni che corrispondono alla voce. Ad esempio,
immettere l’espressione regolare *event* per trovare la
corrispondenza con qualsiasi host il cui nome contenga la
stringa event. Lasciare il campo vuoto per trovare la
corrispondenza per qualsiasi nome applicazione.
Application Description
Immettere la descrizione dell’applicazione. È possibile utilizzare
le espressioni regolari per il filtro delle connessioni che
corrispondono alla voce. Ad esempio, *real time* corrisponde
a qualsiasi hosy che contenga la stringa real time nella
descrizione dell’applicazione. Lasciare il campo vuoto per
trovare la corrispondenza per qualsiasi descrizione
applicazione.
Quando si ritorna alla scheda Receipients nella finestra Channel
Details, le selezioni di colonna vengono visualizzate con una singola
riga. È possibile aggiungere ulteriori righe di destinatari.
Edit the selected Channel Recipient
Fare clic su questo pulsante per modificare i dettagli del destinatario
per tutte le righe selezionate nella scheda Recipients. Si apre la finestra
Channel Recipient Details. Modificare i dettagli del destinatario e
salvare le modifiche per ritornare alla scheda Recipients.
Delete the selected Channel Recipient
Utilizzare questo pulsante per rimuovere i destinatari dalla definizione
del canale. Selezionare la riga di destinatari che si desidera rimuovere e
236
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
quindi fare clic su questo pulsante. Quando richiesto, confermare
l’eliminazione. Le modifiche vengono riportate nella scheda Recipients.
8. Salvare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per salvare i dettagli del canale e chiudere
la finestra. I nuovi canali vengono aggiunti al pannello Channels.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Operazioni di copia e incolla sui canali
È possibile utilizzare un canale come modello per crearne un altro copiando e
incollando la definizione del canale. Questo approccio è utile se si desidera creare
canali con leggere variazioni nella loro definizione.
Limitazione: Non è possibile eseguire l’operazione di copia e incolla tra un
ObjectServer e l’altro.
Per copiare e incollare un canale:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic su Channels. Si apre il riquadro Channels.
3. Per copiare un canale, selezionare il canale dal riquadro Channels, quindi fare
clic su Copy nella barra degli strumenti.
4. Per incollare il canale, fare clic su Paste nella barra degli strumenti. Si apre la
finestra New Channel.
5. Immettere un nome univoco per il canale.
6. Confermare o annullare le azioni nel modo seguente:
v Fare clic su OK per creare il nuovo canale con una definizione di canale
identica a quella del canale selezionato. Si apre, quindi, la finestra Channel
Details, in cui è possibile apportare le modifiche necessarie a questo nuovo
canale.
v Fare clic su Cancel per annullare l’azione copia-e-incolla.
Eliminazione di un canale
Per eliminare un canale:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic sull’icona Channels. Si apre la finestra Channels.
3. Selezionare il canale che si desidera eliminare e fare clic su Delete nella barra
degli strumenti. Il canale viene eliminato.
Capitolo 5. Configurazione della notifica eventi accelerati
237
Invio di messaggi ai destinatari dei canali
È possibile inviare messaggi ai destinatari dei canali che eseguono attualmente il
client AEN (Accelerated Event Notification).
È possibile inviare messaggi a destinatari in ascolto su uno o più canali.
Per inviare messaggi:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic su Channels. Si apre il riquadro Channels.
3. Dal riquadro Channels, selezionare uno o più canali che sono associati al
messaggio da inviare. È possibile utilizzare il tasto Maiusc per selezioni
consecutive o il tasto Ctrl per selezioni non consecutive.
4. Dalla barra degli strumenti, fare clic su Send Message. Si apre la finestra Send
Message.
5. Immettere un messaggio di testo nel campo Message Text. Questo campo
scorre orizzontalmente per consentire l’immissione di testo.
6. Confermare o annullare le azioni nel modo seguente:
v Fare clic su OK per iniziare l’azione di invio, quindi confermare che si
desidera inviare il messaggio facendo clic su Yes.
Nota: Se il campo Message Text è vuoto, non verrà inviato alcun messaggio.
v Fare clic su Cancel per annullare l’azione di invio.
Risultati
Il messaggio verrà visualizzato in una finestra dei messaggi su tutti i client AEN
(Accelerated Event Notification) coinvolti. Il testo del messaggio va a capo dopo
120 caratteri. Se si invia il messaggio a più canali, un client in ascolto su più di
uno tra questi canali, riceverà il messaggio una volta sola.
Disconnessione dei client AEN (Accelerated Event
Notification)
Se occorre eseguire attività di gestione secondarie sull’ObjectServer, ad esempio la
risincronizzazione, è possibile disconnettere in remoto (o chiudere il collegamento)
i client AEN (Accelerated Event Notification) attualmente in esecuzione. Come
parte dell’azione di disconnessione, è possibile immettere un breve messaggio per
gli utenti in cui si spiega il motivo della disconnessione.
Per disconnettere client AEN (Accelerated Event Notification) che sono in ascolto
su uno o più canali:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic su Channels. Si apre il riquadro Channels.
3. Dal riquadro Channels, selezionare uno o più canali che sono associati
all’azione di disconnessione. È possibile utilizzare il tasto Maiusc per selezioni
consecutive o il tasto Ctrl per selezioni non consecutive.
4. Dalla barra degli strumenti, fare clic su Disconnect Clients. Si apre la finestra
Send Disconnect Command.
5. Immettere un messaggio di testo nel campo Reason for Disconnect. Questo
campo scorre orizzontalmente per consentire l’immissione di testo.
238
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
6. Confermare o annullare le azioni nel modo seguente:
v Fare clic su OK per iniziare l’azione di disconnessione, quindi confermare
che si desidera disconnettersi facendo clic su Yes.
Nota: Se il campo Reason for Disconnect è vuoto, i client verranno
disconnessi, ma nella finestra dei messaggi non verrà fornito il motivo della
disconnessione.
v Fare clic su Cancel per annullare l’azione di disconnessione.
Risultati
Dopo aver confermato l’azione di disconnessione, qualsiasi messaggio immesso
verrà visualizzato in una finestra dei messaggi su tutti i client AEN (Accelerated
Event Notification) coinvolti nella disconnessione. Il testo del messaggio va a capo
dopo 120 caratteri. Successivamente, ha luogo una disconnessione automatica.
L’indicatore di stato per i client AEN (Accelerated Event Notification) segnala lo
stato disconnesso anche se l’esecuzione continua in background.
Arresto dei client AEN (Accelerated Event Notification)
Se occorre arrestare l’ObjectServer, è possibile arrestare in remoto i client AEN
(Accelerated Event Notification) che sono in esecuzione. Come parte dell’azione di
arresto, è possibile immettere un breve messaggio per gli utenti in cui si spiega il
motivo dell’arresto.
Per arrestare i client AEN (Accelerated Event Notification) che sono in ascolto su
uno o più canali:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System.
2. Fare clic su Channels. Si apre il riquadro Channels.
3. Dal riquadro Channels, selezionare uno o più canali associati all’azione di
arresto. È possibile utilizzare il tasto Maiusc per selezioni consecutive o il tasto
Ctrl per selezioni non consecutive.
4. Dalla barra degli strumenti, fare clic su Shutdown Clients. Si apre la finestra
Send Shutdown Command.
5. Immettere un messaggio di testo nel campo Reason for Shutdown. Questo
campo scorre orizzontalmente per consentire l’immissione di testo.
6. Confermare o annullare le azioni nel modo seguente:
v Fare clic su OK per iniziare l’azione di arresto, quindi confermare che si
desidera eseguire l’arresto facendo clic su Yes.
Nota: Se il campo Reason for Shutdown resta vuoto, i client verranno
arrestati, ma nella finestra dei messaggi non verrà fornito il motivo.
v Fare clic su Cancel per annullare l’azione di arresto.
Risultati
Dopo aver confermato l’azione di arresto, qualsiasi messaggio immesso viene
visualizzato in una finestra di messaggi su tutti i client AEN (Accelerated Event
Notification) coinvolti nell’arresto. Il testo del messaggio va a capo dopo 120
caratteri. Dopo cinque secondi, ha luogo la disconnessione.
Capitolo 5. Configurazione della notifica eventi accelerati
239
Configurazione di trigger per supportare la notifica eventi accelerati
Per supportare la notifica eventi accelerati, creare trigger di post-inserimento,
post-aggiornamento o post-reinserimento da associare alla tabella alerts.status. Nei
trigger, configurare delle condizioni per definire o identificare gli eventi accelerati
quando tali eventi vengono inseriti o aggiornati nella tabella alerts.status e per
inoltrarli ai client AEN (Accelerated Event Notification) rilevanti.
Sono disponibili due comandi SQL da utilizzare con i trigger: un comando di
traccia rapida dell’evento (o evento accelerato) (IDUC EVTFT) e un comando di
invio messaggio (IDUC SNDMSG).
Suggerimento: Potrebbe essere utile raggruppare i trigger che supportano la
notifica eventi accelerati all’interno del relativo gruppo trigger.
Concetti correlati
“Configurazione dell’automazione utilizzando trigger” a pagina 195
“Configurazione dei trigger” a pagina 85
Riferimenti correlati
“Attivazione della notifica eventi accelerati (comando IDUC EVTFT)” a pagina 218
“Invio di messaggi a client AEN (Accelerated Event Notification) (comando IDUC
SNDMSG)” a pagina 219
240
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Capitolo 6. Utilizzo del controllo processi per gestire processi
e procedure esterne
Il sistema per il controllo processi di Tivoli Netcool/OMNIbus esegue due attività
principali. Gestisce processi locali e remoti ed esegue procedure esterne che
vengono specificate nelle automazioni.
È possibile utilizzare il controllo processi per semplificare la gestione dei
componenti di Tivoli Netcool/OMNIbus, ad esempio ObjectServer, probe e
gateway. È possibile installare agent del processo su ciascun host e configurarli per
la gestione dei processi. Gli agent del processo configurati cooperano in maniera
automatica e riconoscono le rispettive configurazioni. Essi avviano processi e
possono tenerli in esecuzione. È possibile definire processi che dipendono da altri
processi e processi che dipendono da una soglia di tempo. Se un host gestito viene
riavviato, l’agent del processo può essere configurato per riavviare i componenti
locali in maniera automatica.
Il sistema per il controllo processi include una serie di programmi di utilità della
riga comandi che forniscono un’interfaccia per la gestione dei processi. È possibile
configurare e gestire il controllo processi dalla riga comandi oppure utilizzando
Netcool/OMNIbus Administrator.
Come si collegano gli agent del processo
È possibile impostare un sistema di rete per il controllo processi configurando il
controllo processi su numerosi host Tivoli Netcool/OMNIbus.
Gli agent del processo possono quindi comunicare tra loro ed eseguire programmi
su richiesta. Gli agent del processo in esecuzione sui sistemi operativi Windows
possono comunicare con agent del processo in esecuzione sui sistemi operativi
UNIX e viceversa.
Esecuzione di agent del processo in una configurazione di
instradamento
Quando numerosi agent del processo sono collegati mediante istruzioni di
instradamento, è possibile fare in modo che ciascun agent del processo presente nel
sistema di rete per il controllo processi riconosca i processi negli altri agent del
processo. Un file di configurazione dell’agent del processo viene utilizzato per
definire processi, servizi e host nella rete del controllo processi e per definire
istruzioni di instradamento.
Il sistema per il controllo processi supporta la gestione remota completa degli
agent del processo da una singola console. È possibile aggiungere, modificare,
eliminare, avviare e arrestare servizi e processi in remoto. È anche possibile
visualizzare lo stato sia dei processi locali che di quelli remoti. Se si utilizza
Netcool/OMNIbus Administrator per gestire il controllo processi, è possibile
salvare le modifiche ai file di configurazione degli agent del processo.
© Copyright IBM Corp. 1994, 2009
241
Gli agent del processo supportano l’aggiunta dinamica di istruzioni di
instradamento da Netcool/OMNIbus Administrator. È anche possibile aggiungere
un nuovo agent del processo a un gruppo di instradamento come descritto di
seguito:
1. Copiare e modificare la configurazione corrente da un agent del processo
esistente per avere visibilità dei processi correnti.
2. Aggiornare i file di configurazione per ciascuno degli altri agent del processo
aggiungendo nuove voci di instradamento all’area di definizione di
instradamento nei file.
3. Arrestare ciascuno degli agent del processo esistenti e relativi processi child
eseguendo il programma di utilità nco_pa_shutdown con l’impostazione
-option STOP. Riavviare, quindi, i singoli agent del processo per acquisire il
nuovo instradamento.
Nota: I nomi dei servizi e dei processi devono essere univoci nella rete del
controllo processi.
Attività correlate
“Creazione e avvio di un sistema di rete per il controllo processi” a pagina 244
“Definizione di processi, servizi e host per il controllo processi” a pagina 256
“Visualizzazione e configurazione delle informazioni relative allo stato per un
agent del processo” a pagina 277
Riferimenti correlati
“Visualizzazione dello stato di servizi e processi (nco_pa_status)” a pagina 267
“Aggiunta di un nuovo servizio o processo (nco_pa_addentry)” a pagina 271
Componenti del controllo processi
Il sistema per il controllo processi è disponibile come funzione installabile durante
l’installazione di Tivoli Netcool/OMNIbus e include numerosi componenti
standard e configurabili.
Il
v
v
v
controllo processi consiste di:
Agent del processo e file di configurazione associati
Processi
Servizi, in cui vengono organizzati ed eseguiti i processi
v Programmi di utilità, i quali agevolano la gestione degli agent del processo, dei
processi e dei servizi
Agent del processo
Gli agent del processo sono programmi che vengono installati su ciascun host per
gestire processi in un sistema per il controllo processi. Su ogni host partecipante
deve essere installato un agent del processo e un file di configurazione associato.
È possibile avere un numero qualsiasi di agent del processo su un numero
qualsiasi di host. Gli agent del processo possono gestire un numero qualsiasi di
processi.
242
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Processi
I processi sono programmi che vengono eseguiti da un agent del processo sulla
stessa workstation, all’interno di un sistema per il controllo processi. Per una
gestione agevole, i processi devono essere definiti in un servizio.
Riconoscimento del controllo processi
Un processo con riconoscimento PA è un processo che fa parte della configurazione
del controllo processi e che riconosce il controllo processi. Tutte le funzioni del
controllo processi, ad esempio le dipendenze dei processi, possono essere
utilizzate. Ad esempio, gli ObjectServer, i server proxy e i gateway ObjectServer
riconoscono PA. Un processo senza riconoscimento PA può essere gestito dal
controllo processi, ma non può utilizzare tutte le funzioni del controllo processi.
Ad esempio il desktop di Tivoli Netcool/OMNIbus non riconosce PA.
Processi dipendenti
L’ordine in cui le applicazioni vengono avviate può essere importante. È possibile
utilizzare il controllo processi per configurare i processi in modo che dipendano
l’uno dall’altro se si trovano nello stesso servizio. Ad esempio, un processo può essere
configurato perché venga avviato solo dopo che un altro processo ha avviato e
completato le varie attività di avvio.
Un processo con riconoscimento PA comunica con l’agent del processo. Quando il
processo raggiunge il punto nell’avvio in cui riconosce di essere in esecuzione,
invia un messaggio all’agent del processo. Quando l’agent del processo riceve
questo messaggio, avvia i processi dipendenti.
Attività correlate
“Definizione di processi, servizi e host per il controllo processi” a pagina 256
Servizi
In un sistema per il controllo processi, i processi devono essere raggruppati
insieme in servizi. È possibile raggruppare processi correlati in un servizio per
agevolarne la gestione.
Dopo aver configurato correttamente un servizio, esso può essere gestito dal
controllo processi.
È possibile configurare un servizio perché venga avviato automaticamente all’avvio
dell’agent del processo. In alternativa, è possibile avviare un servizio
manualmente.
Un servizio può essere configurato come servizio principale da cui dipendono altri
servizi, o come servizio non principale. Se avviati automaticamente dal controllo
processi, i servizi principali vengono avviati prima di quelli non principali.
Attività correlate
“Definizione di processi, servizi e host per il controllo processi” a pagina 256
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
243
Programmi di utilità del controllo processi
Sono disponibili programmi di utilità della riga comandi che agevolano la gestione
degli agent del processo, dei processi e dei servizi in un sistema per il controllo
processi.
La seguente tabella elenca questi programmi di utilità della riga comandi.
Tabella 72. Programmi di utilità della riga comandi per il controllo processi
Programma di utilità
Descrizione
nco_pa_status
Questo programma di utilità richiama e visualizza lo
stato dei servizi e dei processi controllati dall’agent
del processo.
nco_pa_start
Questo programma di utilità avvia un servizio o un
processo che si trova in un punto qualsiasi della
configurazione.
nco_pa_stop
Questo programma di utilità arresta un servizio o un
processo che si trova in un punto qualsiasi della
configurazione.
nco_pa_shutdown
Questo programma di utilità arresta un agent del
processo.
nco_pa_addentry
Questo programma di utilità aggiunge una voce
servizio o processo quando è in esecuzione un agent
del processo.
Riferimenti correlati
“Visualizzazione dello stato di servizi e processi (nco_pa_status)” a pagina 267
“Avvio di un servizio o di un processo (nco_pa_start)” a pagina 269
“Arresto di un servizio o di un processo (nco_pa_stop)” a pagina 269
“Arresto di un agent del processo (nco_pa_shutdown)” a pagina 270
“Aggiunta di un nuovo servizio o processo (nco_pa_addentry)” a pagina 271
Creazione e avvio di un sistema di rete per il controllo processi
Per gestire il controllo processi, è innanzitutto necessario determinare i requisiti di
configurazione del controllo processi, quindi eseguire numerose attività di
configurazione.
Di seguito viene fornito un riepilogo delle attività di configurazione:
1. Se si utilizza il meccanismo di autenticazione predefinito su UNIX, configurare
un gruppo di utenti dedicato da poter utilizzare per controllare l’accesso al
sistema per il controllo processi. Assegnare utenti a questo gruppo.
Su Windows, l’accesso al sistema per il controllo processi è gestito mediante la
disponibilità di un account utente di dominio o locale valido. Per connettersi a
un agent del processo, è anche possibile specificare un qualsiasi account
utilizzato per accedere al computer sul quale è in esecuzione un agent del
processo, purché l’utente disponga del privilegio Access this computer from
the network.
2. Per ciascun agent del processo, configurare le informazioni sulle comunicazioni
del server (ossia, nome host e numero di porta) sul computer host e su tutti i
computer che devono connettersi alla rete per il controllo processi. È necessario
configurare le informazioni sulle comunicazioni del server nell’editor del server
(oppure utilizzando nco_xigen) prima di avviare un agent del processo.
244
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
3. Aggiornare il file di configurazione dell’agent del processo predefinito per
ciascun agent del processo definendo processi, servizi e host.
Operazioni successive
Al termine della configurazione, avviare gli agent del processo. L’agent del
processo può essere avviato manualmente dalla riga comandi oppure
automaticamente all’avvio del sistema. Per avviare un agent del processo
automaticamente, è possibile utilizzare gli script di avvio su UNIX oppure
installare e configurare l’agent del processo da eseguire come servizio Windows. I
processi vengono eseguiti in maniera automatica come definito nel file di
configurazione per ciascun agent del processo e gli agent del processo comunicano
come indicato nella configurazione.
Attività correlate
“Configurazione e gestione del controllo processi dalla riga comandi” a pagina 256
Prima di configurare il controllo processi
Prima di configurare il controllo processi su uno o più computer host, verificare i
requisiti di configurazione del controllo processi.
Le attività prerequisite sono le seguenti:
v Accertarsi che la funzione controllo processi sia installata. Questa funzione viene
installata quando si seleziona Controllo processi come funzione installabile
durante l’installazione di Tivoli Netcool/OMNIbus. Inoltre, se si desidera gestire
il controllo processi da una GUI, è necessario che Netcool/OMNIbus
Administrator sia installato. Per ulteriori informazioni sull’installazione del
controllo processi e su Netcool/OMNIbus Administrator, consultare IBM Tivoli
Netcool/OMNIbus - Guida all’installazione e alla distribuzione.
v Stabilire quali sono i componenti di Tivoli Netcool/OMNIbus installati e dove si
trovano. Assicurarsi di non aver tralasciato nessun componente e sistema di
failover o di backup. I desktop di Tivoli Netcool/OMNIbus non vengono gestiti
dal controllo processi.
Creazione di gruppi di utenti UNIX per il sistema per il
controllo processi
Il daemon del controllo processi controlla chi può accedere al controllo processi. Su
UNIX, qualunque utente che necessiti dell’accesso al sistema per il controllo
processi deve essere membro di un gruppo di utenti UNIX che viene identificato
per questo scopo come gruppo amministrativo.
Per impostazione predefinita, il sistema per il controllo processi utilizza i nomi
utente e le password UNIX per concedere l’accesso. Quando si esegue il daemon
dell’agent del processo (nco_pad), è possibile specificare altre modalità di
autorizzazione supportate utilizzando l’opzione della riga comandi -authenticate.
È possibile utilizzare un gruppo di utenti UNIX esistente oppure crearne uno
nuovo e aggiungere a questo gruppo gli utenti del controllo processi. Se si esegue
NIS, NIS+ o un altro servizio informazioni globale, questa configurazione deve
essere eseguita dall’amministrazione del servizio in questione. Per informazioni sui
gruppi di utenti, consultare la documentazione fornita con il proprio sistema
operativo.
Quando si esegue il daemon del controllo processi, identificare il gruppo
amministrativo con l’opzione della riga comandi -admingroup. Se non si specifica
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
245
il nome di un gruppo, il controllo processi verifica se la persona che ha eseguito il
comando è membro del gruppo predefinito ncoadmin.
Attenzione: Se si utilizza il framework PAM (Pluggable Authentication Modules)
per l’autenticazione, non è necessario che gli utenti siano membri di un gruppo di
utenti UNIX, ad esempio ncoadmin, per ottenere l’accesso al sistema per il
controllo accessi. Con i client PAM, il sistema per il controllo processi non
convalida gli utenti sulla base di un gruppo di utenti UNIX, pertanto l’accesso non
è limitato.
Concetti correlati
“Servizi” a pagina 243
Riferimenti correlati
“Opzioni della riga comandi dell’agent del processo” a pagina 248
Requisiti degli account Windows per il sistema per il controllo
processi
Su Windows, l’agent del processo deve essere eseguito come l’account
Administrator sul computer locale.
Per connettersi all’agent del processo da Netcool/OMNIbus Administrator, un altro
agent del processo, l’ObjectServer o un programma di utilità per il controllo
processi, occorre uno dei seguenti tipi di account:
v Un account utente Windows locale
v Un account dominio Windows locale
v Un account nel formato UPN (User Principal Name); ossia
username@DNS_domain_name
Per connessioni peer-to-peer tra agent del processo, prestare attenzione all’uso
delle politiche password che bloccano gli account Windows dopo un numero
specifico di tentativi. Gli agent del processo tentano ripetutamente di accedere se
non riescono a connettersi; pertanto, l’uso di una password errata potrebbe causare
rapidamente il blocco degli account Windows.
Configurazione delle informazioni sulle comunicazioni del
server per gli agent del processo
È necessario utilizzare l’editor del server per assegnare un nome server univoco a
ciascun agent del processo e specificare altre informazioni per le comunicazioni e
rendere disponibili questi dettagli per ciascun computer host presente nel sistema
per il controllo processi. In tal modo, gli agent del processo presenti su tutti i
computer host possono comunicare tra loro.
Per configurare le informazioni sulle comunicazioni del server per gli agent del
processo, effettuare le seguenti azioni:
1. Avviare l’editor del server su un computer host e aggiungere una voce server
per ciascun agent del processo che si desidera includere nel sistema per il
controllo processi. Salvare queste informazioni.
Suggerimento: Il nome di un server deve essere composto da un massimo di
29 lettere maiuscole e non può iniziare con un numero intero. Secondo la
convenzione di denominazione è necessario accodare _PA al nome in modo che
sia possibile identificare facilmente il server come agent del processo nell’editor
del server. Ad esempio, se si sta configurando l’agent del processo su un host
246
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
che si chiama sfosys1, l’agent del processo può essere denominato
SFOSYS1_PA. Per impostazione predefinita, il primo agent del processo
installato in una configurazione viene denominato NCO_PA.
2. Su UNIX, generare un file delle interfacce che contiene le informazioni sulle
comunicazioni del server. Di solito, il file delle interfacce viene denominato
$NCHOME/etc/interfaces.arch, dove arch è il nome del sistema operativo UNIX.
In un ambiente Windows, configurare le comunicazioni del server su ciascun
computer Windows.
3. Su UNIX, distribuire il file delle interfacce aggiornate su tutte le workstation
host presenti nella configurazione.
Operazioni successive
Per ulteriori dettagli sulla configurazione di definizioni di server nell’editor del
server e sulla generazione di file delle interfacce, consultare IBM Tivoli
Netcool/OMNIbus - Guida all’installazione e alla distribuzione.
Aggiornamento del file di configurazione predefinito del
controllo processi
Per ciascun agent del processo viene installato un file di configurazione del
controllo processi. Questo file contiene definizioni per ciascun processo, servizio e
host presenti nella configurazione del sistema per il controllo processi.
Il file di configurazione del controllo processi nco_pa.conf si trova nella directory
$NCHOME/omnibus/etc.
Determinare quali processi eseguire sotto il controllo processi e identificare le
dipendenze dei processi. Modificare manualmente il file di configurazione del
controllo processi per configurare le definizioni del controllo processi:
v Creare definizioni dei servizi per raggruppare insieme processi correlati o
dipendenti. In tal modo, si stabilisce l’ordine in cui i processi vengono eseguiti.
v Creare definizioni di instradamento per specificare ciascun agent del processo e
il relativo computer host associato da includere nella configurazione.
Risultati
Quando l’agent del processo viene avviato, legge questo file per stabilire le
impostazioni di configurazione.
Attività correlate
“Definizione di processi, servizi e host per il controllo processi” a pagina 256
Avvio manuale degli agent del processo
È possibile avviare manualmente gli agent del processo dalla riga comandi.
Per avviare manualmente un agent del processo, immettere il seguente comando
dalla riga comandi dell’host:
$NCHOME/omnibus/bin/nco_pad -name process_agent
In questo comando, process_agent è il nome dell’agent del processo così come
definito nel file omni.dat (UNIX) o nel file sql.ini (Windows). È possibile
specificare con questo comando ulteriori opzioni della riga comandi.
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
247
Il daemon dell’agent del processo (nco_pad) viene eseguito relativamente
all’ubicazione $NCHOME/omnibus.
Nota: Una nuova istanza dell’agent del processo non può gestire i processi che
sono stati avviati da un’altra istanza e che sono ancora in esecuzione. Quando
l’agent del processo viene arrestato, quindi riavviato, non è a conoscenza
dell’esistenza di questi processi, pertanto ne avvia una nuova istanza. Le istanze
precedenti continuano ad essere eseguite.
Nota: Se si esegue il comando nco_pad su un computer che già contiene un agent
del processo installato come servizio Windows, qualsiasi comando specificato per il
servizio Windows viene unito alle opzioni della riga comandi per eseguire nco_pad
dal prompt dei comandi. In caso di conflitto tra le opzioni specificate per il
servizio e quelle immesse dal prompt dei comandi, queste ultime hanno la
precedenza. L’output sullo schermo visualizza le opzioni unite.
Opzioni della riga comandi dell’agent del processo
Quando si esegue l’agent del processo con il comando nco_pad, è possibile
specificare diverse opzioni della riga comandi per una ulteriore configurazione.
Le opzioni della riga comandi per il comando $NCHOME/omnibus/bin/nco_pad sono
descritte nella tabella riportata di seguito. Le opzioni della riga comandi specifiche
di UNIX e Linux, che non sono supportate su Windows, sono contrassegnate nella
tabella.
Tabella 73. Opzioni della riga comandi di nco_pad per il daemon dell’agent del processo
Opzione di riga comandi
UNIX
Linux
-admingroup string
-apicheck
248
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Descrizione
Specifica il nome del gruppo di utenti UNIX con
privilegi di amministratore. I membri di questo
gruppo possono accedere al sistema per il controllo
processi. Il nome predefinito del gruppo è ncoadmin.
Nota: L’opzione -admingroup può essere utilizzata
solo nella modalità di autenticazione UNIX.
Se specificata, la verifica dell’API Sybase è abilitata.
Tabella 73. Opzioni della riga comandi di nco_pad per il daemon dell’agent del
processo (Continua)
Opzione di riga comandi
Descrizione
-authenticate string
Specifica la modalità di autenticazione da utilizzare
per verificare le credenziali di un utente o di un
daemon dell’agent del processo remoto.
Nota: In modalità FIPS 140-2, è possibile specificare
per l’autenticazione solo l’opzione PAM.
Su UNIX, i valori sono:
v UNIX: questa è la modalità di autenticazione
predefinita, il che significa che viene utilizzata la
funzione Posix getpwnam o getspnam per
verificare le credenziali utente sulle piattaforme
UNIX. In base alla configurazione del sistema, le
password vengono verificate utilizzando il file
/etc/password, il file delle password shadow
/etc/shadow, NIS o NIS+.
v PAM: se si specifica PAM come modalità di
autenticazione, per verificare le credenziali utente
viene utilizzato il framework PAM (Pluggable
Authentication Modules). Il nome del servizio
utilizzato dal gateway quando viene inizializzata
l’interfaccia PAM è netcool. L’autenticazione PAM è
disponibile solo su piattaforme Linux, Solaris e
HP-UX 11.
v KERBEROS: se si specifica KERBEROS come
modalità di autenticazione, per verificare le
credenziali utente viene utilizzata l’autenticazione
Kerberos IV. Questa opzione è disponibile solo sui
sistemi Solaris sui quali è installato un server di
autenticazione Kerberos IV.
v HPTCB: se si specifica HPTCB come modalità di
autenticazione, viene utilizzato il sistema di
protezione password HP-UX. Disponibile solo su
sistemi affidabili (sicuri) HP.
Su Windows, l’agent del processo si autentica sulla
base di un account Windows. L’unico valore per
l’opzione -authenticate è WINDOWS, che è anche il
valore predefinito.
-configfile string
Utilizzare questo nome file, relativo al file di
configurazione $NCHOME/omnibus anziché il file
predefinito $NCHOME/omnibus/etc/nco_pa.conf.
-connections integer
Imposta il numero massimo di connessioni
disponibili per eseguire azioni esterne.
L’impostazione predefinita è 30.
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
249
Tabella 73. Opzioni della riga comandi di nco_pad per il daemon dell’agent del
processo (Continua)
Opzione di riga comandi
Descrizione
-cryptalgorithm string
Specifica l’algoritmo crittografico da utilizzare per
decodificare password che sono state codificate con il
programma di utilità nco_aes_crypt, quindi
memorizzate nel file di configurazione dell’agent del
processo. Impostare il valore string nel modo
seguente:
v In modalità FIPS 140–2, utilizzare AES_FIPS.
v In modalità non FIPS 140–2, è possibile utilizzare
AES_FIPS o AES. Utilizzare AES solo se occorre
garantire la compatibilità con password che sono
state codificate con gli strumenti forniti nelle
versioni precedenti a Tivoli Netcool/OMNIbus
V7.2.1.
Il valore che si specifica deve essere identico a quello
utilizzato quando è stato eseguito il comando
nco_aes_crypt con l’impostazione -c, per codificare le
password nella sezione definizione degli
instradamenti del file.
Utilizzare l’opzione della riga comandi
-cryptalgorithm insieme all’opzione -keyfile.
-debug integer
Abilita il debug. Il valore integer specifica la quantità
di informazioni di debug scritte nel log. I livelli
disponibili sono 1 (Debug), 2 (Information), 3
(Warning), 4 (Error) e 5 (Fatal). L’impostazione
predefinita è 3.
Al livello di debug 1, l’agent del processo registra
informazioni sui processi che sta per avviare. Queste
informazioni includono il percorso del programma, i
singoli argomenti della riga comandi e l’ID utente
effettivo del processo. Se applicabile, il log include
anche la directory di lavoro corrente e in aggiunta
per UNIX, l’ID gruppo effettivo e la umask (in ottale)
del processo.
Al livello di debug 2, il log contiene un messaggio
che riporta l’account utente con il quale è in
esecuzione l’agent del processo.
250
-DNS string
Specifica un valore per sovrascrivere il nome host
negli ambienti DNS. Deve essere uguale a quello
riportato nel file di configurazione.
-help
Visualizza informazioni della guida relative all’agent
del processo ed esce.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 73. Opzioni della riga comandi di nco_pad per il daemon dell’agent del
processo (Continua)
Opzione di riga comandi
Descrizione
-keyfile string
Specifica il percorso e il nome del file che contiene la
chiave da utilizzare per decodificare le password
codificate che sono memorizzate nel file di
configurazione dell’agent del processo.
Il file chiave che si specifica deve essere identico a
quello utilizzato quando è stato eseguito il
programma di utilità nco_aes_crypt con
l’impostazione -k, per codificare le password nella
sezione delle definizioni degli instradamenti del file.
Utilizzare l’opzione della riga comandi -keyfile
insieme all’opzione -cryptalgorithm per decodificare
le password.
Se specificata, quando il daemon dell’agent del
processo arresta un processo, invia anche un segnale
per arrestare qualsiasi processo nello stesso gruppo di
processi del sistema operativo.
UNIX
Linux
-killprocessgroup
-logfile string
Specifica un file di log alternativo. Su UNIX, il log
può essere reindirizzato a stderr ed a stdout. Su
Windows, il log viene sempre scritto in un file.
Il file di log predefinito è:
$NCHOME/omnibus/log/pa_name.log
Dove pa_name è il nome dell’agent del processo
specificato con l’opzione -name.
-logsize integer
Specifica la dimensione massima del file di log in KB.
L’impostazione predefinita è 1024 KB, mentre la
dimensione minima è 16 KB.
-msgpoolsize integer
Specifica il numero di messaggi disponibili per
l’agent del controllo processi.
-name string
Specifica il nome del server per questo agent del
processo. Se non viene specificata, il nome dell’agent
del processo predefinito è NCO_PA.
-newlog
Questa opzione è obsoleta.
L’agent del processo sovrascrive sempre il file di log
precedente.
-noautostart
Se specificata, l’agent del processo non avvia alcun
servizio automaticamente, anche se nel file
nco_pa.conf i servizi sono impostati per l’avvio
automatico.
-noconfig
Se specificata, l’agent del processo, non legge il file di
configurazione nco_pa.conf. In tal modo, il controllo
processi verrà avviato senza alcuna informazione di
configurazione.
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
251
Tabella 73. Opzioni della riga comandi di nco_pad per il daemon dell’agent del
processo (Continua)
Opzione di riga comandi
UNIX
Linux
Descrizione
Per impostazione predefinita, il controllo processi
passa in background per essere eseguito come
processo daemon. Quando si specifica -nodaemon, il
processo viene eseguito in primo piano.
-nodaemon
-password string
UNIX
Linux
-pidfile string
UNIX
Specifica la password utilizzata per accedere ad altri
agent del processo.
Specifica il percorso, relativo a $NCHOME/omnibus, del
file in cui è memorizzato il PID del daemon del
controllo processi. Ciascun daemon del controllo
processi deve avere un file PID. L’impostazione
predefinita è $NCHOME/omnibus/var/pa_name.pid, dove
pa_name rappresenta il nome dell’agent del processo.
Sempre che a tutti gli agent del processo vengano
assegnati nomi univoci, non occorre modificare
questa impostazione. In tal modo, è possibile eseguire
più di un daemon di agent del processo sullo stesso
computer.
Suggerimento: Su Windows, non vi è alcuna
limitazione al numero di agent del processo che
possono essere eseguiti come servizi Windows sullo
stesso host.
Specifica la dimensione del pool di messaggi per la
gestione dei segnali.
Linux
-pidmsgpool integer
UNIX
Linux
-redirectfile string
252
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Specifica un file verso il quale vengono indirizzati i
messaggi stderr ed stdout dei processi avviati
dall’agent del processo. È molto utile per la
risoluzione dei problemi.
Suggerimento: Su Windows, è possibile ottenere un
risultato simile eseguendo l’agent del processo dalla
riga comandi. Ciascun processo child avrà una
finestra di console in cui verrà visualizzato l’output
dell’elaborazione. In alternativa, se l’agent del
processo è in esecuzione come servizio Windows,
aprire la finestra Servizi e specificare le seguenti
impostazioni nella finestra Proprietà per il servizio:
dalla scheda Connessione, selezionare Account di
sistema locale, quindi selezionare Consenti al
servizio di interagire con il desktop.
Tabella 73. Opzioni della riga comandi di nco_pad per il daemon dell’agent del
processo (Continua)
Opzione di riga comandi
Descrizione
-retrytime integer
Specifica il numero di secondi per i quali un processo
avviato dal controllo processi deve essere eseguito
perché l’avvio sia considerato riuscito. Il retrytime
predefinito è 5.
L’agent del processo tenta di riavviare un processo se
il processo viene chiuso. Se il processo viene chiuso
dopo retrytime secondi, l’agent del processo tenta di
riavviare il processo immediatamente. Se il processo
viene chiuso prima di retrytime secondi, l’agent del
processo tenta di riavviare il processo a una
frequenza esponenziale di 2, 4, 8, 16, 32, ..., 256
secondi. L’agent del processo reimposta l’intervallo di
tempo dopo otto tentativi di avvio del processo.
Se il processo non riesce ad essere eseguito per più di
retrytime secondi, viene ridotto anche il RetryCount
(specificato nella definizione del processo) per quel
processo. Se il processo viene eseguito correttamente
per almeno retrytime secondi, il RetryCount viene
reimpostato sul valore originale. Se il RetryCount è 0,
non vi è alcun limite al numero di tentativi di
riavvio.
-roguetimeout integer
Specifica il tempo in secondi da attendere per
l’arresto del processo. Il valore predefinito è 30
secondi, mentre quello minimo è 5 secondi.
-secure
Se si specifica -secure, tutti i client devono
autenticarsi con un nome utente e una password
validi, che vengono specificati con le opzioni della
riga comandi -user e -password.
In modalità non FIPS 140–2, le informazioni di
accesso vengono codificate automaticamente durante
la trasmissione quando l’agent del processo si
connette a un altro agent del processo. In modalità
FIPS 140–2, le informazioni di accesso vengono
trasmesse in testo semplice e occorre utilizzare l’SSL
se è necessaria la codifica durante la trasmissione.
-stacksize integer
Specifica la dimensione dello stack di thread.
Directory per ticket Kerberos se -authenticate è
impostata su KERBEROS.
UNIX
Linux
-ticketdir string
-traceevtq
Abilita la traccia dell’attività della coda degli eventi.
-tracemsgq
Abilita la traccia dell’attività della coda dei messaggi.
-tracemtx
Abilita la traccia dei blocchi mutex.
-tracenet
Abilita la traccia della libreria net.
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
253
Tabella 73. Opzioni della riga comandi di nco_pad per il daemon dell’agent del
processo (Continua)
Opzione di riga comandi
Descrizione
-user string
Specifica il nome utente utilizzato per accedere a un
altro agent del processo.
Se l’opzione -user non viene specificata, il nome
utente utilizzato per stabilire la connessione è quello
dell’utente che esegue il comando.
Questa opzione deve essere specificata per la
connessione a un agent del processo in esecuzione in
modalità sicura (viene utilizzata l’opzione -secure).
Questo nome utente e la relativa password associata
(che si specifica utilizzando -password) vengono
utilizzati se non si specificano credenziali di accesso
nella sezione degli instradamenti del file di
configurazione del controllo processi.
-version
Visualizza informazioni sulla versione relative
all’agent del processo ed esce.
Avvio automatico degli agent del processo su UNIX
Su UNIX, sono disponibili script di avvio per avviare automaticamente l’agent del
processo all’avvio del sistema.
Questi script si trovano nella seguente directory:
$NCHOME/omnibus/install/startup
Questa directory contiene uno dei seguenti script di installazione, a seconda del
sistema operativo:
v aix5install
v hpux11install
v solaris2install
v linux2x86install
v linux2s390install
Per utilizzare gli script per l’avvio degli agent del processo, è necessario eseguire lo
script di installazione appropriato per il sistema operativo in uso. È possibile che
sia necessario rendere eseguibile lo script prima di poterlo utilizzare.
Per installare gli script per l’avvio degli agent del processo:
1. Eseguire lo script di installazione come utente root. Ad esempio, per installare
gli script su Solaris, eseguire solaris2install dalla directory $NCHOME/omnibus/
install/startup. Viene visualizzato il seguente output:
Name of the Process Agent Daemon [NCO_PA]
2. Premere Invio per accettare il nome server dell’agent del processo predefinito
NCO_PA oppure immettere un altro nome server. Viene visualizzato il seguente
output:
Should pa_name run in secure mode (y/n)? [y]
254
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
3. Premere Invio per includere l’opzione della riga comandi -secure quando si
avvia l’agent del processo. La modalità sicura controlla l’autenticazione delle
richieste di connessione con un nome utente e una password.
Viene visualizzato il seguente messaggio:
Enter value for environment variable NETCOOL_LICENSE_FILE,
if required [27000@localhost]:
Nota: Sebbene Tivoli Netcool/OMNIbus non richieda una chiave di licenza per
l’esecuzione, alcuni probe e gateway che sono stati sottoposti a un recente ciclo
di manutenzione, potrebbero richiedere chiavi di licenza. Se si eseguono questi
pacchetti di probe o gateway meno recenti, essi richiederanno l’impostazione
della variabile di ambiente NETCOOL_LICENSE_FILE e la disponibilità di un
server delle licenze Netcool.
4. Se non si utilizza un server delle licenze, per eseguire lo script sarà sufficiente
premere Invio. Se invece si utilizza un server delle licenze, premere Invio per
accettare il valore predefinito per la variabile di ambiente per la gestione
licenze oppure immettere un altro valore.
Risultati
Ogni script di installazione copia o collega i file di configurazione richiesti nella
directory di avvio del sistema. Su alcuni sistemi (ad esempio, Solaris e HP-UX), è
anche possibile interrompere i processi all’arresto del sistema.
Operazioni successive
Se necessario, è possibile modificare gli script di avvio prima di installarli. Si noti
che gli script linux2x86install e linux2s390install contengono numerose sezioni per
le versioni Red Hat e SUSE di Linux. Queste sezioni sono delimitate da commenti
all’interno dello script come mostrato di seguito:
### REDHAT ONLY
...
### END REDHAT ONLY
### SUSE ONLY
...
### END SUSE ONLY
Modificare le sezioni pertinenti per la versione di Linux che si utilizza. Per
informazioni sulla modifica degli script di avvio, consultare la documentazione
specifica del proprio sistema operativo.
Avvio automatico degli agent del processo su Windows
Su Windows, è possibile installare l’agent del processo come servizio Windows.
Utilizzare la finestra Servizi nel Pannello di controllo per assegnare al servizio uno
dei seguenti account di accesso:
v Account del sistema locale (LocalSystem).
v Un account che appartiene al gruppo Administrators sul computer locale.
Per ulteriori informazioni sull’installazione e sulla configurazione di un agent del
processo come servizio Windows, consultare IBM Tivoli Netcool/OMNIbus - Guida
all’installazione e alla distribuzione.
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
255
Gestione della configurazione del sistema per il controllo
processi
Dopo aver configurato il sistema per il controllo processi e gli agent del processo
sono in esecuzione, è possibile scegliere di apportare modifiche alla configurazione
eseguendo i programmi di utilità per il controllo processi. Le modifiche apportate
alla configurazione valgono solo per la sessione corrente e non vengono salvate nel
file di configurazione.
È anche possibile utilizzare Netcool/OMNIbus Administrator per modificare la
configurazione. Le modifiche alla configurazione apportate da Netcool/OMNIbus
Administrator possono essere salvate nel file di configurazione.
Concetti correlati
“Utilizzo di Netcool/OMNIbus Administrator per gestire il controllo processi” a
pagina 275
Attività correlate
“Configurazione e gestione del controllo processi dalla riga comandi”
Configurazione e gestione del controllo processi dalla riga comandi
È possibile definire processi, servizi e host nel file di configurazione del controllo
processi. È anche possibile utilizzare programmi di utilità della riga comandi per
avviare, arrestare e aggiungere un servizio o un processo, visualizzare lo stato di
servizi e processi e arrestare un agent del processo.
Prima di poter gestire il controllo processi utilizzando uno di questi metodi, è
necessario aver creato una configurazione del sistema per il controllo processi.
Concetti correlati
“Utilizzo di Netcool/OMNIbus Administrator per gestire il controllo processi” a
pagina 275
Attività correlate
“Creazione e avvio di un sistema di rete per il controllo processi” a pagina 244
Definizione di processi, servizi e host per il controllo processi
Perché possano essere eseguiti sotto il controllo processi, i processi, i servizi e gli
host devono essere definiti nel file di configurazione di un agent del processo.
Quando l’agent del processo viene avviato, legge questo file per stabilire le
impostazioni di configurazione.
Il file di configurazione dell’agent del processo predefinito è:
$NCHOME/omnibus/etc/nco_pa.conf
Questo file è costituito da definizioni, ciascuna delle quali contiene attributi e
valori associati, per ogni singolo processo, servizio e host. Nel file, le definizioni
sono elencate nell’ordine seguente:
1. Definizioni di processi
2. Definizioni di servizi
3. Definizioni di sicurezza (facoltative)
4. Definizioni di instradamento
256
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Modificare questo file direttamente per aggiungere o modificare definizioni.
Mantenere i file di configurazione su tutti gli host per assicurare che le
informazioni di configurazione host restino sincronizzate tra tutti gli agent del
processo nella configurazione.
Nota: Per impedire che utenti non autorizzati accedano al sistema operativo,
impostare la sicurezza in maniera appropriata per i file che potrebbero contenere
nomi utenti e password, ad esempio i file di configurazione.
Definizione dei processi nel file di configurazione dell’agent del
processo
Nel file di configurazione dell’agent del processo, è necessario definire l’elenco di
processi che devono essere eseguiti dagli agent del processo.
Esempio di definizione di un processo
Un esempio di definizione di un processo nel file di configurazione
$NCHOME/omnibus/etc/nco_pa.conf è il seguente:
nco_process 'ObjectServer'
{
Command '$NCHOME/omnibus/bin/nco_objserv -name NCOMS -pa SFOSYS1_PA' run as 0
Host
= 'sfosys1'
Managed
= True
RestartMsg = '${NAME} running as ${EUID} has been restored on ${HOST}.'
AlertMsg = '${NAME} running as ${EUID} has died on ${HOST}.'
RetryCount = 0
ProcessType = PaPA_AWARE
}
Descrizione della definizione di un processo
La tabella riportata di seguito utilizza l’esempio precedente per descrivere le
informazioni relative alla definizione di un processo contenute nel file di
configurazione.
Tabella 74. Descrizione della definizione di un processo
Informazioni di
configurazione
nco_process
'ObjectServer'
Descrizione
Definisce il nome del processo. Questo esempio è per un ObjectServer.
Nota: I nomi dei processi devono essere univoci per questo agent del processo. Se si
utilizza lo stesso nome di processo più di una volta, tutte le definizioni, ad eccezione della
prima, vengono ignorate e viene generato un messaggio di avvertenza.
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
257
Tabella 74. Descrizione della definizione di un processo (Continua)
Informazioni di
configurazione
Command
Descrizione
La stringa di comando che avvia il processo, così come verrebbe immessa dalla riga
comandi. Utilizzare il percorso completo per il comando. Ad esempio, per configurare un
ObjectServer denominato NCOMS, immettere:
’$NCHOME/omnibus/bin/nco_objserv -name NCOMS -pa SFOSYS1_PA’ run as 0
Oppure immettere:
’$NCHOME/omnibus/bin/nco_objserv -name NCOMS -pa SFOSYS1_PA’ run as ’root’
In questo esempio:
v L’opzione -pa specifica l’agent del processo che l’ObjectServer utilizza per eseguire
automazioni esterne. In questo esempio, il nome dell’agent del processo viene specificato
come SFOSYS1_PA.
v L’opzione run as indica al computer host di eseguire l’ObjectServer utilizzando il nome
utente che è stato specificato. Su UNIX, è possibile immettere l’ID utente (di solito 0),
oppure immettere il nome utente racchiuso tra virgolette singole (di solito root). Quando
si immette un nome utente, l’agent del processo ricerca l’ID utente da utilizzare. Se
l’agent del processo non è in esecuzione come root, l’opzione run as viene ignorata e il
processo viene eseguito con il nome utente di chi sta eseguendo l’agent del processo.
Su Windows, tutti i processi vengono eseguiti con lo stesso account utente dell’agent del
processo; impostare sempre l’opzione run as su 0.
Suggerimento: Su Windows, è possibile utilizzare %NCHOME%, $NCHOME oppure la
forma estesa della variabile di ambiente, nel percorso per il comando. È anche possibile
utilizzare barre (/), barre retroverse (\) o doppie barre retroverse (\\) come separatori.
È possibile impostare i seguenti attributi di processo aggiungendoli all’inizio della stringa
di comando:
v CWD: impostare la directory di lavoro corrente sul valore specificato.
Su Windows, è possibile specificare la directory in uno qualsiasi dei seguenti formati:
formato MS-DOS (ad esempio, C:\temp), formato UNIX (ad esempio, /temp/mydir) e
formato UNC (ad esempio, \\server\share\mydir). È possibile utilizzare come separatori
sia la singola che la doppia barra retroversa.
Quando si esegue l’agent del processo dalla riga comandi su UNIX o Windows, la
directory di lavoro per tutti i processi child è la directory da cui è stato avviato l’agent
del processo. Quando si esegue l’agent del processo come daemon UNIX, la directory di
lavoro per tutti i processi child è $NCHOME/omnibus. Quando si esegue l’agent del processo
come servizio Windows, la directory di lavoro predefinita per l’agent del processo e per
qualsiasi processo child creato dall’agent del processo è %NCHOME%\omnibus\log.
v SETGID: impostare l’ID gruppo del processo sul valore specificato. Si tratta di un attributo
specifico di UNIX.
v UMASK: impostare la umask del processo sul valore specificato. Si tratta di un attributo
specifico di UNIX.
Il formato per specificare ciascuno di questi attributi è il seguente:
Command '[CWD=directory_path]commandpath options' run as user
Command '[SETGID=groupID]commandpath options' run as user
Command '[UMASK=permission]commandpath options' run as user
Nota: È necessario specificare gli attributi come indicato, tra parentesi quadre e senza spazi.
258
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 74. Descrizione della definizione di un processo (Continua)
Informazioni di
configurazione
Descrizione
Command
(continua dalla pagina precedente)
Esempi (UNIX):
Command '[CWD=/opt/netcool/]$NCHOME/omnibus/bin/nco_objserv -name NCOMS2 -pa
NCO_PA' run as 1253
Command '[SETGID=ncoadmin]$NCHOME/omnibus/bin/nco_objserv -name NCOMS2 -pa NCO_PA'
run as 1253
Command '[UMASK=u=rwx,g=rx,o=rx]$NCHOME/omnibus/bin/nco_objserv -name NCOMS2 -pa
NCO_PA' run as 1253
Suggerimento: Nell’esempio precedente con l’impostazione UMASK, le autorizzazioni di
scrittura vengono assegnate all’utente corrente, ma vengono rimosse per tutti gli altri utenti.
È possibile specificare in alternativa la stringa [UMASK=022].
Command '[UMASK=077]$NCHOME/omnibus/bin/nco_objserv -name NCOMS2 -pa NCO_PA' run as
1253
È possibile specificare uno o più attributi all’interno della stringa di comando. Ad esempio:
Command '[CWD=/tmp][SETGID=ncoadmin][UMASK=u=rwx,g=,o=]$NCHOME/omnibus/bin/
nco_objserv -name NCOMS2 -pa NCO_PA' run as 1253
Esempio (Windows):
Command '[CWD=C:\temp]%NCHOME%\omnibus\bin\nco_objserv -name NCOMS2 -pa NCO_PA' run
as 0
Host
Il nome dell’host sul quale deve essere eseguito il processo. Il controllo processi risolve
automaticamente il nome dell’agent del processo quando è necessario.
Managed
Può avere uno dei seguenti valori:
v True: il processo viene avviato automaticamente nel caso in cui venga chiuso.
v False: il processo non viene avviato automaticamente nel caso in cui venga chiuso.
RestartMsg
Contiene il messaggio da inviare al syslog di UNIX oppure al Visualizzatore eventi di
Windows se il processo viene riavviato. Ad esempio, The ObjectServer has been
restarted.
AlertMsg
Contiene il messaggio da inviare al syslog di UNIX o al Visualizzatore eventi di Windows
se il processo viene chiuso. Ad esempio, The ObjectServer has gone down.
RetryCount
Specifica il numero di tentativi di riavvio da effettuare se il processo viene chiuso nel
tempo specificato dall’opzione della riga comandi nco_pad -retrytime. Se impostata su 0,
non vi è alcun limite al numero di tentativi di riavvio. L’impostazione predefinita è 0.
ProcessType
Può avere il valore PaPA_AWARE per processi che riconoscono PA e PaNOT_PA_AWARE
per processi che non riconoscono PA.
Parole chiave di espansione
È possibile includere parole chiave di espansione nelle voci RestartMsg e AlertMsg
nel file di configurazione. Le parole chiave di espansione fungono da variabili e
contengono informazioni sul processo che è stato riavviato.
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
259
Le parole chiave di espansione sono riportate nella seguente tabella:
Tabella 75. Parole chiave di espansione
Parola chiave di espansione
Descrizione
${NAME}
Il nome del processo
${HOST}
Il nome dell’host su cui è in esecuzione il
processo.
${EUID}
L’ID utente valido con cui è in esecuzione il
processo.
${COMMAND}
Il comando che definisce il processo.
Messaggi di avviso e di riavvio del syslog o del Visualizzatore eventi
Quando il daemon dell’agent del processo nco_pad, genera un messaggio di avviso
o di riavvio, questo messaggio viene trasmesso al syslog di UNIX o al
Visualizzatore eventi di Windows. Tivoli Netcool/OMNIbus ha un probe Syslog
che può monitorare questi messaggi e convertirli in avvisi ObjectServer. Per
ulteriori informazioni sul probe Syslog, fare riferimento alla documentazione del
probe disponibile nel Centro informazioni di Tivoli Network Management,
all’indirizzo http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp.
I messaggi di avviso e di riavvio vengono inviati al syslog di UNIX o al
Visualizzatore eventi di Windows sotto forma di avvertenze. Il messaggio ha il
seguente formato:
HOSTNAME : ALERT_OR_RESTART_MSG : MSG
HOSTNAME è il nome dell’host che ha segnalato il problema.
ALERT_OR_RESTORE_MSG descrive il tipo di messaggio. MSG è il testo definito
nel file di configurazione per quel processo.
Definizione dei servizi nel file di configurazione dell’agent del
processo
Nel file di configurazione dell’agent del processo, è possibile definire servizi per
raggruppare insieme processi correlati e configurare interdipendenze dei processi.
È necessario che i processi siano già definiti nell’elenco dei processi all’interno del
file.
Esempio di definizione di un servizio
Un esempio di definizione di un servizio nel file di configurazione
$NCHOME/omnibus/etc/nco_pa.conf è il seguente:
nco_service 'Omnibus'
{
ServiceType = Master
ServiceStart = Non-Auto
process 'ObjectServer' NONE
process 'Proxy' 'ObjectServer'
process 'Probe' 'Proxy'
process 'Probe-1' 'ObjectServer'
process 'Sleep' 5
}
260
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Esempio di definizione di un servizio
La tabella riportata di seguito utilizza l’esempio precedente per descrivere le
informazioni relative alla definizione di un servizio contenute nel file di
configurazione.
Tabella 76. Esempio di definizione di un servizio
Informazioni di configurazione
Descrizione
nco_service 'Omnibus'
Definisce il nome del servizio (ad esempio, Omnibus).
Nota: Ciascun nome di servizio deve essere univoco
nella rete del controllo processi.
ServiceType
Definisce se questo servizio deve essere avviato
prima di tutti gli altri servizi e gestito come servizio
principale dal quale dipendono altri servizi. È
possibile utilizzare l’impostazione Master o
Non-Master.
ServiceStart
Scegliere Auto per avviare il servizio insieme a
nco_pad, oppure scegliere Non-Auto per avviare il
servizio manualmente con il comando nco_pa_start.
process
Ciascuna voce relativa a un processo definisce un
processo che deve essere eseguito come parte del
servizio. È possibile indicare le dipendenze del
processo in modo che un processo non possa essere
eseguito prima che un altro sia già in esecuzione.
Nota: È necessario includere un processo solo una
volta in qualsiasi definizione di servizio nel file di
configurazione.
Specifica delle dipendenze del processo
Quando si definisce un servizio, è possibile utilizzare l’attributo process per
definire i processi che devono essere eseguiti come parte del servizio. È possibile
aggiungere dipendenze a ciascuno dei processi del servizio. Il formato
dell’attributo process è il seguente:
process 'processname' dependency
In questo attributo, processname è il nome del processo definito nell’elenco di
processi, mentre dependency può essere un valore numerico, un valore stringa
oppure NONE.
Se dependency è un numero, indica una dipendenza temporale, in secondi, per
avviare il processo dipendente. Una dipendenza temporale viene calcolata sempre
dall’avvio del servizio. Ad esempio, se si immette 5, il processo viene avviato
cinque secondi dopo il servizio.
Se dependency è una stringa, indica un altro processo che riconosce PA nello stesso
servizio.
Limitazione: Un processo non può dipendere da un processo che abbia una
dipendenza temporale. Se si specifica una dipendenza da un processo che a sua
volta ha una dipendenza temporale, un messaggio di errore viene aggiunto al file
di log del controllo processi e al processo dipendente e a qualsiasi processo child
viene assegnato lo stato DEAD. Il file di log predefinito è $NCHOME/omnibus/log/
pa_name.log, dove pa_name è il nome dell’agent del processo.
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
261
Il tipo di dependency NONE indica che non vi sono dipendenze.
Nel precedente esempio di definizione di servizio per il servizio Omnibus, il
processo ObjectServer viene avviato per primo perché non ha alcuna dipendenza.
Cinque secondi dopo l’avvio dell’ObjectServer, viene avviato il processo Sleep. Se
l’ObjectServer viene avviato correttamente, vengono avviati i processi Proxy e
Probe-1. Quando il server proxy è in esecuzione, viene avviato il processo Probe.
Se un processo viene specificato come dipendente dal processo Sleep, il quale ha
una dipendenza temporale, quel processo non viene avviato e gli viene assegnato
lo stato DEAD.
Riferimenti correlati
“Definizione dei processi nel file di configurazione dell’agent del processo” a
pagina 257
Definizione di host sicuri nel file di configurazione dell’agent del
processo
È possibile specificare che solo determinati host possono connettersi agli agent del
processo aggiungendo una definizione di sicurezza al file di configurazione
dell’agent del processo. Se non si crea una definizione di sicurezza, qualsiasi
processo può connettersi da qualsiasi host.
Nel file di configurazione $NCHOME/omnibus/etc/nco_pa.conf, la definizione di
sicurezza viene inserita tra le definizioni dei servizi e le definizioni di
instradamento per gli host. È possibile creare una definizione di sicurezza senza
alcun host specificato, nel modo seguente:
nco_security
{
}
Quando non si specificano host, possono connettersi solo i processi che sono in
esecuzione sull’host corrente o su qualsiasi host elencato nella definizione di
instradamento.
I processi in esecuzione su host che non sono elencati nella definizione di
instradamento possono connettersi solo se il relativo host è elencato nella
definizione di sicurezza.
L’agent del processo confronta l’indirizzo IP della connessione in entrata con
quello di ciascuna voce presente nelle definizioni di sicurezza e di instradamento.
L’agent del processo verifica anche l’indirizzo IP dell’host locale. Solo l’indirizzo
principale dell’host che esegue il daemon dell’agent del processo viene aggiunto
automaticamente alla definizione di sicurezza. È necessario aggiungere l’indirizzo
di loopback (127.0.0.1) e le interfacce secondarie, se richiesti.
Nota: Quando un processo che si connette all’agent del processo viene eseguito su
un host con più interfacce, è necessario aggiungere l’interfaccia più vicina al
daemon dell’agent del processo. Non deve essere necessariamente l’indirizzo
principale di quell’host, neppure, nel caso dell’ObjectServer (nco_objserv), quello
del daemon dell’agent del processo (nco_pad), ma deve essere l’indirizzo
specificato nell’editor del server (nco_xigen).
È possibile specificare i seguenti tipi di voci nella definizione di sicurezza:
v Un nome host, nel qual caso viene eseguita una ricerca per trovare l’indirizzo IP
corrispondente
v Un indirizzo IPv4 completo nella notazione decimale puntata
262
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
v Un indirizzo IPv6 nella notazione completa, abbreviata o nella notazione
separata da due punti mista
Un indirizzo IPv4 nella notazione decimale puntata può contenere i seguenti
caratteri jolly:
v ? corrisponde a un carattere
v * corrisponde a un numero qualsiasi di caratteri
È possibile accodare /n a un indirizzo IPv6 specificato, dove n è un numero, per
rappresentare indirizzi IPv6 per i quali i primi n bit corrispondono all’indirizzo IP
dichiarato.
Esempio di definizione di sicurezza
Il seguente esempio di definizione di sicurezza consente connessioni da processi
sui seguenti host:
v alpha
v 192.9.200.34
v Qualsiasi host sulla subnet 193.42.52.0
v Qualsiasi host con un indirizzo IPv6 dove i primi 10 bit corrispondono a
fe80::203:baff:fe2a:6bf0
v fe80::203:baff:fe2a:6bf0
nco_security
{
host 'alpha'
host '192.9.200.34'
host '193.42.52.*'
host 'fe80::203:baff:fe2a:6bf0/10'
host 'fe80::203:baff:fe2a:6bf0'
}
Definizione degli host di instradamento nel file di configurazione
dell’agent del processo
Per specificare gli host che partecipano al sistema per il controllo processi, è
necessario definire i nomi host degli agent del processo nel file di configurazione
degli agent del processo.
Ciascuna voce host definisce il nome dell’host (ad esempio, sfosys1) e il nome
dell’agent del processo da utilizzare nel sistema per il controllo processi (ad
esempio, SFOSYS1_PA). Per ciascuna definizione host, è necessario specificare
anche le credenziali nome utente e password per la connessione all’agent del
processo.
Esempio di definizione di instradamento
Un esempio di definizione di instradamento nel file di configurazione
$NCHOME/omnibus/etc/nco_pa.conf è il seguente:
nco_routing
{
host 'sfosys1' 'SFOSYS1_PA' 'username' 'password'
host 'sfosys2' 'SFOSYS2_PA' 'username' 'password'
}
Nota: Le voci username e password sono obbligatorie se si esegue l’agent del
processo remoto in modalità sicura. Se non si esegue l’agent del processo remoto in
modalità sicura, i nomi utente e le password sono facoltativi.
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
263
Se l’agent del processo utilizza l’autenticazione UNIX (predefinita su UNIX),
username deve essere l’utente del sistema operativo membro del gruppo ncoadmin
(predefinito) o di qualsiasi altro gruppo amministrativo creato per assegnare
l’accesso al sistema per il controllo processi. Un daemon dell’agent del processo in
esecuzione in modalità sicura deve essere eseguito dall’utente root.
Su Windows, username deve essere il nome utente di un account locale, un account
di dominio o un account UPN valido.
Nota: Per impedire l’accesso a utenti non autorizzati, la sicurezza del sistema
operativo deve essere impostata in maniera appropriata per i file che contengono
nomi utente e password.
Quando si esegue il daemon dell’agent del processo nco_pad, è anche possibile
specificare il nome utente e la password utilizzando le opzioni della riga comandi
-user e -password. In tal modo, le voci nel file di configurazione nco_pa.conf
vengono sovrascritte.
Codifica delle password in testo semplice nelle definizioni di
instradamento
È possibile codificare le password di accesso in testo semplice memorizzate nel file
nco_pa.conf.
I dettagli di codifica della password per l’esecuzione in modalità FIPS 140–2 e non
FIPS 140–2 sono descritti nella seguente tabella:
Tabella 77. Codifica della password in modalità FIPS 140–2 e non FIPS 140–2
Modalità
Azione
Modalità FIPS
140–2
In modalità FIPS 140–2, è possibile specificare le password in testo
semplice o in formato codificato. La codifica delle password può
avvenire tramite codifica dei valori di proprietà, nel modo seguente:
1. Se non si dispone ancora di una chiave per la codifica della
password, crearne una eseguendo il programma di utilità
nco_keygen, situato in $NCHOME/omnibus/bin.
2. Eseguire il programma di utilità nco_aes_crypt per codificare la
password con la chiave generata dal programma di utilità
nco_keygen. Anche il programma di utilità nco_aes_crypt si trova in
$NCHOME/omnibus/bin. Tenere presente che è necessario specificare
AES_FIPS come algoritmo da utilizzare per la codifica della
password.
3. Copiare la password codificata nella definizione di instradamento
appropriata nel file di configurazione.
264
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 77. Codifica della password in modalità FIPS 140–2 e non FIPS 140–2 (Continua)
Modalità
Azione
Modalità non
FIPS 140–2
Nella modalità non FIPS 140–2, è possibile utilizzare il programma di
utilità nco_pa_crypt oppure utilizzare la codifica dei valori delle
proprietà per codificare password di accesso in testo semplice su UNIX.
Su Windows, è possibile utilizzare il programma di utilità nco_g_crypt
oppure utilizzare la codifica dei valori delle proprietà. Effettuare una
delle seguenti azioni:
v Per codificare una password utilizzando il programma di utilità
nco_pa_crypt o nco_g_crypt, eseguire i comandi nel modo seguente:
– UNIX:
$NCHOME/omnibus/bin/nco_pa_crypt plaintext_password
– Windows:
%NCHOME%\omnibus\bin\nco_g_crypt plaintext_password
In questi comandi, plaintext_password rappresenta la password non
codificata. Il programma di utilità visualizza la versione codificata
della password. Copiare la password codificata nella definizione di
instradamento appropriata nel file di configurazione.
v Per codificare una password utilizzando una codifica dei valori di
proprietà, è necessaria una chiave generata con il programma di
utilità nco_keygen. È quindi possibile eseguire nco_aes_crypt per
codificare la password con la chiave. Tenere presente che è possibile
specificare AES_FIPS o AES come algoritmo per la codifica della
password. Utilizzare AES solo se occorre mantenere la compatibilità
con password che sono state codificate con gli strumenti forniti in
versioni precedenti a Tivoli Netcool/OMNIbus V7.2.1.
Copiare la password codificata nella definizione di instradamento
appropriata nel file di configurazione.
Nota: Su UNIX, anche se la password viene specificata nella riga comandi, non
viene visualizzata nell’output del comando ps.
Le password codificate utilizzando nco_pa_crypt vengono decodificate dall’agent
del controllo processi remoto.
Le password codificate utilizzando nco_aes_crypt vengono decodificate dal
daemon dell’agent del processo e trasmesse agli agent del processo remoti in testo
semplice. Per decodificare le password, è necessario impostare le opzioni della riga
comandi -cryptalgorithm e -keyfile quando si esegue nco_pad. Queste opzioni
specificano quale algoritmo e file chiave utilizzare per la decodifica.
Per ulteriori informazioni sull’utilizzo della codifica dei valori delle proprietà,
consultare IBM Tivoli Netcool/OMNIbus - Guida all’installazione e alla distribuzione.
Attività correlate
“Creazione di gruppi di utenti UNIX per il sistema per il controllo processi” a
pagina 245
Riferimenti correlati
“Opzioni della riga comandi dell’agent del processo” a pagina 248
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
265
Esempio: File di configurazione dell’agent del processo
Questo esempio mostra il contenuto di un file di configurazione dell’agent del
processo $NCHOME/omnibus/etc/nco_pa.conf.
############################################################################
#NCO_PA3#
# Process Agent Daemon Configuration File 1.1
#
# Ident: $Id: nco_pa.conf 1.3 2002/05/21 15:28:10
#
#
# List of processes
#
nco_process 'NO1_PROXY_ProxyServer'
{
Command '$NCHOME/omnibus/bin/nco_proxyserv -name NETPROXY -server NETOPS1' run as 0
Host = 'objser1'
Managed = True
RestartMsg = '${NAME} running as ${EUID} has been restored on ${HOST}.'
AlertMsg = '${NAME} running as ${EUID} has died on ${HOST}.'
RetryCount = 0
ProcessType = PaPA_AWARE
}
nco_process 'SFOSYS_ObjectServer'
{
Command '$NCHOME/omnibus/bin/nco_objserv -name NETOPS1 -pa OBJSER1_PA' run as 0
Host = 'objser1'
Managed = True
RestartMsg = '${NAME} running as ${EUID} has been restored on ${HOST}.'
AlertMsg = '${NAME} running as ${EUID} has died on ${HOST}.'
RetryCount = 0
ProcessType = PaPA_AWARE
}
nco_process 'Syslog_Probe'
{
Command '$NCHOME/omnibus/probes/nco_p_syslog' run as 0
Host = 'objser1'
Managed = True
RestartMsg = '${NAME} running as ${EUID} has been restored on ${HOST}.'
AlertMsg = '${NAME} running as ${EUID} has died on ${HOST}.'
RetryCount = 0
ProcessType = PaNOT_PA_AWARE
}
nco_process 'Mttrapd_Probe'
{
Command '$NCHOME/omnibus/probes/nco_p_mttrapd' run as 0
Host = 'objser1'
Managed = True
RestartMsg = '${NAME} running as ${EUID} has been restored on ${HOST}.'
AlertMsg = '${NAME} running as ${EUID} has died on ${HOST}.'
RetryCount = 0
ProcessType = PaNOT_PA_AWARE
}
nco_process 'MyScript'
{
Command '$HOME/myscript.sh' run as 0
Host = 'objser1'
Managed = False
RestartMsg = '${NAME} running as ${EUID} has been restored on ${HOST}.'
AlertMsg = '${NAME} running as ${EUID} has died on ${HOST}.'
RetryCount = 0
ProcessType = PaNOT_PA_AWARE
}
#
# List of Services
#
nco_service 'Core'
{
ServiceType = Master
ServiceStart = Auto
process 'MyScript' NONE
# ObjectServer started after 20 seconds to allow the script to finish
process 'SFOSYS_ObjectServer' 20
# Proxy server started after the ObjectServer starts
process 'NO1_PROXY_ProxyServer' 'SFOSYS_ObjectServer'
# Trapd probe and then Syslog probe started after the proxy server starts
process 'Mttrapd_Probe' 'NO1_PROXY_ProxyServer'
process 'Syslog_Probe' 'NO1_PROXY_ProxyServer'
}
266
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
#
# ROUTING TABLE
#
# 'user' - (optional) only required for secure mode PAD on target host
#
'user' must be member of a UNIX administrative group if using UNIX authentication
#
On Windows, 'user' must be the user name of a valid local, domain, or UPN account
# 'password' - (optional) only required for secure mode PAD on target host
#
can be plain text, or encrypted using encryption tool provided for specific
#
platform and security requirements
nco_routing
{
host 'objser1' 'OBJSER1_PA'
}
Gestione del controllo processi utilizzando programmi di
utilità
Il sistema per il controllo processi fornisce programmi di utilità della riga comandi
per gestire e modificare la configurazione di Tivoli Netcool/OMNIbus. È possibile
eseguire questi programmi di utilità per avviare, arrestare e aggiungere un servizio
o un processo, visualizzare lo stato dei servizi e dei processi e arrestare un agent
del processo.
I programmi di utilità della riga comandi sono i seguenti:
v nco_pa_status
v nco_pa_start
v nco_pa_stop
v nco_pa_shutdown
v nco_pa_addentry
Ciascun programma di utilità richiede l’immissione di una password.
Visualizzazione dello stato di servizi e processi (nco_pa_status)
È possibile eseguire il programma di utilità nco_pa_status per richiamare lo stato
dei servizi nella configurazione del sistema per il controllo processi. Per ciascun
servizio, il programma di utilità nco_pa_status restituisce un elenco di processi
definiti, lo stato di ciascun processo e l’identificativo del processo.
Per visualizzare lo stato dei servizi, immettere il seguente comando:
$NCHOME/omnibus/bin/nco_pa_status -server string
In questo comando, string è il nome dell’agent del processo. È anche possibile
eseguire il comando specificando ulteriori opzioni della riga comandi.
Di seguito viene fornito un output di esempio:
-------------------------------------------------------------------------Service Name Process Name Hostname User Status PID
-------------------------------------------------------------------------Master Service ObjectServer SFOSYS1 root RUNNING 16751
Proxy SFOSYS1 root RUNNING 16752
Sleep SFOSYS1 root RUNNING 16753
Probe SFOSYS1 root RUNNING 16754
--------------------------------------------------------------------------
Il valore PID per i processi gestiti è l’identificativo del processo UNIX oppure il
PID riportato in Gestione attività in Windows.
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
267
La seguente tabella descrive i singoli livelli di stato:
Tabella 78. Descrizioni dello stato dei servizi
Livello dello stato
Descrizione
RUNNING
Il processo è in esecuzione.
STARTING
È stata inoltrata una richiesta di avvio.
PENDING
Il processo è in attesa del completamento della
dipendenza temporale. Questo stato indica anche che
non è stato possibile avviare correttamente il processo
(indipendentemente dalle dipendenze del processo).
WAITING
Il processo è in attesa dell’avvio di una dipendenza.
DEAD
Il processo non è esecuzione.
ERROR
Non è stato possibile richiamare uno stato dall’agent
del processo.
Se un agent del processo riceve istruzioni per eseguire un processo mediante un
agent del processo in esecuzione su una macchina differente, l’agent del processo
remoto non mantiene un record del processo. Se l’agent del processo remoto si
interrompe, il processo continua ad essere eseguito. Quando l’agent del processo
remoto viene riavviato, non conserva alcun record del processo, pertanto lo stato
del processo per questo processo orfano viene segnalato come DEAD.
È possibile riavviare il processo manualmente utilizzando il programma di utilità
nco_pa_start.
Opzioni della riga comandi per nco_pa_status
Le opzioni della riga comandi per il programma di utilità nco_pa_status sono
descritte nella seguente tabella:
Tabella 79. Opzioni della riga comandi per nco_pa_status
Opzioni della riga comandi
Descrizione
-help
Visualizza la guida relativa alle opzioni della riga
comandi ed esce.
-nosecure
Si stabilisce una connessione ad agent del processo in
modalità non sicura che non codifica le informazioni
di accesso durante la trasmissione.
-password string
La password da utilizzare per l’agent del processo.
-server string
Nome dell’agent del processo da contattare.
-user string
Il nome utente per l’agent del processo.
L’impostazione predefinita è il nome dell’utente che
esegue il comando.
-version
Visualizza informazioni sulla versione del software ed
esce.
Riferimenti correlati
“Avvio di un servizio o di un processo (nco_pa_start)” a pagina 269
268
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Avvio di un servizio o di un processo (nco_pa_start)
È possibile eseguire il programma di utilità nco_pa_start per avviare un servizio o
un processo in qualsiasi punto della configurazione del sistema per il controllo
processi.
Se il servizio o il processo è stato già avviato, il comando viene ignorato.
Per avviare un servizio o un processo, immettere il comando:
$NCHOME/omnibus/bin/nco_pa_start command_line_options
In questo comando, command_line_options rappresenta una o più opzioni della riga
comandi che è possibile specificare per il programma di utilità nco_pa_start. È
possibile specificare un solo servizio o processo.
Opzioni della riga comandi per nco_pa_start
Le opzioni della riga comandi per il programma di utilità nco_pa_start sono
descritte nella seguente tabella:
Tabella 80. Opzioni della riga comandi per nco_pa_start
Opzione di riga comandi
Descrizione
-help
Visualizza la guida relativa alle opzioni della riga
comandi ed esce.
-nosecure
Si stabilisce una connessione ad agent del processo in
modalità non sicura che non codifica le informazioni
di accesso durante la trasmissione.
-password string
La password da utilizzare per l’agent del processo.
-process string
Il nome del processo da avviare.
-server string
Il nome dell’agent del processo da contattare.
-service string
Il nome del servizio da avviare.
-user string
Il nome utente per l’agent del processo.
L’impostazione predefinita è il nome dell’utente che
esegue il comando.
-version
Visualizza informazioni sulla versione del software ed
esce.
Arresto di un servizio o di un processo (nco_pa_stop)
È possibile eseguire il programma di utilità nco_pa_stop per arrestare un servizio o
un processo in qualsiasi punto della configurazione del sistema per il controllo
processi.
Se il servizio o il processo è stato già arrestato, il comando viene ignorato.
Quando si arresta un servizio, vengono arrestati anche tutti i processi definiti
all’interno di tale servizio. Quando si arresta un processo, lo stato dei processi
dipendenti rimane invariato; se, ad esempio, si arresta un ObjectServer, i probe
dipendenti da tale ObjectServer continuano a venire eseguiti.
Per arrestare un servizio o un processo, immettere il seguente comando:
$NCHOME/omnibus/bin/nco_pa_stop command_line_options
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
269
In questo comando, command_line_options rappresenta una o più opzioni della riga
comandi che è possibile specificare per il programma di utilità nco_pa_stop. È
possibile specificare un solo servizio o processo.
Opzioni della riga comandi per nco_pa_stop
Le opzioni della riga comandi per il programma di utilità nco_pa_stop sono
descritte nella seguente tabella:
Tabella 81. Opzioni della riga comandi per nco_pa_stop
Opzione di riga comandi
Descrizione
-force
Se specificata, non viene fornita alcuna avvertenza se
il processo o il servizio non è in esecuzione.
-help
Visualizza la guida relativa alle opzioni della riga
comandi ed esce.
-nosecure
Si stabilisce una connessione ad agent del processo in
modalità non sicura che non codifica le informazioni
di accesso durante la trasmissione.
-password string
La password da utilizzare per l’agent del processo.
-process string
Il nome del processo da arrestare.
-server string
Il nome dell’agent del processo da contattare.
-service string
Il nome del servizio da arrestare.
-user string
Il nome utente per l’agent del processo.
L’impostazione predefinita è il nome dell’utente che
esegue il comando.
-version
Visualizza informazioni sulla versione del software ed
esce.
Arresto di un agent del processo (nco_pa_shutdown)
È possibile eseguire il programma di utilità nco_pa_shutdown per arrestare un
agent del processo ed eventualmente arrestare i processi e i servizi associati.
Per arrestare un agent del processo, immettere il seguente comando:
$NCHOME/omnibus/bin/nco_pa_shutdown command_line_options
In questo comando, command_line_options rappresenta una o più opzioni della riga
comandi che è possibile specificare per il programma di utilità nco_pa_shutdown.
Opzioni della riga comandi per nco_pa_shutdown
Le opzioni della riga comandi per il programma di utilità nco_pa_shutdown sono
descritte nella seguente tabella:
Tabella 82. Opzioni della riga comandi per nco_pa_shutdown
270
Opzione di riga comandi
Descrizione
-help
Visualizza la guida relativa alle opzioni della riga
comandi ed esce.
-nosecure
Si stabilisce una connessione ad agent del processo in
modalità non sicura che non codifica le informazioni
di accesso durante la trasmissione.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 82. Opzioni della riga comandi per nco_pa_shutdown (Continua)
Opzione di riga comandi
Descrizione
-option string
Specifica il tipo di arresto da eseguire. Può essere
STOP per arrestare tutti i processi gestisti in locale
dall’agent del processo, o LEAVE per lasciare, invece,
in esecuzione i processi gestiti in locale dopo
l’arresto. Se non si specifica -option sulla riga
comandi, il programma di utilità visualizza un menu
con le opzioni di arresto e chiede di specificare il tipo
di arresto da eseguire.
Suggerimento: Per arrestare un processo gestito in
remoto, è necessario eseguire il programma di utilità
nco_pa_stop.
-password string
La password da utilizzare per l’agent del processo.
-server string
Il nome dell’agent del processo da arrestare.
-user string
Il nome utente per l’agent del processo.
L’impostazione predefinita è il nome dell’utente che
esegue il comando.
-version
Visualizza informazioni sulla versione del software ed
esce.
Suggerimento: Se si sta eseguendo un agent del processo come servizio Windows
e si arresta il servizio, vengono arrestati anche i servizi gestiti. Questo significa che
tutti i processi gestiti vengono arrestati in maniera controllata quando si arresta il
sistema.
Riferimenti correlati
“Arresto di un servizio o di un processo (nco_pa_stop)” a pagina 269
Aggiunta di un nuovo servizio o processo (nco_pa_addentry)
È possibile eseguire il programma di utilità nco_pa_addentry per aggiungere un
nuovo servizio o processo mentre l’agent del processo è in esecuzione.
Utilizzare questo programma di utilità per:
v Aggiungere un nuovo servizio a un agent del processo in esecuzione.
v Avviare un processo fire-and-forget. Questi processi vengono avviati in maniera
automatica e non possono essere modificati. Quando si configura un processo
fire-and-forget, definire il processo come non gestito se si desidera assicurare che
venga eseguito una volta sola. A tale scopo, specificare l’opzione della riga
comandi -unmanaged quando si esegue il programma di utilità
nco_pa_addentry.
v Aggiungere un nuovo processo gestito a un servizio.
Nota: Il nuovo servizio o processo non viene aggiunto al file di configurazione
dell’agent del processo a meno che non si scelga di aggiornare il file di
configurazione quando si utilizza Netcool/OMNIbus Administrator.
Per aggiungere un servizio o un processo a un agent del processo in esecuzione,
immettere il comando riportato seguito. Le parentesi quadre racchiudono voci
facoltative.
$NCHOME/omnibus/bin/nco_pa_addentry [-process string | -service string]
command_line_options
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
271
In questo comando, command_line_options rappresenta una o più opzioni della riga
comandi che è possibile specificare per il servizio o il processo o per il programma
di utilità nco_pa_addentry.
Opzioni della riga comandi per nco_pa_addentry
Le opzioni della riga comandi per il programma di utilità nco_pa_addentry sono
descritte nella tabella riportata di seguito.
Importante: Per assicurare che il servizio o il processo venga creato correttamente,
tutte le opzioni della riga comandi pertinenti devono essere specificate in maniera
esplicita con un valore string assegnato. Questa regola vale anche per qualsiasi
impostazione predefinita che si desidera applicare.
Tabella 83. Opzioni della riga comandi per nco_pa_addentry
Opzioni della riga comandi
Descrizione
-alert_msg string
Specifica il messaggio da inviare al syslog di UNIX o
al Visualizzatore eventi di Windows se il processo
viene chiuso.
Su UNIX, racchiudere il valore string tra singole
virgolette se il testo contiene spazi. Su Windows,
racchiudere il valore string tra doppie virgolette se il
testo contiene spazi.
-auto
-nonauto
Se si specifica -auto, il servizio o il processo viene
avviato non appena si avvia l’agent del processo. Per
impostazione predefinita, il servizio deve essere
avviato manualmente con il comando nco_pa_start.
-command string
Specifica la riga comandi del processo. Ad esempio:
$NCHOME/omnibus/bin/nco_objserv -name NCOMS
-pa SFOSYS1_PA
-delay string
Specifica il ritardo in secondi prima che il processo
specificato venga avviato.
-depend string
Indica un processo da cui dipende il processo
specificato.
-help
Visualizza la guida relativa alle opzioni della riga
comandi ed esce.
-host string
Specifica l’host sul quale eseguire il processo.
-managed
Se si specifica -managed, il processo viene riavviato
automaticamente se viene chiuso. L’impostazione
predefinita è -managed.
-unmanaged
-master
-nonmaster
-nosecure
Si stabilisce una connessione ad agent del processo in
modalità non sicura che non codifica le informazioni
di accesso durante la trasmissione.
-pa_aware
Se si specifica -pa_aware, il ProcessType è impostato
su PaPA_AWARE. Per impostazione predefinita, il
processo non riconosce PA.
-not_pa_aware
-parentservice string
272
Se si specifica -master, il tipo di servizio viene
impostato su master. L’impostazione predefinita è
-master.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Specifica il servizio al quale aggiungere il processo.
Nota: Quando si aggiunge un processo a un servizio,
è necessario definire il servizio parent utilizzando
-parentservice.
Tabella 83. Opzioni della riga comandi per nco_pa_addentry (Continua)
Opzioni della riga comandi
Descrizione
-password string
Specifica la password da utilizzare al momento della
connessione all’agent del processo.
-process string
Specifica il nome del processo da aggiungere.
-restart_msg string
Specifica il messaggio da inviare al syslog di UNIX o
al Visualizzatore eventi di Windows se il processo
viene riavviato.
Su UNIX, racchiudere il valore string tra singole
virgolette se il testo contiene spazi. Su Windows,
racchiudere il valore string tra doppie virgolette se il
testo contiene spazi.
-retrycount integer
Specifica il numero di tentativi di riavvio da
effettuare se il processo viene chiuso nel tempo
specificato dall’opzione della riga comandi nco_pad
-retrytime. Se è impostata su 0, non vi è alcun limite
al numero di tentativi di riavvio. L’impostazione
predefinita è 0.
-runas integer
Specifica l’ID utente con il quale eseguire il processo.
-server string
Specifica il nome dell’agent del processo.
L’impostazione predefinita è NCO_PA.
-service string
Specifica il nome del servizio da aggiungere.
-user string
Specifica il nome utente da utilizzare per connettersi
all’agent del processo. L’impostazione predefinita è il
nome dell’utente che esegue il comando.
-version
Visualizza informazioni sulla versione del software ed
esce.
Esempio: Utilizzo di nco_pa_addentry per aggiungere un processo
fire-and-forget (UNIX)
1. Immettere il seguente comando per aggiungere un processo fire-and-forget
chiamato simnet1, che viene avviato automaticamente ed eseguito una sola
volta (come processo non gestito):
./nco_pa_addentry -server TEST_PA -process ’simnet1’ -command
’$NCHOME/omnibus/probes/nco_p_simnet’ -host ’owl’ -retrycount 0
-unmanaged -restart_msg ’test’ -alert_msg ’testalert’
2. Eseguire il programma di utilità nco_pa_status per richiamare lo stato dei
servizi nella configurazione:
$NCHOME/omnibus/bin/nco_pa_status -server TEST_PA
Dove TEST_PA è il nome dell’agent del processo.
Quando il programma di utilità nco_pa_status viene eseguito, l’output non
mostrerà una definizione del processo simnet1 come parte di una voce servizio.
Tuttavia, il comando ps -ef mostrerà il processo simnet1 come se fosse in
esecuzione, anche se non verrà riavviato automaticamente se viene chiuso.
Esempio: Utilizzo di nco_pa_addentry per aggiungere un processo
fire-and-forget (Windows)
1. Immettere il seguente comando per aggiungere un processo fire-and-forget
chiamato simnet1, che viene avviato automaticamente ed eseguito una sola
volta (come processo non gestito):
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
273
″%NCHOME%″\omnibus\bin\nco_pa_addentry -server TEST_PA -process simnet1
-command ″%NCHOME%″\omnibus\probes\win32\nco_p_simnet -host owl
-retrycount 0 -unmanaged -restart_msg ″Probe restarted″ -alert_msg
″Probe stopped″ -password secret
2. Eseguire il programma di utilità nco_pa_status per richiamare lo stato dei
servizi nella configurazione:
″%NCHOME%″\omnibus\bin\nco_pa_status -server TEST_PA
Dove TEST_PA è il nome dell’agent del processo.
Quando il programma di utilità nco_pa_status viene eseguito, l’output non
mostrerà una definizione del processo simnet1 come parte di una voce servizio.
Tuttavia, Gestione attività di Windows mostrerà il processo simnet1 come in
esecuzione, anche se non verrà riavviato automaticamente se viene chiuso.
Esempio: Utilizzo di nco_pa_addentry per aggiungere un processo
gestito a un servizio (UNIX)
1. Immettere il seguente comando per aggiungere un processo chiamato simnet2 a
un servizio Core:
./nco_pa_addentry -server TEST_PA -process ’simnet2’ -command
’$NCHOME/omnibus/probes/nco_p_simnet’ -host ’owl’ -retrycount 0 -managed
-restart_msg ’test’ -alert_msg ’testalert’ -parentservice ’Core’
2. Eseguire il programma di utilità nco_pa_status per richiamare lo stato dei
servizi nella configurazione:
$NCHOME/omnibus/bin/nco_pa_status -server TEST_PA
Dove TEST_PA è il nome dell’agent del processo.
Quando si esegue nco_pa_status, l’output visualizzerà un processo simnet2 con
uno stato DEAD, come parte della definizione del servizio Core. Il processo
simnet2 non verrà avviato automaticamente perché fa parte di un servizio e deve
essere eseguito utilizzando il programma di utilità nco_pa_start.
Esempio: Utilizzo di nco_pa_addentry per aggiungere un processo
gestito a un servizio (Windows)
1. Immettere il seguente comando per aggiungere un processo chiamato simnet2 a
un servizio Core:
″%NCHOME%″\omnibus\bin\nco_pa_addentry -server TEST_PA -process simnet2
-command ″%NCHOME%″\omnibus\probes\win32\nco_p_simnet -host owl
-retrycount 0 -managed -restart_msg ″test″ -alert_msg ″testalert″
-parentservice ″Core″
2. Eseguire il programma di utilità nco_pa_status per richiamare lo stato dei
servizi nella configurazione:
″%NCHOME%″\omnibus\bin\nco_pa_status -server TEST_PA
Dove TEST_PA è il nome dell’agent del processo.
Quando si esegue nco_pa_status, l’output visualizzerà un processo simnet2 con
uno stato DEAD, come parte della definizione del servizio Core. Il processo
simnet2 non verrà avviato automaticamente perché fa parte di un servizio e deve
essere eseguito utilizzando il programma di utilità nco_pa_start.
Riferimenti correlati
“Avvio di un servizio o di un processo (nco_pa_start)” a pagina 269
274
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Utilizzo di Netcool/OMNIbus Administrator per gestire il controllo
processi
Netcool/OMNIbus Administrator fornisce un’interfaccia visiva da cui è possibile
gestire il controllo processi. È possibile utilizzare Netcool/OMNIbus Administrator
per visualizzare e gestire agent del processo, processi e servizi sugli host Tivoli
Netcool/OMNIbus.
Ad esempio, è possibile visualizzare lo stato dei servizi che si trovano sotto il
controllo processi su un computer host, quindi avviare e arrestare i processi in quei
servizi.
È necessario collegarsi
processi. Le modifiche
possono essere salvate
sovrascritto ogni volta
a un agent del processo per poterne gestire i servizi e i
di configurazione che si apportano ai servizi e ai processi
nel file di configurazione del controllo processi, che viene
che si salva.
Nota: Non è possibile utilizzare Netcool/OMNIbus Administrator per specificare
che solo determinati host possono connettersi agli agent del processo. Per definire
questi host sicuri, è necessario aggiungere manualmente una definizione di
sicurezza al file di configurazione dell’agent del processo.
Attività correlate
“Configurazione e gestione del controllo processi dalla riga comandi” a pagina 256
“Avvio di Netcool/OMNIbus Administrator” a pagina 46
Connessione a un agent del processo
Per poter stabilire una connessione a un agent del processo utilizzando
Netcool/OMNIbus Administrator, è innanzitutto necessario assicurarsi che l’agent
del processo sia stato avviato.
È possibile avviare l’agent del processo automaticamente utilizzando gli script di
avvio forniti su UNIX oppure eseguendo l’agent del processo come servizio
Windows. È inoltre possibile avviare l’agent del processo manualmente eseguendo
il comando $NCHOME/omnibus/bin/nco_pad.
Per connettersi a un agent del processo:
1. Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
Reports.
2. Fare clic sull’icona PA. Si apre la finestra Process Agent Report. Questa finestra
visualizza tutti gli agent del processo selezionati l’ultima volta che è stata
eseguita la Import Connections Wizard.
Suggerimento: Una volta avviato Netcool/OMNIbus Administrator, è possibile
selezionare File → Import in qualsiasi momento per visualizzare le informazioni
sulle comunicazioni del nuovo server nell’Editor del server. Queste
informazioni facilitano la comunicazione tra i componenti server Tivoli
Netcool/OMNIbus come, ad esempio, gli ObjectServer, i gateway, gli agent del
processo e i server proxy.
3. Selezionare l’agent del processo a cui si desidera connettersi, quindi effettuare
una delle seguenti azioni:
v Se si esegue la connessione per la prima volta oppure si desidera immettere
informazioni di autenticazione aggiornate da utilizzare durante la
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
275
connessione, fare clic su Connect As nella barra degli strumenti. Si apre la
finestra Process Agent Security. Andare al passo 4.
v Se si desidera connettersi utilizzando le informazioni di autenticazione
specificate precedentemente, fare clic su Connect. Si apre la finestra Process
Agent Security, in cui sono visualizzati i dettagli di autenticazione specificati
precedentemente. Andare al passo 5.
4. Completare la finestra Process Agent Security nel modo seguente:
Username
Immettere il nome utente utilizzato per accedere all’agent del processo.
Su UNIX, qualsiasi utente che desidera accedere all’agent del processo
deve essere membro di un gruppo di utenti UNIX che viene identificato
con un gruppo di amministratori per questo scopo. Su Windows,
l’utente deve essere un utente valido con un account locale o di
dominio.
Password
Immettere la password utilizzata per accedere all’agent del processo.
Always use for this connection
Selezionare questa casella di spunta per indicare che il nome utente e la
password specificati devono essere salvati per essere riutilizzati
automaticamente nei successivi tentativi di connessione a questo agent
del processo. Queste impostazioni durano per la lunghezza della
sessione dell’applicazione.
Use as default
Selezionare questa casella di spunta se si desidera che i valori
specificati per il nome utente e la password vengano compilati
automaticamente alla successiva visualizzazione di questa finestra.
Queste impostazioni durano per la lunghezza della sessione
dell’applicazione.
Nota: Se si selezionano entrambe queste caselle di spunta,
l’impostazione Always use for this connection ha la precedenza.
5. Confermare o annullare l’autenticazione nel modo seguente:
OK
Fare clic su questo pulsante per verificare le credenziali per la
connessione e chiudere la finestra. Si apre il pannello Service/Process
Details. Questo pannello contiene informazioni relative ai processi e ai
servizi configurati per l’agent del processo selezionato.
Cancel
Fare clic su questo pulsante per chiudere la finestra Process Agent
Security senza il tentativo di connessione all’agent del processo. Si
ritorna alla finestra Process Agent Report.
Operazioni successive
Quando si esegue per la prima volta la connessione ad agent del processo esistenti
con Netcool/OMNIbus Administrator, i processi remoti sono visibili solo se sono
stati definiti manualmente nella configurazione dell’agent del processo locale. Per
rendere visibili i processi remoti a tutti gli agent del processo collegati, selezionare
a turno ciascun servizio o processo, fare clic sul pulsante Edit e chiudere la finestra
che viene visualizzata senza apportare alcuna modifica. Al termine di questo
processo, salvare ciascun file di configurazione.
276
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Attività correlate
“Avvio automatico degli agent del processo su UNIX” a pagina 254
“Avvio automatico degli agent del processo su Windows” a pagina 255
“Avvio manuale degli agent del processo” a pagina 247
“Avvio di Netcool/OMNIbus Administrator” a pagina 46
Visualizzazione e configurazione delle informazioni relative
allo stato per un agent del processo
È possibile visualizzare i dettagli relativi alla versione per un agent del processo al
quale si è connessi e modificare il livello di registrazione per i messaggi generati
da questo agent del processo. È anche possibile configurare l’instradamento host
aggiungendo agent del processo a un gruppo di instradamento.
Prima di iniziare
Prima di provare ad aggiungere un agent del processo a un gruppo di
instradamento, è necessario aver utilizzato l’opzione File → Import (e la Import
Connections Wizard) per importare i dettagli dell’agent del processo in
Netcool/OMNIbus Administrator.
Per visualizzare e configurare informazioni relative allo stato per un agent del
processo:
1. Se non si è connessi all’agent del processo, connettersi utilizzando
Netcool/OMNIbus Administrator. Dopo aver stabilito la connessione, per
impostazione predefinita si apre il riquadro Service/Process Details.
2. Fare clic sull’icona Info visualizzata alla sinistra di questo riquadro. Si apre il
riquadro PA Status Information.
3. Completare questo riquadro nel modo seguente:
Version
Quest’area visualizza la versione dell’agent del processo.
Nota: La versione non può essere determinata se l’agent del processo è
di una versione precedente a V7.0.1.
Debug Level
Per modificare il livello di debug per il file di log, selezionare un altro
valore da questo elenco a discesa. Fare clic sul pulsante di graduazione
a destra dell’elenco a discesa per applicare il livello di debug
selezionato alla sessione corrente.
Per salvare il livello di debug aggiornato, fare clic su Save the Process
Agent configuration nella barra degli strumenti.
Defined Hosts (UNIX)/Related Process Agents (Windows)
Quest’area visualizza un elenco di agent del processo noti a questo
agent del processo. Le informazioni vengono lette dal file di
configurazione degli agent del processo, che potrebbero differire dagli
host importati dal file delle interfacce tramite la procedura guidata
Import Connections.
È possibile utilizzare i pulsanti a destra per aggiungere host da un
elenco di host noti o per rimuoverli.
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
277
Per salvare le modifiche della definizione dell’host, fare clic su Save the
Process Agent configuration nella barra degli strumenti. Se non si
effettua il salvataggio in questo modo, le modifiche vengono perse
all’uscita.
Attività correlate
“Avvio di Netcool/OMNIbus Administrator” a pagina 46
“Connessione a un agent del processo” a pagina 275
Visualizzazione dei processi e dei servizi per un agent del
processo
È possibile utilizzare il riquadro Service/Process Details di Netcool/OMNIbus
Administrator per visualizzare dettagli dei processi e dei servizi configurati per un
agent del processo e per gestire questi processi e servizi.
Per visualizzare i processi e i servizi configurati per un agent del processo,
effettuare una delle seguenti azioni:
v Se non si è connessi all’agent del processo, connettersi utilizzando
Netcool/OMNIbus Administrator. Dopo aver stabilito la connessione, per
impostazione predefinita si apre il riquadro Service/Process Details.
v Se si è già connessi all’agent del processo, ma il riquadro Service/Process Details
non è al momento visualizzato, fare clic sull’icona Status nella finestra di
configurazione per l’agent del processo per visualizzare questo riquadro.
Risultati
Nel pannello Service/Process Details vengono mostrati i seguenti dettagli per
ciascun servizio e processo configurato:
v
v
v
v
Il nome univoco assegnato al servizio o al processo
Lo stato del servizio o del processo
L’host su cui è in esecuzione il processo; questa colonna è vuota per i servizi
L’identificativo di un processo in esecuzione; questa colonna è vuota per i
servizi e i processi che non sono attualmente in esecuzione
All’interno della colonna Name l’icona
visualizzata a sinistra di un nome
identifica la voce come servizio e l’icona
identifica la voce come processo. I
processi sono anche raggruppati in base al servizio con il quale vengono eseguiti e
i nomi dei processi vengono mostrati con il seguente formato:
service_name:process_name
Ad esempio: Core:MasterObjectServer
Nella colonna Status l’icona dello stato viene rappresentata come un cerchio e il
relativo colore indica se il servizio o il processo è in esecuzione:
v Green: Il servizio o il processo è in esecuzione.
v Blue: Il servizio è marginale. Non tutti i processi sono in esecuzione.
v Yellow: Il processo è in sospeso. Il processo è in attesa del completamento della
dipendenza temporale. Questo stato può anche indicare che l’avvio del processo
non è riuscito correttamente, indipendentemente da eventuali dipendenze del
processo.
v Gray: Il processo è inutilizzato (non in esecuzione) o il servizio è stato arrestato.
278
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
v Red: Identifica un livello dello stato di errore, che è un’indicazione che un livello
di stato non può essere richiamato dall’agent del processo.
Dal pannello Service/Process Details è possibile gestire i processi e i servizi per
l’agent del processo selezionato nei modi seguenti:
v Creare o modificare un servizio
v Creare o modificare un processo
v Eliminare un servizio o un processo selezionato
v Avviare un servizio o un processo selezionato
v Arrestare un servizio o un processo selezionato
v Copiare e incollare un servizio o un processo nello stesso agent del processo
oppure tra host dell’agent del processo
v Arrestare l’agent del processo
Eseguire un’azione esterna
Inviare un segnale ad un processo
Salvare il file di configurazione dell’agent del processo su disco
Aggiornare il contenuto del pannello (facendo clic su Refresh nella barra degli
strumenti)
Attività correlate
“Avvio di Netcool/OMNIbus Administrator” a pagina 46
“Connessione a un agent del processo” a pagina 275
v
v
v
v
Configurazione di servizi per un agent del processo
È possibile utilizzare Netcool/OMNIbus Administrator per creare, modificare,
eliminare, avviare e arrestare servizi definiti per essere eseguiti in un agent del
processo. Quando si apportano modifiche di configurazione a un servizio, è
possibile scegliere di salvare le modifiche al file di configurazione del controllo
processi.
Creazione e modifica di servizi
È possibile installare un servizio Tivoli Netcool/OMNIbus e configurarlo perché
venga avviato automaticamente o manualmente.
Per creare o modificare un servizio:
1. Svolgere una qualsiasi delle seguenti azioni da Netcool/OMNIbus
Administrator:
v Se si è connessi all’agent del processo e il riquadro Service/Process Details è
aperto, andare al passo successivo.
v Se non si è già connessi, connettersi all’agent del processo. Dopo aver
stabilito la connessione, si apre il riquadro Service/Process Details.
v Se si è connessi all’agent del processo, ma il riquadro Service/Process Details
non è al momento visualizzato, fare clic sull’icona Status nella finestra di
configurazione per l’agent del processo per visualizzare questo riquadro.
2. Per aggiungere un servizio, fare clic su New Service nella barra degli
strumenti. Per modificare un servizio, selezionare il servizio da modificare,
quindi fare clic su Edit nella barra degli strumenti.
Si apre la finestra Service Details.
3. Completare questa finestra nel modo seguente:
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
279
Name Immettere il nome del servizio. Questo nome deve essere univoco nella
rete del controllo processi. Quando si modifica un servizio, non è
possibile modificarne il nome.
Auto Start Service
Selezionare questa casella di spunta per specificare che il servizio deve
essere avviato automaticamente appena viene avviato l’agent del
processo. Deselezionare questa casella di spunta se si desidera riavviare
manualmente il servizio mediante il comando nco_pa_start.
Master Service
Selezionare questa casella di spunta per indicare che si tratta di un
servizio principale. Un servizio principale viene avviato prima di altri
servizi e viene gestito come servizio principale dal quale dipendono
altri servizi.
Se si definiscono più servizi come principali nello stesso file di
configurazione del controllo processi, i servizi principali vengono
avviati nell’ordine in cui vengono visualizzati nel file di configurazione.
Processes and their order within the configuration file
Questo elenco viene visualizzato solo quando si modifica un servizio e
mostra i processi definiti per essere eseguiti come parte del servizio.
L’ordine di visualizzazione dei processi indica il loro ordine nel file di
configurazione. È possibile utilizzare i pulsanti freccia per modificare
l’ordine dei processi.
4. Salvare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per salvare i dettagli del servizio e
chiudere la finestra. I nuovi servizi vengono aggiunti al pannello
Service/Process Details.
Suggerimento: Le modifiche di configurazione non vengono
automaticamente salvate nel file di configurazione del controllo
processi. Per aggiornare il file, fare clic su Write Process Agent Config
file nella barra degli strumenti.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
Attività correlate
“Avvio di Netcool/OMNIbus Administrator” a pagina 46
“Connessione a un agent del processo” a pagina 275
Eliminazione di un servizio
Quando si elimina un servizio, questo viene rimosso dalla configurazione del
controllo processi.
Per eliminare un servizio:
1. Svolgere una qualsiasi delle seguenti azioni da Netcool/OMNIbus
Administrator:
v Se si è connessi all’agent del processo e il riquadro Service/Process Details è
aperto, andare al passo successivo.
v Se non si è già connessi, connettersi all’agent del processo. Dopo aver
stabilito la connessione, si apre il riquadro Service/Process Details.
280
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
v Se si è connessi all’agent del processo, ma il riquadro Service/Process Details
non è al momento visualizzato, fare clic sull’icona Status nella finestra di
configurazione per l’agent del processo per visualizzare questo riquadro.
2. Selezionare il servizio che si desidera eliminare, fare clic su Delete nella barra
degli strumenti, quindi confermare l’eliminazione. Il servizio viene eliminato e
il riquadro Service/Process Details viene aggiornato.
Risultati
Suggerimento: Le modifiche di configurazione non vengono automaticamente
salvate nel file di configurazione del controllo processi. Per aggiornare il file, fare
clic su Write Process Agent Config File nella barra degli strumenti.
Attività correlate
“Avvio di Netcool/OMNIbus Administrator” a pagina 46
“Connessione a un agent del processo” a pagina 275
Avvio di un servizio
È possibile avviare solo servizi il cui stato sia ’Stopped’ (arrestato).
Per avviare un servizio:
1. Svolgere una qualsiasi delle seguenti azioni da Netcool/OMNIbus
Administrator:
v Se si è connessi all’agent del processo e il riquadro Service/Process Details è
aperto, andare al passo successivo.
v Se non si è già connessi, connettersi all’agent del processo. Dopo aver
stabilito la connessione, si apre il riquadro Service/Process Details.
v Se si è connessi all’agent del processo, ma il riquadro Service/Process Details
non è al momento visualizzato, fare clic sull’icona Status nella finestra di
configurazione per l’agent del processo per visualizzare questo riquadro.
2. Selezionare il servizio che si desidera avviare, quindi fare clic su Start nella
barra degli strumenti.
Risultati
Il servizio e i relativi processi associati vengono avviati e il riquadro
Service/Process Details viene aggiornato.
Attività correlate
“Avvio di Netcool/OMNIbus Administrator” a pagina 46
“Connessione a un agent del processo” a pagina 275
Arresto di un servizio
È possibile arrestare solo servizi il cui stato sia ’Marginal’ (marginale) o ’Running’
(in esecuzione).
Per arrestare un servizio:
1. Svolgere una qualsiasi delle seguenti azioni da Netcool/OMNIbus
Administrator:
v Se si è connessi all’agent del processo e il riquadro Service/Process Details è
aperto, andare al passo successivo.
v Se non si è già connessi, connettersi all’agent del processo. Dopo aver
stabilito la connessione, si apre il riquadro Service/Process Details.
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
281
v Se si è connessi all’agent del processo, ma il riquadro Service/Process Details
non è al momento visualizzato, fare clic sull’icona Status nella finestra di
configurazione per l’agent del processo per visualizzare questo riquadro.
2. Selezionare il servizio che si desidera arrestare, quindi fare clic su Stop
nella barra degli strumenti.
Risultati
Il servizio e i suoi processi definiti vengono arrestati e il riquadro Service/Process
Details viene aggiornato.
Attività correlate
“Avvio di Netcool/OMNIbus Administrator” a pagina 46
“Connessione a un agent del processo” a pagina 275
Configurazione dei processi
Utilizzando Netcool/OMNIbus Administrator, è possibile creare, modificare,
eliminare e arrestare processi all’interno di un servizio configurato per essere
eseguito in un agent del processo. È anche possibile inviare segnali ai processi.
Quando si apportano modifiche di configurazione a un processo, è possibile
scegliere di salvare le modifiche al file di configurazione del controllo processi.
Creazione e modifica di processi
È possibile creare un processo e configurarlo perché venga eseguito come parte di
un servizio.
Prima di iniziare
Per poter configurare i processi, è necessario che esista già almeno un servizio.
Per creare o modificare un processo:
1. Svolgere una qualsiasi delle seguenti azioni da Netcool/OMNIbus
Administrator:
v Se si è connessi all’agent del processo e il riquadro Service/Process Details è
aperto, andare al passo successivo.
v Se non si è già connessi, connettersi all’agent del processo. Dopo aver
stabilito la connessione, si apre il riquadro Service/Process Details.
v Se si è connessi all’agent del processo, ma il riquadro Service/Process Details
non è al momento visualizzato, fare clic sull’icona Status nella finestra di
configurazione per l’agent del processo per visualizzare questo riquadro.
2. Per aggiungere un processo, fare clic su New Process nella barra degli
strumenti. Per modificare un processo, selezionare il processo da modificare,
quindi fare clic su Edit nella barra degli strumenti.
Si apre la finestra Process Details.
3. Definire un nuovo processo nel modo seguente:
Name Immettere il nome del processo. Questo nome deve essere univoco per
agent del processo. Quando si modifica un processo, non è possibile
modificarne il nome.
Command
Immettere la stringa di comandi che avvia il processo, come se fosse
immessa nella riga comandi. Utilizzare il percorso completo per il
282
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
comando. Ad esempio, per configurare un ObjectServer denominato
NCOMS, con un agent del processo SFOSYS1_PA, immettere:
$NCHOME/omnibus/bin/nco_objserv -name NCOMS -pa SFOSYS1_PA
Host
Immettere il nome dell’host su cui viene eseguito il processo. Il
controllo processi risolve automaticamente il nome dell’agent del
processo, quando richiesto.
Service
Selezionare il servizio con il quale viene eseguito questo processo.
Quando si modifica un processo, non è possibile modificare il servizio.
4. Dalla scheda Process, specificare ulteriori dettagli sul processo. Completare la
scheda nel modo seguente:
Managed
Selezionare questa casella di spunta se si desidera consentire il riavvio
automatico del processo in caso di errore.
Run As ID
Immettere l’ID utente con il quale viene eseguito il processo. Questo
valore è tipicamente 0, che corrisponde al nome utente root.
Nota: Se l’agent del processo non è in esecuzione come root, questa
opzione viene ignorata e il processo viene eseguito con l’utente che sta
eseguendo l’agent del processo.
Retry Count
Specificare il numero di tentativi di riavvio da effettuare se il processo
viene chiuso nel tempo specificato dall’opzione di riga comando
-retrytime dell’agent del processo. Se è impostata su 0, non vi è alcun
limite al numero di tentativi di riavvio. Il valore predefinito è 0.
Process Type
Da questo elenco a discesa, selezionare PA Aware per rendere il processo
consapevole del controllo processi e abilitare l’utilizzo delle funzioni di
controllo, come, ad esempio, le dipendenze. Selezionare Not PA Aware
se il processo può essere gestito dal controllo processi, ma non può
utilizzare tutte le funzioni di controllo processi.
Dependency
Utilizzare questo elenco a discesa per indicare se il processo possiede
dipendenze. L’opzione selezionata qui determina il resto dei campi che
vengono visualizzati:
v Selezionare None per specificare che il processo non ha dipendenze su
nessun altro processo. Non vengono visualizzati altri campi.
v Selezionare Delay per indicare una dipendenza temporale per l’avvio
del processo. Un campo aggiuntivo intitolato Start delay viene
visualizzato per definire la dipendenza temporale.
v Selezionare Process per indicare una dipendenza da un altro
processo. Viene visualizzato un campo aggiuntivo intitolato Select
Delay from o Dependent Name per specificare un processo.
Start delay
Specificare un tempo (espresso in secondi) per l’avvio del processo.
Questo tempo viene misurato dall’inizio del servizio.
Select Delay from/Dependent Name
Utilizzare questo elenco a discesa per selezionare un altro processo che
riconosce PA da cui dipende il processo in fase di creazione o di
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
283
modifica. Il processo in fase di creazione o di modifica non verrà
avviato fino a quando il processo, dal quale dipende, non è già in
esecuzione.
5. Dalla scheda Messages, specificare i dettagli sul messaggio da inviare al syslog
di UNIX oppure al Visualizzatore eventi di Windows quando si riavvia o si
esce dal processo. Completare la scheda nel modo seguente:
Restart
Immettere il messaggio da inviare al syslog UNIX o al Visualizzatore
eventi di Windows se il processo viene riavviato. Ad esempio,
ObjectServer è stato riavviato.
Alert
Immettere il messaggio da inviare al syslog UNIX o al Visualizzatore
eventi di Windows se il processo viene chiuso. Ad esempio,
ObjectServer è stato chiuso.
Quando l’agent del processo genera un messaggio di avviso o di
riavvio, questo messaggio viene inviato al syslog o al Visualizzatore
eventi. Tivoli Netcool/OMNIbus ha un probe Syslog che può
monitorare questi messaggi e convertirli in avvisi dell’ObjectServer.
I messaggi di avvio e di ripristino vengono inviati al syslog UNIX o al
Visualizzatore eventi di Windows sotto forma di avvertenze. Il
messaggio ha il seguente formato:
HOSTNAME : ALERT_OR_RESTART_MSG : MSG
HOSTNAME è il nome dell’host che ha segnalato il problema.
ALERT_OR_RESTORE_MSG descrive il tipo di messaggio. MSG è il
testo definito nel file di configurazione per quel processo.
È possibile utilizzare le parole chiave di espansione descritte nella seguente
tabella nelle voci di riavvio e di avviso che vengono specificate nella scheda
Messages. Le parole chiave di espansione fungono da variabili e contengono
informazioni sul processo chiuso o riavviato.
Tabella 84. Parole chiave di espansione
Parola chiave di espansione
Descrizione
${NAME}
Il nome del processo
${HOST}
Il nome dell’host su cui è in esecuzione il processo.
${EUID}
L’ID utente valido con cui è in esecuzione il processo.
${COMMAND}
Il comando che definisce il processo.
6. Salvare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per salvare i dettagli del processo e
chiudere la finestra. I nuovi processi vengono aggiunti al pannello
Service/Process Details.
Suggerimento: Le modifiche di configurazione non vengono
automaticamente salvate nel file di configurazione del controllo
processi. Per aggiornare il file, fare clic su Write Process Agent Config
File nella barra degli strumenti.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza salvare le
modifiche.
284
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Attività correlate
“Avvio di Netcool/OMNIbus Administrator” a pagina 46
“Connessione a un agent del processo” a pagina 275
Riferimenti correlati
“Definizione dei processi nel file di configurazione dell’agent del processo” a
pagina 257
Eliminazione di un processo
Quando si elimina un processo, questo viene rimosso dal servizio al quale è stato
assegnato.
Per eliminare un processo:
1. Svolgere una qualsiasi delle seguenti azioni da Netcool/OMNIbus
Administrator:
v Se si è connessi all’agent del processo e il riquadro Service/Process Details è
aperto, andare al passo successivo.
v Se non si è già connessi, connettersi all’agent del processo. Dopo aver
stabilito la connessione, si apre il riquadro Service/Process Details.
v Se si è connessi all’agent del processo, ma il riquadro Service/Process Details
non è al momento visualizzato, fare clic sull’icona Status nella finestra di
configurazione per l’agent del processo per visualizzare questo riquadro.
2. Selezionare il processo che si desidera eliminare, fare clic su Delete nella barra
degli strumenti, quindi confermare l’eliminazione. Il processo viene rimosso
dalla definizione del servizio e il riquadro Service/Process Details viene
aggiornato.
Risultati
Suggerimento: Le modifiche di configurazione non vengono automaticamente
salvate nel file di configurazione del controllo processi. Per aggiornare il file, fare
clic su Write Process Agent Config File nella barra degli strumenti.
Attività correlate
“Avvio di Netcool/OMNIbus Administrator” a pagina 46
“Connessione a un agent del processo” a pagina 275
Avvio di un processo
È possibile avviare solo processi il cui stato sia ’Dead’ (non in esecuzione).
Per avviare un processo:
1. Svolgere una qualsiasi delle seguenti azioni da Netcool/OMNIbus
Administrator:
v Se si è connessi all’agent del processo e il riquadro Service/Process Details è
aperto, andare al passo successivo.
v Se non si è già connessi, connettersi all’agent del processo. Dopo aver
stabilito la connessione, si apre il riquadro Service/Process Details.
v Se si è connessi all’agent del processo, ma il riquadro Service/Process Details
non è al momento visualizzato, fare clic sull’icona Status nella finestra di
configurazione per l’agent del processo per visualizzare questo riquadro.
2. Selezionare il processo che si desidera avviare, quindi fare clic su Start nella
barra degli strumenti.
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
285
Risultati
Il processo viene avviato e il riquadro Service/Process Details viene aggiornato con
lo stato del processo, compreso l’ID processo del processo in esecuzione.
Attività correlate
“Avvio di Netcool/OMNIbus Administrator” a pagina 46
“Connessione a un agent del processo” a pagina 275
Arresto di un processo
È possibile arrestare solo processi il cui stato sia ’Pending’ (in esecuzione) o
’Running’ (in esecuzione).
Quando si arresta un processo, lo stato dei processi dipendenti rimane invariato;
se, ad esempio, si arresta un ObjectServer, i probe dipendenti da tale ObjectServer
continuano a venire eseguiti.
Per arrestare un processo:
1. Svolgere una qualsiasi delle seguenti azioni da Netcool/OMNIbus
Administrator:
v Se si è connessi all’agent del processo e il riquadro Service/Process Details è
aperto, andare al passo successivo.
v Se non si è già connessi, connettersi all’agent del processo. Dopo aver
stabilito la connessione, si apre il riquadro Service/Process Details.
v Se si è connessi all’agent del processo, ma il riquadro Service/Process Details
non è al momento visualizzato, fare clic sull’icona Status nella finestra di
configurazione per l’agent del processo per visualizzare questo riquadro.
2. Selezionare il processo che si desidera arrestare, quindi fare clic su Stop
nella barra degli strumenti.
Risultati
Il processo viene arrestato e il riquadro Service/Process Details viene aggiornato.
Attività correlate
“Avvio di Netcool/OMNIbus Administrator” a pagina 46
“Connessione a un agent del processo” a pagina 275
Invio di segnali ai processi
È possibile utilizzare Netcool/OMNIbus Administrator per inviare un segnale
UNIX a un processo.
Ad esempio, è possibile che si desideri che un probe rilegga il relativo file delle
regole. A tale scopo, inviare un segnale SIGHUP(1) al processo del probe.
Per inviare un segnale a un processo:
1. Svolgere una qualsiasi delle seguenti azioni da Netcool/OMNIbus
Administrator:
v Se si è connessi all’agent del processo e il riquadro Service/Process Details è
aperto, andare al passo successivo.
v Se non si è già connessi, connettersi all’agent del processo. Dopo aver
stabilito la connessione, si apre il riquadro Service/Process Details.
286
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
v Se si è connessi all’agent del processo, ma il riquadro Service/Process Details
non è al momento visualizzato, fare clic sull’icona Status nella finestra di
configurazione per l’agent del processo per visualizzare questo riquadro.
2. Selezionare il processo al quale si desidera inviare un segnale, quindi fare clic
su Send Signal nella barra degli strumenti. Si apre la finestra Send Signal.
3. Completare questa finestra nel modo seguente:
Process Name
Selezionare il processo al quale deve essere inviato il segnale.
Signal Selezionare il segnale che si desidera inviare. I segnali validi includono:
v SIGHUP(1): Segnale di disconnessione per arrestare e riavviare un
processo
v SIGINT(2): Segnale di interruzione
v SIGTERM(15): Segnale di terminazione
Su Windows, i segnali SIGINT(2) e SIGTERM(15) sono supportati solo su
processi Tivoli Netcool/OMNIbus; ad esempio, gli ObjectServer, i
server proxy e i probe. È possibile, in alternativa, utilizzare altri metodi
disponibili per l’arresto dei processi. Quando un probe è in esecuzione
nel controllo processi, il segnale SIGHUP(1) può essere utilizzato per fare
in modo che il probe rilegga il proprio file delle regole.
4. Confermare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per chiudere la finestra e inviare il segnale
al processo selezionato.
Apply Fare clic su questo pulsante per inviare il segnale al processo
selezionato e mantenere la finestra aperta.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza inviare un
segnale.
Attività correlate
“Avvio di Netcool/OMNIbus Administrator” a pagina 46
“Connessione a un agent del processo” a pagina 275
Come copiare e incollare un servizio o un processo tra host
dell’agent del processo
È possibile copiare e incollare un servizio selezionato e i relativi processi oppure
un processo selezionato, in un agent del processo oppure tra due agent del
processo.
Per copiare e incollare un servizio o un processo:
1. Svolgere una qualsiasi delle seguenti azioni da Netcool/OMNIbus
Administrator:
v Se si è connessi all’agent del processo e il riquadro Service/Process Details è
aperto, andare al passo successivo.
v Se non si è già connessi, connettersi all’agent del processo. Dopo aver
stabilito la connessione, si apre il riquadro Service/Process Details.
v Se si è connessi all’agent del processo, ma il riquadro Service/Process Details
non è al momento visualizzato, fare clic sull’icona Status nella finestra di
configurazione per l’agent del processo per visualizzare questo riquadro.
2. Dal riquadro Service/Process Details dell’agent del processo da cui si desidera
copiare un servizio o un processo, selezionare il servizio o il processo da
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
287
copiare, quindi fare clic su Copy nella barra degli strumenti. Il processo
selezionato o il servizio selezionato e i relativi processi, vengono copiati negli
Appunti.
3. Per incollare il contenuto copiato negli Appunti all’interno dello stesso agent
del processo, fare clic su Paste nella barra degli strumenti del riquadro
Service/Process Details corrente.
Per incollare il contenuto copiato negli Appunti in un altro agent del processo
connesso, accedere al riquadro Service/Process Details relativo all’agent del
processo pertinente, quindi fare clic su Paste nella barra degli strumenti.
4. Se si è copiato un processo, si apre il riquadro Process Details. Dal momento
che i nomi dei processi devono essere univoci per ciascun agent del processo,
rinominarli se necessario e apportare tutte le altre modifiche richieste. Fare clic
su OK per chiudere questa finestra e incollare i dettagli del processo nel
riquadro Service/Process Details. Per annullare l’operazione, fare clic su
Cancel.
5. Se si è copiato un servizio, viene visualizzata la procedura guidata Process
Agent Consistency Checker. Dal momento che i nomi dei servizi devono essere
univoci nella rete per il controllo processi e i nomi dei processi devono essere
univoci per ciascun agent del processo, è necessario rinominarli. Effettuare le
seguenti azioni:
a. Fare clic su Next per passare alla pagina successiva e modificare i dettagli
del servizio o del processo in base alle specifiche esigenze. È possibile
specificare per il servizio un nuovo nome sovrascrivendo il nome del
servizio. Per modificare i dettagli di ciascun processo, fare doppio clic sulla
voce relativa al processo per visualizzare la finestra Process Details, quindi
apportare le modifiche desiderate. Inoltre, è possibile specificare se
includere o escludere un processo nell’azione incolla. Su UNIX, fare clic
nella cella Include in Paste per passare dall’opzione true all’opzione false e
viceversa. Su Windows, fare clic con il tasto destro del mouse sulla voce
relativa al processo, quindi selezionare o deselezionare l’opzione Include in
Paste del menu pop up.
b. Fare clic su Next Per visualizzare un riepilogo del servizio e dei processi da
incollare.
c. Fare clic su Finish per chiudere la procedura guidata e incollare i dettagli
nel riquadro Service/Process Details. Per annullare l’operazione, fare clic su
Cancel.
Attività correlate
“Avvio di Netcool/OMNIbus Administrator” a pagina 46
“Connessione a un agent del processo” a pagina 275
Esecuzione di un’azione esterna
È possibile utilizzare Netcool/OMNIbus Administrator per eseguire un comando
su un host.
Per eseguire un’azione esterna:
1. Svolgere una qualsiasi delle seguenti azioni da Netcool/OMNIbus
Administrator:
v Se si è connessi all’agent del processo e il riquadro Service/Process Details è
aperto, andare al passo successivo.
v Se non si è già connessi, connettersi all’agent del processo. Dopo aver
stabilito la connessione, si apre il riquadro Service/Process Details.
288
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
v Se si è connessi all’agent del processo, ma il riquadro Service/Process Details
non è al momento visualizzato, fare clic sull’icona Status nella finestra di
configurazione per l’agent del processo per visualizzare questo riquadro.
2. Per specificare i dettagli del comando, fare clic su Run External Action nella
barra degli strumenti. Si apre la finestra External Action Details.
3. Completare questa finestra nel modo seguente:
Command
Immettere un comando valido che si desidera eseguire su un host.
Host Selezionare l’host su cui eseguire il comando.
4. Confermare o annullare le modifiche nel modo seguente:
OK
Fare clic su questo pulsante per chiudere la finestra e eseguire il
comando.
Cancel
Fare clic su questo pulsante per chiudere la finestra senza eseguire il
comando.
Attività correlate
“Avvio di Netcool/OMNIbus Administrator” a pagina 46
“Connessione a un agent del processo” a pagina 275
Arresto di un agent del processo
È possibile arrestare un agent del processo e tutti i suoi processi gestiti; oppure è
possibile arrestare un agent del processo e lasciare i suoi processi in esecuzione.
Per arrestare un agent del processo:
1. Svolgere una qualsiasi delle seguenti azioni da Netcool/OMNIbus
Administrator:
v Se si è connessi all’agent del processo e il riquadro Service/Process Details è
aperto, andare al passo successivo.
v Se si è connessi all’agent del processo, ma il riquadro Service/Process Details
non è al momento visualizzato, fare clic sull’icona Status nella finestra di
configurazione per l’agent del processo per visualizzare questo riquadro.
nella barra degli strumenti.
2. Fare clic su Stop the Process Agent
3. Quando richiesto, scegliere un’opzione per indicare se si desidera arrestare
l’agent del processo e tutti i suoi processi gestiti, oppure arrestare il solo agent
del processo. Fare clic su OK.
Risultati
L’agent del processo e, gli eventuali processi gestiti, vengono arrestati.
Utilizzo del controllo processi per eseguire procedure esterne nelle
automazioni
Il sistema per il controllo processi esegue procedure esterne che vengono
specificate nelle automazioni. Le procedure esterne vengono eseguite su un host
locale o remoto.
Un’automazione non esegue direttamente programmi. Di fatto, invia una richiesta
a un agent del processo. Se necessario, l’agent del processo inoltra la richiesta
Capitolo 6. Utilizzo del controllo processi per gestire processi e procedure esterne
289
all’agent del processo che è in esecuzione sull’host specificato. Successivamente,
l’agent del processo remoto esegue il programma richiesto.
Le procedure esterne possono essere trasmesse tra ambienti di sistemi operativi
diversi e agent del processo in un determinato sistema operativo possono eseguire
automazioni inviate da agent del processo che si trovano in un altro sistema.
Quando si esegue l’agent del processo dalla riga comandi su UNIX o Windows, la
directory di lavoro per tutti i processi child è la directory da cui è stato avviato
l’agent del processo.
Quando si esegue l’agent del processo come daemon UNIX, la directory di lavoro
per tutti i processi child è $NCHOME/omnibus.
Su Windows, la directory predefinita per un agent del processo in esecuzione come
servizio Windows è %NCHOME%\omnibus\log. Questa directory è anche la directory di
lavoro predefinita di qualsiasi processo child creato dall’agent del processo.
Suggerimento: Durante l’esecuzione di procedure esterne, le proprietà
ObjectServer PA.Username e PA.Password devono essere impostate su una
combinazione valida di nome utente e password nel file delle proprietà
dell’ObjectServer, per una corretta autenticazione. Inoltre, la proprietà ObjectServer
PA.Name deve essere impostata sul nome dell’agent del processo che
l’ObjectServer utilizza per eseguire automazioni esterne. Queste impostazioni
assicurano il buon esito della connessione all’agent del processo e dell’esecuzione
della procedura esterna.
Riferimenti correlati
“Proprietà e opzioni della riga comandi dell’ObjectServer” a pagina 3
290
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Capitolo 7. Ottimizzazione delle prestazioni
Le prestazioni di Tivoli Netcool/OMNIbus possono essere misurate in termini di
tempo di risposta, di resa e di disponibilità.
Su queste metriche delle prestazioni influiscono diversi fattori, che includono:
v Il numero di eventi, inclusi dettagli e journal, nell’ObjectServer
Questo numero incide direttamente sul volume di dati che vengono trasferiti
durante le operazioni di risincronizzazione e sul numero di righe che occorre
sottoporre a scansione durante le query SQL di client e trigger.
v Il volume di eventi che entrano nel sistema da probe o gateway di entrata
v Il volume di eventi che fuoriescono dal sistema da gateway di uscita
v Il numero di client di visualizzazione desktop e Web GUI simultanei e il numero
di altri client connessi che concorrono tra loro per ottenere il tempo
dell’ObjectServer
v Il numero e la complessità di filtri di Web GUI e desktop, nonché il numero di
connessioni e la complessità delle azioni nelle politiche che vengono inoltrate da
client Netcool/Impact, laddove applicabile
v L’efficienza delle automazioni ObjectServer personalizzate e se sottopongono
l’ObjectServer a inutili carichi di lavoro
v Le impostazioni di granularità dell’ObjectServer (ossia la frequenza con la quale
invia broadcast IDUC ai client)
v La configurazione del sistema e dell’hardware
Per ottenere un livello delle prestazioni ottimale per l’ObjectServer, è possibile
monitorare il numero e le prestazioni dei client che si connettono, valutare
l’efficienza delle automazioni dell’ObjectServer e progettare indici efficienti per
supportare le query SQL. Considerare, inoltre, l’uso di un’architettura a più livelli
per supportare l’elevata disponibilità dell’istallazione di Tivoli Netcool/OMNIbus.
Migliori pratiche per l’ottimizzazione delle prestazioni
Utilizzare le linee guida riportate di seguito per configurare il sistema Tivoli
Netcool/OMNIbus in modo da garantire un livello di prestazioni ottimale.
Completare i singoli passi per poter identificare e risolvere le modifiche che hanno
influito negativamente sulle prestazioni e per poter ottimizzare le prestazioni.
Eseguire l’ObjectServer con la creazione profili abilitata
Utilizzare i profili per calcolare la quantità di tempo impiegato nell’esecuzione di
query SQL sull’ObjectServer e per identificare quali connessioni client utilizzano
una quantità eccessiva di risorse.
Per abilitare la creazione profili sull’ObjectServer:
1. Assicurarsi che la proprietà Profile sia impostata su TRUE. È questo il valore
predefinito.
2. Utilizzare la proprietà ProfileStatsInterval per specificare un intervallo al quale
scrivere informazioni sui profili nel file di log dei profili. Se questo valore non
viene modificato, viene utilizzato l’intervallo predefinito di 60 secondi.
© Copyright IBM Corp. 1994, 2009
291
3. Assicurarsi che il gruppo trigger profiler_triggers e i relativi trigger
(profiler_group_report, profiler_report, profiler_toggle) siano abilitati per la
registrazione dei profili.
Informazioni temporali per l’esecuzione di comandi SQL da connessioni client
vengono registrate nella tabella catalog.profiles. È possibile utilizzare
Netcool/OMNIbus Administrator per visualizzare dettagli che vengono registrati
nella tabella catalog.profiles. Dalla finestra Netcool/OMNIbus Administrator,
selezionare il pulsante di menu System, quindi fare clic su Databases. È possibile
utilizzare la tabella Data View nel riquadro Databases, Tables and Columns per
visualizzare i dati di tabelle e utilizzare la scheda Column Definitions per
visualizzare informazioni dettagliate relative alle colonne nella tabella.
Vengono inoltre registrate le statistiche relative ai profili in un file di log dei profili,
$NCHOME/omnibus/log/servername_profiler_report.logn, dove servername
rappresenta il nome dell’ObjectServer ed n è un numero. Il file di log dei profili
mostra un’analisi del tempo impiegato per ciascuna connessione client e il tempo
totale impiegato dal tipo di client per ciascun periodo di granularità (così come
impostato dalla proprietà Granularity). Ciascun client mostrato nel file di log viene
identificato con un nome predefinito standard (ad esempio, GATEWAY o PROBE) e
con l’host sul quale è in esecuzione il client. I client Web GUI vengono sempre
mostrati come singola connessione, indipendentemente dal numero di client
connessi. È possibile utilizzare il file di log dei profili per analizzare il modo in cui
l’ObjectServer ha impiegato il proprio tempo durante i singoli periodi di
granularità e calcolare la percentuale di tempo utilizzato. Ad esempio, se il periodo
di granularità è impostato su 60 secondi e il tempo impiegato per tutte le
connessioni durante un determinato periodo è stato 30 secondi, è possibile
calcolare che l’ObjectServer ha utilizzato il 50% del proprio tempo disponibile a
eseguire comandi SQL ricevuti da connessioni client. Un esempio di output
registrato in un file di log dei profili per un periodo di granularità è il seguente:
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
17:39:46
17:39:46
17:39:46
17:39:46
17:39:46
17:39:46
17:39:46
17:39:46
17:39:46
17:39:46
17:39:46
17:39:46
17:39:46
17:39:46
17:39:46
17:39:46
17:39:46
17:39:46
17:39:46
17:39:46
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
Individual user profiles:
'Administrator' (uid = 0) time on adminhost: 0.000000s
'isql' (uid = 0) time on omnihost1.ibm.com: 3.770000s
'PROBE' (uid = 0) time on probehost.ibm.com: 5.010000s
'e@c0B4D@c0142:11.0' (uid = 0) time on omnihost1.ibm.com: 10.010000s
'c@xxxxx@xxxxx:11.0' (uid = 45) time on omnihost1.ibm.com: 0.000000s
'e@c0B4D@c0142:11.0' (uid = 45) time on omnihost1.ibm.com: 9.870000s
'c@xxxxx@xxxxx:11.0' (uid = 55) time on omnihost1.ibm.com: 0.000000s
'e@c0B4D@c0142:11.0' (uid = 55) time on omnihost1.ibm.com: 6.020000s
'GATEWAY' (uid = 0) time on omnihost1.ibm.com: 0.270000s
'GATEWAY' (uid = 0) time on omnihost1.ibm.com: 0.000000s
'PROBE' (uid = 0) time on omnihost1.ibm.com: 3.010000s
Grouped user profiles:
Execution time for all connections whose application name is 'PROBE': 8.020000s
Execution time for all connections whose application name is 'GATEWAY': 0.270000s
Execution time for all connections whose application name is 'c@xxxxx@xxxxx:11.0': 0.000000s
Execution time for all connections whose application name is 'e@c0B4D@c0142:11.0': 25.93000s
Execution time for all connections whose application name is 'isql': 3.77000s
Execution time for all connections whose application name is 'Administrator': 0.000000s
Total time in the report period (59.275782s): 29.980000s
I numeri delle righe inclusi in questo output consentono di descrivere le voci:
v Riga [1]: introduce un elenco di singoli client che sono connessi all’ObjectServer.
v Riga [2]: mostra il nome dell’applicazione per il client connesso (Administrator),
l’utente associato per quel client (ID utente 0), il computer host (adminhost) e la
quantità di tempo che il client ha utilizzato nell’ultimo periodo di creazione
profili (0.000000s).
v Riga [13]: introduce un elenco che mostra il tempo aggregato per tutti i client
dello stesso tipo.
292
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
v Riga [14]: mostra che due probe connessi hanno utilizzato un tempo combinato
di 8,02 secondi.
v Riga [17]: mostra che gli elenchi eventi hanno utilizzato 25 secondi. Esaminare i
singoli tempi per stabilire quale elenco eventi ha utilizzato più tempo.
v Riga [20]: mostra la riga di riepilogo per il periodo di granularità. Questa riga
mostra la quantità di tempo (in secondi) trascorso dall’ultima volta in cui sono
state riportate informazioni di profilo, solitamente 60 secondi. Il periodo di
creazione profili potrebbe incrementare se l’ObjectServer è troppo occupato a
riportare il tempo di creazione profili. La riga mostra anche il tempo totale in
secondi utilizzato da tutti i client nell’ultimo periodo di creazione profili.
Analizzare le statistiche relative alla creazione profili nel file di log e nella tabella
di database per identificare quali client utilizzano gran parte del tempo e perché:
v Determinare se tutte le connessioni client sono necessarie ed eliminare quelle
ridondanti; ad esempio, gli elenchi eventi che vengono lasciati connessi dagli
operatori al termine della giornata lavorativa.
v Se un client di Web GUI o un elenco eventi desktop utilizza molto tempo,
concentrare l’attenzione sui filtri utilizzati da quel client. Analizzare questi filtri
sia per il numero che per la complessità delle singole query con l’obiettivo di
renderle più efficienti.
v Se il client è un probe, un peggioramento delle prestazioni potrebbe essere
dovuto a file delle regole non scritti correttamente che permettono l’inoltro di
eventi non necessari all’ObjectServer, alla quantità di dettagli inviati per singolo
evento oppure a un flusso abnorme di eventi.
v Incrementare il periodo di granularità dell’ObjectServer per ridurre gli effetti di
carichi client pesanti. Questa azione rallenta la velocità con la quale
l’ObjectServer invia broadcast IDUC ai client e può migliorare le prestazioni del
sistema. Tuttavia, gli eventi impiegheranno più tempo a raggiungere i client,
specialmente se l’ObjectServer fa parte di un’architettura a più livelli.
Raccogliere informazioni statistiche sui trigger
Per raccogliere statistiche sui trigger:
1. Assicurarsi che la proprietà Auto.Enabled dell’ObjectServer sia impostata su
TRUE. Questa è l’impostazione predefinita e viene utilizzata per abilitare il
sistema di automazione.
2. Utilizzare la proprietà Auto.StatsInterval per controllare la frequenza con la
quale il sistema di automazione raccoglie e memorizza informazioni statistiche
nella tabella catalog.trigger_stats. Se questo valore non viene modificato, viene
utilizzato l’intervallo predefinito di 60 secondi.
3. Assicurarsi che il gruppo trigger trigger_stat_reports e il trigger
trigger_stats_report siano abilitati.
Informazioni temporali sui trigger, tra cui il numero di volte in cui il trigger è stato
generato e il numero di volte in cui il trigger è stato attivato, vengono salvate nella
tabella catalog.trigger_stats. È possibile utilizzare Netcool/OMNIbus Administrator
per visualizzare dettagli che vengono registrati nella tabella catalog.trigger_stats.
Dalla finestra Netcool/OMNIbus Administrator, selezionare il pulsante di menu
System, quindi fare clic su Databases. È possibile utilizzare la tabella Data View
nel riquadro Databases, Tables and Columns per visualizzare i dati di tabelle e
utilizzare la scheda Column Definitions per visualizzare informazioni dettagliate
relative alle colonne nella tabella.
Capitolo 7. Ottimizzazione delle prestazioni
293
Vengono inoltre registrate statistiche dei trigger nel file $NCHOME/omnibus/log/
servername_trigger_stats.logn, dove servername rappresenta il nome
dell’ObjectServer ed n è un numero. Il file di log delle statistiche relative ai trigger
mostra la quantità di tempo che ciascun trigger ha utilizzato nell’ultimo periodo di
creazione profili. È possibile utilizzare questo file di log per il debug di
automazioni e per determinare quali trigger sono lenti a causa di query SQL dai
tempi di esecuzione lunghi. Un esempio di output registrato in un file di log delle
statistiche dei trigger è il seguente:
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]
[39]
[40]
[41]
[42]
[43]
[44]
[45]
[46]
[47]
[48]
[49]
[50]
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Mon
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
12
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
18:03:56
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
2009:
Trigger Profile Report
Trigger Group 'compatibility_triggers'
Trigger Group 'system_watch'
Trigger time for 'system_watch_shutdown': 0.000000s
Trigger time for 'system_watch_startup': 0.000000s
Trigger Group 'sae'
Trigger time for 'update_service_affecting_events': 0.006790s
Trigger Group 'default_triggers'
Trigger time for 'deduplication': 0.341918s
Trigger time for 'deduplication_eval': 0.092659s
Trigger time for 'service_update': 0.000000s
Trigger time for 'clean_journal_table': 0.000172s
Trigger time for 'service_insert': 0.000000s
Trigger time for 'service_reinsert': 0.000000s
Trigger time for 'clean_details_table': 0.000083s
Trigger time for 'state_change': 0.075508s
Trigger time for 'deduplication_copy': 0.022087s
Trigger time for 'new_row': 0.002637s
Trigger time for 'deduplicate_details': 0.000000s
Trigger Group 'connection_watch'
Trigger time for 'connection_watch_connect': 0.000000s
Trigger time for 'connection_watch_disconnect': 0.000000s
Trigger Group 'primary_only'
Trigger time for 'generic_clear': 5.879707s
Trigger time for 'expire': 0.008233s
Trigger time for 'delete_clears': 0.007219s
Trigger time for 'enrich_and_correlate': 23.007219s
Trigger Group 'security_watch'
Trigger time for 'disable_user': 0.000000s
Trigger time for 'reset_user': 0.000000s
Trigger time for 'security_watch_security_failure': 0.000000s
Trigger Group 'profiler_triggers'
Trigger time for 'profiler_group_report': 0.065094s
Trigger time for 'profiler_report': 0.087705s
Trigger time for 'profiler_toggle': 0.000000s
Trigger Group 'trigger_stat_reports'
Trigger time for 'trigger_stats_report': 0.198813s
Trigger Group 'iduc_triggers'
Trigger time for 'disconnect_iduc_missed': 0.000000s
Trigger time for 'iduc_stats_update': 0.000949s
Trigger time for 'iduc_messages_tblclean': 0.000089s
Trigger time for 'deduplicate_iduc_stats': 0.000000s
Trigger time for 'iduc_stats_insert': 0.000000s
Trigger Group 'automatic_backup_system'
Trigger time for 'backup_succeeded': 0.000000s
Trigger time for 'backup_failed': 0.000000s
Trigger time for 'backup_state_integrity': 0.000000s
Trigger Group 'gateway_triggers'
Trigger time for 'resync_finished': 0.000000s
Time for all triggers in report period (60s): 29.789663s
I numeri delle righe inclusi in questo output consentono di descrivere le voci:
v Riga [1]: indica l’inizio del report e mostra la data/ora in cui è stato prodotto il
report.
v Riga [2]: mostra che il report è suddiviso per gruppi trigger. In questo caso, il
gruppo trigger compatibility_triggers non contiene nessun trigger abilitato.
v Riga [3]: mostra system_watch come primo gruppo trigger che contiene trigger
abilitati.
v Riga [4]: mostra il nome del trigger e la quantità di tempo (in secondi) utilizzata
dal trigger nell’ultimo periodo di creazione profili.
294
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
v Riga [27]: indica una eccessiva quantità di tempo per il trigger. Se si tratta di una
ricorrenza regolare, è necessario indagare ulteriormente sul trigger. Chiedersi, ad
esempio, se ci sono scansioni di tabella in un trigger di database, se si utilizzano
scansioni nidificate, se è possibile utilizzare un indice per ridurre le scansioni o,
infine, se il tempo è correlato direttamente al numero di eventi che il sistema
deve gestire.
v Riga [50]: mostra la riga di riepilogo come ultima voce del report. Questa riga
mostra il tempo in secondi trascorso da quando è stato eseguito l’ultimo report e
la quantità di tempo totale utilizzata dai trigger nel periodo di creazione report.
In questo esempio, 29 secondi su 60 è una percentuale elevata, quindi è
necessario indagare oltre per determinare la causa, soprattutto se questo valore è
una ricorrenza regolare.
Analizzare le statistiche di trigger nel file di log e la tabella di database per
determinare se un possibile carico di lavoro sta pregiudicando le prestazioni:
v Se si identifica un trigger che utilizza la maggior parte del periodo di
granularità, investigare sulle cause.
v Esaminare le automazioni ObjectServer personalizzate per valutarne l’efficienza e
per ridurre il carico di lavoro sull’ObjectServer.
Nota: Quando si risolvono problemi delle prestazioni, come prima cosa esaminare
il file di log dei profili e il file di log delle statistiche del trigger. Secondo una
regola generale, se il tempo combinato totale per entrambi i client e i trigger
supera costantemente i 60 secondi (il periodo di granularità predefinito), è
necessario intraprendere un’azione correttiva. Le varie metriche del sistema
operativo possono essere utili per stabilire se un sistema è sottoposto a stress. Le
metriche chiave sono l’utilizzo della CPU e la dimensione dei processi di Tivoli
Netcool/OMNIbus. In genere, se l’ObjectServer consuma costantemente più
dell’80% di una CPU, l’ObjectServer potrebbe sovraccaricarsi.
Esaminare e correggere l’architettura del sistema
Utilizzare le personalizzazioni a più livelli fornite con Tivoli Netcool/OMNIbus
per distribuire l’installazione in un’architettura a uno, a due o a tre livelli in cui in
componenti si trovano in livelli di raccolta, di aggregazione e di visualizzazione. È
necessario impostare almeno una coppia virtuale di ObjectServer nel livello di
aggregazione, quindi aggiungere i componenti di raccolta o di visualizzazione, in
base alle esigenze.
Se il traffico dei probe in entrata causa problemi, si consiglia di implementare un
livello di raccolta (qualora non fosse già presente) con ObjectServer di raccolta
dedicati alla gestione degli eventi in entrata prima di trasmetterli al livello di
aggregazione.
Se il traffico del client di visualizzazione causa problemi, ad esempio tempi di
risposta lunghi per gli utenti, si consiglia di implementare un livello di
visualizzazione (qualora non fosse già presente) con ObjectServer di
visualizzazione dedicati alla gestione delle richieste dei client.
Se entrambi il traffico dei probe in entrata e il traffico dei client di visualizzazione
causano problemi, si consiglia di implementare l’architettura a tre livelli con un
livello di raccolta, un livello di aggregazione e un livello di visualizzazione.
Inoltre, configurare Tivoli Netcool/OMNIbus per l’elevata disponibilità allo scopo
di ridurre il tempo di risincronizzazione tra la coppia di failover di ObjectServer,
Capitolo 7. Ottimizzazione delle prestazioni
295
ridurre al minimo la perdita di eventi e migliorare l’integrità dei dati.
Esaminare e correggere i file di configurazione del probe
Esaminare attentamente le impostazioni del file delle regole e del file delle
proprietà del probe per accertarsi che non stiano causando inefficienze
all’elaborazione degli eventi. In generale, non rendere complessi i file di
configurazione. Se si prevede un volume di eventi elevato, si prenda in
considerazione l’uso di più probe per raccogliere gli eventi in entrata: in tal modo,
è possibile ridurre al minimo il rallentamento dei probe e gli eventi scartati.
Configurare il rilevamneto di flussi abnormi di eventi
Configurare i probe per rilevare una condizione di flusso abnorme di eventi
oppure altre quantità anomale di eventi, e per eseguire azioni correttive. File delle
regole di esempio sono disponibili nella directory $NCHOME/omnibus/extensions/
eventflood, che è possibile utilizzare per questa configurazione.
Gestire il volume di informazioni nella tabella alerts.details
Quando un volume elevato di informazioni di avviso viene memorizzato nella
tabella alerts.details, le prestazioni dell’ObjectServer subiscono un peggioramento
significativo. Utilizzare le seguenti linee guida per gestire il volume di
informazioni memorizzate in questa tabella.
v Verificare che l’automazione clean_details_table sia abilitata su entrambi gli
ObjectServer, primario e di backup. Tale automazione esegue operazioni di
pulizia ordinarie sulla tabella alerts.details ed elimina eventuali voci non trovate
nella tabella alerts.status.
v Evitare di utilizzare details($*) in file di regole probe, per aggiungere tutte le
informazioni di avviso alla tabella alerts.details. Per ciascun avviso nella tabella
alerts.status, è possibile aggiungere più righe alla tabella alerts.details poiché il
comando details($*) nel file delle regole registra ciascun token come una riga.
Dopo aver utilizzato details($*) per lunghi periodi di tempo, le tabelle
dell’ObjectServer diventano molto grandi e le prestazioni dell’ObjectServer ne
risentono. Utilizzare details($*) soltanto quando si esegue il debug o la
scrittura di file delle regole.
Se è necessario aggiungere ulteriori informazioni per l’avviso, utilizzare
l’istruzione details per aggiungere specifici elementi oppure utilizzare
un’espressione regolare per estrarre tali elementi dai dettagli. Ad esempio,
details($a,$b) aggiunge gli elementi $a e $b alla tabella alerts.details.
Si noti inoltre che ciascuna voce details richiede un’istruzione INSERT separata,
quindi per un evento con 20 voci details, verranno effettuati 21 inserimenti
nell’ObjectServer. Tuttavia, un evento senza dettagli sarà un singolo inserimento.
v Dall’interfaccia interattiva SQL, utilizzare il comando DELETE SQL per
cancellare tutti i record nella tabella alerts.details. Ad esempio:
delete from alerts.details;
Nota: L’eliminazione manuale di dati dalla tabella alerts.details è una soluzione
temporanea, poiché il numero di dettagli aumenterà di nuovo e in maniera
significativa qualora non si seguano le prime due linee guida. Anziché utilizzare
alerts.details, si prenda in considerazione la colonna ExtendedAttr con la
funzione del file delle regole nvp_add e le funzioni SQL nvp_get o nvp_set SQL
per memorizzare i campi per i quali sono stati inseriti dettagli.
296
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Utilizzare un agent di monitoraggio e gestire risorse di Tivoli
Netcool/OMNIbus
Un agent IBM Tivoli Monitoring è disponibile per monitorare le condizioni e le
prestazioni di Tivoli Netcool/OMNIbus, i trigger di automazione, la distribuzione
e l’attività degli eventi. Questo agent di monitoraggio include una serie di
automazioni che aggiungono ulteriore strumentazione all’ObjectServer.
IBM Tivoli Monitoring per l’agent Tivoli Netcool/OMNIbus è disponibile per il
download come parte del pacchetto di installazione di base di Tivoli
Netcool/OMNIbus. Anche il software IBM Tivoli Monitoring prerequisito è
disponibile per il download.
Per informazioni sull’installazione e sulla configurazione dell’agent di
monitoraggio, andare al centro informazioni di IBM Tivoli Network Management
all’indirizzo http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp.
Dal riquadro di navigazione sulla sinistra, individuare ed espandere il nodo della
versione di Tivoli Netcool/OMNIbus pertinente, quindi andare al nodo IBM Tivoli
Monitoring for Tivoli Netcool/OMNIbus. È inoltre disponibile una pubblicazione PDF
nel nodo Serie di documentazione PDF.
Dopo aver configurato l’agent di monitoraggio, monitorare le risorse di sistema ed
eseguire eventuali azioni correttive che sono necessarie per migliorare le
prestazioni o la disponibilità.
Esaminare e correggere le query SQL, quindi creare una
selezione di indici efficienti e ben progettati
Leggere le linee guida fornite per le query SQL e la creazione di indici.
È utile comprendere in che modo le query SQL vengono ottimizzate in modo da
creare efficaci query SQL. Esaminare le query SQL esistenti e modificarle per
ottenere benefici dall’ottimizzazione e dall’indicizzazione.
Durante la progettazione e la creazione di indici, è utile comprendere anche le
caratteristiche delle tabelle e delle colonne di database ObjectServer per poter
stabilire quali colonne indicizzate potrebbero contribuire al miglioramento delle
prestazioni. I confronti di valori numerici interi sono più rapidi dei confronti di
stringhe; pertanto, se i dati evento contengono stringhe che sono costanti, si prenda
in considerazione l’uso di valori numerici interi per rappresentare le stringhe nei
file delle regole, nelle automazioni e nei filtri, quindi utilizzare le conversioni per
visualizzare le stringhe agli utenti. Ad esempio, la colonna Class nell’ObjectServer
è un tipo di dati integer, ma viene visualizzata come stringa nell’elenco eventi. È
possibile effettuare le seguenti azioni per trasmettere i dati come integer, che
vengono poi visualizzati come stringhe:
v Modificare i file delle regole dei probe per impostare valori integer che si
associano alle stringhe corrispondenti.
v Rivedere le automazioni (e le politiche di Netcool/Impact se applicabile) per
utilizzare valori integer.
v Rivedere i filtri per utilizzare valori numerici interi nelle clausole WHERE.
v Aggiungere conversioni che associano i valori numerici interi ai valori stringa
che verranno visualizzati per gli utenti.
Capitolo 7. Ottimizzazione delle prestazioni
297
È possibile utilizzare il comando SQL CREATE INDEX per creare indici e il
comando DROP INDEX per eliminare indici ridondanti. I dettagli sugli indici che
si creano vengono memorizzati nella tabella catalog.indexes.
Dopo aver rivisto le query SQL e creato gli indici, impostare temporaneamente la
proprietà MessageLevel su debug in modo che il tempo di esecuzione delle
singole query e i dettagli dell’indicizzazione vengano registrati. Attendere il tempo
necessario per il completamento della normale attività di elaborazione.
Esaminare il file di log dell’ObjectServer $NCHOME/omnibus/log/server_name.log
per:
v Determinare quali query SQL hanno influito negativamente sulle prestazioni;
verificare quali query hanno richiesto tempi di esecuzione troppo lunghi e quali,
invece, sono state eseguite ripetutamente.
v Determinare quali indici sono stati utilizzati.
v Analizzare i tempi di risposta per le query SQL che vengono utilizzate di
frequente e valutare se i vantaggi ottenuti sono stati significativi o marginali.
Nota: L’impostazione della registrazione dell’ObjectServer sulla modalità di debug
può essere eseguita senza portare l’ObjectServer non in linea. Questa impostazione
può influire negativamente sulle prestazioni, quindi è necessario disattivare la
registrazione del debug dopo aver raccolto i dati.
Tenere traccia dell’andamento delle prestazioni a intervalli
regolari
Con il passare del tempo, diversi fattori potrebbero influire sulle prestazioni
dell’ObjectServer. Stabilire una baseline delle prestazioni e monitorare
periodicamente le prestazioni per confrontare le metriche raccolte con quelle
raccolte precedentemente. Ricercare differenze significative rispetto alla baseline e
ottimizzare le prestazioni in base alle esigenze.
Concetti correlati
“Indici” a pagina 140
Riferimenti correlati
“Proprietà e opzioni della riga comandi dell’ObjectServer” a pagina 3
“Tabella catalog.profiles” a pagina 331
“Tabella catalog.trigger_stats” a pagina 334
“Automazioni di Tivoli Netcool/OMNIbus standard” a pagina 220
“Tabella catalog.indexes” a pagina 332
“Linee guida per le query SQL” a pagina 299
“Linee guide relative all’indicizzazione” a pagina 301
“Migliori pratiche per la creazione di trigger” a pagina 305
298
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Linee guida per le query SQL
Quando una query SQL viene trasmessa all’ObjectServer, l’ottimizzazione delle
query e i piani di query vengono utilizzati per valutare i metodi disponibili per
accedere o modificare i dati e per selezionare il modo più efficace per eseguire la
query.
La valutazione determina se è possibile utilizzare le scansioni di indice o le chiavi
primarie o se, invece, è necessario eseguire una scansione di tabella completa. Se si
utilizzano scansioni di indice, gli indici vengono applicati automaticamente alle
query SQL che fanno riferimento alle colonne indicizzate.
Regole di ottimizzazione per query SQL
Una serie di regole di ottimizzazioni viene applicata alle query SQL per
determinare il modo più efficace per eseguire le query. Quando viene eseguita
l’ottimizzazione, tutte le regole di ottimizzazione vengono applicate alla condizione
nella query e, successivamente, i predicati vengono riordinati.
Le seguenti clausole WHERE vengono ottimizzate:
v La clausola WHERE nelle operazioni DML (SELECT, UPDATE, DELETE,
GROUP BY e SELECT di aggregazione)
La clausola WHERE viene concatenata al filtro limitazioni (laddove è presente),
quindi ottimizzata. Per una vista, la clausola WHERE viene concatenata alla
clausola WHERE della vista.
v La clausola WHERE di un loop FOR EACH ROW
v La clausola WHERE di un’istruzione IF THEN ELSE
v La clausola WHERE di un’istruzione EVALUATE (GROUP BY, SELECT e
SELECT di aggregazione)
I seguenti tipi di query non vengono ottimizzati:
v Una clausola HAVING di un comando GROUP BY
v Colonna in array
Suggerimento: L’ottimizzazione delle query è abilitata per impostazione
predefinita. Per esaminare i risultati dell’ottimizzazione, utilizzare la proprietà
ObjectServer MessageLevel per impostare il livello di registrazione su debug. Le
clausole ottimizzate e non ottimizzate vengono registrate nel file
$NCHOME/omnibus/log/servername.log predefinito, dove servername è il nome
dell’ObjectServer. Leggere queste informazioni per determinare quali query
vengono riscritte dall’ObjectServer perché siano più efficienti e utilizzarle per
incrementare l’efficienza delle query SQL che si scrivono.
L’ottimizzazione AND e OR e il riordino dei predicati vengono applicati alle query
SQL come mostrato di seguito.
Ottimizzazione AND
Se una clausola WHERE è composta da più predicati che sono collegati mediante
l’operatore AND, l’ottimizzazione ha luogo solo se si utilizzano la stessa colonna e
lo stesso operatore di confronto in ogni predicato e l’operatore è LIKE oppure
uguale a (=).
Il formato accettabile per l’ottimizzazione AND è:
Capitolo 7. Ottimizzazione delle prestazioni
299
where column operator expr1 AND column operator expr2 AND column operator expr3...
In questa clausola WHERE, operator è solo LIKE o =.
Questo formato viene ottimizzato in un elenco ALL nel modo seguente:
where column operator ALL (expr1, expr2, expr3, ...)
Esempio 1
Query SQL originale:
where Node like 'ibm' and Node like 'com'
Query ottimizzata:
where Node like all('ibm','com')
Esempio 2
Query SQL originale:
where Node like 'ibm' and Node like all('com','uk')
Query ottimizzata:
where Node like all('ibm','com','uk')
Esempio 3
Query SQL originale:
where Node like all('ibm','com') and Node like all('uk','london')
Query ottimizzata:
where Node like all('ibm','com','uk','london')
Ottimizzazione OR
Se una clausola WHERE è composta da più predicati che sono collegati mediante
l’operatore OR, l’ottimizzazione ha luogo solo se si utilizzano la stessa colonna e lo
stesso operatore di confronto in ogni predicato e l’operatore di confronto è LIKE
oppure uguale a (=).
Il formato accettabile per l’ottimizzazione OR è:
where column operator expr1 OR column operator expr2 OR column operator expr3...
In questa clausola WHERE, operator è solo LIKE o =.
Questo formato viene ottimizzato in un elenco ANY nel modo seguente:
where column operator ANY (expr1, expr2, expr3, ...)
Esempio 1
Query SQL originale:
where Node like 'London' or Node like 'Copenhagen'
Query ottimizzata:
where Node like any('London', 'Copenhagen')
Esempio 2
Query SQL originale:
where Severity = 1 or Severity = any(2,3)
Query ottimizzata:
where Severity = any(1,2,3)
300
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Esempio 3
Query SQL originale:
where Severity = any(1,2) or Severity = any(3,4)
Query ottimizzata:
where Severity = any(1,2,3,4)
Riordino dei predicati
L’optimizer riordina la valutazione dei predicati in una clausola WHERE in base al
costo di esecuzione loro assegnato.
Se il primo predicato (ossia il meno costoso) in un’ottimizzazione OR viene
valutato su TRUE, i predicati più costosi (ossia uno qualsiasi dei successivi) non
devono essere valutati. In maniera simile, in un’ottimizzazione AND, se il primo
predicato viene valutato su FALSE, i predicati più costosi non devono essere
valutati.
Il costo di esecuzione assegnato, dal più basso al più alto, è:
1. True/False
2.
3.
4.
5.
6.
Confronto di valori integer
Confronto di stringa
ANY/ALL/IN valore integer
ANY/ALL/IN stringa
Selezione secondaria - ossia un’istruzione SELECT nidificata
Esempio: Ottimizzazione AND (a AND b AND c)
Query SQL originale:
where Summary like 'tool' and Serial in (1, 2, 3, 4, 5) and Severity > 2
Query riordinata ottimizzata:
where Severity > 2 and Summary like 'tool' and Serial in (1, 2, 3, 4, 5)
Esempio: Ottimizzazione OR (a OR b OR c)
Query SQL originale:
where Summary like 'tool' or Serial in (1, 2, 3, 4, 5) or Severity > 2
Query riordinata ottimizzata:
where Severity > 2 or Summary like 'tool' or Serial in (1, 2, 3, 4, 5)
Linee guide relative all’indicizzazione
L’indicizzazione può influire sulle prestazioni delle query SQL. Di solito, senza
indicizzazione, una scansione di tabella di database completa viene effettuata
quando si esegue una query SQL. Utilizzare l’indicizzazione per limitare il numero
di righe da esaminare.
Tivoli Netcool/OMNIbus supporta indici hash e indici struttura ad albero. L’indice
hash supporta confronti di uguaglianza nelle query SQL. L’indice struttura ad
albero è un indice ordinato che memorizza valori di colonna in una struttura
ordinata e che consente una più ampia gamma di confronti, compreso quello di
uguaglianza, nelle query SQL. Di conseguenza, un indice struttura ad albero può
essere utilizzato in query di intervallo e in query con una clausola ORDER BY.
Capitolo 7. Ottimizzazione delle prestazioni
301
Gli indici vengono ricreati ogni volta che l’ObjectServer viene riavviato e
consumano una piccola quantità di memoria anziché spazio su disco fisico.
È possibile creare indici su tutte le tabelle ObjectServer, fatta eccezione per le
tabelle dei database di sistema, ad esempio i database di sicurezza o dei cataloghi.
Sebbene non esista alcun limite al numero di indici che è possibile creare su una
tabella, utilizzare gli indici con moderazione. Gli indici causano un sovraccarico
delle prestazioni in quanto vengono aggiornati ogni volta che si eseguono
operazioni di inserimento, aggiornamento o eliminazione nella tabella su cui si
basano. Per le tabelle come alerts.status, che vengono aggiornate di frequente, la
creazione di un numero elevato di indici può compromettere le prestazioni
complessive dell’ObjectServer. Valutare il compromesso tra l’indicizzazione per un
rapido richiamo dei dati e il calo delle prestazioni durante le operazioni di
inserimento, aggiornamento ed eliminazione.
Evitare di indicizzare tabelle che contengono solo piccole quantità di dati. Evitare,
inoltre, l’indicizzazione di colonne che contengono valori che cambiano di
frequente.
Le seguenti colonne sono considerate ottimi candidati per l’indicizzazione:
v Colonne in cui vengono eseguite di frequente ricerche o in base alle quali
vengono eseguite operazioni di ordinamento; ad esempio, le colonne che di
solito vengono utilizzate nelle clausole ORDER
v Colonne che vengono utilizzate di frequente nelle clausole WHERE che
contengono i formati dei predicati supportati per l’indicizzazione; vedere
Tabella 85 a pagina 303
v Colonne con dati che contengono pochi valori duplicati
Le colonne che vengono definite come chiavi primarie, per impostazione
predefinita vengono indicizzate in maniera univoca. Questi speciali indici impliciti
non vengono memorizzati nella tabella catalog.indexes. La colonna Serial della
tabella alerts.status viene indicizzata per impostazione predefinita.
Le limitazioni che si applicano all’indicizzazione delle colonne sono le seguenti:
v È consentito un solo indice per colonna.
v Una colonna definita come booleana non può avere un indice struttura ad
albero.
Durante l’elaborazione SQL, sia il filtro limitazioni per la tabella che la clausola
WHERE in ciascuna istruzione SELECT, UPDATE, DELETE, FOR EACH ROW ed
EVALUATE vengono esaminati per determinare se eseguire una scansione di indice
anziché una scansione di tabella completa. Una scansione di indice viene eseguita
quando uno o più predicati soddisfano le seguenti condizioni:
v Il predicato utilizza l’operatore di uguaglianza (=) nel formato ColumnName =
ConstantExpression, dove ColumnName è una colonna indicizzata.
v Il predicato utilizza l’operatore minore di (<), minore di o uguale a (<=),
maggiore di (>) oppure maggiore di o uguale (>=), purché ColumnName sia una
colonna indicizzata di tipo struttura ad albero.
v Il predicato non è collegato a un altro predicato mediante un operatore OR. Ad
esempio, se il campo Severity o Serial è indicizzato, nella seguente query SQL
non si utilizza un indice:
select Summary from alerts.status where Severity > 3 or Serial = 102;
302
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
La seguente tabella riepiloga i formati di predicato supportati per gli indici hash e
struttura ad albero.
Tabella 85. Formati di predicato per gli indici hash e per gli indici struttura ad albero
Formato del predicato
Indice hash
Indice struttura ad
albero
ColumnName = ConstantExpression
Sì
Sì
ColumnName < ConstantExpression
No
Sì
ColumnName > ConstantExpression
No
Sì
ColumnName <= ConstantExpression
No
Sì
ColumnName >= ConstantExpression
No
Sì
ColumnName %= ConstantExpression
No
No
ColumnName %< ConstantExpression
ColumnName %> ConstantExpression
ColumnName %<= ConstantExpression
ColumnName %>= ConstantExpression
Concetti correlati
“Indici” a pagina 140
Riferimenti correlati
“Esempi di utilizzo di indici con query SQL”
“Esempio di utilizzo di indici con trigger o procedure” a pagina 304
Esempi di utilizzo di indici con query SQL
Questi esempi mostrano in che modo è possibile applicare indici alle query SQL.
Esempio 1
Se il campo Severity o Serial viene indicizzato, l’indice sul campo Severity (purché
si tratti di un indice struttura ad albero) può essere utilizzato nella seguente query
SQL perché tutte le righe dovranno soddisfare l’espressione Severity > 3. L’indice
sul campo Serial non viene utilizzato perché si utilizza un operatore OR per
connettere due predicati.
select Summary from alerts.status where
Severity > 3 and (Serial = 102 or ServerName = 'NCOMS');
Esempio 2
Se si crea un indice struttura ad albero sul campo Severity, è possibile utilizzare
l’indice sul campo Severity nella seguente query SQL. Tuttavia, non è possibile
utilizzare un indice su LastOccurrence a causa dell’operatore OR tra il predicato
LastOccurrence > getdate() - 360 e il predicato Summary like 'LinkUp'. Ad ogni
modo, si noti che l’espressione getdate() - 360 viene considerata costante per la
durata della query.
select Summary, Severity, Node from alerts.status where
Severity > 1 and (LastOccurrence > getdate() - 360 or Summary like 'LinkUp')
Capitolo 7. Ottimizzazione delle prestazioni
303
Esempio 3
Considerare la seguente query:
select Summary from alerts.status where Severity > 0;
Per un operatore di confronto quale >, >=, < o <= da utilizzare con un indice, è
necessario un indice struttura ad albero (che è un indice ordinato). Se solo 100
righe su 20.000 hanno una severità 0, un indice di questo tipo ridurrà il numero di
righe esaminate soltanto dello 0,5% e non offrirà nessun beneficio significativo per
le prestazioni. Pertanto, quando si decide quale colonna indicizzare, è necessario
considerare i dati di riga effettivi.
Esempio 4
Se si crea un indice hash sulla colonna Node, quando viene eseguita la seguente
query SQL, vengono eseguite solo tre ricerche hash per ″tool″, ″bar″ e ″toolbar″,
anziché esaminare ciascuna riga per verificare l’eguaglianza di Node con uno dei
tre valori.
select Identifier from alerts.status where Node in ('tool', 'bar', 'toobar');
Esempio 5
Se si crea un indice struttura ad albero sulla colonna Severity, quando la seguente
istruzione SELECT viene elaborata, vengono ricercati e restituiti solo i valori
Severity 2 e 3.
select * from alerts.status where Severity > 1 and Severity < 4;
Se una clausola ORDER BY include più di una colonna, se disponibile, viene
utilizzato un indice per la prima colonna.
select Identifier, Serial from alerts.status order by Severity;
Esempio 6
Se ci sono 20.000 righe nella tabella alerts.status e si applica alla seguente query un
indice sul campo ServerSerial, vengono esaminate solo due righe anziché 20.000:
select Summary from alerts.status where ServerSerial in (102,103);
Riferimenti correlati
“Linee guide relative all’indicizzazione” a pagina 301
Esempio di utilizzo di indici con trigger o procedure
Questo esempio mostra in che modo è possibile applicare indici ai trigger o alle
procedure. Questo esempio è una correlazione tra due tipi di eventi, ″Type 14″ e
″Type 15″, che, se si verificano sullo stesso host, vengono risolti.
create procedure correlation
begin
for each x in alerts.status where Type = 14
begin
for each y in alerts.status where y.Node = x.Node
and y.AlertGroup = x.AlertGroup and Type = 15
begin
update alerts.status set Severity = 0
where Identifier in (y.Identifier, x.Identifier)
end
end
end;
304
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
In questo esempio, gli eventi di tipo 14 e 15 verranno risolti se si verificano
entrambi sullo stesso nodo e su AlertGroup.
Se ci sono 10.000 eventi di tipo 14 e 10.000 eventi di tipo 15, e ci sono in media, 10
eventi per il singolo nodo, sono possibili i seguenti risultati:
v Senza eseguire l’indicizzazione, la clausola WHERE interna eseguirà la scansione
di circa 10.000 * 20.000 righe, ossia 200 milioni di righe. Questo processo sarà
lento ed è per questo che si sconsiglia l’uso di istruzioni FOR EACH ROW
nidificate senza una buona indicizzazione.
v Con un indice sulla colonna Type, la clausola WHERE interna eseguirà la
scansione di 10.000 * 10.000 righe, ossia 100 milioni di righe. Anche questo
processo è lento, ma rispetto a quello precedente il numero di righe sottoposte a
scansione è pari alla metà quando l’indicizzazione non viene utilizzata.
v Con un indice sulla colonna Node, la clausola WHERE interna eseguirà la
scansione di 10.000 * 10 righe, ossia 100.000 righe. Questa soluzione garantirà
buone prestazioni.
Nota: La scansione eseguita dall’istruzione UPDATE utilizzerà sempre la chiave
primaria.
Riferimenti correlati
“Linee guide relative all’indicizzazione” a pagina 301
Migliori pratiche per la creazione di trigger
L’obiettivo principale quando si creano o si modificano trigger è quello di rendere i
trigger quanto più efficienti possibile con il minor tempo di esecuzione possibile.
Un trigger ha accesso esclusivo al database ObjectServer per la durata
dell’esecuzione. Riducendo al minimo il tempo di esecuzione di un trigger, è
possibile risparmiare tempo per altri trigger o client che richiedono accesso al
database. È particolarmente importante ridurre il tempo di esecuzione dei trigger
di database perché interrompono l’esecuzione di un’operazione del database
causando, in tal modo, forti rallentamenti. Ad esempio, un trigger di
pre-inserimento nella tabella alerts.status verrà attivato per ogni nuovo evento,
quindi se si verifica un flusso abnorme di eventi, il trigger verrà eseguito più volte.
Il grado di efficienza del trigger influirà sulla capacità di risposta del sistema.
L’ObjectServer registra la quantità di tempo che ciascun trigger utilizza durante i
singoli periodi di granularità e salva i dettagli nel file $NCHOME/omnibus/log/
servername_trigger_stats.logn. È possibile utilizzare questo file per identificare
quali trigger utilizzano gran parte del tempo, per assegnare una priorità ai trigger
da rivedere e per monitorare il sistema per assicurarsi che sia in esecuzione come
previsto. In generale, se un singolo trigger utilizza più di 3 secondi di tempo ogni
60 secondi (periodo di granularità predefinito), deve essere rivisto.
Ogni volta che si aggiornano i trigger, esaminare il file di log per verificare che le
modifiche non causino un peggioramento delle prestazioni.
Utilizzare le seguenti linee guida per migliorare le prestazioni dei trigger.
Evitare scansioni di tabella nei trigger di database
Le scansioni di tabella sono operazioni costose e che possono aver luogo quando si
applicano istruzioni SQL, ad esempio FOR EACH ROW, a una tabella di database.
Quando si includono queste istruzioni in un trigger di database, il costo può
Capitolo 7. Ottimizzazione delle prestazioni
305
risultare particolarmente elevato se il trigger viene richiamato di frequente e se la
tabella sottoposta a scansione presenta un numero considerevole di righe. Ad
esempio, se il trigger di deduplicazione nella tabella alerts.status viene modificato
in modo che ad ogni attivazione esegua la scansione di alerts.status per ricercare
righe che corrispondono a una serie di criteri, questa operazione limiterà la
scalabilità del sistema in quanto il trigger di database richiederà una quantità
crescente di tempo mano a mano che aumenta il numero di righe della tabella da
sottoporre a scansione. Evitare, inoltre, scansioni nidificate.
È possibile utilizzare le seguenti tecniche per evitare la scansione delle tabelle nei
trigger di database:
v Eseguire la scansione in un trigger temporale che viene scritto in modo che una
scansione possa soddisfare molte righe. Per un esempio, vedere il trigger
generic_clear in $NCHOME/omnibus/etc/automation.sql.
v Se si utilizza una tabella di ricerca per arricchire gli eventi, accedere a tale
tabella utilizzandone la chiave primaria, come descritto più avanti. L’uso della
chiave primaria consente una ricerca diretta della riga anziché una scansione
(V7.2 o versioni successive). È anche possibile limitare la dimensione della
tabella di ricerca. Il numero di righe accettabili per una tabella di ricerca è
specifico del sito e dipenderà da fattori quali, ad esempio, la frequenza di
accesso alla tabella di ricerca e le prestazioni dell’hardware.
v Accedere a una tabella di ricerca utilizzando un indice.
Evitare di utilizzare la clausola EVALUATE
Quando un trigger contiene una clausola EVALUATE, viene creata una tabella
temporanea per contenere i risultati dell’istruzione SELECT nella clausola
EVALUATE. La quantità di tempo e di risorse che questa tabella temporanea
consuma dipende dal numero di colonne selezionate e dal numero di righe
corrispondenti alla condizione nella clausola WHERE.
Nella maggior parte dei casi, è possibile sostituire la clausola EVALUATE con una
clausola FOR EACH ROW, che esamina i dati e non comporta il sovraccarico della
creazione di una tabella temporanea.
È opportuno utilizzare una clausola EVALUATE quando si applica una clausola
GROUP BY a una query SQL.
Evitare un uso eccessivo dell’istruzione WRITE INTO per lo
scollegamento in un file
L’istruzione WRITE INTO è molto utile per diversi scopi; in particolare, per
eseguire il debug dei trigger durante lo sviluppo. Tuttavia, quando un trigger
viene distribuito in un ambiente di produzione, si consiglia di impostare come
commento o rimuovere le istruzioni WRITE INTO, poiché la quantità di dati
registrati durante il debug può causare un collo di bottiglia.
Determinare qual è l’approccio migliore per il sistema. Ad esempio, se la
registrazione viene richiamata raramente, è possibile che il problema non sussista.
Tuttavia, se la registrazione viene richiamata più volte per ciascuna istruzione
INSERT (ad esempio, all’interno di un loop nidificato), potrebbe esserci un collo di
bottiglia.
306
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Laddove possibile, utilizzare la chiave primaria quando si
modificano le righe
Se si utilizza la chiave primaria di una tabella di database nella clausola WHERE
di un’istruzione UPDATE, l’accesso alla riga viene eseguito attraverso una ricerca
diretta anziché una scansione di tabella. Ad esempio:
update alerts.status where Identifier = tt.Identifier set Severity = Severity + 1;
Nota: La parola chiave VIA non è più richiesta in V7.2 o versioni successive. Il
seguente comando (che utilizza VIA) è equivalente al precedente comando:
update alerts.status VIA Identifier = tt.Identifier set Severity = Severity + 1;
Utilizzare indici quando si utilizzano tabelle di ricerca
In V7.2 o versioni successive, l’ObjectServer utilizza un indice per accedere alle
righe in una tabella se si utilizza la chiave primaria in un’istruzione FOR EACH
ROW.
Ciò è molto utile nei casi in cui si utilizza una tabella ObjectServer come tabella di
ricerca, probabilmente per arricchire gli eventi. In queste situazioni, la tabella e i
trigger che accedono alla tabella di ricerca devono essere progettati per accedere
alla tabella di ricerca mediante le relative chiavi primarie per impedire costose
scansioni di tabella complete. Ad esempio:
create table alerts.iplookup persistent
(
IpAddr varchar(32) primary key,
HostName varchar(8),
Owner varchar(40)
);
create or replace trigger set_hostname
group madeup_triggers
priority 10
before insert on alerts.status
for each row
begin
-- Access the lookup table using the primary key
for each row tt in alerts.iplookup where tt.IpAddr = new.Node
begin
set new.Hostname = tt.HostName;
end;
end;
Rivedere e modificare i trigger prodotti con la migrazione da V3.6
Se è stata eseguita una migrazione da V3.6 a V7.2.1, lo strumento di migrazione in
V7.2.1 produrrà repliche ottimali dei trigger V3.6. Quando si esegue
l’aggiornamento a V7.3, i trigger che inizialmente sono stati migrati da V3.6,
saranno funzionalmente corretti; tuttavia, è improbabile che tali repliche
rappresentino l’implementazione ideale dei trigger. Rivedere e modificare questi
trigger nel modo seguente:
v L’ObjectServer V3.6 supportava solo trigger temporali, mentre V7.0 o successive
include trigger di database e di segnale. L’elaborazione eseguita da un trigger
temporale in V3.6 potrebbe adattarsi meglio a un trigger di database in V7.0 o
successive. Tuttavia, lo strumento di migrazione converte i trigger solo su una
base ″simile per simile″, quindi richiederà una revisione dei trigger migrati per
identificare quelli da poter meglio implementare utilizzando i nuovi tipi di
trigger.
Capitolo 7. Ottimizzazione delle prestazioni
307
v Quando i trigger V3.6 hanno la condizione select *, lo strumento di migrazione
implementa la condizione come clausola EVALUATE, dove sono selezionate
tutte le colonne della tabella alerts.status. Laddove possibile, sostituire la
clausola EVALUATE con un’istruzione FOR EACH ROW.
v Durante la migrazione da V3.6,x, lo strumento di migrazione creerà trigger
generic_clear che funzionano nello stesso modo in cui funzionano in V3.6.
Tuttavia, i trigger forniti in V7.0 o successive, sono più efficienti. Pertanto, si
consiglia di utilizzare trigger V7.0 o successive, che per impostazione predefinita
sono disabilitati, anziché utilizzare i trigger migrati da V3.6.
Utilizzare il trigger generic_clear come base per i trigger di tipo
correlazione
Il trigger generic_clear standard (vedere $NCHOME/omnibus/etc/automation.sql)
associa gli eventi risoluzione agli eventi problema correlati. Dopo l’esecuzione di
questo trigger, la severità di tutte le righe corrispondenti è impostata su 0, in
previsione della rimozione mediante l’automazione delete_clears.
Il trigger generic_clear presenta diverse funzioni di progettazione chiave che
devono essere duplicate se è richiesto un tipo diverso di trigger di correlazione.
Queste funzioni includono il modo in cui gli eventi vengono identificati e
aggiornati.
Il trigger generic_clear standard non utilizza la clausola EVALUATE per
selezionare gli eventi, ma utilizza il costrutto FOR EACH ROW per eseguire un
loop attraverso gli eventi per inserire in una tabella temporanea gli eventi
problema. Dal momento che questa tabella temporanea contiene solo una sottoserie
degli eventi presenti nella tabella alerts.status, il costo dell’operazione di
aggiornamento che si applica per associare i problemi alle risoluzioni è ridotto.
Inoltre, dal momento che l’identificativo dell’evento problema viene memorizzato
nella tabella temporanea, gli eventi problema possono essere aggiornati
direttamente in alerts.status utilizzando il comando UPDATE VIA per eseguire una
ricerca diretta nella riga; in questo caso, si sfrutta il fatto che il campo Identifier è
una chiave primaria.
Utilizzare la deduplicazione per risolvere gli eventi laddove
possibile
Il trigger di deduplicazione può essere utilizzato per risolvere eventi problema con
l’evento risoluzione in entrata quando tra il problema e la risoluzione vi è
un’associazione uno-a-uno. Sul sistema esistente è necessario apportare la seguente
modifica:
v Scrivere le regole di probe in modo che gli eventi problema e risoluzione
abbiano lo stesso identificativo.
v Modificare il trigger di deduplicazione in modo che quando viene attivato,
controlla il campo Type. Se il tipo dell’evento in entrata è impostato su 1
(risoluzione), la severità dell’evento esistente dovrebbe essere impostata su 0.
Il vantaggio di questo approccio è quello di ridurre l’elaborazione che il trigger
generic_clear deve eseguire, lasciandogli il compito di risolvere i casi in cui un
singolo evento risoluzione risolve molti eventi problema.
308
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Eseguire un test delle modifiche
Dopo aver sviluppato e convalidato i nuovi trigger, verificare le prestazioni del
trigger nel modo seguente:
1. Assicurarsi che i dati su cui vengono eseguiti i test siano rappresentativi del
sistema di produzione.
2. Assicurarsi che il numero di righe in qualsiasi tabella cui accede il trigger sia
rappresentativo del sistema di produzione.
3. Misurare l’effetto sulle prestazioni del sistema utilizzando la creazione profili e
raccogliendo le statistiche del trigger.
Capitolo 7. Ottimizzazione delle prestazioni
309
310
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Appendice A. Tabelle dell’ObjectServer
Il database dell’ObjectServer contiene le seguenti tabelle: tabelle di avviso, tabelle
di sistema, tabelle del catalogo di sistema, tabelle di statistiche, tabelle di supporto
degli strumenti client, tabelle dell’ObjectServer desktop, tabelle di sicurezza, tabelle
di canali IDUC e tabelle SAE (service-affected event).
Le tabelle di database dell’ObjectServer sono memorizzate in $NCHOME/omnibus/db
su sistemi UNIX e in %NCHOME%\omnibus\db su sistemi Windows.
Tabelle Alerts
Le informazioni di avviso vengono inoltrate all’ObjectServer da programmi esterni
quali probe e gateway. Tali informazioni vengono memorizzate e gestite in tabelle
database e visualizzate nell’elenco eventi.
Tabella alerts.status
La tabella alerts.status contiene informazioni di stato sui problemi rilevati dai
probe.
La seguente tabella descrive le colonne nella tabella alerts.status.
Tabella 86. Colonne nella tabella alerts.status
Nome colonna
Tipo di dati
Obbligatorio Descrizione
Identifier
varchar(255)
Sì
Controlla la deduplicazione dell’ObjectServer.
Serial
incr
Sì
Il numero di serie di Tivoli Netcool/OMNIbus per
la riga.
Node
varchar(64)
Sì
Identifica l’entità gestita da cui ha avuto origine
l’allarme. Può essere un nome periferica o host, un
nome servizio o un’altra entità. Per host o
periferiche di rete IP, la colonna Nodo contiene il
nome risolto della periferica o dell’host. Nei casi in
cui non è possibile risolvere il nome, la colonna
Nodo deve contenere l’indirizzo IP dell’host o della
periferica.
NodeAlias
varchar(64)
No
L’alias per il nodo. Per periferiche di rete o host,
deve essere l’indirizzo logico (livello 3) dell’entità.
Per periferiche IP o host, deve essere l’indirizzo IP.
Manager
varchar(64)
Sì
Il nome descrittivo del probe che ha raccolto e
inoltrato l’allarme all’ObjectServer. Può essere
utilizzato anche per indicare l’host su cui è in
esecuzione il probe.
Agent
varchar(64)
No
Il nome descrittivo del gestore secondario che ha
generato l’avviso.
AlertGroup
varchar(255)
No
Il nome descrittivo del tipo di errore indicato
dall’avviso (ad esempio Stato interfaccia o
Utilizzo CPU).
© Copyright IBM Corp. 1994, 2009
311
Tabella 86. Colonne nella tabella alerts.status (Continua)
Nome colonna
Tipo di dati
Obbligatorio Descrizione
AlertKey
varchar(255)
Sì
La chiave descrittiva che indica l’istanza dell’oggetto
gestito specificata dall’avviso (ad esempio, la
partizione disco indicata da un avviso completo del
file system o la porta switch indicata da un avviso
di utilizzo).
Severity
integer
Sì
Indica il livello di severità dell’avviso, descrive in
che modo modo la funzione percepita dell’oggetto
gestito è stata influenzata. Il colore dell’avviso
nell’elenco avvisi è controllato dal valore di severità:
0: chiaro
1: indeterminato
2: avvertenza
3: secondario
4: principale
5: critico
Summary
varchar(255)
Sì
Il riepilogo di testo della causa dell’avviso.
StateChange
time
Sì
Una data/ora dell’ObjectServer (conservata
automaticamente) dell’ultimo inserimento o
aggiornamento dell’avviso da qualsiasi origine.
FirstOccurrence
time
Sì
L’ora, in secondi, (dalla mezzanotte del 1 gennaio
1970) in cui è stato creato questo avviso o in cui è
stato avviato il polling nel probe.
LastOccurrence
time
Sì
L’ora in cui è stato aggiornato questo avviso nel
probe.
InternalLast
time
Sì
L’ora dell’ultimo aggiornamento di questo avviso
nell’ObjectServer.
Poll
integer
No
La frequenza di polling per questo avviso in
secondi.
Type
integer
No
Il tipo di avviso:
0: tipo non impostato
1: problema
2: risoluzione
3: problema Netcool/Visionary
4: risoluzione Netcool/Visionary
7: nuovo allarme Netcool/ISMs
8: vecchio allarme Netcool/ISMs
11: più grave
12: meno grave
13: informazioni
312
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 86. Colonne nella tabella alerts.status (Continua)
Nome colonna
Tipo di dati
Obbligatorio Descrizione
Tally
integer
Sì
Mantenuto automaticamente il conteggio del
numero di inserimenti e aggiornamenti dell’avviso
da qualsiasi origine. Tale conteggio viene
influenzato dalla deduplicazione.
Class
integer
Sì
La classe di avviso utilizzata per identificare il probe
o il fornitore da cui è stato generato l’avviso.
Controlla l’applicabilità di strumenti dell’elenco
eventi sensibili al contesto.
Grade
integer
No
Indicato lo stato di escalation per l’avviso:
0: non sottoposto a escalation
1: sottoposto a escalation
Location
varchar(64)
No
Indica l’ubicazione fisica della periferica, host o
servizio per cui è stato generato l’avviso.
OwnerUID
integer
Sì
L’identificativo utente dell’utente assegnato per
gestire questo avviso. Il valore predefinito è 65534,
che è l’identificativo per l’utente nobody.
OwnerGID
integer
No
L’identificativo gruppo del gruppo assegnato per
gestire questo avviso.
Il valore predefinito è 0, che è l’identificativo per il
gruppo public.
Acknowledged
integer
Sì
Indica se l’avviso è stato riconosciuto:
0: no
1: sì
Gli avvisi possono essere riconosciuti manualmente
da un operatore di rete o automaticamente da una
correlazione o processo del workflow.
Flash
integer
No
Abilita l’opzione per visualizzare l’elenco eventi a
intermittenza.
EventId
varchar(255)
No
L’ID evento (ad esempio, SNMPTRAP-link down). Più
eventi possono avere lo stesso ID evento. Tale valore
viene popolato dal file di regole di probe e utilizzato
da IBM Tivoli Network Manager IP Edition.
ExpireTime
integer
Sì
Il numero di secondi finché l’avviso non viene
cancellato automaticamente. Utilizzato
dall’automazione Scadenza.
ProcessReq
integer
No
Indica se l’avviso deve essere elaborato da IBM
Tivoli Network Manager IP Edition. Tale valore
viene popolato dal file di regole di probe e utilizzato
da IBM Tivoli Network Manager IP Edition.
Appendice A. Tabelle dell’ObjectServer
313
Tabella 86. Colonne nella tabella alerts.status (Continua)
Nome colonna
Tipo di dati
Obbligatorio Descrizione
SuppressEscl
integer
Sì
Utilizzato per cancellare o eseguire l’escalation
dell’avviso:
0: normale
1: sottoposto a escalation
2: sottoposto ad un’escalation di livello 2
3: sottoposto ad un’escalation di livello 3
4: cancellato
5: nascosto
6: manutenzione
Il livello di cancellazione viene selezionato
manualmente dagli operatori dall’elenco eventi.
Customer
varchar(64)
No
Il nome del cliente influenzato da questo avviso.
Service
varchar(64)
No
Il nome del servizio influenzato da questo avviso.
PhysicalSlot
integer
No
Il numero slot indicato dall’avviso.
PhysicalPort
integer
No
Il numero porta indicato dall’avviso.
PhysicalCard
varchar(64)
No
Il nome scheda o la descrizione indicati dall’avviso.
TaskList
integer
Sì
Indica se un utente ha aggiunto l’avviso all’elenco
attività:
0: no
1: sì
Gli operatori possono aggiungere gli avvisi
all’Elenco attività dall’elenco eventi.
NmosSerial
varchar(64)
No
Il numero di serie di un avviso cancellato. Popolato
da IBM Tivoli Network Manager IP Edition.
NmosObjInst
integer
No
Popolato da IBM Tivoli Network Manager IP
Edition durante l’elaborazione di avvisi.
NmosCauseType
integer
No
Lo stato dell’avviso, popolato da IBM Tivoli
Network Manager IP Edition come valore di
numero intero:
0: sconosciuto
1: causa root
2: sintomo
NmosDomainName
varchar(64)
No
Il nome del dominio di IBM Tivoli Network
Manager IP Edition che sta gestendo l’evento.
Per impostazione predefinita, questa colonna viene
popolata soltanto per eventi generati da poll IBM
Tivoli Network Manager IP Edition. Per popolare
tale colonna per altre origini dati come i probe, è
necessario modificare i file delle regole.
314
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 86. Colonne nella tabella alerts.status (Continua)
Nome colonna
Tipo di dati
Obbligatorio Descrizione
NmosEntityId
integer
No
Un ID numerico univoco che identifica l’entità di
topologia IBM Tivoli Network Manager IP Edition a
cui è associato l’evento.
Questa colonna è simile alla colonna NmosObjInst,
ma è più granulare. Ad esempio, il valore
NmosEntityId può rappresentare l’ID di
un’interfaccia all’interno di una periferica.
NmosManagedStatus
integer
No
Lo stato gestito dell’entità di rete per cui viene
generato l’evento. Può essere applicato ad eventi da
IBM Tivoli Network Manager IP Edition e da
qualsiasi probe.
È possibile utilizzare questa colonna per filtrare gli
eventi da interfacce non considerate rilevanti.
NmosEventMap
varchar(64)
No
Contiene il IBM Tivoli Network Manager IP Edition
V3.9 o versioni successive richiesto, il nome
eventMap e la precedenza facoltativa per l’evento,
che indica in che modo IBM Tivoli Network
Manager IP Edition dovrebbe elaborare l’evento.
Il numero di precedenza facoltativa può essere
aggiunto alla fine del valore, dopo un punto (.). Se
non si fornisce la precedenza, viene impostata su 0.
I seguenti esempi mostrano la configurazione per
una mappa eventi con una precedenza evento
esplicita di 900, nonché un’altra configurazione in
cui la precedenza assume il valore predefinito 0:
v ItnmLinkdownIfIndex.900
v PrecisionMonitorEvent
LocalNodeAlias
varchar(64)
Sì
L’alias dell’entità di rete indicata dall’avviso. Per
periferiche di rete o host, questo è l’indirizzo logico
(livello 3) dell’entità o un altro indirizzo logico che
consente la comunicazione diretta con la periferica.
Per l’uso nell’identificazione istanza dell’oggetto
gestito.
LocalPriObj
varchar(255)
No
L’oggetto primario specificato dall’avviso. Per l’uso
nell’identificazione istanza dell’oggetto gestito.
LocalSecObj
varchar(255)
No
L’oggetto secondario specificato dall’avviso. Per
l’uso nell’identificazione istanza dell’oggetto gestito.
LocalRootObj
varchar(255)
Sì
Un oggetto equivalente all’oggetto primario
specificato nell’avviso. Per l’uso nell’identificazione
istanza dell’oggetto gestito.
RemoteNodeAlias
varchar(64)
Sì
L’indirizzo di rete dell’entità di rete remota. Per
l’uso nell’identificazione istanza dell’oggetto gestito.
RemotePriObj
varchar(255)
No
L’oggetto primario di un’entità di rete remota
specificata da un allarme. Per l’uso
nell’identificazione istanza dell’oggetto gestito.
RemoteSecObj
varchar(255)
No
L’oggetto secondario di un’entità di rete remota
specificata da un allarme. Per l’uso
nell’identificazione istanza dell’oggetto gestito.
Appendice A. Tabelle dell’ObjectServer
315
Tabella 86. Colonne nella tabella alerts.status (Continua)
Nome colonna
Tipo di dati
Obbligatorio Descrizione
RemoteRootObj
varchar(255)
Sì
Un oggetto equivalente all’oggetto primario
dell’entità remota specificato nell’allarme. Per l’uso
nell’identificazione istanza dell’oggetto gestito.
X733EventType
integer
No
Indica il tipo di avviso:
0: non definito
1: comunicazioni
2: Quality of Service
3: errore di elaborazione
4: apparecchiatura
5: ambientale
6: violazione integrità
7: violazione operativa
8: violazione fisica
9: violazione del servizio di sicurezza
10: violazione del dominio temporale
X733ProbableCause
integer
No
Indica la probabile causa dell’avviso.
X733SpecificProb
varchar(64)
No
Identifica ulteriori informazioni per la probabile
causa dell’avviso. Utilizzato da file delle regole
probe per specificare una serie di identificativi da
adottare nell’identificazione istanze dell’oggetto
gestito.
X733CorrNotif
varchar(255)
No
Un elenco di tutte le notifiche a cui è correlata
questa notifica.
ServerName
varchar(64)
Sì
Il nome dell’ObjectServer di origine. Utilizzato dai
gateway per controllare la propagazione di avvisi
tra ObjectServer.
ServerSerial
integer
Sì
Il numero di serie dell’avviso sull’ObjectServer di
origine (se non ha avuto origine su questo
ObjectServer). Utilizzato dai gateway per controllare
la propagazione di avvisi tra ObjectServer.
URL
varchar(1024)
No
URL facoltativo che fornisce un link ad informazioni
aggiuntive nell’ENMS o nella periferica del
fornitore.
316
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 86. Colonne nella tabella alerts.status (Continua)
Nome colonna
Tipo di dati
Obbligatorio Descrizione
ExtendedAttr
varchar(4096)
No
Conserva coppie nome-valore (di attributi estesi di
Tivoli Enterprise Console) o altre informazioni
aggiuntive per cui non esiste alcuna colonna
dedicata nella tabella alerts.status.
Utilizzare questa colonna soltanto tramite le
funzioni SQL nvp_get, nvp_set e nvp_exists.
Un esempio di una stringa nome-valore è:
Region="EMEA";host="sf01392w";
Error="errno=32: ""Broken pipe"""
In questo esempio, l’attributo Region ha un valore
EMEA, l’attributo host ha un valore sf01392w e
l’attributo Error ha un valore errno=32: "Broken
pipe".
Notare che le virgolette vengono inserite in una
sequenza escape raddoppiandole, come mostrato
con il valore di attributo Error.
In coppie nome-valore, il valore viene sempre
racchiuso tra virgolette (″ ″) e le virgolette
incorporate vengono inserite in una sequenza escape
raddoppiandole. Il separatore tra coppie
nome-valore è il punto e virgola (;). Non è
consentito alcuno spazio prima o dopo il simbolo di
uguale (=) o il punto e virgola.
Nota: la colonna può contenere 4096 byte, quindi
saranno presenti meno di 4096 caratteri se si
utilizzano caratteri a più byte.
OldRow
integer
No
Mantiene lo stato locale della riga in ciascun
ObjectServer durante la risincronizzazione nella
coppia di failover. Questa colonna non deve essere
aggiunta ai file di associazioni gateway.
Il valore di OldRow viene modificato in 1
nell’ObjectServer di destinazione durante la
risincronizzazione se la proprietà di
Gate.ResyncType del gateway è impostata su
Minimal.
L’impostazione predefinita è 0.
ProbeSubSecondId
integer
No
Per quegli avvisi che un probe invia nello stesso
intervallo di un secondo e che, pertanto, hanno lo
stesso valore LastOccurrence, un valore
incrementale, a partire da 1, viene aggiunto al
campo ProbeSubSecondId per differenziare l’orario
di LastOccurrence. L’impostazione predefinita è 0.
Appendice A. Tabelle dell’ObjectServer
317
Tabella 86. Colonne nella tabella alerts.status (Continua)
Nome colonna
Tipo di dati
Obbligatorio Descrizione
MasterSerial
integer
No
Identifica l’ObjectServer principale se questo avviso
viene elaborato in un ambiente ObjectServer
desktop.
Questa colonna viene aggiunta quando si esegue il
programma di utilità di inizializzazione del database
nco_dbinit con l’opzione -desktopserver.
Nota: MasterSerial deve essere l’ultima colonna
nella tabella alerts.status se si utilizza un ambiente
ObjectServer desktop.
Nota: È possibile visualizzare solo colonne di tipo CHAR, VARCHAR, INCR,
INTEGER e TIME nell’elenco eventi. Non aggiungere colonne di qualsiasi altro tipo
alla tabella alerts.status.
Concetti correlati
“Funzioni” a pagina 154
Tabella alerts.details
La tabella alerts.details contiene gli attributi dettagliati degli avvisi nel sistema.
La seguente tabella descrive le colonne nella tabella alerts.details.
Tabella 87. Colonne nella tabella alerts.details
Nome colonna
Tipo di dati
Descrizione
KeyField
varchar(255)
Stringa di sequenze interna per univocità.
Il valore Keyfield è composto da un valore Identifer, da quattro #
e da un numero di sequenza che inizia da 1; ad esempio:
Identifier####1
Dove Identifier è un tipo di dati varchar(255), utilizzato per
correlare dettagli a voci nella tabella alerts.status.
Se il valore Identifier supera una determinata lunghezza, è
possibile che il valore Keyfield superi il relativo limite definito di
255, generando un troncamento del numero di sequenza. I valori
Keyfield non possono più essere univoci e una duplicazione non
intenzionale impedirà gli inserimenti nella tabella alerts.details.
Suggerimento: Per impedire un overflow in KeyField (e garantire
univocità), la lunghezza del valore Identifier deve essere
sufficientemente inferiore a 255 per consentire l’accodamento dei
quattro # e di un numero di sequenza (di una o più cifre).
Identifier
varchar(255)
Identificativo per correlare dettagli a voci nella tabella
alerts.status.
Il valore Identifier viene utilizzato per calcolare il valore Keyfield
e deve essere inferiore ad una determinata lunghezza per
garantire che ciascun valore Keyfield calcolato rimanga univoco.
Per linee guida sulla lunghezza massima del valore Identifier,
consultare il suggerimento nella riga KeyField precedente.
AttrVal
318
integer
Boolean; quando false (0), è valida soltanto la colonna Detail.
Altrimenti, sono valide entrambe le colonne Name e Detail.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 87. Colonne nella tabella alerts.details (Continua)
Nome colonna
Tipo di dati
Descrizione
Sequence
integer
Numero di sequenza, utilizzato per ordinare le voci nella finestra
Informazioni evento dell’elenco eventi.
Name
varchar(255)
Nome dell’attributo memorizzato nella colonna Detail.
Detail
varchar(255)
Valore di attributo.
Tabella alerts.journal
La tabella alerts.journal fornisce una cronologia del lavoro eseguito sugli avvisi.
La seguente tabella descrive le colonne nella tabella alerts.journal.
Tabella 88. Colonne nella tabella alerts.journal
Nome colonna
Tipo di dati
Descrizione
KeyField
varchar(255)
Chiave primaria per la tabella.
Serial
integer
Numero di serie dell’avviso a cui è correlata questa voce del
journal.
UID
integer
Identificativo utente dell’utente che ha creato questa voce.
Chrono
time
Data e ora di creazione di questa voce.
Text1
varchar(255)
Primo blocco di testo per la voce del journal.
Text2
varchar(255)
Secondo blocco di testo per la voce del journal.
Text3
varchar(255)
Terzo blocco di testo per la voce del journal.
Text4
varchar(255)
Quarto blocco di testo per la voce del journal.
Text5
varchar(255)
Quinto blocco di testo per la voce del journal.
Text6
varchar(255)
Sesto blocco di testo per la voce del journal.
Text7
varchar(255)
Settimo blocco di testo per la voce del journal.
Text8
varchar(255)
Ottavo blocco di testo per la voce del journal.
Text9
varchar(255)
Nono blocco di testo per la voce del journal.
Text10
varchar(255)
Decimo blocco di testo per la voce del journal.
Text11
varchar(255)
Undicesimo blocco di testo per la voce del journal.
Text12
varchar(255)
Dodicesimo blocco di testo per la voce del journal.
Text13
varchar(255)
Tredicesimo blocco di testo per la voce del journal.
Text14
varchar(255)
Quattordicesimo blocco di testo per la voce del journal.
Text15
varchar(255)
Quindicesimo blocco di testo per la voce del journal.
Text16
varchar(255)
Sedicesimo blocco di testo per la voce del journal.
Appendice A. Tabelle dell’ObjectServer
319
Tabella alerts.iduc_messages
La tabella alerts.iduc_messages è richiesta per il supporto multiculturale e viene
utilizzare per inviare messaggi di inserimento, eliminazione, aggiornamento o
controllo (IDUC) del client. Questa tabella garantisce che i caratteri trasferiti su
codifiche variabili vengano convertiti in formati riconoscibili.
La seguente tabella descrive le colonne nella tabella alerts.iduc_messages.
Tabella 89. Colonne nella tabella alerts.iduc_messages
Nome colonna
Tipo di dati
Descrizione
MsgID
integer
Chiave primaria per la tabella.
MsgText
varchar(4096)
Testo del messaggio inviato ad un elenco eventi dal programma di
utilità nco_elct. Tale programma consente di aprire un elenco
eventi personalizzato e temporaneo.
MsgTime
time
Ora di invio del messaggio.
Tabella alerts.application_types
La tabella alerts.application_types contiene dettagli sui tipi di applicazioni che
causano la creazione di messaggi di controllo in caso di connessione e
disconnessione delle applicazioni. Utilizzare questa tabella per configurare la
severità di eventi di connessione e disconnessione per tipo di applicazione.
Ad esempio, una connessione gateway viene trattata come una risoluzione (che
cancella una disconnessione), mentre una connessione dell’elenco eventi è un
evento di Tipo 1, che viene risolto da una disconnessione. Una disconnessione
gateway viene trattata come un problema, mentre una disconnessione dell’elenco
eventi è una risoluzione. È possibile utilizzare la tabella alerts.application_types
per configurare un gateway per generare un evento di Tipo 1 (avvertenza) sulla
disconnessione e un evento di Tipo 2 (disconnessione cancellata) sulla connessione
e configurare un elenco eventi per generare un evento di Tipo 1 sulla connessione
e un evento di Tipo 2 (cancellazione) sulla disconnessione.
La tabella alerts.application_types viene letta dai trigger connection_watch_connect
e connection_watch_disconnect.
È possibile aggiungere un nuovo tipo di applicazione a questa tabella aggiungendo
una riga, se necessario. È inoltre possibile modificare il funzionamento di
un’applicazione aggiornando la relativa riga.
La seguente tabella descrive le colonne nella tabella alerts.application_types.
Tabella 90. Colonne nella tabella alerts.application_types
Nome colonna
Tipo di dati
Descrizione
application
varchar(64)
Chiave primaria per la tabella.
Questo è il nome applicazione interno specificato come
espressione regolare per una corrispondenza efficiente tra stringhe.
description
varchar(64)
Nome descrittivo per l’evento.
connect_type
int
Tipo di evento per la connessione.
connect_severity
int
Severità dell’evento per la connessione.
disconnect_type
int
Tipo di evento per la disconnessione.
320
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 90. Colonne nella tabella alerts.application_types (Continua)
Nome colonna
Tipo di dati
Descrizione
disconnect_severity
int
Severità dell’evento per la disconnessione.
expire_time
int
Numero di secondi finché l’avviso non viene cancellato
automaticamente. Utilizzato dall’automazione Scadenza.
discard
Boolean
Impostarlo su TRUE se l’evento deve essere eliminato.
Tabella master.class_membership
La tabella master.class_membership supporta l’associazione di classi di Tivoli
Enterprise Console e classi Tivoli Netcool/OMNIbus e memorizza informazioni di
appartenenza alle classi. Questa tabella viene utilizzata con la funzione SQL
instance_of().
La seguente tabella descrive le colonne nella tabella master.class_membership.
Tabella 91. Colonne nella tabella master.class_membership
Nome colonna
Tipo di dati
Descrizione
Class
integer
Chiave primaria per la tabella. Numero di classe come è
memorizzato nella tabella alert.status.
ClassName
varchar(255)
Nome della classe.
Parent
integer
Chiave primaria per la tabella. ID parent della classe.
La classe root ha un ID parent -1. Se una classe presenta più
parent, esiste una riga per ciascun parent.
Concetti correlati
“Funzioni” a pagina 154
Tabelle di servizio
La tabella di servizio contiene informazioni su IBM Tivoli Composite Application
Manager for Internet Service Monitoring.
Tabella service.status
La tabella service.status viene utilizzata per controllare le funzioni aggiuntive
richieste per supportare IBM Tivoli Composite Application Manager for Internet
Service Monitoring.
La seguente tabella descrive le colonne nella tabella service.status.
Tabella 92. Colonne nella tabella service.status
Nome colonna
Tipo di dati
Descrizione
Name
varchar(255)
Nome del servizio.
CurrentState
integer
Indica lo stato del servizio:
0: buono
1: non valido
2: marginale
3: sconosciuto
Appendice A. Tabelle dell’ObjectServer
321
Tabella 92. Colonne nella tabella service.status (Continua)
Nome colonna
Tipo di dati
Descrizione
StateChange
time
Indica l’ultima volta in cui è stato modificato lo stato del servizio.
LastGoodAt
time
Indica l’ultima volta in cui il servizio è stato buono (0).
LastBadAt
time
Indica l’ultima volta in cui il servizio è stato non valido (1).
LastMarginalAt
time
Indica l’ultima volta in cui il servizio è stato marginale (2).
LastReportAt
time
Ora dell’ultimo report di stato del servizio.
Tabelle del catalogo di sistema
Il database di cataloghi contiene le tabelle di sistema create e gestite
dall’ObjectServer. Le tabelle di sistema contengono metadati relativi agli oggetti
dell’ObjectServer.
È possibile visualizzare le informazioni contenute nelle tabelle di sistema
utilizzando i comandi SELECT e DESCRIBE, ma non è possibile modificare tali
tabelle.
Tabella catalog.memstores
La tabella catalog.memstores memorizza informazioni su memstore, inclusi i limiti
rigidi e flessibili della dimensione del memstore e il numero di byte attualmente
utilizzati.
La seguente tabella descrive le colonne nella tabella catalog.memstores.
Tabella 93. Colonne nella tabella catalog.memstores
Nome colonna
Tipo di dati
Descrizione
StoreName
varchar(40)
Nome del memstore.
HardLimit
unsigned
Dimensione massima dell’archivio in memoria.
SoftLimit
unsigned
Dimensione massima corrente dell’archivio; può essere estesa fino
al limite rigido.
UsedBytes
unsigned
La quantità di memoria, in byte, utilizzata dal memstore.
IsProtected
Boolean
Utilizzato internamente.
Tabella catalog.databases
La tabella catalog.databases memorizza informazioni su ciascun database, incluso il
numero di oggetti al suo interno e il tipo di database (di sistema o dell’utente).
La seguente tabella descrive le colonne nella tabella catalog.databases.
Tabella 94. Colonne nella tabella catalog.databases
Nome colonna
Tipo di dati
Descrizione
DatabaseName
varchar(40)
Nome del database.
NumTables
unsigned
Numero di viste e tabelle di base nel database.
IsSystem
Boolean
TRUE se si tratta di un database di sistema.
322
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella catalog.tables
La tabella catalog.tables memorizza informazioni su tutti i tipi di tabelle, incluse
tabelle di sistema e utente, viste e tabelle transizione.
La seguente tabella descrive le colonne nella tabella catalog.tables.
Tabella 95. Colonne nella tabella catalog.tables
Nome colonna
Tipo di dati
Descrizione
TableName
varchar(40)
Nome della tabella.
DatabaseName
varchar(40)
Nome del database parent.
Status
integer
Stato corrente della tabella:
0: valido
1: non valido
2: compilazione non riuscita
NumDependents
unsigned
Numero di dipendenti.
TableID
integer
Identificativo tabella.
TableKind
integer
Tipo di tabella:
0: tabella di base
1: tabella di transizione
2: vista
StorageKind
integer
Tipo di memoria:
1: persistente
2: virtuale
4: transitoria
Tabella catalog.base_tables
La tabella catalog.base_tables memorizza informazioni su tabelle di sistema e
utente.
La seguente tabella descrive le colonne nella tabella catalog.base_tables.
Tabella 96. Colonne nella tabella catalog.base_tables
Nome colonna
Tipo di dati
Descrizione
TableName
varchar(40)
Nome della tabella.
DatabaseName
varchar(40)
Nome del database parent.
StoreName
varchar(40)
Nome dell’archivio parent.
NumColumns
integer
Numero di colonne nella tabella.
CreationTime
time
Ora di creazione della tabella.
StorageKind
integer
Tipo di memoria:
1: persistente
2: virtuale
IsSystem
Boolean
TRUE se si tratta di una tabella di sistema.
Appendice A. Tabelle dell’ObjectServer
323
Tabella 96. Colonne nella tabella catalog.base_tables (Continua)
Nome colonna
Tipo di dati
Descrizione
IsNoModify
Boolean
TRUE se la tabella non può essere attualmente modificata.
UsedBytes
unsigned
Dimensione, in byte, della tabella. Aggiornata in caso di creazione,
modifica e ad un intervallo predefinito di 60 secondi.
Tabella catalog.views
La tabella catalog.views memorizza informazioni sulle viste. La colonna
CreationText contiene l’SQL utilizzato per creare la vista.
La seguente tabella descrive le colonne nella tabella catalog.views.
Tabella 97. Colonne nella tabella catalog.views
Nome colonna
Tipo di dati
Descrizione
ViewName
varchar(40)
Nome della vista.
DatabaseName
varchar(40)
Nome del database parent.
CreationText
varchar(16384)
Il testo CREATE VIEW utilizzato per creare la vista.
StorageKind
integer
Tipo di memoria:
1: persistente
4: transitoria
IsRecovered
Boolean
TRUE se si tratta di una vista ripristinata correttamente dopo il
riavvio.
IsDmlEnabled
Boolean
TRUE se tutte le chiavi primarie della tabella sono presenti nella
vista e, di conseguenza, le azioni DML possono essere eseguite
sulla vista.
IsAggregate
Boolean
TRUE se viene creato da un’istruzione SELECT di aggregazione.
Tabella catalog.files
La tabella catalog.files memorizza informazioni sui file dell’ObjectServer, incluso il
percorso al file del sistema operativo associato a ciascun file dell’ObjectServer.
La seguente tabella descrive le colonne nella tabella catalog.files.
Tabella 98. Colonne nella tabella catalog.files
Nome colonna
Tipo di dati
Descrizione
FileName
varchar(40)
Nome del file dell’ObjectServer.
FilePath
varchar(1028)
Percorso completo al file sul file system.
MaximumFiles
unsigned
Numero massimo di file.
MaximumSize
unsigned
Dimensione massima del file.
IsEnabled
Boolean
TRUE se le informazioni vengono registrate in questo file.
Status
integer
Stato corrente del file:
0: valido
1: non valido
2: compilazione non riuscita
324
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella catalog.restrictions
La tabella catalog.restrictions memorizza informazioni sui filtri limitazioni. La
colonna ConditionText contiene la condizione SQL.
La seguente tabella descrive le colonne nella tabella catalog.restrictions.
Tabella 99. Colonne nella tabella catalog.restrictions
Nome colonna
Tipo di dati
Descrizione
RestrictionName
varchar(40)
Nome del filtro limitazioni.
TableName
varchar(40)
Nome della tabella su cui è stato creato il filtro limitazioni.
DatabaseName
varchar(40)
Nome del database parent.
ConditionText
varchar(16384)
Il testo di condizione per il filtro limitazioni.
CreationText
varchar(16384)
Il testo CREATE RESTRICTION utilizzato per creare il filtro
limitazioni.
Tabella catalog.columns
La tabella catalog.columns memorizza informazioni sulle colonne di tabella, inclusi
i relativi tipi di dati.
La seguente tabella descrive le colonne nella tabella catalog.columns.
Tabella 100. Colonne nella tabella catalog.columns
Nome colonna
Tipo di dati
Descrizione
ColumnName
varchar(40)
Nome della colonna.
TableName
varchar(40))
Nome della tabella.
DatabaseName
varchar(40)
Nome del database parent.
DataType
integer
Tipo di dati della colonna.
Length
unsigned
Numero di caratteri nella colonna.
IsPrimaryKey
Boolean
TRUE se la colonna è una chiave primaria.
OrdinalPosition
unsigned
Posizione nell’elenco di colonne.
IsHidden
Boolean
TRUE se si tratta di una colonna nascosta.
IsNoModify
Boolean
TRUE se la colonna non può essere attualmente modificata.
IsNoDefault
Boolean
TRUE se il valore di questa colonna deve essere specificato nel
comando INSERT iniziale.
IsSystem
Boolean
TRUE se si tratta di una colonna di sistema.
Tabella catalog.primitive_signals
La tabella catalog.primitive_signals memorizza informazioni sui segnali di sistema
e dell’utente.
La seguente tabella descrive le colonne nella tabella catalog.primitive_signals.
Tabella 101. Colonne nella tabella catalog.primitive_signals
Nome colonna
Tipo di dati
Descrizione
SignalName
varchar(40)
Nome del segnale.
IsSystem
Boolean
TRUE se si tratta di un segnale di sistema.
Appendice A. Tabelle dell’ObjectServer
325
Tabella 101. Colonne nella tabella catalog.primitive_signals (Continua)
Nome colonna
Tipo di dati
Descrizione
CommentBlock
varchar(1024)
Stringa di commento specificata nel comando CREATE SIGNAL.
Tabella catalog.primitive_signal_parameters
La tabella catalog.primitive_signal_parameters memorizza informazioni sui
parametri per segnali di sistema e definiti dall’utente.
La seguente tabella descrive le colonne nella tabella
catalog.primitive_signal_parameters.
Tabella 102. Colonne nella tabella catalog.primitive_signal_parameters
Nome colonna
Tipo di dati
Descrizione
ParameterName
varchar(40)
Nome del parametro.
SignalName
varchar(40)
Nome del segnale con questo parametro.
DataType
integer
Tipo di dati del parametro.
Length
unsigned
Numero di caratteri nel parametro.
OrdinalPosition
integer
Posizione nell’elenco di parametri.
Tabella catalog.trigger_groups
La tabella catalog.trigger_groups memorizza informazioni su gruppi trigger,
indicando anche se il gruppo trigger è abilitato.
La seguente tabella descrive le colonne nella tabella catalog.trigger_groups.
Tabella 103. Colonne nella tabella catalog.trigger_groups
Nome colonna
Tipo di dati
Descrizione
GroupName
varchar(40)
Nome del gruppo trigger.
IsEnabled
Boolean
TRUE se il gruppo trigger è attualmente abilitato.
Tabella catalog.triggers
La tabella catalog.triggers memorizza informazioni sui trigger, incluso il tipo di
trigger, la priorità del trigger e il gruppo trigger in cui si trova.
La seguente tabella descrive le colonne nella tabella catalog.triggers.
Tabella 104. Colonne nella tabella catalog.triggers
Nome colonna
Tipo di dati
Descrizione
TriggerName
varchar(40)
Nome del trigger.
GroupName
varchar(40)
Nome del gruppo trigger.
TriggerKind
integer
Tipo di trigger:
0: database
1: segnale
2: temporale
DebugEnabled
326
Boolean
TRUE se il debug è abilitato per il trigger.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 104. Colonne nella tabella catalog.triggers (Continua)
Nome colonna
Tipo di dati
Descrizione
IsEnabled
Boolean
TRUE se il trigger è abilitato.
TriggerPriority
integer
Priorità trigger: 1 è la massima priorità e 20 è la minima priorità.
CommentBlock
varchar(1024)
Stringa di commento specificata nel comando CREATE TRIGGER.
EvaluateBlock
varchar(2048)
Clausola di valutazione specificata nel comando CREATE
TRIGGER.
BindName
varchar(40)
Nome bind specificato nella clausola di valutazione del comando
CREATE TRIGGER.
ConditionBlock
varchar(1024)
Quando la condizione viene specificata nel comando CREATE
TRIGGER.
DeclareBlock
varchar(1024)
Dichiarazione di variabile specificata nel comando CREATE
TRIGGER.
CodeBlock
varchar(8192)
Il corpo del trigger.
Tabella catalog.database_triggers
La tabella catalog.database_triggers memorizza informazioni sui trigger di
database, incluso il tipo di operazione database che causa l’attivazione del trigger.
La seguente tabella descrive le colonne nella tabella catalog.database_triggers.
Tabella 105. Colonne nella tabella catalog.database_triggers
Nome colonna
Tipo di dati
Descrizione
TriggerName
varchar(40)
Nome del trigger.
EventOrder
integer
Ordine di eventi:
0: prima
1: dopo
EventOp
integer
Operazione evento:
0: inserimento
1: reinserimento
2: aggiornamento
3: eliminazione
EventLevel
integer
Livello di trigger:
0: trigger a livello di riga
1: trigger a livello di istruzione
DatabaseName
varchar(40)
Nome del database.
TableName
varchar(40)
Nome della tabella.
Appendice A. Tabelle dell’ObjectServer
327
Tabella catalog.signal_triggers
La tabella catalog.signal_triggers memorizza informazioni sui trigger di segnale,
incluso il nome del segnale che ha causato l’attivazione del trigger.
La seguente tabella descrive le colonne nella tabella catalog.signal_triggers.
Tabella 106. Colonne nella tabella catalog.signal_triggers
Nome colonna
Tipo di dati
Descrizione
TriggerName
varchar(40)
Nome del trigger.
SignalName
varchar(40)
Nome del segnale.
Tabella catalog.temporal_triggers
La tabella catalog.temporal_triggers memorizza informazioni sui trigger temporali,
inclusa la relativa frequenza di attivazione.
La seguente tabella descrive le colonne nella tabella catalog.temporal_triggers.
Tabella 107. Colonne nella tabella catalog.temporal_triggers
Nome colonna
Tipo di dati
Descrizione
TriggerName
varchar(40)
Nome del trigger.
Frequency
integer
Frequenza di trigger in secondi.
Tabella catalog.procedures
La tabella catalog.procedures memorizza informazioni sulle procedure, incluso il
tipo di procedura, ovvero SQL o esterno.
La seguente tabella descrive le colonne nella tabella catalog.procedures.
Tabella 108. Colonne nella tabella catalog.procedures
Nome colonna
Tipo di dati
Descrizione
ProcedureName
varchar(40)
Nome della procedura.
Kind
unsigned
Tipo di procedura:
0: SQL
1: esterna
Tabella catalog.sql_procedures
La tabella catalog.sql_procedures memorizza informazioni sulle procedure SQL,
incluso il codice per la procedura.
La seguente tabella descrive le colonne nella tabella catalog.sql_procedures.
Tabella 109. Colonne nella tabella catalog.sql_procedures
Nome colonna
Tipo di dati
Descrizione
ProcedureName
varchar(40)
Nome della procedura.
DeclareBlock
varchar(16384)
Dichiarazione di variabile specificata nel comando CREATE
PROCEDURE.
CodeBlock
varchar(32768)
Il corpo della procedura.
328
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella catalog.external_procedures
La tabella catalog.external_procedures memorizza informazioni su procedure
esterne, incluso il nome dell’eseguibile della procedura e l’host su cui tale
procedura viene eseguita.
La seguente tabella descrive le colonne nella tabella catalog.external_procedures.
Tabella 110. Colonne nella tabella catalog.external_procedures
Nome colonna
Tipo di dati
Descrizione
ProcedureName
varchar(40)
Nome della procedura.
ExecutableName
varchar(1024)
Nome dell’eseguibile.
HostName
varchar(1024)
Nome dell’host.
UserId
varchar(1024)
Identificativo utente.
GroupId
varchar(1024)
Identificativo gruppo.
ArgumentsSpec
varchar(32768)
Argomenti specificati nel testo CREATE PROCEDURE.
Tabella catalog.procedure_parameters
La tabella catalog.procedure_parameters memorizza le informazioni sui parametri
della procedura, inclusi i tipi di parametri.
La seguente tabella descrive le colonne nella tabella catalog.procedure_parameters.
Tabella 111. Colonne nella tabella catalog.procedure_parameters
Nome colonna
Tipo di dati
Descrizione
ParameterName
varchar(40)
Nome del parametro.
ProcedureName
varchar(40)
Nome della procedura.
ParameterKind
integer
Tipo di parametro:
0: base
1: riga
2: array
DataType
integer
Tipo di dati del parametro.
OrdinalPosition
integer
Posizione nell’elenco di argomenti.
Length
integer
Numero di caratteri nel parametro.
TableName
varchar(40)
Se si tratta di un parametro di riga, questa è la tabella parent di
tale riga. Altrimenti, è una stringa vuota.
DatabaseName
varchar(40)
Se si tratta di un parametro di riga, questo è il database parent
della tabella parent della riga. Altrimenti, è una stringa vuota.
ParameterMode
integer
Modalità parametro:
1: in
2: out
3: in/out
Appendice A. Tabelle dell’ObjectServer
329
Tabella catalog.connections
La tabella catalog.connections contiene informazioni sulle connessioni
all’ObjectServer.
La seguente tabella descrive le colonne nella tabella catalog.connections.
Tabella 112. Colonne nella tabella catalog.connections
Nome colonna
Tipo di dati
Descrizione
ConnectionID
integer
Identificativo della connessione.
LogName
varchar(40)
Nome del file di log per l’applicazione connessa.
HostName
varchar(40)
Nome dell’host connesso.
AppName
varchar(40)
Nome dell’applicazione connessa.
AppDescription
varchar(40)
Descrizione dell’applicazione connessa.
IsRealTime
Boolean
TRUE se il client utilizza IDUC. I desktop e gateway utilizzano
IDUC e sono connessioni in tempo reale.
ConnectTime
time
Intervallo di tempo durante il quale il client è connesso.
Tabella catalog.properties
La tabella catalog.properties contiene informazioni sulle proprietà dell’ObjectServer.
La seguente tabella descrive le colonne nella tabella catalog.properties.
Tabella 113. Colonne nella tabella catalog.properties
Nome colonna
Tipo di dati
Descrizione
PropName
varchar(40)
Nome della proprietà.
PropGroup
varchar(40)
Gruppo di proprietà, ad esempio Auto o Store. Non tutte le
proprietà appartengono ad un gruppo.
Description
varchar(255)
Descrizione della proprietà.
Type
integer
Tipo di dati della proprietà.
Value
varchar(255)
Valore corrente della proprietà.
IsModifyable
Boolean
TRUE se la proprietà è modificabile.
IsImmediate
Boolean
TRUE se, quando la proprietà viene modificata, l’effetto è
immediato. Altrimenti, è necessario riavviare l’ObjectServer.
IsAdvanced
Boolean
TRUE se la proprietà è avanzata. Si consiglia di non modificare le
proprietà avanzate senza l’assistenza del IBM Software Support.
Tabella catalog.security_permissions
La tabella catalog.security_permissions contiene informazioni sulle autorizzazioni
per oggetti dell’ObjectServer. Tale tabella viene utilizzata soltanto da
Netcool/OMNIbus Administrator.
La seguente tabella descrive le colonne nella tabella catalog.security_permissions.
Tabella 114. Colonne nella tabella catalog.security_permissions
Nome colonna
Tipo di dati
Descrizione
ApplicationID
integer
Identificativo applicazione.
Object
varchar(40)
Nome dell’oggetto.
330
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 114. Colonne nella tabella catalog.security_permissions (Continua)
Nome colonna
Tipo di dati
Descrizione
ObjectType
integer
Tipo di oggetto, ad esempio, tabella.
ActionID
integer64
Identificativo per l’azione di autorizzazione. Utilizzato soltanto da
Netcool/OMNIbus Administrator.
Permission
varchar(40)
Tipo di autorizzazione.
Tabella catalog.profiles
La tabella catalog.profiles contiene informazioni temporali per l’esecuzione di
comandi SQL da connessioni client.
Vengono inoltre registrate statistiche di profilo SQL nel file $NCHOME/omnibus/log/
servername_profiler_report.logn, all’intervallo specificato nella proprietà
ProfileStatsInterval o nell’opzione della riga comandi -profilestatsinterval.
La seguente tabella descrive le colonne nella tabella catalog.profiles.
Tabella 115. Colonne nella tabella catalog.profiles
Nome colonna
Tipo di dati
Descrizione
ConnectionID
integer
Identificativo della connessione.
UID
integer
Identificativo utente.
AppName
varchar(40)
Nome dell’applicazione connessa.
HostName
varchar(40)
Nome dell’host connesso.
ProfiledFrom
time
Ora di inizio della gestione profili.
LastSQLTime
real
Durata, in secondi, dell’ultimo comando SQL.
MinSQLTime
real
Tempo di esecuzione più breve, in secondi, per questo client.
MaxSQLTime
real
Tempo di esecuzione più lungo, in secondi, per questo client.
PeriodSQLTime
real
Intervallo di tempo, in secondi, impiegato dall’applicazione per
l’esecuzione di SQL dall’ultimo report di profilo.
TotalSQLTime
real
Tempo totale, in secondi per l’esecuzione di tutti i comandi SQL
per questo client.
LastTimingAt
time
Ultima volta in cui questo client ha acquisito un profilo SQL.
NumSubmits
integer
Numero di inoltri per questo client. Un singolo inoltro può
contenere più comandi SQL, eseguiti con il comando go.
TotalParseTime
real
Registra l’intervallo di tempo totale impiegato per l’analisi di
comandi per questo client.
TotalResolveTime
real
Registra l’intervallo di tempo totale impiegato per la risoluzione di
comandi per questo client.
TotalExecTime
real
Registra l’intervallo di tempo totale impiegato per l’esecuzione di
comandi per questo client.
Appendice A. Tabelle dell’ObjectServer
331
Tabella catalog.indexes
La tabella catalog.indexes memorizza informazioni sugli indici, inclusa la tabella di
colonne e database su cui si basa l’indice e il tipo di indice.
La seguente tabella descrive le colonne nella tabella catalog.indexes.
Tabella 116. Colonne nella tabella catalog.indexes
Nome colonna
Tipo di dati
Descrizione
IndexName
varchar(40)
Nome dell’indice.
DatabaseName
varchar(40)
Nome database della colonna indicizzata.
TableName
varchar(40)
Nome tabella della colonna indicizzata.
ColumnName
varchar(40)
Nome della colonna indicizzata.
IndexKind
integer
Tipo di indice:
1: hash
2: struttura ad albero
IsValid
Boolean
TRUE se l’indice è valido.
FALSE se l’indice non è valido; ad esempio, a causa di un errore
di assegnazione della memoria. Per rendere un indice nuovamente
valido, è possibile ricrearlo riavviando l’ObjectServer.
Tabelle di statistiche
Le tabelle di statistiche contengono informazioni temporali.
La tabella catalog.profiles contiene informazioni temporali per l’esecuzione di
comandi SQL da connessioni client.
La tabella master.stats memorizza informazioni temporali sulle tabelle alerts.status,
alerts.details e alerts.journal.
La tabella catalog.trigger_stats memorizza informazioni temporali sui trigger.
Tabella catalog.profiles
La tabella catalog.profiles contiene informazioni temporali per l’esecuzione di
comandi SQL da connessioni client. La gestione profili SQL viene abilitata
utilizzando la proprietà Profile o l’opzione della riga comandi -profile.
Vengono inoltre registrate statistiche di profilo SQL nel file $NCHOME/omnibus/log/
servername_profiler_report.logn, all’intervallo specificato nella proprietà
ProfileStatsInterval o nell’opzione della riga comandi -profilestatsinterval.
La seguente tabella descrive le colonne nella tabella catalog.profiles.
Tabella 117. Colonne nella tabella catalog.profiles
Nome colonna
Tipo di dati
Descrizione
ConnectionID
integer
Identificativo della connessione.
UID
integer
Identificativo utente.
AppName
varchar(40)
Nome dell’applicazione connessa.
HostName
varchar(40)
Nome dell’host connesso.
332
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 117. Colonne nella tabella catalog.profiles (Continua)
Nome colonna
Tipo di dati
Descrizione
ProfiledFrom
time
Ora di inizio della gestione profili.
LastSQLTime
real
Durata, in secondi, dell’ultimo comando SQL.
MinSQLTime
real
Tempo di esecuzione più breve, in secondi, per questo client.
MaxSQLTime
real
Tempo di esecuzione più lungo, in secondi, per questo client.
PeriodSQLTime
real
Intervallo di tempo, in secondi, impiegato dall’applicazione per
l’esecuzione di SQL dall’ultimo report di profilo.
TotalSQLTime
real
Tempo totale, in secondi per l’esecuzione di tutti i comandi SQL
per questo client.
LastTimingAt
time
Ultima volta in cui questo client ha acquisito un profilo SQL.
NumSubmits
integer
Numero di inoltri per questo client. Un singolo inoltro può
contenere più comandi SQL, eseguiti con il comando go.
TotalParseTime
real
Registra l’intervallo di tempo totale impiegato per l’analisi di
comandi per questo client.
TotalResolveTime
real
Registra l’intervallo di tempo totale impiegato per la risoluzione di
comandi per questo client.
TotalExecTime
real
Registra l’intervallo di tempo totale impiegato per l’esecuzione di
comandi per questo client.
Tabella master.stats
La tabella master.stats memorizza informazioni temporali sulle tabelle alerts.status,
alerts.details e alerts.journal. Queste informazioni temporali vengono raccolte se il
gruppo trigger stats_triggers è abilitato. Tale gruppo viene disabilitato per
impostazione predefinita nel file automation.sql.
La seguente tabella descrive le colonne nella tabella master.stats.
Tabella 118. Colonne nella tabella master.stats
Nome colonna
Tipo di dati
Descrizione
StatTime
time
L’ora in cui sono state raccolte le statistiche.
NumClients
integer
Il numero totale di client (ad esempio, desktop) collegati
all’ObjectServer.
NumRealtime
integer
Il numero di client in tempo reale collegati all’ObjectServer. I
desktop e gateway utilizzano IDUC e sono connessioni in tempo
reale.
NumProbes
integer
Il numero di probe collegati all’ObjectServer.
NumGateways
integer
Il numero di gateway collegati all’ObjectServer.
NumMonitors
integer
Il numero di monitor collegati all’ObjectServer.
NumProxys
integer
Il numero di server proxy collegati all’ObjectServer.
EventCount
integer
Il numero corrente di voci presenti nella tabella alerts.status.
JournalCount
integer
Il numero corrente di voci presenti nella tabella alerts.journal.
DetailCount
integer
Il numero corrente di voci presenti nella tabella alerts.details.
StatusInserts
integer
Il numero totale di inserimenti nella tabella alerts.status.
StatusNewInserts
integer
Il numero di nuovi inserimenti nella tabella alerts.status.
StatusDedups
integer
Il numero di reinserimenti nella tabella alerts.status.
Appendice A. Tabelle dell’ObjectServer
333
Tabella 118. Colonne nella tabella master.stats (Continua)
Nome colonna
Tipo di dati
Descrizione
JournalInserts
integer
Il numero di inserimenti nella tabella alerts.journal.
DetailsInserts
integer
Il numero di inserimenti nella tabella alerts.details.
Tabella catalog.trigger_stats
La tabella catalog.trigger_stats memorizza informazioni temporali sui trigger, tra
cui il numero di volte in cui è stato generato e attivato il trigger. Tali statistiche
vengono raccolte a meno che il sistema di automazione non venga disabilitato
impostando l’opzione della riga comandi -autoenabled su FALSE.
Vengono inoltre registrate statistiche di trigger nel file $NCHOME/omnibus/log/
servername_trigger_stats.logn.
La seguente tabella descrive le colonne nella tabella catalog.trigger_stats.
Tabella 119. Colonne nella tabella catalog.trigger_stats
Nome colonna
Tipo di dati
Descrizione
TriggerName
varchar(40)
Nome del trigger.
PreviousCondition
Boolean
Valore della condizione l’ultima volta che il trigger è stato
generato.
PreviousRowcount
unsigned
Il numero di righe restituite dalla clausola EVALUATE l’ultima
volta che il trigger è stato generato.
NumZeroRowcount
unsigned
Numero di volte consecutive in cui la valutazione ha restituito
zero righe.
NumPositiveRowcount
unsigned
Numero di volte consecutive in cui la valutazione ha restituito
una o più righe.
PeriodNumRaises
unsigned
Numero di volte in cui il trigger è stato generato dall’ultimo
report.
PeriodNumFires
unsigned
Numero di volte in cui il trigger è stato attivato dall’ultimo report.
PeriodTime
real
Intervallo di tempo durante il quale il trigger è rimasto operativo
dall’ultimo report.
NumRaises
unsigned
Numero di volte in cui il trigger è stato generato.
NumFires
unsigned
Numero di volte in cui il trigger è stato attivato.
MaxTime
real
Intervallo di tempo massimo di esecuzione del trigger.
TotalTime
real
Intervallo di tempo durante il quale il trigger ha operato
dall’avvio.
Nota: La tabella di sistema catalog.trigger_stats viene aggiornata periodicamente,
in base all’impostazione per la proprietà Auto.StatsInterval o all’opzione della riga
comandi -autostatsinterval. Il valore predefinito è ogni 10 secondi.
334
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella catalog.channel_stats
La tabella catalog.channel_stats contiene una voce per ciascun canale attualmente
noto all’interno dell’ObjectServer. Ciascuna voce all’interno della tabella presenta
dettagli sul canale in due parti: statistiche per il periodo di raccolta statistiche
corrente e totale di statistiche dall’avvio dell’ObjectServer.
La seguente tabella descrive le colonne nella tabella catalog.channel_stats.
Tabella 120. Colonne nella tabella catalog.channel_stats
Nome colonna
Tipo di dati
Descrizione
ChannelName
varchar(64)
Il nome del canale.
LastTimingAt
time
L’ora in cui è stato eseguito l’ultimo aggiornamento delle
statistiche; memorizzata come UTC.
PeriodNumMsgs
int
Il numero di volte in cui questo canale è stato utilizzato nella
finestra dell’ultimo profilo.
PeriodTime
real
Il tempo impiegato per inviare i messaggi a tutti i client nella
finestra dell’ultimo periodo di profilo.
PeriodMaxTime
real
Il tempo massimo impiegato per inviare i messaggi a tutti i client
nella finestra dell’ultimo periodo di profilo.
PeriodClientNum
int
Il numero di client a cui sono stati inviati dei messaggi nell’ultimo
richiamo.
PeriodMaxClientNum
int
Il numero massimo di client a cui sono stati inviati dei messaggi
nella finestra dell’ultimo periodo di profilo.
NumMsg
int
Il numero di volte in cui questo canale è stato utilizzato dall’avvio
del server.
TotalTime
real
Il tempo totale impiegato per inviare i messaggi a tutti i client
dall’avvio del server.
MaxTime
real
Il tempo massimo impiegato per inviare i messaggi a tutti i client
dall’avvio del server.
MaxClientNum
int
Il numero massimo di client a cui sono stati inviati dei messaggi
dall’avvio del server.
TotalClientNum
int
Il numero totale di client a cui sono stati inviati dei messaggi
dall’avvio del server.
Tabelle di supporto degli strumenti client
Le tabelle di supporto degli strumenti client vengono utilizzate dalle GUI desktop
per visualizzare informazioni di avviso.
Tabella alerts.resolutions
La tabella alerts.resolutions viene utilizzata per mantenere l’opzione Risoluzioni
nell’elenco eventi.
La seguente tabella descrive le colonne nella tabella alerts.resolutions.
Tabella 121. Colonne nella tabella alerts.resolutions
Nome colonna
Tipo di dati
Descrizione
KeyField
varchar(255)
Chiave primaria per la tabella.
Tag
integer
Valore di classe per questa risoluzione.
Appendice A. Tabelle dell’ObjectServer
335
Tabella 121. Colonne nella tabella alerts.resolutions (Continua)
Nome colonna
Tipo di dati
Descrizione
Sequence
integer
Numero di sequenza che imposta l’ordinamento al momento della
visualizzazione.
Title
varchar(64)
Titolo della risoluzione.
Resolution1
varchar(255)
Prima riga di testo per la risoluzione.
Resolution2
varchar(255)
Seconda riga di testo per la risoluzione.
Resolution3
varchar(255)
Terza riga di testo per la risoluzione.
Resolution4
varchar(255)
Quarta riga di testo per la risoluzione.
Tabella alerts.conversions
La tabella alerts.conversions viene utilizzata per fornire una semplice conversione
da un valore numerico ad una stringa per qualsiasi colonna.
La seguente tabella descrive le colonne nella tabella alerts.conversions.
Tabella 122. Colonne nella tabella alerts.conversions
Nome colonna
Tipo di dati
Descrizione
KeyField
varchar(255)
Chiave primaria per la tabella: stringa di sequenze interna
(comprensiva di Colname e Value).
Colname
varchar(255)
Nome della colonna per cui questa conversione è adeguata.
Value
integer
Valore numerico per la conversione.
Conversion
varchar(255)
Valore stringa per la conversione.
Tabella alerts.col_visuals
La tabella alerts.col_visuals viene utilizzata per fornire gli elementi visivi
predefiniti per colonne quando vengono visualizzate negli strumenti del desktop.
La seguente tabella descrive le colonne nella tabella alerts.col_visuals.
Tabella 123. Colonne nella tabella alerts.col_visuals
Nome colonna
Tipo di dati
Descrizione
Colname
varchar(255)
Nome della colonna per le impostazioni visive.
Title
varchar(255)
Titolo della colonna quando visualizzato.
DefWidth
integer
Larghezza predefinita della colonna quando visualizzata.
MaxWidth
integer
Larghezza massima della colonna quando visualizzata.
TitleJustify
integer
Allineamento per il titolo di colonna:
0: a sinistra
1: centrato
2: a destra
336
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 123. Colonne nella tabella alerts.col_visuals (Continua)
Nome colonna
Tipo di dati
Descrizione
DataJustify
integer
Allineamento per i dati di colonna:
0: a sinistra
1: centrato
2: a destra
Tabella alerts.colors
La tabella alerts.colors viene utilizzata per creare i colori richiesti dal desktop
Windows.
La seguente tabella descrive le colonne nella tabella alerts.colors.
Tabella 124. Colonne nella tabella alerts.colors
Nome colonna
Tipo di dati
Descrizione
Severity
integer
Severità del problema:
0: chiaro
1: indeterminato
2: avvertenza
3: secondario
4: principale
5: critico
AckedRed
integer
Componente rosso del colore RGB per eventi riconosciuti. Deve
essere compreso nell’intervallo 0-255.
AckedGreen
integer
Componente verde del colore RGB per eventi riconosciuti. Deve
essere compreso nell’intervallo 0-255.
AckedBlue
integer
Componente blu del colore RGB per eventi riconosciuti. Deve
essere compreso nell’intervallo 0-255.
UnackedRed
integer
Componente rosso del colore RGB per eventi non riconosciuti.
Deve essere compreso nell’intervallo 0-255.
UnackedGreen
integer
Componente verde del colore RGB per eventi non riconosciuti.
Deve essere compreso nell’intervallo 0-255.
UnackedBlue
integer
Componente blu del colore RGB per eventi non riconosciuti. Deve
essere compreso nell’intervallo 0-255.
Appendice A. Tabelle dell’ObjectServer
337
Tabelle degli strumenti desktop
Le tabelle degli strumenti desktop contengono informazioni utilizzate per
configurare gli strumenti dell’elenco eventi.
Tabella tools.actions
La tabella tools.actions viene utilizzata per controllare gli strumenti del desktop.
La seguente tabella descrive le colonne nella tabella tools.actions.
Tabella 125. Colonne nella tabella tools.actions
Nome colonna
Tipo di dati
Descrizione
ActionID
integer
L’identificativo dello strumento.
Name
varchar(64)
Il nome dello strumento.
Owner
integer
Indica se lo strumento ha un proprietario.
Enabled
integer
Indica se lo strumento è abilitato.
Description1
varchar(255)
La prima riga della descrizione.
Description2
varchar(255)
La seconda riga della descrizione.
Description3
varchar(255)
La terza riga della descrizione.
Description4
varchar(255)
La quarta riga della descrizione.
HasInternal
integer
Indica se lo strumento ha un effetto interno.
InternalEffect1
varchar(255)
La prima riga dell’effetto interno.
InternalEffect2
varchar(255)
La seconda riga dell’effetto interno.
InternalEffect3
varchar(255)
La terza riga dell’effetto interno.
InternalEffect4
varchar(255)
La quarta riga dell’effetto interno.
InternalForEach
integer
Quando impostata, avvia l’effetto interno per ciascuna riga
selezionata.
HasExternal
integer
Indica se lo strumento ha una procedura esterna.
ExternalEffect1
varchar(255)
La prima riga della procedura esterna.
ExternalEffect2
varchar(255)
La seconda riga della procedura esterna.
ExternalEffect3
varchar(255)
La terza riga della procedura esterna.
ExternalEffect4
varchar(255)
La quarta riga della procedura esterna.
ExternalForEach
integer
Quando impostata, avvia la procedura esterna per ciascuna riga
selezionata.
RedirectOut
integer
Quando selezionata, l’output viene sottoposto ad echo tramite una
finestra di sola lettura nella stessa visualizzazione dell’elenco
eventi che ha eseguito lo strumento.
RedirectErr
integer
Quando selezionata, gli errori vengono sottoposti ad echo tramite
una finestra di sola lettura nella stessa visualizzazione dell’elenco
eventi che ha eseguito lo strumento.
Platform
varchar(255)
Indica il tipo di sistema operativo su cui è in esecuzione la
procedura esterna:
NT (piattaforme Windows)
UNIX (piattaforme UNIX)
UNIX, NT (piattaforme UNIX e Windows)
JournalText1
338
varchar(255)
La prima riga della voce di journal.
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 125. Colonne nella tabella tools.actions (Continua)
Nome colonna
Tipo di dati
Descrizione
JournalText2
varchar(255)
La seconda riga della voce di journal.
JournalText3
varchar(255)
La terza riga della voce di journal.
JournalText4
varchar(255)
La quarta riga della voce di journal.
JournalForEach
integer
Quando impostata, aggiunge la voce di journal per ciascuna riga
selezionata.
HasForcedJournal
integer
Forza l’apertura di una finestra della voce di journal durante
l’esecuzione dello strumento.
Tabella tools.action_access
La tabella tools.action_access viene utilizzata per controllare l’accesso a strumenti
del desktop.
La seguente tabella descrive le colonne nella tabella tools.action_access.
Tabella 126. Colonne nella tabella tools.action_access
Nome colonna
Tipo di dati
Descrizione
ActionID
integer
L’identificativo univoco dello strumento, acquisito dalla tabella di
azioni.
GID
integer
Indica per quale gruppo è disponibile lo strumento.
ClassID
integer
Indica per quale classe è disponibile lo strumento.
ActionAccessID
integer
Campo di chiave primaria per la tabella.
Tabella tools.menus
La tabella tools.menus viene utilizzata per controllare i menu di strumenti del
desktop.
La seguente tabella descrive le colonne nella tabella tools.menus.
Tabella 127. Colonne nella tabella tools.menus
Nome colonna
Tipo di dati
Descrizione
MenuID
integer
Campo di chiave primaria per la tabella di menu.
Name
varchar(64)
Nome del menu.
Owner
integer
Indica se il menu ha un proprietario.
Enabled
integer
Indica se il menu è abilitato o disabilitato.
Tabella tools.menu_items
La tabella tools.menu_items viene utilizzata per controllare le voci del menu di
strumenti del desktop.
La seguente tabella descrive le colonne nella tabella tools.menu_items.
Tabella 128. Colonne nella tabella tools.menu_items
Nome colonna
Tipo di dati
Descrizione
KeyField
varchar(32)
Un campo chiave per questa voce di menu. Creato da menu_id
(nella tabella tools.menus) e da menu_item_id.
Appendice A. Tabelle dell’ObjectServer
339
Tabella 128. Colonne nella tabella tools.menu_items (Continua)
Nome colonna
Tipo di dati
Descrizione
MenuID
integer
L’identificativo di menu univoco acquisito dalla tabella
tools.menus.
MenuItemID
integer
L’identificativo della chiave primaria per questa voce di menu.
Title
varchar(64)
Il nome visualizzato nel menu.
Description
varchar(255)
La descrizione della voce di menu.
Enabled
integer
Indica se la voce di menu è abilitata o disabilitata.
InvokeType
integer
Indica il tipo di voce di menu:
0: strumento
1: linea di separazione
2: menu secondario
InvokeID
integer
Indica l’identificativo azione dell’azione definita nella colonna
InvokeType.
Position
integer
Indica la posizione (ordine) di questa voce nel menu.
Accelerator
varchar(32)
Indica che il tasto di scelta rapida di questa voce di menu.
Tabella tools.prompt_defs
La tabella tools.prompt_defs viene utilizzata per memorizzare tutte le definizioni di
prompt.
La seguente tabella descrive le colonne nella tabella tools.prompt_defs.
Tabella 129. Colonne nella tabella tools.prompt_defs
Nome colonna
Tipo di dati
Descrizione
Name
varchar(64)
Il nome del prompt.
Prompt
varchar(64)
Il titolo del prompt che compare nella parte superiore della
finestra di prompt.
Default
varchar(64)
Il valore predefinito da immettere se l’utente non inserisce alcun
valore.
Value
varchar(255)
L’elenco di valori disponibili.
Type
integer
Il tipo di prompt. Un tipo 7 è un link ad una definizione di menu
con lo stesso nome del prompt.
Tabella tools.menu_defs
La tabella tools.menu_defs viene utilizzata per controllare le voci del menu di
strumenti del desktop.
La seguente tabella descrive le colonne nella tabella tools.menu_defs.
Tabella 130. Colonne nella tabella tools.menu_defs
Nome colonna
Tipo di dati
Descrizione
Name
varchar(64)
Il nome del menu. Deve corrispondere al nome della definizione
di prompt tipo 7.
DatabaseName
varchar(64)
Il database utilizzato per creare le voci di menu.
340
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 130. Colonne nella tabella tools.menu_defs (Continua)
Nome colonna
Tipo di dati
Descrizione
TableName
varchar(64)
La tabella utilizzata per creare le voci di menu.
ShowField
varchar(64)
Il campo nella tabella da mostrare come elenco a discesa del
menu.
AssignField
varchar(64)
Il campo effettivo utilizzato per immettere un valore nel prompt.
OrderByField
varchar(64)
Il campo utilizzato per ordinare il menu.
WhereClause
varchar(255)
Il filtro (condizione) per mostrare una sottoserie di voci di menu.
Direction
integer
L’ordine delle voci di menu:
0: ascendente
1: discendente
Tabelle dell’ObjectServer desktop
La tabella master.national viene utilizzata in un’architettura dell’ObjectServer
desktop. Tale tabella viene creata al momento dell’esecuzione di nco_dbinit tramite
l’opzione -desktopserver. La tabella master.servergroups viene utilizzata per
bilanciare il carico di connessioni desktop.
Tabella master.national
La tabella master.national identifica l’ObjectServer principale e la modalità di
doppia scrittura in un’architettura ObjectServer desktop.
La seguente tabella descrive le colonne nella tabella master.national.
Tabella 131. Colonne nella tabella master.national
Nome colonna
Tipo di dati
Descrizione
KeyField
incr
Colonna di chiave primaria per la tabella.
MasterServer
varchar(29)
Nome dell’ObjectServer principale in un’architettura
dell’ObjectServer desktop.
DualWrite
integer
Indica se abilitare la modalità di doppia scrittura. La modalità di
doppia scrittura consente agli operatori di visualizzare
rapidamente i risultati delle azioni degli strumenti (ad esempio,
conferma ricezione e assegnazione della priorità) sui relativi
desktop DSD. Questa operazione viene eseguita inviando tutte le
azioni degli strumenti sia all’ObjectServer desktop che
all’ObjectServer principale.
1: abilitata
0: disabilitata
Appendice A. Tabelle dell’ObjectServer
341
Tabella master.servergroups
La tabella master.servergroups viene utilizzata per bilanciare il carico di
connessioni desktop.
La seguente tabella descrive le colonne nella tabella master.servergroups.
Tabella 132. Colonne nella tabella master.servergroups
Nome colonna
Tipo di dati
Descrizione
ServerName
varchar(64)
Il nome di un ObjectServer desktop.
GroupID
integer
L’identificativo gruppo a cui appartiene ciascun ObjectServer
desktop. Gli accessi degli utenti all’elenco eventi vengono
distribuiti soltanto tra ObjectServer desktop che hanno lo stesso
GroupID.
Weight
integer
La priorità per ciascun ObjectServer desktop. Più alto è il valore
maggiori sono le connessioni. Ad esempio, un ObjectServer con
Weight pari a 2 attrae un numero doppio di connessioni di un
ObjectServer con Weight pari a 1. Le connessioni con
bilanciamento del carico non vengono reindirizzate
all’ObjectServer con Weight pari a 0.
Tabelle di sicurezza per compatibilità con versioni precedenti
In Netcool/OMNIbus V3.6, il database principale conteneva tabelle di
autenticazione utente per memorizzare le informazioni sulla sicurezza di
Netcool/OMNIbus. Tali informazioni sono ora memorizzate nel database della
sicurezza e nella tabella catalog.security_permissions.
Le tabelle master.names, master.members e master.groups fornivano autorizzazione
e identificazione di gruppi e utenti. La tabella master.profiles forniva le
informazioni sulle limitazioni utente. Tali tabelle sono ora richieste soltanto per
compatibilità con precedenti versioni del desktop.
Tabelle di IDUC
Il database iduc_system memorizza tutte le tabelle di supporto dell’applicazione
IDUC per la notifica eventi accelerati, l’invio di messaggi informativi e l’ora/data
di aggiornamento di IDUC.
Tabella iduc_system.channel
La tabella iduc_system.channel definisce la serie di canali IDUC noti all’interno
dell’ObjectServer.
La seguente tabella descrive le colonne nella tabella iduc_system.channel.
Tabella 133. Colonne nella tabella iduc_system.channel
Nome colonna
Tipo di dati
Descrizione
Name
varchar(64)
Il nome del canale.
ChannelID
int
Viene aggiunta una chiave per un riferimento più efficiente ai
dettagli del canale memorizzato nelle tabelle associate.
Description
varchar(2048)
La descrizione del canale.
342
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella iduc_system.channel_interest
La tabella iduc_system.channel_interest memorizza le voci di interesse del canale
per un determinato canale. Possono esistere più voci di interesse per canale.
La seguente tabella descrive le colonne nella tabella iduc_system.channel_interest.
Tabella 134. Colonne nella tabella iduc_system.channel_interest
Nome colonna
Tipo di dati
Descrizione
ElementName
varchar(64)
Il nome dei destinatari del canale. Questo è un nome gruppo o
utente.
IsGroup
int
Un indicazione del fatto che i destinatari sono un gruppo di
utenti.
Hostname
varchar(255)
Il nome host del client IDUC.
AppName
varchar(255)
Il nome applicazione del client IDUC.
AppDescription
varchar(255)
La descrizione dell’applicazione del client IDUC.
ChannelID
int
L’ID canale.
Tabella iduc_system.channel_summary
La tabella iduc_system.channel_summary viene utilizzata soltanto per un comando
client IDUC di traccia rapida evento (o evento accelerato). Le righe provenienti da
qualsiasi tabella nell’ObjectServer possono essere inoltrate come eventi accelerati.
Questa tabella consente di associare un canale a più tabella da cui è possibile
accelerare gli eventi.
La seguente tabella descrive le colonne nella tabella iduc_system.channel_summary.
Tabella 135. Colonne nella tabella iduc_system.channel_summary
Nome colonna
Tipo di dati
Descrizione
DatabaseName
varchar(64)
Il database a cui appartiene la tabella.
TableName
varchar(64)
Il nome della tabella.
SummaryID
int
Viene aggiunta una chiave intera per un riferimento più efficiente
alla tabella di colonne di riepilogo.
ChannelID
int
L’ID canale.
Tabella iduc_system.channel_summary_cols
La tabella iduc_system.channel_summary_cols memorizza dettagli sulle colonne
esatte che compongono il riepilogo effettivo per una determinata tabella.
La seguente tabella descrive le colonne nella tabella
iduc_system.channel_summary_cols.
Tabella 136. Colonne nella tabella iduc_system.channel_summary_cols
Nome colonna
Tipo di dati
Descrizione
ColumnName
varchar(64)
Il nome di una colonna che fa parte di una determinata
definizione di riepilogo.
Position
int
La posizione della colonna nell’ordine di riepilogo.
SummaryID
int
L’ID riepilogo.
Appendice A. Tabelle dell’ObjectServer
343
Tabella iduc_system.iduc_stats
La tabella iduc_system.iduc_stats memorizza i dettagli relativi all’ultima volta in
cui le modifiche IDUC sono state trasmesse a un client IDUC.
La seguente tabella descrive le colonne della tabella iduc_system.iduc_stats.
Tabella 137. Colonne della tabella iduc_system.iduc_stats
Nome colonna
Tipo di dati
Descrizione
ServerName
varchar(40)
Il nome dell’ObjectServer a cui si connette il client IDUC. Chiave
primaria.
AppName
varchar(40)
Il nome applicazione del client IDUC.
AppDesc
varchar(128)
La descrizione dell’applicazione del client IDUC. Chiave primaria.
ConnectionId
int
Identifica in maniera univoca la connessione. Chiave primaria.
LastIducTime
UTC
L’ora in cui le modifiche IDUC sono state trasmesse l’ultima volta
al client IDUC.
Questa colonna viene aggiornata ogni volta che il gateway
recupera dati dall’ObjectServer.
Tabelle SAE (Service Affected Event)
Le tabelle SAE (Service Affected Event) forniscono supporto per SAE (Service
Affected Event) generati in Network Manager IP Edition. Un SAE (Service Affected
Event) è un avviso che avverte gli operatori che un servizio clienti critico è stato
influenzato da uno o più eventi di rete.
Tabella precision.service_affecting_event
La tabella precision.service_affecting_event memorizza l’identificativo di un SAE
(service-affected event) generato in Network Manager IP Edition.
La seguente tabella descrive la colonna nella tabella
precision.service_affecting_event.
Tabella 138. Colonna nella tabella precision.service_affecting_event
Nome colonna
Tipo di dati
Descrizione
ServiceEntityId
integer
Colonna di chiave primaria per la tabella. L’ID di un SAE
(service-affected event).
Tabella precision.service_details
La tabella precision.service_details memorizza i dettagli di un SAE (service-affected
event) generato in Network Manager IP Edition.
La seguente tabella descrive le colonne nella tabella precision.service_details.
Tabella 139. Colonne nella tabella precision.service_details
Nome colonna
Tipo di dati
Descrizione
ServiceEntityId
integer
Colonna di chiave primaria per la tabella. L’ID di un SAE
(service-affected event).
Type
varchar(255)
Il tipo di servizio.
Name
varchar(255)
Il nome del servizio.
344
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 139. Colonne nella tabella precision.service_details (Continua)
Nome colonna
Tipo di dati
Descrizione
Customer
varchar(255)
Il cliente associato.
Tabella precision.entity_service
La tabella precision.entity_service associa gli identificativi di SAE (service-affected
event) agli ID numerici che identificano in modo univoco le entità di topologia
Network Manager IP Edition a cui sono associati gli eventi.
La seguente tabella descrive le colonne nella tabella precision.entity_service.
Tabella 140. Colonne nella tabella precision.entity_service
Nome colonna
Tipo di dati
Descrizione
NmosEntityId
integer
Colonna di chiave primaria per la tabella. Un ID numerico che
identifica l’entità di topologia Network Manager IP Edition a cui è
associato un SAE.
ServiceEntityId
integer
Colonna di chiave primaria per la tabella. L’ID di un SAE
(service-affected event).
Appendice A. Tabelle dell’ObjectServer
345
346
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Appendice B. Pulsanti helper, espressioni variabili e comandi
SQL in strumenti, automazioni ed elenchi eventi transitori
È possibile utilizzare diversi pulsanti helper, espressioni variabili e comandi SQL
per richiamare informazioni da un elenco eventi in esecuzione, dall’evento corrente
o dall’ambiente del sistema operativo. È possibile utilizzare tali espressioni durante
la creazione di uno strumento, trigger o procedura SQL oppure in parametri
passati ad un elenco eventi transitori.
La seguente tabella elenca i pulsanti helper, espressioni variabili e comandi SQL.
Tabella 141. Pulsanti helper, espressioni variabili e comandi SQL in strumenti, trigger, procedure e nell’elenco di
eventi transitori
Comando/
espressione
variabile
Pulsante
select_command
insert_command
Uso
Fare clic su questo pulsante per selezionare un comando SQL dal menu
pop-up. In base al comando selezionato, completare la finestra risultante
nel modo seguente:
update_command
v Seleziona: selezionare il database e la tabella su cui eseguire il comando
SELECT. Quindi, scegliere le colonne di tabella da selezionare.
delete_command
v Inserisci: selezionare il database e la tabella su cui eseguire il comando
INSERT. Quindi, selezionare le colonne di tabella in cui inserire dei
valori. Per ciascuna colonna selezionata, immettere il valore da inserire.
Per istruzioni insert, è necessario includere la chiave primaria. Le chiavi
primarie sono indicate da un asterisco (*).
use_command
service_command
v Aggiorna: selezionare il database e la tabella su cui eseguire il comando.
Quindi, selezionare le colonne di tabella da aggiornare. Per ciascuna
colonna selezionata, immettere il nuovo valore. Per istruzioni update, è
necessario escludere la chiave primaria. Le chiavi primarie sono indicate
da un asterisco (*).
Nota: Per inserimenti e aggiornamenti alla tabella alerts.status, le
eventuali conversioni esistenti vengono visualizzate negli elenchi a
discesa.
v Elimina: selezionare la tabella da eliminare.
v Utilizza: selezionare il database da utilizzare.
v Servizio: selezionare un nome servizio e un valore. I valori possono
essere Buono, Marginale o Non valido.
column_name
@column_name
Fare clic su questo pulsante per selezionare un nome della colonna di
tabella da aggiungere al comando. Il nome colonna viene sostituito per il
corrispondente valore di riga dell’elenco eventi durante l’esecuzione dello
strumento.
Quando viene anteposto il simbolo @, il nome colonna viene sostituito con
il corrispondente valore di riga dell’elenco eventi durante l’esecuzione. Tale
valore può essere utilizzato in un filtro limitazioni o in una query SQL, ad
esempio: RemoteNodeAlias = '@LocalNodeAlias'
conversion_name
Fare clic su questo pulsante per selezionare da un elenco di conversioni
disponibili.
N/D
Fare clic su questo pulsante per visualizzare un elenco di parole chiave che
completano l’SQL immesso.
© Copyright IBM Corp. 1994, 2009
347
Tabella 141. Pulsanti helper, espressioni variabili e comandi SQL in strumenti, trigger, procedure e nell’elenco di
eventi transitori (Continua)
Comando/
espressione
variabile
Pulsante
Uso
N/D
Fare clic su questo pulsante per controllare la validità della sintassi SQL
immessa.
%internal_value
Fare clic su questo pulsante per selezionare da un elenco di valori interni
noti all’istanza corrente dell’elenco eventi. Ad esempio, per eseguire
l’elenco eventi transitorio e specificare l’ObjectServer a cui connettersi
utilizzando l’opzione della riga comandi -server, specificare:
-server ″%server″
I seguenti valori interni sono disponibili per gli strumenti e come parametri
per l’elenco di eventi transitori:
%display: la visualizzazione corrente che esegue l’applicazione (solo
UNIX).
%password: la password dell’utente che esegue l’applicazione.
%encrypted_password: la password codificata dell’utente che esegue
l’applicazione (solo UNIX). In modalità FIPS 140–2, la password viene
inviata come testo semplice quando utilizzata negli strumenti, ma è
nascosta quando specificata come parametro dalla riga comandi.
%server: il nome dell’ObjectServer a cui è attualmente connesso lo
strumento.
%desktopserver: il nome dell’ObjectServer desktop a cui è attualmente
connesso lo strumento.
%uid: l’identificativo utente ObjectServer dell’utente che esegue
l’applicazione.
%username: il nome utente ObjectServer dell’utente che esegue
l’applicazione.
Il seguente valore interno è disponibile per procedure e trigger:
%user: utilizzato per specificare variabili utente e per accedere ad
informazioni sugli utenti connessi.
Il seguente valore interno è disponibile solo per trigger:
%trigger: utilizzato per specificare variabili trigger e per accedere ad
informazioni sulle esecuzioni correnti e precedenti di trigger.
Il seguente valore interno è inoltre disponibile solo per trigger di segnali:
%signal: utilizzato per specificare variabili di segnale e per accedere ad
informazioni sui segnali generati.
$prompt.
prompt_name
Fare clic su questo pulsante per selezionare il nome del prompt da
utilizzare durante l’esecuzione di query sull’utente. Ad esempio, per
eseguire l’elenco eventi transitorio e richiedere all’utente di immettere la
password utilizzando il prompt Password, specificare: -password
$prompt.Password
È possibile utilizzare i prompt negli strumenti e come parametri per
l’elenco di eventi transitori.
348
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tabella 141. Pulsanti helper, espressioni variabili e comandi SQL in strumenti, trigger, procedure e nell’elenco di
eventi transitori (Continua)
Comando/
espressione
variabile
$selected_rows.
column_name
Pulsante
Uso
N/D
Elenco di valori di column_name per tutti gli avvisi selezionati. Ad esempio:
update alerts.status set TaskList = 0 where Serial in
($selected_rows.serial)
Non utilizzare questa sintassi se si seleziona la casella di spunta Esegui per
tutte le righe selezionate. Selezionare invece la casella di spunta se la
modifica è differente per ciascun avviso.
$(environment_
variable)
N/D
Indica una variabile di ambiente. Ad esempio, quando si esegue un elenco
eventi transitorio, è possibile specificare il file di filtro utilizzando l’opzione
della riga comandi -elf, senza modificarla:
-elf ″$(NCHOME)/omnibus/ini/tool.elf
Per eseguire lo strumento su Windows, inserire la variabile di ambiente (ad
esempio, $(NCHOME)), tra virgolette doppie. Se il nome percorso contiene
uno spazio, non verrà interpretato correttamente.
Suggerimento:
v Quando si immettono dei comandi SQL all’interno dei pannelli dell’editor SQL
di Tivoli Netcool/OMNIbus, è possibile immettere uno o più caratteri e
successivamente premere Ctrl+F1 per ottenere una finestra di dialogo con un
elenco di parole chiave che potrebbero corrispondere alla voce utilizzata.
Selezionare la parola chiave richiesta e fare clic su OK per completare la voce. Se
una sola parola chiave corrisponde ai caratteri immessi, la parola chiave viene
completata automaticamente. Se si preme Ctrl+F1 dopo l’immissione di una
parola chiave correlata al database, la finestra di dialogo fornisce un elenco di
possibili database ObjectServer da cui è possibile effettuare una selezione. Se si
preme Ctrl+F1 dopo l’immissione di un nome database seguito da un punto (ad
esempio: alerts.), è possibile premere di nuovo Ctrl+F1 per visualizzare e
effettuare una selezione da un elenco di tabelle del database.
v È possibile fare clic sul pulsante Negli Appunti per copiare il comando in un
formato testo negli Appunti.
Attività correlate
“Creazione e modifica di strumenti” a pagina 77
“Creazione e modifica
“Creazione e modifica
“Creazione e modifica
“Creazione e modifica
Riferimenti correlati
di
di
di
di
trigger di database” a pagina 86
trigger di segnale” a pagina 88
trigger temporali” a pagina 91
procedure SQL” a pagina 96
“Variabili utente implicite in procedure e trigger” a pagina 191
“Utilizzo di variabili di trigger nelle azioni e nelle condizioni di trigger” a pagina
206
“Segnali di sistema e relativi attributi” a pagina 207
Appendice B. Pulsanti helper, espressioni variabili e comandi SQL
349
350
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Informazioni particolari
Queste informazioni sono state progettate per prodotti e servizi offerti negli Stati
Uniti.
È possibile che IBM non offra in altri paesi i prodotti, i servizi o le funzioni
descritti in questo documento. Consultare il rappresentante locale IBM per
informazioni sui prodotti e sui servizi disponibili nel proprio paese. Qualsiasi
riferimento ad un prodotto, programma o servizio IBM non implica o non intende
dichiarare che possa essere utilizzato solo quel prodotto, programma o servizio
IBM. In sostituzione a quelli forniti da IBM possono essere utilizzati prodotti,
programmi o servizi funzionalmente equivalenti che non comportino la violazione
dei diritti di proprietà intellettuale IBM. Tuttavia, è responsabilità dell’utente
valutare e verificare il funzionamento di qualsiasi prodotto, programma o servizio
non IBM.
IBM può avere brevetti o domande di brevetto in corso relativi a quanto trattato
nel presente documento. La fornitura di questo documento non concede alcuna
licenza a tali brevetti. È possibile inviare per iscritto richieste di licenze a:
Director of Commercial Relations
IBM Europe
Schoenaicher Str. 220
D-71032 Boeblingen
Deutschland
Per richieste di licenze relative ad informazioni double-byte (DBCS), contattare il
Dipartimento di Proprietà Intellettuale IBM nel proprio paese o inviare richieste
per iscritto a:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106-0032, Japan
Il seguente paragrafo non è valido per il Regno Unito o per tutti i paesi le cui leggi
nazionali siano in contrasto con le disposizioni in esso contenute:
INTERNATIONAL BUSINESS MACHINES CORPORATION FORNISCE LA
PRESENTE PUBBLICAZIONE ″NELLO STATO IN CUI SI TROVA″ SENZA
ALCUNA GARANZIA, ESPLICITA O IMPLICITA, IVI INCLUSE EVENTUALI
GARANZIE DI COMMERCIABILITÀ E DI IDONEITÀ PER UNO SCOPO
PARTICOLARE. Alcuni stati non consentono la rinuncia a garanzie esplicite o
implicite in determinate transazioni; pertanto la presente dichiarazione potrebbe
non essere a voi applicabile.
Queste informazioni potrebbero contenere imprecisioni tecniche o errori tipografici.
Le informazioni incluse in questo documento vengono modificate su base
periodica; tali modifiche verranno incorporate nelle nuove edizioni della
pubblicazione. IBM si riserva il diritto di apportare miglioramenti e/o modifiche ai
prodotti e/o ai programmi descritti nel manuale in qualsiasi momento e senza
preavviso.
© Copyright IBM Corp. 1994, 2009
351
Tutti i riferimenti a siti Web non IBM contenuti in questo documento sono forniti
solo per consultazione; per essi IBM non fornisce alcuna approvazione. I materiali
disponibili su tali siti Web non fanno parte di questo prodotto IBM e il loro
utilizzo è a discrezione dell’utente.
IBM può utilizzare o divulgare le informazioni ricevute dagli utenti secondo le
modalità ritenute appropriate senza alcun obbligo nei loro confronti.
Coloro che detengono la licenza su questo programma e desiderano avere
informazioni su di esso allo scopo di consentire (i) uno scambio di informazioni tra
programmi indipendenti ed altri (compreso questo) e (ii) l’uso reciproco di tali
informazioni, dovrebbero rivolgersi a:
IBM Corporation
958/NH04
IBM Centre, St Leonards
601 Pacific Hwy
St Leonards, NSW, 2069
Australia
IBM Corporation
896471/H128B
76 Upper Ground
London SE1 9PZ
United Kingdom
IBM Corporation
JBF1/SOM1
294 Route 100
Somers, NY, 10589-0100
U.S.A.
Tali informazioni possono essere disponibili, in base ad appropriate clausole e
condizioni, includendo in alcuni casi, il pagamento di un corrispettivo.
Il programma su licenza descritto in questo manuale e tutto il materiale su licenza
ad esso relativo sono forniti da IBM nel rispetto dei termini dell’IBM Customer
Agreement, dell’IBM International Program License Agreement, o di qualsiasi altro
accordo equivalente tra le parti.
Tutti i dati relativi alle prestazioni contenuti in questo documento sono stati
determinati in un ambiente controllato. Pertanto, i risultati ottenuti in ambienti
operativi diversi possono variare in modo considerevole. Alcune misurazioni
possono essere state effettuate su sistemi a livello di sviluppo e non vi è alcuna
garanzia che tali misurazioni resteranno invariate sui sistemi generalmente
disponibili. Inoltre, alcune misurazioni potrebbero essere state ricavate tramite
estrapolazione. I risultati reali possono variare. Gli utenti di questo documento
devono verificare che i dati siano applicabili al loro specifico ambiente.
Le informazioni relative a prodotti non IBM sono ottenute dai fornitori di quei
prodotti, dagli annunci pubblicati o da altre fonti disponibili al pubblico. IBM non
ha testato quei prodotti e non può confermarne l’accuratezza delle prestazioni, la
compatibilità o qualsiasi altro reclamo relativo ai prodotti non IBM. Eventuali
domande sulle funzionalità dei prodotti non IBM dovranno essere indirizzate ai
fornitori di tali prodotti.
352
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Tutte le dichiarazioni relative all’orientamento o alle intenzioni future di IBM sono
soggette a modifica o a ritiro senza preavviso e rappresentano solo scopi e obiettivi
della IBM stessa.
Queste informazioni contengono esempi di dati e report utilizzati in quotidiane
operazioni aziendali. Per illustrarle nel modo più completo possibile, gli esempi
includono i nomi di individui, società, marchi e prodotti. Tutti questi nomi sono
fittizi e qualsiasi somiglianza con nomi ed indirizzi utilizzati da gruppi aziendali
realmente esistenti è puramente casuale.
LICENZA DI COPYRIGHT:
Queste informazioni contengono programmi applicativi di esempio in linguaggio
sorgente, che illustrano tecniche di programmazione su varie piattaforme operative.
È possibile copiare, modificare e distribuire questi esempi di programmi sotto
qualsiasi forma senza alcun pagamento a IBM, allo scopo di sviluppare, utilizzare,
commercializzare o distribuire i programmi applicativi in conformità alle API
(Application Programming Interface) a seconda della piattaforma operativa per cui
i programmi di esempio sono stati scritti. Questi esempi non sono stati testati
approfonditamente tenendo conto di tutte le condizioni possibili. IBM, pertanto,
non può garantire o sottintendere l’affidabilità, l’utilità o il funzionamento di tali
programmi.
Se questa pubblicazione viene visualizzata in formato elettronico, è possibile che le
fotografie e le illustrazioni a colori non vengano visualizzate.
Marchi
AIX, IBM, il logo IBM, ibm.com, Netcool e Tivoli sono marchi o marchi registrati di
International Business Machines Corporation negli Stati Uniti e/o in altri paesi.
Adobe, Acrobat, PDF (Portable Document Format), PostScript® e tutti i marchi
basati su Adobe sono marchi o marchi registrati di Adobe Systems Incorporated
negli Stati Uniti e/o in altri paesi.
Java e tutti i marchi e i logo basati su Java sono marchi o marchi
registrati di Sun Microsystems, Inc. negli Stati Uniti e/o in altri
paesi.
Linux è un marchio registrato di Linus Torvalds negli Stati Uniti e/o in altri paesi.
Microsoft®, Windows, Windows NT® e il logo Windows sono marchi di Microsoft
Corporation negli Stati Uniti e/o in altri paesi.
UNIX è un marchio registrato di The Open Group negli Stati Uniti e in altri paesi.
Nomi di altre società, prodotti o servizi possono essere marchi di altre società.
Informazioni particolari
353
354
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Indice analitico
A
B
accesso facilitato ix
ADD COLUMN 136
addestramento, tecnico Tivoli x
addestramento tecnico Tivoli x
agent del processo
arresto 270, 289
avvio automatico 254, 255
avvio manuale 247
connessione 50
aggiunta
aggiunta di menu secondari ai
menu 73
aggiunta di separatori ai menu 73
aggiunta di strumenti ai menu 73
colonne 114, 136
colonne di tabella 114, 136
ALTER COLUMN 139
ALTER FILE 146
ALTER GROUP 175
ALTER ROLE 177
ALTER SYSTEM 170
ALTER TABLE 136
ALTER TRIGGER 220
ALTER TRIGGER GROUP 196
ALTER USER 174
arch
directory del sistema operativo x
arresto
agent del processo 289
processi 286
servizi 281
assegnazione di autorizzazioni
ruoli 177
assegnazione di ruoli
gruppi 181
automazioni
configurazione 84
SAE (Service Affected Event) 226
standard 220
automazioni di SAE (Service Affected
Event) 226
autorizzazione
descrizione 58
autorizzazioni
descrizione 58
autorizzazioni dell’oggetto 177
eredità 180
autorizzazioni di sistema 177
avvio
agent del processo 247, 254, 255
interfaccia interattiva SQL 124
Netcool/OMNIbus Administrator 46
processi 285
server proxy 37, 38
servizi 281
avvisi
invio all’ObjectServer 27
azioni esterne
esecuzione 288
browser Web
Netcool/OMNIbus Administrator
© Copyright IBM Corp. 1994, 2009
C
canali
configurazione 120
copia 237
creazione 234
eliminazione 237
modifica 234
operazione di copia e incolla 237
CASE WHEN 189
Centro informazioni per il software
Tivoli viii
CHECK STATEMENT 172
checkpoint
file di checkpoint 24
nco_check_store 25
ObjectServer 24
classi
creazione 110
eliminazione 111
modifica 110
codifica
password 129
password dell’ObjectServer 19
codifica delle password 19, 129
codifica password 41
colonne
aggiunta 114, 136
eliminazione 116, 137
modifica 114, 139
proprietà facoltative 135
tipi di dati 133
colonne di tabella
aggiunta 114, 136
eliminazione 116, 137
modifica 114, 139
colori per la severità
creazione 108
modifica 108
colori per la sintassi SQL
configurazione 56
comandi SQL 347
come ordinare pubblicazioni viii
componenti
controllo processi 242
condizioni 160
configurazione
canali 120
database 111
file 117
filtri limitazioni 70
gruppi 63
notifica eventi accelerati 231, 232,
233, 240
procedure 96
prompt 80
57
configurazione (Continua)
proprietà 116
ruoli 58
segnali 104
strumenti 77
trigger 85
utenti 66
connessione
agent del processo 50, 275
ObjectServer 49
connessioni SSL 52
convalida dei certificati server 52
controllo processi
account utente Windows 246
agent del processo 241
aggiornamento del file di
configurazione 247
aggiunta di processi 271
aggiunta di servizi 271
arresto dei processi 269, 286
arresto dei servizi 269, 281
arresto dell’agent del processo 270
arresto di un agent del processo 289
avvio 244
avvio dei servizi 269, 281
avvio di processi 269, 285
componenti 242
configurazione della comunicazione
del server 246
connessione all’agent del
processo 275
controllo processi
instradamento host 277
copia di processi 287
copia di servizi 287
creazione di gruppi di utenti
UNIX 245
creazione di processi 282
creazione di servizi 279
creazione di una rete 244
definizione degli host di
instradamento 263
definizione degli host sicuri 262
definizione dei processi 257
definizione dei servizi 260
definizione delle dipendenze 260
eliminazione di processi 285
eliminazione di servizi 280
esecuzione di procedure esterne 289
file di configurazione 247
informazioni relative allo stato per un
agent del processo 277
invio di segnali 286
livello di registrazione 277
modifica di processi 282
modifica di servizi 279
nco_pa_addentry 271
nco_pa_shutdown 270
nco_pa_start 269
nco_pa_status 267
nco_pa_stop 269
355
controllo processi (Continua)
nco_pad 247
operazione di copia e incolla sui
processi 287
operazione di copia e incolla sui
servizi 287
opzioni della riga comandi 248
panoramica 241
programmi di utilità 244, 267
visualizzazione dei processi 278
visualizzazione dello stato dei
processi 267
visualizzazione dello stato dei
servizi 267
visualizzazione di servizi 278
convenzioni, carattere tipografico x
convenzioni del carattere tipografico x
convenzioni di denominazione
oggetti ObjectServer 127
conversioni
creazione 107
eliminazione 108
modifica 107
copia
canali 237
processi 287
servizi 287
CREATE DATABASE 130
CREATE FILE 145
CREATE GROUP 175
CREATE INDEX 140
CREATE PROCEDURE 185, 193
CREATE RESTRICTION FILTER 144
CREATE ROLE 176
CREATE SIGNAL 204
CREATE TABLE 133
CREATE TRIGGER 198, 201, 202
CREATE TRIGGER GROUP 195
CREATE USER 173
CREATE VIEW 142
creazione
canali 234
classi 110
colori per la severità 108
conversioni 107
database 112, 130
file 145
file ObjectServer 118
filtri limitazioni 71, 144
gruppi 64, 175
gruppi di trigger 85, 195
indici 140
procedure esterne 99, 193
procedure SQL 96, 185
processi 282
prompt 81
ruoli 61, 176
segnali definiti dall’utente 104, 204
servizi 279
strumenti 77
tabelle 112, 133
trigger di database 86, 198
trigger di segnale 88, 202
trigger temporali 91, 201
utenti 67, 173
viste 142
visuali di colonne 109
356
D
database
configurazione 111
creazione 112, 130
eliminazione 115, 131
inizializzati dal sistema 131
database inizializzati dal sistema 131
definizione
host sicuri 262
definizione dei processi
host di instradamento 263
DELETE 163
DESCRIBE 168
destinatari del manuale vii
dettagli degli indici
visualizzazione 141
dipendenze dei processi 260
directory del sistema operativo
arch x
DROP COLUMN 137
DROP DATABASE 131
DROP FILE 147
DROP GROUP 176
DROP INDEX 141
DROP PROCEDURE 195
DROP RESTRICTION FILTER 144
DROP ROLE 184
DROP SIGNAL 205
DROP TABLE 139
DROP TRIGGER 220
DROP TRIGGER GROUP 197
DROP USER 175
DROP VIEW 143
eliminazione (Continua)
visuali di colonne 110
esecuzione
azioni esterne 288
procedure 194
esempi
nco_postmsg 34
espressioni 160
eventi
invio all’ObjectServer 27
EXECUTE PROCEDURE 194
F
file
configurazione 117
creazione 145
eliminazione 147
modifica 146
file di checkpoint 24
file ObjectServer
creazione 118
eliminazione 119
modifica 118
filtri limitazioni
configurazione 70
creazione 71, 144
eliminazione 72, 144
modifica 71
FOR 191
FOR EACH ROW 190
formazione
consultare addestramento tecnico
Tivoli x
funzioni 154
E
editor esterni per procedure 102
editor esterni per trigger 93
elaborazione avvisi 1
eliminazione
canali 237
classi 111
colonne 116, 137
colonne di tabella 116, 137
conversioni 108
database 115, 131
file 147
file ObjectServer 119
filtri limitazioni 72, 144
gruppi 66, 176
gruppi di trigger 95, 197
indici 141
menu secondari da un menu 76
procedure 104, 195
processi 285
prompt 84
ruoli 63, 184
segnali definiti dall’utente 106, 205
separatori da un menu 76
servizi 280
strumenti 80
strumenti da un menu 76
tabelle 116, 139
trigger 95, 220
utenti 70, 175
viste 143
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
G
generazione
segnali definiti dall’utente 205
GRANT 177
GRANT ROLE 181
gruppi
assegnazione di ruoli 181
configurazione 63
creazione 64, 175
eliminazione 66, 176
modifica 64, 175
predefiniti 63
gruppi di trigger
creazione 85, 195
eliminazione 95, 197
modifica 85, 196
H
host di instradamento
controllo processi 263
host sicuri
controllo processi 262
I
IDUC 21
intervallo di aggiornamento
21
IDUC (Continua)
specifica della porta 21
IDUC EVTFT 218
IDUC FLUSH 170
IDUC SNDMSG 219
IF THEN ELSE 189
indici
creazione 140
eliminazione 141
informazioni sul supporto x
INSERT 162
interfaccia interattiva SQL
avvio 124
esecuzione di comandi 126
modalità GUI 120
modalità sicura 129
notazione della sintassi 126
opzioni della riga comandi 124
reindirizzamento dei file di testo
riga comandi 123
specifica dei percorsi 128
uscita 129
invio di avvisi
nco_postmsg 27
invio di eventi
nco_postmsg 27
invio di segnali
processi 286
isql 123, 124
opzioni della riga comandi 124
L
linee guida per le query SQL 299
ottimizzazione AND 299
ottimizzazione OR 299
regole di ottimizzazione 299
riordino dei predicati 299
linee guide relative
all’indicizzazione 301
M
manuali viii
memstore
archiviazione dei dati
dell’ObjectServer 23
table_store 26
memstore table_store 26
menu
anteprima della struttura 77
modifica 75, 76
personalizzazione 73
menu secondari
aggiunta ai menu 73
eliminazione da un menu 76
migliori pratiche
trigger 305
modalità sicura
interfaccia interattiva SQL 129
ObjectServer 19
server proxy 41
modifica
canali 234
classi 110
colonne 114, 139
128
modifica (Continua)
colonne di tabella 114, 139
colori per la severità 108
conversioni 107
file 146
file ObjectServer 118
filtri limitazioni 71
gruppi 64, 175
gruppi di trigger 85, 196
menu 75, 76
procedure esterne 99
procedure SQL 96
processi 282
prompt 81
ruoli 61, 177
segnali definiti dall’utente 104
servizi 279
strumenti 77
tabelle 136
trigger 220
trigger di database 86
trigger di segnale 88
trigger temporali 91
utenti 67, 174
visuali di colonne 109
monitoraggio
connessioni all’ObjectServer 120
ObjectServer
connessioni 120
N
nco_aes_crypt 19, 41
nco_check_store 25
nco_config 46
opzioni della riga comandi 46
proprietà 46
nco_g_crypt 19, 41
nco_objserv 1
nco_pa_addentry 271
nco_pa_shutdown 270
nco_pa_start 269
nco_pa_status 267
nco_pa_stop 269
nco_pad 247
opzioni della riga comandi 248
nco_postmsg 27
esempi 34
opzioni della riga comandi 31
proprietà 31
nco_proxyserv 38
nco_sql 123, 124
opzioni della riga comandi 124
nco_store_resize 23
opzioni della riga comandi 26
Netcool/OMNIbus Administrator
allineamento delle colonne 55
applicazione di filtri alle righe 55
avvio 46
browser Web per la guida in linea 57
colori per la sintassi SQL 56
configurazione dei colori per la
sintassi 56
copia di oggetti 56
impostazione delle preferenze 54
nascondere colonne 55
nco_config 46
Netcool/OMNIbus Administrator
(Continua)
operazione di copia e incolla su
oggetti 56
opzioni della riga comandi 46
ordinamento delle tabelle dei
risultati 54
proprietà 46
selezione degli oggetti
ObjectServer 53
selezione delle righe da
visualizzare 55
selezione di colonne 55
supporto multiculturale 45
uscita 57
notazione della sintassi SQL 126
notifica eventi accelerati
arresto dei client 239
configurazione 231
configurazione delle regole di
probe 232
configurazione di alerts.status 233
configurazione di canali 233
configurazione di trigger 240
configurazione di un gateway 232
disconnessione dei client 238
invio di messaggi ai destinatari dei
canali 238
O
ObjectServer
ALTER SYSTEM 1
checkpoint 24
configurazione di automazioni 84
connessione 49
conservazione dei file delle tabelle di
database su disco 24
convenzioni di denominazione per gli
oggetti 127
elaborazione avvisi 1
file delle proprietà 1
IDUC 21
intervallo di aggiornamento
IDUC 21
memstore 23
modalità sicura 19
modifica delle proprietà 116
monitoraggio delle connessioni 120
nco_aes_crypt 19
nco_g_crypt 19
opzioni della riga comandi 3
parole riservate 147
precedenza degli operatori 153
proprietà 3
proprietà Granularity 21
ripristino dei dati 25
sequenza di creazione dei file 117
specifica delle opzioni della riga
comandi 1
specifica delle proprietà 1
SQL 123
supporto multiculturale 22
tabelle di sistema 139
visualizzazione delle proprietà 116
operatori 148
confronto binario 149
Indice analitico
357
operatori (Continua)
confronto elenco 151
logici 152
matematici 149
stringa 149
operatori aritmetici 149
operatori di confronto binario 149
operatori di confronto elenco 151
operatori logici 152
operatori stringa 149
operazione di copia e incolla
canali 237
processi 287
servizi 287
opzioni della riga comandi
ObjectServer 3
ottimizzazione delle prestazioni 291
esempi di query SQL 303
esempi di trigger 304
linee guida per le query SQL 299
linee guide relative
all’indicizzazione 301
migliori pratiche 291
P
parole riservate 147
personalizzazione
menu 73
porte
IDUC 21
precedenza degli operatori 153
preferenze
Netcool/OMNIbus Administrator 54
probe
connessione al server proxy 41
procedure
configurazione 96
configurazione di editor esterni 102
creazione 96, 99
creazione in editor esterni 102
eliminazione 104, 195
esecuzione 194
modifica 96, 99
modifica in editor esterni 102
SQL 184
variabili utente implicite 191
procedure esterne
creazione 99, 193
modifica 99
procedure SQL 184
CASE WHEN 189
componenti 184
creazione 96, 185
FOR 191
FOR EACH ROW 190
IF THEN ELSE 189
istruzione del corpo 187
modifica 96
SET 188
processi
arresto 286
avvio 285
copia 287
creazione 282
eliminazione 285
invio di segnali 286
358
processi (Continua)
modifica 282
operazione di copia e incolla
prompt
configurazione 80
creazione 81
eliminazione 84
modifica 81
proprietà
configurazione 116
ObjectServer 3
proprietà facoltative
colonne 135
proprietà Granularity 21
pubblicazioni viii
pubblicazioni in linea viii
pulsanti helper 347
pulsanti helper SQL 347
287
R
raggruppamento mediante il comando
SELECT 167
RAISE SIGNAL 205
regole di ottimizzazione
ottimizzazione AND 299
ottimizzazione OR 299
per query SQL 299
riordino dei predicati 299
REVOKE 181
REVOKE ROLE 183
ruoli
assegnazione di autorizzazioni 177
configurazione 58
creazione 61, 176
eliminazione 63, 184
modifica 61, 177
predefiniti 58
revoca ai gruppi 183
revoca di autorizzazioni 181
S
segnali 207
configurazione 104
segnali definiti dall’utente
creazione 104, 204
eliminazione 106, 205
generazione 205
modifica 104
segnali di sistema 207
SELECT 164
SELECT (aggregazione) 165
SELECT (GROUP BY) 167
SELECT (scalare) 164
SELECT di aggregazione 165
SELECT scalare 164
separatori
aggiunta ai menu 73
eliminazione da un menu 76
server proxy
avvio 37
avvio manuale 38
avvio mediante controllo processi
avvio mediante i servizi 38
connessione di probe 41
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
37
server proxy (Continua)
modalità sicura 41
nco_aes_crypt 41
nco_g_crypt 41
nco_proxyserv 38
opzioni di riga comandi 38
panoramica 37
proprietà 38
servizi
arresto 281
avvio 281
copia 287
creazione 279
eliminazione 280
modifica 279
operazione di copia e incolla 287
SET 188
SET DATABASE 171
strumenti
aggiunta ai menu 73
configurazione 77
creazione 77
eliminazione 80
eliminazione da un menu 76
modifica 77
supporto multiculturale
Netcool/OMNIbus Administrator 45
ObjectServer 22
SVC 169
T
tabella alerts.application_types 320
tabella alerts.col_visuals 336
tabella alerts.colors 337
tabella alerts.conversions 336
tabella alerts.details 318
tabella alerts.iduc_messages 320
tabella alerts.journal 319
tabella alerts.resolutions 335
tabella alerts.status 311
tabella catalog.base_tables 323
tabella catalog.channel_stats 335
tabella catalog.columns 325
tabella catalog.connections 330
tabella catalog.database_triggers 327
tabella catalog.databases 322
tabella catalog.external_procedures 329
tabella catalog.files 324
tabella catalog.indexes 332
tabella catalog.memstores 322
tabella
catalog.primitive_signal_parameters 326
tabella catalog.primitive_signals 325
tabella
catalog.procedure_parameters 329
tabella catalog.procedures 328
tabella catalog.profiles 332
tabella catalog.properties 330
tabella catalog.restrictions 325
tabella catalog.security_permissions 330
tabella catalog.signal_triggers 328
tabella catalog.sql_procedures 328
tabella catalog.tables 323
tabella catalog.temporal_triggers 328
tabella catalog.trigger_groups 326
tabella catalog.trigger_stats 334
tabella catalog.triggers 326
tabella catalog.views 324
tabella iduc_system.channel 342
tabella iduc_system.channel_interest 343
tabella
iduc_system.channel_summary 343
tabella
iduc_system.channel_summary_cols 343
tabella iduc_system.iduc_stats 344
tabella master.class_membership 321
tabella master.national 341
tabella master.servergroups 342
tabella master.stats 333
tabella precision.entity_service 345
tabella
precision.service_affecting_event 344
tabella precision.service_details 344
tabella service.status 321
tabella tools.action_access 339
tabella tools.actions 338
tabella tools.menu_defs 340
tabella tools.menu_items 339
tabella tools.menus 339
tabella tools.prompt_defs 340
tabelle
aggiornamento di colonne 162
creazione 112, 133
eliminazione 116, 139
eliminazione di righe 163
inserimento di righe di dati 162
modifica 136
richiamo dati 164
tabelle alerts 311
tabelle degli strumenti desktop 338
tabelle del catalogo di sistema 322
tabelle dell’ObjectServer
alerts.application_types 320
alerts.col_visuals 336
alerts.colors 337
alerts.conversions 336
alerts.details 318
alerts.iduc_messages 320
alerts.journal 319
alerts.resolutions 335
alerts.status 311
catalog.base_tables 323
catalog.channel_stats 335
catalog.columns 325
catalog.connections 330
catalog.database_triggers 327
catalog.databases 322
catalog.external_procedures 329
catalog.files 324
catalog.indexes 332
catalog.memstores 322
catalog.primitive_signal_param. 326
catalog.primitive_signals 325
catalog.procedure_parameters 329
catalog.procedures 328
catalog.profiles 332
catalog.properties 330
catalog.restrictions 325
catalog.security_permissions 330
catalog.signal_triggers 328
catalog.sql_procedures 328
catalog.tables 323
catalog.temporal_triggers 328
tabelle dell’ObjectServer (Continua)
catalog.trigger_groups 326
catalog.trigger_stats 334
catalog.triggers 326
catalog.views 324
iduc_system.channel 342
iduc_system.channel_interest 343
iduc_system.channel_sum*_cols 343
iduc_system.channel_summary 343
iduc_system.iduc_stats 344
master.class_membership 321
master.national 341
master.servergroups 342
master.stats 333
panoramica 311
precision.entity_service 345
precision.service_affecting_event 344
precision.service_details 344
service.status 321
tabelle alerts 311
tabelle degli strumenti desktop 338
tabelle del catalogo di sistema 322
tabelle desktop 341
tabelle di servizio 321
tabelle di sicurezza 342
tabelle di statistiche 332
tabelle di supporto degli strumenti
client 335
tabelle IDUC 342
tabelle SAE (Service Affected
Event) 344
tools.action_access 339
tools.actions 338
tools.menu_defs 340
tools.menu_items 339
tools.menus 339
tools.prompt_defs 340
tabelle desktop 341
tabelle di servizio 321
tabelle di sicurezza 342
tabelle di sistema 139
tabelle di statistiche 332
tabelle di supporto degli strumenti
client 335
tabelle IDUC 342
tabelle SAE (Service Affected Event) 344
tipi di dati
colonne 133
trigger
configurazione 85
configurazione di editor esterni 93
creazione 86, 88, 91
creazione in editor esterni 94
eliminazione 95, 220
esecuzione di comandi 205
migliori pratiche 305
modifica 86, 88, 91, 220
modifica in editor esterni 94
notifica eventi accelerati 218
variabili 206
variabili implicite 200
variabili utente implicite 191
trigger di database
creazione 86, 198
modifica 86
trigger di segnale
creazione 88, 202
trigger di segnale (Continua)
modifica 88
trigger temporali
creazione 91, 201
modifica 91
U
UPDATE 162
uscita
interfaccia interattiva SQL 129
Netcool/OMNIbus Administrator 57
USE DATABASE 171
utenti
configurazione 66
creazione 67, 173
eliminazione 70, 175
modifica 67, 174
predefiniti 66
visualizzazione delle connessioni 70
V
variabili 191, 200
variabili, notazione per x
variabili di ambiente, notazione
variabili implicite 200
variabili utente implicite 191
viste
creazione 142
descrizione 142
eliminazione 143
visuali di colonne
creazione 109
eliminazione 110
modifica 109
visualizzazione
dettagli degli indici 141
x
W
WRITE INTO
168
Indice analitico
359
360
IBM Tivoli Netcool/OMNIbus: Guida all’amministrazione
Printed in the Republic of Ireland
SC13-4178-00
Scarica