Modelos de recuperación para DB2

Los tipos de recuperación que pueden utilizar con geodatabases en DB2 son recuperación de versión, que utiliza un registro circular; recuperación de puesta al día, que utiliza un registro de archivos; o recuperación de desastres de alta disponibilidad (HADR).

Nota:

Asegúrese de recuperar todas las bases de datos que componen la geodatabase de ArcSDE cuando restaure una geodatabase de ArcSDE en DB2 para z/OS.

• Recuperación de versión y registro circular

  El registro circular utiliza un anillo de archivos de registro para grabar los cambios a la base de datos. Cuando se completa el último registro en el anillo, se vuelve a utilizar el primer archivo. Debido a que la información de transacción se puede sobrescribir, cuando utiliza el registro circular, no es posible la recuperación de puesta al día; sin embargo, generalmente no se necesita la recuperación durante las cargas de datos. El registro circular es el modelo de registro predeterminado.

• Recuperación de puesta al día y registro de archivos

  Si desea utilizar la recuperación de puesta al día, el método de recuperación recomendado para utilizar con geodatabases de ArcSDE, utilice el registro de archivos. El registro de archivos no sobrescribe los archivos de registro; en su lugar, crea registros adicionales para grabar todas las transacciones desde la última copia de seguridad. Para utilizar registro de archivos necesita más espacio en disco, ya que los registros no se vuelven a utilizar como en el registro circular.

• HADR

  La recuperación de desastres de alta disponibilidad es una funcionalidad de replicación de la base de datos disponible en DB2 que protege los datos mediante la replicación de los cambios en los datos de una base de datos de origen (principal) a una base de datos de destino (base de datos en espera). Si la base de datos principal se desconecta, puede cambiar a la base de datos en espera mientras recupera la base de datos principal.

  Puede especificar uno de tres modos de sincronización para la HADR: sincrónico, casi sincrónico o asíncrono.

  En el modo sincrónico, un cambio que se realiza a la base de datos principal no se confirma en dicha base de datos hasta que los registros asociados se escriben en los registros de la transacción de la base de datos en espera. Esto mantiene ambas bases de datos sincronizadas ya que en la base de datos principal no entra ningún cambio que no se haya guardado en un archivo de registro (y por lo tanto es recuperable) en la base de datos en espera. Este modo tiene el mayor impacto en el rendimiento de la base de datos principal.

  En el modo casi sincrónico, un cambio que se realiza en la base de datos principal no se confirma en dicha base de datos hasta que los registros asociados se escriben en la memoria de la base de datos en espera. Esto es casi tan eficaz como el modo sincrónico y tiene menos impacto en la base de datos principal. Sin embargo, si la base de datos en espera falla después de que se confirman los datos en la base de datos principal, los datos transferidos se pueden perder y ambas bases de datos pueden quedar incoherentes.

  Los COMMIT de la transacción de la base de datos en la base de datos principal no están afectados por la comunicación de los registros en la base de datos en espera. En este modo, existe más de una posibilidad de que los datos entre las dos bases de datos se vuelvan incoherentes. Existen otras opciones de replicación que se pueden utilizar con DB2, incluida la replicación de SQL y la replicación Q. Consulte la documentación de DB2 para obtener más información.

Para restaurar su geodatabase, puede utilizar el comando RECOVER DATABASE o el asistente Restore Data desde el Centro de control de DB2. La geodatabase se puede restaurar en una base de datos existente o nueva. Las siguientes son notas sobre la recuperación en una nueva base de datos.

• Si realiza la recuperación en una nueva base de datos, debe estar conectado a la instancia.
• Si realiza la recuperación en una nueva base de datos en otro servidor y los servidores de origen y de destino no utilizan la página de código predeterminada, debe crear la base de datos en el equipo de destino con la página de código correcto antes de realizar la restauración. Si no lo hace y la página de código de producción es diferente a la de origen, la utilidad de restauración asume la página de código predeterminada. Esto da como resultado un error SQL2548N.
• Cuando realiza la recuperación en una nueva base de datos, el archivo de historial de recuperación de la imagen de copia de seguridad se transforma en el nuevo archivo de historial de recuperación de la nueva base de datos.

Cuando realiza una recuperación de base de datos completa de una base de datos recuperable, no puede haber otras conexiones en la base de datos diferentes a la conexión que se realiza cuando se recupera la base de datos. Cuando se restaura una copia de seguridad completa de base de datos, DB2 verifica que todos los espacios de tabla a los que se hace referencia en la imagen de copia de seguridad estén en la base de datos a la cual se restauran los datos. (Puede ser una base de datos existente o una base de datos nueva y vacía). Si falta o no se puede acceder a un espacio de tabla, ocurre un error en la operación de recuperación.

Para evitar esto, puede realizar una operación de restauración redireccionada. Esto permite especificar nuevos espacios de tabla a los que pueda restaurar los espacios de tabla desde la imagen de copia de seguridad, que faltaban de la base de datos de destino. Para obtener detalles sobre cómo realizar una restauración redireccionada, consulte la documentación de DB2.

Si sólo restaura espacios de tabla individuales de una base de datos recuperable, la base de datos puede permanecer online mientras que no haya usuarios conectados a los espacios de tabla que intenta restaurar.

Sugerencia

• Puede automatizar el archivado y la recuperación de archivos de registro con un programa exit de usuario. Para utilizarlo, debe establecer el parámetro de configuración logarchmeth1 en USEREXIT.

  Para obtener detalles sobre cómo desarrollar y utilizar un programa exit de usuario, consulte la documentación de DB2.

• Si la base de datos tiene una partición, debe ejecutar el comando RECOVER DATABASE desde la partición del catálogo. Cuando recupera una base de datos particionada en un punto específico en el tiempo, se ven afectadas todas las particiones del archivo db2nodes.cfg. Cuando recupera hasta el final de los registros, puede especificar qué particiones se ven afectadas por la recuperación. Si no designa particiones específicas, se ven afectadas todas las particiones en el archivo db2nodes.cfg.