Vous êtes sur la page 1sur 62
IBM ® Tivoli ® Netcool/OMNIbus Gateway for JDBC Versão 4.0 Guia de Referência 6 de

IBM ® Tivoli ® Netcool/OMNIbus Gateway for JDBC

Versão 4.0

Guia de Referência

6 de Julho de 2012

S517-0082-03

IBM ® Tivoli ® Netcool/OMNIbus Gateway for JDBC Versão 4.0 Guia de Referência 6 de

IBM ® Tivoli ® Netcool/OMNIbus Gateway for JDBC

Versão 4.0

Guia de Referência

6 de Julho de 2012

S517-0082-03

Aviso Antes de utilizar estas informações e o produto suportado por elas, leia as informações
Aviso Antes de utilizar estas informações e o produto suportado por elas, leia as informações

Aviso Antes de utilizar estas informações e o produto suportado por elas, leia as informações em “Avisos e Marcas”, na página

de utilizar estas informações e o produto suportado por elas, leia as informações em “Avisos e

47.

estas informações e o produto suportado por elas, leia as informações em “Avisos e Marcas”, na

Aviso de Edição

Esta edição (S517-0082-03) se aplica à versão 4.0 do IBM Tivoli Netcool/OMNIbus Gateway para JDB C e a todas as liberações e modificações subsequentes até que seja indicado de outra forma em novas edições.

Esta edição substitui a SC22-5408-02.

© Copyright IBM Corporation 2011, 2012.

Índice

Sobre este Guia

.

.

.

.

.

.

.v

Página de Controle de Documento

 

.

.

.

.

.v

Convenções Usadas Neste Guia

 

.

.

.

.

.

. vi

IBM Tivoli Netcool/OMNIbus Gateway

 

para JDBC

.

.

.

.

.

.

.

.

.

.

.

.

.1

. Bancos de Dados Suportados .

Resumo .

.

.

.

.

.

.

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.2

.3

 

.

.

.

.

.

.

.

.

.

.3

Obtendo o Gateway Visão Geral do Gateway

. Modo de Auditoria e Modo de Relatório .

.

.

.

.

.

 

.

.

.

.

.

.

.4

.6

Dimensionamento do Banco de Dados

.

.

.

.7

Instalando o Gateway no Tivoli Netcool/OMNIbus

V7.2.0 e 7.2.1 .

.

.

.

.

.

.

.

.

.

.

.

. 10

. Visão Geral da Instalação

 

.

.

.

.

.

.

. 11

Instalando as Bibliotecas dos Modos de Auditoria

e de Relatório .

.

.

.

.

.

.

.

.

.

.

.

. 11

Instalando o Gateway nos Sistemas Operacionais

UNIX e Linux

.

.

.

.

.

.

.

.

.

.

.

. 12

Instalando o Gateway nos Sistemas Operacionais

Windows .

.

.

.

.

.

.

.

.

.

.

.

.

. 12

Instalando o Gateway no Tivoli Netcool/OMNIbus

V7.3.0, V7.3.1 ou Posterior

 

.

.

.

.

.

.

. 13

Visão Geral da Instalação

.

.

.

.

.

.

. 13

Instalando as Bibliotecas dos Modos de Auditoria

e de Relatório

.

.

.

.

.

.

.

.

.

.

.

. 13

Instalando o Gateway nos Sistemas Operacionais

UNIX e Linux

.

.

.

.

.

.

.

.

.

.

.

. 14

Instalando o Gateway nos Sistemas Operacionais

Windows

.

.

.

.

.

.

.

.

.

.

.

. 14

Configurando variáveis de ambiente

.

.

.

. 15

Configurando Detalhes de Comunicação

Configurando o Esquema do Banco de Dados .

.

.

. 16

. 16

Migrando de um Gateway Existente

.

. 17

Configurando a Conexão com o Banco de Dados .

. 17

.

.

.

.

.

.

.

.

. 20

Configurando o Gateway . Arquivo de propriedades

. Propriedades e Opções da Linha de Comandos

Arquivo de Definição de Mapas

.

.

.

.

.

.

.

. 21

21

. 35

. Arquivo de Comando de Inicialização

.

.

.

.

. 36

Transferências de Tabelas Arbitrárias .

.

.

. 36

Arquivo de Definição de Replicação da Tabela.

Funções AfterIDUC e de Filtro .

.

.

.

.

. 37

. 38

. Usando um Campo de Particionamento .

.

.

. 39

Filtrando Dados de Ressincronização .

.

.

.

. 39

Arquivo de Log de Mensagens .

.

.

.

.

.

. 40

Modo FIPS e Criptografia

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

. 41

Estatísticas do Gateway .

.

.

. 41

Mensagens de erro

.

.

. 42

Mensagens de Erro de JDBC

.

.

.

.

.

. 43

Executando o Gateway

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

. 44

Problemas Conhecidos .

.

.

. 45

Rótulo de Tabela Customizada .

.

.

.

.

.

. 45

. Esquemas de Nomenclatura do Sybase .

Estados de Erro de SQL .

.

.

.

.

.

.

.

.

. 45

. 46

Apêndice. Avisos e Marcas

Avisos .

.

.

.

.

.

.

.

.

.

.

.

.

.

47

. 47

. Marcas Registradas .

.

.

.

.

.

.

.

.

.

.

. 49

Sobre este Guia

As seções a seguir contêm informações importantes sobre como usar este guia.

Página de Controle de Documento

Use estas informações para rastrear mudanças entre as versões deste guia.

A documentação do IBM Tivoli Netcool/OMNIbus Gateway para JDBC é fornecida apenas em formato eletrônico. Para obter a versão mais recente, visite o Centro de Informações do IBM ® Tivoli Netcool:

Tabela 1. Histórico de Modificação de Documento

Versão do

Data de

 

Documento

publicação

Comentários

SC22-5408-00

02

de dezembro

Primeira publicação da IBM.

de 2011

SC22-5408-01

16

de dezembro

Informações sobre requisitos atualizadas em “Resumo” na página 2.

de 2011

Informações sobre biblioteca de scripts atualizadas em “Obtendo o Gateway” na página 3.

S517-0082-02

02

de março de

Informações sobre requisitos atualizadas em

2012

“Resumo” na página 2.

Lista de bancos de dados suportados atualizada em “Bancos de Dados Suportados” na página 3.

Informações sobre como obter o gateway atualizadas em “Obtendo o Gateway” na página 3.

Informações sobre configuração do banco de dados atualizadas em “Configurando a Conexão com o Banco de Dados” na página 17.

Problema de esquema de nomenclatura do Sybase descrito em “Problemas Conhecidos” na página 45.

Tabela 1. Histórico de Modificação de Documento (continuação)

Versão do

Data de

 

Documento

publicação

Comentários

S517-0082-03

6 de Julho de

Versão do pacote atualizada em “Resumo” na página

2012

2.

Descrições da propriedade Gate.Jdbc.Url para uso com o DB2 LUW e DB2 z/OS atualizados em “Configurando a Conexão com o Banco de Dados” na página 17.

“Propriedades e Opções da Linha de Comandos” na página 21 atualizado.

Informações de replicação de tabela do ObjectServer atualizadas em “Arquivo de Definição de Replicação da Tabela” na página 37.

“Funções AfterIDUC e de Filtro” na página 38 incluído.

“Rótulo de Tabela Customizada” na página 45 incluído.

Convenções Usadas Neste Guia

Todos os guias de gateway usam convenções padrão para variáveis de ambientes e caminhos do diretório dependentes do sistema operacional.

Variáveis e Caminhos Dependentes do Sistema Operacional

Todos os guias de gateway usam convenções padrão para especificar variáveis de ambiente e descrever caminhos do diretório, dependendo do sistema operacional em que o gateway é suportado.

Para gateways suportados nos sistemas operacionais UNIX e Linux, os guias de gateway usam convenções UNIX padrão como $ variable para variáveis de ambiente e barras ( /) nos caminhos do diretório. Por exemplo:

$OMNIHOME/gates

Para gateways suportados somente nos sistemas operacionais Windows, os guias de gateway usam convenções Windows padrão como % variable % para variáveis de ambiente e barras invertidas ( \ ) nos caminhos do diretório. Por exemplo:

%OMNIHOME%\gates

