Solucionando problemas no ambiente de serviços de cluster do DB2

Uma abordagem sistemática à coleta de informações de diagnóstico e determinação de problemas

Esse tutorial orienta os DBAs e administradores de sistema na determinação de problemas para serviços de cluster do IBM ® DB2® pureScale® . Ao implementar sistemas IBM DB2 pureScale Feature for DB2 Enterprise Server Edition em produção, é preciso obter qualificações adequadas de determinação de problema. Esse tutorial fornece informações sobre a coleta de informações de diagnóstico quando ocorrem falhas e fornece informações adicionais para auxiliar no entendimento dos subcomponentes estreitamente integrados do DB2 pureScale Feature, como Cluster Caching Facility (CF), General Parallel File System (GPFS), Reliable Scalable Cluster Technology (RSCT) e IBM Tivoli Systems Automation for Multiplatforms (Tivoli SA MP).

Oleg Tyschenko, DB2 pureScale Development Team Leader, IBM

Photo of Oleg TyschenkoOleg Tyschenko lidera os esforços da equipe de desenvolvimento do mecanismo do DB2 na Irlanda e é membro da equipe de Alta Disponibilidade do DB2 para o desenvolvimento do DB2 pureScale. Ele tem mais de quinze anos de experiência técnica e de engenharia em gerenciamento da informação e tecnologias relacionadas. Atualmente, ele está envolvido em uma série de projetos de implementação do DB2 pureScale e de prova de conceito na Europa. Suas áreas de conhecimento incluem o DB2 pureScale Feature, alta disponibilidade e gerenciamento de cluster do DB2, o Tivoli SA for Multiplatforms e a implementação do GPFS. Oleg é formado em ciência da computação e tem diploma de MBA da Warwick Business School (UK).



Massimiliano Gallo, DB2 Functional Test Engineer, IBM

Photo of Massimiliano GalloMassimiliano Gallo é membro senior da equipe de Teste de Verificação Funcional do DB2 em Dublin e trabalha no teste do DB2 pureScale há vários anos. Ele tem mais de 10 anos de experiência em desenvolvimento de software e teste de produtos, tendo trabalhado em uma ampla variedade de tecnologias. Suas áreas de conhecimento incluem o DB2 pureScale Feature, alta disponibilidade e gerenciamento de cluster do DB2 e o Tivoli SA for Multiplatform. Massimiliano é formado em engenharia aeroespacial pela Sapienza University of Rome.



06/Set/2011

Antes de iniciar

Introdução

O IBM DB2 pureScale Feature for Enterprise Server Edition oferece tecnologia de armazenamento em cluster que ajuda a entregar alta disponibilidade e escalabilidade excepcional transparente para aplicativos, e oferece a melhor arquitetura para a plataforma distribuída. O DB2 pureScale Feature permite que o banco de dados continue o processamento durante indisponibilidades não planejadas e fornece capacidade quase ilimitada para qualquer carga de trabalho transacional. O ajuste de escala de seu sistema é simplesmente uma questão de conectar um host e emitir dois comandos simples. A arquitetura com base em cluster de disco compartilhado do DB2 pureScale Feature também ajuda a reduzir os custos por meio do uso eficiente de recursos do sistema.

O DB2 pureScale Feature combina vários componentes de software estreitamente integrados, que são instalados e configurados automaticamente ao implementar o DB2 pureScale Feature. Você interage com componentes como o gerenciador de cluster do DB2 e os serviços de cluster do DB2 por meio das visualizações e comandos de administração do DB2, como db2instance, db2icrt, db2iupdte db2cluster . A ferramenta db2cluster também fornece opções para resolução de problemas e determinação de problema. Adicionalmente, as mensagens que são geradas pelos subsistemas do gerenciador de cluster do DB2 são uma excelente fonte de informações para determinação de problema. Por exemplo, cada um dos gerenciadores de recurso das classes de recurso usadas por serviços de cluster do DB2 gravam informações de status em seus arquivos de log. Os arquivos de log do db2diag também fornecem informações úteis. Frequentemente, mensagens nos arquivos de log do db2diag explicam o motivo de uma falha e aconselham sobre como resolvê-la.

Os serviços de cluster do DB2 são capazes de manipular automaticamente a maioria das falhas em tempo de execução. No entanto, há tipos específicos de falhas que requerem que você tome ações para resolver as falhas. Por exemplo, o cabo de energia poderá ser desligado do host ou um cabo de rede poderá ser desconectado. Se os serviços de cluster do DB2 não puderem resolver a falha automaticamente, um campo de alerta será definido para notificar o DBA de que ocorreu um problema que requer atenção. Os DBAs podem ver o alerta quando verificarem o status da instância do DB2, como mostrado posteriormente.

Entendimento do modelo de recurso do DB2 pureScale Feature

O modelo de recurso da Versão 9.8 do DB2 pureScale Feature difere do modelo de recurso usado em uma instância de HA DB2 nos ambientes de banco de dados de uma e várias partições da Versão 9.7. Para obter informações adicionais sobre instâncias do HA DB2 em versões do DB2 anteriores ao 9.8 DB2 pureScale Feature, consulte os links de informações de histórico na seção Recursos no final do tutorial.

O novo modelo de recurso implementado na Versão do 9.8 DB2 pureScale Feature é necessário para representar cluster caching facilities (CFs) e o sistema de arquivos em cluster compartilhado.

Em uma instância de dados compartilhados do DB2 pureScale, um CF preenche a função principal, que contém os dados atualmente ativos para a instância de dados compartilhada. O segundo CF mantém uma cópia das informações pertinentes para recuperação imediata da função principal.

O novo modelo de recurso permite que o IBM Tivoli® System Automation for Multiplatforms (Tivoli SA MP) automatize adequadamente o movimento da função principal no caso de falha do nó principal do CF.

Os serviços de cluster do DB2 incluem três componentes principais:

  • Gerenciador do cluster: Tivoli SA MP, que inclui Reliable Scalable Cluster Technology (RSCT)
  • Sistema de arquivos em cluster compartilhado: IBM General Parallel File System (GPFS)
  • Administração do cluster do DB2: comandos e visualizações de administração do DB2 para gerenciar e monitorar o cluster
Figura 1. Serviços de cluster do DB2
Serviços de cluster do DB2

Os serviços de cluster do DB2 fornecem a infraestrutura essencial para que a instância de dados compartilhados esteja altamente disponível e para fornecer failover automático e reiniciar assim que a instância tiver sido criada.

Os elementos do cluster do DB2 são representações de entidades que são monitoradas e cujas mudanças de status são gerenciadas por serviços de cluster do DB2. Para fins desse tutorial, endereçaremos três tipos de elementos do cluster do DB2:

  • Hosts: Um host pode ser uma máquina física, uma LPAR (partição lógica de uma máquina física) ou uma máquina virtual.
  • Membros do DB2: Um membro do DB2 é o mecanismo de processamento principal e normalmente reside em seu host inicial. O host inicial de um membro do DB2 é o nome do host que foi fornecido como o local do membro quando ele foi adicionado à instância de dados compartilhada do DB2. Um membro do DB2 tem um único host inicial. Membros do DB2 podem aceitar conexões de clientes somente quando estiverem em execução em seu host inicial.
  • Cluster caching facilities (CFs): O cluster caching facility (CF) é um aplicativo de software gerenciado pelos serviços de cluster do DB2 que fornece serviços operacionais internos para uma instância de dados compartilhada do DB2.

Não há necessariamente um mapeamento um-para-um entre elementos do cluster do DB2 e os recursos e grupos de recursos do gerenciador do cluster subjacente.

Entendimento sobre como o DB2 pureScale Feature manipula falhas automaticamente

