ECC6.0 on windows verses unix

[Former Member]

Hi ,

Can anyone give me a comparative study of installing ECC6.0

on Windows and Unix from the point of view of performance and

user load.

It will be also helpful if you can give me an idea when it is

beneficial to consider windows and when unix environment.

Regards,

Sasmita

[Former Member · Accepted solution]

Hi Sasmita,

"Windows vs. Unix" is a difficult question to seperate fact and opinion.

Today Operating Systems and Databases have commoditized in terms of features, stability and performance.

OS and DB have not commoditized in terms of price however. Unix/Oracle and mainframe are the most expensive platforms to run SAP on. There are cheaper and better options. The commercial relationship between SAP and Oracle is not too good and this is impacting the merits of running SAP on Oracle.

Oracle itself is a good database, however last time I checked SAP were still delaying official support of 10g over two years after it was released!

SAP is an application that has been ported to many different operating systems (HP-UX, Solaris, Windows, zOS for the mainframe etc). To a large extent SAP does not utilize specific functionality of a particulary operating system or database.

Logically speaking, how could SAP be a truely multi OS application that will run on everything from a IBM zSeries mainframe to a desktop PC running Windows if it was highly optimized for any particular OS. SAP would go bankrupt developing and supporting so many different platform combinations. (remember a platform has multiple DB combinations such as AIX Oracle, AIX DB2, AIX MaxDB).

There is very poor understanding in the SAP community of the recent developments in regards to Windows (particularly amoungst those who work with Unix).

Historically Windows has not be an option for a site with more than ~500 users because Windows was a 32bit operating system and the Intel x86 (386, 486, Pentium etc) processor was a 32 bit.

A 32bit processor has performance limitations regardless of the operating system. 32 bit HP-UX or AIX would not be suitable for large sites, neither was Windows until recently.

A 32bit platform is limited to 4GB of memory (2^32). Windows had a way to try to utilize more than 4GB by mapping memory (AWE) but it was not very useful. With only 4GB of memory available you will typically find that your OS will start paging to disk and slow down.

Fortunately there are now two different 64bit versions of Windows available in addition to the 32 bit version. There are special limitations regarding the use of these operating systems in an SAP context.

In total there are now THREE distinct versions of Windows:

1. Windows IA32 - traditional 32 bit Windows, no useful ability to utilize more than 4GB RAM - everyone is familiar with this one

2. Windows x64 - utilizes the 64 bit extensions first introduced by AMD and then Intel - this version of Windows CAN utilize more than 4GB of RAM if the program has been compiled for x64. If a program has not been compiled for x64 it is generally given a complete 4GB address space to run in. IA32 and x64 are compatible, you can even install Windows IA32 on a x64 chip and it will run very fast. So this version of Windows is "backward compatible" you could say, as it runs IA32 applications and new x64 applications.

3. Windows IA64 - completely different version of Windows compiled for the Itanium chip. The itanium chip is most often found in large HP-UX servers and is very often used for running large SMP Unix/Linux systems. Microsoft ported Windows 2003 to Itanium in 2002/3 and Windows runs very well on this platform. The chip is a complete redesign and is not based on an x86 instruction set. As it result you cannot run IA32 executables effectively. If you application is not compiled for IA64, then forget about running it on an IA64 system. This platform is excellent for large sites.

SAP support all versions of Windows (IA32, x64 & IA64) to varying degrees. IA32 is very common, but is not a good solution for SAP since it has a performace limitation due to the memory address space restrictions. All SAP components I know of run on IA32 however.

Most ABAP components are NATIVELY compiled for x64, the Java components generally are not natively compiled but will run as IA32 applications very well (fast & stable).

Most SAP components ABAP and Java are NATIVELY compiled for IA64 (at least for Win SQL IA64 which is the platform we run - check PAM for other DB - there are restrictions on Oracle). SAP applications run very well and very fast on Windows IA64. Stability is also very good.

Database and SAP related benchmarks show no significant differences between Windows and Unix:

