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.
O DB2 UDB (Universal Database) suporta operações de backup e restauração de plataforma cruzada. É possível restaurar bancos de dados criados em uma plataforma Windows de 32 bits do DB2 UDB Versão 8 para uma plataforma Windows de 64 bits do DB2 UDB Versão 8 ou o contrário. É possível restaurar bancos de dados criados em uma plataforma Linux x86 de 32 bits do DB2 UDB Versão 8 para uma plataforma Linux x86-64 ou IA64 de 64 bits do DB2 UDB Versão 8 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).
O limite máximo de tamanho de bloco para dispositivos de fita 3480 e 3490 no Linux é 61 440 bytes
| Dispositivo | Conexão | Limite de Tamanho de Bloco | Limite do Tamanho de Buffer do DB2 (em páginas de 4 KB) |
|---|---|---|---|
| 3480 | s370 | 61 440 | 15 |
| 3490 | s370 | 61 440 | 15 |
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:
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.
Se você criar um espaço de tabelas no banco de dados principal e a reprodução de log 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 log falhou.
Para verificar erros de reprodução de log, é necessário monitorar o db2diag.log e o log 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:
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 (High Availability Disaster Recovery) não suporta a utilização de E/S brutas (acesso direto ao disco) para arquivos de log 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 logs brutos, o comando associado falhará com o código de razão SQL1768N "9".
[ Início da Página |Página Anterior | Próxima Página | Índice ]