Para gateways suportados nos sistemas operacionais UNIX, Linux e Windows, os guias de gateway usam convenções UNIX padrão para especificar variáveis de ambiente e descrever caminhos do diretório. Ao usar a linha de comandos do Windows com esses gateways, substitua as convenções UNIX usadas no guia com convenções Windows. Se você estiver usando o shell bash em um sistema Windows, será possível usar as convenções UNIX.

Nota: Os nomes das variáveis de ambiente nem sempre são os mesmos nos ambiente Windows e UNIX. Por exemplo, %TEMP% em ambientes Windows é equivalente a $TMPDIR em ambientes UNIX e Linux.

Nomes de Diretório Específicos do Sistema Operacional

Onde os arquivos do Tivoli Netcool/OMNIbus são identificados como localizados em um diretório arch em NCHOME ou OMNIHOME, arch é uma variável que representa seu diretório de sistema operacional. Por exemplo:

$OMNIHOME/gates/arch/

A tabela a seguir lista os nomes de diretório usados para cada sistema operacional suportado.

Tabela 2. Nomes do Diretório para a Variável arch

Sistema Operacional

Nome do diretório representado por arch

Sistemas AIX

aix5

Sistemas baseados em HP-UX PA-RISC

hpux11

Sistemas baseados na Integridade HP-UX

hpux11hpia

Sistemas Red Hat Linux e SUSE

linux2x86

Linux para System z

linux2s390

Sistemas Solaris

solaris2

Sistemas Windows

win32

IBM Tivoli Netcool/OMNIbus Gateway para JDBC

O IBM Tivoli Netcool/OMNIbus Gateway para JDBC usa a API Java Database

Connectivity (JDBC) padrão para trocar alertas entre ObjectServers Netcool/OMNIbus e bancos de dados externos. Ele se comunica com os bancos de dados suportados usando drivers JDBC Java Tipo 4 fornecidos pelos fornecedores dos bancos de dados.

O Gateway para JDBC pode ser usado como um substituto do Tivoli

Netcool/OMNIbus Gateway para ODBC e do Tivoli Netcool/OMNIbus Gateway

para Oracle.

O

Gateway para JDBC possui os seguintes recursos:

v

Modos de operação de relatório e de auditoria.

v

Capacidade Store and forward (SAF) usando cache de eventos persistente e encaminhamento de dados.

v

Ressincronização na inicialização.

v

Escalabilidade fornecida por diversas conexões com o banco de dados.

v

Transferências de tabela arbitrárias.

v

Migração de bancos de dados de destino existentes usando ressincronização bidirecional.

Este guia contém as seguintes seções:

v

“Resumo” na página 2

v

“Bancos de Dados Suportados” na página 3

v

“Obtendo o Gateway” na página 3

v

“Visão Geral do Gateway” na página 4

v

“Modo de Auditoria e Modo de Relatório” na página 6

v

“Dimensionamento do Banco de Dados” na página 7

v

“Instalando o Gateway no Tivoli Netcool/OMNIbus V7.2.0 e 7.2.1” na página 10

v

“Instalando o Gateway no Tivoli Netcool/OMNIbus V7.3.0, V7.3.1 ou Posterior” na página 13

v

“Configurando variáveis de ambiente” na página 15

v

“Configurando Detalhes de Comunicação” na página 16

v

“Configurando o Esquema do Banco de Dados” na página 16

v

“Configurando a Conexão com o Banco de Dados” na página 17

v

“Configurando o Gateway” na página 20

v

“Estatísticas do Gateway” na página 41

v

“Mensagens de erro” na página 42

v

“Executando o Gateway” na página 44

v

“Problemas Conhecidos” na página 45

Resumo

Cada gateway funciona de um modo diferente para prover uma interface ao ObjectServer. Este resumo descreve as características básicas do gateway.

A tabela a seguir fornece um resumo do gateway.

Tabela 3. Resumo

Destino do gateway

DB2 LUW, DB2 z/OS, Informix, Microsoft SQL Server, MySQL, Oracle, Sybase

Consulte “Bancos de Dados Suportados” na página 3 para obter detalhes das versões suportadas.

Nome do arquivo executável do gateway

nco_g_jdbc

Pacote de instalação do gateway

omnibus-arch-gateway-nco-g-jdbc-version

Versão do pacote

4,0

Gateway suportado em

Para obter detalhes dos sistemas operacionais suportados, consulte o Aviso de Liberação a seguir no Web site de Suporte de Software IBM:

Arquivo de propriedades

$OMNIHOME/etc/G_JDBC.props

Requisitos

IBM Tivoli Netcool/OMNIbus V7.2.0 (ou posterior).

Biblioteca de scripts do modo de auditoria (necessária para executar o gateway no modo de auditoria):

gateway-nco-g-jdbc-audit-scripts-1_0

Biblioteca de scripts do modo de relatório (necessária para executar o gateway no modo de relatório):

gateway-nco-g-jdbc-reporting-scripts-1_0

A

instalação no IBM Tivoli Netcool/OMNIbus V7.2.0 ou

7.2.1 requer as seguintes bibliotecas:

v

Gateway Java Support Package: gateway-libngjava-5_0 (ou posterior)

v

Gateway NGtkTK Support Package: gateway-libngtktk- 4_0 (ou posterior)

A

instalação no IBM Tivoli Netcool/OMNIbus V7.2.0 requer

a biblioteca common-libncrypt-1_0 .

Licenciamento

A

licença eletrônica foi reprovada com o release do IBM

Tivoli Netcool V7.2.0. Todos os produtos IBM Tivoli Netcool V7.2.0 (e posterior) usam o processo de licença de software da IBM.

Suporte multicultural

Não disponível

Ambiente IP

IPv4 e IPv6

Nota: O suporte a IPv6 para a conexão com o banco de dados depende do driver JDBC. Consulte a documentação

de seu driver JDBC para obter informações sobre o suporte

a

IPv6.

Tabela 3. Resumo (continuação)

Federal Information Processing Standards (FIPS)

IBM Tivoli Netcool/OMNIbus V7.2.1, 7.3.0 e 7.3.1 usam o provedor criptográfico aprovado por FIPS 140-2: IBM Crypto para C (ICC), certificado 384 para criptografia. Esse certificado está listado no website do NIST em http://csrc.nist.gov/cryptval/140-1/1401val2004.htm. Para obter detalhes sobre a configuração do Netcool/OMNIbus para o modo FIPS 140-2, consulte o IBM Tivoli Netcool/OMNIbus Installation and Deployment Guide

(SC14-7604-00).

Bancos de Dados Suportados

O

Gateway para JDBC é suportado para uso com os bancos de dados listados aqui.

O

gateway é suportado para uso com os bancos de dados e drivers JDBC listados

na tabela a seguir.

Tabela 4. Bancos de Dados e Drivers JDBC Suportados

Banco de dados

Driver JDBC

DB2 LUW 9.5 e 9.7

DB2 Type 4 Universal Driver

(

com.ibm.db2.jcc.DB2Driver )

DB2 z/OS 10

DB2 Type 4 Universal Driver

(

com.ibm.db2.jcc.DB2Driver )

Informix 11.5 e 11.7

IBM Informix JDBC Driver

(

com.informix.jdbc.IfxDriver )

Microsoft SQL Server 2005 e 2008

Microsoft SQL Server Driver for JDBC

(

com.microsoft.sqlserver.jdbc.SQLServerDriver )

Nota: O JRE 1.5 requer o driver Microsoft JDBC 3, enquanto o JRE 1.6 requer o driver Microsoft JDBC 4. Os detalhes podem ser encontrados no website da Microsoft. Nota: No OMNIbus 7.3.1 que é baseado no JRE 1.6, somente o arquivo sqljdbc4.jar pode ser usado. Para versões do OMNIbus mais antigas que 7.3.1, o sqljdbc.jar é usado. Ambos os arquivos .jar não podem estar no $CLASSPATH ou no local $OMNIHOME/gates/java simultaneamente.

MySQL 5.0 e 5.1

MySQL Connector/J ( com.mysql.jdbc.Driver )

Oracle 10g e 11g

Oracle JDBC Thin Driver

(

oracle.jdbc.driver.OracleDriver )

Sybase 12.5 e 15.5

Sybase jConnect for JDBC

(

com.sybase.jdbc4.jdbc.SybDriver )

Obtendo o Gateway

O pacote de instalação do gateway e os componentes relacionados estão

disponíveis para download da IBM.

É possível obter o pacote de instalação do gateway e os componentes relacionados

