Security transports have long import time

[former_member84834]

I'm wondering if anyone could enlighten me as to what would cause security transports take considerably longer to import into my production system as opposed to my QA system.

1.) The QA system is a recent homeogenous copy of production ( 4 weeks old)

2.) The number of users and their roles are copied from production to QA as part of the homogenous system copy

3.) I have several instances where a security transport takes 2 minutes to import to QA, but 12 to import to production.

4.) The transport process spend the vast majority of time in the "Method Execution" phase of importing in both QA and production.

[former_member84834]

Thank you for all your ideas. I stumbled across the answer. One of my peers enabled auditing in the production instance of SAP. 29,000+ tables are being audited. Auditing is not enabled in QA or DEV. Don't let anyone tell you that auditing does not affect performance. I shut it off in production and my transport times are in line with those of QA. Previously they were taking about 10x longer in production than in QA

[Former Member]

Hello,

If your PRD system has multiple App servers and your QAS has only one that could be the reason. Your PRD system needs to coordinate the changes accross multiple servers (can't have server A using different code than server B) and that slows things down. I also find transports run best on the Central Instance.

Regards,

Michael

[Former Member]

Hello Michael,

These are table entries rather than code. Even if it woul have been code everything goes in the database. There is nothing like coorination going to take place amongst the app servers! At the worst a case can still be made for buffers but I really doubt that it can be that case in this scenario.

@Timothy,

Can you try importing the transports when the user activity and therefore load on the system is much low. Conversly if you are not allowing users to frequently access Central Instance just try to do a manual import of central instance.

Also the important thing to understand is any SAP transport would trigger a series of jobs and in case background processes are occupied then there is chance of a delayed start of one of the jobs thereby impacting the entire import timings.

In QA normally the load would be low and batch process might be more readily available when compared to CI.

Regards.

Ruchit.

[Former Member]

Hello,

Security transports are followed by a user comparison during the method execution.

Probably you have a lot of users in PRD, therefore it can take longer.

Also take a look at these 2 SAP Notes, sometimes it is good to consolidate transports, especially in PRD to speed up the import time:

Note 139513 - Merge transports for high availability systems

Note 1223360 - Composite SAP Note: Performance optimization during import

Success.

Wim

[former_member759680]

Do DEV and QA share the same /usr/sap/trans (same transport group)?

And PRD has a separate /usr/sap/trans?

But this still shouldn't affect the step Method execution, i guess.

[Former Member]

Hi Timothy,

Quite funny but is this situation for security transports only or is it for all transports. Also a weird scenario could be that the actual import is taking place on a dialog instance host with much poorer resources compared to the QA system.

May be you can check on security forum as well.

Regards.

Ruchit.

[former_member84834]

This occurs with security transports only. The idea of it running on a dailog instance is interesting, but my dialog servers are equivalent in size to my QA server. QA has 4 CPU's and 16Gb memory - the dialog servers in production have the same configuration. Interestingly The production central instance has 9 CPU's and 32Gb memory.

[former_member84834]

This occurs with security transports only. The idea of it running on a dailog instance is interesting, but my dialog servers are equivalent in size to my QA server. QA has 4 CPU's and 16Gb memory - the dialog servers in production have the same configuration. Interestingly The production central instance has 9 CPU's and 32Gb memory.

[ImtiazKaredia]

Check the step getting executed in SM50 for the import step. What is it doing like sequential read, direct read..

One possible reason may be that on your production system the database statistics are not updated.

[alen_mikulic]

Hi,

One possible reason is the usage of roles in production by end users logged in with the same roles being updated in production by transports.

The others being updation of all roles in buffer of the application servers once the import is started.

Cheers Sam