Aula 10 (1)

Prévia do material em texto

Livro Eletrônico
Aula 10
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com
Videoaulas - Pós-Edital
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
 
 
 
 
 
 1 
64 
 
Gerenciamento de concorrência e carga (WLM), otimização de planos de acesso, ajuste de 
performance (ferramentas e metodologia), ajuste de uso de memória. ............................ 2 
Gerenciamento de concorrência e carga (WLM) ............................................................................... 2 
Otimização de planos de acesso......................................................................................................... 7 
Ajuste de performance (ferramentas e metodologia) ..................................................................... 14 
Ajuste de uso de memória ................................................................................................................ 16 
Alta disponibilidade e recuperação de desastre (HADR), recuperação de dados, integração 
com Tivoli Storage Manager (TSM). ................................................................................ 19 
HADR ................................................................................................................................................. 19 
DB2 pureScale ................................................................................................................................... 32 
Recuperação de dados ...................................................................................................................... 41 
Integração com Tivoli Storage Manager .......................................................................................... 44 
Monitoração de eventos ................................................................................................ 48 
Tipos de Monitoramento .................................................................................................................. 50 
Monitoramento de rotina ................................................................................................................. 50 
Monitoramento de eventos em tempo real/on-line ........................................................................ 51 
Monitoramento de exceções ............................................................................................................ 52 
Questões comentadas ................................................................................................... 53 
Considerações finais ...................................................................................................... 64 
Referências ................................................................................................................... 64 
 
 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 2 
64 
GERENCIAMENTO DE CONCORRÊNCIA E CARGA (WLM), OTIMIZAÇÃO DE 
PLANOS DE ACESSO, AJUSTE DE PERFORMANCE (FERRAMENTAS E 
METODOLOGIA), AJUSTE DE USO DE MEMÓRIA. 
GERENCIAMENTO DE CONCORRÊNCIA E CARGA (WLM) 
A sigla WLM significa WORKLOAD MANAGEMENT. É uma abordagem adoptada para fornecer um 
gerenciamento de carga robusto. Para tal, devemos forcar primeiramente na criação de um 
ambiente de execução. Um ambiente de execução é simplesmente uma área onde as atividades de 
banco de dados podem ser executadas, como uma "sandbox" na qual as requisições podem ser 
executadas. 
Com o conceito de ambiente de execução definido, e depois do estabelecimento dos objetivos de 
negócio, as etapas restantes do gerenciamento de carga são: 
Identificação - Na fase de identificação, você se concentra na atribuição das atividades de 
banco de dados para um ambiente de execução, onde as atividades de banco de dados são 
mapeadas nas atividades que você construiu ao no contexto de cada objetivo de negócio. 
Gestão - Nesta etapa, o foco é sobre os controles táticos que rastreiam e modificam o fluxo 
de execução de atividades de banco de dados, a fim de atender aos objetivos de negócios. 
Monitoramento - Esta etapa dá acesso ao estado de atividades no ambiente de execução, 
bem como uma indicação sobre se as metas de negócios estão sendo atendidas. 
Há uma série de problemas de negócios comuns do DB2 que podem ser abordados através de uma 
implementação eficaz do gerenciamento de carga de trabalho. Estes problemas incluem: 
Proteger o sistema de consultas suspeitas – Atividades que utilizam uma grande 
quantidade de recursos (consultas complexas, por exemplo) podem ser um grande 
obstáculo ao desempenho da carga de trabalho do servidor de dados. Às vezes, as 
atividades são perfeitamente válidas, mas, na maioria das vezes, eles são consultas 
simplesmente mal escritas com muitas atividades caras ou custosas em execução ao 
mesmo tempo. 
Manter tempos de resposta consistentes para as atividades - É fundamental manter 
consultas transacionais curtas na execução de um ambiente de armazenamento a um 
ritmo consistente e previsível. Muitas vezes, essas atividades podem ser isoladas e pode 
facilmente ter tempos de resposta impactados por cargas de trabalho inesperadas. 
Proteger o servidor de dados por meio de um sistema de slowdown durante períodos de 
pico de atividade de banco de dados - Normalmente há períodos durante todos os dias 
(ou semanas, ou meses), onde um grande número de atividades de banco de dados pode 
ser executado ao mesmo tempo. Não surpreendentemente, isso muitas vezes resulta em 
contenção de recursos e lentidão no sistema. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 3 
64 
Fornecimento de controle de recurso explícito - A alocação e contenção de recursos pode 
ser um problema real na máquina do servidor de dados. Os clientes precisam de maneiras 
para alocar de forma justa os recursos em ambientes de execução e limitar o consumo de 
recursos em excesso. 
Objetivos de Service Level Agreement (SLA) - Acordos de Nível de Serviço, muitas vezes, 
introduzem metas de tempo de resposta explícito para as atividades de banco de dados. 
É possível controlar as cargas de trabalho e utilizar as informações do monitor para 
determinar como o servidor de dados é acompanhado no cumprimento desses objetivos. 
O monitoramento das atividades da base de dados pode se dar em diferentes granularidades, isto 
gera a capacidade de controlar todo o ciclo de vida da atividade, bem como a distribuição do 
agregado. 
Muitas vezes, uma visão global da atividade do servidor de dados é informação suficiente para 
determinar a saúde geral da distribuição de atividades. Às vezes a informação detalhada é necessário 
para determinação de problemas e análise histórica. 
Conceitos do DB2 Workload Manager 
No ambiente de negócios competitivo de hoje, a busca por aumentar a produtividade do negócio 
cria uma necessidade crescente para fazer mais com menos recursos, de forma rápida, e com o 
menor custo possível. Um cenário típico para um armazém de dados utilizando o DB2 teríamos 
múltiplos Jobs de Extract, Transform and Load (ETL), várias consultas, e relatórios com informações 
de diferentes fontes de dados de Business Intelligence (BI) em execução durante todo o dia, bem 
como trabalhos em lotes e serviços diários de utilitários de DBA que funcionam durante toda a noite. 
E olhe que não estamos levando em conta mudanças repentinas nas prioridades, devido às 
necessidades do negócio e, talvez, a necessidade de executar vários relatórios ao mesmo tempo, 
criando cargas de trabalho que trazem picos de operação sobre a base de dados. Às vezes, uma 
consulta complexa e pesada pode ser executada durante o horário de pico, causando lentidão no 
sistema comoum todo. Algumas empresas irão adquirir mais recursos de hardware para resolver o 
problema. Outras empresas vão encerrar as consultas com uso intensivo de recursos. Outros ainda 
podem escolher ajustar o desempenho do sistema para recuperar a capacidade plena de produção, 
ou criar uma abordagem mais rígida para enviar cargas de trabalho ao sistema de banco de dados 
DB2 de produção. 
O uso do Query Patroller e do DB2 Governor ajudam consideravelmente na gestão dessas cargas de 
trabalho no ambiente DB2. Para ampliar e expandir as capacidades de gestão do trabalho além dos 
oferecidos por essas ferramentas, um novo conjunto de recursos foi projetado e introduzido no 
motor do DB2 9.5 sob a forma do DB2 Workload Manager (WLM). 
O DB2 WLM é uma solução poderosa que aborda estas várias questões. Ele permite que o usuário 
para tratar diferentes cargas de trabalho (aplicações, usuários e assim por diante) de forma 
diferente, e proporcionar-lhes ambientes de execução diferentes ou caixas de areia (sandbox) para 
a execução das tarefas. A metodologia rápida, flexível e robusta oferecida pelo WLM pode ajudar a 
identificar, gerenciar e controlar suas cargas de trabalho para maximizar o rendimento do servidor 
de banco de dados e utilização de recursos. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 4 
64 
A arquitetura do DB2 WLM é composta principalmente dos seguintes componentes: classes de 
serviço, cargas de trabalho, limites (thersholds), conjuntos de ações de trabalho e conjuntos de 
classes de trabalho. 
A arquitetura do DB2 WLM gira em torno da definição de ambientes de execução para as atividades 
e atribuição de recursos para os ambientes de execução. A implementação DB2 começa com a CPU 
e a gestão de recursos de E/S para cargas de trabalho do DB2, incluindo perguntas como: é possível 
o compartilhamento de recursos ser feito de forma eficaz? Ou, a forma de compartilhamento de 
recursos é feita para garantir a estabilidade e para lidar com mudanças de prioridades e cargas 
flutuantes sobre a sistema? 
Arquitetura 
A arquitetura do DB2 Workload Manager integra todos os objetos gerenciados pelas cargas de 
trabalho em um conjunto coerente de tarefas, a fim de torná-los mais fáceis de identificar, gerenciar 
e monitorar o volume de trabalho no banco de dados DB2. A carga de trabalho sobre o sistema pode 
ser analisada para determinar como o sistema pode ser projetado para lidar com a carga de trabalho 
atual e futura. 
O monitoramento de desempenho utilizando o DB2 WLM pode acompanhar o comportamento do 
sistema, em um nível granular e/ou durante um longo período de tempo. A principal vantagem, 
porém, é a capacidade de compreender as características da carga de trabalho. Esse conhecimento 
permite gerir e manter os tempos de resposta e a vazão (throughput) desejados para o sistema. 
Além disso, alguns dos problemas mais complicados em um ambiente de banco de dados como 
consultas pesadas e agentes de contenção, podem ser tratadas mais eficazmente com as 
funcionalidades do WLM. 
O processo de utilização do DB2 WLM começa efetivamente com a análise da carga de trabalho 
através da identificação dos tipos e frequência de cargas de trabalho, e então partimos para a 
criação de classes de serviço, a fim de classificar a carga de trabalho em grupos gerenciáveis. O 
diagrama na figura abaixo ilustra as inter-relações dos principais componentes da arquitetura do 
DB2 WLM. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 5 
64 
 
Vamos agora, entender o passo-a-passo do fluxo de execução que tem início no usuário. Um usuário 
faz uma conexão ao banco de dados e lhe é atribuída uma carga de trabalho. Todas as atividades 
que funcionam no âmbito de uma carga de trabalho são mapeadas para uma classe de serviço. 
Na figura acima, os usuários atribuídos a carga de trabalho são mapeados para uma superclasse, 
SUPERCLASS1, por meio da palavra-chave UNDER SERVICE CLASS. A conexão pertence ao serviço da 
superclasse, mas todas as atividades de emissão da conexão são mapeadas automaticamente para 
q subclasse de serviço 1A. 
Os usuários atribuídos as cargas de trabalho B e C são mapeado para serem atendidos pela 
superclasse 2, SUPERCLASS2. Qualquer trabalho apresentado para as cargas de trabalho 
pertencentes a cargas de trabalho B e C podem ser mapeados para os serviços de subclasses 2A e 
2B. Todas as atividades que são mapeados para a superclasse 2 são executadas pelo conjunto de 
ações de trabalho 2 que é uma instanciação dos conjuntos de classes de trabalho X. Vejam que 
existe uma atividade de mapeamento, MAP ATIVITITY, que faz a interação entre as subclasses de 
trabalho com o conjunto de ações de trabalho. 
Uma ação de trabalho pode ser definida para cada banco de dados ou para uma superclasse de 
serviço. No diagrama, as ações de trabalho 1A e 1B pertencem ao conjunto de ações de trabalho 1, 
e são definidas para um banco de dados. As ações de trabalho 1A e 1 B pode ser qualquer uma das 
seguintes ações: 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 6 
64 
• A threshold1 - CREATE THERHOLD é um comando específico que aparece em alguns 
banco de dados, o DB2 permite a declaração que pode ser incorporado em um 
programa ou emitida através do uso de instruções SQL dinâmicas. 
• PREVENT EXECUTION – para impedir a execução, especifica que nenhuma das 
atividades de banco de dados associadas à classe trabalho para a qual esta ação de 
trabalho é definida terá permissão para executar (SQLSTATE 5U033). 
• COLLECT ACTIVITY DATA - especifica que os dados de cada atividade associada com 
a classe trabalho para o qual esta ação trabalho é definida são enviados para um dos 
monitores de eventos ativos quando a atividade for concluída. 
• COUNT ACTIVITY - especifica que todas as atividades de base de dados associadas 
com a classe de trabalho que serão executadas e que a cada execução, o contador 
para a classe de trabalho será incrementado. 
As ações de trabalho 2A e 2B pertencem ao conjunto de ações de trabalho 2, e eles são definidos 
para superclasse de serviço 2. As ações de trabalho 2A e 2B podem executar qualquer uma das 
seguintes ações: 
• Uma ação de mapeamento de uma atividade para qualquer subclasse de serviço 
pertencente a superclasse 2, com exceção da subclasse de serviço padrão. 
• PREVENT EXECUTION (veja acima) 
• COLLECT ACTIVITY DATA (veja acima) 
• COUNT ACTIVITY (veja acima) 
• COLLECT AGGREGATE ACTIVITY DATA – especifica que os dados agregados de 
atividade devem ser capturados para atividades que estão associada com a classe 
de trabalho e enviados para as estatísticas do monitor de eventos, se uma estiver 
ativo. 
Os usuários atribuídos a carga de trabalho D são mapeados para uma superclasse de serviço 3 que 
não tem uma subclasse de serviço definida pelo usuário. Neste caso, as conexões são mapeadas para 
a subclasse de por meio do atributo padrão SYSDEFAULTSUBCLASS da superclasse de serviço 3. 
Conexões que não são mapeadas para uma carga de trabalho definida pelo usuário são mapeados 
para a carga de trabalho padrão, conhecida como SYSDEFAULTUSERWORKLOAD, que, por sua vez, 
é mapeado para a superclasse de serviço padrão para solicitações de usuários, 
SYSDEFAULTUSERCLASS. 
As conexões internas de sistema do DB2 são mapeadas para a superclasse de serviço padrão nas 
conexões internas do DB2, por meio do SYSDEFAULTSYSTEMCLASS. As conexões de manutenção 
internas do DB2 são mapeadas para a superclasse de serviçopadrão para solicitações de 
manutenção, SYSDEFAULTMAINTENANCECLASS. 
 
