Este artigo destaca dois recursos-chave do DB2 AESE:

• Replicação Q fornece alta disponibilidade de sistema por meio de replicação ativa/ativa entre um par de servidores de dados DB2 para LUW.
• Federação fornece acesso transparente a dados a partir de diferentes bancos de dados para ajudar a simplificar a integração de dados para clientes usando DB2 e outras tecnologias de banco de dados em um ambiente misto. AESE inclui federação de bancos de dados Oracle à federação integrada do DB2 para bancos de dados DB2 e Informix®.

Visão rápida do DB2 Advanced Enterprise Server Edition

DB2 AESE inclui, sem custo adicional os seguintes recursos e benefícios:

• Recurso de otimização de armazenamento (compressão) reduz custos de armazenamento.
• O IBM Optim™ Performance Manager ajuda a identificar problemas antes que eles afetem os negócios.
• Q Replication permite migração de versão para versão contínua e topologias ativas/ativas de alta disponibilidade (limitado a um par de banco de dados DB2 para LUW).
• Advanced Access Control permite maior controle sobre quem pode acessar os dados.
• IBM Optim Database Administrator ajuda a economizar tempo e reduzir erros na administração de banco de dados.
• IBM Optim Development Studio ajuda a acelerar o desenvolvimento e melhorar a colaboração entre equipes.
• IBM InfoSphere® Federation Server permite integração entre aplicativos em tempo real (limitado a federação de DB2, Informix e Oracle).
• IBM DB2 Workload Manager alinha alocação de recursos com prioridade de negócios.

Disponibilidade contínua entregue por meio de Q Replication

A tecnologia de Q Replication do DB2 AESE pode replicar transações entre bancos de dados com baixa latência com rendimentos muito altos e por distâncias praticamente ilimitadas de tabelas do DB2, ao mesmo tempo preservando integridade transacional e tolerando indisponibilidades do sistema e da rede. Como exemplo, pode ser possível conseguir um rendimento de milhões de alterações por minuto com latência de menos de um segundo.

No DB2 AESE, esse recurso é entregue por meio do uso restrito do recurso de replicação homogênea da IBM para DB2, permitindo replicação ativa/ativa entre um par de bancos de dados DB2 para LUW para maximizar o uso de recursos de servidor, reduzir custos e oferecer disponibilidade em diversos sites. Se for necessário um cenário de replicação mais flexível (por exemplo, replicação com um servidor Oracle), a versão completa do InfoSphere Replication Service pode ser comprada.

A Q Replication de dois sites do DB2 AESE é ideal para soluções de disponibilidade contínua em diversos sites, como bancos de dados ativos/ativos. Cada banco de dados está ativo, permitindo distribuição da carga de trabalho. Bancos de dados podem ser configurados diferentemente e residir em diferentes tipos de hardware e versões de software, permitindo failover imediato durante indisponibilidades, e eliminando tempo de inatividade durante manutenção, atualizações e migrações. Replicação pode ser multidirecional e gerenciar alterações de banco de dados em conflito. E se a empresa estiver usando o recurso IBM pureScale® do DB2 Enterprise Server, a Q Replication pode ser usada de modo integrado para valor adicional.

Os componentes da Q Replication incluem:

• Um programa Q Capture e um Q Apply para cada direção
• Um gerenciador de fila WebSphere® MQ por sistema (uma cópia restrita do WebSphere MQ é incluída no AESE).
• Tabelas de controle de replicação são criadas no DB2 para conter a configuração de Q Replication e informações operacionais.

Alterações capturadas são paradas e entregues via WebSphere MQ, que permite mover dados para fora do DB2 rapidamente, mesmo que o banco de dados de destino esteja inativo. Cada transação de banco de dados capturada é publicada em uma mensagem MQ. O processo de Q Replication é ilustrado abaixo.

Para ilustrar um processo de replicação ativo/ativo, considere o cenário simplificado aqui:

• Aplicativos de atualização são designados para o site primário, com aplicativos somente leitura designados para os sites de espera. Lembre-se de que Q Replication também funciona com ambos os sites ativos para atualizações.
• Programas de captura e aplicação de log estão em execução em ambos os sites, mas, neste cenário simplificado, dados são replicados apenas em uma direção — de primário para espera.
• Uma conexão failover é configurada para alternância automática de aplicativos de atualização de primário para espera.

Quando uma indisponibilidade ocorre, os aplicativos alternam automaticamente para o site de espera, mas um processo manual está disponível, se desejar. Para evitar conflitos, é melhor deixar que a replicação conclua o processamento de qualquer dado antes de permitir que aplicativos de atualização comecem no site de espera. A replicação começa a enfileirar dados alterados para retorno do site primário logo que os aplicativos atualizados cheguem ao sistema de espera.