Quando uma falha ocorre na instância do DB2 pureScale, os serviços de cluster do DB2 automaticamente tentam reiniciar os recursos com falha. Quando e onde a reinicialização ocorre depende de diferentes fatores, como o tipo de recurso que apresentou falha e o ponto no ciclo de vida do recurso no qual a falha ocorreu.

Se uma falha de software ou de hardware em um host causar falha em um membro do DB2, os serviços de cluster do DB2 automaticamente reiniciarão o membro. Os membros do DB2 podem ser reiniciados no mesmo host (reinicialização local) ou, se ele falhar, em um host diferente (reinicializa do membro em modo de reinicialização simples. Reiniciar um membro em outro host é chamado de failover.

A reinicialização de membro inclui reinicializar processos do DB2 com falha e realizar recuperação de falha de membro (desfazer ou reaplicar transações do log) para recuperar quaisquer transações em andamento e liberar quaisquer bloqueios mantidos por elas. A reinicialização de membro também garante que páginas atualizadas foram gravadas no CF.

Quando um membro é reinicializado em um host diferente em modo de reinicialização simples, recursos mínimos são usados no novo host (que é o host inicial de outro membro do DB2). Um membro em execução em modo de reinicialização simples não processa novas transações, porque sua única finalidade é realizar a recuperação de falha de membro. Os bancos de dados no membro com falha são recuperados para um ponto de consistência o mais rapidamente possível. Isto permite que outros membros ativos acessem e alterem objetos de banco de dados que estavam bloqueados pelo membro encerrado anormalmente. Todas as transações em andamento do membro com falha são recuperadas e todos os bloqueios que estavam retidos no momento do encerramento anormal do membro são liberados. Apesar de o membro não aceitar novas transações, ele permanece disponível para resolução de transações em dúvida. Quando um membro do DB2 tiver realizado failover para um novo host, a capacidade total de processamento do cluster completo é reduzida temporariamente. Quando o host inicial estiver ativo e disponível novamente, o membro do DB2 realiza fail back automaticamente para o host inicial e o membro do DB2 é reiniciado em seu host inicial. A capacidade de processamento do cluster é restaurada assim que o membro do DB2 tiver realizado fail back e reinicializado em seu host inicial. Transações em todos os outros membros do DB2 não são afetadas durante o processo de failback.


Gerenciamento do ambiente de cluster para o DB2 pureScale Feature

Os serviços de cluster do DB2 fornecem visualizações e comandos de administração do DB2 para o gerenciamento do cluster. É possível usar os comandos do DB2 para gerenciar o sistema de arquivos compartilhado e o gerenciador do cluster, em vez de usar comandos separados do Tivoli SA MP ou GPFS. Por exemplo, ao criar uma instância do DB2 e adicionar novos membros do DB2 ou CFs, o gerenciador do banco de dados DB2 automaticamente chama as ações apropriadas para que o Tivoli SA MP e o GPFS configurem ou atualizem o domínio do mesmo nível conforme necessário. O domínio do mesmo nível é um cluster de hosts configurado para alta disponibilidade e pode consistir em todos os hosts no cluster ou pode ser um subconjunto de hosts na solução geral de cluster. O domínio do mesmo nível inclui os hosts como destinos de failover em uma política de rodízio, que escolhe um host dentre uma lista de hosts disponíveis.

Os serviços de cluster do DB2 monitoram e reagem aos comandos do cluster do banco de dados quando o gerenciador do banco de dados do DB2 chama qualquer uma das seguintes operações:

  • Criação e exclusão dos recursos do cluster como parte do processo de instalação e atualização
  • Expansão ou contração do gerenciador do cluster e do sistema de arquivos compartilhado para incluir hosts adicionais ou reduzir o número de hosts como parte da adição ou remoção de um host ou um membro do DB2
  • Encerramento da instância para manutenção planejada que não pode ser realizada on-line

Por exemplo, é possível usar o comando db2cluster para entrar em modo de manutenção, o comando db2icrt para criar uma nova instância do DB2 pureScale Feature e o comando db2iupdt para atualizar aquela instância.

Administração adicional dos serviços de cluster do DB2 é fornecida pelo comando db2cluster .

Uso do comando db2cluster para diagnosticar e reparar problemas

Em certas situações raras, o modelo de recurso do cluster poderá se tornar inconsistente, exigindo que você intervenha.

Os comandos db2cluster e db2instance permitem obter informações sobre o estado do modelo de recurso.

Neste exemplo, o modelo de recurso está íntegro:

> db2cluster -cm -verify –resources
Cluster manager resource states for the DB2 instance are consistent.

Neste caso, o modelo de recurso está inconsistente:

> db2cluster -cm -verify –resources
Cluster manager resource states for the DB2 instance are inconsistent. 
Consulte db2diag.log para obter mais informações sobre inconsistências.

Quando um modelo de recurso está inconsistente, é preciso ver as mensagens nos arquivos de log do db2diag para determinar detalhes sobre o problema. Normalmente, mensagens nos arquivos de log db2diag explicam o motivo da falha e aconselham sobre qual é o problema e como resolvê-lo. Como exemplo, esta mensagem indica que o arquivo db2nodes.cfg pode ter sido alterado manualmente. Se for esse o caso, a ação recomendada é reverter para uma versão anterior do arquivo db2nodes.cfg. Se não for esse o caso, então é possível ver uma ação alternativa recomendada para corrigir as inconsistências com o comando db2cluster.

Lista 1. Arquivo db2diag.log com detalhes da falha
2011-05-25-15.01.21.776169+060 E13778E572            LEVEL: Info
PID     : 21058                TID  : 46912898085712 KTID : 21058
PROC    : db2cluster
INSTANCE: db2inst1                NODE : 000
HOSTNAME: hostA
FUNCTION: DB2 UDB, high avail services, sqlhaUISDVerifyResources, probe:0
MESSAGE : Resource verification failed.  Recommendation: if db2nodes.cfg was
          modified, return it to its original form.
DATA #1 : String, 124 bytes
Issue a 'db2cluster -cm -repair -resources' command to fix the inconsistencies 
if the db2nodes.cfg was not manually changed.

Em muitos casos, é possível usar a ferramenta db2cluster para reparar recursos usando o seguinte comando:

> db2cluster -cm -repair -resources
All cluster configurations have been completed successfully. db2cluster exiting...

Note que o comando acima requer que a instância do DB2 seja encerrada.

Depois que o modelo de recurso for reparado, o gerenciador do cluster retorna a um estado operacional íntegro sem alertas emitido em qualquer entidade. Para obter informações adicionais sobre o status do cluster, é possível usar o seguinte comando:

Lista 2. Saída de db2instance -list
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib0
129 CF     CATCHUP    hostD     hostD        NO    -                0            hostD-ib0

HOSTNAME                   STATE                INSTANCE_STOPPED        ALERT
--------                   -----                ----------------        -----
hostD                      ACTIVE               NO                      NO
hostB                      ACTIVE               NO                      NO
hostC                      ACTIVE               NO                      NO
hostA                      ACTIVE               NO                      NO

O exemplo acima da saída de db2instance mostra o caso de um cluster íntegro com dois membros do DB2 e dois CFs. Não há alertas no cluster: todos os membros do DB2 estão iniciados e operacionais em seu host inicial. O CF representado pelo ID 128 detém a função PRIMARY e todos os hosts estão ativos, com a instância do DB2 iniciada em cada host.

Podemos verificar novamente se não há alertas usando o seguinte comando:

> db2cluster -cm -list -alert
There are no alerts

É possível verificar o estado dos hosts no domínio do mesmo nível usando o seguinte comando:

Lista 3. Sapuda de db2cluster -list -cm -host -state
> db2cluster -list -cm -host -state
HOSTNAME                    STATE
------------------------    -----------
hostA                       ONLINE
hostB                       ONLINE
hostC                       ONLINE
hostD                       ONLINE

Isso significa que o domínio do mesmo nível está on-line e operacional em todos os hosts.

Uso de mensagens do subsistema e dados de erros para solucionar problemas de eventos de gerenciamento do cluster do DB2

Para a resolução de problemas e determinação de problema, as mensagens que são geradas pelos subsistemas do gerenciador do cluster do DB2 são uma fonte importante de informações.

Nas plataformas Linux, as mensagens são gravadas no log do sistema (/var/log/messages).

Em plataformas AIX, o criador de logs do sistema não é configurado por padrão e as mensagens são gravadas no log de erro. Recomenda-se que você configure o criador de logs do sistema no arquivo /etc/syslog.conf. Depois de atualizar /etc/syslog.conf, é preciso executar o comando refresh –s syslogd.

Classes de recursos usadas pelos componentes dos serviços de cluster do DB2 são gerenciadas por uma variedade de gerenciadores de recursos (RMs). Qual gerenciador de recursos é responsável por gerenciar uma classe particular depende da classe. Um gerenciador de recursos é executado como um daemon que é controlado pelo system resource controller (SRC). Para obter mais informações sobre gerenciadores de recursos, consulte o Guia do Administrador e o Guia do Usuário do Tivoli SA MP. Está disponível um link na seção Recursos.

O Recurso Global RM (IBM.GblResRM)

Em cada nó, o Recurso Global RM (IBM.GblResRM) mantém um log de auditoria onde ele grava qualquer execução dos comandos start e stop e as operações de reconfiguração. O Recurso Global RM é operável somente no modo domínio do mesmo nível . Logs do Recurso Global RM estão localizados em:

/var/ct/<domain_name>/log/mc/IBM.GblResRM/

O nome de domínio pode ser descoberto usando o comando db2cluster:

> db2cluster -cm -list -domain
Domain Name: db2domain

Para visualizar o log de auditoria, emita o comando rpttr localmente em um nó:

rpttr -o dtic /var/ct/<domain_name>/log/mc/IBM.GblResRM/trace_summary*

Note que o acesso do root ao diretório /var/ct/<domain_name>/log/mc/IBM.RecoveryRM/ precisa ser fornecido para visualizar os logs com o comando rpttr, conforme mostrado acima. (Para ver abordagens alternativas que permitam que usuários não raiz leiam rastreios com privilégios menores, consulte Apêndice A).

O exemplo a seguir mostra o formato das informações de rastreamento no log de auditoria:

Lista 4. Arquivo de rastreio
[00] 04/15/11 17:07:43.324891 T(4150437552) ____  ******************* Trace Started - Pid 
= 7268 **********************
[00] 04/18/11 09:08:57.498711 T(4150433456) ____  ******************* Trace Started - Pid 
= 6735 **********************
[00] 04/19/11 11:41:31.832310 T(4128861088) _GBD Monitor detect OpState change for resourc
e Name=instancehost_db2inst1_hostD OldOpState=0 NewOpState=2 Handle=0x6028 0xffff 0xb82b28
63 0x4a725d1a 0x1215ee4e 0xc2f1e0b0
[00] 04/19/11 11:41:32.574276 T(4128861088) _GBD Monitor detect OpState change for resourc
e Name=instancehost_db2inst1_hostD OldOpState=2 NewOpState=1 Handle=0x6028 0xffff 0xb82b28
63 0x4a725d1a 0x1215ee4e 0xc2f1e0b0
[00] 04/19/11 11:42:07.255763 T(4123835296) _GBD Monitor detect OpState change for resourc
e Name=cacontrol_db2inst1_128_hostD OldOpState=0 NewOpState=2 Handle=0x6028 0xffff 0xb82b2
863 0x4a725d1a 0x1215ee57 0x8657b518
[00] 04/19/11 11:42:08.973508 T(4123736992) _GBD Monitor detect OpState change for resourc
e Name=ca_db2inst1_0-rs OldOpState=0 NewOpState=2 Handle=0x6028 0xffff 0xb82b2863 0x4a725d
1a 0x1215ee57 0xc96670b0
[00] 04/19/11 11:42:19.740162 T(4123638688) _GBD Monitor detect OpState change for resourc
e Name=primary_db2inst1_900-rs OldOpState=0 NewOpState=2 Handle=0x6028 0xffff 0xb82b2863 0
x4a725d1a 0x1215ee5a 0x63655418
[00] 04/19/11 11:50:14.697605 T(4123835296) _GBD Monitor detect OpState change for resourc
e Name=cacontrol_db2inst1_128_hostD OldOpState=2 NewOpState=1 Handle=0x6028 0xffff 0xb82b2
863 0x4a725d1a 0x1215ee57 0x8657b518

Observação: Para a leitura fácil dos rastreios formatados, é possível direcionar a saída do comando rpttr para um arquivo, uma vez que a saída contém um volume significativo de registros do log de eventos.

O Recovery RM (IBM.RecoveryRM)

O Recovery RM (IBM.RecoveryRM) serve como o mecanismo de decisão do Tivoli SA MP. Um Recovery RM é executado em cada host do cluster, com um Recovery RM designado como o principal. O Recovery RM principal é responsável por avaliar as informações de monitoramento e age em informações fornecidas pelo IBM.GlbResRM. Quando surge uma situação que requer intervenção, o Recovery RM controla as decisões que resultam em operações de start ou stop nos recursos, conforme necessário.

Os logs do Recovery RM estão localizados em:

/var/ct/<domain_name>/log/mc/IBM.RecoveryRM/

O Recovery RM mantém um log de auditoria de:

  • Todas as solicitações
  • Respostas de erro às solicitações
  • Informações sobre a política atual
  • Informações sobre problemas de ligação

Para visualizar o log, é preciso emitir o comando rpttr no host no qual o Recovery RM principal está em execução. Primeiro, é possível determinar o host usando o comando lssrc , por exemplo:

Lista 5. Saída do comando lssrc
lssrc -ls IBM.RecoveryRM | grep Master

Exemplo de saída:
   Master Node Name     : hostD (node number =  4)
rpttr -o dtic /var/ct/<domain_name>/log/mc/IBM.RecoveryRM/trace_summary*

Note que o acesso do root ao diretório /var/ct/<domain_name>/log/mc/IBM.RecoveryRM/ precisa ser fornecido para visualizar os logs com o comando rpttr, conforme mostrado acima (para ver abordagens alternativas que permitam que usuários não raiz leiam rastreios com menos privilégios, consulte o Apêndice A).

Um exemplo do arquivo de rastreio de formato é:

Lista 6. Arquivo de rastreio de formato
[02] 05/25/11 14:59:25.487143 T(4112939936) _RCD ReportMoveState: Resource : db2_db2inst1_
1-rs/Float/IBM.Application  reported move state change: a000 - preparing: 0
[02] 05/25/11 14:59:25.487651 T(4112939936) _RCD ReportMoveState: Resource : db2_db2inst1_
1-rs/Fixed/IBM.Application/hostA  reported move state change: db2_db2inst1_1-rs/Fixed/IBM.
Application/hostA  reported state change: 2
[02] 05/25/11 14:59:25.488380 T(4112939936) _RCD Offline request injected: db2_db2inst1_0-
rg/ResGroup/IBM.ResourceGroup
[02] 05/25/11 14:59:25.488637 T(4112939936) _RCD ReportMoveState: Resource : db2_db2inst1_
0-rs/Float/IBM.Application  reported move state change: a000 - preparing: 0
[02] 05/25/11 14:59:25.488914 T(4112939936) _RCD ReportMoveState: Resource : db2_db2inst1_
0-rs/Fixed/IBM.Application/hostA  reported move state change: a000 - preparing: 0
[02] 05/25/11 14:59:25.488955 T(4112939936) _RCD ReportState: Resource : db2_db2inst1_0-rs
/Fixed/IBM.Application/hostA  reported state change: 2
[02] 05/25/11 14:59:25.489642 T(4112939936) _RCD Offline request injected: idle_db2inst1_9
97_hostA-rg/ResGroup/IBM.ResourceGroup

Observação: Para a leitura fácil dos rastreios formatados, é possível direcionar a saída do comando rpttr para um arquivo, uma vez que a saída contém um volume significativo de logs de eventos.

O Configuration RM (IBM.ConfigRM)

O Configuration RM (IBM.ConfigRM) é usado no DB2 pureScale Cluster Services. Além disso, ajuda a fornecer suporte a quorum, que é um meio de garantir a integridade dos dados quando partes de um cluster perdem a comunicação. O Configuration RM atualiza seus logs somente quando o estado muda (um novo evento ocorre). Os logs estão localizados no seguinte caminho:

/var/ct/IW/log/mc/IBM.ConfigRM/

O serviço de topologia em cluster registra quaisquer alterações em um estado de comunicação do domínio do mesmo nível RSCT. Se um adaptador de rede for considerado como indisponível, a mudança de estado do adaptador é registrada nos rastreios do Configuration RM. Os logs dos serviços de topologia estão localizados no seguinte caminho, onde <domain_name> é o nome de seu domínio:

/var/ct/<domain_name>/log/cthats

O daemon "hatsd" é o daemon principal responsável para a maior parte do trabalho nos serviços de topologia. Ele executa a organização de nível mais alto, incluindo a configuração de sinais de heartbeat. Um sinal de heartbeat é um processo em que cada nó envia uma mensagem a um de seus vizinhos e espera receber uma resposta de um de seus outros vizinhos. O daemon "hatsd" pode, algumas vezes, falhar ao detectar uma mudança de estado da topologia para o Network Interface Module (NIM), portanto verifique primeiro os logs do NIM. Os logs principais iniciam com "nim" e contêm o nome da interface sendo monitorada:

nim.cthats.ib0 nim.cthats.ib0.001 nim.cthats.ib0.002 nim.cthats.ib0.003

A biblioteca netmon, usada pelo NIM, monitora o estado de cada adaptador (usado pelos processos NIM Topology Services) para determinar se o adaptador local está ativo. O nome do arquivo de log corresponde ao nome do log do NIM mais o prefixo "nmDiag":

nmDiag.nim.cthats.ib0.001

O arquivo de log para o GPFS

O GPFS grava mensagens operacionais e dados de erros no arquivo de log do MMFS. O arquivo de log MMFS está localizado no diretório /var/adm/ras em cada nó e é chamado de mmfs.log.date.nodeName, onde data é o registro de data e hora de quando a instância do GPFS iniciou no nó e nodeName é o nome do nó. É possível encontrar o arquivo de log do MMFS mais recente usando o nome de arquivo simbólico /var/adm/ras/mmfs.log.latest.

O GPFS registra falhas do sistema de arquivos ou do disco usando a facilidade de criação de log de erros fornecida pelo sistema operacional:

  • O recurso syslog em plataformas Linux
  • O recurso errpt em plataformas AIX

É possível visualizar essas falhas emitindo o seguinte comando em uma plataforma AIX:

errpt -a

Emita este comando em uma plataforma Linux:

grep "mmfs:" /var/log/messages

Cenário 1: Falha de membro e reinicialização em seu host inicial, com logs comentados

Este cenário aborda o caso em que uma falha de software ocorre em um membro do DB2 e ele pode ser automaticamente reinicializado em seu host inicial. Para os fins de demonstração deste cenário, o processo db2sysc no membro do DB2 será encerrado.

Depois que as etapas forem exibidas, segue-se uma explicação detalhada de quais informações são gravadas nos logs.

Inicialmente, há quatro hosts (chamados hostA, hostB, hostC, hostD) que podem acessar os dados compartilhados da instância do DB2 chamada db2inst1 por meio de um sistema de arquivos em cluster. A instância contém dois membros do DB2: o membro 0 do DB2 está em execução no host inicial hostA e o membro 1 do DB2 está em execução no host inicial hostB.

O comando db2instance mostra o estado inicial do cluster íntegro:

Lista 7. Saída do comando db2instance com cluster íntegro
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostB     hostB        NO    0                0            hostB-ib0
128 CF     PRIMARY    hostC     hostC        NO    -                0            hostC-ib0
129 CF     PEER       hostD     hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

Para demonstrar o comportamento no caso de uma falha de software para o membro 1 do DB2 no hostB, primeiro emitimos o comando psdb2 para listar todos os processos do gerenciador do banco de dados em execução no hostB para a instância atual, db2inst1:

Lista 8. Saída de psdb2
> psdb2
25014 db2sysc (idle 997)
25018 db2sysc (idle 998)
25027 db2sysc (idle 999)
	
25416 db2sysc 1
	
25440 db2vend (PD Vendor Process - 1) 0 0
	
25517 db2acd 1 ,0,0,0,1,0,0,0000,1,0,8a8e50,14,1e014,2,0,1,11fc0,0x210000000,0x210000000,1
600000,1138029,2,372802f

A seguir, usamos o comando de sistema kill -9 25416 para remover o processo db2sysc associado com o membro 1 do DB2 no hostB:

> kill -9 25416

Assim que o processo for removido, você verá que a reinicialização do membro do é iniciada, como mostra a execução do comando db2instance imediatamente após o encerramento do processo:

Lista 9. Execução do db2instance depois de encerrar o processo
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER RESTARTING hostB     hostB        NO    0                0            hostB-ib0
128 CF     PRIMARY    hostC     hostC        NO    -                0            hostC-ib0
129 CF     PEER       hostD     hostD        NO    -                0            hostD-ib0

HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

Ao executar o comando psdb2 , também podemos ver o processo db2start que está reinicializando o membro do DB2:

Lista 10. Saída do psdb2 mostrando a reinicialização do membro do DB2
> psdb2
25014 db2sysc (idle 997)
25018 db2sysc (idle 998)
25027 db2sysc (idle 999)
	
27497 db2start NOMSG DATA 1 RESTART HOSTNAME hostB CM NETNAME hostB-ib0

Também é possível obter o estado do recurso a partir do modelo de recurso na saída do comando lssam:

Lista 11. Saída do comando lssam
Pending online IBM.ResourceGroup:db2_db2inst1_1-rg Nominal=Online
'- Pending online IBM.Application:db2_db2inst1_1-rs
|- Offline IBM.Application:db2_db2inst1_1-rs:hostA
'- Pending online IBM.Application:db2_db2inst1_1-rs:hostB

O recurso db2_db2inst1_1-rs associado com o membro 1 do DB2 está no estado PENDING ONLINE, o que significa que o membro está sendo reiniciado pelos serviços do cluster do DB2, conforme relatado pelo comando db2instance .

À medida que o membro do DB2 é reiniciado em seu host inicial, o comando db2instance informará que o estado do cluster retornou à integridade e o membro do DB2 reiniciado está pronto para processar uma carga de trabalho novamente:

Lista 12. Saída do comando db2instance
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostB     hostB        NO    0                0            hostB-ib0
128 CF     PRIMARY    hostC     hostC        NO    -                0            hostC-ib0
129 CF     PEER       hostD     hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

Eventos correspondentes nos logs

O recurso db2_db2inst1_1-rs correspondente ao membro 1 do DB2 é informado como indisponível no hostB (IBM.RecoveryRM):

2011-05-25 18:10:34.421792 R(hostA) T(4118616992) _RCD ReportState: Resource: db2_db2inst
1_1-rs/Fixed/IBM.Application/hostB  reported state change: 2

Subsequentemente, o Recovery RM emite uma solicitação de limpeza para o membro 1 do DB2 em seu host inicial hostB:

2011-05-25 18:10:34.583168 R(hostA) T(4118616992) _RCD Cleanup: Resource db2_db2inst1_1-rs
cleaned up on node hostB

A solicitação de limpeza é informada como bem-sucedida (IBM.RecoveryRM):

2011-05-25 18:10:36.506559 R(hostA) T(4118616992) _RCD RIBME-HIST: db2_db2inst1_1-rs/Float
/IBM.Application Cleanup: Cleanup order successfully completed.

Também é possível ver o comando de limpeza correspondente executado no log do GblRes(IBM.GblResRM):

Lista 13. Arquivo de rastreio formatado com o comando de limpeza
2011-05-25 18:10:34.584000 G(hostB) T(4125461408) _GBD Running cleanup command "/home/db2i
nst1/sqllib/adm/db2rocm 1 DB2 db2inst1 1 CLEANUP" for resource 0x6028 0xffff 0x5b83a378 0x
a4e2ad4a 0x1221057d 0xf2eda550. Supporter: 0x0000 0x0000 0x00000000 0x00000000 0x00000000 
0x00000000.
	
2011-05-25 18:10:36.498548 G(hostB) T(4122803104) _GBD Cleanup command for application 
resource "db2_db2inst1_1-rs" (handle 0x6028 0xffff 0x5b83a378 0xa4e2ad4a 0x1221057d 
0xf2eda550) succeeded with exit code 0

É possível ver os eventos correspondentes nos arquivos de log do db2diag quando o membro do DB2 tiver executado com sucesso a limpeza em seu host inicial hostB:

Lista 14. Arquivo de log do db2diag quando o membro do DB2 tiver executado a limpeza
2011-05-25-18.10.36.485126-240 I128222E517           LEVEL: Event
PID     : 27434                TID  : 46912763496800 PROC : db2rocm 1 [db2inst1]
INSTANCE: db2inst1             NODE : 001
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:949
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-05-25-18.10.34.787912000
DATA #2 : String, 32 bytes
db2rocm 1 DB2 db2inst1 1 CLEANUP
DATA #3 : String, 5 bytes
BEGIN
	
2011-05-25-18.10.36.492805-240 I132248E520           LEVEL: Event
PID     : 27434                TID  : 46912763496800 PROC : db2rocm 1 [db2inst1]
INSTANCE: db2inst1             NODE : 001
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1796
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), 
PD_TYPE_SQLHA_ER_PDINFO, 80 bytes
Original timestamp: 2011-05-25-18.10.36.484918000
DATA #2 : String, 32 bytes
db2rocm 1 DB2 db2inst1 1 CLEANUP
DATA #3 : String, 7 bytes
SUCCESS

