Os clientes escolheram o DB2 como o banco de dados preferido em função do seu incrível tempo para obtenção de valor, habilidade de ser escalado e integrado em ambientes distintos, robustez e minimização do tempo de inatividade (planejado e não planejado). Neste artigo, focamos nos aspectos de high-availability (HA) do DB2, não tanto do ponto de vista de funcionalidade (sobre o que muito foi escrito), mas do ponto de vista do licenciamento.

Ouvimos muitas perguntas sobre o licenciamento do DB2 em um ambiente HA - configurações projetadas para tratar indisponibilidades não planejadas (e às vezes as planejadas também). Normalmente o primeiro nível da confusão é causado por amplas variações em quão diferentes são preços estabelecidos pelos fornecedores dos produtos de banco de dados em ambientes de alta disponibilidade.

Outra fonte de confusão deriva dos termos usados em discussões relacionadas a disponibilidade. Por exemplo, o termo clusters. Às vezes o segmento de mercado de TI refere-se a ambientes de alta disponibilidade como clusters. Não gostamos mais de usar esse termo sozinho, uma vez que ficou um pouco sobrecarregado, já que recentemente clusters pode se referir a armazenamento em cluster para escalabilidade (como o recurso de particionamento de banco de dados InfoSphere Warehouse - DPF - que é baseado em DB2) ou armazenamento em cluster para disponibilidade (por exemplo, usando o software de armazenamento em cluster Tivoli System Automation for Multi-platforms (SA-MP) que foi lançado pela primeira vez no DB2 9 e subsequentemente profundamente integrado na liberação DB2 9.5 release em um grupo de servidores), ou ambos (uma vez que esse é o caso com um cluster DB2 pureScale, ou o IBM Smart Analytics System). Apesar de não gostar do termo, ele é usado; para este artigo, quando nos referimos ao termo cluster, queremos dizer armazenamento em cluster para HA (a menos que indicado de outra forma). Para fins de simplicidade, recomendamos usar o termo cluster com o prefixo alta disponibilidade ou o escalabilidade ao discutir clusters com clientes ou colegas. É claro, algumas soluções abordam tanto escalabilidade quanto alta disponibilidade com um cluster - então apenas garanta que esteja sempre comunicando o que deseja ao conversar com seus colegas.

Outra origem de confusão resulta dos termos usados para descrever um servidor que atua como o servidor de failover no caso de uma falha. Por exemplo, esse servidor pode ser referido como de espera ou o servidor secundário (entre outros nomes). Se você tem experiência suficiente, você provavelmente se deparou com a variedade de termos descrevendo a função que esse servidor realiza. Termos como ocioso, ativo, frio, morno, quente e passivo foram todos usados em discussões sobre disponibilidade.

Na maior parte, a literatura IBM Software Group (IBM SWG) usa a taxonomia frio, morno e quentes para descrever servidores em espera. Antes do DB2 9.5, coisas na "terra do DB2" eram um pouco diferente, entretanto, desde a liberação do DB2 9.5 (e posteriores), a taxonomia e os termos de licenciamento de HA do DB2 e estão de acordo com a taxonomia do IBM SWG e os termos de licenciamento com relação ao preço de HA. Por exemplo, se você configurou um cluster de HA do DB2 9.1 usando o IBM PowerHA for AIX (já conhecido como High Availability Cluster Multiprocessing - HACMP) como o servidor que ficou ocioso (e o gerenciador do banco de dados não foi iniciado), você precisaria licenciar parcialmente o servidor. A partir do DB2 9.5 em diante, você não precisa pagar um centavo! Da mesma forma, se você tivesse o DB2 9.1 instalado em um servidor que fosse desligado, teria de licenciar parcialmente esse servidor também. A partir do DB2 9.5 e posteriores, você não precisa comprar uma licença do DB2 para um servidor que não está ligado. Atualizamos esse arquivo para a liberação do DB2 9.7 e quaisquer alterações temporárias como resultado de um fix pack para ajudá-lo a definir as regras de licenciamento de alta disponibilidade do DB2 e fornecer as informações de que precisa.

Observação: este artigo também aborda a tecnologia DB2 pureScale que foi inicialmente anunciada em outubro de 2009. O veículo de entrega para o DB2 pureScale é o DB2 9.8; entretanto, o único motivo para executar o DB2 9.8 é para DB2 pureScale. Em outras palavras, se você estiver executando um servidor DB2 9.7 e não tiver planos para usar o DB2, você não passaria para o DB2 9.8.

Figura 1 fornece uma boa descrição da taxonomia de high availability (HA) do DB2 9.7 e alguns exemplos dos tipos de configurações que se enquadram em cada categoria.

Tablela 1 mostra os termos mais comuns usados para descrever os ambientes de HA mapeados para a taxonomia e os termos de licenciamento do DB2 9.7.

Tablela 1 anexou uma regra geral abaixo de cada categoria; entretanto, depois de ler este artigo, espera-se que fique claro. De maneira bem simples, como você licencia um servidor DB2 em um ambiente de alta disponibilidade depende das suas respostas a estas diversas perguntas:

Qual edição do DB2 você tem instalada?

Ela é: DB2 Express-C, DB2 Express, DB2 Workgroup, DB2 Enterprise ou DB2 Advanced Enterprise? Por exemplo, um servidor DB2 Express com uma licença SERVER (introduzida quando o DB2 9.7 foi disponibilizado ao público) não tem o conceito de quente, morna ou frio para um servidor de espera (mais sobre isso em breve). Você deve estar ciente de que você não está licenciado para configurar o DB2 Express-C livre em qualquer tipo de configuração de alta disponibilidade - se precisar de alta disponibilidade, precisa, como um mínimo, do DB2 Express. (Observe que o DB2 Express - C FTL estava disponível apenas na liberação DB2 9.5 e não está mais disponível no DB2 9.7. Agora está disponível como DB2 Express FTL: mesmo preço que antes, com mais recursos!)

Como a máquina está sendo usada quando uma falha não ocorreu?

Por exemplo, está sendo usada como um servidor de produção para transação de DB2 e trabalho de consulta? A instância do DB2 nesse servidor está iniciada? Talvez a instância esteja realizando alguma forma de trabalho, mas apenas para ajudar a iniciar uma recuperação no caso de uma falha; por exemplo, em um cenário HADR. Você está gerenciando um cluster DB2 pureScale? De maneira bem simples, o que o servidor de espera está fazendo quando tudo está operando bem está muito relacionado tudo a como o DB2 nesse servidor precisa ser licenciado.

Como você licenciou seu servidor DB2 para o qual deseja garantir alta disponibilidade?

