Introdução

Organizações de nível corporativo geram uma grande quantidade de informações relacionadas à segurança devido ao número crescente de dispositivos de segurança e aplicativos que usam. A quantidade de dados, por si só, torna o armazenamento, recuperação e entendimento dessas informações muito difíceis sem uma arquitetura de análise e coleta de eventos de segurança devidamente projetada.

O IBM Tivoli Security Operations Manager (TSOM) é uma plataforma avançada de software de gerenciamento de informações e eventos de segurança (SIEM) que melhora a eficácia, eficiência e visibilidade das operações de segurança coorporativas. Ele é usado para gerenciar informações e eventos relacionados à segurança de dispositivos físicos e aplicativos por toda a empresa, ajudando a atender às suas necessidades de uma arquitetura de análise e coleta de eventos de segurança.

O IBM TSOM evoluiu a partir do IBM Tivoli Risk Manager and Netcool® para Security Management. Ele foi elaborado para lidar com as crescentes demandas de arquitetura de segurança corporativa, usando recursos de ponta de análise e correlação que não estavam presentes nos produtos anteriores. O IBM TSOM não só permite que administradores e analistas de segurança interpretem e gerenciem informações de evento de segurança em tempo real, mas também ajuda os executivos a entenderem a condição de segurança e de conformidade de sua empresa.

O desempenho do IBM TSOM depende totalmente do desempenho de seu banco de dados backend, como, por exemplo, o IBM DB2 para Linux, UNIX e Windows. O IBM TSOM depende do sistema adjacente de gerenciamento de dados para funções como correlação, configuração, procuras em históricos e geração de relatórios. Todos os eventos são gravados e lidos em tempo real para e do banco de dados. Uma grande quantidade de dados também está sendo trocada constantemente entre o IBM TSOM e o DB2. Por exemplo, para um ambiente de produção, entre 500 GB e 1 TB de dados podem ser gravados no banco de dados em duas semanas. Portanto, para te oferecer o melhor desempenho possível de uma solução SIEM avançada, você deve considerar parâmetros específicos de DB2 para ajustar o banco de dados de acordo com seu ambiente específico.

Você deve entender as etapas requeridas para configurar o ambiente de DB2 antes de passar para os procedimentos usados para ajustar diferentes parâmetros de IBM DB2 para um excelente desempenho com IBM TSOM.

Configuração do ambientes do IBM DB2

Para modificar os parâmetros do DB2, o contexto de login do sistema operacional deve ser o do proprietário da instância do DB2. Os exemplos a seguir mostram como alternar para um contexto de login do proprietário de uma instância de DB2 chamado tsom.

Nos sistemas operacionais Linux ou UNIX, insira o seguinte comando:

su - tsom

Nos sistemas Windows, insira os seguintes comandos:

db2cmd
set DB2INSTANCE=tsom

Os parâmetros de DB2 podem no nível do gerenciador do banco de dados, no nível do banco de dados ou no nível de registro e podem ser modificados, como segue.

Se for um parâmetro de configuração de nível do gerenciador do banco de dados:

  db2 update dbm cfg using <parm_name> <parm_value> 

Se for um parâmetro de configuração no nível do banco de dados:

  db2 update db cfg for <database name> using <parm_name> <parm_value> 

Se for um parâmetro de registro do DB2:

  db2set <parm_name>=<parm_value> 

- where <parm_name> is the name of the parameter and <parm_value> is the new setting.

Para que as mudanças tenham efeito, deve-se reciclar o banco de dados ou gerenciador do banco de dados depois de atualizar os parâmetros do registro do DB2, parâmetros estáticos de configuração no nível do banco de dados ou parâmetros estáticos de configuração de banco de dados no nível do gerenciador.

Para reciclar o banco de dados:

db2 terminate 
db2 deactivate db <database name>
db2 connect to db <database name>

Para reciclar o gerenciador do banco de dados:

db2 force applications all
db2stop force
db2start

O servidor do IBM DB2 pode ser instalado tanto em hardware de 32 bits como de 64 bits. No entanto, você deve usar o IBM DB2 de 64 bits com o IBM TSOM, porque a instalação de 64 bits lida melhora com a memória do que uma instalação de 32 bits.

