In these hard economic times we get to hear one question very often these days: Why do we need SQL Server Enterprise Edition for SAP Netweaver based applications? Background to this question is that SAP mandates the usage of SQL Server Enterprise Edition for applications based on the SAP Netweaver Stack. Especially by customers who did not purchase SQL Server from SAP, but through other channels, this question is asked frequently. Those customers would like to use SQL Server 2008 Standard Edition, especially for their smaller systems. Let me give you some ideas why SQL Server Enterprise Edition is needed for SAP Netweaver.
Latest with SQL Server 2005 SAP Netweaver took hard dependencies on certain features of SQL Server which usually are not present in Standard Edition. For SQL Server 2005, it started with SQL Server’s Table Partitioning which is an Enterprise Edition only feature. SAP implemented the usage of this feature in SAP BI/BW. In older Basis releases like 6.40 (SAP BI/BW 3.5), the usage of table partitioning was on customer demand only (non default). However with SAP BI 7.0, the usage of SQL Server Table Partitioning for Fact tables and Staging tables became the default behavior. Means there is a hard dependency on the presence of the Table Partition feature in the SQL Server 2005/2008 version.
Other Enterprise Edition features SAP customers and to a part SAP relies on, is ‘parallel index creation’ introduced with SQL Server 2000 or Online Index Maintenance introduced with SQL Server 2005. Especially Online Index Maintenance is something one hardly would like to miss today with database sizes in the Terabytes.
Now with SQL Server 2008 we introduced Database Compression and Backup Compression. Both features don’t exist in SQL Server 2008 Standard Edition. In order to use storage in a space efficient manner, SAP by default takes advantage of the new SQL Server Row Compression. This means if you install new SAP systems against SQL Server 2008, SAP will create the tables with using the new and more space efficient Row format. This is true for all the SAP products using the ABAP stack. It represents a hard dependency against a SQL Server feature which doesn’t exist in Standard Edition.
But think about the benefits of features like Database Compression and Backup Compression: They can save you a lot of money. Backup Compression was something a lot of customers requested for a long time. Hence a lot of customers spent money on 3rd party applications to get compressed backups. This isn’t necessary anymore with SQL Server 2008. A net saving one should consider when looking at SQL Server Enterprise Edition. Readers of this blog might have seen articles on Microsoft IT applying the Row compression (new more efficient Row format) to our SAP ERP system. We saved quite a lot of space. Space which now extends the life span of the storage used in production, test and different sandbox systems. All in all around 400K-500K USD of investments in storage could be saved by applying the new Row format (Row Compression) to Microsoft’s productive SAP ERP system alone in this fiscal year. Another customer reported a reduction of 35% volume of their SAP BI/BW system by just applying Row compression. More and more experiences around compression come back, reporting reducing larger tables to a fraction of their original size by either applying ROW compression or Page Dictionary compression. The potential savings achievable by SQL Server’s database compression features and Backup compression could pay easily for the more expensive initial investment of SQL Server Enterprise Edition. We also don’t make a secret about it, there will be more features about lowering the storage footprint of SQL Server in the future.
For a detailed matrix on features supported by different editions of SQL Server please checkout this document: http://msdn.microsoft.com/en-us/library/cc645993.aspx
Hope this gives some good background