Por exemplo, se tiver licenciado um servidor DB2 Express usando a licença SERVER introduzida no DB2 9.7, deve comprar uma licença SERVER adicional para o servidor de espera não importa o tipo de estado operacional em que está: quente, morno ou frio. Se tiver licenciado seu servidor DB2 Express usando o modelo Authorized User (AU), licenciaria o servidor de espera em um estado morno para 5 AUs e não precisaria de nenhuma licença para uma máquina de espera fria. Se o servidor DB2 Express tiver sido licenciado usando o modelo Processor Value Unit (PVU) , você usaria um servidor de espera morno para 100 PVUs (não importa que arquitetura de processo o servidor está usando) e não precisaria sequer de uma licença para uma máquina de espera fria.

Se estiver procurando uma visão geral de todos os servidores DB2 9 distribuídos e como licenciá-los, consulte "Qual edição distribuída do DB2 9.7 é a certa para você?". Para comparações desses recursos, funções e benefícios entre as diferentes edições do servidor DB2, leia "Comparação dos servidores de dados DB2 9.7 distribuídos".

Desde a liberação do DB2 8.2, houve várias melhorias de licenciamento que reduziram significativamente o custo de alta disponibilidade HA associado aos seus servidores DB2. Por exemplo, no DB2 8.2, se desejasse licenciar o DB2 Workgroup com HADR, precisaria comprar o High Availability Feature Pack, e licenciar esse feature pack em ambos os servidores. No DB2 9, isso mudou: você não precisa mais licenciar esse feature pack no servidor de espera. No DB2 9.5, a IBM tornou o High Availability Feature Pack gratuito para servidores DB2 Workgroup. De maneira bem simples, liberação após liberação, a IBM reduziu o custo dos seus ambientes de disponibilidade com base em DB2 em função das seguintes mudanças:

• Quando um único servidor está atuando como uma espera morna para vários servidores de produção, é preciso licenciar apenas o servidor em espera morno uma vez (a partir do DB2 8.2). Por exemplo, se tiver licenciado um servidor DB2 quente para um número ilimitado de usuários, o servidor em espera morno exigira 100 PVUs. Se cinco servidores classificados para 400 PVU estivessem em operação no DB2 Workgroup, e cada servidor estivesse configurado em um cluster HADR para failover para o mesmo servidor, seria preciso licenciar apenas 2100 PVUs (5 servidores x 400 PVUs + 100 PVUs para o servidor em espera), em oposição a 2500 PVUs [(5 servidores x 400 PVUs) + (5 servidores x 100 PVUs)].
• Não é mais preciso licenciar feature packs em um servidor que está atuando como um servidor de espera morno ou frio (a partir do DB2 9). Por exemplo, se tiver licenciado o Storage Optimization Feature Pack (que fornece compactação para dados XML, tabelas, índices, tabelas temporárias, entre outros) para o servidor DB2 Enterprise e configurado o banco de dados para participar de um cluster HADR, precisaria comprar apenas 100 PVUs de DB2 Enterprise no servidor de espera. Nenhum licenciamento extra seria incorrido para usar o Storage Optimization Feature Pack.
• HADR está incluído no DB2 Workgroup sem encargo extra (a partir do DB2 9); se pesquisar o panorama da concorrência, não há outro fornecedor que ofereça o mesmo tipo de funcionalidade (não há restrições para a tecnologia HADR no DB2 Workgroup) para nenhum servidor segmentado para pequenas e médias empresas.
• Você obtém o software de armazenamento em cluster livre para praticamente qualquer edição (com DB2 Express necessário para usar uma licença SERVER ou FTL, ou é preciso comprar um feature pack) - Tivoli System Automation for Multi-platforms (Tivoli SA-MP) - para criar um cluster de alta disponibilidade para seus servidores DB2 (a partir do DB2 9).
• Você não precisa licenciar uma máquina de espera fria (a partir do DB2 9.5). Na verdade, alguns fornecedores alegam algum tipo de vantagem oferecendo 10 dias de uso de failover para uma solução de alta disponibilidade; entretanto, com o DB2, é realmente ilimitado para o mesmo tipo de clusters. O que é mais importante, você obtém o software de armazenamento em cluster gratuitamente! Na verdade, o software de armazenamento em cluster Tivoli SA-MP é profundamente integrado no DB2 (as a partir do DB2 9.5) e inclui interfaces de gerenciamento avançadas que cortam o custo total de propriedade de um cluster de alta disponibilidade.
• É possível configurar dois servidores DB2 Express em um cluster HADR sem precisar comprar o High Availability Feature Pack se licenciar seus servidores DB2 Express usando a licença Fixed Term License (FTL) ou SERVER (ambas opções de licenciamento foram introduzidas quando o DB2 9.7 foi disponibilizado ao público em geral).

Observação: neste artigo, referimo-nos a licenciar um servidor; porém, todas as edições do DB2 têm suporte para licenciamento de subcapacidade em que você licencia unicamente a capacidade que o servidor DB2 está usando. Se usarmos uma frase como licenciar a classificação de PVU do servidor, é possível interpretar isso como a classificação de PVU de uma sessão de VMWare ou LPAR se estiver usando essas tecnologias de virtualização. Há alguns pré-requisitos para esse tipo de licenciamento de que você deve estar ciente, então certifique-se de conhecer todos os detalhes antes de implementar o DB2 nesse tipo de ambiente.

Como se pode ver, houve muitas mudanças para simplificar o custo total de propriedade associado a clusters de alta disponibilidade DB2 tanto da perspectiva de licenciamento quanto da administrativa; isso é muito incentivador, considerando o tipo de economia em que estamos. O melhor lugar para começar uma discussão sobre os efeitos de clusters de alta disponibilidade em licenciamento de DB2 9.7 é com exemplos correlacionados à taxonomia de alta disponibilidade do DB2. Como mencionado anteriormente, o DB2 9.7 define três tipos de servidores de espera: quentes, mornoe frio.

Voltar para parte superior

Espera quente

Uma configuração de espera quente é aquela em que todos os servidores têm bancos de dados operacionais DB2 que atendem consultas e transações do usuário. Essa configuração é chamada de cluster quente/quente (embora às vezes seja chamada de configuração ativo/ativo , uma vez que todas as máquinas no cluster estão realizando algum nível de trabalho de produção de negócios o tempo todo). Se um dos servidores no cluster de alta disponibilidade falhar, então o software de armazenamento em cluster redistribuiria a carga de trabalho do servidor com falha para um ou mais servidores ainda em atividade no cluster de alta disponibilidade. Esse ambiente poderia ser caracterizado por um único aplicativo ou um em que cada servidor apoie o outro, mas também tem seu próprio acordo de nível de serviço (SLA) que precisa cumprir.