Quando a limpeza estiver concluída, você verá uma solicitação on-line emitida para reinicializar o membro do DB2 em seu host inicial hostB (IBM.RecoveryRM):

2011-05-25 18:10:36.563398 R(hostB) T(4118616992) _RCD Resource::doRIBMAction 
Solicitação on-line com relação ao db2_db2inst1_1-rs no nó hostB.

Finalmente, o membro do DB2 é reinicializado com sucesso e seu estado de recurso correspondente é informado novamente como ONLINE (IBM.RecoveryRM):

2011-05-25 18:10:54.947427 R(hostB) T(4118616992) _RCD ReportState: Resource : db2_db2inst
1_1-rs/Fixed/IBM.Application/hostB  reported state change: 1

Também é possível ver a execução correspondente da solicitação on-line (IBM.GblResRM):

Lista 15. Execução correspondente da solicitação on-line
2011-05-25 18:10:36.563972 G(hostB) T(4128926624) _GBD Bringing application resource 
online: Name=db2_db2inst1_1-rs Handle=0x6028 0xffff 0x5b83a378 0xa4e2ad4a 
0x1221057d 0xf2eda550

2011-05-25 18:10:54.937889 G(hostB) T(4122803104) _GBD Start command for application resou
rce "db2_db2inst1_1-rs" (handle 0x6028 0xffff 0x5b83a378 0xa4e2ad4a 0x1221057d 0xf2eda550)
succeeded with exit code 0

