Single stack vs. Dual Stack - Why does SAP recommend single stack?

[Former Member]

Hello SAP,

I am a business partner who specializes in infrastructure consulting for SAP solutions. The SAP Consultants I am working with recently have been recommending that customers install single stack systems. I would like to know why? Are there problems with dual stack systems? Is SAP changing things in a later release and they want customers to be prepared for the change?

From an infrastucture point of view this recommendation combined with SAP NetWeaver architecture will result in an explosion of SID names which leads to an explosion of application server instances and DBMS instances and an explosion of installed servers. I know it is possible to combine SIDs into a single DBMS using MCOD and to have multiple application servers in a single physical server, but there are issues with mulitple application server instances and MCOD use which make normal maintenance operations difficult.

I think it would be much better for customers to install dual stack systems and simply adjust the SAP profile parameters to disable one stack or the other. This way, you could still have 1 stack per application server instance and you would not be have to be creative with SAP SID names!!! Creating a DBMS instance or installing an additional server is not a simple nor economical proposition.

Regards,

Zaz

[Former Member · Accepted solution]

Hi,

We have installed our BI 7.0 landscape as dual stack systems and 1 year later, we consider it was an error because of exactly the same reasons that Markus gave you.

Especially, database copies are a nightmare...

IMHO, the main Error was from SAP to design systems which need both ABAP and JAVA. It's just a mess which increases a lot the complexity and the TCO.

Regards,

Olivier

[Former Member · Accepted solution]

Is it possible to step back and remove a J2EE stack already installed from a ABAP+Java configuration?

I have seen a short explanation given by Nathan Swenson in another sdn forum ( ).

Is this procedure approved by SAP? There is a documentation available?

Thanks for your answer.

[Former Member · Accepted solution]

Francesco - This is not the official answer, of course, but from my experience this can be a very messy effort.

The company where I work for all ABAP + JAVA are installed as dual stacks. Yes, this means a bit of an overhead, but it allows us a lot more flexibility. To get around the overhead, we have very experienced basis people and documented process in place. Mananging a dual-stack is actually easier than it sounds.

[markus_doehr2 · Accepted solution]

And what do you do when you do system copies of multi-TB system? Waiting for R3load to finish?

Markus

[Former Member · Accepted solution]

System copy is actually another technology from SAP that we ... never use.

Instead, we identify individual tables which define a SAP system (user, roles, RFC destinations, logical system configuration, etc.) and save them off via BCP OUT. Then prior to a system copy, we establish log shipping and sync up the data base.

When then run our customized script to clear out the individual tables, restore the tables using the BCP files, and bring the system up.

This results in a system refresh/copy where total downtime is less than 30 minutes. What's even more beautiful is that ... doesn't matter the database size, the refresh / copy times stay constant.

[markus_doehr2 · Accepted solution]

System copy is actually another technology from SAP that we ... never use.

Instead, we identify individual tables which define a SAP system (user, roles, RFC destinations, logical system configuration, etc.) and save them off via BCP OUT. Then prior to a system copy, we establish log shipping and sync up the data base.

So you use your SANs technology to copy the database? Or how do you copy the data?

This results in a system refresh/copy where total downtime is less than 30 minutes. What's even more beautiful is that ... doesn't matter the database size, the refresh / copy times stay constant.

This may work for ABAP but in the Java environment this can become pretty complicated because one doesn´t "know" the table names to be copied...

Markus

[Former Member · Accepted solution]

For copying, we just use robocopy to move the backup files and standard SQL server log shipping to keep the DR site in sync. The BCP files are local, so they never really have to be copied. If they do have to be copied, they are not that large in size.

With that said, yes this is not something that can be done at the last moment. However, this is a method which can same you a lot of time but requires quite a bit of prep work. We use SQL 2008 backup compression to compress the backup files (same thing can be achieved using sqllitespeed), so the files are a bit smaller. But, copying backup files for 5TB DB still takes 2 to 3 days to our DR site, via WAN.

In the prepare phases, as soon as log shipping is setup and in sync, the WAN can support our tlogs just fine (max ~250MB / minute - anything above this we start seeing tlog delays). FYI: To get around tlog delays, you can implement a parallel robocopy strategy. basically ...

1. SQL Log shipping by default uses a single process to copy. This is OK but is vunerable to lag.

2. Disable the SQL log shipping copy job.

3. We take a tlog backup every minute, so there are a few ways to divide up the files. We divided it by 2.

4. Create robocopy SQL jobs to copy tlogs with minutes 01, 23, 45, 56, etc.

5. This way, if tlogs becomes large, you'll get more network throughput.

However - Yes you are completely right (as usual ), the AS-JAVA tables are a bit harder to identify. While we have been able to establish a DR site and do failover (see my post here: ), we have not yet been able to do a refresh (or have to do this).

The only AS-JAVA application we are using is SPNEGO and GRC 5.3. Both are basically transactionally stateless or have no need to be refreshed. However, in the AS-JAVA system everything in the file level is used to reference the host name, ports, etc. Similar to the profiles in AS-ABAP. With that said, most of the configuration is still stored in the database somewhere. Bottomline is: We have analyzed the standard system copy tool SAP provided .. it's just a bit slower than we liked. And, with enough work, I am sure that we can property indentify and refresh an AS-JAVA environment.

[markus_doehr2 · Accepted solution]

Hi Kevin,

thanx for this excellent explanation - I get your point!

What I was referring to initial when speaking of "system copies" are those copies, you need to refresh a QA or DEV system. If you don't do them (or if you do them manually by copying tables) then this works. If you have a sequence of providing QA systems in a quaterly manner, then it's becoming more difficult.