Se uma falha for ocorrer em um dos servidores, a transferência de recursos poderia efetivamente dobrar (em um cluster de dois nós) a carga de trabalho no servidor em espera quente (por exemplo, a única máquina ainda ativa no cluster HADR de dois nós) porque agora precisaria lidar com sua carga de trabalho original mais a carga do servidor que falhou. Isso é algo que você precisa considerar ao configurar qualquer ambiente de alta disponibilidade e aproveitar topologias de armazenamento em cluster avançadas, como DB2 pureScale. Se for um administrador de banco de dados que está colocando tudo na linha para um SLA rígido, precisa garantir que tenha verificado adequadamente sua topologia de alta disponibilidade e escolha da solução de alta disponibilidade que está usando.

Para resumir, no DB2, um servidor de espera quente é uma máquina sendo usada para atender transações e consultas do usuário durante períodos normais de operação, e ainda atuando como espera para outro servidor que também é usado para atender transações do usuário durante períodos de operação normal. Quando uma falha do servidor no cluster ocorre, o servidor de espera quente assume a máquina do servidor que falhou além da carga que estava realizando durante operações normais. Porque a máquina em espera ativa ainda é usada para transações e consultas do usuário, mesmo se nenhuma falha ocorrer, ela deve ser totalmente licenciada. Por exemplo, imagine ter dois bancos de dados em duas máquinas separadas, um executando um aplicativo em pacote enterprise resource planning (ERP) e outra executando um aplicativo em pacote supply chain management (SCM). Se o banco de dados SCM for falhar, a máquina executando a carga de trabalho ERP teria de atender todos os usuários SCM também. Um cenário ilustrando um cluster de alta disponibilidade de espera quente de dois nós é mostrado na Figura 2.

