Traducción el artículo original de Ron Schmerbauch
"SAP on IBM i and Power IBM Rochester Development Lab"
El artículo original hace referencia a SAP, aunque la información aplica cualquier archivo físico de datos o tabla
En artículos de boletines anteriores, hemos hablado sobre cómo las tablas de SAP pueden acercarse a las limitaciones de tamaño y lo que puede hacer para resolver esas situaciones. Puede aumentar la capacidad de una tabla particionándola. O puede reducir el tamaño de una tabla a través del archivado, seguido de la reorganización de la tabla. Sin embargo, la partición o reorganización de una o más tablas grandes puede requerir un largo tiempo de inactividad que su negocio no puede ser capaz de tolerar. Si hubiera una manera de realizar esas operaciones reduciendo el tiempo de inactividad, ¿le interesaría?
Antes de discutir cómo es posible, veamos por qué se necesita un largo tiempo de inactividad. Las operaciones de partición y de reorganización requieren realizar cambios significativos en una tabla, impidiendo cualquier otro acceso mientras se realizan los cambios. Por lo tanto, la aplicación SAP debe detenerse cuando realiza este tipo de operaciones. Una vez que se detiene SAP, DB2 puede obtener un bloqueo exclusivo en la tabla. Una vez que la tabla está bloqueada, DB2 puede hacer lo que sea necesario sabiendo que nadie más puede acceder a la tabla. Conceptualmente, DB2 realiza tanto el particionamiento de tablas como las reorganizaciones fuera de línea básicamente de la misma manera. Al particionar una tabla, DB2 copia los datos fila por fila de la tabla original hacia las nuevas particiones. Cuando se reorganiza una tabla utilizando la opción ALWCANCEL(*NO) de RGZPFM, DB2 copia los datos fila por fila en una nueva tabla. Ambos tipos de operaciones son más complicados que eso, pero "hacer una copia" es una forma de pensar en ello. Cualquiera de las operaciones podría llevar horas o incluso días. Cuando finaliza la operación de partición o reorganización, DB2 libera el bloqueo exclusivo. En ese momento, la tabla finalmente está disponible para su uso y la aplicación SAP se puede iniciar nuevamente. Ahora podemos discutir una mejor opción.
La opción MDRapid de Midrange Dynamics proporciona una manera elegante de realizar estas operaciones en segundo plano en una nueva versión de la tabla mientras su aplicación SAP sigue usando la tabla original. Para evitar la necesidad de un bloqueo exclusivo en la tabla original, MDRapid aprovecha el hecho de que todos los cambios de la aplicación realizados en las tablas de SAP son registrados por diario en objetos receptores de diario del IBM i. Al iniciar una operación de partición o reorganización, MDRapid toma nota de la entrada actual en el receptor de diario. Una vez lista la partición o reorganización en la nueva versión de la tabla, MDRapid actualiza la nueva versión con la original aplicando las entradas de diario que se han registrado en el interín. Mejor aún, MDRapid mantendrá la nueva versión actualizada hasta que Ud. encuentre el momento conveniente para detener la aplicación SAP y otorgue permiso a MDRapid para reemplazar la tabla original con la tabla recién particionada o reorganizada. MDRapid también restablecerá automáticamente los índices y las vistas que estaban en la tabla original. Cuando se reemplaza la tabla original, MDRapid mueve la tabla original a otra biblioteca. Esto le permite eliminar la tabla original una vez que esté seguro de que la nueva tabla funciona como se esperaba. Si bien todavía necesita detener SAP para cambiar la tabla original por la nueva tabla, esto solo debería tomar minutos en lugar de horas porque la mayo parte del trabajo se hizo mientras SAP estaba en ejecución. Esta dramática diferencia de tiempo de inactividad se muestra en el gráfico.
Cuando el equipo de SAP en IBM i vio el potencial de usar MDRapid en estas situaciones, nos entusiasmó mucho probarlo. Lo probé primero aquí en Rochester, y luego el equipo de IBM i en SAP en Alemania realizó pruebas adicionales. En una serie de pruebas, primero ejecutamos la carga de trabajo de SAP Sales and Distribution (SD) con una utilización constante de la CPU de aproximadamente el 70 % para establecer una línea base. A continuación, ejecutamos la misma carga de trabajo SD mientras que el kit de herramientas MDRapid particionó las tablas VBFA y FAGLFLEXA. Obtuvimos los mejores resultados cuando ejecutamos los procesos de MDRapid por sí solos en un espacio relativamente pequeño (500 MB) del almacenamiento principal. Como era de esperar, los procesos que realizan el trabajo de MDRapid agregaron algo de uso de CPU (+15 %) y E/S de disco al sistema. Sin embargo, no notamos cambios medibles en los tiempos promedio de respuesta durante la carga de trabajo de SD tanto si MDRapid se estaba ejecutando como si no. En términos más simples, aunque la utilización de la CPU y la E/S del disco pueden aumente un poco, es posible que sus usuarios no noten ningún impacto en el rendimiento mientras MDRapid está funcionando. Dado que esto es solo una pequeña muestra, sus resultados pueden variar según los recursos de hardware disponibles, los tamaños de las tablas y otros factores, por lo que es mejor consultar un especialista de MDRapid y comprobar si esta herramienta es beneficiosa para su entorno.
Al particionar o reorganizar tablas grandes, ya sea con el método tradicional o con MDRapid, asegúrese de tener suficiente almacenamiento disponible para mantener una copia completa de la tabla o tablas en las que está trabajando, y para los receptores de diario durante la duración de la operación.
La mayoría de los clientes de SAP en IBM i han estado ejecutando sus sistemas durante muchos años. A medida que pasa el tiempo y se agregan datos, la probabilidad de que una de sus tablas grandes deba particionarse o reorganizarse sigue aumentando. El sistema IBM i le advertirá a través de la cola de mensajes QSYSOPR cuando uno de estos límites se acerque, pero ahora hay una manera fácil de manejar estas situaciones con una interrupción mínima para su negocio.
