Recuperação de Dados e High Availability

Visão Geral de Backup

Observe as restrições a seguir:

• A inicialização de uma operação de backup on-line de um espaço de tabela DMS é permitida quando uma tabela dentro do mesmo espaço de tabela está sendo reorganizada on-line. Onde provavelmente pode haver bloqueios pendentes da operação de reorganização durante a fase de truncamento.
• A inicialização de uma operação de backup on-line de um espaço de tabela SMS não é permitida quando uma tabela dentro do mesmo espaço de tabela está sendo reorganizada on-line. Ambas as operações requerem um bloqueio exclusivo.

Utilizando Backup

As seguintes restrições se aplicam ao utilitário de backup:

• Uma operação de backup do espaço de tabelas e uma operação de restauração do espaço de tabela não podem ser executadas ao mesmo tempo, mesmo que espaços de tabelas diferentes estejam envolvidos.
• Se deseja estar capacitado a realizar recuperação rollforward em um ambiente de banco de dados particionado, você deve fazer o backup regularmente do banco de dados na lista de nós e deve ter, pelo menos, uma imagem de backup dos outros nós do sistema (mesmo daqueles que não contenham dados de usuário para o banco de dados). Duas situações solicitam a imagem de backup de uma partição de banco de dados no servidor da partição de banco de dados que não contém dados de usuário para o banco de dados:
  • O servidor da partição de banco de dados foi incluído no sistema de banco de dados após a realização do último backup e foi necessário realizar recuperações avançadas nesse servidor da partição de banco de dados.
  • É utilizada recuperação point-in-time, a qual requer que todas as partições de banco de dados no sistema estejam em estado de pendência rollforward.
  • Operações de backup on-line para espaços de tabela DMS são incompatíveis com as operações a seguir:
    • carregar
    • Reorganização (apenas off-line); (a reorganização on-line de uma tabela no espaço de tabelas que estão em backup pode ser utilizada, porém pode haver bloqueios pendentes durante a fase de truncamento da operação de reorganização).
    • área de tabelas de queda
    • truncamento da tabela
    • criação de índice
    • não registrado em log inicialmente (utilizado com as instruções CREATE TABLE e ALTER TABLE)

Visão Geral da High Availability Disaster Recovery

Ao executar os comandos START HADR, STOP HADR ou TAKEOVER HADR, os códigos de erro correspondentes podem ser gerados: SQL01767N, SQL01769N ou SQL01770N com um código de razão de 98. O código de razão indica que não há licença instalada para o HADR no servidor em que o comando foi executado. Para corrigir o problema, instale uma licença de HADR válida utilizando db2licm ou instale uma versão do servidor que contém uma licença de HADR válida como parte de sua distribuição.

Suporte a Backup e Restauração de Plataforma Cruzada

O DB2 UDB (Universal Database) suporta operações de backup e restauração de plataforma cruzada.

É possível restaurar os bancos de dados criados em uma plataforma DB2 UDB Versão 8 32 bits Windows para uma plataforma DB2 UDB Versão 8 64 bits Windows ou o contrário.

É possível restaurar bancos de dados criados em uma plataforma DB2 UDB Versão 8 32 bits Linux x86 para uma plataforma DB2 UDB Versão 8 64 bits Linux x86-64 ou IA64 ou o contrário.

É possível restaurar bancos de dados criados em plataformas AIX, HP-UX, Linux PPC, Linux zSeries ou Solaris Operating Environment do DB2 UDB Versão 8, em 32 ou em 64 bits, para plataformas AIX, HP-UX, Linux PPC, Linux zSeries ou Solaris Operating Environment do DB2 UDB Versão 8 (32 ou 64 bits).

Fazendo Backup para Fita (Linux)

O limite máximo de tamanho de bloco para dispositivos de fita 3480 e 3490 no Linux é 61 440 bytes

Tivoli Storage Manager

Ao chamar os comandos BACKUP DATABASE ou RESTORE DATABASE, você pode especificar se deseja utilizar o produto TSM (Tivoli Storage Manager) para gerenciar operação de backup ou restauração de banco de dados ou do espaço de tabelas. O nível mínimo requerido da API do cliente TSM é a Versão 4.2.0, exceto no seguinte:

• Sistemas Solaris de 64 bits, que requerem a API do cliente TSM Versão 4.2.1.
• Sistemas Operacionais Windows NT de 64 bits que requerem a API de cliente do TSM Versão 5.1.
• Linux para iSeries e pSeries de 32 bits que requer no mínimo a API de cliente do TSM Versão 5.1.5
• Linux para iSeries e pSeries de 64 bits que requer no mínimo a API de cliente do TSM Versão 5.3
• Sistemas Linux no AMD Opteron de 64 bits que requerem no mínimo a API de cliente do TSM Versão 5.2.0.
• Linux para zSeries de 64 bits que requer no mínimo a API de cliente do TSM Versão 5.2.2.

