Dump y Load entre Plataformas en Adaptive Server Enterprise

Dump y Load entre Plataformas en Adaptive Server Enterprise

Tabla de Contenido

• Introducción
• Alcance del Documento
• Resumen de Compatibilidad
• Usando Dump y Load entre Plataformas Diferentes
• Alistando la Base de Datos
• Restricciones
• Afinamiento y Solución a Problemas
• Conclusión

Introducción

Sybase Adaptive Server Enterprise (ASE) versión 12.5.3 introdujo capacidades mejoradas de creación y cargue de copias de respaldo que responden a restricciones previas que existían al mover bases de datos entre diferentes plataformas o al restaurar copias de respaldo de un servidor ASE corriendo sobre una plataforma, a un servidor ASE sobre una plataforma diferente. Previamente, restaurar una copia de respaldo de una base de datos sobre un servidor ASE ejecutándose bajo una plataforma con arquitectura diferente, no estaba soportado, y para transferir la base de datos se requería el uso de otros utilitarios y comandos como bcp y sybmigrate. Estas herramientas son todavía útiles, pero en muchos casos son menos eficaces que la creación y cargue de copias de respaldo.

Ahora es posible restaurar bases de datos entre diferentes combinaciones de plataformas soportadas por ASE, tales como entre Unix y Linux y entre arquitecturas de 32 y 64 bits, o entre otras plataformas con diferente arquitectura de almacenamiento de bytes incluyendo compatibilidad con copias de respaldo creadas con ASE 11.9 y versiones posteriores. Esta flexibilidad mejorada hace mucho más simple administrar las bases de datos y manejar la migración de bases de datos entre diferentes plataformas. El propósito de éste documento es describir la nueva compatibilidad entre plataformas, explicar cómo usar la creación y cargue de copias de respaldo entre plataformas, identificar algunas restricciones y brindar algunas recomendaciones de afinamiento y solución de problemas.

Alcance del Documento

El Backup Server de Sybase es utilizado para todas las operaciones de creación y cargue de copias de respaldo. El alcance de éste documento está limitado al uso de las nuevas capacidades de creación y cargue de copias de respaldo de bases de datos entre diferentes plataformas. Los utilitarios bcp y sybmigrate son frecuentemente utilizados para extraer datos de usuario y del sistema. En algunos casos, se usan como camino alterno al momento de resolver problemas de incompatibilidad enteplataformas. Las nuevas capacidades de creación y cargue de copias de respaldo pueden brindar un método más simple y rápido de transferir grandes cantidades de datos, pero las estrategias de respaldo y migración están más allá de éste documento.

Resumen de Compatibilidad

Las nuevas características soportan creación y cargue de copias de respaldo entre plataformas con diferentes arquitecturas de almacenamiento de bytes (arquitecturas endian). Con ésta versión, es ahora rápido y fácil restaurar una base de datos creada:

• En ASE 11.9.x y versiones posteriores
• Bajo cualquier sistema operativo soportado (Unix, Linux, Windows, MacOS)
• Bajo cualquier arquitectura de plataforma soportada (32-bit, 64-bit, Big endian, Little endian)

Aunque que la mayor parte de los usuarios están interesados en migraciones específicas, por ejemplo de Unix a Linux, o de 32 a 64 bits, la conversión entre plataformas puede ser usada entre cualquiera de las combinaciones mencionadas arriba.

Usando Dump y Load entre Plataformas Diferentes

No hay cambios a la funcionalidad de DUMP DATABASE. Esto permite que las copias de respaldo existentes sean procesadas para la conversión entre plataformas y también elimina cualquier necesidad de actualizar o hacer cambios al servidor ASE de origen. Las versiones soportadas de archivos de respaldo van desde la 11.9.x en adelante (11.9.x, 12.0.x y 12.5.x).

La base de datos origen debe estar transaccionalmente "quieta" antes de ejecutar el comando DUMP DATABASE; la nueva funcionalidad de cargue entre plataformas verificará los registros del log de transacciones para asegurarse de que éste sea el caso, antes de procesar la copia de respaldo. El procedimiento recomendado es el siguiente:

1. Ponga la base de datos en modo mono usuario (single user mode) usando sp_dboption.
2. Ejecute sp_flushstats y espere a que las páginas sean bajadas a disco.
3. Ejecute CHECKPOINT en la base de datos.
4. Ejecute DUMP DATABASE.