1 Valor mínimo ou máximo (estabelecido para um atributo, característica ou parâmetro), que serve como referência para 
comparação ou orientação. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 7 
64 
Como ilustrado na figura vista anteriormente, os thresholds do DB2 WLM podem ser definidos em 
qualquer um ou todos os seguintes componentes: banco de dados, conjunto de ações de trabalho, 
superclasse de serviço, subclasse de serviço e carga de trabalho. 
O desempenho refere-se à maneira como um sistema de computador se comporta em resposta à 
uma carga de trabalho específica. O desempenho é medido em termos de tempo de resposta do 
sistema, taxa de transferência e utilização de recursos. O desempenho pode ainda ser afetado por: 
• A disponibilidade dos recursos no sistema. 
• Quão bem os recursos são utilizados e compartilhados 
Em geral, você vai ajustar seu sistema para melhorar a sua relação custo-
benefício. Alguns objetivos específicos incluem: 
• Cargas de trabalho com processamento maior ou uma demanda maior, sem aumento dos 
custos de processamento. 
• Obtenção de tempos de resposta do sistema mais rápidos, ou uma maior vazão, sem 
aumento dos custos de processamento. 
• Redução dos custos de processamento sem degradar o serviço para os usuários. 
O DB2 WLM contribui de diversas formas para o desempenho do seu sistema de banco de dados. 
Alguns benefícios do ajuste de desempenho, como a utilização mais eficiente dos recursos e a 
capacidade de adicionar mais usuários ao sistema, são tangíveis. Outros benefícios, como uma maior 
satisfação do usuário por causa de um tempo de resposta mais rápido são intangíveis. 
Falaremos um pouco sobre otimização e ajustes nos próximos tópicos desta aula. 
OTIMIZAÇÃO DE PLANOS DE ACESSO 
Os planos de acesso podem ser otimizados em uma tentativa de melhorar o desempenho da 
consulta. O grau de melhoria depende do tipo de otimização escolhida. Otimizar planos de acesso é 
uma das melhores maneiras de garantir que o compilador de consulta se comporte da maneira que 
você espera. 
Concentrador de instrução (Statement concentrator) 
O concentrador de instrução modifica dinamicamente instruções SQL no servidor de banco de dados 
de modo que instruções similares possam compartilhar o mesmo plano de acesso, melhorando, 
assim, o desempenho. 
No processamento de transações online (OLTP), comandos simples podem ser gerados 
repetidamente com diferentes valores literais. Em tais cargas de trabalho, o custo de recompilar as 
declarações pode gerar um aumento significativo do uso de memória. O concentrador de instrução 
evita o uso de memória, permitindo que as declarações compiladas sejam reutilizadas, 
independentemente dos valores literais passados como parâmetro. O uso de memória associado a 
novas instruções SQL ou comandos modificados para uma carga de trabalho OLTP é pequeno para o 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 8 
64 
concentrador de instrução, quando comparado com a economia obtida reutilizando comandos que 
estão no cache. 
O concentrador de instrução é por padrão desabilitado no DB2. Você pode habilitá-lo para todas as 
instruções dinâmicas em um banco de dados, definindo o parâmetro de configuração de banco de 
dados stmt_conc para LITERALS. 
Se uma instrução dinâmica é modificada, tanto a declaração original quanto a declaração modificada 
são exibidos na saída do comando EXPLAIN. O evento monitorar elementos lógicos e saída a partir 
da função de tabela MON_GET_ACTIVITY_DETAILS a mostra a declaração original se o concentrador 
de instrução modificou o texto da instrução original. Outras interfaces de monitoramento mostram 
apenas o texto da instrução modificada. 
Reutilização do plano de acesso 
Você pode solicitar que os planos de acesso que foram escolhidos para instruções SQL estáticas em 
um pacote permaneçam os mesmos, ou sejam bem semelhantes aos planos de acesso existentes 
quando tivermos necessidade de operações de ligação (bind ou rebind). A ideia aqui é que você possa 
reutilizar o plano de acesso mudando apenas as variáveis associadas caso as consultas possuam um 
alto grau de similaridade. 
A reutilização de plano pode impedir que alterações significativas ocorram sem sua aprovação 
explícita. Isso pode significar que embora suas consultas não se beneficiam de melhorias potenciais 
do plano de acesso, o controle sobre a reutilização do plano de acesso fornece a capacidade de testar 
e implementar melhorias. Até então, você pode continuar a usar planos de acesso existentes 
juntamente com o desempenho estável e previsível. A reutilização do plano de acesso é também 
referida como plano de bloqueio (lockdown plan). 
Para ativar a reutilização do plano de acesso use a instrução ALTER PACKAGE, ou a opção APREUSE 
dos comandos BIND, REBIND ou PRECOMPILE. Pacotes que estão sujeitos a reutilização do plano de 
acesso tem o valor de Y na coluna APREUSE da visão do catálogo SYSCAT.PACKAGES. 
O procedimento ALTER_ROUTINE_PACKAGE é uma forma conveniente de permitir o a reutilização 
dos planos acesso para objetos SQL compilados. No entanto, os planos de acesso não podem ser 
reutilizados durante revalidação do objeto compilado. Isso acontece, pois, o objeto é descartado 
antes de ser recompilado. Neste caso, o APREUSE só terá efeito na próxima vez que o pacote for 
carregado. 
A reutilização do plano de acesso é mais eficaz quando as mudanças no esquema e no ambiente de 
compilação são mínimas. Se forem feitas alterações significativas, não será possível recriar o plano 
de acesso anterior. Exemplos de mudanças significativas incluem a remoção de um índice que está 
sendo usado em um plano de acesso, ou recompilar uma instrução SQL em um nível de otimização 
diferente. 
Você pode combinar a reutilização do plano de acesso com diretrizes de otimização. Uma diretriz 
no nível de instrução tem precedência sobre a reutilização do plano de acesso para a instrução SQL 
estática. Isso significa que se você definir um critério de otimização na consulta que se contraponha 
ao definido no plano de acesso teremos que compilar essa consulta para se adequar a definição do 
comando. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 9 
64 
Os planos de acesso para instruções estáticas que não têm essas diretrizes de nível de instrução 
podem ser reutilizados se eles não entrarem em conflito com alguma das diretrizes de otimização 
especificada. Um comando de profile com uma política de otimização vazia pode ser usado para 
desativar o acesso a reutilização do plano sobre uma declaração específica, deixando a reutilização 
do plano disponível para as outras declarações estáticas no pacote. 
Classes de otimização 
Quando você compila uma instrução SQL ou XQuery, você pode especificar uma classe de 
otimização que determina como o otimizador de consulta escolhe o plano de acesso mais eficiente 
para o comando especificado. 
As classes de otimização diferem no número e tipo de estratégias de otimização que são 
consideradas durante a compilação de uma consulta. Embora você possa especificar técnicas de 
otimização individualmente para melhorar o desempenho do tempo de execução para uma 
determinada consulta, quanto mais técnicas de otimização você especificar, maior serão o tempo e 
os recursos do sistema necessários para a compilação da consulta. 
Destaforma, um conjunto de classes forma criadas para ajudá-lo na definição do conjunto de regras 
de otimização. Você pode especificar uma das seguintes classes de otimização quando você compila 
uma instrução SQL ou XQuery: 
0 - Esta classe direciona o otimizador a usar a otimização mínima ao gerar 
um plano de acesso, e tem as seguintes características: 
• As estatísticas de frequência do valor não são consideradas pelo otimizador. 
• Apenas as regras básicas de reescrita de consulta são aplicadas. 
• A enumeração de junção de Greedy2 é usada. 
• Apenas os métodos de acesso de loop aninhado e varredura de índice são 
habilitados. 
• A lista de prefetch não é usada na geração de métodos de acesso. 
• A estratégia da star-join não é considerada. 
Esta classe só deve ser usada em circunstâncias nas quais a menor sobrecarga de compilação de 
consulta possível é um requisito. A classe de otimização de consulta 0 é adequada para uma 
aplicação que consiste inteiramente de comandos SQL ou XQuery simples que acessam tabelas bem-
indexados. 
1 - Esta classe de otimização tem as seguintes Características: 
• As estatísticas de frequência do valor não são consideradas pelo otimizador. 
• Apenas um subconjunto de regras de reescrita de consulta são aplicadas. 
• A enumeração de junção de Greedy é usada. 
 
2 O algoritmo guloso de junção seleciona apenas um método de junção em uma direção, o que significa que o método join 
selecionada não será alterada durante a otimização. É um método heurístico, que não garante a escolha do melhor plano. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 10 
64 
• A lista de prefetch não é usada na geração de métodos de acesso. 
A classe de otimização 1 é semelhante à classe 0, exceto que as funções de merge scan join e table 
scans também estão disponíveis. 
2 - Esta classe direciona o otimizador a usar um grau de otimização que 
é significativamente maior do que o da classe 1, mantendo os custos de 
compilação para consultas complexas significativamente menor do que 
o da classe 3 ou superior. Esta classe de otimização tem as seguintes 
características: 
• Todas as estatísticas disponíveis, incluindo frequência de valores e as estatísticas de quantis, 
são usados. 
• Todas as regras de reescrita de consulta são aplicados, com exceção de regras 
computacionalmente intensivas 
• A enumeração de junção de Greedy é usada. 
• Uma ampla gama de métodos de acesso é considerada, incluindo a lista de prefetch e 
roteamento para MQT. A estratégia de junção estrela é considerada, se for o caso. 
A classe 2 é recomendada para consultas muito complexas de apoio à decisão ou OLAP. Nesses 
ambientes, uma consulta específica não é repetida exatamente da mesma maneira, de modo que é 
improvável para um plano de acesso que ele permaneça no cache até a próxima ocorrência da 
consulta. 
3 - Esta classe representa uma quantidade moderada de otimização, e 
chega próximo das características de otimização de consulta do DB2. 
Esta classe optimização tem as seguintes características: 
• Estatísticas de valor frequentes são usadas, se disponível. 
• A maioria das regras de reescrita de consulta são aplicadas, incluindo transformações de 
subconsultas em junções. 
• A programação dinâmica join enumeração é usada, com: 
o Uso limitado de composição internas entre tabelas. 
o Uso limitado de produtos cartesianos para esquemas estrela que envolvem tabelas de 
lookup. 
• Uma ampla gama de métodos de acesso é considerada, incluindo a lista de prefetch, o índice 
de AND, e junção estrela. 
Esta classe é adequada para uma ampla gama de aplicações e melhora planos de acesso para 
consultas com quatro ou mais operações de junção. 
5 - Esta classe dirige o otimizador para usar uma quantidade 
significativa de otimização para gerar um plano de acesso, e tem as 
seguintes características: 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 11 
64 
• Todas as estatísticas disponíveis, incluindo frequência dos valores e as estatísticas dos 
quantis, são usadas. 
• Todas as regras de reescrita de consulta (incluindo roteamento MQT) são aplicados, com 
exceção regras computacionalmente intensivas que são aplicáveis somente em casos 
muito raros. 
• A programação dinâmica na enumeração dos join é usada, com: 
o Uso limitado de composições entre tabelas internas (inner tables) 
o Uso limitado de produtos cartesianos para esquemas estrela que envolvem tabelas de 
lookup. 
• Uma ampla gama de métodos de acesso é considerada, incluindo a lista de prefetch, o índice 
de AND, e o roteamento MQT. 
A classe de otimização 5 (o padrão) é uma excelente escolha para um ambiente misto com tanto 
processamento de transações e consultas complexas. Esta classe de optimização foi concebida para 
aplicar a mais valiosas transformações de consulta e outras técnicas de optimização de uma maneira 
eficiente. 
Se o otimizador de detectar que recursos adicionais e tempo de processamento de instruções 
dinâmicas complexas de SQL ou XQuery não são garantidos, a otimização é reduzida. A extensão da 
redução depende do tamanho da máquina e o número de predicados da consulta. Quando o 
otimizador reduz o percentual de otimização de consultas, continua a aplicar todas as regras de 
reescrita de consulta que normalmente seriam aplicadas. No entanto, ele usa enumeração greevy 
join e reduz o número de combinações do plano de acesso que são consideradas. 
7 - Esta classe direciona o otimizador a usar uma quantidade 
significativa de tempo/esforço de otimização para gerar um plano de 
acesso. É semelhante a classe de otimização 5, exceto que, neste caso, 
o otimizador não considera reduzir o percentual de otimização de 
consulta para instruções dinâmicas complexas de SQL ou XQuery. 
 
9 - Esta classe direciona o otimizador a usar todas as técnicas de 
otimização disponíveis. Esses incluem: 
• Todas as estatísticas disponíveis. 
• Todas as regras de reescrita de consulta. 
• Todas as possibilidades para de enumeração de junção, incluindo produtos cartesianos e 
composições ilimitadas de inner joins. 
• Todos os métodos de acesso 
Esta classe aumenta o número de possíveis planos de acesso que são considerados pelo otimizador. 
Você pode usar esta classe para determinar se a otimização mais abrangente geraria um plano de 
acesso melhor para consultas muito complexas ou muito longa duração que usam tabelas grandes. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 12 
64 
Use explicar e medições de desempenho para verificar se um plano melhor, na verdade, foi 
encontrado. 
Perfis de otimização e diretrizes 
Um perfil de otimização é um documento XML que pode conter diretrizes de otimização para uma 
ou mais instruções SQL. A correspondência entre cada instrução SQL e suas diretrizes de otimização 
associadas é estabelecida utilizando o texto SQL e outras informações que são necessárias para 
identificar inequivocamente uma instrução SQL. 
O otimizador do DB2 é um dos otimizadores mais sofisticados baseado em custo disponíveis no 
mercado. No entanto, em casos raros, o otimizador pode selecionar um plano de execução não ideal. 
Um DBA familiarizado com o banco de dados pode usar utilitários como db2advis, runstats e 
db2expln, bem como a definição de classe de otimização para ajudá-lo ajustar o otimizador para um 
melhor desempenho do banco de dados. Se o DBA não receber os resultados esperados depoisque 
todas as opções de ajuste forem esgotadas, ele pode fornecer diretrizes de otimização explícitas ao 
otimizador do DB2. 
Por exemplo, suponha que, mesmo depois de ter atualizado as estatísticas de banco de dados e 
executado todos os outros passos do ajuste, o otimizador ainda não escolheu o índice I_SUPPKEY 
para acessar a tabela SUPPLIERS na seguinte consulta: 
 
Neste caso, uma diretriz de otimização explícita pode ser usada para influenciar o otimizador. Por 
exemplo: 
 
As diretrizes de otimização são especificadas usando uma descrição em XML simples. Cada elemento 
dentro do elemento OPTGUIDELINES é interpretado como uma diretriz de otimização pelo 
otimizador DB2. Existe um elemento de orientação optimização no exemplo anterior. O elemento 
IXSCAN solicita que o otimizador utilize índice para acesso aos dados. O atributo TABLE do elemento 
IXSCAN indica a referência para tabela (usando o nome exposto na referência de tabela) e o atributo 
INDEX especifica o índice. 
O exemplo a seguir é baseado na consulta anterior, e mostra como uma diretriz de otimização pode 
ser passada para o otimizador do DB2 usando um perfil de otimização. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 13 
64 
 
Cada elemento do STMTPROFILE fornece um conjunto de diretrizes de otimização para um comando 
de aplicação. A declaração alvo é identificada pelo subelemento STMTKEY. Ao perfil de otimização 
é então dado um nome qualificado pelo SCHEMA e inserido no banco de dados. O perfil de 
otimização é posto em prática pela declaração desse nome no comando BIND ou PRECOMPILE. 
Os perfis de otimização permitem diretrizes de otimização que serão fornecidas para o otimizador 
de consultas sem alterações nos aplicativos ou na configuração de banco de dados. Você 
simplesmente compõe um documento XML simples, insere no banco de dados e especifica o nome 
do perfil de otimização no comando BIND ou PRECOMPILE. O otimizador combina automaticamente 
diretrizes de otimização para a instrução apropriada. 
As diretrizes de otimização não precisam ser abrangentes, mas devem ser direcionadas para um 
plano de execução desejado. O otimizador do DB2 considera ainda outros planos de acesso possíveis 
que utilizam os métodos baseados nos custos existentes. As diretrizes de otimização especificam as 
referências que não podem substituir as configurações gerais de otimização. Por exemplo, uma 
diretriz de otimização especificando a mesclagem entre as tabelas A e B não é válido na classe de 
otimização 0. 
O otimizador ignora diretrizes de otimização inválidas ou inaplicáveis. Se quaisquer diretrizes de 
otimização forem ignoradas, um plano de execução é criado e um SQL0437W (desempenho desta 
consulta complexa pode ser abaixo do ideal) com o código de razão 13 é retornado. Em seguida, 
você pode usar a instrução EXPLAIN para obter informações de diagnóstico detalhadas sobre 
processamento de diretrizes de otimização. 
 
 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 14 
64 
Impacto da partição de banco de dados na otimização de consultas 
Em ambientes de banco de dados particionado, o otimizador reconhece e usa a localização das 
tabelas quando estabelece o melhor plano de acesso para uma consulta. 
Se as tabelas são frequentemente envolvidas em consultas de junção, devem ser divididos entre as 
partições de banco de dados de tal forma que as linhas de cada tabela usadas na junção se 
encontram na mesma partição do banco de dados. Durante a operação de junção, a colocação de 
dados de ambas as tabelas associadas impede o movimento de dados a partir de uma partição de 
banco de dados para a outra. Colocar as duas tabelas no mesmo grupo de partição de banco de 
dados pode garantir que os dados sejam retornados mais rapidamente. 
Dependendo do tamanho da tabela, quando espalhamos os dados da tabela sobre mais partições 
de banco de dados reduzimos o tempo estimado para executar uma consulta. O número de tabelas, 
a dimensão das tabelas, a localização dos dados nestas tabelas, e do tipo de consulta (por exemplo, 
se uma junção for necessária) todos afetam o custo da consulta. 
Vamos agora analisar algumas ferramentas e metodologias utilizadas no ajuste de performance. 
AJUSTE DE PERFORMANCE (FERRAMENTAS E METODOLOGIA) 
Quando falamos de ajustes de performance podemos pensar sobre o ponto de vista do 
monitoramento operacional de performance do sistema. 
A monitoramento operacional refere-se a coleta de métricas-chaves de desempenho do sistema em 
intervalos periódicos ao longo do tempo. Esta informação fornece dados críticos para refinar a 
configuração inicial ajustando às suas necessidades, e também prepara o ambiente para tratar de 
novos problemas que podem aparecer em atualizações de software, no aumento dos dados ou 
volumes de usuários, ou ainda na implantação de novos aplicativos. 
O utilitário governor, db2gov, monitora o comportamento de aplicativos que são executados contra 
uma base de dados e pode mudar esse comportamento, dependendo das regras especificadas no 
seu arquivo de configuração. Veja abaixo a sintaxe do comando: 
 
