Introdução

O primeiro artigo descreveu como a otimização do cliente pode melhorar o desempenho e a segurança do aplicativo de banco de dados e como ativar a otimização do cliente em um único nó de servidor de aplicativos. Este segundo arquivo apresenta resumidamente o conceito de cluster, explica como definir uma fonte de dados e um provedor JDBC ativado para pureQuery em um ambiente em cluster e, em seguida, descreve como configurar e trabalhar com a otimização do cliente em ambientes de servidor de aplicativos em cluster, especificamente os ambientes WebSphere Application Server (WAS) em cluster.

Revisão da otimização do cliente

Como você deve lembrar, o primeiro artigo descreveu que a otimização do cliente consiste nas seguintes fases principais:

• Captura do SQL do aplicativo em execução.
• Configuração do SQL capturado para especificar os nomes dos pacotes de destino.
• Conexão do arquivo de captura configurado nos pacotes do DB2, se o banco de dados de destino for DB2.
• Execução do aplicativo com o SQL capturado para obter o comportamento desejado, como uma execução estática.

Este segundo artigo foca nas extensões da fase de captura que permitem a acomodação de um ambiente em cluster. O artigo descreve como configurar o provedor JDBC, as fontes de dados e as propriedades pureQuery para permitir a captura do SQL quando diversas instâncias estiverem em execução no mesmo aplicativo em um cluster Isso significa basicamente a criação de diversos arquivos de captura de saída. A outra parte do processo descrita no artigo descreve como mesclar o SQL capturado em um único arquivo que pode posteriormente ser configurado e conectado à fonte de dados de destino.

Revisão do armazenamento em cluster

O armazenamento em cluster, como o nome sugere, refere-se a uma coleção lógica de instâncias de servidores de aplicativos em execução no mesmo aplicativo. O propósito do armazenamento em cluster é fornecer gerenciamento de carga de trabalho e alta disponibilidade. Se uma instância do servidor ficar indisponível, outra instância assume a carga de trabalho. As instâncias individuais do servidor em um ambiente em cluster são chamadas de membros do cluster.

Para usar o armazenamento em cluster com o WebSphere Application Server, é necessário ter o WebSphere Application Server Network Deployment Edition. Essa edição do WebSphere inclui um perfil chamado gerenciador de implementação, que é uma instância especial do WebSphere. O gerenciador de implementação permite a criação e o gerenciamento de clusters.

Os membros de um cluster podem ser do mesmo nó e da mesma máquina ou de nós e máquinas diferentes. Um nó é um agrupamento lógico de instâncias do servidor de aplicativos que compartilha o mesmo controle da configuração e está geralmente associado a uma instalação física do WAS. Cada nó usa um agente para se comunicar com o gerenciador de implementação. O perfil de gerenciador de implementação permite o gerenciamento da configuração de diversos servidores de aplicativos em diversos nós.

Existem três tipos de ambiente em cluster do WAS. Os tipos diferentes variam de acordo com a forma e o local onde os membros do cluster estão localizados:

• Armazenamento em cluster horizontal — Várias instâncias do servidor ou membros do cluster estão em nós diferentes.
• Armazenamento em cluster vertical — Todos os membros do cluster estão no mesmo nó.
• Armazenamento em cluster misto — É uma combinação do armazenamento em cluster horizontal e vertical.

A Figura 1 mostra um exemplo de um ambiente de armazenamento em cluster misto . No Nó 1, os membros de cluster clus1_1 e clus1_2 são um exemplo de armazenamento em cluster horizontal em um nó. De forma similar, o Nó 2 possui dois membros de cluster chamados clus2_1 e clus2_2 que estão em um armazenamento em cluster horizontal. Como o Nó 1 e o Nó 2 também estão em um armazenamento em cluster vertical, o ambiente mostrado representa um armazenamento em cluster misto.

Para aprender mais sobre armazenamento em cluster, consulte o link do Centro de Informações do Device Manager na seção Recursos deste artigo.