Verificando a saída do comando lssam , você verá que o recurso está, realmente, on-line novamente em seu host inicial hostB (apesar de estar off-line no possível host convidado hostA):

Lista 16. Saída do lssam mostrando o recurso on-line no host inicial
Online IBM.ResourceGroup:db2_db2inst1_1-rg Nominal=Online
'- Online IBM.Application:db2_db2inst1_1-rs
'- Online IBM.Application:db2_db2inst1_1-rs:hostB

Nos arquivos de log do db2diag, os seguintes eventos de início do membro do DB2 são registrados em log:

Lista 17. Arquivo de log do db2diag mostrando os eventos de início do membro do DB2
2011-05-25-18.10.36.777580-240 I132769E364           LEVEL: Event
PID     : 27496                TID  : 46912763496800 PROC : db2rocm 1 [db2inst1]
INSTANCE: db2inst1             NODE : 001
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:949
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 1 START
DATA #2 : String, 5 bytes
BEGIN
	
2011-05-25-18.10.54.932894-240 I534141E367           LEVEL: Event
PID     : 27496                TID  : 46912763496800 PROC : db2rocm 1 [db2inst1]
INSTANCE: db2inst1             NODE : 001
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1796
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 1 START
DATA #2 : String, 7 bytes
SUCCESS