Depois de concluída a configuração do ambiente de DB2, é possível prosseguir com o ajuste de desempenho. As seções a seguir mostram diferentes aspectos do ajuste de desempenho que você deve levar em consideração ao configurar o IBM DB2 para excelente uso com o IBM TSOM.

Projeto de espaços de tabela do DB2

Cada banco de dados do DB2 contém pelo menos um espaço de tabela de catálogo, um ou mais espaços de tabela e um ou mais espaços de tabela temporários. Um espaço de tabela é uma entidade lógica que contém os dados reais do usuário final. Um espaço de tabela pode compreender um ou mais contêineres, que podem ser um arquivo ou diretório no nível do sistema operacional. Os contêineres do espaço de tabela são o armazenamento físico do banco de dados do IBM DB2.

Para isolar objetos em diferentes buffer pools, é possível criar mais de um espaço de tabela no mesmo banco de dados e associar cada espaço da tabela com buffer pools separados.

Há três tipos de espaços de tabela:

Espaço gerenciado por sistema (SMS)

O gerenciador de sistema de arquivo do sistema operacional aloca e gerencia o espaço. Antes do DB2 9, o resultado da criação de um banco de dados ou espaço de tabela sem quaisquer parâmetros eram espaços de tabela criados como objetos SMS.

Espaço gerenciado por banco de dados (DMS)

O gerenciador do banco de dados controla o espaço de armazenamento. Esse espaço de tabela é uma implementação de um sistema de arquivos com finalidade especial, elaborado para atender melhor às necessidades do gerenciador do banco de dados.

Armazenamento automático com DMS

O armazenamento automático não é exatamente um tipo separado de espaço de tabela, mas uma forma diferente de manipular o armazenamento com DMS. Os contêineres do DMS exigem mais manutenção, e o armazenamento automático foi apresentado no DB2 V8.2.2 como forma de simplificar o gerenciamento de espaço. Com armazenamento automático, o DB2 cria contêineres espalhadas por todo o caminho declarado para o armazenamento automático. Várias unidades de armazenamento melhorarão o desempenho, explorando o paralelismo de E/S.

Por padrão, todas as tabelas diferentes do IBM TSOM são criadas no espaço de tabela padrão, de modo que você deve usar um espaço de tabela separado para dados de evento e índices de tabela de eventos. É possível usar o paralelismo de E/S para melhorar o desempenho do IBM TSOM, dividindo os dados, índices e arquivos de log de eventos entre unidades de armazenamento separadas.

É altamente recomendado que você use o armazenamento automático para gerenciar os espaços de tabela. A listagem 1 mostra os comandos a serem usados para criar espaços de tabela de armazenamento automáticos.

create regular table space data_ts pagesize 32 k managed by automatic storage 
extentsize 32 overhead 10.5 prefetchsize 32 transferrate 0.14 bufferpool 
data_bp dropped table recovery off no file system caching;

create regular table space index_ts pagesize 32 k managed automatic storage 
extentsize 32 overhead 10.5 prefetchsize 32 transferrate 0.14 bufferpool 
index_bp dropped table recovery off no file system caching;

Para criar as tabelas de dados de eventos nesses espaços de tabela, recrie as tabelas de eventos depois que tiver removido o comentário da seguinte linha de itsom_tables_db2.sql , que está presente no diretório {TSOM Directory}/schema/ no Servidor de gerenciamento central (CMS):

--IN DATA_TS INDEX IN INDEX_TS

Voltar para parte superior

Ajuste dos buffer pools de banco de dados do IBM DB2

Os buffer pools melhoram o desempenho do banco de dados, eliminando o tempo de leitura do disco quando itens são encontrados na memória principal do sistema. Como um buffer pool do DB2 é uma parte da memória principal do sistema, o gerenciador do banco de dados do DB2 o aloca para tabelas em cache e dados de índice quando lê ou grava para e de discos de mídia. Cada banco de dados de DB2 tem, pelo menos, um buffer pool.