Ao instalar um aplicativo em um ambiente em cluster misto, os aplicativos são instalados em todos os membros do cluster ao mesmo tempo. É possível parar, iniciar e administrar um cluster como uma entidade única, da mesma forma que você faria com um único servidor.

Este artigo assume que todos os nós no ambiente em cluster são gerenciados pelo gerenciador de implementação. Isso significa que todas as configurações de propriedade feitas no nível do nó são propagadas para todos os membros do servidor no ambiente. O artigo também assume que o servidor da Web faz parte do servidor de aplicativos.

Criando um provedor JDBC ativado para pureQuery e uma fonte de dados no cluster

Ao criar um provedor JDBC em um ambiente em cluster, é necessário garantir que o escopo do provedor JDBC é o cluster e não a instância individual do perfil do servidor. O escopo de um recurso (como o provedor JDBC ou a fonte de dados) define sua visibilidade no ambiente do servidor de aplicativos. Por exemplo: um escopo definido no nível do cluster significa que todos os membros do cluster conseguem visualizar o recurso. De forma similar, um escopo definido no nível do nó pode ser visualizado por todas as instâncias do servidor naquele nó. É possível definir o escopo ao criar o provedor JDBC ou a fonte de dados.

A fonte de dados é criada no ambiente em cluster da mesma forma que é feita em um ambiente com um único servidor, com exceção da definição do escopo da fonte de dados como cluster. Novamente, isso faz com que a fonte de dados fique visível para todos os membros do cluster. A Figura 2 mostra como usar a página Data sources do Integrated Solutions Console para selecionar o escopo de uma nova fonte de dados. Depois de escolher mostrar a lista suspensa de seleção do escopo, a lista mostra todos os nós, clusters e instâncias do servidor de aplicativos disponíveis.

Consulte o primeiro artigo desta série para obter instruções sobre a criação da fonte de dados.

Depois de criar a fonte de dados, é possível definir as propriedades data-source-level pdq da mesma forma que você faz para um único servidor. As propriedades são então aplicáveis ao cluster. Tudo o que foi descrito no primeiro artigo em termos de propriedades para um ambiente com um único servidor também é aplicável em um ambiente em cluster.

Voltar para parte superior

Configurando a otimização do cliente em um ambiente em cluster

Conforme descrito anteriormente, ao instalar um aplicativo em um cluster, ele é instalado em todos os membros do cluster e todos esses membros terão a mesma visualização do banco de dados backend (fonte de dados). Ao ativar a otimização do cliente em tal ambiente, ela aumenta a possibilidade de contenção de recursos. Isso devido ao aumento da probabilidade de que diversas instâncias do mesmo aplicativo de diferentes membros do cluster estejam em execução no modo de captura e tentem gravar no mesmo arquivo de captura.

Para evitar o problema de contenção de recursos, um novo sufixo de nome de arquivo é usado. O sufixo é o $X. Durante a fase de captura SQL, é possível fornecer um nome do arquivo de captura (usando a propriedade outputPureQueryXml) que inclui o sufixo $X . Por exemplo: pdq.outputPureQueryXml=App1$X.pdqxml

Durante o processo de captura da otimização do cliente, o $X é substituído pelo registro de data e hora e o ID do objeto do carregador de classe do aplicativo quando o arquivo é criado pela primeira vez. Isso garante a criação de um nome de arquivo exclusivo para cada instância do aplicativo em um cluster.

Somente é possível usar o sufixo $X para o arquivo outputPureQueryXml porque ele permite a criação de diversos arquivos. Em um ambiente com um único nó, é necessário somente especificar a propriedade pureQueryXml para a captura inicial, pois não haverá nenhuma contenção de recursos. No entanto, em um ambiente em cluster, para evitar a contenção de recursos durante a captura inicial, o uso da sintaxe $X é recomendado.

É possível usar o sufixo $X em qualquer nível do arquivo pdq.properties (global, fonte de dados ou aplicativo). O sufixo é destinado para uso em ambientes em cluster quando o mesmo aplicativo é executado em diversas instâncias do servidor. Ao usar o sufixo em um ambiente com um único servidor, o resultado é um arquivo com o sufixo de registro de data e hora e o ID do carregador de classe.

