#1
|
|||
|
|||
Trasporte en demora, no pasa se queda en cola. Unix/Oracle
Que tal tengo 2 sistemas DEV y PRD acabo de hacer un upgrade en de sistema de 4.7 a ecc6 unix/db oracle a 10, aqui en detalle entre sistemas las ordenes pasan bien sin problema se visualizan perfecto, pero las ordenes de trasporte en PRD se quedan ahy no pasan, hasta que corro este reporte RDDIMPDP en el trx se38 en el mdt 000 con ddic varias veces. Despues de eso la orden pasa. Ya cheque permisos de rutas, usuarios ddic y el tmsadm en ambos como server´´s y encontre varias notas.
Note 449270 - Job RDDIMPDP is not triggered by sapevt Note 374379 - Triggering SAPEVT from a remote host Note 11661 - Event-driven call of background jobs does not work Dentro de la sm64 si existen estos job SAP_TRIGGER_RDDIMPDP SAP_TRIGGER_RDDIMPDP_CLIENT y estan activados. Ya cambie el kernel al mas actual que a liberado sap pero no he tenido exito. Ahora me di cuenta dentro del sistema operativo al listar los servicios tp que se quedan vivos despues de pasar la orden tengo q matarlos manualmente. Segun se que despues de pasar una orden no debe haber ningun servicio tp. Mi Log es este:> **************************************** NiBufSend starting NiHsLGetHostName: found address 10.1.5.3 in cache NiIGetHostName: addr 10.1.5.3 = hostname 'productivo' NiHsLGetServName: found port number 0E.10/3600 in cache NiIGetServName: port 0E.10/3600 = servicename 'sapmsPMP' ***LOG Q0I=> NiIWrite: writev (32: Broken pipe) [nixxi.cpp 3948] *** ERROR => NiIWrite: SiSendV failed for hdl 0 / sock 9 (SI_ECONN_BROKEN/32; UD; ST; 10.1.5.3:3600) [nixxi.cpp 3948] *** ERROR => MsINiWrite: NiBufSend (rc=NIECONN_BROKEN) [msxxi.c 2476] *** ERROR => MsIDetach: MsINiWrite (rc=NIECONN_BROKEN) [msxxi.c 1145] MsIDetach: send logout to msg_server NiICloseHandle: shutdown and close hdl 0 / sock 9 NiBufIClose: clear extension for hdl 0 MsIDetach: detach MS-system MsDetach, rc = 0 *************************************** Fri May 8 16:24:14 2009 Trace File of External Event Raiser (Level=0, Append=1) EventID: SAP_TRIGGER_RDDIMPDP SAP message server host: productivo SAP message server service (old): sapmsPMP *** ERROR ***: MsSndTypeOnce, rc = -20 *** ERROR ***: Event raise failed *************************************** Espero alguien me pueda ayudar. Llevo algunos dias con el problema. SLDS |
#2
|
|||
|
|||
el job RDDIMPDP se replanifica con el programa RDDNEWPP.
Ejecutalo en el mandante 000 con el ddic. saludos |
#3
|
|||
|
|||
Trasporte en demora, no pasa se queda en cola. Unix/Oracle
Hola Amigo mil gracias por la respuesta, de hecho hice en el mtd 000 con el ddic, corri este reporte que borra todos los job viejos o que estan de sobra RSBTCDEL, despues corri RDDNEWPP este que me indicas y le di alta prioridad al job RDDIMPDP. Aqui el detalle es que al hacer un trasporte este job no se ejecuta automaticamente a pesar de que en la sm64 esta activado estos 2 eventos SAP_TRIGGER_RDDIMPDP, SAP_TRIGGER_RDDIMPDP_CLIENT que son los referentes a ejecutar el trasporte cuando uno lo lanza desde la stms. Pero no lo hace hasta q lo hago manual. De hecho reconfigure la ruta de trasporte y ambos server´´s se ven las ordenes, sin problema.
Aun no funciona. |
#4
|
|||
|
|||
Quedo Solucionado
Fue un logro, muchos dias sin dormir quedo listo.
SLDS |
#5
|
|||
|
|||
Yo tube el mismo problema y fue porque en service no estaba definido el puerto sapmsSID nro/tcp
Lo habilite y en las propiedades de la cola agregue ese mismo valor. |
#6
|
|||
|
|||
Solucion
Aqui el detalle fue la redireccionar unos parametros que apuntaban a la vieja base. Desde El OS
SLDS |
#7
|
|||
|
|||
yo aun sigo con el mismo problema, por favor indicame que mas hiciste.
saludos |
#8
|
|||
|
|||
Cuando os encontréis con este tipo de problemas "transport hangs", además de lo que ya han indicado de ejecutar el report RRDIMPNEW en el mndt 000, hay que analizar las trazas que la herramienta TP deja a nivel de filesystem:
/usr/sap/trans/log --> mirar los últimos por fecha de modificación. /usr/sap/trans/tmp --> también mirar aquí si existe algún log adicional. Problemas que me he encontrado en esta situación: 1- Tuve que ejecutar realmente el report RDDIMPNEW. 2- El kernel estaba mal actualizado (descomprimido con root), y daba acceso denegado al ejecutar el sapevt. 3- En alguna ocasión se ha quedado algún archivo "pillado" dentro de /usr/sap/trans/tmp... en esos casos el log de TP te dirá cual es el fichero al que está re-intentando acceder. En tal caso lo borras, y vuelves a lanzar el transporte. Un saludo.
__________________
--- Visita mi Blog relacionado a temas de Administración SAP Netweaver: |
Herramientas | Buscar en Tema |
Desplegado | |
|
|