La funcionalidad de conversión entre plataformas fue adicionada internamente al comando LOAD DATABASE del servidor ASE de destino, sin cambios a la sintaxis del comando DUMP DATABASE. Las operaciones de conversión de datos son llevadas a cabo automáticamente cuando el comando LOAD DATABASE es invocado en el servidor ASE de destino. Durante la operación de LOAD DATABASE, el orden de almacenamiento de bytes de la copia de respaldo se detecta automáticamente. Si el almacenamiento de bytes del servidor destino difiere, entonces el servidor ASE destino lleva a cabo la conversión al nuevo orden de bytes, en la medida en que la copia de respaldo es procesada. Si se requiere reordenamiento de bytes, generalmente habrá un impacto en el rendimiento al cargar la copia de respaldo. Dependiendo del esquema y los tipos de datos involucrados, éste puede ser de 2 a 3 veces más intensivo que procesar una copia de respaldo con el mismo orden de bytes que el servidor destino.

Salida de LOAD DATABASE:

1> load database pubs2  2> from '/linuxkernel_eng1/terada/test/dump.pubs2.sol32.1253' 3> go Backup Server session id is: 54. Use this value when executing the 'sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server. Backup Server: 6.28.1.1: Dumpfile name 'pubs2042890A14E' section number 1 mounted on disk file '/linuxkernel_eng1/terada/test/dump.pubs2.sol32.1253' Backup Server: 4.58.1.1: Database pubs2: 1384 kilobytes LOADed. Backup Server: 4.58.1.1: Database pubs2: 3078 kilobytes LOADed. Backup Server: 4.58.1.1: Database pubs2: 3086 kilobytes LOADed. Backup Server: 3.42.1.1: LOAD is complete (database pubs2). Started cross-platform conversion for database pubs2. Started cross-platform conversion for system objects. Cross-platform conversion for database pubs2: 33 pages completed. Completed cross-platform conversion for system objects. Started cross-platform conversion for user objects. Cross-platform conversion for database pubs2: 259 pages completed. Completed cross-platform conversion for user objects. Started cross-platform conversion for log records. Cross-platform conversion for database pubs2: 1 page completed. Completed cross-platform conversion for log records. Completed cross-platform conversion for database pubs2. Started estimating recovery log boundaries for database 'pubs2'. Database 'pubs2', checkpoint=(1150, 19), first=(1150, 19), last=(1150, 19). Completed estimating recovery log boundaries for database 'pubs2'.

Alistando la Base de Datos

Aunque no hay cambios en la sintaxis del comando ONLINE DATABASE, ASE automáticamente ejecutará algunas operaciones adicionales después de haber completado un cargue de copias de respaldo entre plataformas, al invocar el comando ONLINE DATABASE. Después de llevar a cabo el cargue entre plataformas, ASE:

• Trunca el log de transacciones – usando la finalización del cargue como nuevo checkpoint.
• Arregla la columna colidarray de systatistics – regenerándola con el nuevo orden de bytes.
• Verifica y reconstruye los índices de las tablas del sistema, de ser necesario.
• Marca como suspect los índices de las tablas de usuario (excepto los índices clustered de las tablas APL).

Es posible que sea necesario reconstruir los índices de las tablas de usuario después de una conversión que haya involucrado conversión de orden de bytes para re-optimizar la ruta de búsqueda, debido a los cambios en los identificadores de las filas de los índices. Los índices marcados como suspect pueden ser identificados usando el procedimiento almacenado sp_indsuspect. El proceso de re-crear éstos índices para tablas grandes puede ser largo, así que se brindan varias opciones. Los índices del servidor ASE destino pueden ser re-creados manualmente, borrándolos y volviéndolos a crear, o usando un nuevo procedimiento almacenado. El nuevo procedimiento almacenado, sp_post_xpload, verifica los índices de tablas de usuario que hayan sido marcadossuspect y los reconstruye, de ser necesario. Después verifica y reconstruye los siguientes índices:

• Índices non-clustered de tablas APL.
• Índices clustered sobre tablas DOL.
• Índices non-clustered sobre tablas DOL.

Al completarse la ejecución del procedimiento almacenado, se elimina el estado suspect de éstos índices.

