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 
banco