Monitoramento operacional da performance do Sistema 
Uma estratégia de monitoramento operacional deve abordar vários aspectos. Por exemplo, ela 
precisa ser o mais leve possível, ou seja, não deve consumir grande parte do processamento do 
sistema que está medindo. Ela deve ainda ser abrangente, mantendo uma capacidade de observação 
ampla que vá além dos potenciais problemas que podem aparecer em qualquer lugar no sistema. 
O fato de você planejar a coleta regular de métricas operacionais durante toda a vida útil do sistema 
gera uma necessidade de termos uma maneira de gerenciar todos os dados. Para muitos dos 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 15 
64 
possíveis usos que você venha a ter para os dados, tais como calcular a tendências de desempenho 
a longo prazo, você quer ser capaz de fazer comparações entre coleções arbitrárias de dados que 
estão distribuídas por vários meses. O DB2 facilita esse tipo de gerenciamento de dados muito bem!! 
A análise e comparação de dados de monitoramento se torna muito simples, e você já tem uma 
infraestrutura robusta para armazenamento e organização dos dados a longo prazo. 
Um sistema de banco de dados DB2 fornece algumas excelentes ferramentas de monitoramento de 
dados. Os principais são monitores de snapshot e o gerenciamento de carga (WLM) com funções 
de tabela para agregação de dados. Ambos se concentram na sumarização dados, onde ferramentas 
como contadores, temporizadores e histogramas contabilizam os dados sobre as atividades no 
sistema de banco de dados. Por amostragem das informações obtidas por estes elementos de 
monitoramento ao longo do tempo, você pode derivar a atividade média durante um intervalo. 
Não há nenhuma razão para limitar suas métricas a apenas as que o produto DB2 fornece. A 
informação contextual é fundamental para a determinação de problemas de desempenho. Os 
usuários, o aplicativo, o sistema operacional, o subsistema de armazenamento e a rede - todos estes 
podem fornecer informações valiosas sobre o desempenho do sistema. Incluindo métricas externas 
ao sistema de banco de dados DB2 podem ser importantes para produzir uma imagem global 
completa do desempenho do sistema. 
A tendência nos últimos lançamentos do banco de dados DB2 tem sido a de fazer mais e mais dados 
de monitoramento disponibilizados através de interfaces SQL.Isso torna o gerenciamento de dados 
de monitoramento muito simples, porque você pode facilmente redirecionar os dados das visões de 
administração, por exemplo, de volta para tabelas do DB2. Os dados do monitor de eventos de 
atividade também podem ser gravados em tabelas do DB2, proporcionando benefícios semelhantes. 
Com a grande maioria dos nossos dados de monitoramento tão fácil de armazenar em DB2, um 
pequeno investimento para que as métricas do sistema sejam também armazenadas no DB2, tais 
como a utilização da CPU por meio do comando vmstat, é administrável. 
Tipos de dados coletados pelo monitoramento operacional 
Vários tipos de dados são úteis para serem coletados pelo monitoramento operacional contínuo. 
Um conjunto básico de métricas de monitoramento de desempenho do sistema DB2: 
Informações de configuração DB2 
Conhecer as cópias regulares do banco de dados e a configuração do gerenciador de banco de 
dados, as variáveis de registro DB2, e a definição do esquema ajuda a fornecer um histórico de todas 
as alterações que foram feitas, e pode ajudar a explicar as mudanças que surgem em dados de 
monitoramento. 
Carga total do sistema 
Se é permitido que a utilização da CPU ou E/S se aproximar da saturação, isto pode criar um gargalo 
no sistema que pode ser difícil de detectar usando apenas instantâneos (snapshot) de DB2. A melhor 
prática, então, é monitorar regularmente carga do sistema com vmstat e iostat (e possivelmente 
netstat para problemas de rede) em Linux e UNIX, e perfmon no Windows. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 16 
64 
Você também pode usar as visões administrativas, tais como ENV_GET_SYSTEM_RESOURCES, para 
recuperar informações do sistema operacional, CPU, memória e outras informações relacionadas ao 
sistema. Normalmente você deve olhar para as mudanças nos valores considerados normais para o 
seu sistema. 
Taxa de transferência e tempo de resposta medido no nível de negócios 
Uma visão do desempenho da aplicação, medida pelo DB2, no nível de lógica de negócios, tem a 
vantagem de ser mais relevante para o usuário final, além de que normalmente inclui tudo o que 
poderia criar um gargalo, tais como a lógica de apresentação, servidores de aplicações, servidores 
web, várias camadas da rede, e assim por diante. Estes dados podem ser vitais para o processo de 
criação ou verificação de um acordo de nível de serviço (SLA). 
Os elementos de monitoramento de desempenho do sistema DB2 e os dados de carga do sistema 
são compactos o suficiente para que mesmo que sejam coletadas a cada cinco a quinze minutos, o 
volume total de dados ao longo do tempo é irrelevante na maioria dos sistemas. Da mesma forma, 
a sobrecarga da coleta de dados é tipicamente na faixa de 1-3% do consumo de CPU adicional 
Vejam que podemos considerar pequeno o preço a pagar por uma série histórica contínua de 
importantes métricas do sistema. As informações de configuração mudam raramente, de modo a 
coleta destes dados uma vez por dia é suficiente para ser útil, sem criar uma quantidade excessiva 
de dados. 
Há centenas de métricas para escolher, mas coletar todas elas podem ser contra produtivo, devido 
ao grande volume de dados produzidos. Você deve procurar por métricas que sejam: 
Fácil de coletar - Você não quer usar ferramentas complexas ou dispendiosas para o 
monitoramento quotidiano, e você, também, não quer que o ato de monitorar a carga 
seja significativo na performance do sistema. 
Fácil de entender - Você não quer procurar o significado da métrica cada vez que você 
for visualizá-la. 
Tenha relevância para o seu sistema - Nem todas as métricas fornecem informações 
significativas em todos os ambientes. 
Sensível, mas não muito sensível ☺ - Uma mudança na métrica deve indicar uma 
mudança real no sistema. A métrica não deve flutuar por conta própria. 
AJUSTE DE USO DE MEMÓRIA 
Ter memória suficiente e corretamente configurada é fundamental para o bom desempenho do 
sistema. Sem a quantidade de memória adequada, o acesso aos dados que poderiam ser 
“bufferizdos” se transformam acesso ao disco por meio de operações de E/S, criando muitas vezes 
um gargalo de disco no processo. 
Temos ainda quantidades menores, mas importantes de memória que são usadas para armazenar 
os metadados e os resultados calculados, tais como planos de acesso SQL e os bloqueios de itens de 
dados. Sem memória suficiente para estes, o sistema deve descartar ou coletar essas informações 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 17 
64 
importantes e ainda recalcular ou de algum modo compensar com processamento adicional, 
aumentando a sobrecarga na CPU. Assim, um gargalo de memória pode realmente ser disfarçado 
como um problema de disco ou CPU. 
A tabela a seguir resume os gargalos de disco e CPU que têm memória como um potencial causa 
subjacente. 
 
A maioria dos gargalos de memória se manifestam com os sintomas de um gargalo de CPU ou de 
disco. As questões de memória dever se considerados na investigação de tais problemas. Uma 
análise mais aprofundada dos dados do comando vmstat indica a partir da atividade de paginação 
(com ou sem o uso elevado da CPU do sistema), se há pressão de memória excessiva no sistema. 
A arquitetura multithreaded do DB2 que foi introduzida no DB2 9.5 em todas as plataformas 
simplifica a configuração e otimização do uso de memória em servidores DB2. O limite global para o 
uso de memória é definido por um único parâmetro de configuração do gerenciador de banco de 
dados chamado INSTANCE_MEMORY. Em ambientes particionados, o INSTANCE_MEMORY 
especifica a quantidade máxima de memória que pode ser alocada para uma partição de banco de 
dados. 
O INSTANCE_MEMORY é definido como AUTOMATIC por padrão. Isto permite que a memória cresça 
conforme a necessidade - até um limite entre 75% e 95% da memória RAM física do servidor. Em 
ambientes em que outros aplicativos compartilham o mesmo servidor com o sistema DB2, 
estabelecer um valor específico para a variável INSTANCE_MEMORY é recomendado. 
A maneira mais fácil de monitorar o uso geral da memória do servidor DB2 (ou das partições em 
ambientes particionados) é usando o comando db2pd –dbptnmem (alternativamente, você pode 
consultar a função de tabela ADMIN_GET_MEM_USAGE). A saída do comando db2pd -dbptnmem 
lista o uso de memória atual, bem como o pico (high-water mark - HWM) da variável 
INSTANCE_MEMORY, bem como dos diferentes conjuntos de memória no DB2. Os conjuntos de 
memória mais importantes em um ambiente de servidor DB2 são: 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 18 
64 
1. Conjunto de memória do gerenciador de BD: A memória usada pela própria instância 
do DB2 (por exemplo, para o monitoramento ou auditoria do próprio DB2). 
2. Conjunto de memória de banco de dados: Este conjunto de memória é geralmente o 
maior em um servidor DB2. Ele contém todos os consumidores de memória de banco de 
dados compartilhados, como os pools de buffer, a pilha classificação, a lista de bloqueio 
e o cache do pacote. Este conjunto de memória é controlado pelo parâmetro 
DATABASE_MEMORY de configuração de banco de dados (o valor padrão é AUTOMATIC). 
3. Conjunto e memória de aplicação: Trata-se da memória usada para um processamento 
específico do aplicativo. Este conjunto é configurado com o parâmetro de configuração 
APPL_MEMORY do banco de dados (inicializado por padrão como AUTOMATIC). 
Além desses conjuntos de memória, um servidorDB2 tem dois conjuntos de memória adicionais, 
PRIVATE (de uso geral), FMP (para processamento de modo vedado), e FCM (Fast Communication 
Manager para ambientes de cluster). Além comando db2pd -dbptnmem, você pode usar a função 
de tabela MON_GET_MEMORY_SET para ver o tamanho dos diferentes conjuntos de memória. 
Para todos os grandes consumidores de memória do banco de dados definidos você pode habilitar 
o gerenciador de memória para auto ajuste (self-tuning memory manager - STMM). O STMM 
sintoniza os diferentes pools de memória como lista de bloqueio ou cache de pacotes que fazem 
parte do DATABSE_MEMORY. Uma maneira fácil de determinar o consumo de memória real dos 
diferentes pools de memória está na função de tabela MON_GET_MEMORY_POOL 
(alternativamente, você pode usar o comando db2pd -mempools). 
Os gargalos de memória ainda podem ocorrer nas seguintes condições: 
1. Se o valor do INSTANCE_MEMORY foi explicitamente definido para um valor numérico 
(não automático) e o STMM está habilitado, o STMM vai levar o consumo de memória até 
o valor de INSTANCE_MEMORY se a carga de trabalho no banco de dados for alta. Se o 
seu sistema de banco de dados DB2 compartilha o mesmo host com outro consumidor de 
memória grande como o WebSphere ou uma instância central de SAP, certifique-se de 
definir um valor para o INSTANCE_MEMORY que deixa memória suficiente tanto para DB2 
e da aplicação. 
2. Um valor explícito de INSTANCE_MEMORY muito elevado para o sistema pode não ser 
um problema até bancos de dados adicionais serem colocados online, levando a dotação 
total de memória do DB2 para um patamar maior do que o sistema pode acomodar, mas 
ainda dentro do valor estabelecido para INSTANCE_MEMORY. Isso acontece porque o 
STMM é projetado para lidar com a pressão de memória, libertando memória de volta 
para o sistema operacional, se necessário, este cenário seria mais provável de ocorrer 
quando o STMM não está habilitado, ou quando a plataforma envolvida não suporta a 
libertação de memória de volta ao SO, ou quando as exigências de memória do banco de 
dados são extremamente dinâmicas (por exemplo, a criação rápida de conexões de banco 
de dados). 
3. Se um grande número de conexões de base de dados é necessário, isto pode resultar 
no consumo de grande parte da memória da instância pelos agentes. Se este montante 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 19 
64 
for excessivo - deixando pouca memória para banco de dados fazer suas alocações de 
memória globais com ou sem o STMM. Isso pode ser reduzido com o uso do concentrador 
de conexão. 
ALTA DISPONIBILIDADE E RECUPERAÇÃO DE DESASTRE (HADR), 
RECUPERAÇÃO DE DADOS, INTEGRAÇÃO COM TIVOLI STORAGE MANAGER 
(TSM). 
Não importa a um usuário o motivo pelo qual sua solicitação ao banco de dados falhou. Se uma 
operação sofreu timeout por causa do mau desempenho, ou se um componente da solução falhou, 
ou ainda se um DBA tornou o banco de dados off-line para realizar manutenção, o resultado é 
sempre o mesmo para o usuário: O banco de dados não está disponível para processar seus pedidos. 
Existem diversas estratégias para melhorar a disponibilidade da sua solução de banco de dados que 
incluem: 
Redundância - Ter cópias secundárias de cada componente de sua solução pode levar ao 
processamento de uma carga de trabalho (worklaod) em caso de falha. 
Monitoramento do sistema - Recolher dados estatísticos sobre os componentes de sua 
solução para facilitar o balanceamento de carga ou detecção de quais componentes falharam. 
Balanceamento de carga – Consiste em Transferir parte da carga de trabalho de um 
componente do seu sobrecarregado para um outro componente de sua solução que tem uma 
carga de trabalho baixa. 
Failover – Transferir toda a carga de trabalho de um componente com falha para um 
componente secundário. 
Maximização de desempenho - Reduzindo a chance de que as transações levam muito tempo 
para concluir ou sofrer timeout. 
Minimizar o impacto da manutenção - Agendamento de atividades de 
manutenção automática e manual de manutenção atividades de forma a 
impactar os aplicativos de usuário tão pouco quanto possível. 
Nas próximas seções vamos tratar de duas funcionalidades fornecidas pelo DB2 para manter a alta 
disponibilidade: HADR e pureScale. 
HADR 
A funcionalidade HADR é adequada para manter um ambiente de alta disponibilidade, seja por uma 
falha total ou parcial no site. HADR protege seu banco de dados contra a perda de dados por meio 
da replicação das mudanças feitas na sua fonte de dados, conhecido como banco de dados primário, 
e em um ou vários bancos de destinos, conhecidos como banco de dados de standby ou espera. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 20 
64 
Em outras palavras, High Availability Disaster Recovery (HADR) usa os registros de log do banco de 
dados para replicar os dados do banco primário para um banco de standby. Algumas atividades 
podem levar o banco de dados de standby a reproduzir o banco de dados primário, como a 
transmissão dos registos de log. Algumas atividades geram tantas informações de log que a grande 
quantidade de arquivos de log pode causar problemas de armazenamento. 
Embora a replicação de dados para o banco de dados standby usando logs seja o núcleo das 
estratégias de alta disponibilidade, o log em si pode, potencialmente, ter um impacto negativo sobre 
a disponibilidade da sua solução. Projete sua estratégia de manutenção de forma inteligente, 
configure o sistema para minimizar o impacto negativo da utilização dos logs, e permitir que o uso 
dos logs possa para proteger seus dados transacionais. 
Uma falha parcial no site pode ser causada por uma falha hardware, rede ou software (sistema de 
banco de dados ou sistema operacional). Sem HADR, uma falha parcial no site requer a 
reinicialização do servidor do sistema de gerenciamento de banco de dados. A duração de tempo 
que leva para reiniciar o banco de dados e o servidor é imprevisível. É possível que demore vários 
minutos antes do banco de dados ser trazido de volta para um estado consistente e disponível. Com 
HADR, um banco de dados de espera pode assumir em segundos. Além disso, você pode redirecionar 
os clientes que usam o banco de dados primário original para o novo banco de dados principal 
usando reencaminhamento (reroute) automático de cliente ou repetição lógica (retry logic) no 
aplicativo. 
Uma falha completa no site pode ocorrer quando um desastre, como um incêndio, faz com que o 
site inteiro seja destruído. No entanto, como o HADR usa TCP/IP para a comunicação entre os bancos 
de dados primário e de espera, esses bancos de dados podem estar em locais diferentes. Por 
exemplo, o banco de dados principal pode estar na sede da empresa em uma cidade, e um banco de 
dados de espera pode estar em seu escritório de vendas em outra cidade. 
Se ocorrer um desastre no site primário, a disponibilidade dos dados é mantida por ter o banco de 
dados de standby remoto para assumir como principal com todas as funcionalidades do DB2. Depois 
de ocorrer uma operação de recuperação, você pode trazer o banco de dados principal original de 
volta e devolvê-lo à sua função de banco de dados principal, este conceito é conhecido como 
failback. 
Você pode iniciar uma operação de failback se você quiser fazer o antigo banco de dados primário 
consistente com o novo banco de dados principal. Depois de reintegrar o antigo banco de dados 
primário na configuração do HADR como um banco de dados de espera, você pode alternar os papéis 
dos bancos de dados para permitir que o banco de dados primário original se torne mais uma vez o 
banco dedados primário. 
As funcionalidades de um DB2 HADR incluem: 
o Capacidade recuperação rápida (fast failover) 
o Impacto insignificante no desempenho 
o Fácil de configurar e monitorar 
o Upgrades contínuos sem tempo de inatividade para aplicações em execução 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 21 
64 
o Failover e failback transparentes para aplicações 
o Fácil integração com software de clustering alta disponibilidade 
o Recuperação melhorada de desastres em comparação com métodos convencionais 
Todas as mudanças que ocorrem no servidor de banco de dados principal são escritas em registros 
de log. Estes registros de log são então enviados para o servidor de banco de dados secundário, onde 
as alterações são reproduzidas na cópia local do banco de dados. Este procedimento garante que os 
servidores de banco de dados primário e secundário estão em um estado sincronizado. Deste ponto 
em diante, o servidor de espera está em um modo de avanço contínuo e está sempre em um estado 
de quase prontidão (near-readiness), assim assumir o controle é bastante rápido. 
No DB2 10.1, também é possível utilizar a capacidade do banco de dados de espera para executar 
operações somente leitura no banco de dados em sua solução HADR. Operações de leitura que estão 
sendo executados no banco de espera não afetam o principal papel do servidor de espera que seria 
a replicação de logs que são enviados a partir do banco de dados primário. 
Usando duas portas dedicadas de comunicação TCP/IP e um monitor de pulsação (heartbeat), o 
primário e os bancos de dados standby rastreiam onde estão processando no momento, o estado 
atual da replicação, e se o banco de dados standby está atualizado com o banco de dados primário 
(conhecido como estado HADR Peer). Quando um registro de log está sendo escrito no disco 
primário, ele é enviado para o HADR para ser encaminhado ao banco de espera ao mesmo tempo. 
Essa descrição de eventos apresentadas até aqui, presentes na solução de HADR podem ser 
observadas na figura abaixo. 
 