O membro 1 do DB2 reinicializa com sucesso em seu host inicial, hostB, e agora pode processar novas transações. O estado para o membro 1 do DB2 é STARTED novamente e, se o status dos membros for consultado usando o comando db2instance -list , o host atual ainda é exibido como hostB.


Cenário 2: Failover e failback de membro (cenário do cabo desconectado), com logs comentados

Neste cenário, ocorre um erro de hardware. Especificamente, alguém acidentalmente puxa o cabo de comunicação do InfiniBand.

Os serviços de cluster do DB2 reiniciam automaticamente o membro em modo de reinicialização simples em outro host ativo no cluster. Quando o host inicial com falha ficar on-line novamente, o membro em modo de reinicialização simples executará failback para seu host inicial e se tornará um membro totalmente ativo que pode voltar a processar novas transações.

Depois que as etapas forem exibidas, segue-se uma explicação detalhada de quais informações são gravadas nos logs.

Inicialmente, há quatro hosts (chamados hostA, hostB, hostC, hostD) que podem acessar os dados compartilhados da instância do DB2 chamada db2inst1 por meio de um sistema de arquivos em cluster. O membro 0 do DB2 está em execução no host inicial hostA e o membro 1 do DB2 está em execução no host inicial hostC. Há um link do InfiniBand entre os membros e o CF, que é essencial para os membros do DB2 e para o CF.

Lista 18. Saída do db2instance mostrando a configuração
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib1
129 CF     CATCHUP    hostD     hostD        NO    -                0            hostD-ib1

HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE                             NO           NO
hostB                ACTIVE                             NO           NO
hostC                ACTIVE                             NO           NO
hostD                ACTIVE                             NO           NO

Quando alguém tropeça e desliga o cabo de comunicação do InfiniBand, os serviços de cluster do DB2 detectam que ocorreu uma falha no hostA. O estado do recurso da interface de rede muda para OFFLINE para o hostA. É possível obter o estado do recurso a partir da saída do comando lssam :