Neste exemplo, há um par de servidores que estão ambos sendo usado para cargas de trabalho de transação e consulta durante períodos de operação normal (as caixas sólidas representam onde a carga de trabalho para cada máquina ocorre antes de uma falha , as caixas quadriculadas são onde um trabalho ocorreria no caso de uma falha da máquina respectiva). Neste cenário de exemplo, a máquina 2 falha e a sua carga de trabalho é transferida para sua parceira de failover, a máquina 1. A máquina 1 é um servidor de espera quente para a máquina 2 (e vice-versa quando se olha com atenção para essa figura - observe a caixa quadriculada para a máquina 1 na máquina 2). Esse tipo de configuração é frequentemente referido como par de armazenamento em cluster de alta disponibilidade, par de failover duplo, par quente/quente ( par ativo/ativo e é comum no panorama de TI de hoje. Há muitas maneiras de implementar um cluster de alta disponibilidade quente/quente no DB2, e dependendo do que você precisa da solução, pode usar PowerHA for AIX, HADR junto com um banco de dados em cada servidor fazendo failover para outro, HADR (com Leitura em Espera ativada), Q-Replication, usando uma espera quente para relatar via tecnologia de captura instantânea ou cópias de imagem em disco, ou o ápice da escalabilidade e disponibilidade combinado: aproveitar a tecnologia DB2 pureScale.

Novamente, a máquina 1 e a máquina 2 na Figura 2 estavam sendo usadas o tempo todo para cargas de trabalho de produção; quando a máquina 2 falhou sua carga de trabalho simplesmente do DB2 foi simplesmente transferida para a máquina 1.

Um cluster HADR pode funcionar como um cluster quente/quente de várias maneiras. Por exemplo, considere o ambiente mostrado na Figura 3.

Na figura anterior, você pode ver que o Servidor A hospeda um banco de dados de produção chamado Database A, bem como um banco de dados de espera no cluster HADR, chamado Database B1. Ao mesmo tempo, o Servidor B hospeda um banco de dados de produção chamado Database B, bem como um banco de dados de espera no mesmo cluster HADR chamado Database A1. Neste caso, quando não há failure, o Servidor A e o Servidor B estão ocupados atendendo trabalho de produção no Database A e no Database B, respectivamente e, portanto, isso é considerada uma configuração quente/quente e ambos os servidores devem ser totalmente licenciados.

Figura 4 mostra um exemplo de um ambiente HADR que está usando o recurso de Leitura em Espera que é parte do DB2 9.7 Fix Pack 1 e posteriores.

No modo Figura 4 Você pode ver que os clientes podem ler e gravar no servidor Primário (tornando-o quente); mas, uma vez que estão lendo no servidor Secundário, também é quente e, portanto, ambos os servidores devem ser totalmente licenciados. De maneira bem simples, se você ler os dados de um servidor para fins de negócio, ele é uma máquina quente.

Por fim, Figura 5 mostra um cluster de escala e alta disponibilidade DB2 pureScale de três membros.

No modo Figura 5, você apenas licencia o DB2 e o DB2 pureScale Feature Pack nos Membros (as máquinas processando transações). Os servidores Caching Facility (CF) de cluster (que, como se pode ver, normalmente são totalmente duplexados) não exigem nenhuma licença. Nesse mesmo exemplo, uma vez que as transações estão sendo continuamente tendo a carga balanceada através de todos os Membros, elas são todas quentes e, portanto, devem ser totalmente licenciadas.

Considerações de licenciamento para uma máquina em espera quente

Como uma regra geral, uma configuração quente/quente deve ser licenciada da mesma maneira que você licenciaria cada servidor se ele não estivesse armazenado em cluster para alta disponibilidade de forma alguma.

A partir do DB2 9.7, há cinco métodos de licenciamento diferentes (alguns estão disponíveis apenas com edições específicas do DB2): SERVER, Fixed Term License (FTL), SOCKET, Authorized User (AU) e Processor Value Unit (PVU). A seguir são detalhadas as considerações de licenciamento de alta disponibilidade de que você deve estar ciente para cada licença respectiva em um cluster de alta disponibilidade quente/quente.

Licença SERVER

Uma licença SERVER é nova para o DB2 9.7 e está disponível somente para servidores DB2 Express. Ao licenciar um servidor DB2 Express usando uma licença SERVER, você simplesmente compra uma licença para cada servidor no cluster não importa o tipo de espera (quente, morna ou fria) que é usada. De maneira bem simples, não há necessidade de identificar o nível de atividade de um servidor DB2 Express licenciado usando uma licença SERVER no que se refere a licenciamento de alta disponibilidade. Não há mínimos de usuário e não é preciso descobrir a classificação de PVU do servidor subjacente nem nada mais: simples! Contudo, em uma configuração quente/quente essa regra não tenha efeito sobre o licenciamento (já que ambas as máquinas são quentes); você verá que em uma configuração de espera morna os requisitos de licenciamento SERVER são diferentes em comparação com outras licenças do DB2.

Além disso, se desejar criar um cluster HADR usando um servidor DB2 Express no DB2 9.5, precisa comprar o DB2 High Availability Feature Pack para obter esse recurso junto com outros recursos relacionados a alta disponibilidade. No DB2 9.7, a licença do DB2 Express SERVER na verdade vem com todos os recursos no High Availability Feature Pack (incluindo HADR) gratuitamente; entretanto, você compra esse feature pack se desejar HADR (ou outros recursos) com um servidor DB2 Express licenciado via as licenças alternativas PVU ou AU. Por esse motivo, entre outros, recomendamos usar essa licença (ou FTL) para quaisquer servidores DB2 Express.

Licença Fixed Term License (FTL)

Embora a licença FTL seja nova para o DB2 Express 9.7, ela tem a mesma metodologia de preço que a antiga licença DB2 Express-C FTL 9.5 (que não está mais disponível). Essa licença fornece acesso a todos os recursos no DB2 Express (diferentemente da predecessora). Uma licença DB2 Express FTL proporciona acesso ao software DB2 Express pelo período de um ano - é uma licença por prazo, em oposição à licença perpétua fornecida com licenças da outras edição do DB2. Ao licenciar um servidor DB2 Express usando uma licença FTL, você simplesmente compra uma licença FTL para cada servidor no cluster - exatamente como as licenças DB2 Express SERVER - não importa qual o tipo de espera (quente, morna ou fria) que é usada. De maneira bem simples, não há necessidade de identificar o nível de atividade de um servidor DB2 Express licenciado usando uma licença FTL no que se refere a licenciamento de alta disponibilidade. Não há mínimos de usuário e não é preciso descobrir a classificação de PVU do servidor subjacente nem nada mais: simples! Enquanto em uma configuração quente/quente, essa regra não tem efeito sobre o licenciamento (uma vez que ambas as máquinas são quentes), você verá que em uma configuração de espera morna os requisitos de licenciamento são diferentes em comparação a outras edições do DB2.

Um servidor DB2 Express licenciado com uma licença FTL fornece acesso a todos os recursos no DB2 High Availability Feature Pack, incluindo HADR. (Observe, porém, que é preciso comprar esse feature pack para ativar HADR, entre outros recursos de alta disponibilidade, se estiver usando uma licença DB2 Express PVU ou AU.) Por esse motivo, entre outros, recomendamos fortemente usar essa licença (ou uma SERVER) para quaisquer servidores DB2 Express.

Licença SOCKET

Uma licença SOCKET é nova para o DB2 9.7 e está disponível somente para servidores DB2 Workgroup. Ao licenciar um servidor DB2 Workgroup usando uma licença SOCKET, você simplesmente licencia o mesmo número de soquetes que no primário para cada servidor , uma vez que essa é uma configuração quente/quente e todos os servidores são totalmente utilizados para operações regulares.

Por exemplo, se você tinha um servidor IBM POWER7 de dois núcleos e quatro vias, compraria quatro licenças DB2 Workgroup SOCKET. Incidentalmente, esse servidor seria classificado em 960 PVUs e você ainda precisaria comprar apenas quatro licenças DB2 Workgroup SOCKET. Para uma configuração quente/quente, você precisaria de oito licenças DB2 Workgroup SOCKET: quatro soquetes para o servidor primário e quatro soquetes para o servidor de espera quente. Sempre que licenciar um servidor DB2 Workgroup, recomendamos fortemente usar essa licença em função da capacidade adicional de CPU que ela oferece ao seu ambiente.

Licença Processor Value Unit (PVU)

Qualquer servidor DB2 pode ser licenciado usando o modelo PVU. Em uma configuração ativa/ativa, toda a classificação de PVU do servidor de espera quente (máquina 1 no nosso exemplo de trabalho) deve ser licenciada adicionalmente. É claro, você usaria essa mesma abordagem para licenciar seu servidor DB2 mesmo se não fosse parte de um cluster de alta disponibilidade, uma vez que sua produção de serviço funciona mesmo assim, então não deve haver nenhuma surpresa aqui.

Se o servidor na Figura 3 utilizasse apenas quatro núcleos de um servidor POWER7, e presumindo que cada máquina estivesse executando em um DB2 Workgroup (que está limitado com essa licença a servidores com uma classificação máxima de 480 PVU a partir de 2Q08), seria preciso comprar um total de 960 PVUs para esta solução: 480 PVUs para máquina 1 e 480 PVUs para a máquina 2.

Licença Authorized User (AU)

Para qualquer produto de servidor DB2 licenciado pelo modelo AU, é preciso licenciar esse ambiente comprando o número total de AUs que o acessarão no primário quente, além do número correspondente de usuários que acessarão o servidor de espera quente também (uma vez que são ambos efetivamente servidores quentes para seus próprios aplicativos e servidores de espera um para o outro).

Uma AU é um único indivíduo (em alguns casos, pode ser um aplicativo ou aplicativos, desde que não atue em nome de outros usuários) com uma identidade específica que reside dentro ou fora da sua empresa. Essas licenças podem ser usadas sobre a Internet também (como um aplicativo de comércio online) porque o usuário final é bem conhecido, uma vez que deve ser especificamente identificável para esta licença. As licenças AU são direitos totais; não há necessidade de licenças de servidor separadas como era o caso no DB2 8, em que você comprava direitos de usuário junto com uma licença de servidor de base. Se você estivesse usando multiplexação ou software de concentração de conexão, esses usuários precisariam ser totalmente identificados e enumerados antes de essas tecnologias serem aplicadas à conexão contada.

É preciso uma licença AU para qualquer um acessando o servidor. Entretanto, não importa quantos usuários estão acessando seu servidor, há alguns mínimos dependentes de edição que precisam ser considerados. As edições DB2 Express ou DB2 Workgroup exigem um mínimo de cinco licenças AU. O DB2 Enterprise requer um mínimo de 25 AUs por 100 PVUs para o servidor subjacente. Dito de outra forma, para cada 100 PVUs no servidor, você exige um pacote de 25 AU. Por exemplo, um servidor com 480 PVUs exigiria como um mínimo 125 licenças AU porque você arredonda a contagem de PVU para a determinação de mínimo de usuários. É claro, se tivesse 150 usuários, precisaria licenciar o servidor além da contagem mínima para o número real de usuários; neste caso, 150 AUs. As licenças AU não são transferíveis através de turnos de trabalho (embora possam ser transferidas para rotatividade de funcionários), e são válidas apenas para um específico . E é claro, uma vez que a Figura 3 é um exemplo de uma configuração quente/quente, que essas regras são controversas, já que precisam ser licenciadas como servidores independentes de qualquer forma.

No exemplo mostrado na Figura 3, se tivesse 100 usuários que precisassem acessar ambos os servidores quentes DB2 Workgroup, precisaria comprar um total de 200 licenças AU do DB2 Workgroup para esses 100 usuários: 2 servidores x 100 AUs por servidor. Mesmo se apenas 12 desses usuários estivesse conectado a um servidor por vez, todos os 100 ainda precisariam ser licenciados para cada servidor (então você ainda precisaria de 200 licenças AU para este exemplo). Se estivesse usando o DB2 Express ou o DB2 Workgroup na Figura 3, e tivesse apenas três usuários na empresa, precisaria de um total de 10 licenças AU do DB2 Express ou DB2 Workgroup (2 servidores x mínimo de 5 AUs) para atender os requisitos mínimos de AU associados a essas edições do DB2.

Se os servidores sendo usados naFigura 3 fossem DB2 Enterprise, como mencionado anteriormente, as coisas são um pouco diferentes: vamos continuar com o exemplo em que consideramos que cada servidor é um servidor de quatro núcleos com base em POWER7 classificado em 480 PVUs. Se tivesse 100 usuários que precisassem acessar ambos os servidores DB2 Enterprise quentes, seria preciso comprar um total de 250 AU do DB2 Enterprise para esses 100 usuário: 2 servidores x 125 AUs por servidor em função do mínimo de 25 usuários por 100 PVU para cada servidor DB2 Enterprise. Novamente, mesmo se apenas 12 desses usuários fosse estar conectado a qualquer servidor DB2 por vez, todos os 125 usuários ainda precisariam ser licenciados parada para .

Voltar para parte superior

Espera morna

Uma configuração de espera morna é aquele em que pelo menos um servidor no cluster de alta disponibilidade não tem um banco de dados DB2 atendendo cargas de trabalho de transações ou consulta de usuários durante os períodos de operação normal. É morna no sentido de que o servidor não está realizando trabalho "útil". Trabalho que é classificado como "não útil" (embora ironicamente possa ser o trabalho mais útil que seu servidor de espera faz) inclui ações administrativas que auxiliam em cenários de failover, como ter o banco de dados em um estado pendente de rollforward para suportar envio de log, dando suporte a envio de log no nível da transação para um ambiente HADR, e assim por diante. Se um dos servidores no cluster de alta disponibilidade falhar, então a carga de trabalho é redistribuída para o servidor de espera morno.

Um entendimento incorreto comum que muitos têm sobre uma configuração morna é que uma máquina de espera morna é um desperdício de recursos quando dedicada unicamente a operações de recuperação. Esse é um entendimento errado desse tipo de configuração. A verdade é que você pode aproveitar uma máquina de espera morna para muitos usos (relacionados ou não relacionados ao DB2) além da função de espera. Por exemplo, você poderia criar uma instância separada do DB2 na máquina de espera morna (dependendo do trabalho relacionado a DB2 que você escolhe realizar aqui, poderia ter implicações de licenciamento) e usá-la como uma máquina de teste ou talvez descarregar outras cargas de trabalho e funções nela. No caso de uma falha, você poderia escalar de volta essas cargas de trabalho (ou recursos alocados para uma partição virtualizada em que executam) e permitir que a máquina de espera morna use todos os recursos do servidor para lidar com a carga do servidor que falhou, contornando, portanto, considerações de carga descritas na discussão de espera quente/quente na última seção.

Um cenário de espera morna é mostrado na Figura 6. Nessa figura, uma configuração de HADR "baunilha" (a capacidade de Leitura em Espera não está sendo usada) que foi criada para um ambiente OLTP de produção. Nesse exemplo, durante períodos de operações normais, a máquina 2 está sendo usada para cargas de trabalho de transação e consulta (observada como Active Work na figura), enquanto a máquina 1 está parada em uma espera morna para a carga de trabalho da máquina 2. A máquina 2 falha e sua carga de trabalho do DB2 é passada para sua máquina 1 parceira morna. Nesse cenário, provavelmente seria o caso de que, se qualquer trabalho (de qualquer tipo) estivesse sendo realizado na máquina 1 antes da falha, ele seria escalado de volta para tratar a nova carga de trabalho após a falha da máquina 2 lidar com a nova carga de trabalho após a falha da máquina 2 (ou a máquina 1 foi originalmente dimensionada para suportar sua carga de trabalho e a carga de trabalho da máquina 2 ao mesmo tempo - caso contrário, você terá um problema de desempenho).

Porque em períodos de operação normal apenas uma máquina é quente de uma perspectiva do DB2 na Figura 6 enquanto a outra está realizando alguma atividade morna, como preparar um parceiro de failover de HADR, essa configuração é frequentemente referida como quente/morno (ou ativo/inativo, em alguns círculos). O conceito importante a observar aqui é que a máquina 1 não estava fazendo nenhum trabalho "significativo" de DB2 antes de a indisponibilidade ocorrer. É claro, em um cenário de Leitura em Espera de HADR ou DB2 pureScale, a "espera" (que não é realmente uma espera, porque é quente) está realizando trabalho significativo e, portanto, nenhuma dessas tecnologias é associada com uma classificação de espera morna ou fria.

Os clientes assumem todos os tipos de abordagens a máquinas de espera. Recomendamos priorizar suas metas e requisitos de negócio com relação a uma máquina em espera. Por exemplo, alguns clientes podem escolher configurar um ambiente de alta disponibilidade em uma máquina em espera e, ao mesmo tempo, usar o banco de dados de espera para uma versão somente leitura mais ou menos atual da máquina de produção - portanto, distribuindo as alocações de custo sobre cada vez mais recursos; você pode fazer isso com HADR a partir do DB2 9.7 Fix Pack 1 ou posterior. Você deve estar ciente de que muitos fornecedores limitam esse modelo a um ou outro, o que significa que enquanto você está lendo o banco de dados, não pode rolar para diante os logs para mantê-los atualizados (se não for um ou outro, há um comprometimento com relação à velocidade da execução do processamento de refazer, entre outras considerações). Subsequentemente, deixar o banco de dados aberto por longos períodos de operações somente leitura nesses ambientes aumenta o mean time to repair (MTTR) no caso de uma falha: exatamente o problema que essa configuração foi projetada para evitar. Outro exemplo é com a leitura de bancos de dados OLTP de espera. Se pensar sobre isso, um banco de dados OLTP é projetado de modo que haja um mínimo de índices. Se começar a executar cargas de trabalho semelhantes a relatório nesse servidor de espera, a espera provavelmente terá várias verificações de tabela, uma vez que não há índices para auxiliar em consultas rápidas. Executar verificações de tabelas completas em um servidor de espera pode consumir tantos recursos que ele pode ter dificuldade em manter o banco de dados sincronizado.

Dependendo dos seus requisitos de disponibilidade, carga de trabalho, entre outros, uma espera morna pode ou não ser a escolha certa para seu ambiente; entretanto, ao planejar para o tipo de espera que deseja suportar, nunca esqueça o motivo pelo qual você tem um ambiente de alta disponibilidade em primeiro lugar - minimizar o MTTR de uma indisponibilidade. O ponto é que o DB2 tem opções para quente/quente também (incluindo alguma tecnologia de leitura em espera HADR que não era parte do DB2 9.7 quando foi disponibilizado pela primeira vez, mas que foram introduzidas no DB2 9.7 Fix Pack 1) e todo o novo DB2 pureScale. Se você ler de um servidor de espera, por exemplo, em uma configuração HADR, esse servidor é instantaneamente considerado quente. Ou seja, a noção de que um servidor de espera morno (da perspectiva do DB2) está apenas parado desperdiçando recursos é um conceito muito mal entendido e frequente quando realmente se olha para ele - mas com o DB2, a escolha fica a seu critério; apenas lembre que o DB2 pode oferecer qualquer configuração desejada.

Considerações de licenciamento para uma máquina de espera morna

A partir do DB2 9.7, há cinco métodos de licenciamento diferentes (alguns estão disponíveis apenas com edições específicas do DB2): SERVER, Fixed Term License (FTL), SOCKET, Authorized User (AU) e Processor Value Unit (PVU). A seguir são detalhadas considerações de licenciamento de alta disponibilidade de que você deve estar ciente para cada licença respectiva.

Licença SERVER

Uma licença SERVER é nova para o DB2 9.7 e está disponível somente para servidores DB2 Express. Ao licenciar um servidor DB2 Express usando uma licença SERVER, você simplesmente compra uma licença para cada servidor no cluster não importa qual o tipo de espera (quente, morna ou fria) que é usada. De maneira bem simples, não há necessidade de identificar o nível de atividade de um servidor DB2 Express licenciado usando uma licença SERVER no que se refere a licenciamento de alta disponibilidade. Não há mínimos de usuário e não é preciso descobrir a classificação de PVU do servidor subjacente nem nada mais: simples!

Além disso, se desejar criar um cluster HADR usando um servidor DB2 Express no DB2 9.5, precisa comprar o DB2 High Availability Feature Pack para obter esse recurso junto com outros recursos relacionados a alta disponibilidade. No DB2 9.7, a licença do DB2 Express SERVER na verdade vem com todos os recursos no High Availability Feature Pack (incluindo HADR) gratuitamente; entretanto, você compra esse feature pack se desejar HADR (ou outros recursos) com um servidor DB2 Express licenciado via as licenças alternativas PVU ou AU. Por esse motivo, entre outros, recomendamos usar essa licença (ou FTL) para quaisquer servidores DB2 Express.

Em um cluster de alta disponibilidade quente/morno, você realmente compraria uma licença SERVER para cada servidor DB2 Express. Se desejasse criar um cluster HADR usando um servidor DB2 Express em DB2 9.5, precisaria comprar o DB2 High Availability Feature Pack para obter esse recurso junto com outros recursos relacionados a alta disponibilidade. o DB2 9.7, a licença SERVER do DB2 Express na verdade vem com todos os recursos incluídos no High Availability Feature Pack (incluindo HADR) gratuitamente. Seria preciso comprar esse feature pack se desejasse usar HADR (ou várias outras tecnologias DB2 relacionadas a alta disponibilidade avançadas) com um servidor DB2 Express licenciado via licenças PVU ou AU.

Licença Fixed Term License (FTL)

Embora a licença FTL seja nova para o DB2 Express 9.7, ela tem a mesma metodologia de preço que a antiga licença DB2 Express-C FTL 9.5 (que não está mais disponível). Essa licença fornece acesso a todos os recursos no DB2 Express (diferentemente da predecessora). Uma licença DB2 Express FTL proporciona acesso ao software DB2 Express pelo período de um ano - é uma licença por prazo, em oposição à licença perpétua fornecida com licenças da outras edição do DB2. Ao licenciar um servidor DB2 Express usando uma licença FTL, você simplesmente compra uma licença FTL para cada servidor no cluster - exatamente como as licenças DB2 Express SERVER - não importa qual o tipo de espera (quente, morna ou fria) que é usada. De maneira bem simples, não há necessidade de identificar o nível de atividade de um servidor DB2 Express licenciado usando uma licença FTL no que se refere a licenciamento de alta disponibilidade. Não há mínimos de usuário e não é preciso descobrir a classificação de PVU do servidor subjacente nem nada mais: simples!

Em um cluster quente/morno de alta disponibilidade, você na verdade compraria uma licença FTL para cada servidor DB2 Express. Se você desejasse criar um cluster HADR usando um servidor DB2 Express no DB2 9.5, teria de comprar o DB2 High Availability Feature Pack para obter esse recurso junto com outros recursos relacionados a alta disponibilidade. No DB2 9.7, a licença DB2 Express FTL vem com todos os componentes de um High Availability Feature Pack (incluindo HADR) gratuitamente; na verdade, uma licença DB2 Express FTL dá direito a todos os recursos disponíveis no DB2 High Availability Feature Pack! É preciso comprar esse Feature Pack se desejar HADR (ou várias outras tecnologias DB2 avançadas relacionadas a alta disponibilidade) com um servidor DB2 Express licenciado via licenças PVU ou AU. Por esse motivo, entre outros, recomendamos fortemente usar essa licença (ou uma SERVER) para quaisquer servidores DB2 Express.

Licença SOCKET

Uma licença SOCKET também é nova no DB2 9.7 e é somente para servidores DB2 Workgroup. Ao licenciar um servidor DB2 Workgroup usando uma licença SOCKET, você simplesmente compra uma licença para o número de soquetes que o DB2 usará no servidor primário. Se tiver um servidor de dois núcleos de quatro vias IBM POWER7, compraria quatro licenças SOCKET do DB2 Workgroup. Para o servidor em espera morna, simplesmente compraria uma licença SOCKET adicional, não importa o contexto. No exemplo da Figura 6 , você precisaria de 4 soquetes (máquina quente) + 1 soquete (espera morna) = 5 soquetes.

Incidentalmente, o servidor primário seria classificado em 960 PVUs e você ainda precisaria comprar apenas quatro licenças SOCKET do DB2 Workgroup. Sempre que licenciar um servidor DB2 Workgroup, recomendamos fortemente usar essa licença em função da capacidade adicional de CPU que ela oferece ao seu ambiente.

Licença Processor Value Unit (PVU)

Para qualquer servidor DB2 licenciado usando o modelo PVU, você licencia um servidor de espera morna para 100 PVUs não importa em que tipo de arquitetura de núcleo de processamento o servidor está baseado. Em outras palavras, se um servidor com quatro processadores AMD de quatro núcleos equivale a 800 PVUs e um servidor com dois processadores POWER7 de quatro núcleos equivale a 960 PVUs, com um servidor de espera morna, você apenas o licencia com 100 PVUs da edição correspondente do DB2.

Por exemplo, se o servidor na Figura 6 utilizasse apenas quatro núcleos de um servidor POWER7, e presumindo que cada máquina estivesse executando o DB2 Workgroup (que não está mais limitado a servidores com uma classificação máxima de 480 PVU desde junho de 2011), seria preciso comprar um total de 580 PVUs para esta solução: (480 PVUs para a máquina 2 = 100 PVUs para a máquina 1 de espera morna ).
OBS.: Desde junho de 2011, a restrição de 480 PVUs foi removida. Isso significa que agora é possível instalar e usar o DB2 Workgroup em servidores físicos ou virtuais com mais de 480 PVUs, desde que você tenha licenciado adequadamente todas as PVUs a que o DB2 Workgroup tem acesso, até 16 núcleos. Se o servidor físico ou virtual tiver mais de 16 núcleos, você ainda paga apenas por 16 núcleos, porque isso é tudo o que o DB2 usará. Isso aplica-se às versões 9.5 e 9.7.

Licença Authorized User (AU)

Para qualquer servidor DB2 que seja licenciado pelo modelo AU, é preciso licenciar o servidor de espera morna comprando o número mínimo de AUs para a edição por ser um servidor de espera morna. Para DB2 Express e DB2 Workgroup, em função de o número mínimo de cinco AUs que é preciso licenciar para qualquer instalação, um servidor de espera morna exigiria cinco licenças AU. Na figura Figura 6, se um servidor DB2 Workgroup fosse quente e estivesse configurado para participar de um cluster quente/morno HADR, e houvesse 100 usuários, seria preciso comprar um total de 105 licenças AU do DB2 Workgroup para esses 100 usuários: 100 AUs + 5 AUs para o servidor de espera morna. (É claro, o número mínimo de licenças AU para o servidor quente precisa ser cumprido se o número de usuários for inferior à exigência mínima).

Se a Figura 6 estivesse usando o DB2 Enterprise, seria um pouco diferente e também um pouco mais confusas. No DB2 Enterprise, o número mínimo de AUs é de 25 para cada 100 PVUs (conforme detalhado antes neste artigo). Uma vez que é preciso ter 100 PVUs licenciadas como um mínimo para uma espera morna no modelo PVU com o servidor DB2 Enterprise, você converte o mínimo de 100 PVUs para 25 AUs e isso torna-se o número mínimo de AUs necessárias para um servidor de espera morna DB2 Enterprise licenciado usando o modelo AU. Vamos esclarecer com um exemplo usando a Figura 6. Se aos servidores na Figura 6 fossem dois servidores de dois núcleos com base em Intel x86 de soquete, a classificação total de PVU para o servidor quente seria de 200 PVUs. Se houvesse apenas três usuários acessando o servidor DB2 Enterprise quente, ainda seria preciso um total de 75 AUs para esta configuração: (200/100=2 x 25 AUs) para o servidor quente mais 25 AUs para o servidor de espera morna DB2 Enterprise. Entretanto, se os servidores na Figura 6 fossem dois servidores de dois núcleos POWER7 de soquete (então há um total de quatro núcleos nesse servidor), a classificação total de PVU para o servidor quente seria de 480 PVUs. Se houvesse apenas três usuários acessando o servidor DB2 Enterprise quente, seria preciso agora de um total de 150 usuários de AUs para esta configuração: (480/100=4,8, arredondado para 5 x 25 AUs para o servidor quente = 125 AUs) + o mínimo de 25 AUs para o servidor de espera morna DB2 Enterprise.

Voltar para parte superior

Espera fria

Uma configuração de espera fria é aquela em que pelo menos um servidor no cluster não tem um banco de dados DB2 atendendo cargas de trabalho de transações ou consultas de usuário durante os períodos de operação normal e não está realizando nenhuma ação administrativa que auxilie em cenários de failover, como ter um banco de dados em um estado pendente de rollforward para dar suporte a HADR; na verdade, um servidor de espera fria pode não estar nem ligado. Um cenário de espera fria é mostrado na Figura 7.

Neste exemplo, durante períodos de operação normal, a máquina 2 está sendo usada para cargas de trabalho de transação e consulta (observadas como Active Work na figura), enquanto a máquina 1 não tem uma instância do DB2 iniciada. Talvez seja inclusive o caso de que o DB2 está instalado na máquina e está desligado; no caso de uma falha, a máquina 1 é inicializada, recuperada para um certo ponto no tempo a partir de uma imagem de backup e aberta para transações do usuário. Também poderia ser o caso de máquina 1 estar configurada para ser parte de um cluster Tivoli SA-MP (entre outras opções de armazenamento em cluster de alta disponibilidade, incluindo PowerHA para AIX), mas a instância do banco de dados não está iniciada. Como se pode imaginar, a configuração de espera fria não é tanto uma solução de disponibilidade no sentido de que o MTTR normalmente será muito mais longo que uma configuração de espera quente ou morna. Isso dito, pode adequar-se às necessidades de alguns dos seus aplicativos, e se for o caso, o custo dessa solução fica realmente atraente no DB2 9.5 e posteriores pelos motivos descritos antes neste artigo.

Considerações de licenciamento para uma máquina de espera fria

Um servidor de espera fria DB2 não precisa ser licenciado e, portanto, obviamente não há considerações de licenciamento. Uma boa regra geral para determinar se uma máquina de espera pode ser classificada como fria é ver se a instância do DB2 está iniciada; entretanto, há algumas exceções. Por exemplo, se for obtida uma imagem de captura instantânea de um servidor de produção e iniciado o servidor de espera DB2 com o único objetivo de realizar backup e então interrompê-lo, isso seria considerado uma espera fria e nenhuma licença para o servidor seria necessária.

Então esse é um exemplo perfeito de como as regras de licenciamento nas últimas liberações do DB2 economizam dinheiro, e quem não está em busca disso nesta economia difícil? Vamos presumir que você estivesse licenciando um servidor DB2 9 Workgroup junto com o pureXML Feature Pack para um aplicativo com base em XML com alguns requisitos de alta disponibilidade. No DB2 9, você teria de licenciar totalmente o servidor quente (como esperado) para o DB2 e o pureXML Feature Pack; além disso, o servidor frio teria de ser licenciado para as 100 PVUs do DB2 Workgroup e as 100 PVUs do pureXML Feature Pack. No DB2 9.7, apenas compraria licenças do DB2 Workgroup para o servidor quente. O recurso pureXML é gratuito em todas as edições do DB2 (desde 9 de fevereiro de 2009) e um servidor de espera fria não exige licenciamento. Agora adicione o fato de que é possível licenciar o DB2 Workgroup com uma licença SOCKET e terá duplicado a capacidade da solução com base em XML de alta disponibilidade e reduzido os custos em mais de 50%!

Voltar para parte superior

Alcance mais longe - ou seja, disponibilidade

Como se pode ver, há muitas opções de alta disponibilidade com o DB2. Recomendamos que os clientes criem classificações para aplicativos que exigem disponibilidade; por exemplo Bronze, Prata e Ouro. Talvez seja o caso de que qualquer coisa classificada como Bronze aproveitaria uma espera fria e um cluster integrado DB2; enquanto uma solução classificada como Prata aproveitaria a tecnologia DB2 HADR; e, por fim, uma solução classificada como Ouro seria uma configuração de espera quente, como DB2 pureScale. Reunimos alguma folha de cola com algumas das possíveis soluções de alta disponibilidade e suas respectivas classificações na Tablela 2.

Gostaríamos de observar neste ponto que não é sempre o caso de que tudo precisa ser uma solução de nível Ouro. Todos pensam que precisam de disponibilidade 24 horas por dia/sete dias por semana para todos os aplicativos, mas em nossa ampla experiência de consultoria isso não é verdade. Por exemplo, um cliente tinha um aplicativo crítico para a missão que precisava de disponibilidade 24 horas por dia, sete dias por semana, mas seus outros aplicativos poderiam suportar uma indisponibilidade de até dois dias. Nesses casos, faria sentido tratar todos da mesma forma de uma perspectiva de disponibilidade? Se você tivesse um orçamento ilimitado talvez. Escolha a solução de disponibilidade certa que atende o acordo de nível de serviço que está apoiando seu trabalho: alta disponibilidade em uma curva de custo linear. Além do software, quanto mais alta disponibilidade você deseja, normalmente mais acabará pagando (pense em redundância, licenciamento, energia, entre outros fatores). O ponto é que nem tudo precisa ser ultradisponível; seja inteligente e aproveite definitivamente a tecnologia certa para os requisitos de alta disponibilidade certos.

Embora fora do escopo deste artigo, para fins que o material seja completo, incluímos um pouco sobre o "primo" da alta disponibilidade, a recuperação de desastre, na Tablela 3. (As mesmas considerações que você usa para determinar o licenciamento adequado para alta disponibilidade aplica-se a recuperação de desastre):

Recursos

Aprender

• "Comparação dos servidores de dados DB2 9.7 distribuídos" (developerWorks, setembro de 2009): em uma tabela de comparação lado a lado, o autor Paul Zikopoulos torna fácil de entender as regras de licenciamento básicas, as funções e as diferenças de recursos entre os integrantes da família de servidores DB2 9.7 distribuídos.
  
  
• "Qual edição distribuída do DB2 9.7 é a certa para você?" (developerWorks, setembro de 2009): conheça os detalhes que tornam cada edição do DB2 9.7 única. O autor define as especificações para cada edição, descreve as considerações de licenciamento, as mudanças históricas do DB2 9 e descreve algumas coisas interessantes que os clientes estão fazendo com cada edição do DB2.
  
  
• "DB2 and IBM Processor Value Unit (PVU) Pricing" (developerWorks, setembro de 2009): esse artigo descreve como licenciar o DB2 usando a nova métrica de Unidade de Valor, bem como vários cenários úteis do dia a dia.
  
  
• Visite o página de recursos do developerWorks para o DB2 para Linux, UNIX e Windows para ler artigos e tutoriais e se conectar a outros recursos para expandir as suas qualificações no DB2.
  
  
• Saiba mais sobre os conceitos, o planejamento e a instalação dos DB2 Express-C, a versão gratuita do DB2 Express Edition para a comunidade.
  
  
• Information Management do developerWorks: saiba mais sobre os produtos IBM Information Management. Encontre documentação técnica, artigos de instruções, treinamento, downloads, informações de produto e mais.
  
  

Obter produtos e tecnologias

• Faça download de uma versão de teste gratuita do DB2 para Linux, UNIX e Windows.
  
  
• Agora é possível usar o DB2 gratuitamente. Faça download do código fonte de DB2 Express-C, uma versão gratuita do DB2 Express Edition para a comunidade que oferece os mesmos recursos de dados centrais que o DB2 Express Edition e fornece uma base sólida para e implementar aplicativos.
  
  

Discutir

• Participar do fórum de discussão.
  
  
• blogs do developerWorks: Participe da comunidade do developerWorks.
  
  

Sobre os autores

Paul C. Zikopoulos, BA, MBA, é Program Director da equipe DB2 Evangelist na IBM. Ele é escritor e palestrante premiado com mais de 14 anos de experiência com DB2. Paul escreveu mais de 230 artigos de revista e 11 livros sobre DB2, incluindo Information on Demand: Introduction to DB2 9.5 New Features, DB2 9 Database Administration Certification Guide and Reference (6ª Edição), DB2 9: New Features, Information on Demand: Introduction to DB2 9 New Features, Off to the Races with Apache Derby, DB2 Version 8: The Official Guide, DB2: The Complete Reference, DB2 Fundamentals Certification for Dummies, DB2 for Dummies e A DBA's Guide to Databases on Linux. Paul é Certified Advanced Technical Expert em DB2 (DRDA e Clusters) e Certified Solutions Expert em DB2 (BI e DBA). No seu tempo livre, ele gosta de todo tipo de atividade esportiva, incluindo correr com seu cachorro Chachi, evitar golpes no treinamento de MMA e tentar entender o mundo de acordo com Chloë, sua filha. É possível entrar em contato com ele em paulz_ibm@msn.com.

Steven Astorino, bacharel em ciência da computação, é Senior Manager de Desenvolvimento do DB2, supervisionando o Desenvolvimento de Informações, a Experiência do Usuário e o Desenvolvimento de Instalação do DB2. Ele tem muitos anos de experiência em Bancos de Dados, incluindo DB2 e Replicação de Banco de Dados em tempo real. Começou sua carreira como desenvolvedor e exerceu uma ampla gama de funções, desde o desenvolvimento de software e o controle de qualidade até o desenvolvimento de informações e a experiência do usuário. No início da carreira, Steven passou vários anos trabalhando com tecnologias de teste de redes para o segmento de telecomunicações, exercendo um papel fundamental no fornecimento de soluções de teste de VoIP. A alta qualidade, eficiência e foco no cliente estão entre os seus objetivos e diretivas mais importantes, para garantir uma excelente satisfação e experiência do cliente. É possível entrar em contato com ele pelo e-mail: astorino@ca.ibm.com.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Espera quente
• Espera morna
• Espera fria
• Alcance mais longe - ou seja, disponibilidade
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

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

---

Saiba mais