Observação: Os clusters são visualizados como uma única entidade e fornecem uma visualização única do aplicativo. Então, não é possível ter configurações diferentes para membros diferentes do cluster.

Voltar para parte superior

Mesclando arquivos de captura incremental

Ao usar o sufixo $X em um ambiente em cluster, é criado um arquivo separado para cada instância/membro do cluster. Todos os arquivos contêm as instruções SQL capturadas por cada membro do cluster. Algumas instruções SQL podem ser comuns para diversos arquivos e alguns arquivos podem conter um único SQL. Isso dependerá do fluxo do aplicativo em cada instância. Então, após a execução da captura, você talvez queira combinar todos os SQL capturados em um único arquivo que pode ser configurado e conectado às fontes de dados respectivas para execução estática.

Para fazer isso, é possível usar o utilitário de linha de comando Merge . Esse utilitário permite a mesclagem de dois ou mais arquivos capturados em um único arquivo de saída pdqxml. (Como alternativa, é possível usar o Optim Development Studio para mesclar arquivos.) A Listagem 1 mostra um exemplo de como usar o comando Merge .

java com.ibm.pdq.tools.Merge 
-inputPureQueryXml “c:\Program Files\capture1.pdqxml” capture2.pdqxml capture3.pdqxml 
-outputPureQueryXml merge.pdqxml

Use o parâmetro inputPureQueryXml para especificar os arquivos de captura de entrada que serão mesclados. Insira os nomes dos arquivos como uma lista separada por espaços. É possível especificar os nomes dos arquivos no formato absoluto ou relativo. Como o caractere de espaço é usado como o delimitador da lista, se um nome de arquivo contiver um espaço, será necessário incluir esse nome de arquivo entre aspas. Os arquivos de entrada são tratados como arquivos somente leitura. O exemplo na Listagem 1 especifica três arquivos de entrada.

Use o parâmetro outputPureQueryXml para especificar o nome do arquivo de captura mesclado. O exemplo na Listagem 1 especifica merge.pdqxml como o nome do arquivo de captura mesclado.

A seção Recursos deste artigo contém um link para a documentação do produto do comando Merge .

A Figura 3 ilustra o processo de mesclagem de diversos arquivos de captura.

Capturando de forma incremental um arquivo de captura mesclado existente

Depois de mesclar diversos arquivos de captura de entrada em um único arquivo de saída e configurar e conectar esse arquivo de saída, talvez ainda seja necessário capturar de forma incremental SQLs adicionais. Isso pode ocorrer devido a alterações nos aplicativos ou por outros motivos. Se o arquivo de captura mesclado for usado como o pureQueryXml para captura incremental, existe novamente o risco de ocorrência de problemas de contenção de recursos.

Para solucionar esse problema, é possível usar os arquivos pureQueryXml e outputPureQueryXml. Quando os dois arquivos são especificados e possuem nomes diferentes, isso é conhecido como captura incremental. O pureQueryXml é tratado como entrada e somente as novas instruções SQL que não estão presentes no pureQueryXml são capturadas no arquivo outputPureQueryXml. Novamente, é possível usar o outputPureQueryXml com a sintaxe de sufixo de arquivo $X para criar diversos arquivos, um para cada instância, e mesclá-los usando o utilitário Merge .

A Listagem 2 mostra um exemplo das configurações de propriedade para uso da captura incremental, no qual App1_base.pdqxml é o nome do arquivo mesclado.

pdq.pureQueryXml=App1_base.pdqxml
pdq.outputPureQueryXml=App1$X.pdqxml
pdq.captureMode=ON

Para processar somente os SQLs novos e não perder os nomes de pacote e as estruturas existentes do SQL capturado originalmente, é possível identificar o arquivo configurado pdqxml existente como um arquivo seed . O SQL recém-capturado é então incluído no arquivo pdqxml existente. Esse cenário é ilustrado na Figura 4. A opção para especificar um arquivo seed é -baseFile. Para configurar e conectar o novo SQL sem perder os nomes de pacote e as estruturas existentes, use as opções -cleanConfigure FALSE e conexão -differenceOnly TRUE.