no website do IBM Passport Advantage Online, na seguinte URL:

Para instalações do gateway no IBM Tivoli Netcool/OMNIbus V7.2.1 (e anteriores), o Gateway Java Support Package ( gateway-libngjava ) e o Gateway NGtkTK Support Package ( gateway-libngtktk ) são fornecidos separadamente do pacote de instalação do gateway, e podem ser obtidos no website do IBM Passport Advantage Online.

Para instalações no IBM Tivoli Netcool/OMNIbus V7.3.0 (e posteriores), o Gateway Java Support Packag e e o Gateway NGtkTK Support Package são empacotados com o pacote de instalação do gateway.

Você deve obter os drivers JDBC para o banco de dados de destino do fornecedor do banco de dados.

Visão Geral do Gateway

O Gateway para JDBC usa o Gerenciador JDBC integrado no IBM JVM (fornecido

com o Tivoli Netcool/OMNIbus) para trocar alertas entre ObjectServers Netcool/OMNIbus e bancos de dados externos. Ele se comunica com os bancos de dados suportados usando drivers JDBC Java Tipo 4 fornecidos pelos fornecedores dos bancos de dados.

Operação do Gateway

No modo de ressincronização unidirecional padrão, o gateway processa ciclos Insert, Delete, Update, Control (IDUC) da seguinte maneira:

1.

O

componente leitor-gravador recebe dados do ObjectServer.

2.

O

componente leitor-gravador formata os dados em um mapa, usando nomes

de campos como chaves, e passa os dados mapeados para o componente Gerenciador do gateway.

3.

O

componente gerenciador usa o tipo da tabela de origem (status, diário ou

detalhes ) e o estado do ciclo de vida do alerta (o alerta existe ou não no cache

do gateway) para formar a instrução SQL necessária para enviar a atualização do alerta para o banco de dados de destino.

4.

O

componente gerenciador grava a instrução SQL no lote atual.

Se

não existir um lote, o componente gerenciador cria um.

5.

O

componente gerenciador processa todos os dados no ciclo IDUC atual, salva

o lote em disco e coloca o lote na fila no cache do gateway.

O

cache é salvo como parte desse processo.

6.

O

componente consumidor lê o lote da fila, lendo-o do disco se necessário.

7.

O

componente consumidor processa todas as instruções SQL contidas no lote.

8.

O

componente processador executa partes do lote atomicamente.

Persistência e Confiabilidade

O gateway gerencia duas partes de dados persistentes: o cache de alertas

conhecidos e lotes pendentes, e os próprios lotes. Os lotes somente são processados depois que o lot e e o cache tiverem sido salvos com êxito no disco. Se o gateway encerrar inesperadamente, deve ser possível recuperar o estado confirmado sem duplicar ou perder dados.

Nota: Uma recuperação bem-sucedida também depende da operação correta do JVM subjacente e do sistema operacional do host.

O mecanismo de envio em lote opera efetivamente como um mecanismo store and

forward (SAF). Erros fatais, tais como erros na análise de SQL ou erros de restrição, resultam em os dados inválidos serem registrados em log e, em seguida, descartados.

O gateway também suporta atualizações atômicas e duráveis ao cach e e a arquivos

em lote. Isso protege contra a distorção de dados e assegura que os dados na área

de trabalho do gateway sejam sempre válidos.

Ressincronização

O gateway pode executar dois tipos de ressincronização: unidirecional e

bidirecional. A propriedade Gate.Jdbc.ResyncMode fornece quatro modos de ressincronização para controlar como o gateway executa ressincronizações.

Os seguintes modos de ressincronização estão disponíveis:

1.

nenhum

 

O

gateway não executa ressincronização.

2.

Unidirecional

O

gateway compara o conteúdo de seu cache com o conteúdo da tabela

alerts.status do ObjectServer. Alertas novos, excluídos e atualizados são

encaminhados para o banco de dados de destino, ressincronizando-o assim com

o

ObjectServer.

3.

Bidirecional

O

gateway armazena inicialmente em seu cache os alertas abertos armazenados

no banco de dados de destino. Em seguida, ele compara o conteúdo de seu cache com o conteúdo da tabela alerts.status do ObjectServer e ressincroniza

o

banco de dados de destino de acordo com isso.

Nota: A ressincronização bidirecional resulta em varreduras integrais da tabela na tabela de status do banco de dados de destino. Uma grande quantia de histórico de eventos resultará em uma longa ressincronização.

4.

Automática

Este é o modo padrão de ressincronização. Ele faz com que o gateway opere no modo de ressincronização unidirecional por padrão. No entanto, se o cache do gateway estiver vazio na inicialização (o que normalmente ocorre somente na primeira vez que o gateway é executado), ele faz com que o gateway opere no modo de ressincronização bidirecional. Nesse modo, somente as tabelas alerts.status e alerts.journal do ObjectServer são ressincronizadas ao banco de dados de destino. É possível ressincronizar manualmente outras tabelas do ObjectServer usando comandos de transferência.

Deduplicação

O gateway deduplica atualizações de alertas e diários. Isso resulta em

ressincronização eficiente, porque somente alertas que foram alterados são encaminhados para o banco de dados de destino. Também significa que atualizações a campos que não estão incluídos no arquivo de definição de mapa, ou campos que não são requeridos no banco de dados de destino (tais como campos de mudança de estado), são ignorados.

Modo de Auditoria e Modo de Relatório

O gateway pode operar em um de dois modos, modo de auditoria ou modo de

relatório. No modo de auditoria, o gateway arquiva eventos em um banco de dados de destino para propósitos de auditoria. No modo de relatório, o gateway arquiva eventos em um banco de dados de destino para uso com ferramentas de relatório tais como o Tivoli Netcool/Reporter ou o Tivoli Common Reporting.

Modo de Auditoria

Se desejar executar o gateway no modo de auditoria, você deverá configurar o esquema apropriado do banco de dados. Se estiver usando o Gateway para JDBC como substituto do Gateway para Oracle ou do Gateway para ODBC, sua configuração existente do banco de dados de destino pode não requerer nenhuma mudança. Caso contrário, você deverá instalar a biblioteca gateway-nco-g-jdbc- audit-scripts . Essa biblioteca contém os scripts SQL necessários para criar o esquema do banco de dados de destino.

O

modo de auditoria é suportado para os seguintes bancos de dados:

v

DB2

v

Informix

v

Microsoft SQL Server

v

MySQL

v

Oracle

v

Sybase

No modo de auditoria, uma nova linha é criada na tabela do banco de dados para cada novo alerta e atualização de alerta. O banco de dados de destino pode conter diversas linhas para cada alerta, dependendo de seu histórico de atualização. No modo de auditoria, dados existentes no banco de dados de destino nunca são atualizados ou excluídos.

Inserções, atualizações e exclusões são mapeados da seguinte maneira:

v

Novos alertas fazem com que uma nova linha seja inserida no banco de dados de destino.

v

Atualizações de alertas fazem com que uma nova linha contendo os valores do alerta atualizado seja inserida no banco de dados de destino. Os valores de alertas anteriores são preservados em linhas criadas anteriormente.

v

Exclusões de alertas fazem com que uma nova linha contendo os valores finais do alerta seja inserida no banco de dados de destino. A maioria dos dados do alerta não está mais disponível no momento da exclusão, portanto, a linha de exclusão conterá principalmente valores NULL. Os valores de alertas anteriores são preservados em linhas criadas anteriormente.

Modo de Relatório

Se desejar executar o gateway no modo de relatório, você deverá configurar o esquema apropriado do banco de dados. Se estiver usando o Gateway para JDBC como substituto do Gateway para Oracle ou do Gateway para ODBC, sua configuração existente do banco de dados de destino pode não requerer nenhuma mudança. Caso contrário, você deverá instalar a biblioteca gateway-nco-g-jdbc- reporting-scripts . Essa biblioteca contém os scripts SQL necessários para criar o esquema do banco de dados de destino.

O

modo de relatório é suportado para os seguintes bancos de dados:

v

DB2

v

Informix

v

Microsoft SQL Server

v

Oracle

v

Sybase

No modo de relatório, o banco de dados de destino contém uma linha para cada novo alerta e essa linha é atualizada sempre que o alerta é atualizado. Isso requer que o banco de dados de destino seja configurado para relatório, o que envolve vários acionadores para gerar os dados do relatório. No modo de relatório, o gateway essencialmente replica a tabela de status da origem do ObjectServer para o banco de dados de destino.

