Transports very slow in production

[Former Member]

we are running BW transports into production which ran in 2-5minutes on pre prod but are now taking 30 mins plus (both boxes are same spec, transports are config only no data).  Looking at the logs I notice where previously there was one second gap between import and check version this is now taking 5 minutes plus. I am not a Basis person but our Basis guys are saying they see no issue so any ideas or help appreciated If you need any additional info I will give all I can but they have locked down all access to most st and sm codes but I know the odd backdoor   They use shared drive over network rather than usr/sap/trans over nfs but our networks guys are claiming no issues and lan activity in st06 is ok last hour (8k in 16k out) but has been in low double digits rest of day so could just be batch jobs creating packet volume now?

[Sriram2009 · Accepted solution]

Hi Peter

Any major changes in the change request?  If possible do the full system restart and check the transports.

BR

SS

[Former Member · Accepted solution]

Thick ache S Sriram (hope I guessed region right!) for quick response.  transports are new config DSO's, transformations etc minor start end routines example attached of current running transport and previous log.

[Former Member · Accepted solution]

No chance to re-start system, we have overnight data loads and also I have no stms access and basis have set as a script so my only hope is to resolve the delays by other means, or at least manage some decent root cause analysis so I can help them sort this out for future....

[avadhesh_sap]

Hi,

Can you please ask BASIS team to check STAD logs in system:

1) In the transport logs, check for the exact time when TR is imported or import initiated.

2) Start STAD transaction and analyse there with time slot captured in above step and there you can find work process response time, database esponse time

alternatively , as you said it take time in check versions, could you please try importing TR with option "ignore invalid component version"(please confirm with TR owner before doing this.

Thnaks,

Avadhesh

[Former Member]

Hello Peter,

Can you check the BTC usage with SM50 and also check the background jobs with hSM37 to see if there are background jobs with high delay times. I wouldn't be surprised with it being a BW that maybe all your BTC processes are in use.

KR,

Amerjit

[Former Member]

21 of 35 BGD slots free, I am only user occupying dialog slot, max delay time on any SM37 job today sub 1 minute, st06 shows no bottlenecks or issues yet; where normally checks version within 1 second of import is taking 6 minutes. Log for import and check version both blank so no pointers there, very ODD, if delay wasn't so big between import and check would say network but......

[Former Member]

Hello Peter,

1. Could you check with SM37 filtering by jobname RD* for the period 21-09 19:57 => 21-09 20:15. Check the job log of each of the RD* jobs and see if the start and end time corresponds to what you are seeing in the import summary.

2. If you are getting a blank screen for the job logs then that in itself is a problem.

The logs should be available on the o/s level so ask your basis people to provide them to you for analysis. You will then be able to see what's going on. Also ask then to have a look in the ALOG and SLOG files. Try having a look with AL11 by navigating to DIR_TRANS.

3. Network .... 8k in 16k out ..... are you sure ???????

KR,

Amerjit