Quando você cria um banco de dados de DB2 em plataformas UNIX, um buffer pool padrão chamado IBMDEFAULTBP é criado, ou seja, 1000 páginas com um tamanho de página de 4k. Para outras plataformas, o tamanho do buffer pool é de 250 páginas com um tamanho de página de 4K. Quando novos buffer pools são configurados, certifique-se de que entende como ele impacta a memória disponível do seu sistema.

Para criar buffer pools, use os seguintes comandos:

connect to <database name>;
create bufferpool data_bp immediate size 250 pagesize 8K; 
create bufferpool index_bp immediate size 250 pagesize 8K;

É possível usar os seguintes comandos para alterar os tamanhos dos buffer pools depois de criá-los:

alter bufferpool bufferpool_name <size new_size_in_32768_byte_pages>
terminate 

Apesar de ajustar buffer pools do DB2 seja um desafio, é possível melhorar o desempenho de forma significativa. Ao projetar buffer pools, deve-se considerar os requisitos de memória do banco de dados. Por exemplo, olhe a quantidade de memória disponível na sua máquina e a memória requerida por outros aplicativos que estão sendo executados simultaneamente ao DB2 na mesma máquina. Não se deve executar nenhum outro aplicativo na mesma máquina na qual o servidor do DB2 foi instalado. Seu desempenho melhora quando mais dados do usuário do banco de dados estiverem em cache. No entanto, isso não significa que se deve sempre criar buffer pools grandes. Se você ajustar o buffer pool em um tamanho muito grande, o uso da memória do sistema excederá a memória física disponível, fazendo com que o sistema operacional gaste mais tempo paginando a memória.

É possível usar o Self Tuning Memory Manager (STMM) do servidor do IBM DB2 para medir e analisar como a memória do banco de dados do DB2 é consumida, e realocar a memória dinamicamente para otimizar o desempenho da carga de trabalho. Também é possível usar o STMM para gerenciar os requisitos e o uso da memória do DB2, de modo a balancear seus requisitos com o sistema operacional, outros aplicativos e outros bancos de dados na mesma ou em outras instâncias. É possível usar o seguinte comando para criar um buffer pool novo, no qual o STMM gerencia a memória:

create bufferpool <pool_name> immediate size 250 automatic pagesize 32K; 

Todas as tabelas no banco de dados são criadas no espaço de tabela padrão USERSPACE1, e o buffer pool IBMDEFAULTBP na instalação padrão do IBM TSOM. Como as características das tabelas de eventosEVENT_DATA, EVENT_DATA_SECURITY_DOMAIN_MAPeEVENT_DATA_EVENT_CLASS_MAP são constantes, é possível criar uma tabela de espaço e um buffer pool gerenciado pelo STMM para elas. A seguir, há uma definição de amostra de buffer pool, usando buffer pools separados para índices de dados de eventos e de tabela de eventos:

create bufferpool data_bp immediate size 2500 automatic pagesize 32K; 
create bufferpool index_bp immediate size 625 automatic pagesize 32K;

É possível ver que o tamanho da página é ajustado em 32k em vez de 4k padrão, o que melhora o desempenho no processo de inserção de eventos, resultando em uma atribuição de memória de 2500 x 32k + 625 x 32k = 100 MB.

Voltar para parte superior

Implementação do recurso de particionamento de tabela

O DB2 V9 apresentou um recurso de particionamento de tabela que pode aumentar o tamanho potencial de uma tabela única, e reduzir significativamente o esforço de manutenção requerida para gerenciar bancos de dados muito grandes. É possível armazenar dados em partições diferentes na mesma tabela de um banco de dados usando particionamento de tabela. É possível fazer partições usando colunas que possuem valores de um intervalo específico, como critérios de data, em que as partições podem ser identificadas como Jan, Feb, March e assim por diante; ou como 1st_Quarter, 2nd_Quarter, etc. O limite teórico do número de partições é 32.000, e o tamanho máximo suportado para uma tabela e um espaço de tabela é 16 TB para um tamanho de página de 32k. No entanto, desde que as partições da tabela sejam tratadas exatamente como uma tabela individual, uma partição pode, teoricamente, crescer até um máximo de 16 TB.