Inserções, atualizações e exclusões são mapeados da seguinte maneira:

v

Novos alertas fazem com que uma linha, exclusiva para o alerta, seja inserida no banco de dados de destino.

v

Atualizações de alertas fazem com que a linha do alerta existente seja atualizada com os novos valores do alerta.

v

Exclusões de alertas fazem com que a linha do alerta existente seja atualizada com um registro de data e hora da exclusão.

Dimensionamento do Banco de Dados

Os fatores principais que afetam o crescimento do banco de dados (e portanto os requisitos de dimensionamento de seu banco de dados) são: o tamanho de um evento, a taxa à qual os eventos são passados para o banco de dados e a combinação do modo operacional do gateway (auditoria ou relatório ) e a mistura de tipos de evento (inserção, atualização ou exclusão). Os tópicos a seguir discutem esses fatores e como avaliar seu sistema para determinar os requisitos de dimensionamento ideais.

Tamanho do Evento do Netcool/OMNIbus

O tamanho da linha do banco de dados de destino deve corresponder

proximamente ao tamanho do evento do Netcool/OMNIbus. Isso é devido aos esquemas de banco de dados fornecidos espelharem amplamente o esquema do Netcool/OMNIbus.

O

tamanho de uma linha ou evento individual depende dos seguintes fatores:

v

Tamanhos de campos individuais

v

Se campos customizados foram incluídos

v

Se campos padrão foram omitidos

v

Se campos estão realmente preenchidos com dados

O

tamanho de campo máximo permissível pode ser determinado descrevendo as

tabelas do ObjectServer executando nco_sql e executando os seguintes comandos:

describe

>

>go

alerts.status

O tamanho máximo possível de um evento pode ser determinado por uma soma

dos tamanhos dos campos de uma tabela.

A tabela a seguir mostra os tamanhos de linha máximos permissíveis para uma

instalação padrão do Netcool/OMNIbus 7.3.1:

Tabela

Tamanho máximo de linha

alerts.status

10284 bytes

alerts.journal

4347

bytes

alerts.details

1028

bytes

A tabela a seguir mostra os tamanhos de linha típicos que você provavelmente

encontrará na maioria das aplicações práticas:

Tabela

Tamanho típico operacional de linha

alerts.status

2048

bytes

alerts.journal

512 bytes

alerts.details

0 bytes

Taxa de Eventos

A taxa à qual os eventos são passados para o gateway para encaminhamento ao

banco de dados pode ser avaliada empiricamente (observada durante um período de tempo), ou uma avaliação do rendimento esperado ou requerido pode ser feita.

A extensão com que o rendimento está correlacionado à entrada de origens de

dados tais como análises pode ser afetada significativamente pela deduplicação. A

deduplicação converte inserções no ObjectServer (com os mesmos valores de Identifier ) em atualizações (aumentando incrementalmente o campo Tally ), limitando assim o tamanho do ObjectServer e potencialmente limitando o tamanho do banco de dados de destino. O efeito da deduplicação pode ser o de reduzir o volume de dados por um fator de 10. Para calcular a redução de volume que a deduplicação tem sobre um determinado fluxo de dados, calcule a proporção de eventos reais para eventos inseridos em alerts.status dividindo o cálculo sum(Tally) pela contagem count(*) .

Condições de filtro aplicadas na configuração do gateway também restringirão o interesse do gateway a um subconjunto de eventos colocados no ObjectServer, e portanto limitarão o tamanho do banco de dados de destino.

Modo de Operação

Os gateways de banco de dados operam em um de dois modos:

v

Auditoria: No modo de auditoria, todos os tipos de eventos do Netcool/OMNIbus (inserções, atualizações e exclusões) são encaminhados como inserções, mantendo assim uma trilha de auditoria no banco de dados de destino, sujeita à (ou restringida pela) granularidade do ciclo IDUC.

v

Relatório: No modo de relatório, atualizações e exclusões do Netcool/OMNIbus são encaminhadas como atualizações a linhas inseridas anteriormente.

Um gateway operando no modo de relatório provavelmente preencherá o banco de dados com menos dados. No entanto, acionadores incluídos nos esquemas de banco de dados padrão preenchem tabelas adicionais com dados resumidos, a partir das quais os relatório são executados. Tipicamente, uma tabela adicional será preenchida e mantida no banco de dados para cada relatório que possa ser

executado. Essas tabelas são relativamente pequenas em comparação com a tabela de status principal; consulte adiante para obter informações adicionais.

Nota: Os gateways de banco de dados não excluem linhas de tabelas do banco de dados de destino. Portanto, os bancos de dados de destino crescerão em tamanho indefinidamente se não ocorrer remoção ou arquivamento do banco de dados como uma atividade separada. Isso independe do modo de operação do gateway.

Tabelas Monitoradas

A configuração do gateway determina quais tabelas do Netcool/OMNIbus são monitoradas. A maioria dos usuários configura gateways para monitorar apenas a

tabela alerts.status , mas é possível também monitorar as tabelas alerts.journal

e alerts.details . A tabela alerts.details , mesmo se monitorada pelo gateway,

geralmente não é preenchida com dados em configurações padrão de análise. Em geral, ela é preenchida somente em cenários de depuração ou configuração. Atualmente, nenhum dos relatórios padrão do gateway de banco de dados depende de dados recebidos da tabela alerts.details .

Embora os gateways de banco de dados sejam usados primariamente para receber dados das três tabelas principais (status, diários e detalhes), outras tabelas podem ser monitoradas em uma configuração customizada. Isso impactaria os requisitos de tamanho do banco de dados.

Entradas no Diário

As entradas no diário se enquadram em duas categorias principais: aquelas geradas automaticamente por automações, por exemplo, quando um evento é reconhecido ou excluído por uma ferramenta de clique com o botão direito definida no visualizador de eventos, e aquelas criadas por usuários. Os diários gerados automaticamente geralmente são curtos , e o proporção do número de entradas no diário para o número de eventos é baixa. O tamanho dos diários gerados pelo usuário é determinado pelo comportamento ou pela política do usuário individual.

Tabelas de Relatório

Conforme mencionado anteriormente, os esquemas de relatório contêm outras tabelas além das análogas das três tabelas principais do Netcool/OMNIbus (status, diário e detalhes). Essas tabelas se enquadram em duas categorias: tabelas das quais relatórios são gerados (uma por definição de relatório; atualmente existem quatro, geralmente chamadas rep_audit_fieldname , e contendo uma linha por evento de status) e tabelas de dados na maioria estáticos ou que raramente mudam. O segundo tipo são geralmente pequenas e podem ser ignoradas em cálculos de dimensionamento, ou absorvidas nas margens de erro. As linhas em tabelas usadas para gerar relatórios tipicamente têm menos que 256 bytes.

Implementação e Ajuste do Destino

A multiplicação da taxa de eventos pelo tamanho do evento fornece uma boa

estimativa bruta do tamanho do banco de dados de destino, mas a implementação

e os ajustes do banco de dados podem facilmente e significativamente aumentar

esses cálculos. Um fator a ser considerad o é o tamanho de bloco e quão vazio ou

cheio você permite que os blocos de dados estejam quando são atualizados.

Dependendo da implementação do banco de dados e do nível de ajuste, é possível esperar aumentar a estimativa bruta por um fator de dois a quatro.

Avaliando o Sistema

Uma maneira de avaliar o sistema seria executar o Gateway de Arquivo Simples e monitorar o crescimento de seu arquivo de saída. No entanto, observe que a saída desse gateway será mais próxima à de um gateway de banco de dados executando no modo de auditoria que no modo de relatório, porque todos os tipos de eventos são gravados (análogo a inseridos) no arquivo de saída. Não obstante, uma análise do arquivo de saída fornecerá uma percepção sobre a combinação de inserções e atualizações encontradas em um determinado sistema. Para um gateway de banco de dados executando no modo de relatório, atualizações e exclusões podem ser grandemente descontadas nos cálculos.

Nota: Números inteiros com 4 bytes em um ObjectServer se igualarão a quantias de dados muito maiores na saída do Gateway de Arquivo Simples devido a sua representação em formato de caractere.

Use a seguinte fórmula para calcular um requisito bruto de dimensionamento de banco de dados anual:

<inserções

por

dia>

*

(<bytes

por

evento>

+

(<número

de

tabelas

de

relatório>

*

<bytes

por

linha

de

tabela

de

relatório>)

*

<52

semanas>

*

<7

dias>)