Na alta disponibilidade para recuperação de desastres (HADR), as seguintes operações são 
replicadas do primário para o banco de dados de espera (standby): 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 22 
64 
o Linguagem de definição de dados (DDL) 
o Linguagem de manipulação de dados (DML) 
o Operações de buffer pool 
o Operações em tablespaces 
o Reorganização on-line 
o Reorganização off-line 
o Metadados para procedimentos armazenados e funções definidas pelo usuário 
(UDF) (mas não o objeto ou biblioteca de arquivos relacionados) 
O HADR não replica procedimentos armazenados e, objetos e bibliotecas de arquivos UDF. Você 
deve criar os arquivos em caminhos idênticos em ambos os bancos de dados primário e de espera. 
Se o banco de dados de standby não conseguir encontrar o objeto ou biblioteca referenciado, o 
procedimento armazenado ou UDF chamado irá falhar no banco de dados de espera. 
Topologia HADR 
Com HADR, você define o nível de proteção contra perda potencial de dados nas escolhas de 
configuração e de topologia. Algumas das escolhas importantes que você deve fazer são os 
seguintes: 
Nível de sincronização: bancos de dados de standby são sincronizados com o banco de dados 
primário por meio dos dados de log que são gerados no banco primário e enviados para os bancos 
de standby. Estes vão, constantemente, passar (roll forward) pelos arquivos de log. Você pode 
escolher entre quatro modos de sincronização diferentes. Na ordem da maior para a menor 
proteção, estes modos são: síncrono (SYNC), quase-síncrono (NEARSYNC), assíncrono (ASYNC), e 
super-assíncrono (SUPERASYNC). 
Janela de pares (peer window): o recurso de janela de pares especifica que os bancos de dados 
primário e de espera estão a comportar-se como se eles ainda estivessem em estado de peer por 
um período de tempo configurado se o banco primário perder a conexão HADR no estado de peer. 
Se o banco de dados primário falhar no estado de peer ou no estado "desconectado dos pares", o 
failover de espera tem perda de dados zero. Este recurso fornece uma maior proteção. (Falaremos 
sobre os estados do HADR logo em seguida) 
Número de banco de standby: Quando você está trabalhando com HADR você pode optar pelo modo 
de standby único ou múltiplo. Com múltiplos bancos de standby você pode garantir os objetivos alta 
disponibilidade e recuperação de desastres com uma única tecnologia. Existem algumas formas de 
uso para banco de dados de espera em uma solução de HADR que estão associadas com diferentes 
propósitos: 
Leitura no banco de standby: É possível usar os bancos de dados de espera para fornecer 
funcionalidades de leitura sem afetar as responsabilidades de alta disponibilidade e 
recuperação de desastres. Essa funcionalidade pode reduzir a carga de trabalho no 
servidor de banco de dados primário. Você precisa habilitar a leitura no banco de dados 
de standby para que isso aconteça. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 23 
64 
Reprodução adiada (delayed replay): Você pode usar o recurso de reprodução adiada 
para especificar que um banco de dados de espera possa permanecer em um ponto 
anterior no tempo em relação ao banco de dados principal, em termos de reprodução do 
registo de log. A funcionalidade HADR de reprodução atrasada ajuda a prevenir a perda 
de dados resultante de operações incorretas. Para implementar HADR delayed replay, 
defina o parâmetro de configuração de banco de dados hadr_replay_delay no banco de 
dados de espera. 
Avanço de versões (updates e upgrades): A configuração do HADR permite que a 
execução de vários tipos de upgrades e fix packs seja feita sem levar o banco para o estado 
de off-line. Se você tem vários nós em standby, é possível executar um upgrade mantendo 
a proteção provida pela solução HADR. 
HADR pode ser a melhor opção quando a maioria ou todos os dados do seu banco de dados precisam 
de proteção ou se você executar operações DDL que devem ser replicados automaticamente em 
um banco de dados standby. No entanto, HADR é apenas uma das várias soluções de replicação que 
são oferecidos na família de produtos DB2. 
O software InfoSphere Federation Server e o sistema de banco de dados DB2 incluem a replicação 
SQL e soluções Q-replication que você também pode usar, em algumas configurações, para fornecer 
alta disponibilidade. Estas soluções mantêm cópias logicamente consistentes de tabelas de banco 
de dados em vários locais. Além disso, elas fornecem funcionalidades flexibilidades e complexas, 
como o suporte à filtragem de coluna e de linha, transformação de dados e atualizações em 
quaisquer das cópias de uma tabela. Você também pode usar essas soluções em ambientes de banco 
de dados particionado. 
A topologia padrão é um banco primário e outro banco de dados de standby. Esta topologia se 
tornou o layout mais comumente visto no mercado. Esta configuração consiste em um par de 
servidores, um com uma única instância DB2 e um único banco de dados que age como o banco de 
dados principal, e outro com uma única instância DB2 e um único banco de dados que funciona como 
o banco de dados de standby. 
No entanto, esta situação não é, de modo algum, a única forma em que pares de bases de dados 
HADR podem ser implementados em servidores. A replicação HADR ocorre em um nível de banco 
de dados, e não no nível de instância. Portanto, um servidor de espera pode ter vários bancos de 
dados a partirde múltiplos bancos primários. Outra opção de configuração é implementar dois 
servidores, um modo de cluster ativo/ativo. Na figura abaixo, os bancos de dados primários HADR 
estão espalhados por ambos os servidores em uma configuração de compartilhamento de carga. A 
vantagem com esta opção é que faz uso mais eficiente dos ciclos dos processadores disponíveis, e 
de outros recursos do servidor. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 24 
64 
 
Desde a versão 10.1 do DB2, o recurso de HADR também suporta múltiplos bancos de dados 
standby. Este recurso permite uma topologia avançada onde você implanta HADR no modo de 
espera múltipla. Neste cenário, você pode ter até três bancos de dados de standby em sua 
configuração. Você define um desses bancos de dados como o principal banco de dados standby 
HADR. Qualquer outro banco de dados standby é um banco de dados de espera auxiliar. 
Tal como acontece com a implantação padrão de HADR, os dois tipos de bancos de esperas são 
sincronizados com o banco de dados primário através de uma conexão direta TCP/IP. Ambos os tipos 
suportam a leitura sobre o banco de espera, e você pode ainda configurar a reprodução adiada de 
log. Este cenário é ilustrado pela figura abaixo. 
 
Há muitos benefícios ao usar uma configuração múltipla HADR de espera. Em vez de utilizar o recurso 
HADR para alcançar seus objetivos de alta disponibilidade e outra tecnologia para atingir seus 
objetivos de recuperação de desastres, você pode usar HADR para ambos. Você pode implantar seu 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 25 
64 
principal modo de espera no mesmo local como o primário. Se houver uma interrupção no primário, 
o banco principal de espera pode assumir o papel de primário atingindo os objetivos de tempo de 
recuperação (RTOs). Você também pode implantar esperas auxiliares em locais distantes, que 
fornecem proteção contra desastres generalizados que afetam tanto o primário quando o banco 
principal de espera. 
Quando você trabalha com vários bancos de dados de espera, todos os modos de sincronização 
HADR são suportados sobre o banco de espera principal, mas as esperas auxiliares podem ser apenas 
no modo SUPERASYNC. 
Outro ponto que devemos levar em consideração quando você configura um ambiente HADR é o 
recurso de delayed replay. Este recurso evita a perda de dados por causa de transações incorretas. 
A reprodução atrasada mantém intencionalmente o banco de dados de espera em um ponto no 
tempo que é anterior ao banco de dados principal, atrasando repetição de logs no banco de espera. 
Se uma transação incorreta é executada no primário, você tem o tempo de atraso configurado para 
impedir que a transação seja repetida no banco de espera. Para recuperar os dados perdidos, você 
pode copiar esses dados para o primário, ou você pode deixa a espera se tonar o novo banco de 
dados primário. 
Você pode usar esse recurso em qualquer modo de espera único ou modo de espera múltiplo. No 
modo de espera múltiplo, normalmente uma ou mais esperas permanecem atualizadas de forma 
sincronizada com o primário garantindo a alta disponibilidade ou a recuperação de desastres, e uma 
das esperas é configurada com reprodução retardada para proteção contra as transações incorretas. 
Conforme prometido anteriormente, vamos agora tratar dos estados do banco de dados HADR. 
Estados do banco de dados HADR 
A qualquer momento, um banco de dados HADR de espera está em um dos cinco estados: local 
catchup, remote catchup pending, remote catchup, peer ou disconnected peer. Os estados são 
definidos pelo status do log de envio. Independentemente do estado, todos as ocorrências dos 
registos log disponíveis são respondidas. 
Se o banco de espera está conectado ao primário, isso é relatado no campo HADR_STATE da tabela 
MON_GET_HADR e na saída do comando db2pd. (Se não estiver conectado, ele relata 
DISCONNECTED). 
A figura a seguir mostra a progressão através dos diferentes estados da base de dados de espera. 
Em seguida veremos o que cada estado representa. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 26 
64 
 
Local catchup: Com o recurso HADR, quando um banco de dados é iniciado como um 
banco de espera, ele entra no estado local catchup, e os arquivos de log armazenados 
localmente são lidos para determinar quais registros estão disponíveis. Neste estado, os 
registros não são recuperados a partir do arquivo, mesmo se você configurou o método 
para log de arquivamento (log archiving method). Além disso, neste estado, uma conexão 
para a base de dados principal não é necessária, no entanto, se uma conexão não existir, 
o banco de dados de standby tenta se conectar ao banco de dados principal. Quando o 
final dos arquivos de log locais é atingido, o banco de dados de standby entra no estado 
remote catchup pending. Basicamente neste estado ocorre a verificação das informações 
de logo nos arquivos locais. 
Remote catchup pending: Este estado começa com a verificação da conexão com o site 
primário, se ela ainda não foi estabelecida, então, uma conexão é solicitada e espera-se 
para que seja concretizada. Estabelecida a conexão o servidor do banco de dados de 
standby obtém as informações dos logs correntes. Isso permite que se verifique se os 
registros de logs do banco de dados de standby são válidos, caso esteja configurado no 
modo log archive. Vejam que está etapa é responsável por fazer a conexão com a base 
primária e por executar um match entre os arquivos de logo do servidor primário com o 
de standby. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 27 
64 
Remote catchup: Neste estado os dados são de fato lidos do log de dados da base 
primária e enviados para a base de espera. Após todos os dados serem transferidos as 
bases entrem no estado de Peer. 
Peer: Aqui os dados de log são enviados diretamente do buffer do log gravação do site 
primário para o banco de espera sempre que o principal libera suas páginas de log para o 
disco. O modo de sincronização do HADR especifica se os bancos primários esperam por 
uma mensagem de confirmação de que os dados dos registros log foram recebidos. As 
páginas de log são sempre gravadas nos arquivos de log locais do banco de dados de 
standby. Esse comportamento protege contra um acidente e permite que um arquivo 
possa ser arquivado no novo banco primário em caso de falha, caso não tenha sido 
arquivado no antigo primário. Depois de serem escritas no disco local, as páginas de log 
recebidas podem ser reproduzidas no banco de dados de espera. 
Se o log spooling estiver desativado, que é o padrão, a ação de reprodução dos logs vai ler os 
registros apenas do log buffer de recepção. Se o log de repetição estiver lento, o buffer de recepção 
pode ficar cheio, e o banco de espera deixa de receber novos logs. Se isso acontecer, a escrita no log 
primário é bloqueada. 
Se a conexão entre os bancos de dados primário e de espera é perdida quando os bancos de dados 
estão em estado de peer e o parâmetro de configuração de banco de dados hadr_peer_window é 
definido como 0, que é o padrão, o banco de dados standby entra no estado remoto catchup 
pending. No entanto, se a conexão entre os bancos de dados primário e de espera é perdida durante 
o estado de peer e você definiu oparâmetro hadr_peer_window para um valor diferente de zero (o 
que significa que você configurou uma janela de pares), o banco de dados standby entra no estado 
disconnected peer. 
Disconnected peer: Se você configurou uma janela de pares e o banco de dados primário 
perde sua conexão com o banco de dados de standby, no estado de peer, o banco de 
dados primário continua a se comportar como se os bancos de dados estão em estado de 
Conceitos rápidos: hadr_timeout e hadr_peer_window 
hadr_timeout: parâmetro de configuração que determina 
quanto tempo uma base de dados HADR aguarda antes de 
considerar que sua conexão com o banco de dados do parceiro 
como falhou. 
hadr_peer_window: parâmetro de configuração determina se 
o banco de dados entra em estado disconnected peer após uma 
conexão for perdida, e quanto tempo o banco de dados deve 
permanecer nesse estado. O HADR peer window não é 
suportado em um ambiente DB2 pureScale®, portanto, 
qualquer definição para hadr_peer_window é ignorada. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 28 
64 
peer. Este comportamento dura até que a janela de pares expira ou até que o bando de 
espera se reconecta, o que ocorrer primeiro. Quando o banco de dados primário e de 
espera são desconectados, mas se comportam como se eles estivessem em estado de 
peer, este estado é chamado disconnected peer. 
Com a janela de pares habilitada, o banco de dados primários bloqueia o processamento de 
transações por um determinado período de tempo, depois de perder sua conexão com o banco de 
espera em estado de peer, o que gera uma proteção contra falhas em cascata. Além disso, a espera 
pode assumir dentro do tempo de janela de pares sem risco de perda de dados. 
Vamos agora desenvolver um pouco melhor a descrição dos modos de sincronização que forma 
listados no início da aula. 
Modos de sincronização 
Com HADR, você pode escolher o nível de proteção que você admite para uma perda potencial de 
dados, especificando um dos modos de sincronização: 
Síncrono (Syncronous): A gravação de log é considerada bem-sucedida somente quando 
os buffers de log são escritos nos arquivos de registro de log do banco de dados primário 
e depois do recebimento de um ack que os dados foram igualmente escritos para os 
arquivos de log dos bancos de espera. Não pode haver perda de dados neste modo se o 
HADR está no estado de pares (Peer state). 
Quase-síncrono (Near-synchronous) - Esta é a opção padrão. A escrita do log só é bem-
sucedida quando o buffer de log do banco primário é escrito nos arquivos no log do banco 
primário e uma confirmação é recebida que o buffer de log foi recebido no banco de 
espera. 
Assíncrono (Asynchronous) – A escrita do log é bem-sucedida quando os logs são 
gravados no disco no banco primário e os registros de log de dados são enviados usando 
TCP/IP para o banco de espera. A perda de dados pode ocorrer neste modo. 
Super-assíncrono (Super-asynchronous) - As gravações de log são consideradas bem-
sucedidas quando os registros de log são escritos para os arquivos de log no banco de 
dados primário. O fato do banco de dados primário não esperar pelas confirmações do 
banco de dados de standby leva as transações a serem consideradas comitadas 
independentemente do estado da replicação dessa transação. 
A figura a seguir ilustra esses modos de sincronização do HADR e o ponto em que o DB2 se considera 
capaz de confirmar uma transação durante o estado de pares (Peer state). A figura representa os 
dois bancos, primário e de espera, interligados pelo protocolo TCP/IP. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 29 
64 
 
Arquitetura 
A tecnologia HADR é estritamente acoplada a estratégia de escrita de logs e recuperação de 
desastres. O objetivo principal da solução é prover uma failover rápido, substituindo o sistema de 
banco de dados primário pelo banco de espera se alguma falha acontecer. 
A arquitetura básica do HADR é simples. Sua estrutura é baseada no repasse dos logs do banco de 
dados primário para o banco de dados de espera. Cabe ao DBA a escolha de quais bancos de dados 
devem ser replicados. 
Para inicializar o HADR você deve escutar comandos tanto no banco de dados primário quanto nos 
bancos de espera. O sistema HADR começa a funcionar assim que o banco de dados primário fica no 
estado ativo. 
O DB2 tem duas unidades especiais de motores de despaches (engine dispatchable units - EDUs) 
para lidar com todo o trabalho do HADR. Uma é executada sobre o banco de dados principal 
chamada db2hadrp. Sua contraparte no banco de dados de espera é chamada db2hadrs. Eles são 
responsáveis pelo envio dos registros de log do banco primário para o banco de espera, pelo 
processamento de mensagens do sistema, e por receber arquivos de log no sistema de espera. 
Na ativação do banco de dados do primário, o db2hadrp é criado. O processo, em seguida, lê o 
arquivo de configuração de banco de dados e abre uma porta para atender a conexão a partir do 
banco de espera. Durante esse tempo, nenhuma conexão de clientes é permitida. O banco primário 
aguarda um número de segundos definidos no parâmetro de configuração HADR_TIMEOUT pela 
conexão. Se o primário não receber qualquer comunicação do banco de dados de standby, então o 
primário conclui que a conexão com o banco de espera está perdida. 
Se principal e seu correspondente standby estiverem no estado de pares quando a conexão for 
perdida, eles se movem para o estado de pares desconectado se o parâmetro de configuração de 
banco de dados hadr_peer_window for maior do que zero, ou para o estado catchup remoto 
pendente se hadr_peer_window não for maior que zero. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
==10ef0==
 
 
 
 
 
 
 
 
 30 