O IBM TSOM usa particionamento por intervalo para tabelas de eventos, de modo que é possível destacar uma partição, fazer archive da partição destacada em um armazenamento externo, ou eliminar a partição destacada.

É possível usar partições diariamente para melhorar o desempenho da consulta em uma tabela de eventos com relação a colunas não indexadas, se a maioria das consultas que foram iniciadas com relação à tabela de eventos cair em uma janela de 24 horas de tempo de normalização do evento (coluna de partição por intervalo). É possível anexar e destacar as partições usando o comando DB2 alter table para mover os dados de uma tabela (tabela de produção) para outra tabela (tabela de históricos) no mesmo banco de dados.

Configuração de logs de transação do DB2

As operações básicas de qualquer banco de dados relacional incluem CREATE, INSERT , DELETE, UPDATE , DROP, etc. O DB2 mantém um registro de todas as operações ou alterações realizadas nos objetos de banco de dados em logs transacionais. Todas as alterações são gravadas primeiro em arquivos de log antes de serem gravados no banco de dados no tempo COMMIT , assim, no caso de algum contratempo, como uma falha de energia, os arquivos de log podem ser usados para trazer o banco de dados de volta a um estado consistente.

Buffers de log

Antes que os arquivos de log sejam gravados nos arquivos de log, eles são gravados primeiro nos buffers. O parâmetro de configuração do banco de dados que define o tamanho do buffer do log é chamado de LOGBUFSZ. A memória é alocada de uma área chamada de database heap, cujo tamanho é controlado pelo parâmetro de configuração de banco de dados DBHEAP.

Os registros de log são gravados em disco quando ocorrer uma das seguintes situações:

• O buffer do log estiver cheio.
• Em resultado de algum outro evento interno do gerenciador do banco de dados.

O armazenamento em buffer dos registros de log resultar em um arquivo de log de E/S mais eficiente, já que os registros de log são gravados no disco com menos frequência e mais registros de log são gravados nos arquivos de logo a cada E/S.

UmLOGBUFSZ de 4096 é excelente quando usado com IBM TSOM. É possível usar os comandos a seguir para atualizar o tamanho de heap do banco de dados e o tamanho do buffer do log:

update db cfg for <database name> using dbheap 50000
update db cfg for <database name> using logbufsz 4096

Arquivos de log primários e secundários

A seguir, há dois tipos de arquivos de log:

• PRIMÁRIO
• SECUNDÁRIO

Os arquivos de log primários estabelecem uma quantidade fixa de armazenamento alocado para os arquivos de log de recuperação. Esses arquivos são pré-alocados durante a primeira conexão ao banco de dados. O parâmetro de configuração do banco de dados LOGPRIMARY determina o número de arquivos de log primários. O tamanho desses arquivos de log é determinado pelo parâmetro de configuração de banco de dados LOGFILSIZ .

Os arquivos de log secundários são alocados um por vez, conforme necessário, até o valor do parâmetro de configuração do banco de dados LOGSECOND, quando os arquivos de log primários ficarem cheios. O parâmetro de configuração de banco de dados LOGFILSIZ especifica o tamanho dos arquivos de log secundários.

Observação: O valor padrão de LOGFILSIZ é de 1.000 páginas para as versões do DB2 baseadas em UNIX. Para Windows, o valor é de 250 páginas. O tamanho da página é sempre 4 KB.

O número padrão de arquivos de logs primários (LOGPRIMARY) é definido como 3, e o número de arquivos de log secundários (LOGSECOND) como 2. O espaço em disco livre deve ser maior ou igual ao tamanho definido pela seguinte fórmula: (LOGFILSIZ x 4096 x (LOGPRIMARY + LOGSECOND) ÷ 1024) KB.

O seguinte comando do DB2 mostra uma saída que inclui a configuração atual desses parâmetros, com tsom como o nome do banco de dados usado pelo IBM TSOM:

get database configuration for tsom |
egrep 'LOGFILSIZ|LOGPRIMARY|LOGSECOND|NEWLOGPATH|Path to log files' 