/

<bytes

por

GB>

 

For exemplo, usando os seguintes valores:

 

v

10.000 inserções por dia, após deduplicação

 

v

2048 bytes por evento

 

v

4 tabelas de relatório

v

256 bytes por linha de tabela de relatório

 

v

52 semanas

 

v

diários e detalhes não incluídos

 

O

requisito de armazenamento do banco de dados anual seria:

 

(10000

*

(2048

+

(4

*

256))

*

52

*

7)

/

1024^3

=

10.4

GB

<inserções

por

dia>

*

(<bytes

por

evento>

+

(<número

de

tabelas

de

relatório>

*

<bytes

por

linha

de

tabela

de

relatório>)

*

<52

semanas>

*

<7

dias>)

/

<bytes

por

GB>

 

Instalando o Gateway no Tivoli Netcool/OMNIbus V7.2.0 e 7.2.1

O processo de instalação de gateways no Tivoli Netcool/OMNIbus V7.2.0 e 7.2.1

consiste no download do pacote de instalação adequado e na instalação de cada uma das correções contidas no pacote.

O pacote de instalação e as correções para o gateway são fornecidos como

arquivos. O aplicativo de gerenciamento de archive que você usa para extrair os arquivos deve estar apto a preservar a estrutura de diretório contida no archive na extração.

Visão Geral da Instalação

O Gateway para JDBC e seus pacotes relacionados são instalados conforme descrito a seguir.

Você deve instalar o gateway e os componentes associados na seguinte ordem:

1. Instale o pacote do modo de relatório ou do modo de auditoria, conforme necessário.

2. Instale o Gateway Java Support Package ( gateway-libngjava ) e o Gateway NGtkTK Support Package ( gateway-libngtktk ) de acordo com as instruções fornecidas com seus pacotes de instalação.

3. Instale o gateway.

4. Instale os drivers JDBC para o banco de dados de destino.

Você deve obter os drivers do fornecedor do banco de dados e instalá-los de acordo com as instruções do fornecedor.

Para obter mais informações, consulte o manual “Configurando a Conexão com o Banco de Dados” na página 17.

Instalando as Bibliotecas dos Modos de Auditoria e de Relatório

Para executar o gateway no modo de auditoria ou de relatório, você deve configurar o esquema de banco de dados apropriado. Se estiver usando o Gateway para JDBC como substituto do Gateway para Oracle ou do Gateway para ODBC, sua configuração existente do banco de dados de destino pode não requerer nenhuma mudança. Caso contrário, você deverá instalar a biblioteca gateway-nco-g-jdbc-audit-scripts ou a biblioteca gateway-nco-g-jdbc-reporting- scripts , conforme necessário. Essas bibliotecas contêm os scripts necessários para criar os esquemas do banco de dados de destino.

Para instalar a biblioteca de scripts de auditoria ou a biblioteca de scripts de relatório, use as seguintes etapas:

1. Extraia os arquivos no archive do pacote para um diretório temporário, temp .

2. Instale o pacote requerido da seguinte maneira:

v

Em sistemas operacionais UNIX e Linux, execute o seguinte comando:

$OMNIHOME/install/nco_patch -install /temp/script_package

v

Em sistemas operacionais Windows, copie todos os arquivos no diretório temp\patches\script_package\gates para o seguinte diretório:

%OMNIHOME%\gates

em que script_package é o pacote de scripts de auditoria ou o pacote de scripts de relatório, conforme necessário.

Os scripts instalados estão localizados no diretório $OMNIHOME/gates/audit ou $OMNIHOME/gates/reporting .

Depois de instalar os scripts, é possível usá-los para criar um esquema do banco de dados para uso com o gateway. Para obter mais informações, consulte o manual “Configurando o Esquema do Banco de Dados” na página 16.

Instalando o Gateway nos Sistemas Operacionais UNIX e Linux

Para instalar o gateway nos sistemas operacionais UNIX e Linux, use as seguintes etapas:

1. Faça download do pacote de instalação para o gateway no Web site do Passport Advantage Online:

2. Faça um backup de todos os arquivos de configuração existentes que você queira manter.

3. Extraia o conteúdo do pacote de instalação para um diretório temporário.

4. No diretório temporário, localize e leia o arquivo README.txt .

O arquivo README.txt dirá se você precisa fazer download de alguma correção

adicional no Web site do Passport Advantage Online.

5. Localize o diretório patches (no diretório que contém o arquivo README.txt ).

Esse diretório contém as correções principais do gateway.

6. Consulte o arquivo README.txt para determinar a ordem na qual as correções devem ser instaladas.

7. Instale cada correção, na ordem correta, executando o seguinte comando:

$OMNIHOME/install/nco_patch -install patch_path

em que patch_path é o caminho para o arquivo de correção extraído.

Nota: Em qualquer ponto no processo de instalação, você poderá ver quais correções foram instaladas executando o seguinte comando:

$OMNIHOME/install/nco_patch

-print=id

Instalando o Gateway nos Sistemas Operacionais Windows

Para instalar o gateway nos sistemas operacionais Windows, execute as seguintes etapas:

1. Faça download do pacote de instalação para o gateway no Web site do Passport Advantage Online:

2. Faça um backup de todos os arquivos de configuração existentes que você queira manter.

3. Extraia o conteúdo do pacote de instalação para um diretório temporário.

4. No diretório temporário, localize e leia o arquivo README.txt .

O arquivo README.txt dirá se você precisa fazer download de alguma correção

adicional no Web site do Passport Advantage Online.

5. Localize o diretório patches (no diretório que contém o arquivo README.txt ).

Esse diretório contém as correções principais do gateway.

6. Extraia os arquivos de correção para o seguinte diretório:

%OMNIHOME%

Instalando o Gateway no Tivoli Netcool/OMNIbus V7.3.0, V7.3.1 ou Posterior

Com a introdução do Tivoli Netcool/OMNIbus V7.3.0 e V7.3.1, todos os gateways são instalados usando o instalador do Tivoli Netcool/OMNIbus. Você pode instalar o gateway usando o assistente de instalação, usando um instalador baseado em texto (modo de console) ou usando as configurações predefinidas em um arquivo de texto (modo silencioso).

O pacote de instalação e as correções para o gateway são fornecidos como

arquivos. O aplicativo de gerenciamento de archive que você usa para extrair os arquivos deve estar apto a preservar a estrutura de diretório contida no archive na extração.

Visão Geral da Instalação

O Gateway para JDBC e seus pacotes relacionados são instalados conforme

descrito a seguir.

Você deve instalar o gateway e os componentes associados na seguinte ordem:

1. Instale o pacote do modo de relatório ou do modo de auditoria, conforme necessário.

2. Instale o gateway.

3. Instale os drivers JDBC para o banco de dados de destino.

Você deve obter os drivers do fornecedor do banco de dados e instalá-los de acordo com as instruções do fornecedor.

Para obter mais informações, consulte o manual “Configurando a Conexão com o Banco de Dados” na página 17.

Instalando as Bibliotecas dos Modos de Auditoria e de Relatório

Para executar o gateway no modo de auditoria ou de relatório, você deve configurar o esquema de banco de dados apropriado. Se estiver usando o Gateway para JDBC como substituto do Gateway para Oracle ou do Gateway para ODBC, sua configuração existente do banco de dados de destino pode não requerer nenhuma mudança. Caso contrário, você deverá instalar a biblioteca gateway-nco-g-jdbc-audit-scripts ou a biblioteca gateway-nco-g-jdbc-reporting- scripts , conforme necessário. Essas bibliotecas contêm os scripts necessários para criar os esquemas do banco de dados de destino.

Para instalar a biblioteca de scripts de auditoria ou a biblioteca de scripts de relatório, use as seguintes etapas:

1. Inicie o assistente de instalação:

v

Em sistemas operacionais UNIX e Linux, execute o seguinte comando:

$NCHOME/omnibus/install/nco_install_integration

v

Em sistemas operacionais Windows, execute o seguinte comando:

%NCHOME%\omnibus\install\nco_install_integration

2. Escolha instalar o pacote de scripts de auditoria ou o pacote de scripts de relatório e siga as instruções na tela para concluir a instalação.

Os scripts instalados estão localizados no diretório $OMNIHOME/gates/audit ou $OMNIHOME/gates/reporting .