Lista 19. Estado do recurso a partir do lssam
Online IBM.Equivalency:db2_private_network_db2inst1_0
|- Offline IBM.NetworkInterface:ib0:hostA
'- Online IBM.NetworkInterface:ib0:hostC

Os serviços de cluster do DB2 iniciam automaticamente uma reinicialização do membro 0 em um host convidado:

Lista 20. db2instance mostrando a reinicialização do membro 0
>$ db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0  MEMBER RESTARTING hostA   hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib1
129 CF     CATCHUP    hostD     hostD        NO    -                0            hostD-ib1

HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      YES
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO
There is currently an alert for a member, CF, or host in the data-sharing instance. For mo
re information on the alert, its impact, and how to clear it, run the following command: '
db2cluster -cm -list -alert'.

Quando os serviços de cluster do DB2 concluírem a reinicialização do membro 0, podemos ver que ele foi reinicializado no host convidado hostC:

Lista 21. db2instance mostrando o alerta
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0  MEMBER WAITING_FOR.hostA  hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib1
129 CF     CATCHUP    hostD     hostD        NO    -                0            hostD-ib1

HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      YES
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO
There is currently an alert for a member, CF, or host in the data-sharing instance. For 
more information on the alert, its impact, and how to clear it, run the following 
command: 'db2cluster -cm -list -alert'.


$ db2cluster -cm -list -alert
1.
Alert: Host 'hostA' is not responding on the network adapter 'ib0'. Check the operating
system for error messages related to this network adapter and chec k the connections to 
the adapter as well.

Action: This alert will clear itself when the network adapter starts to respond. This 
alert cannot be cleared manually with db2cluster.

Impact: DB2 members and CFs on the affected host that require access to network adapter 
'ib0' will not be operational until the problem is resolved. While the network adapter 
is offline, the DB2 members on this host will be in restart light mode on other systems, 
and will be in the WAITING_FOR_FAILBACK state. The affected CFs will not be available 
for CF failover and will remain in the STOPPED state until the network adapter issue is 
resolved.

Depois de religar o cabo do InfiniBand, os serviços de cluster do DB2 automaticamente detectam que o hostA está novamente on-line e redefine a interface de rede para ONLINE para o hostA:

Lista 22. Redefinição da interface de rede
Online IBM.Equivalency:db2_private_network_db2inst1_0
|- Online IBM.NetworkInterface:ib0:hostA
'- Online IBM.NetworkInterface:ib0:hostC

A seguir, os serviços de cluster do DB2 encerram o membro 0 do DB2 no host convidado hostC e chama uma reinicialização normal do membro 0 do DB2 no host inicial hostA:

Lista 23. Reinicialização do membro 0 do DB2 no host inicial
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0  MEMBER STARTED    hostA   hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib1
129 CF     CATCHUP    hostD     hostD        NO    -                0            hostD-ib1
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO
> db2cluster -cm -list -alert
There are no alerts

Eventos correspondentes nos logs:

A interface de rede correspondente ao adaptador ib0 no host hostA é informado como indisponível (IBM.RecoveryRM):

2011-02-28 06:15:26.411814 R(hostA) T(4117486496) _RCD ReportState: Resource : ib0/Fixed/I
BM.NetworkInterface/hostA reported state change: 2

O Recovery RM emite uma solicitação off-line com relação ao membro 0 em seu host inicial hostA:

Lista 24. Solicitação off-line com relação ao membro 0
2011-02-28 06:15:26.421832 R(hostA) T(4117486496) _RCD Resource::doRIBMAction Offline Requ
est against db2_db2inst1_0-rs on node hostA.
2011-02-28 06:15:26.425470 G(hostA) T(4127394720) _GBD Taking application resource offline
: Name=db2_db2inst1_0-rs Handle=0x6028 0xffff 0x77babcfd 0xac578906 0x120693f5 0xeea64740
2011-02-28 06:15:26.425613 R(hostA) T(4117486496) _RCD ReportState: Resource : db2_db2inst
1_0-rs/Fixed/IBM.Application/hostA reported state change: 6
2011-02-28 06:15:29.009743 G(hostA) T(4123753376) _GBD Stop command for application resour
ce "db2_db2inst1_0-rs" (handle 0x6028 0xffff 0x77babcfd 0xac578906 0x120693f5 0xeea64740) 
succeeded with exit code 0
2011-02-28 06:15:29.288071 R(hostA) T(4117486496) _RCD ReportState: Resource : db2_db2inst
1_0-rs/Fixed/IBM.Application/hostA reported state change: 2

É possível ver os eventos correspondentes nos arquivos de log do db2diag quando o membro tiver sido encerrado com sucesso em seu host inicial hostA:

Lista 25. Arquivo db2diag.log quando o membro tiver sido encerrado no host inicial
2011-02-28-06.15.28.988205-300 I981598E541           LEVEL: Event
PID : 1613                     TID : 46912880928864  KTID : 1613
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostA
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:915
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-02-28-06.15.26.693115000
DATA #2 : String, 40 bytes
db2rocm 1 DB2 db2inst1 0 STOP (SA_RESET)
DATA #3 : String, 5 bytes
BEGIN
	
2011-02-28-06.15.29.001230-300 I984566E544           LEVEL: Event
PID : 1613                     TID : 46912880928864  KTID : 1613
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostA
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1590
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-02-28-06.15.28.987779000
DATA #2 : String, 40 bytes
db2rocm 1 DB2 db2inst1 0 STOP (SA_RESET)
DATA #3 : String, 7 bytes
SUCCESS

Agora, o membro 0 foi reinicializado no host convidado hostC (IBM.RecoveryRM):

Lista 26. Membro 0 reinicializado no host convidado
2011-02-28 06:15:29.439708 R(hostA) T(4117486496) _RCD Resource::doRIBMAction Online Reque
st against db2_db2inst1_0-rs on node hostC.
2011-02-28 06:15:35.491788 G(hostC) T(4122594208) _GBD Start command for application resou
rce "db2_db2inst1_0-rs" (handle 0x6028 0xffff 0x5b83a378 0xa4e2ad4a 0x120693f5 0xeea67620)
succeeded with exit code 0
2011-02-28 06:15:35.496093 R(hostA) T(4117486496) _RCD ReportState: Resource : db2_db2inst
1_0-rs/Fixed/IBM.Application/hostC reported state change: 1

Os arquivos de log do db2diag mostram:

Lista 27. db2diag.log mostrando o início no host convidado
2011-02-28-06.15.29.710141-300 I996097E381           LEVEL: Event
PID : 17290                    TID : 46912880937056  KTID : 17290
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostC
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:915
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 0 START
DATA #2 : String, 5 bytes
BEGIN
	
2011-02-28-06.15.35.482268-300 I1342111E384          LEVEL: Event
PID : 17290                    TID : 46912880937056  KTID : 17290
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostC
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1590
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 0 START
DATA #2 : String, 7 bytes
SUCCESS

Quando o cabo do InfiniBand é ligado novamente, o adaptador (ib0) no hostA informa como on-line novamente (IBM.RecoveryRM):

2011-02-28 06:22:40.503749 R(hostA) T(4117486496) _RCD ReportState: Resource : ib0/Fixed/I
BM.NetworkInterface/hostA reported state change: 1

Portanto, o membro 0 está parado no host convidado hostC:

Lista 28. Membro 0 parado no host convidado
2011-02-28 06:22:40.549388 R(hostA) T(4117486496) _RCD Resource::doRIBMAction Offline Requ
est against db2_db2inst1_0-rs on node hostC.
2011-02-28 06:22:43.402484 G(hostC) T(4122594208) _GBD Stop command for application resour
ce "db2_db2inst1_0-rs" (handle 0x6028 0xffff 0x5b83a378 0xa4e2ad4a 0x120693f5 0xeea67620) 
succeeded with exit code 0