Sybase recomienda que la reconstrucción de índices se haga manualmente, borrando y volviendo a crear los índices, para bases de datos más grandes de 10Gb, y usando el procedimiento almacenado para la reconstrucción de índices en bases de datos más pequeñas.

Restricciones

• La base de datos debe estar transaccionalmente "quieta" al ejecutar el comando DUMP DATABASE.
• No se soporta el cargue de copias de respaldo de bases de datos creadas con versiones anteriores a la 11.9.
• No se soporta el cargue de la base de datos master.
• El cargue entre plataformas está sólo disponible para copias de respaldo de bases de datos, no de logs de transacciones.
• El cargue entre plataformas de copias de respaldo protegidas por contraseña no se soporta.
• El cargue entre plataformas usando un Backup Server remoto no se soporta.
• El cargue entre plataformas con objetos XML compilados no se soporta.
• El cargue entre plataformas con estructuras de datos embebidas almacenadas en columnas binary, varbinary o image no se soporta.
• Después de un cargue entre plataformas, todos los procedimientos almacenados y otros objetos compilados son re-compilados a partir de su código fuente, en la primera ejecución. Esto puede ser llevado a cabo proactivamente usando DBCC UPGRADE_OBJECT.

Afinamiento y Solución a Problemas

Para asistir en el diagnóstico y corrección de condiciones que evitan una finalización exitosa de la conversión entre plataformas, los siguientes mensajes de error son nuevos:

Error 3151

Adaptive Server cannot load this database because the database that was dumped was not quiescent when the dump was performed. Run sp_flushstats before DUMP DATABASE and ensure that the database is not updated during the dump.

Arrojado cuando ASE encuentra que la copia de respaldo no es apropiada para el cargue entre plataformas. Se ejecutó una actualización concurrente durante el DUMP DATABASE. Había una transacción abierta al ejecutar DUMP DATABASE. No se ejecutó sp_flushstats antes de ejecutar DUMP DATABASE. No se ejecutó un checkpont antes de ejecutar DUMP DATABASE. La base de datos no estaba en modo mono-usuario al ejecutar DUMP DATABASE.

Errores 3161 y 3162

LOAD DATABASE for database '%.*s' failed during cross-platform conversion: insufficient memory to allocate context structure. LOAD DATABASE for database '%.*s' failed during cross-platform conversion: insufficient memory to allocate translation dictionary.

Arrojados cuando ASE no puede asignar memoria para una estructura de contexto o diccionario de traducción. Se requiere aumentar la memoria asignada al caché de procedimientos (sp_configure 'procedure cache size'). Cálculo aproximado para la memoria requerida en el caché de procedimientos: 2KB (context structure) + 16KB (translation dictionary para tablas del sistema) + 146KB (memoria de trabajo para el diccionario de traducción para tablas del sistema y de usuario) + ((# de tablas de usuario) * 20 bytes) + ((# índices en tablas de usuario) * 8 bytes) + ((# de columnas de tablas de usuario que requieren traducción + # de columnas en las llaves de índices de tablas de usuario que requieren traducción) * 12 bytes) Ejemplo: 10,000 tablas de usuario + 40,000 índices + 400,000 columnas = 164KB + 200KB + 320 KB + 4.8 MB = 5.5MB

Conclusión

Con la introducción de las nuevas capacidades de creación y cargue de copias de respaldo entre plataformas, Sybase ASE significativamente extiende sus capacidades de manejar la transferencia y restauración de bases de datos entre versiones, sistemas operativos y arquitecturas de plataforma. El proceso de creación y cargue de copias de respaldo es generalmente más rápido que otros métodos de transferencia de datos, eliminando restricciones previas existentes que harán más fácil y rápido enfrentar la migración de datos y otras operaciones entre plataformas.

Ahora es posible restaurar bases de datos entre diferentes combinaciones de plataformas soportadas por ASE, tales como entre Unix y Linux y entre arquitecturas de 32 y 64 bits, o entre otras plataformas con diferente arquitectura de almacenamiento de bytes incluyendo compatibilidad con copias de respaldo creadas con ASE 11.9 y versiones posteriores. Esta flexibilidad mejorada hace mucho más simple administrar las bases de datos y manejar la migración de bases de datos entre diferentes plataformas.