Depois de instalar os scripts, é possível usá-los para criar um esquema do banco de dados para uso com o gateway. Para obter mais informações, consulte o manual “Configurando o Esquema do Banco de Dados” na página 16.

Instalando o Gateway nos Sistemas Operacionais UNIX e Linux

Para instalar o gateway nos sistemas operacionais UNIX e Linux, use as seguintes etapas:

1. Faça download do pacote de instalação para o gateway no Web site do Passport Advantage Online:

2. Faça um backup de todos os arquivos de configuração existentes que você queira manter.

3. Extraia o conteúdo do pacote de instalação para um diretório temporário.

4. Para instalar o gateway usando o assistente de instalação, execute as seguintes etapas:

a. Execute o seguinte comando:

$NCHOME/omnibus/install/nco_install_integration

b. Quando o assistente de instalação for iniciado, especifique o diretório extraído que contém o arquivo README.txt como o local dos arquivos de instalação do gateway.

c. Aceite as condições da licença.

5. Para instalar o gateway usando o modo do console, use as etapas a seguir:

a. Execute o seguinte comando:

$NCHOME/omnibus/install/nco_install_integration -i console

b. Quando o instalador baseado em texto for iniciado, especifique o diretório extraído que contém o arquivo README.txt como o local dos arquivos de instalação do gateway.

c. Aceite as condições da licença.

6. Para instalar o gateway usando o modo silencioso, use as etapas a seguir:

a. Crie um arquivo de texto denominado reponse.txt e inclua as seguintes entradas:

PROBE_OR_GATE_LOCATION=README_directorypath

LICENSE_ACCEPTED=true

em que README_directorypath é o caminho para o diretório que contém o arquivo README.txt no pacote extraído.

b. Execute o seguinte comando:

$NCHOME/omnibus/install/nco_install_integration

response_path/response.txt

em que response_path é o caminho completo para o arquivo response.txt .

-i

silent

-f

Em cada caso, o gateway é instalado no diretório $NCHOME/omnibus/gates .

Instalando o Gateway nos Sistemas Operacionais Windows

Para instalar um gateway nos sistemas operacionais Windows, use as seguintes etapas:

1.

Faça download do pacote de instalação para o gateway no Web site do Passport Advantage Online:

2. Faça um backup de todos os arquivos de configuração existentes que você queira manter.

3. Extraia o conteúdo do pacote em um diretório temporário.

4. Para instalar o gateway usando o assistente de instalação, execute as seguintes etapas:

a. Execute o seguinte comando:

%NCHOME%\omnibus\install\nco_install_integration

b. Quando o assistente de instalação for iniciado, especifique o diretório extraído que contém o arquivo README.txt como o local dos arquivos de instalação do gateway.

c. Aceite as condições da licença.

5. Para instalar o gateway usando o modo do console, use as etapas a seguir:

a. Execute o seguinte comando:

%NCHOME%\omnibus\install\nco_install_integration -i console

b. Quando o instalador baseado em texto for iniciado, especifique o diretório extraído que contém o arquivo README.txt como o local dos arquivos de instalação do gateway.

c. Aceite as condições da licença.

6. Para instalar o gateway usando o modo silencioso, use as etapas a seguir:

a. Crie um arquivo de texto denominado reponse.txt e inclua as seguintes entradas:

PROBE_OR_GATE_LOCATION=README_directorypath

LICENSE_ACCEPTED=true

em que README_directorypath é o caminho para o diretório que contém o arquivo README.txt no pacote extraído.

b. Execute o seguinte comando:

%NCHOME%\omnibus\install\nco_install_integration

response_path\response.txt

em que response_path é o caminho completo para o arquivo response.txt .

-i

silent

-f

Em cada caso, o gateway é instalado no diretório %NCHOME%\omnibus\gates .

Configurando variáveis de ambiente

Pode ser necessário configurar algumas variáveis de ambiente para definir o ambiente de trabalho do gateway.

Antes de executar o gateway em um sistema operacional Windows, assegure que a variável de ambiente %PATH% contenha a localização do arquivo JVM.DLL . A localização padrão de JVM.DLL é:

%NCHOME%/platform/win32/jre_1.x.y/jre/bin/j9vm

em que x e y são determinados pela versão do Netcool/OMNIbus que está sendo executada.

Configurando Detalhes de Comunicação

Para ativar a comunicação entre o gatewa y e o ObjectServer, você deve configurar detalhes de comunicação para o ObjectServe r e o gateway usando o Editor do Servidor Netcool/OMNIbus ( nco_xigen ) e criar uma entrada para o ObjectServer no arquivo de interfaces $NCHOME/etc/omni.dat ).

Se o ObjectServer já estiver configurad o e o gateway irá ser executado da mesma instalação, não é necessário configurar detalhes de comunicação para o ObjectServer.

Em sistemas operacionais UNIX e Linux, use o seguinte comando para iniciar o Server Editor:

$NCHOME/omnibus/bin/nco_xigen

Em sistemas operacionais Windows, use o seguinte comando para iniciar o Server Editor:

Iniciar > Programas > NETCOOL Suite > Utilitários do Sistema > Server Editor

Você deve também incluir uma entrada do servidor gateway no arquivo de interfaces. É possível fazer isso usando o Server Editor. Como alternativa, em sistemas operacionais Unix e Linux, é possível editar o arquivo de interfaces e gerá-lo novamente usando o utilitário nco_igen . O nome padrão do servidor gateway é G_JDBC .

Se houver um firewall entre o gatewa y e o ObjectServer, configure o ObjectServer para usar uma porta fixa para IDUC e assegure que a porta principa l e a porta IDUC do ObjectServer estejam abertas no firewall. Por padrão o ObjectServer usa uma porta IDUC aleatória.

Para obter informações adicionais sobre o uso do Editor de Servidor e do arquivo de interfaces, consulte o IBM Tivoli Netcool/OMNIbus Installation and Deployment Guide (SC14-7604-00).

Configurando o Esquema do Banco de Dados

A configuração do esquema do banco de dados envolve a execução dos scripts SQL do modo de auditoria ou de relatório apropriados para o banco de dados de destino. Os scripts fornecidos nas bibliotecas dos modos de auditoria e de relatório são projetados para cobrir casos de uso gerais. Provavelmente será necessário modificá-los para trabalhar com as configurações de seu banco de dados ou para adequar-se a seus requisitos particulares.

As bibliotecas dos modos de auditoria e de relatório contêm scripts SQL que criam todos os objetos de esquema de banco de dados necessários para armazenar dados processados pelo gateway, incluindo o espaço de tabela, espaço de tabela temporário, relator, tabelas ( status , journal e details ), índices e restrições.

Use os scripts do modo de auditoria ou os scripts do modo de relatório para criar os objetos de esquema do banco de dados, conforme necessário. Consulte “Modo de Auditoria e Modo de Relatório” na página 6 para obter detalhes sobre como o gateway opera em cada modo.

Executando os Scripts

Os scripts instalados estão localizados em subdiretórios dos diretórios $OMNIHOME/gates/audit e $OMNIHOME/gates/reporting , denominados para o banco de dados de destino que eles configuram. Por exemplo, os scripts para o IBM DB2 estão localizados nos subdiretórios $OMNIHOME/gates/audit/db2 e $OMNIHOME/gates/reporting/db2 .

Antes de executar os scripts, você deve consultar a documentação de seu banco de dados para obter instruções sobre como o banco de dados usa scripts SQL. Consulte também os arquivos leia-me nas bibliotecas de scripts e os comentários nos arquivos de script para detalhes de quaisquer limitações ou restrições específicas de scripts individuais.

Migrando de um Gateway Existente

Se estiver usando o Gateway para JDBC como substituto do Gateway para Oracle ou do Gateway para ODBC, sua configuração existente do banco de dados de destino pode não requerer nenhuma mudança. Nesses casos, não há necessidade de executar os scripts de esquema do banco de dados.

A migração de um banco de dados de destino existente deve ser feita durante um período quieto para o ObjectServer. Isso assegurará que um número mínimo de eventos se perca para arquivamento enquanto o gateway não estiver ativo.

Antes de migrar de um banco de dados de destino existente, execute um encerramento correto do gateway antigo para assegurar que os dados existentes sejam encaminhados para o novo gateway. O novo gateway irá executar uma ressincronização de eventos do ObjectServer, portanto, problemas com o encerramento do gateway antigo não devem resultar em perda de dados. No entanto, a ressincronização pode resultar em dados de evento duplicados e mensagens de erro subsequentes se violações de restrição no banco de dados de destino forem acionadas.

