Recuperación de datos y alta disponibilidad

Visión general de la copia de seguridad

Tenga en cuenta las restricciones siguientes:

• Se puede iniciar una operación de copia de seguridad en línea de un espacio de tabla DMS mientras se realiza una reorganización en línea de una tabla que reside dentro del mismo espacio de tabla. Se pueden producir esperas de bloqueo en la operación de reorganización durante la fase de truncamiento.
• No se puede iniciar una operación de copia de seguridad en línea de un espacio de tabla SMS mientras se realiza una reorganización en línea de una tabla que reside dentro del mismo espacio de tabla. Ambas operaciones necesitan un bloqueo exclusivo.

Utilización de la copia de seguridad

Son aplicables las restricciones siguientes al programa de utilidad de copia de seguridad:

• No se puede ejecutar al mismo tiempo una operación de copia de seguridad de un espacio de tabla y una operación de restauración de una espacio de tabla, aunque en las operaciones intervengan espacios de tabla diferentes.
• Si desea poder realizar una recuperación ascendente en un entorno de base de datos particionada, debe hacer una copia de seguridad periódica de la base de datos para la lista de nodos, y debe tener como mínimo una imagen de copia de seguridad de los demás nodos del sistema (incluso de aquellos que no contengan datos de usuario para esa base de datos). En los dos casos siguientes es necesario tener una imagen de copia de seguridad de una partición de base de datos en un servidor de partición de base de datos que no contiene datos de usuario para la base de datos:
  • Ha añadido un servidor de partición de base de datos al sistema de base de datos después de realizar la última copia de seguridad, y necesita realizar una recuperación ascendente en este servidor de partición de base de datos.
  • Se está utilizando la recuperación de punto en el tiempo, la cual necesita que todas las particiones de base de datos del sistema estén en el estado de actualización ascendente pendiente.
  • La operación de copia de seguridad en línea de un espacio de tabla DMS es incompatible con las operaciones siguientes:
    • cargar (load)
    • Reorganización (fuera de línea solamente); (se puede realizar una reorganización en línea de una tabla que reside en el espacio de tabla del que se está haciendo una copia de seguridad, pero se pueden producir esperas de bloqueo durante la fase de truncamiento de la operación de reorganización).
    • descartar espacio de tabla
    • truncamiento de tabla
    • creación de índice
    • Not Logged Initially (utilizado con las sentencias CREATE TABLE y ALTER TABLE)

Visión general sobre la recuperación de catástrofes de alta disponibilidad

Cuando se ejecutan los mandatos START HADR, STOP HADR o TAKEOVER HADR, se pueden generar los correspondientes códigos de error: SQL01767N, SQL01769N o SQL01770N con el código de razón 98. El código de razón indica que no hay instalada ninguna licencia para HADR en el servidor en el que se ha ejecutado el mandato. Para corregir el problema, instale una licencia de HADR válida utilizando db2licm o instale una versión del servidor que contenga una licencia de HADR válida como parte de su distribución.

Soporte de copia de seguridad y restauración en varias plataformas

DB2 Universal Database (UDB) da soporte a las operaciones de copia de seguridad y restauración en varias plataformas.

Puede restaurar bases de datos creadas en una plataforma DB2 UDB Versión 8 de 32 bits de Windows a una plataforma DB2 UDB Versión 8 de 64 bits de Windows, o viceversa.

Puede restaurar bases de datos creadas en una plataforma DB2 UDB Versión 8 de 32 bits Linux x86 en una plataforma DB2 UDB Versión 8 de 64 bits Linux x86-64 o IA64 o viceversa.

Puede restaurar bases de datos creadas en las plataformas AIX, HP-UX, Linux PPC, Linux zSeries o Entorno operativo Solaris de DB2 UDB Versión 8 , de 32 ó 64 bits, en plataformas AIX, HP-UX, Linux PPC, Linux zSeries o Entorno operativo Solaris de DB2 UDB Versión 8 (32 bits o 64 bits).

Copia de seguridad en cinta (Linux)

El límite máximo del tamaño de bloque para los dispositivos de cintas 3480 y 3490 en Linux es de 61.440 bytes

Tivoli Storage Manager

Cuando llame a los mandatos BACKUP DATABASE o RESTORE DATABASE, puede especificar que desea utilizar el producto Tivoli Storage Manager (TSM) parra gestionar la operación de copia de seguridad o restauración de base de datos o de espacio de tabla. El nivel mínimo necesario de la API cliente de TSM es la Versión 4.2.0, excepto en:

• Sistemas Solaris de 64 bits, que necesitan la API cliente de TSM Versión 4.2.1.
• Sistemas operativos Windows NT de 64 bits, que necesitan la API cliente de TSM Versión 5.1.
• Linux para iSeries y pSeries de 32 bits, que necesita como mínimo la API cliente de TSM Versión 5.1.5
• Linux para iSeries y pSeries de 64 bits, que necesita como mínimo la API cliente de TSM Versión 5.3
• Linux de 64 bits en sistemas AMD Opteron, que necesita como mínimo la API cliente de TSM Versión 5.2.0.
• Linux para zSeries de 64 bits, que necesita como mínimo la API cliente de TSM Versión 5.2.2.

Restricciones de valores para los parámetros de servicio local y de sistema principal local HADR

Cuando se especifican valores para los parámetros de servicio local y de sistema principal local de recuperación de catástrofes de alta disponibilidad (HADR) (HADR_LOCAL_SVC y HADR_REMOTE_SVC) al preparar un mandato update database configuration, los valores deben ser puertos que no esté utilizando ningún otro servicio. Si los parámetros se configuran mediante la línea de mandatos de Linux o UNIX, los valores también se deben establecer en el archivo /etc/services.

Requisitos adicionales del sistema para la recuperación de catástrofes de alta disponibilidad

Si crea un espacio de tabla en la base de datos principal y la respuesta de anotación falla en la base de datos en espera porque los contenedores no están disponibles, la base de datos principal no recibe ningún mensaje de error que indique que la respuesta de anotación ha fallado.

Para comprobar si hay errores de respuesta de anotación, debe supervisar el archivo db2diag.log y las anotaciones cronológicas de administración en la base de datos en espera cuando esté creando nuevos espacios de tabla.

Si se produce una operación de toma de control, el nuevo espacio de tabla que ha creado no está disponible en la nueva base de datos principal. Para recuperarse de esta situación, restaure el espacio de tabla en la nueva base de datos principal a partir de la imagen de copia de seguridad.

En el siguiente ejemplo, el espacio de tabla MY_TABLESPACE se restaura en la base de datos MY_DATABASE antes de que se utilice como nueva base de datos principal:

1. db2 connect to my_database
2. db2 list tablespaces show detail
   Nota:
   Ejecute el mandato db2 list tablespaces show detail para mostrar el estado de todos los espacios de tabla y para obtener el número de ID de espacio de tabla necesario para el Paso 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

Operaciones no duplicadas para la recuperación de catástrofes de alta disponibilidad

La documentación de la Versión 8.2 indica:

Los BLOB y CLOB no se duplican; sin embargo, el espacio correspondiente a los mismos se asignará en la base de datos en espera.

La frase debe ser la siguiente:

Los BLOB y CLOB no anotados no se duplican; sin embargo, el espacio correspondiente a los mismos se asignará en la base de datos en espera.

HADR no da soporte a anotaciones en bruto

La recuperación de catástrofes de alta disponibilidad (HADR) no da soporte al uso de E/S en bruto (acceso directo a disco) para archivos de anotaciones cronológicas de bases de datos. Si HADR se inicia con el mandato START HADR, o si la base de datos se reinicia con HADR configurado, y se detectan anotaciones cronológicas en bruto, el mandato asociado fallará con el código de razón de SQL1768N "9".

Comparación del supervisor de errores y del supervisor de salud

El supervisor de salud y el supervisor de errores son herramientas que trabajan |sobre una instancia. El monitor de salud utiliza los indicadores |de salud para evaluar la salud de los aspectos específicos del rendimiento del |gestor de bases de datos o el rendimiento de la base de datos. Un indicador |de salud mide la salud o estado de alguno de los aspectos de una clase específica |de objetos de base de datos, tal como un espacio de tabla. Los indicadores de salud pueden ser evaluados contra criterios específicos para |determinar la salud de dicha clase de objeto de base de datos. Adicionalmente, los indicadores de salud pueden generar alertas para notificarle |cuando un indicador excede un umbral o indica que un objeto de base de datos |está en un estado no normal.

Por comparación, el supervisor de salud sólo es responsable de conservar la instancia |que se está supervisando y ejecutando. Si la instancia de DB2 UDB que se supervisa termina de manera inesperada, el supervisor de errores |reinicia la instancia. El supervisor de errores no está disponible en Windows.

Desactivación de la supervisión de errores

Para desactivar la supervisión de errores para la instancia de base de datos DB2INST1, escriba |el mandato siguiente desde la ventana de mandatos de DB2 UDB:

   db2fm -i db2inst1 -f no

Para confirmar que el supervisor de errores ya no se ejecuta para DB2INST1, escriba el mandato |siguiente en sistemas UNIX:

   ps -ef|grep -i fm

En sistemas Linux, escriba el mandato siguiente:

   ps auxw|grep -i fm

Una entrada que muestra db2fmd y DB2INST1 indica que el supervisor de errores |todavía se ejecuta en dicha instancia. Para desactivar el supervisor de errores, escriba el mandato siguiente |como el propietario de la instancia:

   db2fm -i db2inst1 -D