We do those copies "online", means, I create a few pipes on our source (production) system, I use "dd" and "rsh" to bring those pipes to the target system and there I start a recover. This is done through a Gbit interconnect and runs for a 2.5 TB database about 8 hours (since it's a logical copy, not a filesystem copy). After the usual things to do after a system copy (environment, xuser (we use MaxDB)) the system is up in a matter of 15 minutes.

Things are VERY different in the Java environment, here you have a dozen places with hostnames/SID references which are not really documented. Especially the application developers (speak: Business Packages) don't communicate on which places they store that information. Even with standard copy mechanisms it's sometimes pretty difficult to do a copy because sapinst does not change things in all places necessary...

Markus

[Former Member · Accepted solution]

Things are VERY different in the Java environment, here you have a dozen places with hostnames/SID references which are not really documented.

Aye my friend ... we tried this when we first did a concept for XI and wow ... completely destroyed the AS-JAVA. Thankfully we had a backup. AS-JAVA is a messy place, that's for sure!

[andreas_zigann]

Hello,

we have installed dual stack BW 7.0. We copy our productive system to our quality assurance system by database copy (Oracle). I did two days of research and used the following notes to adapt servernames and instance information:

Hinweis 970518 - Hom./Het.System Copy SAP NetWeaver 7.0 (2004s) SR2

Hinweis 831812 - Config Tool zeigt falsche Parameter nach Systemkopie an

Hinweis 757692 - Hostnamen für eine J2EE Engine 6.40/7.0-Installation ändern

Now I can refresh the quality assurance out of the productiv system within two hours after DB-Copy, 1 hour ABAP and 1 hour J2EE.

With this information I can adapt technical configuration. You have to adapt also the configuration of application like WEBDYNPRO, Portal Content System connection, etc.

Regards

Andreas

[markus_doehr2]

I am a business partner who specializes in infrastructure consulting for SAP solutions. The SAP Consultants I am working with recently have been recommending that customers install single stack systems. I would like to know why? Are there problems with dual stack systems?

The problems are:

- difficult to size and maintain - Java + ABAP will fight for resources (memory,CPU) and there´s not much one can do to tune if either ABAP or Java as dual stack instance on a single box is running nuts (for whatever reason).

- System copies via R3load - if you want to copy a huge system (let´s say ERP 6.0 + Java stack) you need to use sapinst + R3load to do the copy. Imagine if the system is 1 TB or bigger, this is very time consuming

- Upgrades are complicated - if you upgrade a dual stack system you need to run two PREPARES and two upgrades at the same time - there are sync points each upgrade wait for the other to finish --> difficult to plan in sense of runtimes and even more notes/preparation to do (a dual stack SolMan upgrade from 3.2 to 4.0 had almost 100 notes (technical!) and two upgrade preparation guides...)

- interdependencies - example: you run ERP + EP + BI-Java on one system. You upgrade your BI (which is on a different box) to a new support package. Since the BI-Java need to be in sync with the BI ABAP support package you need to upgrade the EP too - and since there´s a direct dependency (doublestack system) you will need to install support packages on your ERP. So you finally end up in having dependency chains that a total different system (BI) will force you to upgrade/patch your ERP. And if you have e. g. a CRM connected to the same EP you will need to patch that too...

Is SAP changing things in a later release and they want customers to be prepared for the change?

No - the possibility of having a dual stack installation will be still there.

From an infrastucture point of view this recommendation combined with SAP NetWeaver architecture will result in an explosion of SID names which leads to an explosion of application server instances and DBMS instances and an explosion of installed servers. I know it is possible to combine SIDs into a single DBMS using MCOD and to have multiple application servers in a single physical server, but there are issues with mulitple application server instances and MCOD use which make normal maintenance operations difficult.

I agree - MCOD is not a good solution for this problem.

I think it would be much better for customers to install dual stack systems and simply adjust the SAP profile parameters to disable one stack or the other. This way, you could still have 1 stack per application server instance and you would not be have to be creative with SAP SID names!!! Creating a DBMS instance or installing an additional server is not a simple nor economical proposition.

There are 36 * 36 * 36 (minus a few reserved) names for SIDs- this should be enough - also for the biggest customers

Of course one could install both and disable the one you don´t need - but this won´t help in dependency thing. If you e. g. install a dual stack instance for CRM and disable the Java part, you can nicely run it. In case of an upgrade, you will need to upgrade the Java part too (see above) although you don´t use it. The upgrade will detect the doublestack and wait for the java instance to be upgraded too. Same is true vice versa. And believe me: you don´t want that

In fact it is better to separate - that´s at least our experience. The main no-go for such a configuration on our side was the dependency thing. Since they are there and you can´t do much about them we decided to have a 1:1 relationship for ABAP backend and Java "frontend". You will get more instances (and names and databases) but you can patch applications independently from each other. So an implementation of a BI patch won´t imply that you finally also patch your ERP production and other systems that connect to that portal.

There are virtualization techniques available to not need more boxes, you can consolidate them on one machine as if you were installing a dual stack so that is not really an issue. This depends, of course, on the platform and database you use (e. g. Oracle does not support production installations in VMWare). We use for our Java instances Solaris on Opteron (or Intel 64bit) and zones/containers and for the ABAP part we use Linux + Xen. Both virtualization methods come with the OS (so no additional $$$) and both are supported by SAP.

The propagated advantage of having a dual stack installation (shared memory access etc.) is so small that it doesn´t outban the additional complexity - which is definitely there.

I hope those arguments will help to understand SAPs (and the consultants) position - get back if you want more

Markus