Os arquivos de log do db2diag mostram o evento:

Lista 29. Log do db2diag mostrando o evento
2011-02-28-06.22.43.373821-300 I2291438E542          LEVEL: Event
PID : 19699                    TID : 46912880937056  KTID : 19699
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostC
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:915
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-02-28-06.22.40.810556000
DATA #2 : String, 40 bytes
db2rocm 1 DB2 db2inst1 0 STOP (SA_RESET)
DATA #3 : String, 5 bytes
BEGIN
	
2011-02-28-06.22.43.392086-300 I2295670E545          LEVEL: Event
PID : 19699                    TID : 46912880937056  KTID : 19699
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostC
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1590
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-02-28-06.22.43.373504000
DATA #2 : String, 40 bytes
db2rocm 1 DB2 db2inst1 0 STOP (SA_RESET)
DATA #3 : String, 7 bytes
SUCCESS

Agora, o membro 0 foi reinicializado em seu host inicial, hostA (IBM.RecoveryRM):

Lista 30. Membro 0 reinicializado no host inicial
2011-02-28 06:22:43.825145 R(hostA) T(4117486496) _RCD Resource::doRIBMAction Online Reque
st against db2_db2inst1_0-rs on node hostA.
2011-02-28 06:22:55.189619 G(hostA) T(4123360160) _GBD Start command for application resou
rce "db2_db2inst1_0-rs" (handle 0x6028 0xffff 0x77babcfd 0xac578906 0x120693f5 0xeea64740)
succeeded with exit code 0
2011-02-28 06:22:55.193415 R(hostA) T(4117486496) _RCD ReportState: Resource : db2_db2inst
1_0-rs/Fixed/IBM.Application/hostA reported state change: 1

Os arquivos de log do db2diag mostram o evento:

Lista 31. Arquivo de log do db2diag mostrando o membro 0 reinicializado
2011-02-28-06.22.44.102847-300 I2369547E380          LEVEL: Event
PID : 4468                     TID : 46912880928864  KTID : 4468
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostA
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:915
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 0 START
DATA #2 : String, 5 bytes
BEGIN
	
2011-02-28-06.22.55.178487-300 I2763321E383          LEVEL: Event
PID : 4468                     TID : 46912880928864  KTID : 4468
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostA
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1590
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 0 START
DATA #2 : String, 7 bytes
SUCCESS

Cenário 3: Controle do Cluster Caching Facility (CF)

Neste cenário, uma instância do DB2 pureScale Feature foi configurada com dois cluster caching facilities (CFs). Um foi designado como o CF principal e o outro como CF secundário. Os membros do DB2 automaticamente duplicam informações críticas, como status de modificação de bloqueio e páginas do buffer pool do grupo, para ambos os CFs. Como no início desse cenário o CF secundário está no estado peer, sabemos que as informações críticas estão duplicadas e atualizadas no CF secundário. Se o CF principal falhar, o CF secundário rapidamente assume as responsabilidades do CF principal para que a falha seja praticamente invisível para os aplicativos.

Inicialmente, há quatro hosts (chamados hostA, hostB, hostC, hostD) que podem acessar os dados compartilhados da instância do DB2 chamada db2inst1 por meio de um sistema de arquivos em cluster. O membro 0 do DB2 está em execução no host inicial hostA e o membro 1 do DB2 está em execução no host inicial hostC. Há um link do InfiniBand entre os membros e o CF, que é essencial para os membros do DB2 e para os CFs e, portanto, existem dependências à equivalência do InfiniBand de ambos os membros e dos CFs.

Lista 32. Saída do db2instance mostrando a configuração
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib0
129 CF     PEER       hostD     hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

Se o CF falhar no hostB, há o failover da função principal para um CF secundário, que está em um estado peer. Os serviços de cluster do DB2 detectarão que os processos de CF estão indisponíveis em um host inicial e chamarão o comando de limpeza do CF no host com falha (IBM.RecoveryRM):

Lista 33. Serviços de cluster detectam que os processos de CF estão indisponíveis e chamam a limpeza
2011-04-21 11:17:49.485951 G(hostB) T(4124957600) _GBD Monitor detect OpState change for r
esource Name=ca_db2inst1_0-rs OldOpState=1 NewOpState=2 Handle=0x6028 0xffff 0x88a0f77a 0x
4444ff43 0x12168f02 0x33bd39f8
2011-04-21 11:17:49.547613 R(hostB) T(4118584224) _RCD Cleanup: 
Resource ca_db2inst1_0-rs/Concurrent/IBM.Application cleanup order for constituent 
a_db2inst1_0-rs/Fixed/IBM.Application/hostB

Os arquivos de log do db2diag contêm entradas de log para a emissão desse comando e o resultado da limpeza:

Lista 34. Arquivo de log do db2diag mostrando a limpeza
2011-04-21-11.17.54.442397-240 I45376528E522         LEVEL: Event
PID     : 4287                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:927
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-04-21-11.17.50.333529000
DATA #2 : String, 34 bytes
db2rocme 1 CF db2inst1 128 CLEANUP
DATA #3 : String, 5 bytes
BEGIN
	
2011-04-21-11.17.54.450788-240 I45379976E525         LEVEL: Event
PID     : 4287                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1639
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-04-21-11.17.54.442222000
DATA #2 : String, 34 bytes
db2rocme 1 CF db2inst1 128 CLEANUP
DATA #3 : String, 7 bytes
SUCCESS

A função principal é iniciada no CF secundário (no hostD):

Lista 35. db2instance mostra a função principal iniciada no CF secundário
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     RESTARTING hostB     hostB        NO    -                0            hostB-ib0
129 CF     BECOMING_PR.hostD   hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

IBM.RecoveryRM:

Lista 36. IBM.RecoveryRM
2011-04-21 11:17:52.137049 G(hostB) T(4124760992) _GBD Stop command for application resour
ce "primary_db2inst1_900-rs" (handle 0x6028 0xffff 0x88a0f77a 0x4444ff43 0x12168f06 0xe30a
b210) succeeded with exit code 0
2011-04-21 11:17:52.537322 R(hostB) T(4118584224) _RCD Cleanup: Resource primary_db2inst1_
900-rs/Fixed/IBM.Application/hostD is dirty.
2011-04-21 11:17:52.539174 G(hostD) T(4128926624) _GBD Bringing application resource onlin
e: Name=primary_db2inst1_900-rs Handle=0x6028 0xffff 0x1802cd9b 0xb77f5380 0x12168f06 0xe3
85c1f8
2011-04-21 11:17:52.543773 R(hostB) T(4118584224) _RCD Resource::doRIBMAction Online Reque
st against primary_db2inst1_900-rs on node hostD.
2011-04-21 11:18:08.446049 G(hostD) T(4123556768) _GBD Start command for application res
ource "primary_db2inst1_900-rs" (handle 0x6028 0xffff 0x1802cd9b 0xb77f5380 0x12168f06 0xe
385c1f8) succeeded with exit code 0

Os arquivos de log do db2diag contêm o seguinte evento para a reinicialização da função principal:

Lista 37. Arquivo de log do db2diag mostrando o evento para a reinicialização da função principal
2011-04-21-11.17.52.784069-240 I45349553E400         LEVEL: Event
PID     : 2560                 TID  : 46912733618560 PROC : db2rocme 900 [db2inst1]
INSTANCE: db2inst1             NODE : 900
HOSTNAME: hostD
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:927
DATA #1 : String, 63 bytes
/home/db2inst1/sqllib/adm/db2rocme 1 PRIMARY db2inst1 900 START
DATA #2 : String, 5 bytes
BEGIN
	
2011-04-21-11.18.08.440950-240 I46272100E403         LEVEL: Event
PID     : 2560            TID  : 46912733618560 PROC : db2rocme 900 [db2inst1]
INSTANCE: db2inst1        NODE : 900
HOSTNAME: hostD
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1639
DATA #1 : String, 63 bytes
/home/db2inst1/sqllib/adm/db2rocme 1 PRIMÁRIO db2inst1 900 START
DATA #2 : String, 7 bytes
SUCCESS

Os serviços de cluster do DB2 tentam reinicializar os processos do CF com falha no hostB. Depois que o CF for reinicializado com sucesso, ele passa para o estado CATCHUP, seguido do estado PEER quando o failover estiver concluído.

Figura 2. Transição de estado do Cluster Caching Facility
Transição de estado do Cluster Caching Facility

O log do Recovery RM mostra:

Lista 38. Log do IBM.RecoveryRM
2011-04-21 11:17:53.885765 G(hostB) T(4124269472) _GBD Cleanup command for application res
ource "ca_db2inst1_0-rs" (handle 0x6028 0xffff 0x88a0f77a 0x4444ff43 0x12168f02 0x33bd39f8
) succeeded with exit code 0
2011-04-21 11:17:53.964794 R(hostB) T(4118584224) _RCD Resource::doRIBMAction Online Reque
st against ca_db2inst1_0-rs on node hostB.
2011-04-21 11:17:53.966743 G(hostB) T(4128926624) _GBD Bringing application resource onlin
e: Name=ca_db2inst1_0-rs Handle=0x6028 0xffff 0x88a0f77a 0x4444ff43 0x12168f02 0x33bd39f8
2011-04-21 11:18:08.947076 G(hostB) T(4124269472) _GBD Start command for app
lication resource "ca_db2inst1_0-rs" (handle 0x6028 0xffff 0x88a0f77a 0x4444ff43 0x12168f0
2 0x33bd39f8) succeeded with exit code 0

Os arquivos de log do db2diag mostram:

Lista 39. Arquivo db2diag.log
2011-04-21-11.17.54.442397-240 I45376528E522         LEVEL: Event
PID     : 4287                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:927
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-04-21-11.17.50.333529000
DATA #2 : String, 34 bytes
db2rocme 1 CF db2inst1 128 CLEANUP
DATA #3 : String, 5 bytes
BEGIN
	
2011-04-21-11.17.54.450788-240 I45379976E525         LEVEL: Event
PID     : 4287                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1639
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-04-21-11.17.54.442222000
DATA #2 : String, 34 bytes
db2rocme 1 CF db2inst1 128 CLEANUP
DATA #3 : String, 7 bytes
SUCCESS

2011-04-21-11.17.54.787350-240 I45392043E395         LEVEL: Event
PID     : 4358                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:927
DATA #1 : String, 58 bytes
/home/db2inst1/sqllib/adm/db2rocme 1 CF db2inst1 128 START
DATA #2 : String, 5 bytes
BEGIN
	
2011-04-21-11.18.09.512434-240 I46330550E398         LEVEL: Event
PID     : 4358                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1639
DATA #1 : String, 58 bytes
/home/db2inst1/sqllib/adm/db2rocme 1 CF db2inst1 128 START
DATA #2 : String, 7 bytes
SUCCESS

> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     CATCHUP   hostB    hostB        NO    -                0            hostB-ib0
129 CF     PRIMARY    hostD     hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PEER      hostB    hostB        NO    -                0            hostB-ib0
129 CF     PRIMARY    hostD     hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

Note que, em um cenário similar, se o CF secundário não estiver no estado PEER, a situação será mais complicada. Nesse caso, haverá uma interrupção no processamento transacional e a falha afetará clientes conectados ao banco de dados. Quando o segundo CF não estiver no estado PEER, ele não terá as informações mais atualizadas sobre o estado da instância de dados compartilhados. Portanto, se o CF primário falhar, a instância de dados compartilhados deverá realizar uma reinicialização de grupo. Os serviços de cluster do DB2 iniciarão a reinicialização de grupo automaticamente.


Conclusão

Há muitas fontes de informações importantes sobre o status de seu cluster DB2 pureScale. Os serviços de cluster do DB2 monitoram eventos e gravam logs que registram informações relevantes sobre situações bem-sucedidas e com falha. É possível usar os comandos db2cluster e db2instance , em conjunto com essas informações de log dos serviços de cluster do DB2, para entender o que ocorre dentro do cluster e diagnosticar e solucionar problemas.

Se você estiver trabalhando com o suporte técnico da IBM, também poderá usar o comando db2support para coletar dados de diagnóstico, rastreio e arquivos de log para os serviços de cluster do DB2 pureScale, juntamente com informações de log do DB2. Os arquivos de saída podem ser enviados para o suporte técnico da IBM para investigação e resolução de problemas adicionais.


Apêndice A: Privilégios de acesso necessários para ler rastreios dos gerenciadores de recursos

Para formatar e ler rastreios do gerenciador de recursos, por exemplo, aqueles em /var/ct/< domain_name >/log/mc/IBM.GblResRM/, use o seguinte comando:

rpttr -o dtic /var/ct/<domain_name>/log/mc/IBM.GblResRM/trace_summary*

Você deverá ter acesso de leitura/gravação no diretório /var/ct/< domain_name >/log/mc/IBM.GblResRM/ e acesso de leitura aos arquivos de log presentes no diretório.

Se o acesso de gravação não for permitido no diretório, então o acesso de leitura no diretório e nos arquivos de log pode ser suficiente. Nesse caso, é possível usar a seguinte abordagem para ler os logs:

Lista 40. Abordagem para ler os logs se o acesso de gravação não for permitido
mkdir ~/gblresrm_logs_copy
cp /var/ct/<domain_name>/log/mc/IBM.GblResRM/trace_summary* ~/gblresrm_logs_copy

rpttr -o dtic ~/gblresrm_logs_copy/trace_summary*
rpttr -o dtic ~/gblresrm_logs_copy/trace_summary* > formatted_gblresrm.log

Note que, por padrão, permissões de arquivos de log são definidas com acesso de leitura-gravação somente para o raiz. Portanto, um administrador deverá fornecer a um dado usuário os privilégios adicionais necessários nesses arquivos de log.


Informações de segundo plano

As seguintes informações opcionais são fornecidas somente como referência.

Tivoli SA MP e versões anteriores do gerenciador do banco de dados do DB2

O gerenciador do banco de dados do DB2 foi integrado com o Tivoli SA MP por algum tempo. As versões 9.5 e 9.7 do sistema de banco de dados do DB2 foram integradas com o Tivoli SA MP para fornecer a funcionalidade de particionamento do banco de dados, partição ESE única e alta disponibilidade e recuperação de desastre (HADR), mas não são padrão no uso do Tivoli SA MP ou na automação do gerenciamento de cluster. Há várias etapas manuais necessárias para a criação inicial do cluster e para a adição e a remoção de partições do DB2.

Consulte a seção Recursos para obter links para livros e outros recursos que fornecem informações adicionais sobre a integração do sistema de banco de dados do DB2 com o Tivoli SA MP antes da versão 9.8.


Agradecimentos

Além dos autores, as seguintes pessoas também contribuíram para esse tutorial:

  • Joyce Simmonds - DB2 Information Developer
  • Nikolaj Richers DB2 Information Developer

Recursos

Aprender

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Information Management, Tivoli
ArticleID=756021
ArticleTitle=Solucionando problemas no ambiente de serviços de cluster do DB2
publish-date=09062011