Observação: Uma exceção ao comportamento acima é um cenário no qual a instrução SELECT é capturada na captura inicial e a atualização da posição correspondente é capturada no modo de captura incremental. Nesse caso, a otimização do cliente pureQuery precisa mover a instrução de atualização de posição para o pacote existente (o pacote de origem da instrução SELECT ) para executar a instrução de atualização de posição com sucesso no modo estático. Ao mover a instrução de atualização de posição para um pacote diferente, é necessário efetuar uma configuração. Se for necessário manter os pacotes conectados anteriormente, deve-se excluir a instrução de atualização de posição do arquivo capturado — no tempo de execução a otimização do cliente pureQuery executa uma atualização dinâmica em um cursor estático. Se não for necessário manter o pacote, deve-se executar uma configuração de limpeza depois do arquivo de saída ser mesclado com o arquivo de entrada. A execução da configuração de limpeza garante que a instrução SELECT e as instruções de atualização de posição correspondentes estão no mesmo pacote. Depois da configuração, é possível executar uma conexão para substituir o pacote existente.

A seção Use a captura incremental com os arquivos de captura mesclados deste artigo contém mais detalhes sobre esse tipo de cenário de captura incremental.

Voltar para parte superior

Um cenário

O cenário a seguir destina-se a descrever em detalhes como configurar e trabalhar com a otimização do cliente em ambientes de servidor de aplicativos em cluster. O cenário começa com um exemplo similar ao exemplo descrito no primeiro artigo. No entanto, neste caso ele é estendido para oferecer suporte para um ambiente em cluster ao invés de um ambiente com um único nó de servidor de aplicativos.

Conforme mostrado na Figura 5, o Aplicativo 1 e o Aplicativo 2 estão instalados em um cluster que possui quatro membros. Os quatro membros consistem em dois nós com dois membros de cluster por nó. DS1, DS2 e DS3 são as fontes de dados configuradas no cluster. Cada nó possui o seu próprio sistema de arquivos comum. O Aplicativo 1 usa as três fontes de dados (DS1, DS2 e DS3), enquanto o Aplicativo 2 usa somente uma fonte de dados (DS3).

Capture SQL em um ambiente em cluster

Para este cenário, o arquivo de propriedades no nível do aplicativo chamado pdq.appwide.properties é configurado para capturar as instruções SQL dos dois aplicativos.

A Tabela 1 mostra a configuração das fontes de dados do Aplicativo 1.

A Tabela 2 mostra as configurações dos arquivos de propriedades pureQuery do Aplicativo 1. Essas configurações permitem a captura do aplicativo e a produção de arquivos de captura específicos para qualquer SQL executado com relação à fonte de dados de destino.

A Tabela 3 mostra a configuração do arquivo de propriedades pureQuery do Aplicativo 2, que acessa somente a fonte de dados 3 (DS3).

Quando os aplicativos são executados no modo de captura, o $X é substituído pelo registro de data e hora e o ID do objeto do carregador de classe do aplicativo. Cada cluster cria seu próprio arquivo de captura para cada fonte de dados. A Tabela 4 mostra os vários arquivos criados ao capturar SQL do Aplicativo 1. Tn representa os registros de data e hora. On representa os IDs do carregador de classe do aplicativo.

A Tabela 5 mostra os vários arquivos criados ao capturar SQL do Aplicativo 2.

Observação: É possível usar o sufixo $X para um arquivo de propriedades no nível do aplicativo, mas esteja ciente que o arquivo de propriedades no nível do aplicativo afeta todas as fontes de dados. Neste cenário, o Aplicativo 2 está usando somente uma fonte de dados. Dessa forma, o uso do sufixo no arquivo de propriedades no nível do aplicativo afetará somente uma fonte de dados.

Mescle os arquivos capturados

