Cómo verificar el progreso de la ejecución de BDLS y evitar que se quede 'colgada'

John,

Me gustan las posibilidades de esta publicación y el momento es perfecto. Tengo una actualización de 6TB la próxima semana y es nuestra más lenta para la conversión de BDLS. Hay una nueva transacción BDLSS que consta de dos pasos. El primer paso escanea todas tus tablas que contienen LOGSYS para ver si alguna fila tiene datos en el campo. El segundo paso actualiza solo las tablas relevantes (la parte de actualización real es rápida). Así que bajo este proceso, puedo ver cómo algunos podrían decir que excluir tablas es irrelevante porque la fase de escaneo inicial está identificando las únicas tablas relevantes.

Sin embargo, el escaneo para ver qué tablas necesitan actualización lleva una eternidad si eres como nosotros y tienes millones de filas en algunas tablas. La buena noticia es que puedo tomar los resultados de la última ejecución e identificar muchas de estas tablas monstruosas que no están utilizando su LOGSYS de ninguna manera e intentar excluirlos del paso de escaneo inicial. Eso tiene la posibilidad de ahorrarme mucho tiempo.

Actualmente, mi BDLS se ejecutará durante varios DÍAS si simplemente dejo que escanee todo. Voy a probar tu enfoque en nuestro sistema ECC 6.0 (Basis 7.0 SP19) y ver cuánto puedo reducir mis tiempos. La última vez, se ejecutó durante más de 3 días solo para encontrar 9 tablas que necesitan unas pocas miles de filas actualizadas. Fue una gran pérdida de tiempo.

Gracias,

Richard

Georgia-Pacific

Si este hilo sigue activo ... tengo un poco de información para agregar, así como una pregunta para el grupo.

Solía utilizar el código BDLSC para excluir varias tablas de la ejecución de BDLS. BDLSC es una transacción simple que actualiza la tabla BDLSEXZ. La única opción que usaba en BDLSC era la opción "Tabla excluida". Ingresábamos tablas que sabíamos que no era necesario actualizar.

¿Cómo sabíamos qué tablas no necesitaban actualización? ... observábamos BDLS en SM50 - esperábamos a que se 'colgara' durante mucho tiempo en una tabla. Luego verificábamos esa tabla a través de SE16 - contábamos el número de registros donde LOGSYS (o AWSYS, etc.) no estaba vacío. Si no se devolvían registros, no había nada que actualizar en BDLS. Cancelábamos el trabajo, añadíamos la tabla a la lista de exclusión a través de BDLSC y comenzábamos de nuevo. Con el tiempo, agregamos las tablas conocidas a BDLSC en el sistema de producción, dejamos que se copiaran de vuelta a Q durante la actualización y estábamos listos para continuar.

La otra forma en que aceleramos las cosas fue a través de un programa ABAP personalizado que realizaba actualizaciones directas en algunas tablas grandes donde realmente necesitábamos actualizar LOGSYS. Estoy seguro de que habrá personas que lo consideren un gran error. Está bien - lo entiendo... pero supongo que hay muchos clientes de SAP que han hecho esto.

Mi pregunta aquí se refiere al uso de BDLSC. Me han dicho que no es necesario. Que BDLS solo dedicará tiempo a actualizar tablas que tengan datos en LOGSYS. Si todas las entradas están vacías, omitirá la tabla. Intentaré verificar en el código, pero ¿alguien puede comentar si esto es cierto?

gracias,

-john

Hola,

1. Ejecuta el informe RBDLSMAP_RESET para limpiar ejecuciones antiguas o atascadas de BDLS.

2. Crea el índice temporal para las tablas identificadas como enormes y que contienen los campos (AWSYS, LOGSYS, SNDSYSTEM, RCVSYSTEM, etc.) - esto se puede identificar si realizas una ejecución de prueba o escribes un fragmento de código para identificar dichas tablas.

3. Después de que se creen los índices - ejecuta el informe RBDLS2LS (a través de SE38).

4. Aparece la pantalla normal de BDLS - aquí, ingresa el rango de tablas.

5. Después de ejecutar el informe RBDLS2LS por primera vez en el sistema, creará un nuevo informe RBDLS<client.no.>.

6. Ahora, utiliza el informe RBDLS<client No> para programar el BDLS más adelante (esto permite ejecuciones en paralelo también).

Estamos probando esto ahora y ha tenido una mejora significativa en el tiempo de ejecución de BDLS. Este enfoque es imprescindible para sistemas de tamaño TB.