Quando o site primário retorna, aplicativos de atualização ficam onde estão até que o potencial para conflitos seja resolvido. Primeiro, o programa de captura é iniciado no primário para capturar qualquer dado alterado que tenha sido isolado lá quando o primário ficou inativo. Essa é uma oportunidade para ver se há conflitos, pois mudanças antigas no primário podem não se encaixar com novas mudanças no de espera. Quando a replicação detecta um conflito, o SQL do conflito é registrado em uma tabela. Um relatório pode ser gerado para verificar se há problemas importantes. Escolher a opção que evita que a replicação seja aplicada a dados em conflito na tabela de espera evita que dados novos (considerando que são melhores) sejam sobrescritos por dados mais antigos.

Quando os dados isolados são replicados, os dados de espera podem ser enviados ao primário iniciando o programa Apply no sistema primário. Assim os dados de espera fluem para o primário. Se houve anteriormente um conflito entre os dados antigos do primário e os dados novos do site de espera, a opção selecionada permite que os dados antigos sejam sobrescritos pelos novos, mas é registrada para revisão. Aplicativos podem ser movidos de volta para o primário, mas é melhor esperar que o programa Apply conclua a lista não processada do site de espera antes. Após isso, o sistema fica novamente como o cenário original.

Além dos recursos flexíveis e eficientes de Q Replication fornecidos pelo DB2 AESE, vários relatórios e ferramentas estão disponíveis para torná-lo ainda mais efetivo. Primeiro, um resumo do funcionamento do Q Replication Dashboard, que oferece visualizações globais de produção e visualizações agregadas do funcionamento e status de programas, filas, assinatura e topologia. Detalhes de drill down estão disponíveis por trás do status, bem como acesso a dados históricos. Também estão disponíveis no painel suporte para alertas, operações e funções de usuário para controle de acesso.

A seguir está um relatório de amostra da tendência histórica da latência de ponta a ponta dos dados de um sistema de destino, o que ajuda a verificar a conformidade com SLA e a rastrear aumentos inesperados na latência.

Finalmente, Q Replication Performance Advisor ajuda a identificar problemas com o ambiente de replicação e sugere maneiras de diminuir a latência de ponta a ponta.

Integrando bancos de dados Oracle com DB2 por meio de federação

Está incluída no AESE para LUW uma cópia restrita do IBM InfoSphere Federation Server, que fornece integração fácil de bancos de dados Oracle, Informix e DB2 em uma empresa e a capacidade de consultar esses dados que residem em diversos bancos de dados com uma única instrução SQL. InfoSphere Replication Server (comprado separadamente) é necessário para usar Q Replication com bancos de dados Oracle.

A federação de origens de dados diversas em um sistema integrado oferece:

• Transparência — A capacidade de criar código e usar aplicativos como se os dados residissem em um único banco de dados. Isso permite que aplicativos continuem funcionando a despeito de qualquer mudança na maneira como os dados são armazenados.
• Heterogeneidade — A capacidade de acomodar diferentes requisitos de dados e origens na empresa.
• Autonomia — A ausência de restrições que são aplicadas na origem de dados remota, o que permite que permaneça autônoma e elimina qualquer interrupção em origens de dados, aplicativos e sistemas.
• Alta função — A capacidade de aplicativos de explorar não só o alto grau de função oferecido pelo sistema federado mas também as funções especiais exclusivas de algumas das origens de dados.
• Extensibilidade e abertura — A flexibilidade de incluir de forma integrada uma nova origem de dados ao sistema corporativo de informações.
• Desempenho otimizado — O poder de aplicativos desenvolvidos para o sistema federado de obter desempenho sólido sem precisar implementar estratégias especiais para avaliar consultas.

O núcleo do sistema federado consiste em uma instância do DB2 que opera como um servidor federado. Componentes incluem um banco de dados do DB2 que funciona como o banco de dados federado, uma ou mais origens de dados tais como Oracle ou outro banco de dados DB2, e clientes (usuários e aplicativos) que acessam os dados por meio do banco de dados federado. Com um banco de dados federado, é possível usar uma única instrução SQL que junta dados de diversas origens, incluindo do próprio banco de dados federado.

Após registrar as tabelas de uma origem de dados no banco de dados federado, é possível referenciá-las facilmente, da mesma maneira que se referencia tabelas locais. Aplicativos se comunicam com o servidor federado por meio de qualquer interface de programação suportada pelo DB2. Como um sistema federado inclui um banco de dados do DB2, é possível também armazenar dados locais, bem como combinar informações de tabelas locais e remotas.

Os conceitos básicos de um sistema federado IBM são exibidos abaixo.

Para transformar o DB2 AESE em um servidor de banco de dados federado, é preciso alterar a configuração do gerenciador de banco de dados da instância do DB2 (configurar Federated como Yes) e configurá-lo para se comunicar com as origens de dados.