Ressincronização Bidirecional

Na primeira vez que o gateway for executado, ele detectará que não há alertas em seu cache e executará uma ressincronização bidirecional. Isso irá detectar quaisquer eventos no banco de dados de destino que ainda estavam abertos quando o gateway antigo foi executado pela última vez e que foram subsequentemente fechados e excluídos do ObjectServer. Isso permite que exclusões de eventos que foram perdidas quando o gateway estava sendo migrado sejam recuperadas para o banco de dados de destino. Em execuções subsequentes, quando houver alertas em seu cache, o gateway executará uma ressincronização unidirecional na inicialização.

Nota: A ressincronização bidirecional resulta em varreduras integrais da tabela na tabela de status do banco de dados de destino. A quantia de tempo necessária para a conclusão da ressincronização é proporcional ao tamanho da tabela de banco de dados. Uma grande quantia de histórico de eventos resultará em uma longa ressincronização.

Configurando a Conexão com o Banco de Dados

A configuração da conexão com o banco de dados envolve configurar o driver JDBC e especificar valores para as propriedades relacionadas à conexão.

Drivers JDBC

Você deve obter o driver JDBC do fornecedor do banco de dados e instalá-lo de acordo com as instruções do fornecedor. Os drivers geralmente são fornecidos como Java archives ( .jar ).

Você deve copiar o arquivo .jar do driver JDBC para o seguinte diretório:

$OMNIHOME/gates/java

Propriedade de Conexão do Banco de Dados

Para ativar o gateway para se comunicar com o banco de dados de destino, você deve especificar valores para as seguintes propriedades:

v

Gate.Jdbc.Connections

Esta propriedade especificar o número de conexões que o gateway faz com o banco de dados de destino. Aumentar o número de conexões aumenta o nível de paralelismo disponível para o gateway e potencialmente aumenta o desempenho. Inicie com valores baixos conforme necessário para localizar o nível de desempenho desejado.

v

Gate.Jdbc.Driver

Esta propriedade especifica o driver JDBC.

v

Gate.Jdbc.Url

Esta propriedade especifica a URL do banco de dados de destino.

v

Gate.Jdbc.Username

Esta propriedade especificar o nome de usuário para o banco de dados de destino.

v

Gate.Jdbc.Password

Esta propriedade especifica a senha para o banco de dados de destino.

A tabela a seguir lista exemplos de valores para as propriedades Gate.Jdbc.Driver

e Gate.Jdbc.Url para uso com cada banco de dados. Consulte a documentação de

seu driver para obter informações adicionais sobre a configuração de conexões com

o banco de dados. Os valores padrão podem ser diferentes dependendo de sua configuração.

Tabela 5. Exemplo de Valores de Propriedades de JDBC

DB2 LUW

Gate.Jdbc.Driver

com.ibm.db2.jcc.DB2Driver

Gate.Jdbc.Url

jdbc:db2://host_name:port/db_name

Em que host_name é o nome da máquina host do banco de dados, port é o número da porta e db_name é o nome do banco de dados. Por exemplo:

jdbc:db2://server.example.ibm.com:9999/REPORTER

DB2 z/OS

Gate.Jdbc.Driver

com.ibm.db2.jcc.DB2Driver

Tabela 5. Exemplo de Valores de Propriedades de JDBC (continuação)

Gate.Jdbc.Url

jdbc:db2://host_name:port/db_name

Em que host_name é o nome da máquina host do

banco de dados, port é o número da porta e db_name é

o

nome do banco de dados. Por exemplo:

jdbc:db2://server.example.ibm.com:9999/REPORTER

Informix

Gate.Jdbc.Driver

com.informix.jdbc.IfxDriver

Gate.Jdbc.Url

jdbc:informix-sqli://host_name:port/

db_name:INFORMIXSERVER=server_name

Em que host_name o nome da máquina host do banco de dados, port é o número da porta, db_name é o nome do banco de dados, e server_name é o mesmo que o host_name . Por exemplo:

jdbc:informix-sqli://server.example.ibm.com:1433/

REPORTER:INFORMIXSERVER=server.example.ibm.com

Microsoft SQL Server

Gate.Jdbc.Driver

com.microsoft.sqlserver.jdbc.SQLServerDriver

Gate.Jdbc.Url

jdbc:sqlserver://

host_name:port;databaseName=db_name

Em que host_name é o nome da máquina host do banco de dados, port é o número da porta e db_name é

o

nome do banco de dados. A port padrão é 1433 . Por

exemplo:

jdbc:sqlserver://

server.example.ibm.com:1433;databaseName=REPORTER

MySQL

Gate.Jdbc.Driver

com.mysql.jdbc.Driver

Gate.Jdbc.Url

jdbc:mysql://host_name[,failover_host]:port/

db_name[?param1=value1&param2=value2]

Em que host_name é o nome da máquina host do

banco de dados, host_failover é o nome do host de failover opcional, port é o número da porta, db_name é

o

nome do banco de dados e param1 e param2 são

parâmetros opcionais. A port padrão é 3306 . Por

exemplo:

jdbc:mysql://server.example.ibm.com:3306/alerts

Oracle

Gate.Jdbc.Driver

oracle.jdbc.driver.OracleDriver

Gate.Jdbc.Url

jdbc:oracle:thin:@host_name:port:db_name

Em que host_name é o nome da máquina host do

banco de dados, port é o número da porta e db_name é

o

nome do banco de dados. A port padrão é 1521 . Por

exemplo:

jdbc:oracle:thin:@server.example.ibm.com:1521:

REPORTER

Tabela 5. Exemplo de Valores de Propriedades de JDBC (continuação)

Sybase

Gate.Jdbc.Driver

com.sybase.jdbc4.jdbc.SybDriver

Gate.Jdbc.Url

jdbc:sybase:Tds:host_name:port/

db_name[?property=value;]

Em que host_name é o nome da máquina host do banco de dados, port é o número da porta, db_name é o nome do banco de dados e property é um parâmetro opcional. Por exemplo:

jdbc:sybase:Tds:server.example.ibm.com:1521/

REPORTER

Configurando o Gateway

Depois de instalar o gateway, você deverá configurá-lo para trabalhas com seu ambiente operacional.

O pacote de instalação do gateway contém os arquivos de configuração necessários para executar o gateway. Os arquivos de configuração padrão configuram o gateway para operação no modo de relatório.

A tabela a seguir lista os arquivos de configuração instalados com o pacote de instalação do gateway.

Tabela 6. Arquivos de Configuração do Gateway

Arquivo de Configuração

Descrição

$OMNIHOME/etc/G_JDBC.props

O

arquivo de propriedades padrão usado pelo

gateway. Esse arquivo configura o gateway para

operação no modo de relatório.

$OMNIHOME/gates/jdbc/

O

arquivo de propriedades usado para configurar

audit.G_JDBC.props

o

gateway para operação no modo de auditoria.

$OMNIHOME/gates/jdbc/

O

arquivo de definição de mapa usado para

audit.jdbc.map

configurar o gateway para operação no modo de

auditoria.

$OMNIHOME/gates/jdbc/G_JDBC.props

Uma cópia do arquivo de propriedades padrão usado pelo gateway. Esse arquivo configura o gateway para operação no modo de relatório.

$OMNIHOME/gates/jdbc/jdbc.map

O

arquivo de definição de mapa padrão usado

pelo gateway. Esse arquivo configura o gateway para operação no modo de relatório.

$OMNIHOME/gates/jdbc/

O

arquivo de definição de replicação de tabela

jdbc.rdrwtr.tblrep.def

padrão usado pelo gateway.

$OMNIHOME/gates/jdbc/

O

arquivo de comando de inicialização padrão

jdbc.startup.cmd

usado pelo gateway.

$OMNIHOME/gates/jdbc/

O

arquivo de propriedades usado para configurar

reporting.G_JDBC.props

o

gateway para operação no modo de relatório. Ele

idêntico ao arquivo de propriedades padrão G_JDBC.props .

é

Tabela 6. Arquivos de Configuração do Gateway (continuação)

Arquivo de Configuração

Descrição

$OMNIHOME/gates/jdbc/

O arquivo de definição de mapa usado para configurar o gateway para operação no modo de relatório. Ele é idêntico ao arquivo de definição de mapa padrão jdbc.map .

