cancel
Showing results for 
Search instead for 
Did you mean: 

Transports are brutally slow - what can I do to speed them up?

Former Member
0 Kudos

Two iSeries – DEV and PRD – connected by a T1 circuit

/usr/sap/trans is on PRD

Both systems kernel 720_EXT, patch level 513, OS at V7R1 - ptf's are current

DEV – parallel processes set to 2 – for HR year end packages/Phase 1  – 8.5 hours

PRD – parallel processes set to 1 – same HR year end packages – 50 minutes

Will upping the parallel processes on DEV to 4 or 5 actually help?

Is there something else I can do? – this is unbearable - Thanks

Accepted Solutions (0)

Answers (4)

Answers (4)

christoph_ostrop
Active Contributor
0 Kudos


please have a look at sap-note 1581638

http://service.sap.com/sap/support/notes/1581638

maybe STMS-option SP_TRANS_SYNC = OFF  will speed up TMS?

Former Member
0 Kudos

If I am reading those notes correctly, that parameter affects the import. My biggest problem is with the export of the transports. I am also curious about parameter tp_version. Does that have any impact? I know it became a global variable some time back. In my case it = 266. When I run tp -v, it tells me "This is tp version 380.18.68 (release 720, unicode enabled)." Patch level =616. Does it actually matter if I change that?

Former Member
0 Kudos

Hello Abdelhadi / Volker / Rick

I have a similar problem; I have three IBM i systems (DEV, QAS and PRD); my domain controller is in the DEV environment; and my PRD system connects to DIR_TRANS from /QFileSvr.400; however, when I make an update queue PRD from Tx. STMS, the system has a high response time; I have verified that there are TP processes that remain active in the PRD environment; and when I update queue, the job QPWFSERVSO associated with the PRD system, stays in the TIMA status for several minutes. Can you help me find a solution?. I've checked the OSS notes 1924741, 68896, 1223360, 1706350 and 1742547 and I was not helpful. Thanks.

volker_gldenpfennig
Active Participant
0 Kudos

Hello Henry,

as described above:

Shrink your transport buffer to values smaller than 100KB - otherwise, it is REALLY slow ...

If you really want to have good (&identical) performance of STMS in all systems, you can only do the following as well:

In your Setup ONLY the 2 different trans directories are a solution!

With GB Ethernet it is typically 2-3 tyimes slower on the remote site ...

Regards

Volker Gueldenpfennig, consolut international ag

Former Member
0 Kudos

Henry - far be it from me to argue with Volker and Hadi. Their long term solution is almost certainly the correct way to go.

However, my problems got noticeably worse when I upgraded the kernel from 700 to 720. My COFILE gets written within seconds. My DATA file gets written within minutes. It then takes ten to twenty minutes for the update of the COFILE after the DATA file has already finished writing. I have NOT yet converted to the new user concept.

It might sound strange to bring that into the discussion but I had some problems with some recent kernel patches because the cofiles and data files all of a sudden had new owners (DEV01 instead of DEVOFR) and some "hidden" authorization issues. Hopefully I will be able to perform the CONVUSRCPT by the end of the month. I don't have high hopes or anything, but I will let you know if it does in fact help.

Former Member
0 Kudos

Hi Rick;

I deleted buffer of my PRD environment; but I needed to have the information of all 2014; Therefore, I deleted by running a CL at the operating system level. The command I used was:

TP PARMLIST ('DELFROMBUFFER DEVK900000 PRD pf=/usr/sap/trans/bin/TP_DOMAIN_DEV.PFL')

I deleted information from 2011, 2012 and 2013 and the response time has been reduced; not as much as I expected but at least acceptable.


Thanks Volker!!!

volker_gldenpfennig
Active Participant
0 Kudos

Hello Henry,

I do not see a good reason, why you want to have one or two years of IMPORTED transports in the queue. There is the history button, that should help on this ...

Therefore, I would always delelte ALL imported requests with the menu item in STMS - that shrinks the buffer file a lot ...

If you are on 7.02 or higher, the already mentioned SP_TRANS_SYNC = OFF is very helpful ...

Regards

Volker Gueldenpfennig, consolut international ag

Former Member
0 Kudos

Hello Rick,

Hadi is fully correct 😉

In your Setup ONYL the 2 different trans directories are a solution!