64 
Se a cláusula BY FORCE for usada quando você executar o comando START HADR, o primário não 
aguarda o banco de espera se conectar. O banco primário cria um listener que fica monitorando 
uma conexão na porta HADR. A espera inicia a conexão com o primário. Se a tentativa de conexão 
do banco de espera falhar, ele tenta se conectar para o primário novamente. Os clientes DB2 são 
sempre capazes de se conectar a um banco de dados primário HADR ativo, e sempre que a espera 
estiver pronta, a funcionalidade real do HADR torna-se operacional. 
O EDU db2lfr captura as alterações que são feitas no servidor primário, quer através da leitura do 
buffer de log ou lendo os arquivos de log. Em seguida, ele retransmite os registros de log para o 
db2hadrp, que por sua vez encaminha os registros para o segmento db2hadrs no banco de espera. 
Por fim, o segmento db2hadrs passa os dados de registo recebidos para o sistema de log local. 
Depois de todos os registros em disco e memória do banco primário serem retransmitidos para o 
banco de espera, o sistema HADR entra no estado de pares. 
Apresentamos de forma rápida dos conceitos e estruturas relacionados a alta disponibilidade do DB2 
incluso dentro da estrutura do HADR. Agora vamos passar para a definição de alguns termos que 
considero importante, eles aparecem dentro do assunto de administração de banco de dados. 
Vamos a eles? 
Terminologia 
A seguir apresentamos uma lista dos termos mais comuns que são usados em uma solução HADR 
DB2. A maioria desses termos podem ser encontrados em vários manuais do DB2, onde você pode 
pesquisar, e vê-los sendo usados em diversões contextos. 
Catchup phase: A inicialização do HADR sempre começa na fase de catchup, em que o 
bancode standby tenta pegar (catch up) os registros na memória do banco primário. 
Durante esta fase, o banco de espera pode recuperar arquivos de log localmente ou 
remotamente a partir do primário por meio da conexão de rede HADR. 
Cluster: Um cluster é um sistema que se baseia em dois ou mais nós. Os nós são 
conectados uns aos outros e possuem armazenamento compartilhado. Cada um desses 
itens é considerado um recurso do cluster. Um software de clustering é usado para 
conectar logicamente esses recursos para parecer como um único sistema para os 
clientes. 
Recurso de cluster: Um objeto que pode ser gerenciado por um software de clustering. 
Os softwares de clustering suportam muitos tipos de recursos. Esses tipos de recursos 
incluem discos, endereços IP, arquivos compartilhados, instância do DB2, e assim por 
diante. 
Failover: No contexto da HADR, este termo refere-se a alterar o estado do banco de 
espera em um par de HADR para torna-lo o banco primário, com a funcionalidade 
completa do DB2, porque a primário original falhou. O primário original pode iniciar, em 
seguida, no papel de standby. Alguns cuidados devem ser tomados para garantir que o 
primário original esteja verdadeiramente não-funcional no momento do failover. Se 
ambas as bases de dados estão funcionando como primário, haverá um conflito na 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 31 
64 
atualização de dados que o HADR não consegue resolver. O resultado são duas versões 
incorretas do banco de dados. 
Failback: No contexto da HADR, após um failover, que fez o banco de espera original 
torna-se um banco primário, o failback é o ato de reverter esta base de dados de volta 
para um modo de espera e trazer o banco primário original de volta. Isso significa que, 
trocando os papéis do primário e do banco de espera, enquanto ambos estão em 
execução e sem falhas. 
O failback não é uma operação obrigatória. Um cliente pode escolher deixar as bases de 
dados nos seus papéis invertidos até que outra operação de failover seja necessária. Esta 
situação é especialmente provável nos casos em que o objetivo é um failover ultrarrápido, 
onde o retorno de uma falha pode ser visto como uma interrupção desnecessária do 
serviço. 
Os clientes que escolhem esta opção devem garantir que todos os objetos e processos 
relacionados ao DB2, que o HADR não replica, são os mesmos em ambos os servidores. 
Esta situação é especialmente verdadeira para coisas como agendamento de tarefas em 
lote, que devem ser desativados enquanto o banco de dados estiver no modo de espera, 
e ativados enquanto ele estiver no modo primário. 
Falhas (failure): Uma falha é um evento em que qualquer componente que seja pré-
requisito do serviço de banco de dados (DB2, sistema operacional, máquina de servidor 
ou de rede) não seja mais capaz de prestar seu serviço. O HADR mantém a disponibilidade 
dos dados, se houver uma falha em qualquer componente isolado. Se a falha afeta apenas 
o sistema de espera ou a comunicação entre o primário e o banco de espera, os dados 
permanecem totalmente disponíveis no primário, sem qualquer interrupção ou 
necessidade de ação do usuário. 
Se a falha impede que o próprio banco primário forneça a funcionalidade do DB2, o DBA 
pode tirar do ar a instância primária do DB2, o servidor, ou ambos (se já não estiver) e 
iniciar um failover, que muda rapidamente o banco de espera para a função de banco 
primário, tornando os dados disponíveis novamente após uma breve interrupção. 
Algumas falhas podem ser detectadas e reportadas pelo HADR e pelo DB2 para ajudar o 
DBA a decidir se o failover é necessário ou se certos componentes do banco de dados 
simplesmente exigem atenção. Os processos de banco de dados HADR relatam falha 
quando eles são incapazes de se comunicar. Os processos de banco de dados DB2 expõe 
uma falha quando detectam um problema. Estes componentes são os únicos 
componentes de banco de dados DB2 que relatam falhas fornecidos pelo software DB2. 
Split brain: Este termo refere-se à condição em que dois bancos de dados em um par 
HADR estão atuando como bancos primários simultaneamente. Tal situação leva as bases 
de dados a um estado inconsistente entre si e devem ser evitadas a todo custo. O HADR 
não faz automaticamente transições de estado que resultam em dois bancos primários, e 
quando o par pode se comunicar um com os outros (isto é, a conexão de rede entre eles 
está a funcionar corretamente), ele também impede que um usuário crie esta situação. 
O HADR também não permite que um banco de dados primário inativo seja ativado sem 
uma conexão bem-sucedida para um banco de espera dentro do período definido pela 
variável HADR_TIMEOUT. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 32 
64 
No entanto, o Split brain ainda é possível em uma situação onde o DBA instrui o banco 
de espera a se tornar um primário enquanto o link de comunicação entre o par está para 
indisponível, e ainda se o primário atual ainda estiver ativo ou se ele foi colocado em um 
estado não-HADR. Mas, este comando é manual e executado somente nos casos mais 
extremos. 
Feita essa rápida consideração sobre termos que considero importantes e que ainda haviam sido 
apresentados durante a aula, podemos concluir nosso estudo de HADR e partir para a solução de 
pureScale. 
DB2 PURESCALE 
Esta seção apresenta a pureScale do DB2, uma tecnologia que trabalha em um ambiente de cluster 
e usa uma arquitetura de compartilhamento de dados. Esta arquitetura é ideal para escalabilidade 
e principalmente apropriada para o processamento de transações. Neste ambiente, os dados que 
estão sendo acessado são compartilhados por todos os servidores no cluster. Se houver uma falha 
em um dos servidores, ou se ele necessita ficar off-line para fins de manutenção, o restante dos 
membros que continuam on-line no cluster assumem o trabalho, proporcionando assim uma alta 
disponibilidade transparente para os dados. 
DB2 pureScale é baseado na tecnologia robusta que foi executada em sistemas de produção de 
mainframe por mais de uma década. Como em outras soluções como no particionamento de banco 
de dados DB2, com o DB2 pureScale não há necessidade dos desenvolvedores de aplicativos 
escreverem algum código especial para fazer uso da tecnologia. 
Visão geral da arquitetura 
Um ambiente DB2 pureScale é composto de membros que executam com a tecnologia do DB2 
pureScale. Cada membro do coopera com o outro para proporcionar o acesso coerente à mesma 
cópia do banco de dados compartilhado. O banco de dados é armazenado em um disco 
compartilhado acessível por todos os membros. 
A figura a seguir ilustra um cluster pureScale com quatro membros, cada um executando uma cópia 
do DB2. Todos os membros estão compartilhando os dados de um único banco de dados 
particionado. Cada membro mantém seu próprio conjunto de arquivos de log de transações no disco 
compartilhado, cada conjunto em um caminho (diretório) de log separado. O topo da figura mostra 
os clientes que executam consultas que acessam o banco de dados. Estas consultas são 
automaticamente redirecionadas para um dos membros do cluster visando garantir o 
balanceamento de carga; isso garante nenhum membro está sobrecarregado com o trabalho. 
A figura também mostra os serviços de cluster em cada membro e uma interconexão de cluster 
(interconexão de alta velocidade e baixa latência) para facilidades de armazenamento em dois 
clusters de cache, além de outros conceitos e componentes, tais como o sistema de arquivos em 
cluster, locking global, gestão de buffer, e assim por diante. Todas estas tecnologias e componentes, 
que são descritos em mais detalhena seção seguinte, ajudam o pureScale a conseguir escalabilidade 
transparente e elevada disponibilidade. (a IBM deveria me pagar para escrever esse texto). 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 33 
64 
 
DB2 pureScale também pode ser implantado em um ambiente virtualizado. Por exemplo, um 
servidor físico que executa duas máquinas virtuais pode ter DB2 pureScale instalado em ambos. Em 
um ambiente de produção, recomenda-se que cada membro tenha seu próprio computador ou host 
físico único para oferecer alta disponibilidade e escalabilidade ideal. 
Interconexão do cluster 
Membros do DB2 pureScale e outros componentes da tecnologia compartilham dados e outras 
informações entre eles. A alta velocidade e a baixa latência de interconexão são necessárias para a 
comunicação extremamente rápida. A tecnologia remota de acesso direto à memória (RDMA) 
desempenha um papel fundamental para atingir esse objetivo. 
RDMA é uma característica de interface da placa de rede que permite que um host acessar a 
memória de outro host diretamente. Ele ignora os sistemas operacionais, evita os dados 
atravessando de memória do aplicativo para a memória do kernel, não necessita de chamadas de 
socket de IP, nenhuma mudança de contexto, e sem interrupções. Por isso, é também referido como 
RDMA livre de interrupção. 
O DB2 pureScale foi projetado e otimizado para trabalhar com uma estrutura de interconexão 
Infiniband e RDMA over Converged Ethernet (RoCE). Infiniband é um padrão da indústria para a 
arquitetura de interconexão para conectividade entre o servidor de processamento e o storage. Esta 
tecnologia é muito madura, foi criada em 1999. Por outro lado, a especificação ‘RoCE’ foi lançada 
por volta de 2010. É um transporte leve de RDMA sobre Ethernet. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 34 
64 
DB2 pureScale exige que uma rede de comunicação de alta velocidade que use uma rede InfiniBand 
ou uma rede 10GE (Gigabit Ethernet). A mistura destas duas redes no cluster pureScale não é 
suportada. 
DB2 pureScale suporta apenas sistemas operacionais AIX e Linux no System X. pureScale suporta 
redes Infiniband e RoCE. O suporte a ‘RoCE’ para pureScale no AIX foi adicionado no DB2 10.1. 
Funcionalidades do Cache de cluster 
Conhecido como cluster cache facility (CF) é um software especializado que oferece gestão global de 
bloqueio, serviço de buffer pool em grupo, e alguns outros serviços. 
Quando um membro requer um bloqueio de linha ou tabela para processar uma transação, a gestão 
de bloqueio local do membro comunica ao gerenciador de bloqueio global da CF usando RDMA. 
Processos dedicados no servidor de CF executam imediatamente o pedido. 
Da mesma forma, quando um membro tenta acessar uma página de dados, a sua buffer pool local 
solicita a cópia mais recente da página a CF usando RDMA. O serviço de pool de buffer de grupo do 
CF gerencia um cache global para as páginas acessadas com maior frequência (também conhecido 
como páginas quentes) no cluster. Se a página solicitada está na área de buffer de grupo, a página é 
transferida para o buffer pool local do membro. O pool de buffer de grupo também mantém um 
registro da página, que registra as páginas que são alocadas para cada membro. Se uma página é 
atualizada, o pool de buffer de grupo informa a todos os membros que a página já não é mais válida 
com base no registo página. 
Recomenda-se a utilização de dois CFs para fornecer redundância e para eliminar um único ponto 
de falha no cluster. 
Serviços de cluster DB2 
DB2 pureScale vem com um componente integrado chamado Cluster Services (CS). O CS é executado 
em todos os membros e nos CFs do cluster pureScale. Ele é usado para detectar falhas em algum 
membro, impulsionar a recuperação automatizada do membro, e gerenciar o acesso aos dados 
compartilhados. Esses serviços são fornecidos por três produtos de software diferentes da IBM que 
são totalmente integrados dentro da estrutura do DB2: 
• IBM Reliable Services Clustering Technology (RSCT): Permite a detectar a falha membro. 
• Tivoli Systems Automation for Multi Platforms (TSAMP): Permite a recuperação 
automática. 
• IBM General Parallel File System (GPFS): Fornece o sistema de arquivos compartilhados 
em cluster. 
Embora estes três produtos IBM sejam separados, eles são perfeitamente integrados no DB2 
pureScale. Por exemplo, o CS interage com o RSCT e o GPFS quando acontece uma falha de membro. 
Antes do membro ser recuperado e ter novamente acesso ao sistema de arquivos GPFS, o RSCT deve 
primeiramente reconhecer e permitir que o membro volte a fazer parte do cluster. 
 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 35 
64 
Sistema de arquivos do cluster 
GPFS é o sistema de arquivos de cluster utilizado com DB2 pureScale. Ele fornece acesso simultâneo 
a todos os membros da arquitetura pureScale para os arquivos de instância e os arquivos de banco 
de dados, tais como contêineres de espaço de tabela e logs. 
GPFS tem sua própria ferramenta de gestão. No entanto, para fornecer uma experiência integrada 
para administradores de banco de dados DB2, eles podem usar o comando db2cluster -cfs para criar, 
montar e configurar os sistemas de arquivos. Há uma lista de opções disponíveis para o comando 
db2cluster. Diferentes opções requerem diferentes níveis de autorização do DB2, como SYSADM, 
SYSCTL ou SYSMAINT. 
Uma instância de DB2 pureScale 
Em um cluster pureScale, você pode definir uma instância pureScale. Em uma instância, vários 
bancos de dados ativos são suportados. Como no ambiente de banco de dados particionado, o DB2 
pureScale também usa o arquivo de configuração do nó (db2nodes.cfg) para manter informações 
sobre os hosts do cluster. Especificamente, ele armazena informações sobre cada membro do 
pureScale e cada CF, o nome do host, e o nome de interface de rede. Abaixo temos um arquivo 
db2nodes.cfg com quatro hosts membros e dois CFs. 
 
Durante a instalação e configuração do DB2 pureScale, o Assistente de Configuração do DB2 atualiza 
o arquivo de configuração do nó com base nos nomes de rede de interconexão de cluster que você 
especificar. 
Para obter uma visão geral da saúde do cluster pureScale, você pode usar o comando db2instance -
list. Por exemplo, você receberia uma lista semelhante à seguinte: 
 
Uma visão administrativa DB2, DB2_GET_CLUSTER_HOST_STATE, fornece informações 
semelhantes. Por exemplo, você pode usar a seguinte instrução SQL para consultar o status cluster. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 36 
64 
 
Em um ambiente em cluster como pureScale, você pode se perguntar onde os arquivos relacionados 
ao pureScale são armazenados. Lembre-se que o DB2 está instalado em cada membro como 
mostrado na figura que apresenta a arquitetura. Por isso, cada host tem um diretório sqllib local, 
assim como no ambiente sem o pureScale. No diretório sqllib, há uma combinação de diretórios e 
arquivos locais para o membro, bem como arquivos que apontam para o diretório de instalação. 
O arquivo de configuração do nó DB2, db2nodes.cfg, arquivo de configuração do gerenciador de 
banco de dados, db2systm, arquivos de log, esses arquivos são comuns a membros pertencentes à 
instância pureScale. Eles estão localizados no diretório sqllib_sharedno sistema de arquivos 
compartilhado em cluster. 
Observem a figura a seguir para ter uma ideia de como os arquivos são mapeados para o diretório 
sqllib_shared. 
 
 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 37 
64 
Membros de um cluster DB2 pureScale também podem ser configurados para estarem em locais 
diferentes, o que minimiza o risco de interrupção total caso todo o data center seja desativado 
devido a um incêndio ou falha de energia. Esta configuração é conhecida como o geographically 
dispersed DB2 pureScale cluster (GDPC). 
Depois de apresentarmos as diversas partes da estrutura da arquitetura DB2 pureScale, vamos agora 
comentar um pouco sobre três características que fazem parte do serviço entregue: Transparência 
da aplicação, Disponibilidade contínua e Escalabilidade e capacidade extrema. 
Transparência da aplicação 
A palavra transparência como um recurso do DB2 pureScale é fundamental. Idealmente, você espera 
que qualquer aumento na carga de trabalho ou falhas em um cluster de banco de dados não afete 
o funcionamento de uma aplicação. Assim, do ponto de vista de aplicação, a sua única preocupação 
é recuperar as solicitações dos usuários e responder de volta com informações adequadas. O recurso 
DB2 pureScale oferece as seguintes vantagens sem alterar uma aplicação: 
⦿ Escalabilidade para você crescer: Capacidade para comprar apenas o suficiente para satisfazer as 
necessidades de capacidade atuais e adicionar membros DB2 para escalar conforme sua carga de 
trabalho cresce. 
⦿ Manutenção da disponibilidade: Maximizar as taxas de utilização de hardware e manter os 
tempos de resposta consistente porque as solicitações de entrada são automaticamente 
balanceadas, ou seja, espalha-se a carga de trabalho entre os vários servidores de processamento. 
⦿ Adicionar ou remover recursos facilmente: Adicionar recursos durante a hora de pico ou eventos 
sazonais para evitar tempos de resposta lentos, ou o quando um tempo de inatividade de um 
servidor é necessário. 
 
1. BANCA: TRC CONCURSO ANO: 2019 ÓRGÃO: INDEFINIDO PROVA: NÍVEL SUPERIOR - 
ANALISTA DE SISTEMAS 
Com relação ao DB2 pureScale julgue o item abaixo: 
Você pode usar o recurso DB2 pureScale IBM para escalar um banco de dados (DB) para um 
conjunto de servidores em uma abordagem ativo-ativo. O tráfego destinado a um nó com falha 
ou é repassado para outro nó existente ou carregar equilibrada para os nós restantes. Esta 
tecnologia é similar à arquitetura de compartilhamento de dados encontrada no DB2 para IBM 
z/OS®. Este recurso fornece os benefícios da transparência, disponibilidade e escalabilidade a 
um custo operacional menor que o anterior. 
Comentário. A questão encontra-se correta e adiciona a informação que não tínhamos visto 
até agora que é a redução de custos por meio do uso desta arquitetura em relação outras 
opções oferecidas pela IBM. 
Gabarito: C 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 38 
64 
 
Disponibilidade contínua 
Disponibilidade garante que o cluster permanece operacional durante interrupções, planejadas ou 
não. Durante as operações de manutenção, falhas de hardware ou falhas de rede, a instância do DB2 
pureScale ainda deve ser capaz de processar solicitações de banco de dados sem interrupções. Além 
disso, a disponibilidade também garante que você receba a resposta esperada às solicitações de 
serviço em tempo hábil, não importa as circunstâncias. 
Disponibilidade contínua é dependente de eventos não planejados ou planejados, conforme descrito 
abaixo. 
Eventos não planejados 
As falhas de hardware podem ser altamente perturbadoras, mesmo em sistemas com componentes 
redundantes. Por projeto, o recurso do DB2 pureScale contém funções, tais como heartbeats, 
mecanismos de barreia, reinícios automáticos e mudanças de papeis, para manter uma instância em 
execução e minimizar os efeitos das falhas no restante do sistema de banco de dados Veja a figura 
seguir um cenário de falha no CF. 
 