O valor excelente de LOGFILSZ é 20.000. É possível usar o seguinte para atualizar o parâmetro do tamanho do arquivo de log:

update db cfg for <database name> using logfilsiz 20000

Voltar para parte superior

Ajustes de heaps da memória e variável de registro do DB2

Tamanho de heap do aplicativo

O parâmetro do tamanho de heap do aplicativo define o número de páginas de memória privada disponível para ser usado pelo gerenciador do banco de dados em nome de um agente ou subagente específico. A unidade de medida é 4k por página.

db2 update db cfg for <database name> using applheapsz 2048

É possível começar inicialmente com um valor de 2.048. No entanto, se perceber qualquer problema relacionado a applheapsz, é possível modificar dinamicamente mais tarde, sem afetar o funcionamento do IBM TSOM.

CHNGPGS_THRESH

O valor padrão para CHNGPGS_THRESH é 60 por cento, o que significa que quando 60% das páginas nos buffer pools não são mais puras (ou seja, contêm dados), NUM_IO_CLEANERS começa a gravar de modo assíncrono as páginas modificadas para o disco.

É possível melhorar o desempenho da inserção de eventos reduzindo CHNGPGS_THRESH para 30 (intervalo de 25 a 40) com o seguinte comando:

db2 update db cfg for <database name> using CHNGPGS_THRESH 30

DB2_SKIPINSERTED

Para melhores tempos de resposta de consulta, é possível usar o comando db2set para configurar DB2_SKIPINSERTED=ON para ignorar as linhas inseridas, mas ainda não comprometidas. Do contrário, o DB2 aguardará essas linhas até que uma operação de compromisso tenha sido concluída, o que diminui a velocidade do leitor. É possível usar o seguinte comando para configurar DB2_SKIPINSERTED para ON:

db2set DB2_SKIPINSERTED=ON

Observação: Configurações incorretas de alguns parâmetros do banco de dados podem fazer com que ele falhe. Se suspeitar que há configurações incorretas, verifique o arquivo db2diag.log no diretório para o qual o parâmetro diagpath aponta para mensagens de erro em qualquer sistema operacional. O parâmetro diagpath é o parâmetro de configuração no nível do gerenciador do banco de dados que aponta para o caminho totalmente qualificado para informações de diagnóstico do DB2.

Voltar para parte superior

Criação de índices para um melhor desempenho com consultas de históricos do IBM TSOM

Um índice é um conjunto ordenado de ponteiros para linhas em uma tabela base. Os índices melhoram o desempenho da consulta, evitando uma varredura completa da tabela. No entanto, a sobrecarga de manutenção dos índices pode impactar negativamente o desempenho de INSERT , UPDATE e DELETE .

Por padrão, a tabela EVENT_DATA possui índices definidos nas seguintes colunas: sensor_id_fk, event_type_id_fk, source_ip, destination_ip, destination_host_id_fke source_host_id_fk.

Se sua instalação executa consultas com frequência em quaisquer outras colunas da tabela EVENT_DATA na cláusula WHERE , pode-se considerar a criação de índices adicionais.

Para um melhor desempenho, crie índices adicionais nas duas tabelas a seguir:

• EVENT_DATA_SECURITY_DOMAIN_MAP
• EVENT_DATA

A sintaxe para criar índices adicionais nessas tabelas é:

CREATE INDEX DB2INST1.EDSDM_NORM ON DB2INST1.EVENT_DATA_SECURITY_DOMAIN_MAP 
("NORMALIZATION_TIME" ASC, "SECURITY_DOMAIN_ID_FK" ASC, "EVENT_DATA_ID_FK" ASC) 
ALLOW REVERSE SCANS ;

RUNSTATS ON TABLE DB2INST1.EVENT_DATA_SECURITY_DOMAIN_MAP FOR INDEX DB2INST1.EDSDM_NORM;

CREATE INDEX DB2INST1.ED_NORM ON DB2INST1.EVENT_DATA ("NORMALIZATION_TIME" ASC, 
"EVENT_DATA_ID" ASC) ALLOW REVERSE SCANS ;