Everything else Ends up in such a mess ;-(

... even with T1 lines ..

With GB Ethernet it is typically 2-3 tyimes slower on the remote site ...

Regards

Volker Gueldenpfennig

Khouri
Explorer
0 Kudos

Hello Rick,


for the short term I will go for cleaning up the transport buffer of the affected system.

Make a backup of the buffer file (/usr/sap/<trans-dir>/buffer) before starting with clean up.

For the clean up execute the following command with <sid>adm:

tp 'cleanup <sid> pf=/usr/sap/<trans-dir>/bin/tp_domain_<sid>.pfl'

I suggest for the long term solution to go for 2 local transport domains for DEV and PRD and connect both in STMS configuration.

Hope it helps.

Best regards,

Hadi

Former Member
0 Kudos

Thanks for the information. I am not really clear about how I would set up "2 local transport domains for DEV and PRD and connect both in STMS configuration." I know we created a /usr/sap/tran2 on DEV when we were performing an upgrade a few years ago, but we basically treated DEV as a standalone instance in that case. I'm not sure how I would link two standalone instances in STMS if that is what you are recommending. Could you refer me to some OSS notes or other documentation? Also, my version of tp does not recognize the 'cleanup' parameter but I regularly clear the buffer anyway. Manual cleanup of the /usr/sap/trans subdirectories is fairly regular as well. Thanks again for all your help. (Volker too)

Khouri
Explorer
0 Kudos

Sorry Rick,

First of all, I want to say that I'm really sorry I am only replying to your email now. I can get a little scatterbrained when life gets busy and lose track of even more important things.

Concerning how to set up "2 local transport domains for DEV and PRD" please consider the following:


Example of initial Set up:

- DEV  as Domain Controller and  Local  DIR_TRANS (/usr/sap/trans) 

- PRD connected to  Domain Controller DEV and  Remote DIR_TRANS via QFileSvr.400  (/usr/sap/trans)


Configuration of 2 Local TMS  :

- Check whether SIDADM (SIDOFR) are present on both side and have the same password

- Remove the symlnk for DIR_TRANS on PRD Server

- Copy the local DIR_TRANS on DEV to a local DIR_TRANS on PRD (SAVF)

- Log on to PRD Client 000 and delete the TMS configuration (T-Code STMS) 

- Distribute the TMS Configuration and also check in DEV

- Create a new Domain Controller in PRD and activate the configuration.

- Log on to PRD domain controller client 000 T-Code STMS --> SAP System --> create --> Domain       link  Enter the parameter for DEV system. 

- You can now see that you have requested the domain link to the other domain in the system overview.

- Log on DEV domain controller client 000 T-Code STMS --> SAP System --> Approve

- Confirm and distribute the configuration.

You can now see all systems in both domains in the system overview and the import overview, but you still need to adjust the transport route.

- Log on DEV domain controller client 000 T-Code STMS --> Overview --> Transport Route --> Edit

Create a new Transport route and add PRD system.

Now once you release a transport in DEV  the import queue of PRD shows the requests to which the transport files must still be transferred. .

It looks too many work steps but it isn't when you are a bit familiar with the STMS concept.

If you are still interested in the cleanup command please send me the error message.

Regards,

Hadi

Former Member
0 Kudos

Thanks, that is very helpful. In my situation PRD is currently the domain controller so the roles are reversed but I think I see the process now with the "domain link" .However, I'm still not clear on what I actually gain. The files still need to be duplicated to the remote machine at some point. At what point does that happen? Is it just a "straight copy" as opposed to "multiple reads and writes" where I gain performance? Sorry, just thinking out loud here.

Khouri
Explorer
0 Kudos

Hello Rick,

Concerning you question about at what point does data files get "duplicated" actually it depends on the system landscape and the defined transport route but assuming you have 2 system landscape then once you release the transport in DEV, it will be marked in the buffer of PRD as " Data file must still be transferred" and on PRD you have only to push the button "Adjust import queue" and the transports are available for Import.

I think all of us would like to perform transports as quickly as possible to minimize system downtimes or to be able to reduce the maintenance intervals as short as possible. In our case we have QAS in beside to DEV on the same box and as we are creating too many transports on daily basis so the scenario of multiple transport domains helps us on one hand to release the transports(export) in DEV and on other hand to import faster in QAS.

In General here some PROS for the multiple transport domains:

  • Independency and Flexibility: i.e. in case of downtime...
  • Faster SAP SW implementations (SP update, Upgrade,..), it helps here also by the estimation of run time
  • Faster export while releasing the transport - Faster Import
  • You can use the other transport domain as HA (Backup) - Additional security level:  The transport in PRD is first available after you push the button "Adjust Import queue"

Some CONS why not?

  • On PRD side data file must still be transferred (according to our experience the process takes only some seconds)
  • In case of SAP SW implementations you need to extract the files twice or move the extracted files in DEV to PRD But to be honest how many times per year you are doing SAP SW implementations

Best regards,

Hadi