Depois de finalizar a sessão de captura, é possível mesclar os vários arquivos antes de configurá-los e conectá-los. Para este cenário de amostra, os arquivos específicos da fonte de dados serão conectados aos seus bancos de dados correspondentes. Por exemplo: para o Aplicativo 1 com DS1, mescle os quatro arquivos de captura correspondentes ao DS1 (consulte a Tabela 4) antes de configurar e conectar o arquivo mesclado ao banco de dados correspondente (DB1).

A Listagem 3 mostra um exemplo do comando Merge que deve ser usado para mesclar os arquivos específicos do DS1.

java com.ibm.pdq.tools.Merge 
–inputPureQueryXml app1_ds1T1O1.xml app1_ds1T2O2.xml app1_ds1T3O3.xml app1_ds1T4O4.xml 
-outputPureQueryXml app1_ds1.pdqxml

No exemplo acima, app1_ds1.pdqxml é o arquivo de saída produzido pela mesclagem. Depois de criar o arquivo de saída, é possível configurá-lo e conectá-lo.

De forma similar, é possível mesclar os arquivos de captura específicos do DS2 e configurar e conectar o arquivo de saída ao banco de dados DB2.

Use a captura incremental com os arquivos de captura mesclados

Esta parte do cenário corresponde à situação ilustrada na Figura 4. Vamos supor que você descobriu que precisa executar uma captura incremental no Aplicativo 1. Isso pode acontecer porque você esqueceu algum SQL na captura anterior ou porque uma lógica adicional foi incluída no aplicativo. Para fazer isso, use o arquivo mesclado (app1_ds1.pdqxml) como o arquivo pureQueryXml de entrada e especifique um arquivo separado com o sufixo $X para o nome do arquivo outputPureQueryXml.

A Listagem 4 mostra um exemplo de como configurar as propriedades do pdq.ds1.properties para executar capturas incrementais no DS1.

	
pdq.pureQueryXml=app1_ds1.pdqxml
pdq.outputPureQueryXml=app1_ds1$X.pdqxml

Observação: Ao definir o outputPureQueryXml, o arquivo pureQueryXml é automaticamente considerado como entrada e como somente leitura. Esse exemplo não possui um arquivo inputPureQueryXml explícito. Se o outputPureQueryXml não for especificado, o pureQueryXml será considerado como o arquivo de entrada e de saída.

Ao usar as configurações mostradas na Listagem 4 e executar o aplicativo no modo de captura para o DS1, quatro arquivos são criados, um para cada membro do cluster. É possível então usar o utilitário de linha de comando Merge para mesclar esses arquivos em um novo arquivo pureQueryXML.

Para este cenário, o novo SQL será mesclado com o arquivo configurado pdqxml existente sem sobrescrever as configurações feitas no pdqxml. Para fazer isso, é necessário especificar o arquivo configurado pdqxml existente como o arquivo de base, app1_ds1.pdqxml.

A Listagem 5 mostra um exemplo do comando Merge que pode ser usado para fazer isso.

java com.ibm.pdq.tools.Merge 
–inputPureQueryXml app1_ds1T1O1.pdqxml app1_ds1T2O2.pdqxml 
app1_ds1T3O3.pdqxml app1_ds1T4O4.pdqxml 
-baseFile app1_ds1.pdqxml
-outputPureQueryXml app1_ds1_V2.pdqxml

As opções do comando Merge do exemplo acima especificam que você deseja colocar o SQL novo dos três arquivos de entrada em uma instrução sem nome definida após os conteúdos atuais do arquivo app1_ds1.pdqxml e gravar o SQL novo no arquivo de saída app1_ds1_V2.pdqxml. Em seguida, é possível configurar de forma incremental o arquivo de saída usando a opção -cleanConfigure FALSE e conectá-lo usando a opção -differenceOnly TRUE .

Voltar para parte superior

Resumo

Os ambientes WebSphere Application Server em cluster são usados para alta disponibilidade e desempenho. Como o pureQuery fornece otimização de desempenho para o WAS, é importante entender como a otimização do cliente pureQuery pode operar nesse ambiente. Este artigo revisou o uso das propriedades e do sufixo de arquivo de captura $X para permitir a captura de SQL nos membros de um cluster. Essas técnicas servem para evitar a contenção de recursos que pode ocorrer quando um único arquivo de captura é usado.