• O servidor federado se comunica com as origens de dados por meio de módulos de software chamados wrappers. Esses wrappers oferecem a lógica para facilitar registro de objeto federado e comunicação com a origem de dados. É preciso registrar apenas um wrapper para acessar todas as origens de dados do tipo que o wrapper suporta. Por exemplo, um wrapper de banco de dados Oracle é tudo que é preciso para qualquer número de origens de dados Oracle.
• Após registrar as bibliotecas de wrapper no banco de dados federado, cada origem de dados deve ser identificada no sistema como um servidor. Um servidor geralmente representa um banco de dados em outro sistema. O banco de dados federado usa os atributos do servidor para garantir que os recursos de cada origem sejam propriamente explorados. Atributos de servidor no banco de dados federado armazenam as características de cada origem de dados. O otimizador do DB2 usa essas características e restrições ao determinar a melhor maneira de processar uma consulta. Usando opções de servidor para configurar atributos de servidor externo, é possível especificar o local da origem de dados (nó da máquina), informações de segurança de conexão (ID e senha) e algumas características de servidor que afetam o desempenho. Cada módulo de wrapper mantém um conjunto de atributos de servidor relacionado ao tipo e versão das origens de dados que suporta. Colocar para baixo — uma operação que permite ser realizada em uma origem de dados remota — pode ser benéfico ao reduzir a quantidade de dados trazidos para o servidor federado na rede, ajudando assim o desempenho da consulta.
• Nomes alternativos são criados no banco de dados federado para identificar tabelas de origem de dados e visualizações. Agora é possível referenciar o nome alternativo no aplicativo como se fosse uma tabela local, e elas aparecerão para clientes como tabelas do DB2. Nomes alternativos podem ter colunas, estatísticas, índices ou restrições de informações.
• Origens de dado geralmente exigem autenticação. Informações de autenticação são registradas com o sistema federado como mapeamentos de usuário. Isso fornece uma camada adicional de segurança. O ID do usuário e senha do cliente para acessar o banco de dados federado é mapeado para um ID de e usuário e senha remotos.
• Um procedimento federado é um procedimento local mapeado para o procedimento da origem de dados.

Voltar para parte superior

Conclusão

DB2 AESE é uma solução de banco de dados completa em um único pacote por um preço baixo. Entre o amplo conjunto de recursos e benefícios que ele oferece estão soluções de alta disponibilidade e continuidade de negócios, e administração simplificada que pode ajudar a unificar o ambiente de dados heterogêneo para clientes usando bancos de dados DB2 e Oracle. A replicação ativa/ativa oferecida por meio de sua tecnologia de Q Replication permite proteção contra falhas do site e disponibilidade contínua durante atualizações e manutenção. O servidor de federação no DB2 AESE simplifica a integração de bancos de dados para clientes passando do Oracle para o DB2, ou que estejam gerenciando um ambiente misto. Para saber mais sobre o DB2 AESE e os recursos que ele oferece, consulte os recursos abaixo.

Recursos

Aprender

• Leia "Por dentro do IBM DB2 Advanced Enterprise Server Edition, Parte 1, que foca no gerenciamento de desempenho e otimização de armazenamento.
  
  
• Leia "Combining IBM DB2 pureScale with Q replication for scalability and business continuity" para aprender como estender o recurso do DB2 pureScale à Q Replication.
  
  
• O texto no blog de David Tolleson chamado "Should you switch from IBM's SQL Replication to Q replication?" explica melhor este assunto.
  
  
• Consulte "Using data replication for continuous availability", um vídeo curso que oferece uma visão geral sobre o uso de Q Replication.
  
  
• Consulte "Why IBM's replication server scales", um vídeo curto que oferece uma visão geral sobre por que o Servidor de Replicação da IBM faz ajuste de escala.
  
  
• Em The Data Replication Exchange, David Tolleson responde perguntas técnicas sobre replicação de dados.
  
  
• Em About Data Federation, David Tolleson responde perguntas técnicas sobre federação.
  
  
• O Grupo do developerWorks sobre InfoSphere Federation Server oferece informações sobre as tecnologias de federação de dados da IBM.
  
  
• A Série de webcasts sobre IBM DB2 para Profissionais Oracle explora aspectos essenciais do DB2 para Linux, UNIX e Windows.
  
  
• Confira o IBM DB2 e-kit for Database Professionals, a página do produto IBM DB2 Workshop para Profissionais Oraclee a unidade Knowledge Path: DB2 Fundamentals for Oracle Professionals.
  
  
• Saiba mais sobre Information Management na zona de Information Management no developerWorks. Encontre documentação técnica, artigos com instruções, educação, downloads, informações sobre produtos e mais.
  
  

Obter produtos e tecnologias

• Faça download de uma versão de teste gratuita do DB2 para Linux, UNIX e Windows para experimentá-lo no seu ambiente.
  
  
• Crie seu próximo projeto de desenvolvimento com a Versão de testes do software IBM, disponível para download diretamente no developerWorks.
  
  

Discutir

• Participar do fórum de discussão.
  
  
• Confira os blogs do developerWorks e participe da comunidade do developerWorks.
  
  

Sobre o autor

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Visão rápida do DB2 Advanced Enterprise Server Edition
• Conclusão
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

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

---

Saiba mais