Multiple or single transport domain

[Former Member]

Hi,

We have question on transport domain and planning /usr/sap/trans. Need your suggestion on this.

We have seen customers using separate transport domain for ECC,BI,CRM etc and also some customers having a common transport domain for all the systems of the landscape having a common transport domain with a common "/usr/sap/trans".

Now the question is that if we use the first option then whether we have to use separate /usr/sap/trans for indiviual landscapes like one /usr/sap/trans location for BI landscape and one /usr/sap/trans for ECC ? or we'll use separate transport domains but a "common" /usr/sap/trans path ?

Which one you guys suggest ?

[Former Member]

Hi,

Dir /usr/sap/trans is called Transport Group. So technically single transport group and multiple transport group both are feasible.

If client does not give any instruction specifically to use one transport group for each product/solution (like ECC, CRM,..), better to use single transport group which will be nfs mounted (shared in windows) - available to all system in the transport landscapes.

Thanks,

Subrata

[Astashonok]

Here in her excellent blog, Dolores, a deep professional in SAP Solution Manager clearly states that one-domain approach is highly recommended in majority of cases. Excerpt from blog:

SAP STRONGLY recommend to setup system landscape only in one transport domain to reduce the complexity and administration effort! This is in accordance with our designed goal of Charm.

The grounds for this is simplification and less effort for maintenance such landscape, which will overweight the advantages (disadvantages) of keeping multi-domain landscape.

So you'd better use one and the only domain.

[Former Member]

My recommendation will be to use separate Domain for each application e.g. one Domain for ECC, another one for BI and so on. So ECC (Dev, QA and PRD) sharing /usr/sap/trans and BI and CRM having there own.

The simple reason for this setup that I see is that for some reason I take down my Dev ECC which is Domain Controller for the ECC landscape, I will only impact the ECC landscape., my BI and CRM systems will not be impacted. Another one will be maintenance becomes more manageable when it comes to directories under /usr/sap/trans.

Another reason that I can think of is when patching the system all the patches are stored under /usr/sap/trans/EPS/in. So if we are not careful we can apply a higher ABAP, BASIS or BI version of patch which was intended for a BI system and we ended up applying on ECC as well.

Hope this helps.

Thanks,

Naveed

[Former Member]

I would recommend using septare file system and seprate domain.

/usr/sap/trans/BI for BI system

/usr/sap/trans/ECC for ECC systema and so on

You need to make sure /usr/sap/trans/BI and /usr/sap/trans/ECC are different mount point not coming from same NFS (Refer point 3 below)

There are some distinct advantages of above solution

1. You do not have dependency of one domain on another

2. Flexibility and Ease of maintenance.Like not impacting BI development when you take down ECC for say OS patching

3. Effecient usage of storage what i mean by that is you can allocate 100 GB to /usr/sap/trans/ECC and just 25 GB to /usr/sap/trans/BI because development in BI will be definately less as compared to ECC. So you can use your storage effectively.

4. Parallel processing of some task like support pack upgrade.

Also i would always recommend making Production system as domain controller in case it has an HA solution even if no HA solution my recommendation is always make your production system as domain controller because that is the system which is expected to be available to business community 24 * 7 if you are a global SAP shop.

Refer parameter TRANSDIR and DIR_EPS_ROOT for configuration

Cheers !

Manish

[Former Member]

The only other thing I would suggest is instead you are better to make Solution Manager Production your Transport Domain Controller.

Like the people above have suggested an outage in one part of the landscape like ECC would cause an outage on the migrations on the BI side. Solution Manager Production should always be online for you production monitoring and having the Transport Domain Controller running from here fits in with the centralised management that solution manager handles.

I hope this helps.

Regards,

Chris

Edited by: Chris O'Haire on Oct 4, 2011 3:06 AM

[Former Member]

Chris i would like to respectfully differ on some of the comments

"The only other thing I would suggest is instead you are better to make Solution Manager Production your Transport Domain Controller "

If a have solmnan as a single domain controller for a big landscape having ECC , SRM , PI , BI , APO etc when we take solman out for maintenance it will be impacting all the landscape above if you have each producion system as a domain controller for their respective landscape then impact of solman outage is minimized.

" Production should always be online for you production monitoring " -

This totally depends on how much and for what solman is being used for .Monitoring system continously has never been a business requirment that is one of the part of good administration but if you use solman for business process defination , ChaRM , or if it is your SLD etc then business would expect it to be up and running.

So i would suggest to have each prod system to be its domain controller for its landscape.

Cheers !

Manish