RUNSTATS ON TABLE DB2INST1.EVENT_DATA FOR INDEX DB2INST1.ED_NORM ;

COMMIT WORK ;

Use o comando a seguir para visualizar o índice existente em uma tabela em particular:

connect to tsom 
describe indexes for table <table name> show detail 

Use o seguinte comando para criar novos índices:

create index <index name> on <table name>
(<column_names separated by commas and ordered by>);

A cláusula IN para criar um índice no mesmo espaço de tabela em que os dados do usuário residem, ou em um espaço de tabela diferente. Você deve criar um índice em um espaço de tabela separado, de modo que, se alguma coisa der errado com o espaço de tabela do índice, você possa eliminá-lo facilmente e depois recriar os mesmos índices.

Você deve executar reorg e runstats depois de criar novos índices, como mostrado abaixo:

reorg indexes all for table <Table name>
runstats on table <schema name>.<table name> and detailed indexes all

O DB2 Design Advisor é um utilitário que recomenda índices automaticamente.

O Design Advisor pode ajudá-lo a:

• Encontrar os melhores índices para uma consulta problemática
• Encontrar os melhores índices para um conjunto de consultas (uma carga de trabalho) sujeito a limites de recursos que são aplicados opcionalmente
• Testar um índice em uma carga de trabalho sem ter de criar o índice

É possível iniciar o Design Advisor a partir do DB2 Control Center, ou usando db2advis .

A saída db2advis também fornece a sintaxe exata para criar os índices recomendados.

Voltar para parte superior

Requisitos de espaço em disco do servidor do DB2

Quando o IBM TSOM é configurado com IBM DB2 em um ambiente de 1.000 EPS (eventos por segundo), muito espaço em disco será consumido pelos eventos. A equação a seguir mostra que para um evento de 1 KB (os campos varchar o tornam variável de acordo com o local), o espaço seria calculado para 1.000 eventos por segundo com um período de retenção de três meses:

1.000(EPS) x 60(segundos) x 60(minutos) x 24(horas por dia) x 90(número de dias) x 1 KB
                (tamanho aproximado de cada evento) = 7.776.000.000 KB =~ 7,7 TB

Taxa de gravação do disco do servidor do DB2

O processo de inserção é essencialmente o limite de E/S para o banco de dados. Normalmente, mesmo em um hardware antigo e lento, a CPU, a memória e os componentes BUS são rápidos o suficiente para conectarem-se à inserção. É a velocidade de gravação do disco que causa o gargalo. Nesse caso, é possível melhorar o desempenho conectando-se a um dispositivo de armazenamento externo que possua cache de gravação ativado.

Localização do gargalo de E/S no processo de inserção de eventos

O tempo do processador é organizado em quatro modos de tempo: tempo do sistema, tempo do usuário, tempo de espera de E/S e tempo inativo. Na máquina que hospeda o servidor do DB2, deve-se controlar o tempo de espera. Quando um processo aguarda por uma solicitação de dados do dispositivo de bloco, ele fica sujeito ao tempo de espera de E/S, e todo o tempo inativo se torna tempo de espera. Se perceber que o tempo inativo é zero, você deve verificar se o seu sistema possui problemas de rendimento de E/S.

Certifique-se de que a velocidade de gravação do disco corresponde ao EPS desejado. Por exemplo, ao gravar 1.000 eventos/segundo, a taxa de gravação do disco deve ser de aproximadamente 1 MB/segundo.

Teste de desempenho de consultas de CMS com banco de dados backend

É possível ativar o registro de OJB para veras consultas que estão sendo executadas pelo CMS no banco de dados backend. Para ativar o registro de OJB, você deve realizar as seguintes etapas:

1. Edite o arquivo {tsom_home}/conf/db/OJB-logging.properties removendo os comentários de # Logger for jdbc access querying and object materialization .

   # Logger for jdbc access querying and object materialization, useful # for debugging JDBC related problems org.apache.ojb.broker.accesslayer.JdbcAccessImpl.LogLevel=DEBUG org.apache.ojb.broker.accesslayer.RsIterator.LogLevel=WARN org.apache.ojb.broker.accesslayer.StatementsForClassImpl.LogLevel=DEBUG org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG org.apache.ojb.broker.core.QueryReferenceBroker.LogLevel=ERROR

   
   