Os seguintes recursos do DB2 pureScale fornecem disponibilidade contínua: 
⦿ Heartbeats: Uma “pulsação” enviada entre hosts garante que uma falha de host é 
imediatamente detectada e isolada. Esse conceito também aparece na solução de HADR 
estudada anteriormente, lembram? 
⦿ Mecanismos de barreira: Quando um membro falha durante o processamento de uma 
solicitação de banco de dados, a sua falha necessita ser imediatamente detectada e 
qualquer comunicação com este membro deve ser terminada assim que possível. Esse 
recurso permite a comunicação com o membro a seja barrada além do seu acesso ao 
disco. Enquanto isso, os dados ainda estão acessíveis ao restante dos membros ativos 
para processar a solicitação de banco de dados. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 39 
64 
⦿ Reinício automático do membro: Durante uma falha de software em um membro, ele 
tenta recuperar automaticamente no mesmo dispositivo para retomar as transações. Se 
o membro não pode reiniciar em seu host, ocorre uma reinicialização em outro host de 
modo que quaisquer bloqueios mantidos pelo membro afetado são liberados 
imediatamente. Quaisquer transações que não foram concluídas no momento da falha 
também serão revertidas (rollback), e a aplicação é notificada. 
⦿ Reinício automático do conjunto CF: Em uma falha de software ou hardware no cluster 
primário de CF, um segundo clusters que contém as informações replicadas assume o 
papel do principal. A ação de assumir a posição do CF primário é transparente para as 
aplicações e a instância continua disponível. 
Com o recurso DB2 pureScale, características de disponibilidade são integradas diretamente na 
arquitetura. Todos os recursos necessários são monitorados automaticamente por serviços de 
cluster do pureScale DB2. Esses recursos são reiniciados e recuperados quando necessário. Falhas 
nos membros não são detectadas pelos aplicativos clientes porque as requisições do cliente são 
reencaminhadas automaticamente para os membros ativos restantes. Contudo, um dos fatores que 
faz com que o recurso DB2 pureScale seja competitivo é que não há um congelamento de todo o 
cluster quando ocorre uma falha em um dos membros. 
Na verdade, os dados continuam sendo processados, e todos os membros são atualizados para 
informar outros membros que este membro não está mais disponível até que a recuperação esteja 
completa. Aplicativos em usuários ativos que estão tentando acessar dados bloqueados pelo 
membro que falho são colocados no estado de espera rapidamente, mas não recebem os erros 
automaticamente. 
Em todos os casos de falha, após o host está disponível na rede, o recurso de DB2 pureScale 
automatiza a recuperação e tenta trazer o host de volta para o conjunto sem intervenção. O recurso 
DB2 pureScale reinicia o membro DB2 que deveria estar rodando no host. 
Eventos planejados 
Há várias circunstâncias em que você pode querer retirar do ar um sistema temporariamente, tal 
como com a manutenção do sistema ou atualizações de hardware. O recurso DB2 pureScale é 
projetado para executar estes tipos de tarefas de manutenção com o mínimo de impacto possível 
para todo o cluster DB2 pureScale. 
Você pode usar o DB2 para colocar um membro em estado off-line. Quando estiver neste estado, 
transações e conexões subsequentes são redirecionadas para outros membros disponíveis, e 
membro atual, eventualmente, para o processamento de transações. Os aplicativos clientes nem 
percebe que um membro foi colocadooff-line (também conhecido como manutenção discreta 
(stealth)). 
Como os aplicativos de cliente são agora conectados a outros membros, você pode tonar o membro 
off-line e realizar a manutenção, causando o mínimo de transtorno possível para os aplicativos 
clientes. Você pode usar esse método para a implantação de atualizações de sistema sem parar a 
instância do DB2 pureScale ou afetar a disponibilidade do banco de dados. Após a manutenção estar 
concluída, você pode reintegrar o membro à instância do DB2 pureScale. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 40 
64 
Escalabilidade e capacidade extrema 
Você pode usar o recurso DB2 pureScale para aumentar o número de nós até 128 e ainda oferecer 
escalabilidade quase linear e taxa de transferência máxima. Você pode usar essa abordagem 
transparente para escalabilidade ao adicionar recursos à medida que são necessários durante os 
horários de pico. Você também pode ajustar às variações sazonais ou para atender às necessidades 
da aplicação. 
A figura abaixo ilustra o comportamento desta escalabilidade quando você adiciona membros ao 
cluster. O cluster pode processar mais carga de trabalho assim que os novos membros se juntarem 
às operações de cluster. O throughput total é quase dobra quando o número de membros dobra. 
 
Finalizamos aqui nosso conteúdo teórico de DB2 pureScale. Decidimos por não alongar mais 
sobre esse assinto, pois seria um detalhamento inócuo quando o propósito é provas de concurso. 
Passaremos para os próximos pontos dentro da ementa e em seguida teremos um bloco de 
questões, nele faremos uma revisão e servirá para fixação do conteúdo. 
 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 41 
64 
RECUPERAÇÃO DE DADOS 
Backup e recuperação são tecnologias fundamentais para uma solução de recuperação de desastres. 
O DB2 fornece métodos de backup flexíveis para atender a vários requisitos de negócios. Você pode 
fazer backup de um banco de dados inteiro ou de espaços de tabelas selecionados, seja off-line ou 
on-line. 
 
 Além disso, você pode fazer backup de um banco de dados de forma incremental, o que significa 
que você tem que fazer o backup apenas dos dados mudaram desde o último backup. Ele é mais 
rápido do que um backup completo. 
O DB2 também fornece a funcionalidade de backup automático. Nele você define a sua política de 
backup e o DB2 faz cópias de segurança do seu banco de dados automaticamente. Em um ambiente 
de banco de dados particionado, o DB2 suporta backups Single System View (SSV), que você pode 
usar para fazer backup de um banco de dados em todas as partições de banco de dados ou de um 
subconjunto de partições de banco de dados com um comando backup. Todas as imagens de backup 
têm o mesmo timestamp e incluem os registos necessários para retomarmos o banco a um ponto 
consistente. 
O DB2 Advanced Copy Service (ACS) suporta a funcionalidade de snapshot, que é baseado na 
tecnologia IBM FlashCopy® da solução IBM Tivoli Storage Manager. Quando você usa essa 
funcionalidade, você pode fazer cópias de todo o volume lógico ou de conjuntos de dados com o 
mínimo impacto no seu sistema de produção. O DB2 ACS é empacotado com o DB2 a partir da Versão 
10.1. 
OBS: FlashCopy® permite que você faça cópias de um conjunto de faixas, com as cópias 
imediatamente disponíveis para acesso de leitura ou gravação. Este conjunto de faixas pode 
consistir em um volume inteiro, um data set, ou apenas um conjunto selecionado de faixas. 
A recriação do banco de dados é chamada de recuperação. A recuperação de versão é a restauração 
de uma versão anterior consistente do banco de dados, usando uma imagem que foi criado durante 
uma operação de backup. A recuperação de avanço (rollfoward) é a reaplicação de transações que 
são utilizados os valores registrados nos arquivos de log do banco de dados depois de um banco de 
dados ou um espaço de tabela de backup ser restaurado. Ambos os tipos de recuperação são 
fundamentais para uma solução de recuperação de desastres. Veja abaixo um exemplo da sintaxe 
dos dois comandos: 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 42 
64 
 
 
 
 
Se o seu plano de recuperação de desastres passa por restaurar todo o banco de dados em outra 
máquina, você deve ter pelo menos um backup completo e todos os logs arquivados para o banco 
de dados em questão. Embora seja possível reconstruir um banco de dados se você tiver um backup 
do espaço de tabela completo de cada tablespace do banco de dados, este método pode envolver 
várias imagens de backup e ser mais demorado do que a recuperação usando um backup completo. 
Desenvolvendo uma estratégia de recuperação 
Um banco de dados pode se tornar inutilizável por causa de uma falha de hardware ou software, ou 
ambos. Você pode, em um determinado momento, encontrar problemas de armazenamento, 
interrupções de energia ou falhas de aplicação, e cada cenário de falha requer uma ação de 
recuperação diferente. Proteger seus dados contra a possibilidade de perda traz a necessidade de 
uma estratégia de recuperação bem estruturada. 
Você precisa levar em consideração questão sobre o tempo gasto para recuperação, bem como o 
tempo necessário para a execução da tarefa de backup. O espaço disponível para armazenar as 
cópias de backup e os arquivos de log também aparecem como entrada numa análise. Por fim, 
precisamos pensar quais os dados devem fazer parte do backup, neste contexto, analisamos se uma 
cópia completa da base é de fato um requisito da nossa estratégia. 
A estratégia de recuperação de banco de dados deve garantir que toda a informação necessária para 
a recuperação do banco de dados esteja disponível quando for preciso. Ela deve incluir um 
agendamento regular para a execução de backups de banco de dados e, no caso de ambientes de 
banco de dados particionados, incluir backups quando o sistema for redimensionado (quando são 
adicionados ou removidos servidores ou nós de partição de banco de dados). Sua estratégia global 
também deve incluir procedimentos para a recuperação de scripts de comando, aplicações, funções 
Sintaxe para restauração de um banco: 
db2 restore database <nome_do_banco> from <localização> 
taken at <timestamp> 
 Exemplo: 
db2 restore database concursos from /home/db2inst1/ taken at 
20160822112743 
Sintaxe para aplicação dos logs: 
db2 rollforward db <nome_do_banco> to end of logs and stop 
Exemplo: 
db2 rollforward db concursos to end of logs and stop 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 43 
64 
definidas pelo usuário (UDF), código de procedimentos armazenados em bibliotecas do sistema 
operacional e cópias de carga. 
Vamos apresentar diferentes métodos de recuperação a seguir, e você vai descobrir qual método de 
recuperação é o mais adequado para o seu ambiente de negócios. 
O conceito de backup de banco de dados é o mesmo que qualquer outro backup de dados: “tirar 
uma cópia dos dados e, em seguida, armazená-la em um meio diferente para o caso de falha ou 
dano ao original”. O caso mais simples de backup envolve desligar o banco de dados, garantir que 
nenhuma operação nova ocorra, e em seguida, basta fazer o backup. Você pode, em seguida, recriar 
o banco de dados se ele for danificado ou corrompido de alguma forma.Recuperação de falhas (crash recovery) é uma recuperação automática da base de dados caso 
ocorra uma falha antes de todas as alterações que fazem parte de uma ou mais unidades de trabalho 
(transações) serem concluídas e confirmadas. Isso é feito por reverter as transações incompletas e 
completar as transações confirmadas que ainda estavam na memória quando o acidente ocorreu. 
Esse assunto é tratado do ponto de vista teórico no conteúdo da aula de recuperação e backup. 
Os arquivos de log de recuperação e o arquivo de histórico de recuperação são criados 
automaticamente quando um banco de dados é criado (veja a figura abaixo). Esses arquivos de log 
são importantes se você precisa recuperar os dados perdidos ou danificados. 
 
Cada banco de dados inclui logs de recuperação, que são usados para a recuperação de erros de 
aplicação ou de sistema. Em combinação com as cópias de segurança da base de dados, são 
utilizados para recuperar a consistência da base de dados até ao momento em que o erro ocorreu. 
O arquivo histórico de recuperação contém um resumo das informações de backup que pode ser 
usado para determinar as opções de recuperação, se a totalidade ou parte do banco de dados deve 
ser recuperado para um determinado ponto no tempo. Ele é usado para monitorar eventos 
relacionados com a recuperação, tais como operações de backup e restauração, entre outros. Este 
arquivo está localizado no diretório do banco de dados. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 44 
64 
O arquivo histórico de alterações de tablespace, que também está localizado no diretório do banco 
de dados, contém informações que podem ser usadas para determinar quais arquivos de log são 
necessários para a recuperação de um espaço de tabela particular. 
Você não pode modificar diretamente o arquivo de histórico de recuperação ou o arquivo histórico 
de alterações de tablespace; no entanto, você pode excluir as entradas dos arquivos usando o 
comando PRUNE HISTORY. Você também pode usar o parâmetro de configuração de banco de dados 
rec_his_retentn para especificar o número de dias que esses arquivos de histórico serão mantidos. 
As operações de backup de banco de dados podem ser executada off-line ou on-line (on-line significa 
dizer que outras aplicações podem se conectar ao banco de dados durante a operação de backup). 
O espaço de tabela de restauração on-line e as operações de avanço são suportados apenas se o 
banco de dados for recuperável. Se o banco de dados for não-recuperável, a restauração da base de 
dados e as operações de avanço devem ser realizadas off-line. Durante uma operação de backup on-
line, a recuperação de avanço garante que todas as alterações da tabela sejam capturadas e 
reaplicadas se que o backup for restaurado. 
Se você tem um banco de dados recuperável, você pode fazer backup, restaurar e fazer avanços de 
espaços de tabelas individuais, em vez de todo o banco de dados. Quando você faz backup de um 
espaço de tabela on-line, ele ainda fica disponível para uso, e as atualizações simultâneas são 
registradas nos logs. Quando você executa uma restauração on-line ou uma operação de avanço em 
um espaço de tabela, o espaço de tabela em si não ficará disponível para uso até que a operação 
seja concluída, mas os usuários não são impedidos de acessar tabelas em outras tablespaces. 
Apresentamos os conceitos básicos relacionados a recuperação de dados no DB2, agora vamos dar 
continuidade à nossa aula aprendendo sobre a integração do DB2 com o Tivoli Storage Manager. O 
IBM Spectrum Proteger (ou Tivoli Storage Manager) é uma plataforma de proteção de dados que 
dá às empresas um ponto único de controle e administração de backup e recuperação. 
INTEGRAÇÃO COM TIVOLI STORAGE MANAGER 
Tivoli Storage Manager (TSM) é o principal produto da família IBM Spectrum Proteger. Ele permite, 
backups confiáveis de baixo custo e recuperação rápida para ambientes virtuais, físicos e nuvem de 
todos os tamanhos. 
O TSM pode ajudar a construir uma infra-estrutura de gerenciamento de armazenamento mais 
inteligente que pode ajudá-lo a lidar com vários desadios da administração dos dados. Ele irá ajudá-
lo das seguintes maneiras: 
o Reduzindo o investimento e os custos operacionais, diminuindo os requisitos de 
armazenamento. 
o Melhorando a disponibilidade da aplicação e os níveis de serviço, reduzindo o 
tempo de inatividade. 
o Mitigando os riscos associados com a perda de dados em um ambiente em rápida 
recuperação. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 45 
64 
O objetivo é proteger os dados da organização de falhas. A proteção é fornecida através de uma 
ampla gama de sistemas operacionais e aplicativos, rodando em diferentes hardware como 
notebooks e mainframes. A figura abaixo mostra a família de produtos IBM que ajuda a lidar com os 
desafios de gerenciar de armazenamento. 
 
Muito está sendo dito sobre soluções de backup sem fita como a tendência para a proteção de 
dados. Esta não é uma ideia nova. Desde a sua primeira versão, o Tivoli Storage Manager usou disco 
como armazenamento primário para backups, juntamente com fitas. 
Mais frequentemente, como a tecnologia de armazenamento em disco evoluiu, outras soluções 
tornaram-se possíveis, e estão sendo incorporadas ao produto. Desduplicação e instantâneos 
(snapshots) são exemplos de recursos do Tivoli Storage Manager que tiram proveito da arquitetura 
do subsistema de disco. 
No entanto, as fitas não podem ser descartadas. A tecnologia de fita continua a evoluir, aumentando 
a sua velocidade e capacidade. Ela ainda é o dispositivo de armazenamento adequado para muitas 
aplicações e necessidades de negócio. É mais adequada para o backup de grandes arquivos 
sequenciais, como grandes bancos de dados e imagens digitais, e para armazenar dados que 
precisam ser mantidos por um longo período de tempo por requisitos regulamentares. 
TSM é a solução de gerenciamento de armazenamento primária para ambientes de plataforma 
mista. O IBM Tivoli Storage Manager ajuda as empresas a gerenciar e controlar seus dados de 
negócios através da apresentação de um ponto único de controle e administração de backup e 
recuperação de dados. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 46 
64 
Este produto avançado, altamente escalável ajuda a aumentar a eficiência de suas operações de TI 
e a reduzir os custos relacionados com a gestão de armazenamento, fornecendo uma ampla gama 
de proteção ao dados, gerenciamento de recuperação, movimentação, retenção, relatórios e 
capacidades de monitoramento usando a automação baseada em políticas. 
As empresas enfrentam uma onda de informações e dados que parece aumentar diariamente. A 
capacidade de gerir com sucesso e eficiência informações e dados tornou-se imperativo. A família 
de produtos IBM Tivoli Storage Manager ajuda as empresas a obter sucesso com um melhor 
controle e gestão eficiente da informação e ainda com melhorias significativas na proteção dos 
dados. 
O TSM possui várias ferramentas que ajudam a administração do mesmo. Você pode configurar e 
gerenciar o servidor IBM Tivoli Storage Manager através de interfaces web e por assistentes que 
ajudam a guiá-lo através das diversas tarefas de configuração e gerenciamento. Você precisa fazer 
login uma única vez para acessar vários servidores a partir de uma única interface TSM. 
Você pode facilmente monitorar a saúde de seu ambiente de armazenamento, filtrar e classificar os 
objetosde armazenamento, como nós clientes e volumes da biblioteca. Você pode ainda usar os 
assistentes para realizar mais facilmente tarefas complexas, como: 
o Criação de horários para executar nós cliente e operações administrativas. 
o Criação de um script de manutenção do servidor para executar no banco de dados e no 
pool de armazenamento backup, migração e recuperação 
o Configurar dispositivos de armazenamento. Um assistente abrangente ajuda a criar uma 
biblioteca, adicionar unidades, fazer check-in de volumes de mídia, e criar pools de 
armazenamento 
o Configurar o servidor no sistema UNIX local ou remoto, a partir da Versão 6.1. 
o Agendar uma publicação do cliente para diferentes nós em vários domínios 
Outra ferramenta importante é o recurso de monitoramento e relatórios IBM Tivoli Storage Manager 
que pode ser instalado no IBM AIX, Linux, IBM System x® e plataformas Microsoft Windows, mas 
pode monitorar um servidor em execução em qualquer plataforma. 
É possível visualizar os relatórios históricos para determinar se quaisquer problemas ou tendências 
necessitam de atenção, tais como crescimento descontrolado ao longo do tempo. Você também 
pode visualizar os espaços de trabalho que estão sendo monitorados para ver as identificações de 
servidor Tivoli Storage Manager, do tamanho do banco de dados, o status do agente, status do nó 
cliente, eventos agendados, e assim por diante. 
O componente de relatórios, por vezes referido como Tivoli Common Reporting, exibe dados 
históricos recuperados. O IBM Tivoli Monitoring funciona como um aplicativo de monitoramento 
que fornece espaços de trabalho para você acompanhar informações em tempo quase real. 
A questão de integração entre o TSM e a recuperação de desastres pode ser endereçada por meio 
de um painel que define uma solução de proteção de dados e deve ser cuidadosamente concebido 
para cumprir os objetivos de tempo de recuperação (RTO) e objetivos de ponto de recuperação 
(RPO). Estas são as duas peças mais importantes quando você constrói uma solução de proteção de 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 47 
64 
dados pelo fato de revelarem o impacto nos negócios. Veja a tabela abaixo com uma relação entre 
as ferramentas do TSM Toolkit e a solução de recuperação de desastres. 
 