http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=all (check #3 on the list)

http://www50.sap.com/benchmarkdata/sd3tier.asp (over 96,000 users benchmarked on Windows SQL Itanium)

With a Windows environment you do need to block access to your servers with a firewall/SAP Router/VLAN/Web dispatcher or some other mechanism. A well designed Unix environment should follow a similar network design as well.

There are some limitations with MSCS which you need to overcome with third party software. HP offer a good solution for HA.

Stability is dependant on your hardware. In the case of HP Windows Itanium servers there is no difference whatsoever between the server hardware for HP-UX and Windows. In fact you can have Win2003 running in one partition and HP-UX in another.

You do need to ensure that your Windows support people are disciplined in regards to change control on the OS, however this is also true of Unix platforms.

IA32 and x64 hardware is generally of a lesser quality unless you buy from the larger vendors such as HP and IBM

Hope some of this is informative. The TCO case for moving to Windows is compelling if you do the numbers, it will pay for itself very quickly.

Cheers

Deepanshu

[markus_doehr2 · Accepted solution]

Very interesting statements!

> There is very poor understanding in the SAP community of the recent developments in regards to Windows (particularly amoungst those who work with Unix).

What do you mean with that?

<...>

> Most ABAP components are NATIVELY compiled for x64, the Java components generally are not natively compiled but will run as IA32 applications very well (fast & stable).

Well - that is not true.

Java code is bytecode, it runs in a "virtual environment" - which is the Java VM. If you run the supported VM for Windows x64 then the Java application itself is 64bit also. Basically any Java programs is by definition cross platform, you can install them theoretically on all platforms (the same identical file). However, things as Adobe Document Services brings native libraries with them which limit the platform availibility. But any pure Java application is totally agnostic on which OS it runs - as long as the VM (the execution environment) is J2EE compliant. So e. g. the Java portal application you install (EPCORE) is identical on Windows, HP-UX, AIX and IBM i.

> Most SAP components ABAP and Java are NATIVELY compiled for IA64 (at least for Win SQL IA64 which is the platform we run - check PAM for other DB - there are restrictions on Oracle). SAP applications run very well and very fast on Windows IA64. Stability is also very good.

Check Note 931024 - FAQ: 64-bit platforms for Windows (version 11, not the actual version):

<...>

On the other hand IA64 was designed to be the next generation for HP PA-Risk and Intel x86 32-bit. Its EPIC architecture offloads scheduling logic to compilers. Instead of that logic the chip contains more parallel integer and float units and more registers. Scientific calculation highly benefits from that architecture, but on Windows large applications based on virtual machines, like ABAP, Java or .Net, are not able to fully leverage it. Therefore the SAP application server on Windows doesn't show the performance that's expected from the pure cpu power. Also 32 Bit applications pay a significant performance penalty on Windows.

<...>

On to of that another big vendor (Unisys) does not sell any more IA64 hardware (http://news.cnet.com/8301-13924_3-10167332-64.html) - so the only option you have here is HP and SGI/Cray. SAP does not plan to support Windows 2008 + Oracle (as of now according to PAM) on IA64 so if you don't run SQL Server or MaxDB you may run onto a "dead" platform/processor (for Windows).

> IA32 and x64 hardware is generally of a lesser quality unless you buy from the larger vendors such as HP and IBM

There are even more options for x64 processors: Solaris 10 (http://www.saponsolaris.com/).If you start new implementations that can also be a good option: A mature Unix on "commodity" hardware with a superior filesystem (ZFS) and virtualization included in the OS (zones/containers) without the need of paying additional license fees for VM solutions or filesystems/volume managers (e. g. Veritas VxFS/VxVM).

> Hope some of this is informative. The TCO case for moving to Windows is compelling if you do the numbers, it will pay for itself very quickly.

We ran our SAP systems for 6 years on Windows until we moved to Linux. Not because of license costs but because of stability.

High volume printing (at that time under Windows NT 4.0 and Windows 2000) was a nightmare, service pack installations or updates for the OS together with SCSI drivers and tape drivers was a second nightmare, not to talk about the virus affinity. This has certainly changed with Windows 2003 but the virus thing stays. If you need to put firewalls and/or virusscanners in front of you boxes to secure them and deal with filesystem and registry ACLs and monthly reboots (because of MS patch day) I'm not yet convinced, that the TCO is really competitive with a *nix based platforms or IBM i. But as always: if you are fine with that - go for it!

Windows may appear "easier" to administer, nice GUI, "easy clicking" - but that is only on the first view. Diagnosing problems on Windows can be pretty tricky and if one reads the "SAP on Windows" forum, one will notice, that as soon as problem can't be solved by "clicking somewhere", many people are clueless (no offense).

The platform chosen should be the best for YOUR environment, choose the one that YOUR administrators are most familiar with or if you choose a different one, make sure you educate them so they know how to run your systems. For our requirements it turned out not to have been the right choice, that's why we migrated away from Windows.

Markus

[Former Member · Accepted solution]

Dear Markus,

Thanks for more update on same.

Cheers

Deepanshu

[Former Member · Accepted solution]

Dear Mr.Markus & Deepanshu,

Very interesting discussion and Pros & Cons of SAP on "Windows Vs. Unix"

Regards

Rayees Palot

[Former Member · Accepted solution]

Dear All,

We are in the planning phase of implementing SAP Business Objects with BW. So far our ERP 6.0 systems run on MS Windows IA64/MS SQL environment. But taking into consideration the future growth, we are in 2 minds to go ahead with the same platform and DB.

Can you all help me to give some pointers/comparitive factors to the decision making committee to go with HP-Unix/Oracle or Windows/Oracle as the estimated size of database is around 4TB (5 year growth taken into consideration)?

Appreciate your guidance.

Regards,

Mohammad.

[markus_doehr2 · Accepted solution]

> Can you all help me to give some pointers/comparitive factors to the decision making committee to go with HP-Unix/Oracle or Windows/Oracle as the estimated size of database is around 4TB (5 year growth taken into consideration)?

The question is: Do you want to stay with Itanium-2 as platform or do you maybe consider switching to less expensive platforms such as x86_64 (with Linux/Windows) - which are "mainstream"?

As already stated: There is no planned support for Windows 2008 on IA64 and Oracle (see actual PAM). So you will need to stick with Windows 2003. You may also run in troubles if HP (or SGI) creates new machines that are only supported on Windows 2008 in the future. So you may already be on a dead-end platform (SAP may change their plans though).

Also consider the fact, that all patching and problem resolution may be a bit behind all other mainstream platforms. As an actual example you can take patchset 10.2.0.4 - which was released last year in september and is as of today still not released for Windows/IA64.

HP-UX will certainly be supported long term and can be considered "mainstream".

If you switch from Windows IA64 to HP-UX IA64 you need to take into account that Windows is implemented as a little endian (LE) platform whereas HP-UX on IA64 is big endian (BE). This may have impact on interfaces and data transfers to other systems if technologies other than Webservices or RFC are used (filesystem transfers etc.)

Other "pros and cons" are already above written - just read them

Markus

[Former Member · Accepted solution]

i think this deserves to its initial writter Sam Badan

[Former Member]

Hi,

I dont think you will get readymade material on this. But you need to think about windows stability and SLA required for your business.

Example.

Windows regular updates, antivirus updates etc might need the reboot of server.

I found Disaster Recovery is lot easier in unix than windows.

Memory management on unix/windows

Cost on unix/windows platfroms

Hope this helps.

Manoj