Restrições de Valores para os Parâmetros de Host Local e de Serviço Local do HADR

Quando especificar valores para os parâmetros de host local e de serviço local do HADR (High Availability Disaster Recovery) (HADR_LOCAL_SVC e HADR_REMOTE_SVC) durante a preparação de um comando update database configuration, os valores devem ser portas que não estão sendo utilizadas por nenhum outro serviço. Se os parâmetros estiverem sendo configurados utilizando a linha de comandos do Linux ou UNIX, os valores deverão também ser definidos no arquivo /etc/services.

Requisitos de Sistema Adicionais para High Availability Disaster Recovery

Se você criar um espaço de tabelas no banco de dados principal e a reprodução de registro falhar no banco de dados de espera porque os contêineres não estão disponíveis, o banco de dados principal não receberá uma mensagem de erro indicando que a reprodução de registro falhou.

Para verificar erros de reprodução de registro, é necessário monitorar o db2diag.log e o registro de administração no banco de dados de espera quando estiver criando novos espaços de tabelas.

Se ocorrer uma operação de tomada de controle, o novo espaço de tabelas criado não estará disponível no novo banco de dados principal. Para recuperar-se desta situação, restaure o espaço de tabelas no novo banco de dados principal a partir de uma imagem de backup.

No exemplo a seguir, o espaço de tabelas MY_TABLESPACE é restaurado no banco de dados MY_DATABASE antes de ser utilizado como o novo banco de dados principal:

1. db2 connect to my_database
2. db2 list tablespaces show detail
   Nota:
   Execute o comando db2 list tablespaces show detail para mostrar o status de todos os espaços de tabelas e obter o número do ID do espaço de tabelas requerido para a Etapa 5.
3. db2 stop hadr on database my_database
4. db2 "restore database my_database tablespace (my_tablespace) online redirect"
5. db2 "set tablespace containers for my_tablespace_ID_# ignore rollforward container operations using (path '/my_new_container_path/')"
6. db2 "restore database my_database continue"
7. db2 rollforward database my_database to end of logs and stop tablespace "(my_tablespace)"
8. db2 start hadr on database my_database as primary

Operações Não-replicadas para Recuperação de Dados e High Availability

A documentação da Versão 8.2 afirma:

BLOBs e CLOBs não são replicados; no entanto, o espaço para eles será alocado no banco de dados de espera.

A afirmação deve ser lida da seguinte forma:

BLOBs e CLOBs não registrados não são replicados; no entanto, o espaço para eles será alocado no banco de dados de espera.

O HADR Não Suporta Registros Brutos

O HADR (High Availability Disaster Recovery) não suporta a utilização de E/S brutas (acesso direto ao disco) para arquivos de registro do banco de dados. Se o HADR for iniciado com o comando START HADR ou se o banco de dados for reiniciado com o HADR configurado e forem detectados registros brutos, o comando associado falhará com o código de razão SQL1768N "9".

Comparação entre o Monitor de Falhas e o Monitor de Funcionamento

O monitor de funcionamento e o monitor de falhas são ferramentas que funcionam em uma única |instância de banco de dados. O monitor de funcionamento utiliza indicadores de funcionamento para avaliar o funcionamento de aspectos específicos de desempenho do |gerenciador de banco de dados ou de desempenho do banco de dados. Um indicador de funcionamento avalia o funcionamento de algum aspecto |de uma classe específica de objetos de banco de dados, como um espaço de tabelas. Os indicadores de funcionamento |podem ser avaliados em critérios específicos para determinar o funcionamento dessa |classe de objeto de banco de dados. Além disso, os indicadores de funcionamento podem gerar alertas para notificá-lo quando um indicador exceder um limite ou indicar que um objeto de |banco de dados está em um estado anormal

Por comparação, o monitor de falhas é responsável apenas por manter a instância |que ele está monitorando ativa e em execução. Se a instância do DB2 UDB que ele está monitorando for encerrada inesperadamente, o monitor de falhas reiniciará a instância. O monitor de falhas não está disponível no Windows.

Desativando o Monitoramento de Falhas

Para desativar o monitoramento de falhas para a instância de banco de dados DB2INST1, digite o seguinte comando a partir de uma janela de comandos do DB2 UDB:

   db2fm -i db2inst1 -f no

Para confirmar se um monitor de falhas não está mais em execução para DB2INST1, digite o |seguinte comando em sistemas UNIX:

   ps -ef|grep -i fm

Em sistemas Linux, digite o seguinte comando:

   ps auxw|grep -i fm

Uma entrada que mostra db2fmd e DB2INST1 indica que o monitor de falhas |ainda está em execução nessa instância. Para desativar o monitor de falhas, digite |o seguinte comando como o proprietário da instância:

   db2fm -i db2inst1 -D