Terminada nossa explanação teórica sobre alta disponibilidade e recuperação de dados no DB2 
vamos passar nosso foco para as ferramentas de monitoramento de eventos. 
 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 48 
64 
MONITORAÇÃO DE EVENTOS 
Um dos principais objetivos de uma organização de TI é assegurar que sua infraestrutura ofereça o 
desempenho necessário para garantir que os objetivos de negócios são sempre satisfeitos, em um 
ambiente de negócios em constante evolução e mutação. 
Isto exige que o profissional de TI adote uma estratégia que é tanto proativa quanto reativa às 
condições e eventos que tendem a afetar negativamente os sistemas de TI. O esforço proativo 
envolve uma série de tarefas, incluindo: 
• Planejamento da capacidade dos recursos de TI. 
• Escolha da arquitetura de TI mais eficaz para a carga de trabalho atual. 
• Adoção das melhores práticas de design da aplicação, desenvolvimento e implantação. 
• Realização de testes de regressão rigorosos antes da implantação em um ambiente de produção. 
• Realizar o monitoramento de rotinas de indicadores-chave de desempenho para evitar possíveis 
problemas de desempenho, bem como reunir informações para planejamento de capacidade. 
O esforço reativo envolve ter uma metodologia bem definida para identificar a causa raiz de um 
problema e resolver o mesmo através da aplicação de melhores práticas existentes. A seguir, nós 
introduzimos o conceito de gestão de desempenho, descrevemos os diferentes tipos de 
monitoramento disponíveis e uma metodologia comum para a determinação efetiva de problemas 
de desempenho nos ambientes DB2. 
A maioria dos ambientes modernos variam desde sistemas independentes a combinações 
complexas de servidores de banco de dados e clientes que executam em múltiplas plataformas. É 
fundamental a todos estes ambientes a obtenção de um desempenho adequado para atender aos 
requisitos de negócios. O desempenho é tipicamente medido em termos de tempo de resposta, 
taxa de transferência e disponibilidade. 
O desempenho de qualquer sistema depende de muitos fatores, incluindo o hardware do sistema e 
configuração de software, número de usuários simultâneos, e a carga de trabalho. 
Observação: A gestão de desempenho é uma questão complexa, e pode ser definida como a 
modificação do sistema e ambiente de aplicação, a fim de satisfazer aos objetivos de 
desempenho previamente definidos. 
Estes objetivos de desempenho devem ser: 
Realistas. Devem ser atingíveis dado o estado atual da tecnologia disponível. Por exemplo, definir 
os tempos de resposta em torno de milissegundos para processar milhões de linhas de dados não é 
possível. 
Razoáveis. Baseado numa tecnologia disponível, os processos de negócio não podem exigir 
demandas de desempenho muito rigorosas. Por exemplo, exigindo tempos de resposta de 
milissegundos para relatórios analíticos que precisam ser estudados e analisados em detalhe antes 
de tomar uma decisão de negócios poderia ser considerado não razoável. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 49 
64 
Quantificáveis. Os objetivos devem usar medidas quantitativas (números, proporções, 
percentagens) em vez de métricas qualitativas (como muito bom, média, etc.). Um exemplo de 
medidas quantitativas que podem ser 95 por cento de um tempo de operação específico deve ter 
tempo de resposta inferior a um segundo, enquanto uma métrica qualitativa pode ser que a 
disponibilidade do sistema deve ser muito alta. 
Mensuráveis. Devemos ser capazes de medir o desempenho, a fim de determinar a conformidade 
ou não-conformidade com os objetivos de desempenho. Unidades de medida incluem o tempo de 
resposta para uma determinada carga de trabalho, transações por segundo, operações I/O, o uso da 
CPU, ou uma combinação das opções acima. 
Importante: Sem objetivos de desempenho bem definidos, medir o desempenho é um 
exercício de hit-or-miss, sem nenhuma maneira de entregar os acordos de nível de serviço que 
são negociados com os usuários. 
Para definir o gerenciamento de performance podemos seguir o ciclo definido na figura abaixo. 
 
A gestão de desempenho é um processo iterativo que envolve o monitoramento constante para 
determinar se os objetivos de desempenho estão sendo cumpridos considerando as mudanças de 
ambientes e cargas de trabalho ao longo do tempo. Quando os objetivos de desempenho não estão 
sendo cumpridos, alterações necessárias devem ser feitas no hardware e/ou no ambiente de 
software, bem como os próprios objetivos de desempenho, a fim de garantir que eles serão 
readequados e cumpridos. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 50 
64 
De perspectiva de banco de dados, problemas de desempenho podem surgir a partir de uma 
combinação de problemas de aplicação e design do sistema; CPU inadequada, memória em disco, e 
recursos de rede; e ajuste não ideal desses recursos. 
Além de usar o monitoramento para determinar se os objetivos de desempenho estão sendo 
atendidos,o monitoramento também é usado para: 
• Avaliar a carga de trabalho atual de um sistema e acompanhar suas mudanças ao 
longo do tempo para fins de planejamento de capacidade. 
• Adotar uma abordagem proativa para o gerenciamento de desempenho por 
prevenir e resolver possíveis problemas que possam impedir a realização dos 
objetivos de desempenho. 
• Reagir a problemas inesperados, auxiliando no diagnóstico de problemas. 
A fim de atender os objetivos de desempenho atuais e futuros, o DBA precisa desenvolver e executar 
uma estratégia de acompanhamento adequada capaz de fornecer a qualidade de serviço requerido. 
Há tipicamente três tipos de monitoração disponíveis para um DBA: a monitorização de rotina, o 
monitoramento de eventos em tempo real/on-line e o monitoramento de exceção. Falaremos sobre 
cada um deles na próxima sessão. 
TIPOS DE MONITORAMENTO 
Falaremos agora sobre os tipos de monitoramento, começando pelo monitoramento de rotina 
MONITORAMENTO DE ROTINA 
Os objetivos deste tipo de monitoramento são: 
• Coletar informações sobre a carga de trabalho e estresse do sistema durante 
períodos normais e de pico para fins de planejamento de capacidade, bem como 
identificar possíveis problemas de desempenho. 
• Verificar a conformidade do sistema com os objetivos de desempenho, e registrar 
os desvios se houver. 
A chave para esse tipo de monitoramento é que ele envolve a análise das informações coletadas ao 
longo de um período e toma medidas corretivas, se necessário, para alcançar os objetivos de 
desempenho. Em outras palavras, pode haver um atraso significativo entre o recebimento das 
informações e uma resposta corretiva. 
Um exemplo dos resultados de tal monitorização é uma percepção de que o número de transações 
cresce de forma constante a uma taxa de 1 por cento a cada semana, o que irá exigir uma atualização 
do servidor em 12 meses, a fim de continuar a satisfazer os objetivos de tempo de resposta. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 51 
64 
Outra característica dessa monitoração é que a necessidade de minimizar a sobrecarga introduz uma 
exigência para que seja executado permanentemente ou apenas durante períodos de pico. 
Em algumas referências da literatura, esse tipo de monitoramento é subdividido em monitoramento 
contínuo (para cargas normais) e acompanhamento periódico (para cargas de pico). De uma 
perspectiva do DB2, o monitoramento de rotina pode ajudar a identificar as causas de potenciais 
problemas de desempenho, tais como: 
• Tamanho do buffer pool 
• Tamanho do cache dinâmico de SQL 
• Tamanho do heap 
• Tamanho do locklist e maxlocks 
• Concorrência entre aplicações e questões de isolamento 
• Tabelas desorganizadas 
• Dados estatísticos desatualizados 
• Comandos SQL com execuções muito demoradas 
MONITORAMENTO DE EVENTOS EM TEMPO REAL/ON-LINE 
O objetivo deste tipo de monitoramento é procurar por determinados eventos que podem 
identificar um problema específico, ou prever problemas num futuro próximo, a fim de tomar 
medidas corretivas imediatas. Futuro próximo é contabilizado em minutos ou poucas horas. 
A chave para esse tipo de monitoramento é que ele envolve olhar para eventos específicos em um 
curto intervalo de tempo que são conhecidos por prejudicar o desempenho e ter a opção de tomar 
medidas corretivas imediatas para corrigir o problema. 
Em outras palavras, provavelmente precisamos de atraso um muito pequeno entre a coleta de 
informações e uma resposta corretiva. Um exemplo deste tipo de evento é a ocorrência de um 
número excessivo de impasses ou deadlocks em um curto período de tempo, que precisam ser 
tratados imediatamente, para garantir que os objetivos de negócio não sejam comprometidos. 
Aqui, também, a necessidade de minimizar a sobrecarga causada pela monitorização é crítica, dado 
que a maioria dos problemas se manifestam em cargas de pico. 
De uma perspectiva do DB2, o monitoramento de eventos em tempo real/ online pode ajudar a 
identificar problemas potenciais de desempenho, tais como: 
• Impasses (Deadlocks) 
• Tempos de espera longos e tempo outs 
• Consultas SQL de longa duração 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 52 
64 
MONITORAMENTO DE EXCEÇÕES 
Este tipo de monitoramento é necessário quando você descobriu ou suspeita de um problema e 
precisa identificar a causa do problema, a fim de aplicar as medidas corretivas adequadas para 
corrigi-lo. 
Ao contrário do monitoramento de rotina e de eventos, que estão previstas ocorrências e são 
projetados para ter uma sobrecarga baixa sobre o sistema de gestão, o monitoramento de exceções 
é impulsionado por situações-problema e pode impor sobrecargas significativas no sistema 
gerenciado. 
Um exemplo de uma necessidade de monitoramento de exceção é quando o administrador recebe 
um número significativo de reclamações dos usuários sobre os tempos de resposta degradados, ou 
incapacidade de acessar um aplicativo. 
O administrador, então, precisa iniciar uma série de ações de monitoramento para achar indícios 
sobre a causa raiz do problema. Isso geralmente envolve trabalhar com um conjunto de hipóteses 
que poderiam explicar o comportamento percebido, e, em seguida, verificar sistematicamente um 
de cada vez até que o problema seja diagnosticado. 
Do ponto de vista do DB2, o monitoramento de exceção pode ser aplicado a qualquer um dos itens 
identificados através de monitoramento de eventos ou de tempo real/online. 
Percebam que a ideia aqui é o monitoramento de diferentes tipos de situações que podem impactar 
o desempenho sobre o banco de dados. A IBM oferece um conjunto de ferramentas que podem 
contribuis para a correta execução das tarefas de monitoramento. Passaremos na próxima sessão 
ao tratamento específico de uma dessas ferramentas. Espero que você esteja acompanhando o 
conteúdo até o momento. 
 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 53 
64 
QUESTÕES COMENTADAS 
Apresentaremos abaixo algumas questões de concursos anteriores e outras questões de minha 
autoria que vão ajudar você a compreender melhor o assunto. 
 
1. BANCA: CESPE CONCURSO: TJDFT ANO: 2015 ÓRGÃO: TJDFT PROVA: 
SUPORTE DE TI 
A respeito da configuração e da administração de sistemas gerenciadores de 
bancos de dados (SGBD) e de produtos a eles relacionados, julgue os itens a 
seguir. 
84 A ocorrência de falha em uma instância do DB2 pureScale exige a 
interferência do administrador do banco de dados para que os recursos sejam 
reiniciados, devendo a forma de notificação da falha ser configurada pelo 
administrador. 
Comentário: O DB2 pureScale do DB2 é uma tecnologia que trabalha em um 
ambiente de cluster e usa uma arquitetura de compartilhamento de dados. Esta 
arquitetura é ideal para escalabilidade e principalmente apropriada para o 
processamento de transações. Neste ambiente, os dados que estão sendo 
acessado são compartilhados por todos os servidores no cluster. 
Se houver uma falha em um dos servidores (instâncias), ou se ele necessita ficar 
off-line para fins de manutenção, o restante dos membros que continuam on-
line no cluster assumem o trabalho, proporcionando assim uma alta 
disponibilidade transparente para os dados. Serviços de cluster do DB2 são 
usados para agrupar os componentes integrados em serviços de cluster que são 
usados para monitorar e automatizar a recuperação de falhas no sistema. Vejam 
que a alternativa se apresenta incorreta, pois aarquitetura, após configurada, 
exige o mínimo de trabalho do BDA. Vejam também que os recursos 
permanecem no ar, mesmo com uma falha em uma instância. 
Gabarito: E 
 
 
2. BANCA: TRC CONCURSO: TJDFT ANO: 2015 ÓRGÃO: TJDFT PROVA: 
SUPORTE DE TI 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 54 
64 
A respeito da configuração e da administração de sistemas gerenciadores de 
bancos de dados (SGBD) e de produtos a eles relacionados, julgue os itens a 
seguir. 
85 Na instalação do DB2 PureScale em Linux, se um usuário existente for 
selecionado como proprietário de instância do DB2, ele deverá existir com o 
mesmo UID em todos os hosts. 
Comentário: Um ambiente do DB2 pureScale requer um ID do usuário para o 
proprietário da instância, um ID de usuário não raiz para usar um protocolo de 
rede de shell seguro (SSH) entre hosts, e outro para executar funções ou 
procedimentos definidos pelo usuário protegido. Se você usar o assistente de 
Configuração do DB2 para instalar o DB2 pureScale Feature, os usuários 
necessários serão criados como parte da instalação. Caso contrário, você deverá 
criar os usuários manualmente. Estes usuários são necessários em todos os 
servidores que hospedam um recurso de armazenamento em cache do cluster 
ou membro. Cada usuário deve ser configurado para ter as mesmas 
configurações de usuário e senha que o mesmo usuário em todos os outros 
servidores. 
Para usar usuários existentes, ambos os usuários devem existir em 
todos os hosts com o mesmo ID do usuário (UID), ID do grupo ID (GID) 
e diretório HOME antes da instalação. Questão tirada da documentação, 
muito específica! Mas está correta. 
Gabarito: C 
 
 
3. BANCA: FCC ANO 2010 ÓRGÃO: TCE-SP PROVA: AGENTE DA 
FISCALIZAÇÃO FINANCEIRA - PRODUÇÃO E BANCO DE DADOS 
Alguns SGBDs (como, por exemplo, o DB2) possuem uma opção adicional sobre 
as restrições de chave estrangeira, onde as linhas da tabela referenciada são 
excluídas (delete) ou atualizadas (update) somente se não houver valores de 
chaves estrangeiras correspondentes. Trata-se de 
(A) commited. 
(B) restricted. 
(C) revoked. 
(D) rollup. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 55 
64 
(E) rollback. 
Comentário: A questão aparece na aula pois no seu enunciado consta a palavra-
chave DB2. Percebam, porém, que se trata de uma questão na qual é verificado 
seu conhecimento sobre a sintaxe de SQL. Sabemos que a integridade referencial 
trada do fato dos valores das chaves estrangeiras para serem válidos precisam 
estar presentes na tabela referenciada. O valor pode ser nulo ou um dos valores 
presentes na coluna referenciada. 
Na execução de operações de UPDATE ou DELETE que interferem nos valores da 
chave estrangeira na tabela pai deve-se tomar alguma ação na tabela filho para 
manter a integridade. Essa ação é especificada na definição da restrição de 
integridade. Suponha que a chave estrangeira foi definida como RESTRICT, se 
um comando tenta executar uma atualização no valora da chave na tabela pai, 
essa operação é rejeitada pelo SGBD. 
Outra opção seria a utilização do CASCADE, neste caso a atualização feita na 
tabela pai seria replicada na tabela filho. 
Gabarito: B 
 
4. BANCA: FCC ANO: 2004 ÓRGÃO: TRT - 2ª REGIÃO (SP) PROVA: 
ANALISTA JUDICIÁRIO - TECNOLOGIA DA INFORMAÇÃO 
Uma tabela do banco de dados DB2 pode ser deletada com o comando 
(A) close tablespace. 
(B) clean table. 
(C) drop table. 
(D) delete table. 
(E) alter tablespace. 
Comentário: Essa questão mostra, mais uma vez, que existe uma relação direta 
entre o padrão SQL/ANSI e as linguagens de banco de dados comerciais. A 
questão pede para que você demonstre o conhecimento sobre o comando 
utilizado para deletar uma tabela. Vejam que se trata do comando DDL DROP. 
Gabarito: C 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 56 
64 
 
5. BANCA: CESPE ÓRGÃO: BACEN PROVA: ANALISTA DO BACEN - 
SUPORTE À INFRAESTRUTURA DE TECNOLOGIA DA INFORMAÇÃO 
A respeito da utilização da interface de conexão, distribuição de dados e 
replicação, julgue os itens seguintes. 
[1] Um sistema federado do DB2 é um tipo especial de sistema de gerenciamento 
de banco de dados distribuído. Com um sistema federado, é possível distribuir 
pedidos para várias fontes de dados em uma única instrução SQL. 
Comentário: Quando pensamos em consultas SQL em um sistema federado, 
podemos pensar em tabelas que estão em bancos de dados distintos, mas que 
fazem parte do mesmo modelo. Imaginem que a tabela FUNCIONÁRIO esteja 
em uma base de dados e remuneração em outra. Nesta situação uma consulta 
que faça um join entre essas tabelas pode ser executa parcialmente nos dois 
servidores que contêm cada um dos bancos. 
O DB2 permite esse tipo de federação e distribuição em seus bancos de dados. 
Sendo plenamente possível que uma consulta seja processada sobre diferentes 
fontes de dados. 
Gabarito: C 
 
6. BANCA: CESPE ÓRGÃO: BACEN PROVA: ANALISTA DO BACEN - 
SUPORTE À INFRAESTRUTURA DE TECNOLOGIA DA INFORMAÇÃO 
A respeito da utilização da interface de conexão, distribuição de dados e 
replicação, julgue os itens seguintes. 
[1] A IBM oferece a solução de conectividade via JDBC, que concede 
conectividade para banco de dados mainframe e midrange a partir de 
plataformas Windows e plataformas baseadas em Unix para suporte a qualquer 
linguagem. É possível também se conectar com banco de dados não-IBM que 
estão de acordo com Distributed Relational Database Architecture (DRDA). 
Comentário: Falamos um pouco na segunda aula de DB2 sobre o DB2 Connect. 
O DB2 Connect concede conectividade para bancos de dados mainframe e 
midrange a partir de plataformas Windows e baseadas em UNIX. Você pode se 
conectar ao banco de dados DB2 no OS/390 e z/OS, iSeries, VSE e VM. É possível 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 57 
64 
também se conectar com bancos de dados não-IBM que estão de acordo com 
Distributed Relational Database Architecture (DRDA). 
O texto acima é o primeiro parágrafo do documento da IBM sobre o DB2 Connect. 
Observem que o examinador trocou a palavra DB2 Connect por JDBC, que é um 
conjunto de classes e interfaces (API) escritas em Java que fazem o envio de 
instruções SQL para qualquer banco de dados relacional. Desta forma, a 
alternativa está errada. 
Gabarito: E 
 
7. BANCA: CESPE ÓRGÃO: BACEN PROVA: ANALISTA DO BACEN - 
SUPORTE À INFRAESTRUTURA DE TECNOLOGIA DA INFORMAÇÃO 
Julgue o item subsequente acerca do IBM DB2 v10. 
[1] Para instalar servidores de banco de dados DB2, é necessário reservar um 
espaço de paginação dependente do sistema operacional onde ocorrerá a 
instalação. Nos sistemas operacionais Solaris e AIX, entretanto, não é necessário 
reservar esse espaço, pois eles estão preparados para criá-los automaticamente. 
Comentário: Essa questão trata de detalhes da instalação do DB2. O DB2 requer 
que a paginação, também chamada de troca, seja ativada. Essa configuração é 
necessária para suportar várias funções no DB2 que monitoram ou dependem 
do conhecimento da utilização de espaço de troca/paginação. A quantidade real 
de espaço de troca/paginação necessária varia nos sistemas e é baseada 
exclusivamente na utilização de memória por partedo software de aplicativo. Ela 
só é estritamente necessária para o DB2 em plataformas Solaris e HP devido 
ao seu uso de alocação de espaço de paginação antecipado. Desta forma, 
observamos que a alternativa está incorreta. 
Para saber um pouco mais sobre pré-requisitos de memória e disco do BD2 10.5, 
veja aqui. 
Gabarito: E 
 
8. Banca: FGV Ano: 2010 Órgão: BADESC Prova: Analista de Sistemas 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 58 
64 
No SGBD DB2, com relação ao armazenamento de informações do tipo textos 
grandes, textos binários grandes ou arquivos, etc., analise as afirmativas a 
seguir. 
I. Tem o tipo de dado denominado de Large Object. 
II. Estes tipos de dados podem ser BLOB, CLOB e DBCLOB. 
III. O SGBD DB2 não permite o armazenamento de tipos de dados para estas 
informações. 
Assinale: 
(a) se somente a afirmativa I estiver correta. 
(b) se somente a afirmativa II estiver correta. 
(c) se somente a afirmativa III estiver correta. 
(d) se somente as afirmativas I e II estiverem corretas. 
(e) se todas as afirmativas estiverem corretas. 
Comentário. No DB2, você pode usar tipos de dados de objeto grandes para 
armazenar áudio, vídeo, imagens e outros arquivos que são maiores do que 
32KB. O BD2 prover três tipos de dados para armazenar esses tipos de objetos: 
Character large objects (CLOBs), Double-byte character large objects (DBCLOBs) 
e Binary large objects (BLOBs). Desta forma podemos marcar a alternativa D 
como nossa resposta. Para mais informações sobre os tipos de dados para 
grandes objetos clique aqui. 
Gabarito: D 
 
 
9. BANCA: TRC CONCURSO ANO: 2016 ÓRGÃO: INDEFINIDO PROVA: 
NÍVEL SUPERIOR - ANALISTA DE SISTEMAS 
Com relação ao DB2 pureScale julgue o item abaixo: 
O sistema pureScale DB2 é executado em até 128 múltiplos hosts que acessam 
dados compartilhados simultaneamente, sem a necessidade de modificar 
explicitamente a aplicação. Você pode usar essa transparência para realizar 
operações de manutenção em hosts, adicionar hosts, ou remover servidores 
desnecessários sem afetar o funcionamento da aplicação. Com este método, 
você pode controlar o número de hosts ativos para lidar com a carga de trabalho 
e para garantir que você permanecer na taxa de transação desejada. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 59 
64 
Comentário. Falamos da característica de transparência e da quantidade 
máxima de membros que podem ser levantados em paralelo pelo recurso do DB2 
pureScale. Veja, portanto, que a alternativa está correta. 
Gabarito C 
 
10. BANCA: TRC CONCURSO ANO: 2016 ÓRGÃO: INDEFINIDO PROVA: 
NÍVEL SUPERIOR - ANALISTA DE SISTEMAS 
Com relação ao DB2 pureScale julgue o item abaixo: 
O armazenamento compartilhado (shared storage) é uma unidade de 
armazenamento que está conectada a todos os membros, mas não aos CFs 
(cluster caching facility) do cluster DB2, para permitir a todos os dados sejam 
compartilhados e utilizados simultaneamente. 
Comentário. Vimos que tanto os membros quanto os CFs estão conectados ao 
armazenamento compartilhado. Sendo assim, alternativa encontra-se incorreta. 
Gabarito E 
 
 
11. BANCA: TRC CONCURSO ANO: 2017 ÓRGÃO: INDEFINIDO PROVA: 
NÍVEL SUPERIOR - ANALISTA DE SISTEMAS 
Serviços de cluster do DB2 são usados para agrupar os componentes integrados 
em serviços de cluster que são usados para monitorar e automatizar a 
recuperação de falhas no sistema. Estes serviços têm daemons que são 
executados em cada um dos hosts, no entanto, as decisões são tomadas em 
grupo. Você deve ter hosts suficientes se comunicando nestes grupos para 
decidir quais ações devem ser tomadas. Qual dos componentes abaixo não 
compõem os serviços de cluster do DB2: 
(A) IBM Reliable Scalable Cluster Technology (RSCT) 
(B) IBM Tivoli® System Automation for Multi-platforms 
(C) IBM General Parallel File System (GPFS™) 
(D) Remote Direct Memory Access (RDMA) 
(E) IBM DB2 High Availability Disaster Recovery (HADR) 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 60 
64 
Comentário. O recurso de HADR fornece uma solução de alta disponibilidade 
para falhas parciais e completas. O HADR protege contra a perda de dados, 
replicando alterações de dados de uma fonte ou o servidor primário, em um ou 
mais servidores de espera. O DB2 HADR suporta até três servidores remotos de 
espera e está disponível em todas as edições do DB2 excluindo DB2 Express-C. 
As demais alternativas foram vistas e explicadas durante a aula, apenas 
reforçando e tentando inserir mais algum detalhe, vamos explicar novamente 
abaixo: 
(A) IBM Reliable Scalable Cluster Technology (RSCT) é um conjunto de 
componentes de software que ajudam a fornecer monitoramento de cluster do 
ambiente. Estes processos são responsáveis por monitorar o “batimento 
cardíaco” em cada um dos hosts e proporcionar uma camada que é utilizada para 
a comunicação segura entre eles. Além disso, fornece os mecanismos de barrira 
que são chamados pelo DB2 quando um host falha, e são usados para notificar 
os processos do DB2 quando condições específicas ocorrem. 
(B) IBM Tivoli® System Automation para Multi-platforms oferece detecção rápida 
de paralisações e monitores de disponibilidade dentro do cluster DB2. É a camada 
utilizada pelo DB2 para definir quais ações devem ser tomadas após falhas 
específicas. Ao integrar um sistema de detecção e recuperação automatizado, o 
componente reduz o monitoramento manual do cluster DB2 pureScale para 
garantir que tudo está online e continua funcionado se espera. Ao mesmo tempo, 
ele fornece mais tempo para você se concentrar em seu negócio, em vez do 
próprio banco de dados. 
(C) IBM General Parallel File System (GPFS™) fornece um coerente sistema de 
arquivos compartilhado com cache. Em suma, ele fornece a gestão dos sistemas 
de arquivos que o DB2 usa para armazenar seus dados e logs. Com o recurso 
DB2 pureScale, todos os dados e logs devem ser armazenados no GPFS, de modo 
que possam ser compartilhados entre os membros para fins de recuperação. 
Debaixo do GPFS estão os subsistemas de armazenamento, que podem ser tanto 
o armazenamento SAN-attached ou fibre attached. 
(D) Remote Direct Memory Access (RDMA) é a interconexão de hardware que 
fornece a capacidade de usar o bloqueio centralizado e os algoritmos de buffer 
cache usados pelo cluster CF. 
OK! Após essa rápida revisão vamos para a próxima questão! 
Gabarito E 
 
 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 61 
64 
12. BANCA: TRC CONCURSO ANO: 2018 ÓRGÃO: INDEFINIDO PROVA: 
NÍVEL SUPERIOR - ANALISTA DE SISTEMAS 
Com relação ao DB2 pureScale julgue o item abaixo: 
RDMA permite que cada membro do cluster acesse diretamente a memória no 
CF e que o CF acesse diretamente a memória de cada membro. Esta configuração 
permite o acesso mais rápido a verificação de bloqueios e recuperação de página 
de dados, aumentando o desempenho das consultas. Esta tecnologia é baseada 
em um dos dois tipos diferentes de interfaces de rede: InfiniBand e 10 GbE. 
Comentário. São exatamente essas duas interfaces de rede que podem ser 
utilizadas pelo RDMA. InfiniBand, que, ainda é a de menor latência de rede e 
mais rápida que suporta RDMA através da interface de programação de aplicativouDAPL. 10 GbE, que suporta RDMA sobre protocolos Ethernet convergentes 
(também conhecidos como o RoCE). 
Gabarito C 
 
13. BANCA: TRC CONCURSO ANO: 2018 ÓRGÃO: INDEFINIDO PROVA: 
NÍVEL SUPERIOR - ANALISTA DE SISTEMAS 
Com relação ao DB2 pureScale julgue o item abaixo: 
O recurso DB2 pureScale foi inicialmente disponível e comercializado por conta 
própria, como uma versão separada chamada DB2 9.8. A partir do DB2 10.1, 
esta funcionalidade está incorporada no código base do DB2 e é agora uma 
funcionalidade incluída nos releases normais do DB2. 
Gabarito C. Essa é uma questão que minha intuição diz que pode cair. É 
decoreba básico, saber que o pureScale se transformou em uma funcionalidade 
do DB2 na versão 10.1. 
 
14. BANCA: TRC CONCURSO ANO: 2018 ÓRGÃO: INDEFINIDO PROVA: 
NÍVEL SUPERIOR - ANALISTA DE SISTEMAS 
Com relação ao alta disponibilidade e recuperação de desastres julgue os itens 
abaixo: 
[1] A recuperação de desastres é a capacidade de um sistema continuar a 
trabalhar independentemente de falhas que ocorrem com o sistema, até certo 
ponto. Em todos os sistemas deste tipo, há um ponto no qual as falhas 
conseguem tornar o sistema inutilizável, e um plano de recuperação de desastres 
deve ser posto em prática e executar naquele momento. 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 62 
64 
[2] Alta disponibilidade é o plano de contingência quando o cluster primário 
falhar ao ponto em que ele não pode ser trazido de volta online. Este desastre 
pode ser tão simples como uma falha no site por causa de um incêndio edifício 
ou desastre natural. O plano de contingência pode ser outro banco de dados em 
um local diferente, quer a poucos quilómetros de distância ou muitos quilômetros 
de distância em outra província ou país. 
Comentário. Observem que os conceitos estão trocados. Basta substituir 
recuperação de desastres por alta disponibilidade na alternativa 1, e alta 
disponibilidade por recuperação de desastres na alternativa 2 que ambas 
ficariam corretas. 
Gabarito: E E. 
 
15. BANCA: TRC CONCURSO ANO: 2018 ÓRGÃO: INDEFINIDO PROVA: 
NÍVEL SUPERIOR - ANALISTA DE SISTEMAS 
Com relação ao DB2 pureScale julgue o item abaixo: 
Para consultar o estado geral de um cluster, execute db2instance -list, que 
retorna uma saída semelhante à mostrada abaixo. 
 
Comentário. A saída se configura como um resultado possível ao comando em 
questão, portanto, alternativa correta. 
Gabarito C 
 
16. BANCA: TRC CONCURSO ANO: 2018 ÓRGÃO: INDEFINIDO PROVA: 
NÍVEL SUPERIOR - ANALISTA DE SISTEMAS 
Com relação ao DB2 pureScale julgue o item abaixo: 
No núcleo do cluster do DB2 pureScale estão os seguintes componentes de 
hardware: Os servidores rodam o software DB2 pureScale; o subsistema de 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 63 
64 
armazenamento contém a base de dados e todos os seus componentes 
relacionados; e a rede de comunicação entre os clientes, servidores, FC e 
membros. 
Comentário. Esses são os principais componentes de hardware presentes na 
arquitetura. Servidores que rodam sistemas operacionais Linux são servidores 
os System X da IBM, enquanto os sistemas IBM AIX são todos baseados em 
servidores POWER. Assim, em algumas organizações, o servidor que você usa é 
determinado pelo seu sistema operacional (AIX ou Linux). 
Você deve usar a mesma plataforma para todos os servidores. Por exemplo, você 
não pode ter membros em System X e FCs sistema POWER. Além disso, é uma 
prática preferida manter os tipos de processadores entre os membros e entre os 
FCs. Se você usar diferentes tipos de processador, você deve levar em conta as 
diferenças de capacidade de processamento entre os processadores ao 
determinar quantos núcleos são necessários. 
Gabarito C 
 
17. BANCA: TRC CONCURSO ANO: 2016 ÓRGÃO: INDEFINIDO PROVA: 
NÍVEL SUPERIOR - ANALISTA DE SISTEMAS 
Com relação ao DB2 pureScale julgue o item abaixo: 
Os membros DB2 são responsáveis pela manipulação das cargas de trabalho 
de banco de dados em geral. As facilidades de cache do cluster DB2 (CFS) 
são responsáveis pela gestão de bloqueio e cache global. O armazenamento 
compartilhado (shared storage) permite que você acesse os dados a partir 
de vários servidores simultaneamente. 
Comentário. Está questão é um resumo dos principais componentes da 
arquitetura do DB2 pureScale. Fixar os nomes e as responsabilidades de cada 
um pode ser importante, pelo menos para a sua prova! ☺ 
A configuração mínima recomendada em um ambiente DB2 pureScale é de dois 
membros DB2, dois CFs de cluster e um único subsistema de armazenamento 
compartilhado. Compreender a configuração básica pode ajudar a compreender 
as opções de configuração que estão disponíveis e as considerações de hardware 
para garantir uma implantação bem-sucedida de cluster que se adéque à sua 
carga de trabalho. 
Gabarito C 
 
 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br
 
 
 
 
 
 
 
 
 
 64 
64 
CONSIDERAÇÕES FINAIS 
Chegamos, pois, ao final da nossa aula sobre alta disponibilidade e monitoração 
de eventos no DB2! 
Esperamos que você tenha conseguido fixar todo o conteúdo. Sabemos que é 
um assunto que foi muito pouco cobrado em provas anteriores e não temos 
muitas referências de questões sobre o tema. Contudo, pelo conteúdo 
apresentado, você está preparado para acertar a grande maioria das questões 
deste assunto na hora da prova! 
Espero que tenha gostado! 
Forte abraço e bons estudos, 
 
REFERÊNCIAS 
1. High Availability and Disaster Recovery Options for DB2 for Linux, UNIX, 
and Windows - October 2012 – Bartkowski, Stanislaw, et al. - disponível 
em http://www.redbooks.ibm.com/redbooks/pdfs/sg247363.pdf 
2. IBM Tivoli Storage Manager as a Data Protection Solution - August 2014 – 
Lovelace, Mary, et al – disponível em 
http://www.redbooks.ibm.com/redbooks/pdfs/sg248134.pdf 
3. DB2 II: Performance Monitoring, Tuning and Capacity Planning Guide – 
Novembro 2004 – Alur, Nagraj, et al. 
4. IBM Optim Performance Manager for DB2 for Linux, UNIX, and Windows – 
Fevereiro – 2011 – Chen, Whei-Jen, et al 
 
 
 
 
Thiago Rodrigues Cavalcanti, Equipe de TI do Estratégia Concursos
Aula 10
69360
Banco de Dados e Colaboração Mensageira p/ BRB (Analista TI) Com Videoaulas - Pós-Edital
www.estrategiaconcursos.com.br