Ajuste del rendimiento para el procesamiento paralelo

	Ajuste del rendimiento para el procesamiento paralelo En este apéndice se describe el ajuste del rendimiento que puede ser necesario para ejecutar la sesión Proceso CI (tccri7203m000) mediante el procesamiento paralelo. El rendimiento real de Proceso CI (tccri7203m000) depende de una serie de factores, incluido el número de CPU disponibles, así como la configuración de los servidores de aplicación y de base de datos. La cantidad de datos incluidos en las tablas es otro factor importante. Por lo general, las tablas siguientes contienen grandes cantidades de datos: Transacciones de integración (tfgld482) Datos de conciliación (tfgld495) Transacciones finalizadas (tfgld106) Transacciones de OEC y movimientos de stock (SFC) (ticst300) Transacciones de OEC y movimientos de stock de PCS (tipcs300) Historia de órdenes de venta (tdsls450, tdsls451 y tdsls456) En Infor LN FP5 y versiones posteriores, hay una característica disponible para actualizar las tablas directamente mediante RDBMS. Esta característica está implementada en porting set 8.7a.03 y posteriores. Las actualizaciones directamente mediante RDBMS son más eficientes que las actualizaciones a través del bshell. La diferencia es que toda la transacción se transfiere a RDBMS. Este tipo de actualización se limita a tablas o datos para los que no es necesario recalcular los importes propios ni los tipos de cambio. Esto puede ocurrir si, por ejemplo, los importes propios de una divisa de listado se convierten en los importes en la divisa local. Otro ejemplo puede ser la eliminación de los importes propios. Esto puede ocurrir si las divisas de listado se borran o, en las tablas logísticas, si el sistema de divisas cambia a un sistema de divisas estándar. La sesión Proceso CI (tccri7203m000) comprobará si se pueden aplicar actualizaciones directamente mediante RDBMS. La sesión utilizará las actualizaciones convencionales (más lentas) si no está permitida la actualización directa mediante RDBMS. Las siguientes condiciones determinan si se pueden utilizar actualizaciones de RBDMS: En la sesión Tarifas CI (tccri7100m000), el valor del campo Expresar en divisa base debe coincidir con el del campo correspondiente en la sesión Tipos de cambio de divisas (tcmcs0108m000). Por ejemplo, en las compañías de EURO los tipos de cambio de EUR (local) a divisas transaccionales pueden seguir igual si lo expresado en la divisa base no cambia durante la conversión. Nota: Esto se aplica a todos los tipos de tarifas de cada divisa base en la sesión Tipos de cambio de divisa. Limitaciones técnicas Se aplican estas restricciones: El controlador de la base de datos debe ser un controlador de nivel 2. Las siguientes tablas se auditan, no se replican: tfgld495, tfgld482, tdsls451 y tdsls456 Se debe utilizar la versión 8.7a.03 o posterior del porting set. El nivel de TIV del porting set debe ser 1744 o posterior. Para comprobar este número, ejecute $BSE/bin/bshell6.2 –V en la línea de comandos (en Windows, utilice %BSE\bin\ntbshell –V) Si el proceso de inicialización de la divisa empieza en la sesión Proceso CI (tccri7203m000), esta sesión accederá al grupo de conversión y a las compañías pertinentes y determinará el tipo de conversión necesaria. Si se pueden aplicar actualizaciones directamente a través del RDBMS, se generarán algunos datos en las Tablas de conversión CI por compañías de grupo (tccri725) y los Grupos de actualización de tablas de conversión del grupo CI (tccri726). Nota Los grupos de actualización de tablas de conversión del grupo CI (tccri726) sólo se generan para las entradas Transacción de integración (tfgld482) de la sesión Tablas de conversión CI por compañías de grupo (tccri7125m000). En la sesión Tablas de conversión CI por compañías de grupo (tccri7125m000), se seleccionará el campo Actualizaciones masivas si Proceso CI (tccri7203m000) actualiza directamente una tabla mediante las actualizaciones de RDBMS. La tabla Transacciones de integración (tfgld482) puede contener transacciones que pertenecen a varias compañías contables. Las transacciones de integración que se pueden gestionar con actualizaciones directamente mediante RDBMS se agruparán en grupos de actualización. Las transacciones de un grupo de actualización se pueden convertir a una actualización de RDBMS. Si Transacciones de integración (tfgld482) también se debe convertir sin actualizaciones directamente mediante RDBMS, la conversión aún se puede dividir. De esta forma, la actualización convencional de la tabla se procesará mediante procesos paralelos. Los datos de conciliación (tfgld495) se deben dividir sólo si no se pueden aplicar actualizaciones directamente mediante RDBMS. Esto ocurre si, por ejemplo, es necesario recalcular los importes propios o de los tipos de cambio. Nota Si se divide la conversión de Datos de conciliación (tfgld495), la tabla no se actualizará con las actualizaciones directas mediante RDBMS. La tabla Transacciones finalizadas (tfgld106) se puede convertir mediante procesos paralelos. No se admiten las actualizaciones directas mediante RDBMS. Ejemplo de ajuste Este ejemplo se aplica a las tareas de conversión que se gestionan sin actualizaciones directas mediante RDBMS, y que se pueden dividir en Tablas de conversión CI por compañías de grupo (tccri7125m000). Una conversión interna con procesamiento paralelo puede implicar conversiones con o sin actualizaciones directas mediante RDBMS, según la configuración de divisa de cada compañía. Supongamos que los datos de tres compañías se deben convertir mediante nueve bshells paralelos. En la imagen se muestra este caso con distintos colores para las tres compañías. La tabla convertida en la tarea 1.1 es muy grande. Al mismo tiempo, también hay otras tres tablas grandes convertidas (2.1, 2.2 y 3.1). Si la tarea de conversión grande, la 1.1, se puede dividir, puede decidir que haya seis bshells procesando la tarea 1.1, mientras que tres bshells procesarán las tareas 2.1, 2.2 y 3.1. Después de dividir la tarea 1.1, las tareas más pequeñas (de color lila) quedarán apartadas por las seis tareas más grandes que procesan la tarea 1.1. El mismo enfoque se puede utilizar si, por ejemplo, se puede dividir la conversión de las tablas 2.3 y 2.4. Si la tabla 2.3 es procesada por dos bshells en paralelo y la tabla 2.4 es procesada por tres bshells en paralelo, aún quedará suficiente capacidad para que los bshells paralelos restantes procesen las tareas más pequeñas (de color verde) al mismo tiempo. Después de dividir las tareas, la carga de los procesos paralelos quedará más equilibrada. El tiempo total transcurrido se reduce de 28 a 17 unidades de tiempo. Proceso CI (tccri7203m000): conversión de prueba frente a conversión real En el modo de simulación, se probarán las transacciones de la base de datos de las actualizaciones realizadas directamente mediante RDBMS. Este tipo de actualizaciones se pueden utilizar en la conversión de Datos de conciliación (tfgld495), Transacciones de integración (tfgld482), Historia de líneas de orden de venta (tdsls451) e Historia de líneas de entrega reales de orden venta (tdsls456). Las transacciones se revertirán en el modo de prueba. Esto puede tardar mucho más tiempo que la transacción real en una conversión real. En la lógica de conversión convencional, la actualización de los datos de la tabla no se lleva a cabo durante la conversión de prueba. Tenga en cuenta que, si bien estas tablas se procesarán en menos tiempo durante la conversión de prueba, su procesamiento en la conversión real llevará más tiempo. Importante Durante la inicialización de la divisa, no debe haber ningún otro usuario o proceso activo en las compañías del grupo de conversión, incluso aunque se utilice la sesión Proceso CI (tccri7203m000) para llevar a cabo una conversión de prueba. Para evitar problemas de bloqueo de tablas o de lectura de transacciones sin confirmar, tenga en cuenta lo siguiente: Las actualizaciones directas mediante RDBMS serán transacciones grandes que se prueban, pero no se asignan durante la conversión de prueba. Esto podría provocar bloqueos de tablas en Datos de conciliación (tfgld495), Transacciones de integración (tfgld482), Historia de líneas de órdenes de venta (tdsls451) e Historia de líneas de entrega reales de orden venta (tdsls456). SQL Server: De forma predeterminada, el controlador de la base de datos utiliza el nivel de aislamiento "Read uncommitted" para evitar bloqueos compartidos, y el bloqueo exclusivo para actualizar y borrar acciones. Como resultado, durante la conversión (de prueba), otros usuarios o procesos podrían leer transacciones no confirmadas en Datos de conciliación (tfgld495), Transacciones de integración (tfgld482), Historia de líneas de órdenes de venta (tdsls451) e Historia de líneas de entrega reales de orden venta (tdsls456). Para obtener más información, consulte Infor Enterprise Server Technical Reference Guide for SQL Server Database Driver (U8173 US). Configuración de Oracle Las actualizaciones directas mediante RDBMS serán transacciones grandes. Como consecuencia, se necesitará una gran cantidad de espacio de tabla Undo. LN se prueba con un espacio de tabla Undo de 32 GB. Recomendamos que configure el espacio de tabla Undo para ampliar los archivos de datos automáticamente con, por ejemplo, 8 GB cada vez. Esto evitará que se produzcan los errores ORA-1555 (Snapshot too old). Recuerde el tamaño máximo del archivo de datos. No es fácil prever si el tamaño del espacio de tabla Undo será suficiente. Se recomienda que busque los errores ORA-1555 en los registros del visor de eventos de LN cuando se esté ejecutando Proceso CI (tccri7203m000). En general, para que las consultas se realicen correctamente, la base de datos de Oracle se debe ajustar de la forma adecuada. LN se probó con la siguiente configuración aplicada al entorno de LN mediante el archivo $BSE/lib/default/db_resource: `ora_init:0101000` `ora_max_array_fetch:100` `ora_max_array_insert:100` `ora_alter_session`: set " `_optim_peek_user_binds` "= `false` Debería fusionar las líneas anteriores con el recurso de base de datos basado en lotes para la conversión. En algunas implementaciones, se aplican valores no predeterminados a los parámetros de Oracle ocultos (los denominados parámetros Underscore). Esta configuración podría afectar a los planes de ejecución de las consultas. Debería restablecer sus valores predeterminados. Para ello, puede añadirlos a la propiedad `ora_alter_session` del archivo $BSE//lib/defaults/db_resource. Configuración de SQL Server Debería cambiar el registro en la base de datos de LN durante la inicialización de divisas a Simple y crear una copia de seguridad completa tras finalizar la inicialización de las divisas. Configure el archivo $BSE/lib/default/db_resource para habilitar la recuperación de matriz y entonces establezca el tamaño de recuperación en 100. Configuración de DB2 Configure el archivo $BSE/lib/default/db_resource para habilitar la recuperación de matriz y entonces establezca el tamaño de recuperación en 100.