2. Pare o CMS, aguarde alguns minutos e depois reinicie o CMS. Você verá que a saída do registro acima está gravada em {tsom_home}/logs/server.log .
3. Para testar o desempenho de consultas que estão demorando, insira o seguinte comando:

   db2batch -d dbname -f input.txt -cli -r output.txt

   
   Em que dbname especifica o banco de dados com relação ao qual executar as consultas, input.txt especifica o arquivo de entrada com suas consultas SQL, cli especifica a execução no modo CLI, output.txt especifica o arquivo para o qual os resultados do comando db2batch serão canalizados.
4. A ferramenta db2batch resume os resultados de desempenho em um formato aritmético e geométrico. Para sintaxe e opções, insira db2batch -h a partir da linha de comando. Observação: as consultas SQL geralmente levam mais tempo para serem executadas.

Voltar para parte superior

Conclusão

Você aprendeu as diferentes etapas que podem ser realizadas para ajustar o IBM DB2. Usando os procedimentos neste artigo, você verá uma melhoria significativa no desempenho das instalações do IBM TSOM que usam o IBM DB2 como banco de dados backend, e reduzirá a quantidade de tempo de inatividade que normalmente ocorrem nesses ambientes. Você está convidado a testar os procedimentos deste artigo para ver como eles podem beneficiá-lo.

Recursos

Aprender

• Saiba mais sobre ajuste do DB2 no Centro de Informações do IBM DB2 para Linux, UNIX e Windows.
  
  
• Obtenha mais informações sobre o IBM TSOM no Centro de Informações do Tivoli Security Operations Manager.
  
  
• Acesse os recursos de suporte do Tivoli a partir do Portal de Suporte do IBM TSOM.
  
  
• Publicação do IBM Redbooks: Série de Guia de Implementação - IBM Tivoli Security Operations Manager: Obtenha as informações de que precisa para planejar seu evento de segurança e o projeto de gerenciamento de informações.
  
  
• Obtenha os recursos de que precisa para melhorar seu DB2 a partir da área de DB2 para Linux, UNIX, and Windows do developerWorks.
  
  

Obter produtos e tecnologias

• Faça o download de uma versão de avaliação do DB2 para Linux, UNIX e Windows.
  
  

Discutir

• Participar do fórum de discussão.
  
  
• Confira osblogs do developerWorks e participe do developerWorks .
  
  

Sobre os autores

Boudhayan Chakrabarty trabalha na Equipe de Segurança de Tivoli da IBM no Laboratório de Software da IBM na Índia, e é especializado em produtos de conformidade de segurança como IBM Tivoli Security Operations Manager (TSOM), IBM Tivoli Compliance Insight Manager (TCIM) e IBM Tivoli Security Information and Event Manager (TSIEM). Ele é formado em ciências da computação pela Escola de Engenharia em Bhubaneswar, na Índia.

Yogesh Gawali é analista de suporte técnico avançado de DB2 no Laboratório de Software da IBM na Índia, em Pune, onde seu foco principal é ajudar os clientes do IBM DB2 no mundo todo. Ele possui vasta experiência em diagnóstico e resolução de problemas de clientes. É formado em engenharia da computação pela Universidade de Pune. É possível entrar em contato com ele pelo e-mailyogeshgawali@in.ibm.com.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Configuração do ambientes do IBM DB2
• Projeto de espaços de tabela do DB2
• Ajuste dos buffer pools de banco de dados do IBM DB2
• Implementação do recurso de particionamento de tabela
• Configuração de logs de transação do DB2
• Ajustes de heaps da memória e variável de registro do DB2
• Criação de índices para um melhor desempenho com consultas de históricos do IBM TSOM
• Requisitos de espaço em disco do servidor do DB2
• Taxa de gravação do disco do servidor do DB2
• Localização do gargalo de E/S no processo de inserção de eventos
• Teste de desempenho de consultas de CMS com banco de dados backend
• Conclusão
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais