História
O Adabas é conhecido por seu excelente desempenho, em particular pela sua capacidade de processar grandes volumes de dados sem degradação de desempenho, sua sobrecarga mínima em relação à administração do sistema, e seu alto nível de estabilidade e confiabilidade (operação contínua, recuperação eficiente e confiável de erros). Tradicionalmente, a Adabas usava multi-threading para atender muitos usuários simultaneamente. Para muitos sites, este foi um bom compromisso entre os requisitos de processamento e manter a sobrecarga de processamento, o que era necessário para garantir a integridade dos dados, ao mínimo. No entanto, havia muitos sites e aplicativos que exigiam ainda mais throughput do que o multi-threading oferecido. Software AG, em seguida, introduziu Adabas SMP que fez uso de multi-processamento. Adabas SMP minimizou a sobrecarga para a integridade dos dados por meio de um núcleo de atualização e vários núcleos de somente leitura.
Quando a IBM ofereceu sua solução de cluster para mainframes, o Parallel Sysplex, a Software AG desenvolveu uma solução de "compartilhamento de dados", os Serviços de Cluster, para suportar os recursos do Parallel Sysplex. Com os Serviços de Cluster, vários núcleos podem ser executados em uma única imagem de sistema operacional (LPAR) e em diferentes CPUs em um ambiente Sysplex Paralelo. O objetivo era tornar disponível o poder de processamento combinado de várias CPUs para um único banco de dados e aumentar a disponibilidade e o funcionamento contínuo, evitando pontos de falha únicos. Gone foi o único núcleo de atualização como uma instância para um único ponto de falha. Agora, todos os núcleos eram homogêneos e capazes de processamento de atualização. Em caso de falha de um núcleo, um peer to peer mecanismo de recuperação de nível foi estabelecido para que tal falha não seria perceptível pelos usuários do aplicativo do banco de dados.
Para manter a sobrecarga dos Serviços de Cluster dentro dos limites, foram introduzidos e implementados no Cluster Services vários conceitos inovadores de design, como um protocolo de bloqueio otimista para bloqueio interno do RABN. O esforço de desenvolvimento foi substancial e provavelmente o maior projeto na história do desenvolvimento da Adabas.
O sucesso dos Serviços de Cluster convenceu a Software AG que os mesmos princípios poderiam ser aplicados para sites, o que exigia mais débito, mas dentro de uma única imagem de sistema operacional.
Adabas SMP foi substituído por um novo produto chamado Parallel Services. Os objetivos foram melhor throughput, menos CPU overhead e um projeto mais robusto e confiável. O mesmo mecanismo de recuperação peer to peer seria aplicado para aumentar a disponibilidade e operação contínua.
Objetivos dos Serviços Paralelos
Os principais objetivos de desenvolvimento dos Serviços Paralelos Adabas foram:
Performance melhorada:
O throughput (comandos Adabas por unidade de tempo) deveria ser aumentado usando recursos de CPU de vários processadores simultaneamente. A taxa de transferência deve ser escalável, ou seja, deve aumentar o mais linearmente possível com o número de núcleos em um cluster. Quando comparado com o uso de um único núcleo Adabas, Parallel Services resultará em um aumento pequeno, mas inevitável, no consumo de CPU. Este consumo de CPU, no entanto, deve permanecer dentro de limites estreitos, e deve aumentar apenas muito ligeiramente em relação à carga de trabalho sempre que o número de núcleos é ampliada.
Transparência da aplicação:
O comportamento do Adabas Parallel Services em relação aos programas de aplicação deve ser compatível com o de um único núcleo Adabas. Para um programa aplicativo, ele deve ser transparente se ele está sendo executado com um único núcleo ou com o Adabas Parallel Services, e também deve ser transparente quanto ao núcleo específico dentro de um cluster está processando os comandos do programa aplicativo.
Maior disponibilidade:
Se um núcleo de Adabas aborta, os outros núcleos podem continuar a funcionar praticamente sem interrupções. (Nenhum ponto de falha em nosso software). Os serviços paralelos têm menos sobrecarga de CPU do que os serviços de cluster do Adabas. A principal razão para isso é que uma operação típica contra a facilidade de acoplamento custa aproximadamente um quarto a um terço do tempo médio de CPU requerido por um comando Adabas em um ambiente bem ajustado OLTP. Nos serviços paralelos, a função da facilidade de acoplamento é substituída por operações num espaço de dados. Estas operações são mais baratas uma vez que, em comparação com a facilidade de acoplamento, todas as comunicações permanecem dentro do mesmo sistema operativo. As comunicações entre diferentes CPUs, que são responsáveis pela maior parte da sobrecarga da CPU nos Serviços de Cluster, não existem nos Serviços Paralelos.
Arquitetura
Com Adabas, um núcleo trabalha em um banco de dados. Com serviços paralelos, até 31 núcleos podem trabalhar na mesma base de dados. Cada núcleo do cluster executa seu próprio processo em seu próprio espaço de endereço conectado a um espaço de dados. Os conjuntos de dados que compõem o banco de dados são acessíveis de todos os núcleos. Para a sincronização, os núcleos usam uma estrutura de cache comum e uma estrutura de bloqueio no espaço de dados. Além disso, os núcleos trocam mensagens enviando chamadas internas Adabas entre si.
Um único núcleo Adabas usa um conjunto de dados de trabalho para armazenar resultados intermediários, bem como dados de proteção necessários para a recuperação de reinicialização. Além disso, o núcleo grava dados de proteção em dois conjuntos de dados do Registro de Proteção que são usados para recuperação de arquivamento. Em Serviços Paralelos, cada núcleo tem seus próprios conjuntos de dados de Log de Trabalho e Proteção, que são escritos apenas por esse núcleo, mas que podem ser lidos por todos os outros núcleos.
As funções do núcleo em Adabas Parallel Services são totalmente simétricas: cada núcleo pode executar todas as operações.
No entanto, existem operações que em um dado momento podem ser executadas por apenas um núcleo. Um exemplo de tal operação é um bufferflush, que grava blocos alterados da estrutura de cache para o banco de dados. Ainda assim, o bufferflush seguinte pode ser executado por um núcleo diferente.
Operações de Bloco de Banco de Dados
O Adabas Parallel Services usa uma estrutura de cache no espaço de dados. No entanto, sempre que a alocação virtual de 64 bits está disponível, o espaço de cache pode ser alocado através de um parâmetro ADARUN em um espaço de cache de 64 bits fora do espaço de dados. Os núcleos do cluster gravam todos os blocos de banco de dados, que foram alterados, para essa estrutura de cache. O processo bufferflush grava os blocos alterados regularmente do espaço de dados para o banco de dados. Os blocos que não foram alterados pelos núcleos são ainda registados com a estrutura de cache, relativamente à presença de cópias destes blocos no conjunto de memória intermédia local dos núcleos individuais, de modo que estas cópias podem ser marcadas como inválidas sempre que qualquer um destes núcleos escrever Alterou versões desses blocos para o cache global.
Bloquear atualizações sem bloqueio
O Adabas Parallel Services usa um método otimista para leitura e alteração de blocos, onde os blocos não são bloqueados. Uma lógica de comparação e de troca é usada para escrever blocos alterados para a estrutura de cache. Esta função executa a operação de escrita somente se nenhum outro núcleo tiver escrito o bloco para o cache após o momento em que o bloco foi lido pela última vez ou escrito pelo primeiro núcleo. Se a operação de escrita falhar devido a uma alteração conflitante, o núcleo tentando a operação de escrita deve reler o bloco alterado, repetir suas próprias alterações e solicitar novamente a operação de gravação para o cache. Este método de permitir alterações conflitantes em blocos é possível porque bloqueios no nível de registro de dados impedem núcleos de cluster diferentes de atualizar simultaneamente o mesmo objeto em um bloco. Em que atualizações conflitantes sempre se aplicam a diferentes partes de um bloco, eles podem ser repetidos se o bloco subjacente é alterado abruptamente.
A maioria das operações de atualização de índice envolve apenas um único bloco no nível mais baixo (índice normal) da árvore de índice. Neste caso, o Adabas Parallel Services altera o bloco sem bloqueá-lo previamente. Se a operação de escrita para o cache do bloco alterado falhar porque outro núcleo mudou o mesmo bloco, então o primeiro núcleo deve reler o bloco e repetir sua atualização. É possível que no ínterim a estrutura de índice tenha sido alterada. Neste caso, o núcleo também deve repetir o posicionamento dentro do índice.
Algumas operações de atualização alteram a estrutura de índice. Ou seja, eles mudam campos nos níveis de índice superior que contêm referências físicas para níveis inferiores. Um exemplo típico é uma atualização que divide um bloco de índice em dois porque ele é executado completamente. Uma referência deve então ser inserida no próximo nível mais alto para indicar a localização do novo bloco. Esta informação de estrutura é vital para posicionamento de índice, bem como para ler, pesquisar e atualizar comandos. Incoerências temporárias podem influenciar a correção das operações paralelas. Portanto, para atualizações complexas que resultam em alterações de estrutura no índice, os blocos envolvidos são bloqueados inteiramente para impedir o uso paralelo durante a atualização.
Para um único núcleo de Adabas, a sincronização de operações de índice paralelas é realizada definindo bloqueios de leitura e escrita nos blocos de controle que são usados para gerenciar o pool de buffer. Como todas as operações participantes têm acesso direto a esses blocos de controle, uma sincronização eficiente é possível.
No Adabas Parallel Services, o método direto de sincronização de operações de índice conflitantes requer o uso de bloqueios de leitura e gravação no espaço de dados.
Recuperação
Embora em menor grau do que as operações de banco de dados, a lógica de recuperação do Adabas também foi afetada pela extensão dos Serviços Paralelos. Isso envolveu não tanto o apoio de transações individuais (recuperação de transações), mas sim o tratamento de situações de erro que causam um aborto de um núcleo Adabas, bem como erros que causam danos ou destruição do banco de dados.
Transação e reinicie a recuperação
Durante a operação, a Adabas grava registros de proteção para atualizações e transações para o chamado conjunto de dados de trabalho. Se o núcleo Adabas deve abortar, essas informações de proteção são usadas para retornar o banco de dados a um estado fisicamente e logicamente consistente. A escrita de blocos alterados para o banco de dados ocorre de forma assíncrona para a execução de comandos de atualização ea alteração de blocos no pool de buffer. Os blocos modificados podem ser gravados no banco de dados antes que as atualizações tenham sido confirmadas até o final da transação correspondente (roubar). No entanto, eles não precisam necessariamente ser gravados no banco de dados no final da transação (noforce). Portanto, durante uma recuperação de reinício após um aborto do núcleo Adabas, todas as transações que terminaram, mas cujas atualizações não foram armazenadas no banco de dados antes do aborto, devem ser repetidas (refazer, conseqüência de nenhuma força). Por outro lado, todas as atualizações, que foram armazenadas no banco de dados como parte de uma transação, que ainda não estava concluída no momento do aborto, devem ser retiradas do banco de dados (desfazer, conseqüência do roubo). Os registros de proteção, Que o núcleo escreve para o conjunto de dados de trabalho, contém as informações necessárias para as operações refazer e desfazer. Em Adabas Parallel Services, cada núcleo tem seu próprio conjunto de dados de trabalho, e somente o próprio núcleo escreve dados de proteção para seu próprio conjunto de dados de trabalho. No entanto, cada núcleo é capaz de ler os registros de proteção criado por outro núcleo dentro do cluster. O backout de transações individuais (por exemplo, comandos backout (reversão)) funciona em um núcleo Paralelo da mesma forma que com um único núcleo. O núcleo lê os registros de proteção necessários de seu próprio conjunto de dados de trabalho e faz o backup das atualizações da transação. E somente o próprio núcleo escreve dados de proteção para seu próprio conjunto de dados de Trabalho. No entanto, cada núcleo é capaz de ler os registros de proteção criado por outro núcleo dentro do cluster. O backout de transações individuais (por exemplo, comandos backout (reversão)) funciona em um núcleo Paralelo da mesma forma que com um único núcleo. O núcleo lê os registros de proteção necessários de seu próprio conjunto de dados de trabalho e faz o backup das atualizações da transação. E somente o próprio núcleo escreve dados de proteção para seu próprio conjunto de dados de Trabalho. No entanto, cada núcleo é capaz de ler os registros de proteção criado por outro núcleo dentro do cluster. O backout de transações individuais (por exemplo, comandos backout (reversão)) funciona em um núcleo Paralelo da mesma forma que com um único núcleo. O núcleo lê os registros de proteção necessários de seu próprio conjunto de dados de Trabalho e faz o backup das atualizações da transação.
Se todos os núcleos ativos abortarem, o núcleo que é iniciado a seguir inicia a recuperação de reinício. Esta é a recuperação off-line, durante a qual o núcleo lê os registros de proteção dos conjuntos de dados de trabalho de todos os núcleos de cluster previamente ativos e executa, em essência, a mesma lógica de recuperação que para um único núcleo. Antes de poderem ser aplicados, os registos de protecção dos vários conjuntos de dados de trabalho devem ser colocados em ordem cronológica. Isso é possível, pois cada registro de proteção contém um carimbo de data / hora que indica exatamente quando ele foi criado.
Se um ou mais, mas não todos, os núcleos devem abortar, os núcleos remanescentes executam a recuperação on-line. Cada núcleo permite um certo tempo para todas as transações correntemente em execução para atingir conclusão normal, após o qual todas as atividades restantes são interrompidas e as conexões com a estrutura de cache e bloqueio são encerradas. Isso resulta na perda de todos os dados nessas estruturas. O núcleo então executa a lógica de recuperação offline, após a qual todos os núcleos podem se conectar a novas estruturas de cache e bloqueio, e as operações normais podem continuar. Durante todo esse processo, os contextos do usuário permanecem intactos nos núcleos que não abortaram.
Conclusão
Testes de clientes mostraram que os procedimentos acima descritos para o aperfeiçoamento de Parallel Services alcançaram resultados impressionantes. Em um esforço conjunto com a IBM no ano passado, mais de 300.000 chamadas Adabas foram executadas por segundo tempo decorrido em um mainframe IBM comercial no Poughkeepsie da IBM, centro de testes de Nova York. Isto é 100% mais do que poderia ter sido realizado com um único núcleo. Isso faz com que o Parallel Services seja o produto ideal para qualquer site que tenha que lidar com requisitos de alto rendimento ou que precise se preparar para rajadas repentinas de alta atividade. O teste foi executado no z / OS V1.8, que suporta mais de 128 GB de memória real em uma única imagem. A CPU consistia em uma série z9 com 32 processadores que suportam memória virtual de 64 bits.
Retirado
By Reiner Makohl, Software AG Germany
O Adabas é conhecido por seu excelente desempenho, em particular pela sua capacidade de processar grandes volumes de dados sem degradação de desempenho, sua sobrecarga mínima em relação à administração do sistema, e seu alto nível de estabilidade e confiabilidade (operação contínua, recuperação eficiente e confiável de erros). Tradicionalmente, a Adabas usava multi-threading para atender muitos usuários simultaneamente. Para muitos sites, este foi um bom compromisso entre os requisitos de processamento e manter a sobrecarga de processamento, o que era necessário para garantir a integridade dos dados, ao mínimo. No entanto, havia muitos sites e aplicativos que exigiam ainda mais throughput do que o multi-threading oferecido. Software AG, em seguida, introduziu Adabas SMP que fez uso de multi-processamento. Adabas SMP minimizou a sobrecarga para a integridade dos dados por meio de um núcleo de atualização e vários núcleos de somente leitura.
Quando a IBM ofereceu sua solução de cluster para mainframes, o Parallel Sysplex, a Software AG desenvolveu uma solução de "compartilhamento de dados", os Serviços de Cluster, para suportar os recursos do Parallel Sysplex. Com os Serviços de Cluster, vários núcleos podem ser executados em uma única imagem de sistema operacional (LPAR) e em diferentes CPUs em um ambiente Sysplex Paralelo. O objetivo era tornar disponível o poder de processamento combinado de várias CPUs para um único banco de dados e aumentar a disponibilidade e o funcionamento contínuo, evitando pontos de falha únicos. Gone foi o único núcleo de atualização como uma instância para um único ponto de falha. Agora, todos os núcleos eram homogêneos e capazes de processamento de atualização. Em caso de falha de um núcleo, um peer to peer mecanismo de recuperação de nível foi estabelecido para que tal falha não seria perceptível pelos usuários do aplicativo do banco de dados.
Para manter a sobrecarga dos Serviços de Cluster dentro dos limites, foram introduzidos e implementados no Cluster Services vários conceitos inovadores de design, como um protocolo de bloqueio otimista para bloqueio interno do RABN. O esforço de desenvolvimento foi substancial e provavelmente o maior projeto na história do desenvolvimento da Adabas.
O sucesso dos Serviços de Cluster convenceu a Software AG que os mesmos princípios poderiam ser aplicados para sites, o que exigia mais débito, mas dentro de uma única imagem de sistema operacional.
Adabas SMP foi substituído por um novo produto chamado Parallel Services. Os objetivos foram melhor throughput, menos CPU overhead e um projeto mais robusto e confiável. O mesmo mecanismo de recuperação peer to peer seria aplicado para aumentar a disponibilidade e operação contínua.
Objetivos dos Serviços Paralelos
Os principais objetivos de desenvolvimento dos Serviços Paralelos Adabas foram:
Performance melhorada:
O throughput (comandos Adabas por unidade de tempo) deveria ser aumentado usando recursos de CPU de vários processadores simultaneamente. A taxa de transferência deve ser escalável, ou seja, deve aumentar o mais linearmente possível com o número de núcleos em um cluster. Quando comparado com o uso de um único núcleo Adabas, Parallel Services resultará em um aumento pequeno, mas inevitável, no consumo de CPU. Este consumo de CPU, no entanto, deve permanecer dentro de limites estreitos, e deve aumentar apenas muito ligeiramente em relação à carga de trabalho sempre que o número de núcleos é ampliada.
Transparência da aplicação:
O comportamento do Adabas Parallel Services em relação aos programas de aplicação deve ser compatível com o de um único núcleo Adabas. Para um programa aplicativo, ele deve ser transparente se ele está sendo executado com um único núcleo ou com o Adabas Parallel Services, e também deve ser transparente quanto ao núcleo específico dentro de um cluster está processando os comandos do programa aplicativo.
Maior disponibilidade:
Se um núcleo de Adabas aborta, os outros núcleos podem continuar a funcionar praticamente sem interrupções. (Nenhum ponto de falha em nosso software). Os serviços paralelos têm menos sobrecarga de CPU do que os serviços de cluster do Adabas. A principal razão para isso é que uma operação típica contra a facilidade de acoplamento custa aproximadamente um quarto a um terço do tempo médio de CPU requerido por um comando Adabas em um ambiente bem ajustado OLTP. Nos serviços paralelos, a função da facilidade de acoplamento é substituída por operações num espaço de dados. Estas operações são mais baratas uma vez que, em comparação com a facilidade de acoplamento, todas as comunicações permanecem dentro do mesmo sistema operativo. As comunicações entre diferentes CPUs, que são responsáveis pela maior parte da sobrecarga da CPU nos Serviços de Cluster, não existem nos Serviços Paralelos.
Arquitetura
Com Adabas, um núcleo trabalha em um banco de dados. Com serviços paralelos, até 31 núcleos podem trabalhar na mesma base de dados. Cada núcleo do cluster executa seu próprio processo em seu próprio espaço de endereço conectado a um espaço de dados. Os conjuntos de dados que compõem o banco de dados são acessíveis de todos os núcleos. Para a sincronização, os núcleos usam uma estrutura de cache comum e uma estrutura de bloqueio no espaço de dados. Além disso, os núcleos trocam mensagens enviando chamadas internas Adabas entre si.
Um único núcleo Adabas usa um conjunto de dados de trabalho para armazenar resultados intermediários, bem como dados de proteção necessários para a recuperação de reinicialização. Além disso, o núcleo grava dados de proteção em dois conjuntos de dados do Registro de Proteção que são usados para recuperação de arquivamento. Em Serviços Paralelos, cada núcleo tem seus próprios conjuntos de dados de Log de Trabalho e Proteção, que são escritos apenas por esse núcleo, mas que podem ser lidos por todos os outros núcleos.
As funções do núcleo em Adabas Parallel Services são totalmente simétricas: cada núcleo pode executar todas as operações.
No entanto, existem operações que em um dado momento podem ser executadas por apenas um núcleo. Um exemplo de tal operação é um bufferflush, que grava blocos alterados da estrutura de cache para o banco de dados. Ainda assim, o bufferflush seguinte pode ser executado por um núcleo diferente.
Operações de Bloco de Banco de Dados
O Adabas Parallel Services usa uma estrutura de cache no espaço de dados. No entanto, sempre que a alocação virtual de 64 bits está disponível, o espaço de cache pode ser alocado através de um parâmetro ADARUN em um espaço de cache de 64 bits fora do espaço de dados. Os núcleos do cluster gravam todos os blocos de banco de dados, que foram alterados, para essa estrutura de cache. O processo bufferflush grava os blocos alterados regularmente do espaço de dados para o banco de dados. Os blocos que não foram alterados pelos núcleos são ainda registados com a estrutura de cache, relativamente à presença de cópias destes blocos no conjunto de memória intermédia local dos núcleos individuais, de modo que estas cópias podem ser marcadas como inválidas sempre que qualquer um destes núcleos escrever Alterou versões desses blocos para o cache global.
Bloquear atualizações sem bloqueio
O Adabas Parallel Services usa um método otimista para leitura e alteração de blocos, onde os blocos não são bloqueados. Uma lógica de comparação e de troca é usada para escrever blocos alterados para a estrutura de cache. Esta função executa a operação de escrita somente se nenhum outro núcleo tiver escrito o bloco para o cache após o momento em que o bloco foi lido pela última vez ou escrito pelo primeiro núcleo. Se a operação de escrita falhar devido a uma alteração conflitante, o núcleo tentando a operação de escrita deve reler o bloco alterado, repetir suas próprias alterações e solicitar novamente a operação de gravação para o cache. Este método de permitir alterações conflitantes em blocos é possível porque bloqueios no nível de registro de dados impedem núcleos de cluster diferentes de atualizar simultaneamente o mesmo objeto em um bloco. Em que atualizações conflitantes sempre se aplicam a diferentes partes de um bloco, eles podem ser repetidos se o bloco subjacente é alterado abruptamente.
A maioria das operações de atualização de índice envolve apenas um único bloco no nível mais baixo (índice normal) da árvore de índice. Neste caso, o Adabas Parallel Services altera o bloco sem bloqueá-lo previamente. Se a operação de escrita para o cache do bloco alterado falhar porque outro núcleo mudou o mesmo bloco, então o primeiro núcleo deve reler o bloco e repetir sua atualização. É possível que no ínterim a estrutura de índice tenha sido alterada. Neste caso, o núcleo também deve repetir o posicionamento dentro do índice.
Algumas operações de atualização alteram a estrutura de índice. Ou seja, eles mudam campos nos níveis de índice superior que contêm referências físicas para níveis inferiores. Um exemplo típico é uma atualização que divide um bloco de índice em dois porque ele é executado completamente. Uma referência deve então ser inserida no próximo nível mais alto para indicar a localização do novo bloco. Esta informação de estrutura é vital para posicionamento de índice, bem como para ler, pesquisar e atualizar comandos. Incoerências temporárias podem influenciar a correção das operações paralelas. Portanto, para atualizações complexas que resultam em alterações de estrutura no índice, os blocos envolvidos são bloqueados inteiramente para impedir o uso paralelo durante a atualização.
Para um único núcleo de Adabas, a sincronização de operações de índice paralelas é realizada definindo bloqueios de leitura e escrita nos blocos de controle que são usados para gerenciar o pool de buffer. Como todas as operações participantes têm acesso direto a esses blocos de controle, uma sincronização eficiente é possível.
No Adabas Parallel Services, o método direto de sincronização de operações de índice conflitantes requer o uso de bloqueios de leitura e gravação no espaço de dados.
Recuperação
Embora em menor grau do que as operações de banco de dados, a lógica de recuperação do Adabas também foi afetada pela extensão dos Serviços Paralelos. Isso envolveu não tanto o apoio de transações individuais (recuperação de transações), mas sim o tratamento de situações de erro que causam um aborto de um núcleo Adabas, bem como erros que causam danos ou destruição do banco de dados.
Transação e reinicie a recuperação
Durante a operação, a Adabas grava registros de proteção para atualizações e transações para o chamado conjunto de dados de trabalho. Se o núcleo Adabas deve abortar, essas informações de proteção são usadas para retornar o banco de dados a um estado fisicamente e logicamente consistente. A escrita de blocos alterados para o banco de dados ocorre de forma assíncrona para a execução de comandos de atualização ea alteração de blocos no pool de buffer. Os blocos modificados podem ser gravados no banco de dados antes que as atualizações tenham sido confirmadas até o final da transação correspondente (roubar). No entanto, eles não precisam necessariamente ser gravados no banco de dados no final da transação (noforce). Portanto, durante uma recuperação de reinício após um aborto do núcleo Adabas, todas as transações que terminaram, mas cujas atualizações não foram armazenadas no banco de dados antes do aborto, devem ser repetidas (refazer, conseqüência de nenhuma força). Por outro lado, todas as atualizações, que foram armazenadas no banco de dados como parte de uma transação, que ainda não estava concluída no momento do aborto, devem ser retiradas do banco de dados (desfazer, conseqüência do roubo). Os registros de proteção, Que o núcleo escreve para o conjunto de dados de trabalho, contém as informações necessárias para as operações refazer e desfazer. Em Adabas Parallel Services, cada núcleo tem seu próprio conjunto de dados de trabalho, e somente o próprio núcleo escreve dados de proteção para seu próprio conjunto de dados de trabalho. No entanto, cada núcleo é capaz de ler os registros de proteção criado por outro núcleo dentro do cluster. O backout de transações individuais (por exemplo, comandos backout (reversão)) funciona em um núcleo Paralelo da mesma forma que com um único núcleo. O núcleo lê os registros de proteção necessários de seu próprio conjunto de dados de trabalho e faz o backup das atualizações da transação. E somente o próprio núcleo escreve dados de proteção para seu próprio conjunto de dados de Trabalho. No entanto, cada núcleo é capaz de ler os registros de proteção criado por outro núcleo dentro do cluster. O backout de transações individuais (por exemplo, comandos backout (reversão)) funciona em um núcleo Paralelo da mesma forma que com um único núcleo. O núcleo lê os registros de proteção necessários de seu próprio conjunto de dados de trabalho e faz o backup das atualizações da transação. E somente o próprio núcleo escreve dados de proteção para seu próprio conjunto de dados de Trabalho. No entanto, cada núcleo é capaz de ler os registros de proteção criado por outro núcleo dentro do cluster. O backout de transações individuais (por exemplo, comandos backout (reversão)) funciona em um núcleo Paralelo da mesma forma que com um único núcleo. O núcleo lê os registros de proteção necessários de seu próprio conjunto de dados de Trabalho e faz o backup das atualizações da transação.
Se todos os núcleos ativos abortarem, o núcleo que é iniciado a seguir inicia a recuperação de reinício. Esta é a recuperação off-line, durante a qual o núcleo lê os registros de proteção dos conjuntos de dados de trabalho de todos os núcleos de cluster previamente ativos e executa, em essência, a mesma lógica de recuperação que para um único núcleo. Antes de poderem ser aplicados, os registos de protecção dos vários conjuntos de dados de trabalho devem ser colocados em ordem cronológica. Isso é possível, pois cada registro de proteção contém um carimbo de data / hora que indica exatamente quando ele foi criado.
Se um ou mais, mas não todos, os núcleos devem abortar, os núcleos remanescentes executam a recuperação on-line. Cada núcleo permite um certo tempo para todas as transações correntemente em execução para atingir conclusão normal, após o qual todas as atividades restantes são interrompidas e as conexões com a estrutura de cache e bloqueio são encerradas. Isso resulta na perda de todos os dados nessas estruturas. O núcleo então executa a lógica de recuperação offline, após a qual todos os núcleos podem se conectar a novas estruturas de cache e bloqueio, e as operações normais podem continuar. Durante todo esse processo, os contextos do usuário permanecem intactos nos núcleos que não abortaram.
Conclusão
Testes de clientes mostraram que os procedimentos acima descritos para o aperfeiçoamento de Parallel Services alcançaram resultados impressionantes. Em um esforço conjunto com a IBM no ano passado, mais de 300.000 chamadas Adabas foram executadas por segundo tempo decorrido em um mainframe IBM comercial no Poughkeepsie da IBM, centro de testes de Nova York. Isto é 100% mais do que poderia ter sido realizado com um único núcleo. Isso faz com que o Parallel Services seja o produto ideal para qualquer site que tenha que lidar com requisitos de alto rendimento ou que precise se preparar para rajadas repentinas de alta atividade. O teste foi executado no z / OS V1.8, que suporta mais de 128 GB de memória real em uma única imagem. A CPU consistia em uma série z9 com 32 processadores que suportam memória virtual de 64 bits.
Retirado
By Reiner Makohl, Software AG Germany
0 comentários:
Enviar um comentário