reporting.jdbc.map

Os tópicos a seguir contêm informações adicionais sobre a configuração do gateway.

v

“Arquivo de propriedades”

v

“Propriedades e Opções da Linha de Comandos”

v

“Arquivo de Definição de Mapas” na página 35

v

“Arquivo de Comando de Inicialização” na página 36

v

“Transferências de Tabelas Arbitrárias” na página 36

v

“Arquivo de Definição de Replicação da Tabela” na página 37

v

“Funções AfterIDUC e de Filtro” na página 38

v

“Usando um Campo de Particionamento” na página 39

v

“Filtrando Dados de Ressincronização” na página 39

v

“Arquivo de Log de Mensagens” na página 40

v

“Modo FIPS e Criptografia” na página 41

Para obter informações adicionais sobre o uso de arquivos de configuração de gateway, consulte o IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide

(SC14-7608-00).

Arquivo de propriedades

O arquivo de propriedades é um arquivo de texto que contém um conjunto de

propriedades específicas do gateway e genéricas do Netcool/OMNIbus e seus valores correspondentes. É possível editar o arquivo de propriedades para adequar-se a seu ambiente operacional.

O arquivo de propriedades padrão instalado com o gateway, $OMNIHOME/etc/

G_JDBC.props , configura o gateway para operar no modo de relatório.

Para configurar o gateway para operar no modo de auditoria, use as seguintes

etapas:

1. Copie $OMNIHOME/gates/jdbc/audit.G_JDBC.props para $OMNIHOME/etc/ G_JDBC.props .

2. Copie $OMNIHOME/gates/jdbc/audit.jdbc.map para $OMNIHOME/gates/jdbc/ jdbc.map .

Propriedades e Opções da Linha de Comandos

Você usa as propriedades para definir o ambiente operacional do gateway. É possível substituir os valores padrão da propriedade editando o arquivo de propriedades ou usando as opções de linha de comandos da propriedade.

As tabelas a seguir descrevem as propriedades principais requeridas para configurar o Gateway para JDBC. Para obter informações sobre propriedades e opções de linha de comandos adicionais genéricas do gateway Netcool/OMNIbus, consulte o IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide (SC14-7608-00).

As seções a seguir descrevem as propriedades usadas para configurar o gateway:

v

“Propriedades Comuns do Netcool/OMNIbus”

v

“Propriedades de Gateway JDBC” na página 23

v

“Propriedades Genéricas do Gateway” na página 28

v

“Propriedades Java” na página 29

v

“Propriedades de Mapeamento” na página 30

v

“Propriedades do Leitor/Gravador de Gateway” na página 30

v

“Propriedades de Conexão” na página 35

Propriedades Comuns do Netcool/OMNIbus

A Tabela 7 lista as propriedades comuns disponíveis.

Tabela 7. Propriedades Comuns do Netcool/OMNIbus

Nome da propriedade

Opção da linha de comandos

Descrição

ConfigCryptoAlg string

-configcryptoalg string

Use esta propriedade para especificar o algoritmo de criptografia que o gateway usa.

O

padrão é AES.

ConfigKeyFile string

-configkeyfile string

Use esta propriedade para especificar a chave de criptografia com os dados criptografados.

O

padrão é "" .

Connections integer

-connections integer

Use esta propriedade para especificar o número máximo de conexões do cliente que podem ser feitas no servidor gateway.

O

padrão é 30 .

MaxLogFileSize integer

-maxlogfilesize integer

Use essa propriedade para especificar o tamanho (em bytes) que o gateway aloca para o arquivo de log. Quando o arquivo de log atinge esse tamanho, o gateway o renomeia anexando o sufixo .old e cria um novo arquivo de log.

O

padrão é 1024 .

MessageLevel string

-messagelevel string

Use esta propriedade para especificar o nível de relatório das mensagens do arquivo de log.

O

padrão é warn .

Tabela 7. Propriedades Comuns do Netcool/OMNIbus (continuação)

Nome da propriedade

Opção da linha de comandos

Descrição

MessageLog string

-messagelog string

Use essa propriedade para especificar o local do arquivo de log de mensagens.

O

padrão é

'$OMNIHOME/log/G_JDBC.log' .

Name string

-name string

Use esta propriedade para especificar o nome da

instância de gateway atual.

Se

você quiser executar

vários gateways em uma máquina, deverá usar um nome diferente para cada instância.

O

padrão é 'G_JDBC' .

Props.CheckNames boolean

Nenhuma linha de comandos equivalente.

Use esta propriedade para

instruir o gateway a encerrar

 

se

qualquer propriedade no

arquivo de propriedades for

configurada para um valor inválido.

O

padrão é TRUE .

PropsFile string

-propsfile string

Use esta propriedade para especificar o local do arquivo de propriedades do gateway.

O

padrão é

$OMNIHOME/etc/G_JDBC.props .

UniqueLog boolean

-uniquelog boolean

Use esta propriedade para especificar que os nomes dos arquivos de log são criados exclusivamente incluindo o ID do Processo (PID) do gateway ao nome do arquivo.

O

padrão é FALSE .

Propriedades de Gateway JDBC

A Tabela 8 lista as propriedades de gateway JDBC disponíveis.

Tabela 8. Propriedades de Gateway JDBC

Nome da propriedade

Opção da linha de comandos

Descrição

Gate.Jdbc.ActionCodeField

-jdbcactioncodefield

Use essa propriedade para especificar o nome da coluna para informações de código de ação quando o gateway estiver no modo de auditoria.

O padrão é 'ACTIONCODE' .

string

string

Tabela 8. Propriedades de Gateway JDBC (continuação)

Nome da propriedade

Opção da linha de comandos

Descrição

Gate.Jdbc.ActionTimeField

-jdbcactiontimefield

Use essa propriedade para especificar o nome da coluna para informações de tempo da ação quando o gateway estiver no modo de auditoria.

O

padrão é 'ACTIONTIME' .

string

string

Gate.Jdbc.Connections

-jdbcconnections integer

Use esta propriedade para especificar o número de conexões com o banco de dados de destino.

integer

O

padrão é 3 .

Gate.Jdbc.DeletedAtField

-jdbcdeleteatfield

Use esta propriedade para especificar o campo na tabela de destino que é usado para registrar o tabela de destino de exclusão de um alerta.

Esta propriedade somente é requerida ao executar o gateway no modo de relatório.

string

string

O

padrão é 'DELETEDAT' .

Gate.Jdbc.Details

-jdbcdetailstablename

Use esta propriedade para especificar o nome da tabela do banco de dados de destino para armazenar dados da tabela alerts.details do ObjectServer.

O

padrão é 'details' .

TableName string

string

Gate.Jdbc.Driver string

-jdbcdriver string

Use esta propriedade para especificar o driver JDBC.

O

padrão é "" .

Gate.Jdbc.DupIgnore string

-jdbcdupignore string

Use esta propriedade para especificar quais campos ignorar ao deduplicar atualizações de alertas.

Esta propriedade pode tomar diversos valores, separados por espaços.

O

padrão é "ActionCode

ActionTime

LastModified

StateChange" .

Gate.Jdbc.FatalErrors

-jdbcfatalerrors string

Use esta propriedade para especificar quais prefixos de SQLSTATE são considerados fatais ao processar um lote de alertas.

Esta propriedade pode tomar diversos valores, separados por espaços.

string

O

padrão é "0A 42" .

Tabela 8. Propriedades de Gateway JDBC (continuação)

Nome da propriedade

Opção da linha de comandos

Descrição

Gate.Jdbc.Initialization String string

-jdbcinitialization string string

Use esta propriedade para especificar uma sequência de inicialização SQL a ser executada na conexão com o banco de dados de destino.

O

padrão é "".

Gate.Jdbc.Journal

-jdbcjournaltablename

Use esta propriedade para especificar o nome do banco de dados de destino para armazenar dados da tabela alerts.journal do ObjectServer.

O

padrão é 'journal' .

TableName string

string

Gate.Jdbc.MaxBatchSize

-jdbcmaxbatchsize

Use esta propriedade para especificar o número máximo de linhas a processar em um lote.

O

padrão é 250 .

integer

integer

Gate.Jdbc.Mode string

-jdbcmode string

Use esta propriedade para especificar o modo de operação do gateway. Essa propriedade aceita os seguintes valores:

AUDIT : O gateway executa no modo de auditoria.

-jdbcaud