Visão Geral das Funções
O utilitário ADARAI prepara o Log de recuperação (RLOG), lista as informações contidas no RLOG, cria as instruções de controle de job para recuperar o banco de dados e desabilita o log de ADARAI.
A "transação" de recuperação é fornecida sempre que uma sessão do Adabas é anormalmente terminada. A rotina autobackout do Adabas, que é automaticamente invocada no início de cada sessão do Adabas, remove os efeitos de todas as transações interrompidas do banco de dados. Consulte as informações de reinício / recuperação na documentação do Adabas Operations.
No entanto, quando um dataset de banco de dados (ASSO, DATA ou WORK) é destruído, é necessário restaurar e regenerar o banco de dados para recuperar os dados perdidos.
O utilitário Adara Recovery Aid ADARAI pode ser usado para automatizar e otimizar a recuperação de "banco de dados". Ele grava e relata todas as informações necessárias para recuperar o banco de dados e cria o fluxo de job de recuperação (JCL / JCS), que é a base para reexecutar os trabalhos executados desde o último SAVE até o ponto de falha e erro.
Nota: A função de geração de fluxo de job ainda não está disponível em VSE / ESA ou VM / ESA.
Conceitos e Componentes
O Adabas Recovery Aid compreende dois componentes:
(*) Uma interface (ADARAC) para coletar informações à medida que os eventos relevantes ocorrem contra o banco de dados; e
(*) Um utilitário (ADARAI) para listar as informações coletadas, gerar trabalhos para recuperar o banco de dados ou arquivos no banco de dados ou desativar o log de recuperação.
A interface de coleção
A interface de coleta é chamada pelo núcleo e por todos os utilitários para registrar informações sobre cada evento que ocorre; Por exemplo, um núcleo parar / iniciar, uma execução de utilitário ou um evento gerado pelo Adabas Online System.
Log de recuperação (RLOG)
A interface registra todas as informações de evento em um arquivo de log de recuperação (RLOG) para uso pelo componente de utilitário. O RLOG armazena as informações sobre conjuntos de dados, parâmetros de utilitário e registros de proteção necessários para criar o controle de trabalho de recuperação. O conjunto de dados RLOG é DD / RLOGR1.
Em um ambiente de cluster de núcleos, todos os núcleos usam o mesmo RLOG. Atualizações simultâneas para o RLOG são controladas por um bloqueio.
Notas:
Os conjuntos de dados seqüenciais usados pelos utilitários cujas execuções são registradas no RLOG devem ser mantidos e disponíveis para qualquer operação de recuperação; Por exemplo, a entrada DD / EBAND para uma operação ADALOD LOAD. As alterações de arquivo ADADBS agora são registradas no conjunto de dados RLOG. As informações registradas no RLOG geralmente excedem as exigidas para recuperação; Ele também pode ser usado como um registro de eventos que ocorreram em um banco de dados durante um período de tempo.
Geração: A Unidade de Recuperação
A informação é armazenada no RLOG por geração, a unidade lógica usada para a recuperação.
Uma "geração" inclui toda a atividade entre operações consecutivas de
(*) ADASAV SAVE/RESTORE (banco de dados),
(*) RESTORE GCB, e/ou
(*) SAVE DELTA /RESTORE DELTA (banco de dados).
A primeira geração inclui a primeira operação e se estende para (mas exclui) a segunda. Uma nova geração é iniciada quando um banco de dados pode ser recuperado completamente após a operação anterior.
As gerações podem ser normais, restritas ou erradas:
(*) Uma geração é rotulada como "normal" se uma reserva completa estiver disponível quando ela começou e nenhum evento incomum ocorreu enquanto as atividades estavam sendo registradas nele.
(*) Uma geração é rotulada como "restrita" quando certos eventos ocorrem durante o ciclo de registro que tornam impossível para ADARAI reconstruir o banco de dados sem a intervenção do usuário. ADARAI gera um trabalho, mas o trabalho não será executado sem a ajuda do usuário. Por exemplo, se o conjunto de dados do trabalho tiver diminuído de tamanho, o usuário deve criar um conjunto de dados do trabalho com o tamanho original para que o trabalho de recuperação possa ser executado corretamente até o ponto onde o tamanho do conjunto de dados do trabalho foi diminuído.
(*) Uma geração é rotulada como "errada" quando ocorrem erros durante o ciclo de registro, por qualquer motivo. ADARAI gera um trabalho, mas o trabalho não será executado sem alterações.
Nota:
Quando uma geração se torna restrita ou errada, a Software AG recomenda que você inicie uma nova geração o mais rápido possível, executando uma salvaguarda on-line ou off-line do banco de dados. Se o Delta Save Facility estiver instalado, um SAVE DELTA iniciará uma nova geração.
Retendo gerações não Correntes
As gerações não-correntes fornecem um histórico de operações que afetaram o banco de dados para uso na resolução de problemas ou para fins de auditoria.
O acesso a gerações não correntes é essencial se uma tentativa de recuperar um banco de dados falhar depois que a etapa RESTORE na tarefa de recuperação for executada. Neste ponto, a geração a ser recuperada torna-se a geração atual. Se for necessário reconstruir o trabalho de recuperação, a geração a ser recuperada será uma geração mais antiga.
O RLOG mantém o número de gerações especificado pelo parâmetro MINGENS durante a etapa ADARAI PREPARE. ADARAI recicla gerações quando o número armazenado no RLOG atinge o número especificado pelo parâmetro MINGENS.
Quando uma nova geração mais aqueles já armazenados excederem o espaço RLOG disponível, um dos dois eventos ocorrerá: Se o número mínimo de gerações especificado por MINGENS pode ser mantido, a geração mais antiga é substituída; de outra forma O RLOG é colocado "fora de serviço", definindo um sinalizador no bloco de controle RLOG. Nesse caso, os dados não são mais registrados.
CHKDB: Verifique o Status do banco de dados
DISABLE: Desativar Registro de recuperação
A função ADARAI DISABLE desativa o registo de recuperação definindo a tabela RLOG (bloco de controlo) para o estado inactivo.
Nota:
ADARAI DISABLE deve ser executado com o banco de dados inativo.
Após DISABLE, as informações não são mais gravadas no RLOG e a geração atual é encerrada. O conteúdo do RLOG antes de DISABLE é mantido e ainda pode ser listado ou usado de outra forma para propósitos de recuperação.
O log de recuperação pode ser iniciado novamente iniciando uma nova geração.
Exemplo: Desativa todo o registro de Ajuda de recuperação.
Nota: Os RLOGs da versão 6 do Adabas não podem ser listados; Somente a versão 7 e acima de RLOGs são suportados.
A função ADARAI LIST é usada para visualizar o conteúdo do RLOG na forma de tabela:
(*) As gerações são listadas em ordem numérica;
(*) Os intervalos de blocos RLOG são listados para cada geração; e
(*) A datas de parada/inicio e os tempos cobertos por cada geração são listados.
As informações a seguir são fornecidas para cada entrada no RLOG, incluindo execuções de utilitários e entradas de início de sessão de núcleo e entradas de parada de sessão:
(*) Nome do evento para o qual a entrada do RLOG foi escrita;
(*) Data e hora em que a informação foi escrita para o RLOG;
(*) Número PLOG associado ao evento (se houver);
(*) Bloco PLOG contendo um ponto de verificação associado (se houver);
(*) Parâmetros especificados para o evento registado para as instruções DD/CARD e DD/KARTE; e
(*) Detalhes de quaisquer arquivos escritos ou lidos durante o evento registrado.
Em um ambiente de cluster de núcleo, os conjuntos de dados PLOG também são listados nas entradas de início da sessão de núcleo. O ID do núcleo do cluster (NUCID) também está listado.
Exemplo:
Parâmetros opcionais
GENS: Generation Print Control
GENS determina se a informação de geração está listada. GENS = NO lista somente as informações de controle RLOG. GENS = YES (o padrão) lista as informações de geração também.
RELGEN: Número Relativo de Geração de Recuperação RELGEN especifica o número relativo de geração (ou intervalo de números de geração) a ser listado. A geração atual é sempre acoplada com a geração relativa "0" (zero). A última geração completa é acoplada com a geração relativa 1; "Duas gerações atrás", a geração antes da última geração completada, é especificada como geração relativa "2". Exemplo:
Para listar as gerações que vão desde três gerações até a última geração completa (inclusive), especifique RELGEN = 3-1. Se o número da primeira geração especificado for menor que o número da segunda geração, o ADRAI reduz o número da segunda geração para coincidir com o primeiro.
Exemplo:
Se você especificar RELGEN = 2-3, ADARAI altera para RELGEN = 2-2. Se RELGEN não for especificado, todas as gerações serão impressas. A geração especificada deve estar atualmente no RLOG. Observe, no entanto, que em vez de um número relativo, cada geração listada tem um número de ordem ascendente, começando com 1 (a primeira geração após o início da operação RLOG).
Exemplo:
RELGEN = 0 é equivalente ao número de geração 690; RELGEN = 3-2 é equivalente aos números de geração 687 e 688.
RLOGDEV: RLOG dispositivo alternativo
RLOGDEV especifica o tipo de dispositivo que contém o arquivo RLOG. Se o arquivo RLOG estiver localizado no tipo de dispositivo especificado pelo parâmetro ADARUN DEVICE (o tipo de dispositivo padrão), você não precisará especificar RLOGDEV.
Exemplos
Exemplos de entrada
Este exemplo lista todas as gerações no RLOG.
DDSAVE1 VOLSER=SMS018 FROM BLOCK=1 (ASSO) TO BLOCK =1598 VOLUME IS ASSOCIATED WITH PLOG NO. 6
PREPARE: Inicializar e Iniciar o RLOG
O log de recuperação (RLOG) deve ser preparado antes de ser usado. As etapas a seguir são necessárias para iniciar o arquivo RLOG:
Etapa 1. Formate o arquivo RLOG usando a função ADARF RLOGFRM.
Antes de executar ADARAI PREPARE, o conjunto de dados RLOG deve ser formatado usando a função RLOGFRM do utilitário ADAFRM. Se não estiver, um erro 159 é retornado.
Etapa 2. Execute a função ADARAI PREPARE para preparar o RLOG.
ADARAI PREPARE deve ser executado com o banco de dados inativo.
A função ADARAI PREPARE é utilizada para
(*) O tamanho do RLOG (o tamanho deve ser o mesmo que o valor do parâmetro SIZE da função ADAFRM RLOGFRM);
(*) O número mínimo de gerações a reter (4 é o padrão); e
(*) O tipo de dispositivo (o padrão é o tipo de dispositivo especificado pelo parâmetro ADARUN DEVICE).
Etapa 3. Execute a função ADASAV SAVE (banco de dados) para iniciar a primeira geração de logs.
Depois que a função PREPARE for executada, o registro começa para a geração inicial; No entanto, esta geração tem um status "restrito" porque não foi iniciado por um banco de dados completo salvar ou restaurar.
Consulte a documentação do Adabas Operations para obter mais informações sobre status de geração.
Sintaxe
Parâmetro Essencial
RLOGSIZE: RLOG Tamanho da Área
RLOGSIZE define o tamanho do arquivo RLOG em cilindros ou blocos. Esse valor deve ser o mesmo definido pelo parâmetro SIZE da função ADARFM RLOGFRM. RLOGSIZE deve ser especificado; Não há padrão.
Nota:O conjunto de dados RLOG está limitado a 16.777.215 (x'FFFFFF ') blocos / RABNs.
Parâmetros opcionais
MINGENS: contagem de geração RLOG
MINGENS especifica o número de gerações de registro a serem mantidas no RLOG. O RLOG indica as gerações em ordem ascendente começando por "0". O mínimo é de 4 gerações (o padrão); O máximo é 32.
RLOGDEV: RLOG Tipo de dispositivo
RLOGDEV especifica o tipo de dispositivo que contém o arquivo RLOG. Se o arquivo RLOG estiver localizado no tipo de dispositivo especificado pelo parâmetro ADARUN DEVICE (o tipo de dispositivo padrão), você não precisará especificar RLOGDEV.
Importante:
Se você escolher um tipo de dispositivo para o conjunto de dados RLOG que é diferente do padrão, você deve especificar o parâmetro RLOGDEV para todas as execuções ADARES PLCOPY e COPY também.
Exemplos
Exemplo 1: Esta função ADARAI PREPARE define e inicializa o RLOG para manter o mínimo de quatro gerações em um tamanho de log de cinco cilindros. O dispositivo RLOG padrão é o especificado pelo parâmetro ADARUN DEVICE.
RECOVER: Criar um fluxo de job de recuperação
Nota: A função RECOVER está disponível apenas para sistemas BS2000 e OS / 390 ou z / OS. Está previsto o suporte a sistemas VM / ESA, z / VM e VSE/ESA.
A função ADARAI RECOVER cria as informações de controle de job (fluxo de job de recuperação) para recuperar o banco de dados Adabas ou arquivos de banco de dados selecionados. A função RECOVER
(*) Lê as informações PLOG para determinar se um PLCOPY é necessário; e
(*) Lê o RLOG para criar o fluxo de job de recuperação a partir do controle de job de esqueleto.
ADARAI RECOVER cria o fluxo de job necessário para restaurar o banco de dados ou arquivos para a condição antes da função RECOVER foi executada. O fluxo de job concluído é enviado para o conjunto de dados DD / JCLOUT.
Quando apropriado, ADARAI inclui mensagens de erro ou informações no fluxo de job gerado. Em seguida, você deve corrigir manualmente os erros antes de enviar o trabalho. A existência de mensagens no fluxo de job é indicada por um código de retorno diferente de zero de ADARAI RECOVER.
Para sistemas BS2000, RECOVER adicionalmente
Executa, ao gerar o controle do trabalho, as mesmas verificações realizadas pela função LIST para BS2000; e
Inclui instruções BS2000 / REMARK no controle de trabalho criado para verificações que produzem erros.
Nota: Quando ocorrem tais erros, o controle do trabalho deve ser corrigido manualmente.
Processamento de recuperação
A função ADARAI RECOVER cria um job com base na seqüência exata encontrada na geração a ser recuperada:
Ele restaura o banco de dados a partir dos conjuntos de dados criados pela operação que iniciou a geração;
Ele regenera PLOGs até o próximo ponto de verificação de utilidade encontrado;
Ele gera uma etapa de trabalho para reexecute o utilitário e iniciar a regeneração após esse ponto de verificação.
Esta seqüência continua até que todos os utilitários tenham sido repetidos e o último bloco PLOG na geração tenha sido regenerado.
O diagrama a seguir ilustra o funcionamento do ADARAI, onde
(*) Um banco de dados é salvo para iniciar uma nova geração em A.
(*) O banco de dados é executado e em vários momentos durante a geração
(*) Uma atualização é executada no arquivo 1;
(*) Um reordenamento é executado no arquivo 2;
(*) Um invertido é executado contra o arquivo 3; e
(*) Uma carga é executada no arquivo 5.
Tendo em conta o que precede, a ordem de recuperação é a seguinte:
1 - Uma gravação completa ou uma gravação completa mais as salvaguardas delta são restauradas para retornar o banco de dados para o status em A.
2 - Um regenerado de banco de dados é executado do primeiro ponto de verificação em A até o ponto de verificação de atualização em B. O trabalho de regeneração termina.
3 - O utilitário de atualização é executado para o arquivo 1 e um regenerado de banco de dados é executado entre o ponto de verificação em B eo ponto de verificação invertido em C.
4 - O utilitário de inverter é executado para o arquivo 3 e um regenerado de banco de dados é executado entre o ponto de verificação C eo ponto de verificação de carga em D.
5 - O utilitário de carregamento é executado para o arquivo 5 e um regenerado de banco de dados é executado entre o ponto de verificação D eo ponto de verificação de reordenação em E.
6 - A reordenação é executada para o arquivo 3 e um banco de dados é gerado entre o ponto de verificação E eo nível mais atualizado do banco de dados em F.
Processamento de recuperação otimizado
O parâmetro OPT para a função RECOVER do ADARAI é usado para identificar operações ou seqüências que minimizariam o tempo necessário para recuperar um banco de dados grande.
Por exemplo, se um arquivo com 10.000 atualizações é excluído ou recarregado, deve ser possível evitar a restauração do arquivo desde o início, reproduzindo as 10.000 atualizações e, em seguida, jogando tudo fora quando a operação de exclusão ou carregamento ocorre.
Quando a otimização é selecionada, ADARAI não restaurar o arquivo de exemplo na restauração principal para o trabalho. Regeneração para o arquivo ocorre somente após o arquivo foi excluído ou criado pela carga:
(*) Um arquivo excluído não tem mais atualizações;
(*) Para um arquivo criado por uma carga, somente as atualizações subseqüentes à carga são importantes.
Quando um fluxo de job otimizado é usado, o banco de dados recuperado é reconstruído de uma maneira que é diferente da compilação original. Como os trabalhos de recuperação otimizados não são reproduzidos exatamente da mesma maneira que os trabalhos originais, problemas podem ocorrer na recuperação; Por exemplo, espaço insuficiente pode estar disponível no banco de dados. Na maioria dos casos, no entanto, o risco é mínimo comparado com os benefícios potenciais de otimizar a recuperação do banco de dados. Cada situação deve ser examinada para possíveis problemas.
Requisitos
Para gerar um trabalho de recuperação que será executado com êxito, ADARAI impõe as seguintes condições:
(*) O banco de dados deve ser executado com o registro de proteção dupla ou múltipla ativo.
(*) Conjuntos de dados seqüenciais para funções de utilitário que atualizam arquivos no banco de dados devem ser mantidos.
(*) Os conjuntos de dados de saída seqüenciais criados pelas funções SAVE ou MERGE devem ser mantidos. Isso se aplica às funções SAVE FILE somente se RESTFILE = YES for usado para ADARAI RECOVER.
(*) Os conjuntos de dados retidos devem manter seus nomes originais; ADARAI não consegue rastrear cópias com nomes diferentes.
A Software AG recomenda que os conjuntos de dados retidos sejam catalogados.
Restrições
Shadow Databases
Se bancos de dados "shadow" (sombra) ou cópias de bancos de dados normais de produção forem construídos restaurando a saída de salvamento delta eo conjunto de dados DSIM para salvar o banco de dados original, ADARAI não tem conhecimento da atividade do PLOG ocorrida durante o delta save no banco de dados original e portanto Não é possível reconstruir o conjunto de dados DSIM se uma operação de restauração se torna necessária no banco de dados sombra. No entanto, se o conjunto de dados DSIM e o conjunto de dados de salvamento delta forem mesclados para criar um novo conjunto de dados de salvamento delta "off-line" e o novo conjunto de dados mesclado for restaurado para o banco de dados sombra, o ADARAI tem todas as informações necessárias para recuperar o banco de dados sombra. O PLOG não é necessário neste caso.
Restaurando Delta salva com um conjunto de dados DSIM
Em geral, ADARAI trata RESTORE DELTA processamento sem problemas. No entanto, se o DELTA RESTORE usa um conjunto de dados DSIM (que é essencialmente um conjunto de dados "funcionando"), o conjunto de dados DSIM pode não estar intacto se um ADARAI RECOVER se torna necessário. O ADARAI registra, portanto, as solicitações COPY ou PLCOPY usadas para criar um conjunto de dados DSIM e emite uma etapa de trabalho para reconstruir o conjunto de dados antes de tentar reproduzir um DELTA RESTORE durante o processamento RECOVER. ADARAI pesquisa o RLOG inteiro para entradas apropriadas. Se as entradas não puderem ser encontradas, ADARAI não é possível reconstruir o conjunto de dados DSIM antes da etapa RESTORE e, portanto, não é possível reproduzir o RESTAURAR DELTA.
Arquivo DD/FILEA
Em um trabalho de recuperação gerado, ADARAI grava o arquivo DD / FILEA do utilitário ADAORD. Isso não pode ser evitado porque as funções REORDER devem ser repetidas e exigem que o arquivo DD / FILEA seja gravado.
Neste caso, aplicam-se as seguintes restrições:
(*) O processamento ADAORD STORE lê simplesmente o mesmo DD / FILEA lido quando o utilitário foi originalmente executado como parte da geração sendo recuperada.
(*) Um arquivo temporário (DISP = (NEW, DELETE), que é excluído depois que a etapa é executada) pode ser usado para DD / FILEA porque a tarefa de recuperação cria e exclui o arquivo novamente quando ele é executado.
(*) Um arquivo existente (DISP = OLD) pode ser usado para DD / FILEA. Se ele ainda existe quando o trabalho de recuperação é executado, ADARAI simplesmente aloca o arquivo com a disposição que tinha quando o trabalho original foi executado.
(*) Se um novo arquivo (DISP = NEW, CATLG) for alocado para DD / FILEA e mantido na etapa original do ADAORD REORDER, e se ele ainda existir quando a tarefa de recuperação chegar ao passo REORDER (o que é normal), o ADARAI tentará criar O mesmo arquivo novamente, o que faz com que o trabalho falhe.
(*) Se um GDG é usado, o trabalho de recuperação ADARAI vê somente o nome do conjunto de dados real criado pela geração. Se o conjunto de dados já existir (o que é normal), ADARAI arrempts para criar o mesmo arquivo novamente, o que faz com que o trabalho falhar.
Entrada necessária para recuperação
Os conjuntos de dados a seguir são inseridos na função ADARAI RECOVER:
(*) DD/RLOGR1, o log de recuperação.
(*) DD/PLOGR1 e DD / PLOGRn, os registos de protecção múltipla, que são necessários quando é utilizado o parâmetro ADARAI RECOVER FEOFPL = YES (o predefinido).
(*) DD/JCLIN, que fornece instruções de controle de job de esqueleto dependentes do site. A operação RECOVER funde essas instruções com as informações RLOG para criar um fluxo de job de recuperação de banco de dados completo.
Em sistemas BS2000, DDJCLIN é um conjunto de dados SAM com formato de registro variável. EDT pode ser usado para criar e editar este conjunto de dados. Consulte a seção Controle de trabalho de esqueleto para obter mais informações.
Em sistemas OS / 390 ou z / OS, o conjunto de dados DDJCLIN deve ser definido com RECFM = FB, LRECL = 80 e um BLKSIZE que é um múltiplo de 80 bytes.
Saída da Operação de Recuperação
A saída ADARAI RECOVER é um fluxo de job pronto para execução para recuperar o banco de dados. Este fluxo de job de recuperação é gravado no arquivo DD / JCLOUT. Se uma possível condição de erro for detectada durante a operação RECOVER, ADARAI emite uma mensagem de aviso e termina com um código de condição de 4. Consulte a seção Verificação de pré-recuperação .
Em sistemas BS2000, DDJCLOUT e DDJCLCON são conjuntos de dados SAM com formato de registro variável. Eles estão em conformidade com as convenções de controle de trabalho BS2000.
Em sistemas OS/390 ou z/OS, a instrução DDJCLOUT DD deve apontar para um conjunto de dados definido com RECFM = FB, LRECL = 80 e um BLKSIZE que é um múltiplo de 80 bytes.
O fluxo de job de recuperação inclui etapas de trabalho para iniciar o núcleo
(*) Antes da primeira etapa de trabalho de regeneração; e
(*) Após qualquer operação de utilitário que faz com que o núcleo termine automaticamente.
Os trabalhos de ADARAI RECOVER replay todos os utilitários com o banco de dados ativo, se o utilitário foi originalmente executado no modo de usuário único ou não. Os utilitários originalmente executados no modo de usuário único são reproduzidos no modo multiusuário. Essas etapas de trabalho são descritas nas seções Criando o Fluxo de Trabalho de Recuperação e o Controle de Trabalho de Esqueleto.
Executando a função RECOVER
A função RECOVER é executada uma geração de cada vez sob o controle do parâmetro RELGEN. Se RELGEN não for especificado, o padrão é a geração atual.
RECOVER pode ser executado com o núcleo ativo ou inativo. Ele pode ser executado mais de uma vez para a mesma geração porque não altera as informações do RLOG para essa geração.
No entanto, se RECOVER for rerun após uma falha durante a execução de um fluxo de job de recuperação DD / JCLOUT, o novo fluxo de job de recuperação produzido pode ser diferente do fluxo de job de recuperação original. A razão é que o fluxo de job de recuperação original pode executar utilitários contra o banco de dados que atualiza o RLOG. A nova operação RECOVER cria um fluxo de job de recuperação para os utilitários executados como parte do fluxo de trabalho de recuperação falhado.
Além disso, se o fluxo de job de recuperação falhar após a execução de um ADASAV RESTORE, uma nova geração é criada. Neste caso, execute RECOVER usando o parâmetro RELGEN = 1 para obter a geração original.
Processando o PLOG - No início da execução, se ADARAI RECOVER FEOFPL = YES, RECOVER lê os PLOGs, procurando informações que devem ser copiadas. Se necessário, ele chama o núcleo para forçar uma chave PLOG. Se o núcleo estiver inativo, ele invoca a user exit 2.
Lendo o Registro de Recuperação - Em seguida, RECOVER lê o controle de trabalho esqueleto em armazenamento e lê o RLOG em ordem cronológica, começando no início da geração especificada pelo parâmetro RELGEN. Veja Geração: A Unidade de Recuperação para uma definição de geração. Se todo o banco de dados estiver sendo recuperado, o RECOVER usa as informações de ADASAV SAVE ou RESTORE para criar uma nova operação de banco de dados RESTORE / RESTONL. Para recuperação em nível de arquivo, ele usa as informações de banco de dados SAVE / RESTORE para criar uma função RESTORE FILE=...
Criando o Fluxo de Trabalho de Recuperação - Depois de criar um fluxo de job para restaurar o banco de dados ou arquivo, RECOVER cria uma etapa de trabalho para iniciar o núcleo, usando a instrução %% JCL-STARTNUC. RECOVER cria o primeiro passo de trabalho de regeneração. Esta etapa de trabalho não contém um ponto de verificação FROM (FROMCP) a menos que um SAVE on-line (ou DELTA SAVE) tenha sido a base para iniciar a geração. Nesse caso, o regenerado começa no ponto de verificação final (SYN2) da salvaguarda on-line.
Todos os PLOGs até e incluindo o próximo ponto de verificação de serviço (no qual o REGENERATE deve parar) são incluídos e os parâmetros apropriados são fornecidos à função ADARES REGENERATE. Se mais de 99 PLOGs devem ser regenerados, ADARAI gera várias etapas de trabalho REGENERATE, cada uma processando até 99 conjuntos de dados PLOG de entrada. Uma vez que os PLOGs são regenerados até a próxima execução do utilitário, o passo de tarefa de utilitário é gerado no trabalho de recuperação de saída. ADARAI, em seguida, insere outra etapa de trabalho REGENERATE que inclui todos os PLOGs até e incluindo o próximo ponto de verificação do utilitário.
O trabalho de recuperação continua inserindo etapas REGENERATE e etapas de utilitário até que ele detecta o final da geração especificada pelo parâmetro RELGEN. Nesse ponto, o fluxo de job concluído é enviado para o arquivo DD / JCLOUT.
Recuperação de nível de arquivo
A recuperação pode ser feita em um nível de arquivo especificando o parâmetro FILE da função RECOVER. O processo de recuperação de nível de arquivo é essencialmente o mesmo que o processo de recuperação de nível de banco de dados, mas é restrito aos arquivos especificados usando o parâmetro FILE.
ADARAI produz um resultado específico do arquivo em DD / JCLOUT adicionando parâmetros às instruções de execução do utilitário. Por exemplo, suponha que a seguinte instrução estava na instrução ADASAV RESTORE original:
Nota: Se um ficheiro a recuperar for parte de uma cadeia de ficheiros expandida ou estiver acoplado, todos os ficheiros da cadeia ou da lista acoplada devem ser recuperados em conjunto. Se todos os arquivos acoplados ou cadeias de arquivos expandidos não forem recuperados juntos, ADARAI detecta isso e a função ADARAI RECOVER falha.
O núcleo Adabas deve estar ativo antes de executar um trabalho de recuperação em nível de arquivo. Isso é diferente do trabalho de recuperação no nível do banco de dados, que inicia o próprio banco de dados.
Uma operação RECOVER nível de arquivo não cria controle de trabalho para utilitários que foram executados em todo o banco de dados (por exemplo, ADADEF NEWWORK). As exceções a isso são utilitários que podem ser reexecuted para arquivos individuais, bem como o banco de dados completo. Um exemplo é ADASAV RESTORE (banco de dados), que fornece um dataset de entrada DD / SAVE que pode ser usado para criar ADASAV RESTORE FILE=... job control.
Sintaxe
Parâmetros Opcionais e Subparâmetros
AUTOBACKOUT: Retirar transações incompletas
AUTOBACKOUT só pode ser especificado para recuperação de nível de arquivo. Se AUTOBACKOUT for especificado, as transações que não foram concluídas no final da última função REGENERATE no trabalho de recuperação são excluídas. Somente as transações concluídas são deixadas no banco de dados. Se AUTOBACKOUT não for especificado, transações incompletas são deixadas no banco de dados. Para recuperação no nível do banco de dados, transações incompletas no final da última função REGENERATE são sempre excluídas.
DRIVES: ADASAV Restore Input Drive Volumes
DRIVES é o número de conjuntos de dados de entrada a serem usados como entrada para a etapa RESTORE do job de recuperação que está sendo gerado. O parâmetro DRIVES especificado deve ser igual ou menor que o parâmetro DRIVES no job que iniciou a geração. Por exemplo, se a geração foi iniciada com um banco de dados salvo com DRIVE = 4, o parâmetro RECOVER DRIVES só pode ser especificado como 1, 2, 3 ou 4. Quando você especifica um número menor de DRIVES para a etapa RESTORE, ADARAI RECOVER aloca somente os DD / DLBs DD / RESTn necessários e aloca um número igual de datasets de entrada para cada DD / DLL de DD / RESTn.
DSIMDEV: DSIM Dataset Tipo de dispositivo
DSIMDEV especifica o tipo de dispositivo de dataset DSIM se diferente da especificada pelo parâmetro ADARUN DEVICE, que é o padrão.
DSIMSIZE: Tamanho do conjunto de dados DSIM
O tamanho é especificado em cilindros.
Quando o Adabas Delta Save Facility está ativo no banco de dados que está sendo recuperado, esse parâmetro deve ser especificado para que ADARAI pode especificar o parâmetro DSIMSIZE para qualquer ADARES COPY operações que ele pode ter para gerar.
FEOFPL: sincronizar vários PLOGs
Se FEOFPL = YES (o padrão), o ADARAI garante que os dados do log de proteção (PLOG) de todos os conjuntos de dados PLOG múltiplos foram copiados:
(*) Se o núcleo estiver ativo, ADARAI forçará uma chave de registro de proteção. O núcleo então chama o usuário exit 12, que copia os dados do log; ADARAI aguarda até que a cópia seja concluída. Observe que o parâmetro ADARUN UEX12 deve ser especificado sempre que FEOFPL = YES for especificado.
(*) Se o núcleo não estiver ativo, o próprio ADARAI chama a saída do usuário 12, que por sua vez copia os dados do log.
Num ambiente de cluster de núcleos, FEOFPL = YES funciona de forma diferente:
(*) Se pelo menos um núcleo de Adabas estiver disponível, ADARAI chama o núcleo para mudar os PLOGs.
(*) Se nenhum núcleo Adabas estiver disponível, ADARAI gera um trabalho que deve ser executado manualmente.
Em qualquer caso, ADARAI deve ser reiniciado com FEOFPL = NO.
FILE: Número do File FILE especifica um ou mais arquivos de banco de dados a serem incluídos quando o fluxo de job de recuperação é criado. A especificação do FILE causa a recuperação do arquivo em vez da recuperação do nível do banco de dados; Somente os arquivos especificados estão envolvidos na operação RECOVER. Se FILE não for especificado, todos os arquivos de banco de dados serão incluídos (o padrão).
JCLLOG: Controle de tarefas fornecido pelo usuário
O JCLLOG controla a listagem do controle de trabalho de entrada fornecido pelo usuário (o JCL no DDJCLIN ou o JCS no JCLIN). Se JCLLOG = YES for especificado, os elementos de controle de tarefa de entrada fornecidos pelo usuário serão impressos no log de utilitários. O padrão é nenhuma lista de instruções de controle de job de entrada (NO).
OPT: otimizar trabalho de recuperação para uma geração
Quando OPT = YES é especificado, ADARAI tenta otimizar o trabalho de recuperação que ele produz para uma determinada geração; Ou seja, ele tenta omitir etapas que não são necessárias para trazer o banco de dados ou arquivo de volta para seu estado lógico original. Quando OPT = NO é especificado, o trabalho de recuperação não é otimizado.
Nota: Quando o espaço no banco de dados é limitado, um trabalho de recuperação otimizado pode falhar devido ao fato de que o banco de dados não é construído exatamente da mesma maneira como era originalmente. Se isso ocorrer, um trabalho de recuperação gerado sem otimização deve ser usado ou o tamanho do banco de dados aumentado antes de recuperação é tentada.
PLOGDEV: Tipo de dispositivo PLOG múltiplo
O valor PLOGDEV é usado somente quando FEOFPL = YES é especificado. PLOGDEV especifica um tipo de dispositivo PLOG diferente do especificado pelo parâmetro ADARUN DEVICE, que é o padrão.
RELGEN: Número Relativo de Geração de Recuperação
RELGEN especifica o número relativo de geração a ser usado para recuperação. A geração atual é sempre acoplada com a geração relativa "0" (zero), que é também o padrão. "Duas gerações atrás", ou a geração anterior à última geração completa, é especificada como geração relativa "2". A geração especificada deve estar atualmente no RLOG. Use a função ADARAI LIST para ver as gerações RLOG atuais disponíveis. Note, no entanto, que as gerações listadas são numeradas em ordem crescente, começando com a geração "1", a primeira geração após o início da operação RLOG.
RESTFILE: Criar tarefa de arquivo de restauração
Quando RESTFILE = NO (o padrão), o fluxo de trabalho de recuperação DDJCLOUT não inclui as etapas de trabalho do ADASAV RESTORE FILE = ... para o ADASAV SAVE FILE = executado. Tais etapas de trabalho não estão incluídas porque ADARES REGENERATE não pára em ADASAV SAVE FILE = ... checkpoints.
Quando RESTFILE = YES, ADARAI RECOVER cria uma etapa de trabalho ADASAV RESTORE FILE = ... no fluxo de job de recuperação para cada execução de utilitário ADASAV SAVE FILE = ... registrada.
Observação : Ao usar RESTFILE = YES, você deve manter os conjuntos de dados de salvamento de arquivo criados na geração. Quando RESTFILE = YES e OPT = YES são especificados, os passos RESTORE FILE = criados podem acelerar o processo de recuperação porque os arquivos restaurados até a etapa RESTORE são ignorados. Quando RESTFILE = YES e OPT = NO são especificados, uma etapa RESTORE desnecessária é incluída no trabalho de recuperação. Você pode gerar o trabalho de recuperação desta maneira e, em seguida, remover manualmente todas as etapas antes das etapas RESTORE para o (s) arquivo (s) que são de interesse.
RLOGDEV: RLOG dispositivo alternativo RLOGDEV especifica o tipo de dispositivo que contém o arquivo RLOG. Se o arquivo RLOG estiver localizado no tipo de dispositivo especificado pelo parâmetro ADARUN DEVICE (o tipo de dispositivo padrão), você não precisará especificar RLOGDEV.
Exemplos
Exemplo 1: A função RECOVER cria um fluxo de job de recuperação com base na geração atual (0, o padrão). A parte SAVE RESTORE do fluxo de job inclui instruções para três conjuntos de dados de entrada: DDREST1, DDREST2 e DDREST3.
REMOVE: Remove the Recovery Aid
ADARAI REMOVE é funcionalmente o mesmo que a antiga função ADARAI NORAI; REMOVE ou NORAI podem ser especificados.
Nota: ADARAI REMOVE/NORAI deve ser executado com o banco de dados inativo.
As informações existentes do RLOG são mantidas e disponíveis para operação de listagem ou recuperação após REMOVE, até a próxima operação PREPARE ser executada. Depois que a função ADARAI PREPARE é executada, todos os dados existentes do RLOG são perdidos.
Para reiniciar o log de recuperação depois de usar a função REMOVE, execute a função ADARAI PREPARE seguida por um banco de dados ADASAV SAVE / RESTORE, RESTORE GCB e / ou SAVE DELTA / RESTORE DELTA (banco de dados) para iniciar uma nova geração. Veja a discussão do ADARAI PREPARE para obter informações sobre a preparação do RLOG.
Exemplo
Para todos os logs do Recovery Aid.
O utilitário ADARAI prepara o Log de recuperação (RLOG), lista as informações contidas no RLOG, cria as instruções de controle de job para recuperar o banco de dados e desabilita o log de ADARAI.
A "transação" de recuperação é fornecida sempre que uma sessão do Adabas é anormalmente terminada. A rotina autobackout do Adabas, que é automaticamente invocada no início de cada sessão do Adabas, remove os efeitos de todas as transações interrompidas do banco de dados. Consulte as informações de reinício / recuperação na documentação do Adabas Operations.
No entanto, quando um dataset de banco de dados (ASSO, DATA ou WORK) é destruído, é necessário restaurar e regenerar o banco de dados para recuperar os dados perdidos.
O utilitário Adara Recovery Aid ADARAI pode ser usado para automatizar e otimizar a recuperação de "banco de dados". Ele grava e relata todas as informações necessárias para recuperar o banco de dados e cria o fluxo de job de recuperação (JCL / JCS), que é a base para reexecutar os trabalhos executados desde o último SAVE até o ponto de falha e erro.
Nota: A função de geração de fluxo de job ainda não está disponível em VSE / ESA ou VM / ESA.
Conceitos e Componentes
O Adabas Recovery Aid compreende dois componentes:
(*) Uma interface (ADARAC) para coletar informações à medida que os eventos relevantes ocorrem contra o banco de dados; e
(*) Um utilitário (ADARAI) para listar as informações coletadas, gerar trabalhos para recuperar o banco de dados ou arquivos no banco de dados ou desativar o log de recuperação.
A interface de coleção
A interface de coleta é chamada pelo núcleo e por todos os utilitários para registrar informações sobre cada evento que ocorre; Por exemplo, um núcleo parar / iniciar, uma execução de utilitário ou um evento gerado pelo Adabas Online System.
Log de recuperação (RLOG)
A interface registra todas as informações de evento em um arquivo de log de recuperação (RLOG) para uso pelo componente de utilitário. O RLOG armazena as informações sobre conjuntos de dados, parâmetros de utilitário e registros de proteção necessários para criar o controle de trabalho de recuperação. O conjunto de dados RLOG é DD / RLOGR1.
Em um ambiente de cluster de núcleos, todos os núcleos usam o mesmo RLOG. Atualizações simultâneas para o RLOG são controladas por um bloqueio.
Notas:
Os conjuntos de dados seqüenciais usados pelos utilitários cujas execuções são registradas no RLOG devem ser mantidos e disponíveis para qualquer operação de recuperação; Por exemplo, a entrada DD / EBAND para uma operação ADALOD LOAD. As alterações de arquivo ADADBS agora são registradas no conjunto de dados RLOG. As informações registradas no RLOG geralmente excedem as exigidas para recuperação; Ele também pode ser usado como um registro de eventos que ocorreram em um banco de dados durante um período de tempo.
Geração: A Unidade de Recuperação
A informação é armazenada no RLOG por geração, a unidade lógica usada para a recuperação.
Uma "geração" inclui toda a atividade entre operações consecutivas de
(*) ADASAV SAVE/RESTORE (banco de dados),
(*) RESTORE GCB, e/ou
(*) SAVE DELTA /RESTORE DELTA (banco de dados).
A primeira geração inclui a primeira operação e se estende para (mas exclui) a segunda. Uma nova geração é iniciada quando um banco de dados pode ser recuperado completamente após a operação anterior.
As gerações podem ser normais, restritas ou erradas:
(*) Uma geração é rotulada como "normal" se uma reserva completa estiver disponível quando ela começou e nenhum evento incomum ocorreu enquanto as atividades estavam sendo registradas nele.
(*) Uma geração é rotulada como "restrita" quando certos eventos ocorrem durante o ciclo de registro que tornam impossível para ADARAI reconstruir o banco de dados sem a intervenção do usuário. ADARAI gera um trabalho, mas o trabalho não será executado sem a ajuda do usuário. Por exemplo, se o conjunto de dados do trabalho tiver diminuído de tamanho, o usuário deve criar um conjunto de dados do trabalho com o tamanho original para que o trabalho de recuperação possa ser executado corretamente até o ponto onde o tamanho do conjunto de dados do trabalho foi diminuído.
(*) Uma geração é rotulada como "errada" quando ocorrem erros durante o ciclo de registro, por qualquer motivo. ADARAI gera um trabalho, mas o trabalho não será executado sem alterações.
Nota:
Quando uma geração se torna restrita ou errada, a Software AG recomenda que você inicie uma nova geração o mais rápido possível, executando uma salvaguarda on-line ou off-line do banco de dados. Se o Delta Save Facility estiver instalado, um SAVE DELTA iniciará uma nova geração.
Retendo gerações não Correntes
As gerações não-correntes fornecem um histórico de operações que afetaram o banco de dados para uso na resolução de problemas ou para fins de auditoria.
O acesso a gerações não correntes é essencial se uma tentativa de recuperar um banco de dados falhar depois que a etapa RESTORE na tarefa de recuperação for executada. Neste ponto, a geração a ser recuperada torna-se a geração atual. Se for necessário reconstruir o trabalho de recuperação, a geração a ser recuperada será uma geração mais antiga.
O RLOG mantém o número de gerações especificado pelo parâmetro MINGENS durante a etapa ADARAI PREPARE. ADARAI recicla gerações quando o número armazenado no RLOG atinge o número especificado pelo parâmetro MINGENS.
Quando uma nova geração mais aqueles já armazenados excederem o espaço RLOG disponível, um dos dois eventos ocorrerá: Se o número mínimo de gerações especificado por MINGENS pode ser mantido, a geração mais antiga é substituída; de outra forma O RLOG é colocado "fora de serviço", definindo um sinalizador no bloco de controle RLOG. Nesse caso, os dados não são mais registrados.
CHKDB: Verifique o Status do banco de dados
ADARAI CHKDB [{ACTIVE | INACTIVE}]ADARAI CHKDBDISABLE: Desativar Registro de recuperação
ADARAI DISABLEA função ADARAI DISABLE desativa o registo de recuperação definindo a tabela RLOG (bloco de controlo) para o estado inactivo.
Nota:
ADARAI DISABLE deve ser executado com o banco de dados inativo.
Após DISABLE, as informações não são mais gravadas no RLOG e a geração atual é encerrada. O conteúdo do RLOG antes de DISABLE é mantido e ainda pode ser listado ou usado de outra forma para propósitos de recuperação.
O log de recuperação pode ser iniciado novamente iniciando uma nova geração.
Exemplo: Desativa todo o registro de Ajuda de recuperação.
ADARAI DISABLENota: Os RLOGs da versão 6 do Adabas não podem ser listados; Somente a versão 7 e acima de RLOGs são suportados.
A função ADARAI LIST é usada para visualizar o conteúdo do RLOG na forma de tabela:
(*) As gerações são listadas em ordem numérica;
(*) Os intervalos de blocos RLOG são listados para cada geração; e
(*) A datas de parada/inicio e os tempos cobertos por cada geração são listados.
As informações a seguir são fornecidas para cada entrada no RLOG, incluindo execuções de utilitários e entradas de início de sessão de núcleo e entradas de parada de sessão:
(*) Nome do evento para o qual a entrada do RLOG foi escrita;
(*) Data e hora em que a informação foi escrita para o RLOG;
(*) Número PLOG associado ao evento (se houver);
(*) Bloco PLOG contendo um ponto de verificação associado (se houver);
(*) Parâmetros especificados para o evento registado para as instruções DD/CARD e DD/KARTE; e
(*) Detalhes de quaisquer arquivos escritos ou lidos durante o evento registrado.
Em um ambiente de cluster de núcleo, os conjuntos de dados PLOG também são listados nas entradas de início da sessão de núcleo. O ID do núcleo do cluster (NUCID) também está listado.
Exemplo:
*** 2001-08-21 11:37:08 NUCLEUS PLOG NUMBER=4
*** START NUCLEUS SESSION NUCID 40002
SYNC PLOG BLOCK NUMBER = 1
ACTIVE PLOG DATA SET NAMES: EXAMPLE.DBddddd.PLOGR21
EXAMPLE.DBddddd.PLOGR22ADARAI LIST [GENS = {NO | YES}]
[RELGEN = {gen-number | gen-number - gen-number}]
[RLOGDEV = {device | ADARUN-device}]Parâmetros opcionais
GENS: Generation Print Control
GENS determina se a informação de geração está listada. GENS = NO lista somente as informações de controle RLOG. GENS = YES (o padrão) lista as informações de geração também.
RELGEN: Número Relativo de Geração de Recuperação RELGEN especifica o número relativo de geração (ou intervalo de números de geração) a ser listado. A geração atual é sempre acoplada com a geração relativa "0" (zero). A última geração completa é acoplada com a geração relativa 1; "Duas gerações atrás", a geração antes da última geração completada, é especificada como geração relativa "2". Exemplo:
Para listar as gerações que vão desde três gerações até a última geração completa (inclusive), especifique RELGEN = 3-1. Se o número da primeira geração especificado for menor que o número da segunda geração, o ADRAI reduz o número da segunda geração para coincidir com o primeiro.
Exemplo:
Se você especificar RELGEN = 2-3, ADARAI altera para RELGEN = 2-2. Se RELGEN não for especificado, todas as gerações serão impressas. A geração especificada deve estar atualmente no RLOG. Observe, no entanto, que em vez de um número relativo, cada geração listada tem um número de ordem ascendente, começando com 1 (a primeira geração após o início da operação RLOG).
Exemplo:
RELGEN = 0 é equivalente ao número de geração 690; RELGEN = 3-2 é equivalente aos números de geração 687 e 688.
I GEN- I BLOCK I DATE /TIME I
I NUMBER I FROM TO I FROM TO I
I--------I-----------------I--------------------------------------------I
I 690 I 715 715 I 2001-08-20 02:07:13 2001-08-20 08:51:19 I
I 689 I 714 714 I 2001-08-17 18:24:49 2001-08-20 02:03:21 I
I 688 I 713 713 I 2001-08-16 18:24:26 2001-08-17 16:48:16 I
I 687 I 712 712 I 2001-08-15 18:29:09 2001-08-16 12:54:28 I
I 686 I 711 711 I 2001-08-14 18:24:30 2001-08-15 17:45:44 I
I 685 I 710 710 I 2001-08-13 18:32:07 2001-08-14 15:46:25 I
I 684 I 709 709 I 2001-08-13 02:07:15 2001-08-13 18:00:18 I
I 683 I 708 708 I 2001-08-10 18:25:59 2001-08-13 02:03:23 I
I 682 I 707 707 I 2001-08-09 18:36:39 2001-08-10 10:24:14 IRLOGDEV: RLOG dispositivo alternativo
RLOGDEV especifica o tipo de dispositivo que contém o arquivo RLOG. Se o arquivo RLOG estiver localizado no tipo de dispositivo especificado pelo parâmetro ADARUN DEVICE (o tipo de dispositivo padrão), você não precisará especificar RLOGDEV.
Exemplos
Exemplos de entrada
Este exemplo lista todas as gerações no RLOG.
ADARAI LISTADARAI LIST RELGEN=15-1A D A R A I Vv.v SMv DBID = 00203 STARTED yyyy-mm-dd hh:mm:ss
PARAMETERS:
-----------
ADARAI LIST RELGEN=0
RECOVERY LOG FILE FOR DATABASE 203
START RABN FOR LOG DATA AREA IS 21
HIGHEST LOG AREA RABN IS 633
CURRENT VALUE FOR ROTATING RABN IS 23
I GEN- I I BLOCK I DATE /TIME I
I NUMBER I S I FROM TO I FROM TO I
I--------I---I-----------------I--------------------------------------------I
I 3 I N I 23 23 I yyyy-01-13 16:06:28 yyyy-01-13 16:11:35 I
I 2 I N I 22 22 I yyyy-01-09 16:07:10 yyyy-01-13 16:04:13 I
I 1 I N I 21 21 I yyyy-01-09 16:04:41 yyyy-01-09 16:06:16 I
I 0 I R I 20 20 I yyyy-01-09 16:04:07 yyyy-01-09 16:04:30 I
I--------I---I-----------------I--------------------------------------------I
*** yyyy-01-13 16:06:28
*** SAVE DATABASE OFFLINE
DELTA SAVE ID IS AS FOLLOWS:
FULL SAVE...............2
LOW DELTA SAVE NUMBER...0
HIGH DELTA SAVE NUMBER..0
DATE WRITTEN............yyyy-01-13
TIME WRITTEN............16:12:03
FILES = 1,2,3,19
ADARUN DBID=203,SVC=249,DEVICE=3390,PLOGRQ=YES
ADARUN NCLOG=2,CLOGDEV=3390,CLOGSIZE=150
ADARUN NPLOG=2,PLOGSIZE=1350
ADARUN PLOGDEV=3390
ADARUN DSF=YES
ADARUN UEX2=USEREX2M
ADARUN PROG=ADASAV
ADASAV SAVE
//DDSAVE1 DD DSN=EXAMPLE.ADASAV.FULL.G0058V00,
// UNIT=3390,SPACE=(TRK,(5,5)),DISP=NEW,
// DCB=(RECFM=VB,BLKSIZE=27998,LRECL=27994),
// VOL=SER=(SMS018)DDSAVE1 VOLSER=SMS018 FROM BLOCK=1 (ASSO) TO BLOCK =1598 VOLUME IS ASSOCIATED WITH PLOG NO. 6
DDSAVE1 VOLSER=SMS018 FROM BLOCK=1 (DATA)
TO BLOCK =750
VOLUME IS ASSOCIATED WITH PLOG NO. 6
*** yyyy-01-13 16:07:09 NUCLEUS PLOG NUMBER=7
*** START NUCLEUS SESSION [NUCID=nnnnn]
SYNC PLOG BLOCK NUMBER = 5
[ACTIVE PLOG DATASET NAMES: EXAMPLE.DBddddd.PLOGR21
EXAMPLE.DBddddd.PLOGR22]
ADARUN DBID=203,SVC=249,DEVICE=3390,PLOGRQ=YES
ADARUN NCLOG=2,CLOGSIZE=150,CLOGDEV=3390
ADARUN NPLOG=2,PLOGSIZE=1350
ADARUN PLOGDEV=3390
ADARUN DSF=YES
ADARUN UEX2=USEREX2M
ADARUN PROG=ADANUC
ADARUN MODE=MULTI
ADARUN LOCAL=YES
ADARUN SPT=NO
ADARUN LWP=480000
ADARUN LP=200
ADARUN TT=1800
ADARUN TNAE=1800
ADARUN LBP=80000
ADARUN NH=500
ADARUN LFP=60000
ADARUN LU=65525
ADARUN NAB=45
ADARUN LQ=12000
ADARUN LI=20000
ADARUN NT=10
ADARUN NC=300
ADARUN NU=300
ADARUN LS=20000
ADARUN TNAX=1800
ADARUN CT=300
ADARUN OPENRQ=NO
ADARUN LOGGING=NO
ADARUN LOGCB=NO
ADARUN LOGSB=NO
ADARUN LOGFB=NO
ADARUN IGNDIB=NO
ADARUN FORCE=NO
*** yyyy-01-13 16:07:18 NUCLEUS PLOG NUMBER=7
*** END NUCLEUS SESSION
HIGHEST PLOG BLOCK WRITTEN = 7
*** yyyy-01-13 16:07:22
*** COPY MULTIPLE PROTECTION LOG DATASET FOR PLOG 7
ADARUN DBID=203,SVC=249,DEVICE=3390,PLOGRQ=YES
ADARUN NCLOG=2,CLOGSIZE=150,CLOGDEV=3390
ADARUN NPLOG=2,PLOGSIZE=1350
ADARUN PLOGDEV=3390
ADARUN DSF=YES
ADARUN UEX2=USEREX2M
ADARUN PROG=ADARES,MODE=MULTI
ADARES PLCOPY OPENOUT
ADARES DSIMSIZE=5
//DDSIAUS1 DD DSN=EXAMPLE.PLOG.G0243V00,UNIT=3390,
// SPACE=(TRK,(10,1)),DISP=NEW,DCB=(RECFM=VB,
// BLKSIZE=27998,LRECL=27994),
// VOL=SER=(SMS018)
DDSIAUS1 VOLSER=SMS018 FROM BLOCK=1
TO BLOCK =7
FROM DATE =yyyy-01-13 17:07:09
TO DATE =yyyy-01-13 17:07:18
VOLUME IS ASSOCIATED WITH PLOG NO. 7
*** yyyy-01-13 16:07:39 NUCLEUS PLOG NUMBER=8
*** START NUCLEUS SESSION [NUCID=nnnnn]
SYNC PLOG BLOCK NUMBER = 3
[ACTIVE PLOG DATASET NAMES: EXAMPLE.DBddddd.PLOGR21
EXAMPLE.DBddddd.PLOGR22]
ADARUN DBID=203,SVC=249,DEVICE=3390,PLOGRQ=YES
ADARUN NCLOG=2,CLOGSIZE=150,CLOGDEV=3390
ADARUN NPLOG=2,PLOGSIZE=1350
ADARUN PLOGDEV=3390
ADARUN DSF=YES
ADARUN UEX2=USEREX2M
ADARUN PROG=ADANUC
ADARUN MODE=MULTI
ADARUN LOCAL=YES
ADARUN SPT=NO
ADARUN LWP=480000
ADARUN LP=200
ADARUN TT=1800
ADARUN TNAE=1800
ADARUN LBP=80000
ADARUN NH=500
ADARUN LFP=60000
ADARUN LU=65525
ADARUN NAB=45
ADARUN LQ=12000
ADARUN LI=20000
ADARUN NT=10
ADARUN NC=300
ADARUN NU=300
ADARUN LS=20000
ADARUN TNAX=1800
ADARUN CT=300
ADARUN OPENRQ=NO
ADARUN LOGGING=NO
ADARUN LOGCB=NO
ADARUN LOGSB=NO
ADARUN LOGFB=NO
ADARUN IGNDIB=NO
ADARUN FORCE=NO
*** yyyy-01-13 16:09:16 NUCLEUS CHECKPOINT
ENCOUNTERED
CHECKPOINT IS ON PLOG NUMBER 8 BLOCK NUMBER 4
SYNS-CHECKPOINT IS 'DELETE FILE'
FILES = 1
*** yyyy-01-13 16:09:16 NUCLEUS CHECKPOINT ENCOUNTERED
CHECKPOINT IS ON PLOG NUMBER 8 BLOCK NUMBER 5
SYNS-CHECKPOINT IS 'DELETE FILE'
FILES = 2
*** yyyy-01-13 16:10:27 NUCLEUS PLOG NUMBER=8
*** ADABAS UTILITY RUN
SYNP-CHECKPOINT ID IS 'ADALOD - LOAD'
SYNP-CHECKPOINT IS FOUND ON PLOG 8 IN BLOCK NO. 6
FILES = 1
ADARUN DBID=203,SVC=249,DEVICE=3390,PLOGRQ=YES
ADARUN NCLOG=2,CLOGSIZE=150,CLOGDEV=3390
ADARUN NPLOG=2,PLOGSIZE=1350
ADARUN PLOGDEV=3390
ADARUN DSF=YES
ADARUN UEX2=USEREX2M
ADARUN PROG=ADALOD,MODE=MULTI
ADALOD LOAD FILE=1
ADALOD NAME='EMPLOYEES'
ADALOD MAXISN=1500,DSSIZE=1
ADALOD TEMPSIZE=15,SORTSIZE=15
//DDEBAND DD
DSN=ADABAS.Vvrs.EMPL,UNIT=3390,DISP=OLD,
// VOL=SER=(ADA001)
*** yyyy-01-13 16:11:21 NUCLEUS PLOG NUMBER=8
*** ADABAS UTILITY RUN
SYNP-CHECKPOINT ID IS 'ADALOD - LOAD'
SYNP-CHECKPOINT IS FOUND ON PLOG 8 IN BLOCK NO. 7
FILES = 2
ADARUN
PROG=ADALOD,MODE=SINGLE,SVC=249,DEVICE=3390,DBID=203
ADALOD LOAD FILE=2
ADALOD NAME='VEHICLES'
ADALOD MAXISN=1000,DSSIZE=1
ADALOD TEMPSIZE=15,SORTSIZE=15
//DDEBAND DD
DSN=ADABAS.Vvrs.VEHI,UNIT=3390,DISP=OLD,
// VOL=SER=(ADA001)
*** yyyy-01-13 16:11:31 NUCLEUS PLOG NUMBER=8
*** END NUCLEUS SESSION
HIGHEST PLOG BLOCK WRITTEN = 9
*** yyyy-01-13 16:11:35
*** COPY MULTIPLE PROTECTION LOG DATASET FOR PLOG 8
ADARUN DBID=203,SVC=249,DEVICE=3390,PLOGRQ=YES
ADARUN NCLOG=2,CLOGSIZE=150,CLOGDEV=3390
ADARUN NPLOG=2,PLOGSIZE=1350
ADARUN PLOGDEV=3390
ADARUN DSF=YES
ADARUN UEX2=USEREX2M
ADARUN PROG=ADARES,MODE=MULTI
ADARES PLCOPY OPENOUT
ADARES DSIMSIZE=5
//DDSIAUS1 DD DSN=EXAMPLE.PLOG.G0244V00,UNIT=3390,
// SPACE=(TRK,(10,1)),DISP=NEW,DCB=(RECFM=VB,
// BLKSIZE=27998,LRECL=27994),
// VOL=SER=(SMS018)
DDSIAUS1 VOLSER=SMS018 FROM BLOCK=1
TO BLOCK =9
FROM DATE =yyyy-01-13 17:07:39
TO DATE =yyyy-01-13 17:11:30
VOLUME IS ASSOCIATED WITH PLOG NO. 8
A D A R A I TERMINATED NORMALLY yyyy-01-13 16:12:03PREPARE: Inicializar e Iniciar o RLOG
O log de recuperação (RLOG) deve ser preparado antes de ser usado. As etapas a seguir são necessárias para iniciar o arquivo RLOG:
Etapa 1. Formate o arquivo RLOG usando a função ADARF RLOGFRM.
Antes de executar ADARAI PREPARE, o conjunto de dados RLOG deve ser formatado usando a função RLOGFRM do utilitário ADAFRM. Se não estiver, um erro 159 é retornado.
Etapa 2. Execute a função ADARAI PREPARE para preparar o RLOG.
ADARAI PREPARE deve ser executado com o banco de dados inativo.
A função ADARAI PREPARE é utilizada para
(*) O tamanho do RLOG (o tamanho deve ser o mesmo que o valor do parâmetro SIZE da função ADAFRM RLOGFRM);
(*) O número mínimo de gerações a reter (4 é o padrão); e
(*) O tipo de dispositivo (o padrão é o tipo de dispositivo especificado pelo parâmetro ADARUN DEVICE).
Etapa 3. Execute a função ADASAV SAVE (banco de dados) para iniciar a primeira geração de logs.
Depois que a função PREPARE for executada, o registro começa para a geração inicial; No entanto, esta geração tem um status "restrito" porque não foi iniciado por um banco de dados completo salvar ou restaurar.
Consulte a documentação do Adabas Operations para obter mais informações sobre status de geração.
Sintaxe
ADARAI PREPARE RLOGSIZE = tamanho
[RLOGDEV = {device | ADARUN-device}]
[MINGENS = {count | 4}]Parâmetro Essencial
RLOGSIZE: RLOG Tamanho da Área
RLOGSIZE define o tamanho do arquivo RLOG em cilindros ou blocos. Esse valor deve ser o mesmo definido pelo parâmetro SIZE da função ADARFM RLOGFRM. RLOGSIZE deve ser especificado; Não há padrão.
Nota:O conjunto de dados RLOG está limitado a 16.777.215 (x'FFFFFF ') blocos / RABNs.
Parâmetros opcionais
MINGENS: contagem de geração RLOG
MINGENS especifica o número de gerações de registro a serem mantidas no RLOG. O RLOG indica as gerações em ordem ascendente começando por "0". O mínimo é de 4 gerações (o padrão); O máximo é 32.
RLOGDEV: RLOG Tipo de dispositivo
RLOGDEV especifica o tipo de dispositivo que contém o arquivo RLOG. Se o arquivo RLOG estiver localizado no tipo de dispositivo especificado pelo parâmetro ADARUN DEVICE (o tipo de dispositivo padrão), você não precisará especificar RLOGDEV.
Importante:
Se você escolher um tipo de dispositivo para o conjunto de dados RLOG que é diferente do padrão, você deve especificar o parâmetro RLOGDEV para todas as execuções ADARES PLCOPY e COPY também.
Exemplos
Exemplo 1: Esta função ADARAI PREPARE define e inicializa o RLOG para manter o mínimo de quatro gerações em um tamanho de log de cinco cilindros. O dispositivo RLOG padrão é o especificado pelo parâmetro ADARUN DEVICE.
ADARAI PREPARE MINGENS=4,RLOGSIZE=5ADARAI PREPARE
RLOGSIZE=20,MINGENS=20,RLOGDEV=3390RECOVER: Criar um fluxo de job de recuperação
Nota: A função RECOVER está disponível apenas para sistemas BS2000 e OS / 390 ou z / OS. Está previsto o suporte a sistemas VM / ESA, z / VM e VSE/ESA.
A função ADARAI RECOVER cria as informações de controle de job (fluxo de job de recuperação) para recuperar o banco de dados Adabas ou arquivos de banco de dados selecionados. A função RECOVER
(*) Lê as informações PLOG para determinar se um PLCOPY é necessário; e
(*) Lê o RLOG para criar o fluxo de job de recuperação a partir do controle de job de esqueleto.
ADARAI RECOVER cria o fluxo de job necessário para restaurar o banco de dados ou arquivos para a condição antes da função RECOVER foi executada. O fluxo de job concluído é enviado para o conjunto de dados DD / JCLOUT.
Quando apropriado, ADARAI inclui mensagens de erro ou informações no fluxo de job gerado. Em seguida, você deve corrigir manualmente os erros antes de enviar o trabalho. A existência de mensagens no fluxo de job é indicada por um código de retorno diferente de zero de ADARAI RECOVER.
Para sistemas BS2000, RECOVER adicionalmente
Executa, ao gerar o controle do trabalho, as mesmas verificações realizadas pela função LIST para BS2000; e
Inclui instruções BS2000 / REMARK no controle de trabalho criado para verificações que produzem erros.
Nota: Quando ocorrem tais erros, o controle do trabalho deve ser corrigido manualmente.
Processamento de recuperação
A função ADARAI RECOVER cria um job com base na seqüência exata encontrada na geração a ser recuperada:
Ele restaura o banco de dados a partir dos conjuntos de dados criados pela operação que iniciou a geração;
Ele regenera PLOGs até o próximo ponto de verificação de utilidade encontrado;
Ele gera uma etapa de trabalho para reexecute o utilitário e iniciar a regeneração após esse ponto de verificação.
Esta seqüência continua até que todos os utilitários tenham sido repetidos e o último bloco PLOG na geração tenha sido regenerado.
O diagrama a seguir ilustra o funcionamento do ADARAI, onde
(*) Um banco de dados é salvo para iniciar uma nova geração em A.
(*) O banco de dados é executado e em vários momentos durante a geração
(*) Uma atualização é executada no arquivo 1;
(*) Um reordenamento é executado no arquivo 2;
(*) Um invertido é executado contra o arquivo 3; e
(*) Uma carga é executada no arquivo 5.
+---------+
| Número | Tempo --------->
| do File |
+---------+--------------+---------+---------+---------+-------+
| 1 | UPDATE : : : : |
| | : : : : : |
+---------+----+---------+---------+---------+---------+-------+
| 2 | : : : : REORDER |
| | : : : : : |
+---------+----+---------+---------+---------+---------+-------+
| 3 | : INVERT : : : |
| | : : : : : |
+---------+----+---------+---------+---------+---------+-------+
| 4 | : : : : : |
| | : : : : : |
+---------+ : : +---------+---------+-------+
| 5 | : : LOAD : : |
| | : : : : : |
| | : : : : : |
| | : : : : : |Tendo em conta o que precede, a ordem de recuperação é a seguinte:
1 - Uma gravação completa ou uma gravação completa mais as salvaguardas delta são restauradas para retornar o banco de dados para o status em A.
2 - Um regenerado de banco de dados é executado do primeiro ponto de verificação em A até o ponto de verificação de atualização em B. O trabalho de regeneração termina.
3 - O utilitário de atualização é executado para o arquivo 1 e um regenerado de banco de dados é executado entre o ponto de verificação em B eo ponto de verificação invertido em C.
4 - O utilitário de inverter é executado para o arquivo 3 e um regenerado de banco de dados é executado entre o ponto de verificação C eo ponto de verificação de carga em D.
5 - O utilitário de carregamento é executado para o arquivo 5 e um regenerado de banco de dados é executado entre o ponto de verificação D eo ponto de verificação de reordenação em E.
6 - A reordenação é executada para o arquivo 3 e um banco de dados é gerado entre o ponto de verificação E eo nível mais atualizado do banco de dados em F.
Processamento de recuperação otimizado
O parâmetro OPT para a função RECOVER do ADARAI é usado para identificar operações ou seqüências que minimizariam o tempo necessário para recuperar um banco de dados grande.
Por exemplo, se um arquivo com 10.000 atualizações é excluído ou recarregado, deve ser possível evitar a restauração do arquivo desde o início, reproduzindo as 10.000 atualizações e, em seguida, jogando tudo fora quando a operação de exclusão ou carregamento ocorre.
Quando a otimização é selecionada, ADARAI não restaurar o arquivo de exemplo na restauração principal para o trabalho. Regeneração para o arquivo ocorre somente após o arquivo foi excluído ou criado pela carga:
(*) Um arquivo excluído não tem mais atualizações;
(*) Para um arquivo criado por uma carga, somente as atualizações subseqüentes à carga são importantes.
Quando um fluxo de job otimizado é usado, o banco de dados recuperado é reconstruído de uma maneira que é diferente da compilação original. Como os trabalhos de recuperação otimizados não são reproduzidos exatamente da mesma maneira que os trabalhos originais, problemas podem ocorrer na recuperação; Por exemplo, espaço insuficiente pode estar disponível no banco de dados. Na maioria dos casos, no entanto, o risco é mínimo comparado com os benefícios potenciais de otimizar a recuperação do banco de dados. Cada situação deve ser examinada para possíveis problemas.
Requisitos
Para gerar um trabalho de recuperação que será executado com êxito, ADARAI impõe as seguintes condições:
(*) O banco de dados deve ser executado com o registro de proteção dupla ou múltipla ativo.
(*) Conjuntos de dados seqüenciais para funções de utilitário que atualizam arquivos no banco de dados devem ser mantidos.
(*) Os conjuntos de dados de saída seqüenciais criados pelas funções SAVE ou MERGE devem ser mantidos. Isso se aplica às funções SAVE FILE somente se RESTFILE = YES for usado para ADARAI RECOVER.
(*) Os conjuntos de dados retidos devem manter seus nomes originais; ADARAI não consegue rastrear cópias com nomes diferentes.
A Software AG recomenda que os conjuntos de dados retidos sejam catalogados.
Restrições
Shadow Databases
Se bancos de dados "shadow" (sombra) ou cópias de bancos de dados normais de produção forem construídos restaurando a saída de salvamento delta eo conjunto de dados DSIM para salvar o banco de dados original, ADARAI não tem conhecimento da atividade do PLOG ocorrida durante o delta save no banco de dados original e portanto Não é possível reconstruir o conjunto de dados DSIM se uma operação de restauração se torna necessária no banco de dados sombra. No entanto, se o conjunto de dados DSIM e o conjunto de dados de salvamento delta forem mesclados para criar um novo conjunto de dados de salvamento delta "off-line" e o novo conjunto de dados mesclado for restaurado para o banco de dados sombra, o ADARAI tem todas as informações necessárias para recuperar o banco de dados sombra. O PLOG não é necessário neste caso.
Restaurando Delta salva com um conjunto de dados DSIM
Em geral, ADARAI trata RESTORE DELTA processamento sem problemas. No entanto, se o DELTA RESTORE usa um conjunto de dados DSIM (que é essencialmente um conjunto de dados "funcionando"), o conjunto de dados DSIM pode não estar intacto se um ADARAI RECOVER se torna necessário. O ADARAI registra, portanto, as solicitações COPY ou PLCOPY usadas para criar um conjunto de dados DSIM e emite uma etapa de trabalho para reconstruir o conjunto de dados antes de tentar reproduzir um DELTA RESTORE durante o processamento RECOVER. ADARAI pesquisa o RLOG inteiro para entradas apropriadas. Se as entradas não puderem ser encontradas, ADARAI não é possível reconstruir o conjunto de dados DSIM antes da etapa RESTORE e, portanto, não é possível reproduzir o RESTAURAR DELTA.
Arquivo DD/FILEA
Em um trabalho de recuperação gerado, ADARAI grava o arquivo DD / FILEA do utilitário ADAORD. Isso não pode ser evitado porque as funções REORDER devem ser repetidas e exigem que o arquivo DD / FILEA seja gravado.
Neste caso, aplicam-se as seguintes restrições:
(*) O processamento ADAORD STORE lê simplesmente o mesmo DD / FILEA lido quando o utilitário foi originalmente executado como parte da geração sendo recuperada.
(*) Um arquivo temporário (DISP = (NEW, DELETE), que é excluído depois que a etapa é executada) pode ser usado para DD / FILEA porque a tarefa de recuperação cria e exclui o arquivo novamente quando ele é executado.
(*) Um arquivo existente (DISP = OLD) pode ser usado para DD / FILEA. Se ele ainda existe quando o trabalho de recuperação é executado, ADARAI simplesmente aloca o arquivo com a disposição que tinha quando o trabalho original foi executado.
(*) Se um novo arquivo (DISP = NEW, CATLG) for alocado para DD / FILEA e mantido na etapa original do ADAORD REORDER, e se ele ainda existir quando a tarefa de recuperação chegar ao passo REORDER (o que é normal), o ADARAI tentará criar O mesmo arquivo novamente, o que faz com que o trabalho falhe.
(*) Se um GDG é usado, o trabalho de recuperação ADARAI vê somente o nome do conjunto de dados real criado pela geração. Se o conjunto de dados já existir (o que é normal), ADARAI arrempts para criar o mesmo arquivo novamente, o que faz com que o trabalho falhar.
Entrada necessária para recuperação
Os conjuntos de dados a seguir são inseridos na função ADARAI RECOVER:
(*) DD/RLOGR1, o log de recuperação.
(*) DD/PLOGR1 e DD / PLOGRn, os registos de protecção múltipla, que são necessários quando é utilizado o parâmetro ADARAI RECOVER FEOFPL = YES (o predefinido).
(*) DD/JCLIN, que fornece instruções de controle de job de esqueleto dependentes do site. A operação RECOVER funde essas instruções com as informações RLOG para criar um fluxo de job de recuperação de banco de dados completo.
Em sistemas BS2000, DDJCLIN é um conjunto de dados SAM com formato de registro variável. EDT pode ser usado para criar e editar este conjunto de dados. Consulte a seção Controle de trabalho de esqueleto para obter mais informações.
Em sistemas OS / 390 ou z / OS, o conjunto de dados DDJCLIN deve ser definido com RECFM = FB, LRECL = 80 e um BLKSIZE que é um múltiplo de 80 bytes.
Saída da Operação de Recuperação
A saída ADARAI RECOVER é um fluxo de job pronto para execução para recuperar o banco de dados. Este fluxo de job de recuperação é gravado no arquivo DD / JCLOUT. Se uma possível condição de erro for detectada durante a operação RECOVER, ADARAI emite uma mensagem de aviso e termina com um código de condição de 4. Consulte a seção Verificação de pré-recuperação .
Em sistemas BS2000, DDJCLOUT e DDJCLCON são conjuntos de dados SAM com formato de registro variável. Eles estão em conformidade com as convenções de controle de trabalho BS2000.
Em sistemas OS/390 ou z/OS, a instrução DDJCLOUT DD deve apontar para um conjunto de dados definido com RECFM = FB, LRECL = 80 e um BLKSIZE que é um múltiplo de 80 bytes.
O fluxo de job de recuperação inclui etapas de trabalho para iniciar o núcleo
(*) Antes da primeira etapa de trabalho de regeneração; e
(*) Após qualquer operação de utilitário que faz com que o núcleo termine automaticamente.
Os trabalhos de ADARAI RECOVER replay todos os utilitários com o banco de dados ativo, se o utilitário foi originalmente executado no modo de usuário único ou não. Os utilitários originalmente executados no modo de usuário único são reproduzidos no modo multiusuário. Essas etapas de trabalho são descritas nas seções Criando o Fluxo de Trabalho de Recuperação e o Controle de Trabalho de Esqueleto.
Executando a função RECOVER
A função RECOVER é executada uma geração de cada vez sob o controle do parâmetro RELGEN. Se RELGEN não for especificado, o padrão é a geração atual.
RECOVER pode ser executado com o núcleo ativo ou inativo. Ele pode ser executado mais de uma vez para a mesma geração porque não altera as informações do RLOG para essa geração.
No entanto, se RECOVER for rerun após uma falha durante a execução de um fluxo de job de recuperação DD / JCLOUT, o novo fluxo de job de recuperação produzido pode ser diferente do fluxo de job de recuperação original. A razão é que o fluxo de job de recuperação original pode executar utilitários contra o banco de dados que atualiza o RLOG. A nova operação RECOVER cria um fluxo de job de recuperação para os utilitários executados como parte do fluxo de trabalho de recuperação falhado.
Além disso, se o fluxo de job de recuperação falhar após a execução de um ADASAV RESTORE, uma nova geração é criada. Neste caso, execute RECOVER usando o parâmetro RELGEN = 1 para obter a geração original.
Processando o PLOG - No início da execução, se ADARAI RECOVER FEOFPL = YES, RECOVER lê os PLOGs, procurando informações que devem ser copiadas. Se necessário, ele chama o núcleo para forçar uma chave PLOG. Se o núcleo estiver inativo, ele invoca a user exit 2.
Lendo o Registro de Recuperação - Em seguida, RECOVER lê o controle de trabalho esqueleto em armazenamento e lê o RLOG em ordem cronológica, começando no início da geração especificada pelo parâmetro RELGEN. Veja Geração: A Unidade de Recuperação para uma definição de geração. Se todo o banco de dados estiver sendo recuperado, o RECOVER usa as informações de ADASAV SAVE ou RESTORE para criar uma nova operação de banco de dados RESTORE / RESTONL. Para recuperação em nível de arquivo, ele usa as informações de banco de dados SAVE / RESTORE para criar uma função RESTORE FILE=...
Criando o Fluxo de Trabalho de Recuperação - Depois de criar um fluxo de job para restaurar o banco de dados ou arquivo, RECOVER cria uma etapa de trabalho para iniciar o núcleo, usando a instrução %% JCL-STARTNUC. RECOVER cria o primeiro passo de trabalho de regeneração. Esta etapa de trabalho não contém um ponto de verificação FROM (FROMCP) a menos que um SAVE on-line (ou DELTA SAVE) tenha sido a base para iniciar a geração. Nesse caso, o regenerado começa no ponto de verificação final (SYN2) da salvaguarda on-line.
Todos os PLOGs até e incluindo o próximo ponto de verificação de serviço (no qual o REGENERATE deve parar) são incluídos e os parâmetros apropriados são fornecidos à função ADARES REGENERATE. Se mais de 99 PLOGs devem ser regenerados, ADARAI gera várias etapas de trabalho REGENERATE, cada uma processando até 99 conjuntos de dados PLOG de entrada. Uma vez que os PLOGs são regenerados até a próxima execução do utilitário, o passo de tarefa de utilitário é gerado no trabalho de recuperação de saída. ADARAI, em seguida, insere outra etapa de trabalho REGENERATE que inclui todos os PLOGs até e incluindo o próximo ponto de verificação do utilitário.
O trabalho de recuperação continua inserindo etapas REGENERATE e etapas de utilitário até que ele detecta o final da geração especificada pelo parâmetro RELGEN. Nesse ponto, o fluxo de job concluído é enviado para o arquivo DD / JCLOUT.
Recuperação de nível de arquivo
A recuperação pode ser feita em um nível de arquivo especificando o parâmetro FILE da função RECOVER. O processo de recuperação de nível de arquivo é essencialmente o mesmo que o processo de recuperação de nível de banco de dados, mas é restrito aos arquivos especificados usando o parâmetro FILE.
ADARAI produz um resultado específico do arquivo em DD / JCLOUT adicionando parâmetros às instruções de execução do utilitário. Por exemplo, suponha que a seguinte instrução estava na instrução ADASAV RESTORE original:
ADASAV RESTORE FMOVE=2,3,NIRABN=100,1000,DSSIZE=550B,20ADASAV RESTORE FMOVE=2,3,NIRABN=100,1000,DSSIZE=550B,20Nota: Se um ficheiro a recuperar for parte de uma cadeia de ficheiros expandida ou estiver acoplado, todos os ficheiros da cadeia ou da lista acoplada devem ser recuperados em conjunto. Se todos os arquivos acoplados ou cadeias de arquivos expandidos não forem recuperados juntos, ADARAI detecta isso e a função ADARAI RECOVER falha.
O núcleo Adabas deve estar ativo antes de executar um trabalho de recuperação em nível de arquivo. Isso é diferente do trabalho de recuperação no nível do banco de dados, que inicia o próprio banco de dados.
Uma operação RECOVER nível de arquivo não cria controle de trabalho para utilitários que foram executados em todo o banco de dados (por exemplo, ADADEF NEWWORK). As exceções a isso são utilitários que podem ser reexecuted para arquivos individuais, bem como o banco de dados completo. Um exemplo é ADASAV RESTORE (banco de dados), que fornece um dataset de entrada DD / SAVE que pode ser usado para criar ADASAV RESTORE FILE=... job control.
Sintaxe
ADARAI RECOVER [AUTOBACKOUT]
[DRIVES = {number | 1}]
[DSIMSIZE = {tamanho, DSIMDEV = {device | ADARUN-device}}]
+---------------------------------
| NO
| FEOFPL =
| YES [,PLOGDEV = {device | ADARUN-device}
+---------------------------------
[FILE = {file-list [,AUTOBACKOUT]]
[JCLLOG = {YES | NO}]
[OPT = {YES | NO}]
[RELGEN = {number | 0}]
[RESTFILE = {YES | NO}]
[RLOGDEV = {device | ADARUN-device}]Parâmetros Opcionais e Subparâmetros
AUTOBACKOUT: Retirar transações incompletas
AUTOBACKOUT só pode ser especificado para recuperação de nível de arquivo. Se AUTOBACKOUT for especificado, as transações que não foram concluídas no final da última função REGENERATE no trabalho de recuperação são excluídas. Somente as transações concluídas são deixadas no banco de dados. Se AUTOBACKOUT não for especificado, transações incompletas são deixadas no banco de dados. Para recuperação no nível do banco de dados, transações incompletas no final da última função REGENERATE são sempre excluídas.
DRIVES: ADASAV Restore Input Drive Volumes
DRIVES é o número de conjuntos de dados de entrada a serem usados como entrada para a etapa RESTORE do job de recuperação que está sendo gerado. O parâmetro DRIVES especificado deve ser igual ou menor que o parâmetro DRIVES no job que iniciou a geração. Por exemplo, se a geração foi iniciada com um banco de dados salvo com DRIVE = 4, o parâmetro RECOVER DRIVES só pode ser especificado como 1, 2, 3 ou 4. Quando você especifica um número menor de DRIVES para a etapa RESTORE, ADARAI RECOVER aloca somente os DD / DLBs DD / RESTn necessários e aloca um número igual de datasets de entrada para cada DD / DLL de DD / RESTn.
DSIMDEV: DSIM Dataset Tipo de dispositivo
DSIMDEV especifica o tipo de dispositivo de dataset DSIM se diferente da especificada pelo parâmetro ADARUN DEVICE, que é o padrão.
DSIMSIZE: Tamanho do conjunto de dados DSIM
O tamanho é especificado em cilindros.
Quando o Adabas Delta Save Facility está ativo no banco de dados que está sendo recuperado, esse parâmetro deve ser especificado para que ADARAI pode especificar o parâmetro DSIMSIZE para qualquer ADARES COPY operações que ele pode ter para gerar.
FEOFPL: sincronizar vários PLOGs
Se FEOFPL = YES (o padrão), o ADARAI garante que os dados do log de proteção (PLOG) de todos os conjuntos de dados PLOG múltiplos foram copiados:
(*) Se o núcleo estiver ativo, ADARAI forçará uma chave de registro de proteção. O núcleo então chama o usuário exit 12, que copia os dados do log; ADARAI aguarda até que a cópia seja concluída. Observe que o parâmetro ADARUN UEX12 deve ser especificado sempre que FEOFPL = YES for especificado.
(*) Se o núcleo não estiver ativo, o próprio ADARAI chama a saída do usuário 12, que por sua vez copia os dados do log.
Num ambiente de cluster de núcleos, FEOFPL = YES funciona de forma diferente:
(*) Se pelo menos um núcleo de Adabas estiver disponível, ADARAI chama o núcleo para mudar os PLOGs.
(*) Se nenhum núcleo Adabas estiver disponível, ADARAI gera um trabalho que deve ser executado manualmente.
Em qualquer caso, ADARAI deve ser reiniciado com FEOFPL = NO.
FILE: Número do File FILE especifica um ou mais arquivos de banco de dados a serem incluídos quando o fluxo de job de recuperação é criado. A especificação do FILE causa a recuperação do arquivo em vez da recuperação do nível do banco de dados; Somente os arquivos especificados estão envolvidos na operação RECOVER. Se FILE não for especificado, todos os arquivos de banco de dados serão incluídos (o padrão).
JCLLOG: Controle de tarefas fornecido pelo usuário
O JCLLOG controla a listagem do controle de trabalho de entrada fornecido pelo usuário (o JCL no DDJCLIN ou o JCS no JCLIN). Se JCLLOG = YES for especificado, os elementos de controle de tarefa de entrada fornecidos pelo usuário serão impressos no log de utilitários. O padrão é nenhuma lista de instruções de controle de job de entrada (NO).
OPT: otimizar trabalho de recuperação para uma geração
Quando OPT = YES é especificado, ADARAI tenta otimizar o trabalho de recuperação que ele produz para uma determinada geração; Ou seja, ele tenta omitir etapas que não são necessárias para trazer o banco de dados ou arquivo de volta para seu estado lógico original. Quando OPT = NO é especificado, o trabalho de recuperação não é otimizado.
Nota: Quando o espaço no banco de dados é limitado, um trabalho de recuperação otimizado pode falhar devido ao fato de que o banco de dados não é construído exatamente da mesma maneira como era originalmente. Se isso ocorrer, um trabalho de recuperação gerado sem otimização deve ser usado ou o tamanho do banco de dados aumentado antes de recuperação é tentada.
PLOGDEV: Tipo de dispositivo PLOG múltiplo
O valor PLOGDEV é usado somente quando FEOFPL = YES é especificado. PLOGDEV especifica um tipo de dispositivo PLOG diferente do especificado pelo parâmetro ADARUN DEVICE, que é o padrão.
RELGEN: Número Relativo de Geração de Recuperação
RELGEN especifica o número relativo de geração a ser usado para recuperação. A geração atual é sempre acoplada com a geração relativa "0" (zero), que é também o padrão. "Duas gerações atrás", ou a geração anterior à última geração completa, é especificada como geração relativa "2". A geração especificada deve estar atualmente no RLOG. Use a função ADARAI LIST para ver as gerações RLOG atuais disponíveis. Note, no entanto, que as gerações listadas são numeradas em ordem crescente, começando com a geração "1", a primeira geração após o início da operação RLOG.
RESTFILE: Criar tarefa de arquivo de restauração
Quando RESTFILE = NO (o padrão), o fluxo de trabalho de recuperação DDJCLOUT não inclui as etapas de trabalho do ADASAV RESTORE FILE = ... para o ADASAV SAVE FILE = executado. Tais etapas de trabalho não estão incluídas porque ADARES REGENERATE não pára em ADASAV SAVE FILE = ... checkpoints.
Quando RESTFILE = YES, ADARAI RECOVER cria uma etapa de trabalho ADASAV RESTORE FILE = ... no fluxo de job de recuperação para cada execução de utilitário ADASAV SAVE FILE = ... registrada.
Observação : Ao usar RESTFILE = YES, você deve manter os conjuntos de dados de salvamento de arquivo criados na geração. Quando RESTFILE = YES e OPT = YES são especificados, os passos RESTORE FILE = criados podem acelerar o processo de recuperação porque os arquivos restaurados até a etapa RESTORE são ignorados. Quando RESTFILE = YES e OPT = NO são especificados, uma etapa RESTORE desnecessária é incluída no trabalho de recuperação. Você pode gerar o trabalho de recuperação desta maneira e, em seguida, remover manualmente todas as etapas antes das etapas RESTORE para o (s) arquivo (s) que são de interesse.
RLOGDEV: RLOG dispositivo alternativo RLOGDEV especifica o tipo de dispositivo que contém o arquivo RLOG. Se o arquivo RLOG estiver localizado no tipo de dispositivo especificado pelo parâmetro ADARUN DEVICE (o tipo de dispositivo padrão), você não precisará especificar RLOGDEV.
Exemplos
Exemplo 1: A função RECOVER cria um fluxo de job de recuperação com base na geração atual (0, o padrão). A parte SAVE RESTORE do fluxo de job inclui instruções para três conjuntos de dados de entrada: DDREST1, DDREST2 e DDREST3.
ADARAI RECOVER,DRIVES=3ADARAI RECOVER,RELGEN=1,OPT=YADARAI RECOVER,RELGEN=1,OPT=YREMOVE: Remove the Recovery Aid
ADARAI REMOVE é funcionalmente o mesmo que a antiga função ADARAI NORAI; REMOVE ou NORAI podem ser especificados.
Nota: ADARAI REMOVE/NORAI deve ser executado com o banco de dados inativo.
ADARAI REMOVEAs informações existentes do RLOG são mantidas e disponíveis para operação de listagem ou recuperação após REMOVE, até a próxima operação PREPARE ser executada. Depois que a função ADARAI PREPARE é executada, todos os dados existentes do RLOG são perdidos.
Para reiniciar o log de recuperação depois de usar a função REMOVE, execute a função ADARAI PREPARE seguida por um banco de dados ADASAV SAVE / RESTORE, RESTORE GCB e / ou SAVE DELTA / RESTORE DELTA (banco de dados) para iniciar uma nova geração. Veja a discussão do ADARAI PREPARE para obter informações sobre a preparação do RLOG.
Exemplo
Para todos os logs do Recovery Aid.
ADARAI REMOVE
0 comentários:
Enviar um comentário