O artigo também forneceu uma visão geral e exemplos de como usar o utilitário de linha de comando Merge para mesclar arquivos SQL capturados de cada membro em um único arquivo que pode ser configurado e conectado ao pacote (ou pacotes) de banco de dados nos servidores de banco de dados de destino.

Voltar para parte superior

Agradecimentos

Agradecemos Christopher M. Farrar, Kathryn Zeidenstein, Patrick Titzler e Kavitha Pullela pelo apoio na revisão do conteúdo deste artigo.

Recursos

Aprender

• Leia "No Excuses" Database Programming for Java para aprender mais sobre SQL estático e seus benefícios.
  
  
• Consulte o Centro de Informações do Device Manager para obter uma visão geral do armazenamento em cluster.
  
  
• Para obter informações sobre captura de SQL em ambientes em cluster, consulte este tópico no Centro de Informações do Integrated Data Management.
  
  
• Para obter detalhes sobre o utilitário Merge, consulte este tópico no Centro de Informações do Integrated Data Management.
  
  
• O artigo "Integrated Data Management: Managing data across its lifecycle" (developerWorks, atualizado em junho de 2009) explica a visão e a realidade do gerenciamento de dados integrado nas funções.
  
  
• A demo da solução de gerenciamento de desempenho Optim mostra como uma empresa fictícia usa as soluções Optim para o gerenciamento do desempenho. O demo inclui um cenário de otimização de cliente.
  
  
• Consulte a página da família Optim no developerWorks para aprender mais sobre as soluções Optim. Encontre documentação técnica, artigos de instruções, educação, downloads, informações do produto e muito mais.
  
  

Obter produtos e tecnologias

• O software de teste gratuito Data Studio e Optiminclui um link para o Optim Development Studio, que fornece um período de 30 dias de teste para o ambiente de desenvolvimento e o pureQuery Runtime para uso e desenvolvimento em uma única máquina.
  
  
• Os pré-requisitos do pureQuery Runtime para Linux, UNIX e Windows 2.2.0.1 estão nesta nota técnica.
  
  
• Os pré-requisitos do pureQuery Runtime para z/OS 2.2 estão nesta nota técnica.
  
  

Discutir

• Participar do fórum de discussão.
  
  
• Confira o blog dos especialistas em gerenciamento de dados integrado e participe do espaço da comunidade de gerenciamento de dados integrado, que possui uma lista abrangente de recursos e downloads.
  
  

Sobre os autores

Charul Kapil é engenheira de software dos Laboratórios de Software IBM Índia há três anos. Atualmente ela trabalha na equipe de QA de Relatórios OPM. Anteriormente, ela participou da equipe de QA de otimização de cliente pureQuery.

Jaijeet Chakravorty é engenheiro de software na IBM. Ele está localizado no Laboratório IBM do Vale do Silício, em São José, na Califórnia. Ele trabalha com driver JDBC do Java Common Client, SQLJ e produtos pureQuery do lado do cliente. Jaijeet está envolvido no desenvolvimento de produtos e no fornecimento de suporte L3 para clientes do mundo inteiro.

Manoj Sardana é engenheiro de software e trabalha nos Laboratórios de Software IBM Índia há mais de cinco anos. Ele é administrador avançado com certificação IBM e desenvolvedor de aplicativos para DB2 Linux, UNIX e Windows. Atualmente ele trabalha na equipe de desenvolvimento do pureQuery. Manoj possui bacharelado em engenharia da computação da NITK Surathkal. No seu tempo livre, ele gosta de ouvir música e brincar com seus filhos.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Criando um provedor JDBC ativado para pureQuery e uma fonte de dados no cluster
• Configurando a otimização do cliente em um ambiente em cluster
• Mesclando arquivos de captura incremental
• Um cenário
• Resumo
• Agradecimentos
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

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

---

Saiba mais