A sessão do usuário é uma sequência de chamadas Adabas, opcionalmente, começando com um comando OP e terminando com um comando CL. Um usuário é um programa de modo de batch ou de uma pessoa usando um terminal. O usuário pode ser identificado por um ID de 8 bytes únicos fornecidos com o comando OP. Essa identificação permite ao Adabas manter reiniciar informações (ET data) para além do final da sessão.
Para efeitos de comunicações, um usuário de terminal é identificado pela máquina, address space, e terminal ID, garantindo assim que cada ID de usuário é único.
Durante uma sessão Adabas (a partir da ativação da terminação), o núcleo Adabas cria uma sequência de entradas de proteção na sequência histórica exata refletindo todas as modificações feitas no banco de dados. A sequência de entradas de proteção é escrito para o conjunto de dados de trabalho (parte 1) e um log de proteção na forma de blocos. Cada bloco contém o número da sessão núcleo, um número de bloco único, e um carimbo do tempo.
Work
Parte 1 do data set de Work (ADARUN parâmetro LP) armazena os cadastros de proteção de entradas mais recente com um método wrap-around.
As entradas de proteção do data set de Work são usados para executar um comando de BT e executar autorestart/autobackout quando reativar o núcleo Adabas após uma falha do sistema. As entradas podem conter todos ou alguns dos seguintes procedimentos:
* imagens do antes/depois de um registro de dados;
* imagens do antes/depois de elementos das listas invertidas (DVT);
* especial de imagens-antes de blocos da lista invertida para reparar automaticamente o banco de dados após uma falha do sistema;
* entradas do checkpoint;
* Entradas ET incluindo ET data;
* entradas especiais para o tratamento internos dos restart de procedimentos.
Adabas identifica um usuário batch, verificando o store clock (STCK) o valor Adabas durante o primeiro programa de chamada.
Protection Log
O registo de proteção contém as mesmas entradas como 1 parte de um data set de Work (exceto a especial imagens anteriores mencionados na discussão dos dados de trabalho conjunto. entradas adicionais sobre o log de proteção que não são armazenados no conjunto de dados de Work inclui uma entrada para os dados C5 raramente utilizados e em uma pós-imagem do Associator ou Data Storage no bloco escrita durante buffer flush, o segundo ocorre quando uma função SAVE online do utilitário ADASAV está sendo executado.
Todas as entradas do protection log criadas pelo núcleo para descrever as modificações feitas ao banco de dados em ordem histórica exata. Cada bloco é associado a um número de bloco de sequência.
O registo de proteção pode ser escrito:
* diretamente para um log de protection sequencial (DD/SIBA) data set, ou
* para registrar em multiplos protection logs data set (DD/PLOGR1, DD/PLOGR2 ... DD/PLOGR8)
Nota:
Adabas ainda suporta dupla proteção log usando DUALPLD/S e user exit 2.
Multiplos data sets de protection logs de registro são cada conjunto de dados físicos do mesmo tamanho e comprimento do bloco, acessado aleatoriamente, e utilizado em sucessão. Isto significa que um dos data sets podem ser usados e escrito pelo núcleo, enquanto outros estão sendo copiados em ordem para fins de arquivamento.
Sequencial Protection Log
A seqüencial protection log do data set é aberto pelo núcleo quando a sessão é iniciada e encerrada quando uma sessão é encerrada. Em geral, esse data set é atribuído a fita/cartucho para evitar problemas de espaço em disco que pode provocar o encerramento inesperado anormal. Porque a quantidade de dados a serem gravados para tal um conjunto de dados depende da quantidade de atividade de todos os utilizadores, a estimativa de espaço em disco é difícil.
No final da sessão, Adabas, marca um end-of-file (EOF) e é gravado na fita/cartucho para indicar o fim da sessão. O Adabas suporta vários multivolume de data sets de protection logs. Se uma não é suficiente para armazenar todas as entradas do log de proteção, várias fitas pode ser usada posteriormente.
O núcleo escreve no checkpoint cada volume utilizado. Este ponto de verificação contém informações sobre o número da sessão, o número de série do volume, bloco e o números de sequência.
A Adares função COPY deve ser usado para copiar um data set da protection log estabelecido para fins de arquivamento.
Se uma sessão de núcleo terminou de forma anormal, a marca de EOF final sobre a fita não pode ser escrito. Isso pode causar problemas se o log de proteção é usado diretamente como entrada para a ADARES BACKOUT ou função REGENERATE. A função de cópia do Adares é capaz de detectar o fim lógico de entrada/saida da proteção e escreve uma marca EOF válidas para a saída. Adares checkpoints escreve da mesma maneira que o núcleo faz para cada volume de saída.
Multiplos data set de Protection Log
O Adabas com vários data set de protection log consiste de dois a oito data sets (DD/PLOGRn onde n é o número sequencial do data set) com os seguintes atributos:
* bloco de tamanho fixo;
* estar em disco;
* pré-formatado usando o utilitário ADAFRM;
* todos os data set têm que ter o mesmo número de blocos e blocos de tamanho idêntico;
* todos os data sets podem ser compartilhados pelo núcleo e outras utilidades (ADARES).
Assumindo recentemente formatado a dual ou multipla protection log de dados define log. O Adabas seleciona DD/PLOGR1 na inicio e começa a gravar as entradas de log de PLOG. A gravação começa no bloco 2. Bloco 1 contém informações sobre o status do data set. conjuntos de dados PLOG Outros ainda estão sem uso. Entradas de dados do PLOG são escritas para vários conjuntos de proteção de dados de log na mesma ordem em que são gravados em um log sequencial.
Cada data set de registro de PLOG não precisa ser grande o suficiente para acomodar todos os cadastros de proteção de registro para uma sessão. Quando um conjunto de dados torna-se cheio, a mudança de registro de proteção ocorre da seguinte forma:
1. informações de status é escrito para o bloco 1 para terminar PLOG de dados de log atual conjunto;
2. há uma mudança para outro data set;
3. uma mensagem é gravada para o operador e para a saída do log, e
4. user exit 12 é chamado (veja abaixo).
Enquanto o núcleo continua a gravar as entradas de PLOG para o data set, a primeiro é copiada para um data set sequencial por Adares PLCOPY. ADARES pode ser iniciado manualmente ou "startado" pela user exit 12, que é chamada sempre que a passagem de um registro de dados de proteção definido para outro ocorre. Adares escreve no checkpoint de controle cada volume de produção gravada. Este ponto de verificação contém o número da sessão, número de série, volume e número de sequência do bloco.
Um switch de log proteção pode ocorrer mais de uma vez em uma única sessão. O conteúdo de cada conjunto de logs de protecção de dados devem ser copiados para um data set único sequencial. Todas as cópias posteriores produzidos dentro de uma sessão são logicamente equivalentes às informações que o núcleo teria gravado em um log de proteção seqüencial (DD/SIBA).
Todas as cópias sequenciais podem ser concatenadas para formar um conjunto sequencial de dados único contendo todas as entradas de proteção de registro para uma sessão. Na verdade, uma cópia sequencial é exigido como entrada nas funções BACKOUT/REGENERATE funções do ADARES.
Uma unidade de fita para armazenar as entradas do registro sequencial de proteção é necessária apenas durante a execução PLCOPY Adares.
Se multiplos data sets do proteção de log é usado, mas user exti 12 não está disponível para chamar Adares PLCOPY, alternando log proteção ocorre da seguinte forma:
1. a corrente de proteção log conjunto de dados é fechado e
2. se nenhum conjunto de outros data sets está vazio, a seguinte mensagem é emitida e os dados antigos são substituídos:
Now it's too late to copy DDPLOGRn (or PLOGRn)Neste caso, informações de log de proteção é perdida.
Restart Operations
Entradas do PLOG são necessárias para que qualquer um dos seguintes falhas:
* uma aplicação ou programa do usuário
* Adabas
* o sistema operacional
* o hardware
Restart after a User Application Program Failure
Uma aplicação escrita em programa que está no meio de uma transação pode detectar que a operação não pode ser concluída com êxito. Removendo a primeira parte da operação, chamada de volta ou reverter, é realizada pelo comando da BT.
O comando da BT é executado pela leitura dos dados de trabalho conjunto para trás e executar as entradas para a transação específica em sentido inverso (pós-imagem é usada para riscar um elemento no banco de dados, antes de imagem é utilizado para inserir um elemento no banco de dados). O bit de início de transação em um elemento serve como indicador de parada para o processo BT.
Restart after an Adabas, Operating System, or Hardware Failure
Quando Adabas é reativada depois de qualquer falha que causou ao núcleo do Adabas um termino de forma anormal (ou seja, falha do Adabas, o sistema operacional ou hardware), um procedimento automático é executado para trazer o banco de dados para um estado fisicamente e logicamente válido. Todos os comandos de atualização são executadas parcialmente reposto. Todas as transações incompletas são recuou.
Este procedimento automático compreende três etapas:
1. reparar o banco de dados
2. autorestart
3. autobackout
O reparo é necessário para modificar o banco de dados para o estado que teria se um buffer flush tinha terminado no momento da falha. Em outras palavras, todos os blocos na base de dados estão em um status que permite que o núcleo para executar normalmente, abordando os registros de armazenamento de dados através do conversor de endereços e entradas de índice normal através do índice superior.
Autorestart volta as atualizações de comandos de atualização único que foram parcialmente executadas quando o sistema falha; Autobackout volta as atualizações de transações do usuário que foram parcialmente executadas quando o sistema falhou.
As entradas principais de proteção utilizado para autorestart e autobackout são as imagens anteriores e depois de imagens de armazenamento de dados e as listas invertidas (DVT).
Restart after a Power Failure
Dependendo do hardware, uma falha de energia durante uma operação de I/O pode danificar os blocos Adabas que estavam sendo processadas. Este dano não pode ser detectada durante autorestart e, portanto, pode resultar em problemas futuros, tais como códigos de resposta inesperada de atualizações de dados perdidos.
Nota:
Se a causa do abend foi uma falha de energia, a Software AG recomenda recuperar os arquivos afetados usando os utilitários ADASAV e ADARES conforme descrito na seção Banco de Dados de recuperação.
Sempre que uma sessão Adabas é reativado com o parâmetro IGNDIB=YES, o que obriga a nova sessão para ignorar um bloco de comunicação existentes sessão (DIB) na Associator, o Adabas checa se um buffer flush estava ativo quando o abend ocorreu. Se o buffer foi liberado no processo, o autorestart desliga e emite uma mensagem de ADAN58:
ADAN58 BUFFER-FLUSH START RECORD DETECTED DURING AUTORESTART. THE NUCLEUS WILL TERMINATE AFTER AUTORESTART. IN CASE OF POWER FAILURE, THE DATABASE MIGHT BE INCONSISTENT...
A mensagem também inclui uma lista dos arquivos que estavam sendo atualizados quando o buffer foi liberado no processo. Neste caso, o DBA deve verificar se a causa do abend foi uma falha de energia.
Se o abend definitivamente não foi uma falha de energia e da integridade da informação sobre o hardware de saída pode ser garantido, o banco de dados pode ser reativado imediatamente. Recuperação de banco de dados não é necessária.
Using Automatic Restart Management (ARM)
Automatic restart management (ARM) é usado para reiniciar automaticamente quando o núcleo abends. Automatic restart é suprimida quando o abend é intencional, por exemplo, quando resulta de um erro de parâmetro.
ARM pode ser usado para o Adabas núcleos em ambientes de cluster e não-cluster.
O parâmetro ADARUN ARMNAME é usado para identificar o elemento em "política" que está para ser ativado. Cada elemento especifica quando, onde e quantas vezes uma reinicialização automática, deve ser tentada. Se uma política de ARM não foi definido, o parâmetro ARMNAME não tem efeito.
Retirado - Clique Aqui
0 comentários:
Enviar um comentário